SKU czy EAN? Jak identyfikować produkty w integracjach e-commerce

SKU jest identyfikatorem operacyjnym

SKU powstaje wewnątrz firmy. Może kodować model, kolor, rozmiar, sezon albo kolejny numer. Najważniejsze, żeby było stabilne, unikalne w danym katalogu i nie zmieniało się bez procesu migracji.

SKU jest dobrym kluczem do aktualizacji stanów, cen i danych pomiędzy systemami tej samej organizacji, jeżeli wszystkie systemy rzeczywiście korzystają z tej samej wartości. Nie można zakładać tego bez sprawdzenia — ERP, sklep i BaseLinker mogą mieć różne pola nazwane „SKU”.

EAN identyfikuje jednostkę handlową

EAN jest używany w handlu, skanowaniu, marketplace i wymianie danych z partnerami. W katalogu wariantowym zwykle identyfikuje konkretny wariant, nie całą rodzinę produktu.

EAN może być dobrym kluczem do matchingu z hurtownią albo marketplace, ale tylko wtedy, gdy jest poprawny i unikalny. Brak EAN nie oznacza automatycznie, że produktu nie da się integrować. Produkty własne, usługi lub część katalogów B2B mogą działać wyłącznie na SKU.

Dlaczego nie należy wybierać jednego identyfikatora dla wszystkiego

Najbezpieczniejszy matching nie polega na szukaniu pierwszego podobnego kodu. Powinien mieć ustaloną kolejność i poziom pewności.

• wewnętrzny identyfikator rekordu systemu
• stabilne SKU firmy
• EAN jednostki handlowej
• identyfikator dostawcy
• mapa powiązań między systemami

Przykładowa hierarchia matchingu

Mapa identyfikatorów jest najpewniejsza, bo nie wymaga ponownego zgadywania przy każdym uruchomieniu. Po pierwszym poprawnym połączeniu rekordów integracja zapisuje relację i używa jej dalej.

• istniejąca mapa source_id → target_id
• zgodne i unikalne SKU
• zgodny i unikalny EAN
• ręczna kolejka dopasowania
• nigdy: automatyczne dopasowanie wyłącznie po nazwie

Typowe konflikty

Każdy z poniższych przypadków powinien trafić do raportu, nie do cichego automatycznego połączenia. Wykrywamy je w ramach audytu danych produktowych.

• jedno SKU występuje przy dwóch produktach
• jeden EAN przypisano do kilku rozmiarów
• ERP przechowuje SKU bez prefiksu, sklep z prefiksem
• BaseLinker ma własny numer katalogowy zamiast SKU producenta
• dostawca zmienił kod produktu
• stary produkt został skopiowany wraz z EAN
• arkusz usunął zera z początku EAN
• produkt główny i wariant mają ten sam identyfikator

Warianty wymagają identyfikatora na poziomie jednostki sprzedażowej

Koszulka w kolorze czarnym i rozmiarze M musi mieć identyfikator odróżniający ją od rozmiaru L. Wspólne SKU rodziny nie wystarczy do aktualizacji stanu wariantu.

Zmiana SKU jest migracją, nie zwykłą edycją

Jeżeli SKU pełni funkcję klucza integracji, jego zmiana może zerwać powiązania, utworzyć duplikat albo przestać aktualizować stary rekord. Dlatego zmiana SKU powinna tworzyć historię aliasów lub aktualizować mapę identyfikatorów.

• eksportuj mapę stary SKU → nowy SKU
• sprawdź zamówienia, magazyn i marketplace
• wykonaj migrację na kopii
• zablokuj równoległe aktualizacje
• zweryfikuj liczbę rekordów przed i po

Polityka identyfikatorów powinna być spisana

To krótki dokument, ale usuwa wiele problemów z importami, stanami i zamówieniami. Szersza architektura — kto rządzi którym polem między sklepem, ERP i BaseLinkerem — jest tematem poradnika o źródle prawdy.

• kto nadaje SKU i czy może się zmienić
• czy wielkość liter ma znaczenie
• czy SKU produktu i wariantu są oddzielne
• kiedy EAN jest obowiązkowy i jak obsłużyć jego brak
• jak wykrywać duplikaty
• gdzie przechowywana jest mapa identyfikatorów między systemami

Jaki identyfikator do jakiej operacji

Zamiast jednej reguły „zawsze SKU” albo „zawsze EAN” warto mieć tabelę decyzji dla konkretnych operacji.