Jak przygotować katalog produktów do migracji: SKU, EAN, warianty i zestawy

Zacznij od wskazania źródła prawdy

Pierwszy krok to ustalenie, z którego systemu pochodzi referencyjna wersja katalogu.

W firmie mogą jednocześnie istnieć:

• katalog w sklepie,
• katalog w Base.com,
• katalog w ERP,
• katalog w WMS,
• arkusz używany przez zespół,
• dane w marketplace,
• historyczne eksporty i importy.

Nie próbowałbym łączyć wszystkich źródeł bez reguły pierwszeństwa.

Dla każdego pola warto ustalić osobno:

• nazwa,
• SKU,
• EAN,
• wariant,
• producent,
• stawka VAT,
• jednostka,
• waga i wymiary,
• status aktywności,
• przypisanie do magazynu,
• skład zestawu.

Czasem jedno źródło jest najlepsze dla SKU, a inne dla opisu produktu. Ważne, żeby ta decyzja była jawna.

Jeżeli nie masz jeszcze mapy danych i systemów, zacznij od audytu migracji.

SKU powinno identyfikować produkt jednoznacznie

SKU jest zwykle jednym z najważniejszych kluczy operacyjnych, ale samo pole „SKU” nie gwarantuje jakości identyfikatora.

Przed migracją sprawdzam:

• puste SKU,
• duplikaty,
• różnice tylko wielkością liter,
• spacje na początku lub końcu,
• znaki specjalne,
• SKU zmieniane historycznie,
• to samo SKU użyte dla produktu i wariantu,
• różne SKU dla tego samego fizycznego produktu w różnych kanałach.

Najważniejsze pytanie brzmi: czy po SKU da się bez wątpliwości odnaleźć dokładnie jeden rekord docelowy.

Jeżeli odpowiedź brzmi „zwykle tak”, katalog nie jest jeszcze gotowy do automatycznej migracji.

EAN traktuj jako identyfikator zewnętrzny, nie zamiennik SKU

EAN może pomóc w mapowaniu, ale nie powinien być automatycznie traktowany jako jedyny klucz wewnętrzny.

W praktyce spotykasz między innymi:

• produkty bez EAN,
• jeden EAN wpisany w kilku rekordach,
• błędny format,
• EAN zapisany na produkcie głównym zamiast wariancie,
• produkty z historycznym kodem,
• zestawy bez własnego EAN.

Dlatego EAN wykorzystuję jako dodatkowy sygnał zgodności, a nie jako dowód, że dwa rekordy są tym samym produktem.

Przy walidacji dobrze działa kombinacja kilku cech: SKU, EAN, nazwa, wariant i relacja z produktem głównym.

Warianty wymagają sprawdzenia struktury, nie tylko rekordów

Najczęstszy błąd przy wariantach polega na tym, że wszystkie rekordy istnieją, ale relacja między nimi jest niewłaściwa.

Trzeba sprawdzić:

• który rekord jest produktem głównym,
• które rekordy są wariantami,
• jaki atrybut rozróżnia wariant,
• czy każdy wariant ma własne SKU,
• czy EAN jest przypisany do właściwego poziomu,
• czy wariant ma niezależny stan,
• czy marketplace rozpoznaje go tak samo jak system docelowy.

Przykład: koszulka może mieć produkt główny „Model X” i warianty rozmiarowe. Jeśli podczas migracji wszystkie warianty staną się osobnymi produktami, import technicznie może się udać, ale dalsze powiązania będą inne niż przed zmianą.

Zestawy są relacją, nie zwykłym produktem

Zestaw wymaga osobnego traktowania, bo jego poprawność zależy od składników.

Przy każdym zestawie sprawdzam:

• czy ma własne SKU,
• z jakich produktów się składa,
• w jakich ilościach,
• czy składniki są dostępne jako osobne rekordy,
• jak wyliczany jest stan zestawu,
• czy rezerwacja zestawu wpływa na składniki,
• jak zestaw jest prezentowany w kanałach sprzedaży.

Jeżeli nowy system liczy dostępność zestawu inaczej niż stary, sama migracja struktury produktu nie wystarczy. Trzeba przetestować zachowanie po zamówieniu.

To jest szczególnie ważne przed przełączeniem stanów i zamówień w Sellasist/WMS.

Usuń niejednoznaczności przed importem, nie po nim

Migracja nie powinna być pierwszym momentem, w którym odkrywasz, że dwa rekordy mają to samo SKU.

Przed właściwym importem tworzę raport problemów, na przykład:

• duplikat SKU,
• duplikat EAN,
• brak SKU,
• brak powiązania wariantu,
• zestaw z brakującym składnikiem,
• rekord bez kategorii wymaganej przez proces,
• produkt obecny w jednym systemie i brakujący w drugim.

Każdy problem powinien dostać decyzję: poprawiamy, ignorujemy świadomie albo mapujemy według jawnej reguły.

Nie zostawiam takich rekordów z założeniem „potem się poprawi”, bo później są już częścią zamówień i synchronizacji.

Przygotuj tabelę mapowania przed kodem

Zanim powstanie migrator, warto mieć prostą tabelę mappingu.

Przykładowe kolumny:

• source_id,
• source_sku,
• target_sku,
• source_ean,
• target_ean,
• product_type,
• parent_sku,
• bundle_components,
• action,
• validation_status.

Nie chodzi o konkretny format arkusza. Chodzi o to, żeby przed implementacją było wiadomo, co ma się wydarzyć z każdym typem rekordu.

Dzięki temu kod realizuje ustalone reguły zamiast podejmować decyzje „w locie”.

Nie migruj pełnego katalogu jako pierwszego testu

Dry-run powinien obejmować mały, ale zróżnicowany zestaw.

Wybrałbym między innymi:

• prosty produkt,
• wariant,
• produkt bez EAN,
• zestaw,
• rekord z kilkoma zdjęciami,
• produkt sprzedawany w kilku kanałach,
• rekord z nietypową historią zmian.

Po imporcie sprawdzam nie tylko, czy rekord istnieje.

Sprawdzam:

• identyfikatory,
• relacje,
• warianty,
• zestawy,
• pola wymagane przez dalszą synchronizację,
• widoczność w interfejsie,
• zachowanie po przykładowym zamówieniu.

Warstwę techniczną tej kontroli opisuję w HTTP 200 to nie dowód zapisu.

Po imporcie zrób read-back i porównanie

Najbezpieczniejszy scenariusz to taki, w którym migrator nie kończy pracy po zapisie.

Po każdej partii warto:

1. odczytać zapisane rekordy,
2. porównać kluczowe pola,
3. sprawdzić relacje,
4. zapisać różnice,
5. zatrzymać kolejną partię, jeśli odchylenie przekracza ustalone kryterium.

Nie trzeba sprawdzać każdego pola opisowego. Trzeba sprawdzać te, od których zależy proces.

Dla katalogu najczęściej będą to SKU, EAN, typ produktu, relacja wariantu i skład zestawu.

Nie kasuj starej mapy identyfikatorów po cutoverze

Po migracji często potrzebujesz przełożyć stary identyfikator na nowy.

Przydaje się to przy:

• analizie błędu,
• starym zamówieniu,
• zwrocie,
• porównaniu logów,
• ręcznej korekcie,
• integracji, która przez chwilę korzysta jeszcze ze starego ID.

Dlatego mapping source → target powinien być trwałym artefaktem migracji, a nie plikiem tymczasowym usuwanym po pierwszym sukcesie.

Katalog jest gotowy dopiero wtedy, gdy można na nim wykonać proces

Poprawna liczba produktów nie jest końcem walidacji.

Katalog jest gotowy, gdy można:

• odnaleźć produkt,
• rozpoznać właściwy wariant,
• policzyć stan,
• utworzyć zamówienie,
• zarezerwować właściwy rekord,
• obsłużyć zestaw,
• wysłać poprawne dane dalej.

Dlatego test katalogu kończę scenariuszem operacyjnym, nie tabelą z liczbą zaimportowanych wierszy.

Jeśli planujesz migrację katalogu jako część większej zmiany systemu, zacznij od zakresu migracji i zależności między systemami albo opisz problem w formularzu.