Czym jest źródło prawdy i dlaczego bez niego integracja się sypie
Źródło prawdy (single source of truth) to jednoznaczna odpowiedź na pytanie: który system jest nadrzędny dla danej informacji. Jeśli stan magazynowy mogą zmieniać jednocześnie sklep, ERP i BaseLinker, to przy każdej synchronizacji systemy zaczynają nadpisywać się nawzajem, a Ty gonisz różnice ręcznie.
Najczęstszy objaw braku źródła prawdy to „raz jest dobrze, raz źle” — stan na sklepie różni się od ERP, ceny wracają do starych wartości po imporcie, a nikt nie wie, który zapis był ostatni i prawidłowy.
- jeden system nadrzędny dla każdej informacji, nie „wszystkie po trochu”
- reszta systemów tylko czyta tę informację albo dostaje ją w jednym kierunku
- każda wartość musi być odtwarzalna: wiadomo skąd pochodzi i kiedy się zmieniła
Trzeba ustalić, który system jest główny dla SKU, EAN, stanów, cen, zdjęć i atrybutów. Bez tego każdy import będzie tworzył konflikt.
Ręczne poprawki w sklepie nadpisywane kolejnym importem z Excela, XML albo ERP. Dlatego potrzebne są reguły, logi i kontrola zmian.
Ustal źródło prawdy per pole, nie per system
Błędem jest myślenie „nadrzędny jest ERP” albo „nadrzędny jest sklep”. W praktyce różne pola mają różne źródła. Stan i cena zwykle pochodzą z ERP, ale opis, zdjęcia, SEO i treść karty produktu należą do sklepu. Zamówienia powstają w sklepie i marketplace, a ich status często aktualizuje ERP.
Dlatego źródło prawdy ustala się dla każdego pola osobno: kto je tworzy, kto może je zmieniać i w którą stronę płynie aktualizacja. To jedyny sposób, żeby uniknąć sytuacji, w której dwa systemy „walczą” o to samo pole.
- stan magazynowy → zwykle ERP (lub hurtownia przez BaseLinker)
- cena bazowa → ERP; ceny promocyjne/marketplace → wg ustalonej reguły
- opis, zdjęcia, SEO, kategorie → sklep
- zamówienia → sklep i marketplace; statusy i numery przewozowe → ERP
Produkt główny i warianty muszą mieć spójną relację, rozmiary, kolory, zdjęcia i unikalne identyfikatory. W przeciwnym razie listing, filtry i B2B szybko się sypią.
Importer powinien najpierw pokazać, co zmieni, co pominie i gdzie ma niską pewność. Dopiero potem powinien zapisywać dane do sklepu.
Kierunek danych i pętle nadpisań
Po ustaleniu, kto rządzi danym polem, trzeba zdefiniować kierunek synchronizacji. Domyślnie integracja powinna być jednokierunkowa dla każdego pola: z systemu nadrzędnego do pozostałych. Dwukierunkowość włącza się tylko tam, gdzie jest naprawdę potrzebna i bezpieczna.
Najgroźniejsza jest pętla nadpisań: sklep wysyła stan do BaseLinkera, BaseLinker do ERP, ERP z powrotem do sklepu — i przy każdym cyklu wartość lekko się rozjeżdża. Jeśli nie wiesz, w którą stronę płyną dane, prawie na pewno masz gdzieś taką pętlę.
- domyślnie jeden kierunek na pole: źródło → odbiorcy
- dwukierunkowość tylko świadomie, z zabezpieczeniem przed echem
- znacznik czasu lub wersji rekordu, żeby wykryć starsze zapisy
- brak „cichych” aktualizacji wstecznych do systemu nadrzędnego
Produkt główny i warianty muszą mieć spójną relację, rozmiary, kolory, zdjęcia i unikalne identyfikatory. W przeciwnym razie listing, filtry i B2B szybko się sypią.
Importer powinien najpierw pokazać, co zmieni, co pominie i gdzie ma niską pewność. Dopiero potem powinien zapisywać dane do sklepu.
Typowy, bezpieczny podział odpowiedzialności
Dla większości sklepów spinanych z ERP i BaseLinkerem sprawdza się prosty podział: ERP jest magazynem prawdy o stanach, cenach i danych księgowych; sklep jest właścicielem treści, prezentacji i SEO; BaseLinker pełni rolę huba do marketplace i pośrednika w przepływie zamówień.
To nie jest jedyna możliwa konfiguracja, ale jest dobrym punktem startu. Konkretny podział zależy od tego, gdzie naprawdę powstają dane w Twojej firmie — i to ustalamy na początku, zanim cokolwiek połączymy.
- ERP: stany, ceny bazowe, dane produktu księgowego, statusy realizacji
- Sklep: opisy, zdjęcia, kategorie, SEO, układ karty produktu
- BaseLinker: integracja marketplace, zbieranie zamówień, etykiety i przewoźnicy
- jedna tabela decyzyjna: pole → system nadrzędny → kierunek
Produkt główny i warianty muszą mieć spójną relację, rozmiary, kolory, zdjęcia i unikalne identyfikatory. W przeciwnym razie listing, filtry i B2B szybko się sypią.
Importer powinien najpierw pokazać, co zmieni, co pominie i gdzie ma niską pewność. Dopiero potem powinien zapisywać dane do sklepu.
Jak wdrożyć to bezpiecznie
Po ustaleniu zasad nie włącza się pełnej synchronizacji od razu. Najpierw robi się dry-run na próbce danych z raportem różnic: co integracja chciałaby zmienić i dlaczego. Dopiero gdy raport się zgadza, uruchamia się zapisy — etapami, z logami i raportem wyjątków.
Rekordy, które nie przejdą walidacji (brak SKU, podejrzana cena, pusty stan, duplikat EAN), nie powinny trafiać do systemów po cichu. Trafiają do raportu, żeby człowiek mógł podjąć decyzję — to różnica między automatyzacją a chaosem.
- dry-run na próbce z raportem różnic przed pierwszym zapisem
- walidacja przed zapisem: SKU, EAN, cena, stan, duplikaty
- logi każdej operacji i retry dla nieudanych
- raport wyjątków zamiast cichego nadpisywania błędnych danych
Produkt główny i warianty muszą mieć spójną relację, rozmiary, kolory, zdjęcia i unikalne identyfikatory. W przeciwnym razie listing, filtry i B2B szybko się sypią.
Importer powinien najpierw pokazać, co zmieni, co pominie i gdzie ma niską pewność. Dopiero potem powinien zapisywać dane do sklepu.
Co sprawdzić przed podjęciem decyzji?
Ten etap porządkuje rozmowę przed wdrożeniem. Dzięki temu zakres nie opiera się na zgadywaniu, tylko na danych, celu biznesowym i realnym procesie.
Od eksportu obecnych danych i sprawdzenia, które pola są źródłem prawdy: SKU, EAN, cena, stan, kategoria, atrybuty, zdjęcia i warianty.
Mapowanie, walidację, logi, tryb dry-run, raport pominięć, obsługę wyjątków i możliwość powtórzenia operacji bez ręcznego sprzątania.
Gdy wspierają filtry, SEO, integracje, marketplace, B2B i codzienną aktualizację bez tworzenia nowych duplikatów lub konfliktów.
Co przygotować przed rozmową?
Nie potrzebujesz gotowej specyfikacji. Wystarczy kilka konkretów, które pozwalają szybko ocenić realny zakres i nie zgadywać kosztu.
Jak przełożyć to na konkretny projekt?
Najlepszy następny krok to krótka diagnoza: obecna platforma, skala katalogu lub strony, źródła danych, aktualne problemy i oczekiwany efekt biznesowy. Dopiero wtedy można dobrać zakres bez przepalania budżetu na elementy, które nie zdejmą realnej pracy z zespołu.
Najczęstsze pytania w tym temacie
Domyślnie nie. Dla każdego pola ustalamy jeden kierunek: ze źródła prawdy do pozostałych systemów. Dwukierunkowość włączamy tylko tam, gdzie jest bezpieczna i zabezpieczona przed pętlą nadpisań.
Najczęściej ERP odpowiada za cenę bazową, a sklep za prezentację i promocje. Kluczowe jest spisanie tego per pole, żeby dwa systemy nie nadpisywały tej samej ceny.
Zwykle zbiera je BaseLinker i przekazuje dalej do ERP lub sklepu. Ważne, żeby statusy i numery przewozowe miały jedno źródło prawdy i jeden kierunek aktualizacji.
Jeśli ta sama wartość (np. stan) zmienia się cyklicznie bez działania człowieka albo „wraca” po imporcie, prawie na pewno masz pętlę. Pomaga dry-run i log z kierunkiem każdej zmiany.