API, ERP, PIM i DPPC – jak połączyć dane produktu

Dane produktu z ERP, PIM i DPPC łączy się tak, żeby każdy atrybut miał jednego właściciela, każdy produkt miał stabilny zestaw identyfikatorów, a dane płynęły w jednym kierunku: ERP tworzy produkt i odpowiada za dane handlowe, PIM go wzbogaca, DPPC publikuje dane i dokumenty w formie paszportu i karty produktu, a sklep lub platforma B2B pobiera gotowy komplet. API jest tu tylko transportem – o powodzeniu decyduje model danych, wersjonowanie i obieg dokumentów. Poniżej opisujemy, jak taki przepływ zaprojektować.

Problem: ten sam produkt w pięciu miejscach

Dane produktowe często żyją jednocześnie w ERP, PIM, sklepie, panelu B2B, arkuszach Excel i folderach z dokumentami. Każde z tych miejsc ma trochę inną nazwę, inną jednostkę i inną wersję karty technicznej. Bez integracji trudno ustalić, która wersja jest aktualna i kto odpowiada za zmianę.

Jeśli nie wiesz jeszcze, które systemy są w Twojej firmie potrzebne, zacznij od wpisu PIM, ERP i DPPC – kiedy potrzebujesz każdego systemu. Ten tekst zakłada, że systemy już są i trzeba je połączyć.

Przepływ docelowy krok po kroku

Typowy przepływ dla nowego produktu wygląda tak:

1. ERP – powstaje indeks produktu z nazwą roboczą, jednostką, grupą towarową, ceną bazową i statusem.
2. Zdarzenie „nowy produkt” trafia do PIM przez API lub kolejkę.
3. PIM – zespół produktowy uzupełnia atrybuty techniczne, opisy, zdjęcia, tłumaczenia i przypina dokumenty. Produkt dostaje status „gotowy do publikacji”.
4. DPPC – pobiera komplet danych wymaganych w paszporcie, łączy je z dokumentami zgodności, nadaje identyfikator paszportu i publiczny adres karty produktu.
5. Sklep lub platforma B2B – otrzymuje dane do prezentacji, ceny i stany z ERP oraz link do paszportu z DPPC.
6. Informacja zwrotna – każdy system odsyła status przyjęcia, a błędy wracają do właściciela danych.

Najważniejsza zasada: dane nie wracają „pod prąd”. Sklep nie poprawia opisu, który należy do PIM, a PIM nie zmienia ceny, która należy do ERP.

Master data per atrybut, nie per system

Zdanie „PIM jest źródłem prawdy dla produktów” jest zbyt ogólne. W praktyce właściciela ustala się dla każdego atrybutu lub grupy atrybutów. Przykładowa tabela odpowiedzialności:

• Indeks, nazwa systemowa, jednostka magazynowa, status handlowy – ERP.
• Cena bazowa, stany, termin dostępności – ERP.
• GTIN – ERP lub PIM, zależnie od tego, kto zarządza numeracją w firmie; ważne, żeby tylko jeden system.
• Parametry techniczne, opisy, zdjęcia, tłumaczenia – PIM.
• Skład materiałowy, informacje o zgodności, dane środowiskowe – PIM lub DPPC, zależnie od tego, kto je zbiera i zatwierdza.
• Dokumenty zgodności i identyfikator paszportu – DPPC.
• Ceny indywidualne, uprawnienia klientów, widoczność asortymentu – platforma B2B lub ERP.

Dla każdego wiersza warto zapisać także osobę odpowiedzialną za treść. Gdy pojawi się błąd, wiadomo, kto go poprawia i w którym systemie.

Identyfikatory: SKU, GTIN i ID paszportu

Stabilne identyfikatory to kręgosłup integracji. Zwykle potrzebne są co najmniej trzy:

• Indeks ERP (SKU) – wewnętrzny, istnieje dla każdego produktu, także takiego, który nie trafia do sprzedaży.
• GTIN – globalny numer nadawany w systemie GS1, używany w handlu i na opakowaniach. Nie każdy produkt B2B go ma.
• Identyfikator paszportu DPPC – powiązany z produktem, a w zależności od wymagań dla danej grupy produktów także z partią lub egzemplarzem.

Zasady, które oszczędzają kłopotów:

• Identyfikator raz nadany nie jest używany ponownie dla innego produktu.
• Zmiana indeksu w ERP nie może zerwać powiązań – każdy system przechowuje mapę identyfikatorów.
• Warianty (rozmiar, kolor, opakowanie) mają własne identyfikatory i wskazanie produktu nadrzędnego.
• Klucz integracji to identyfikator, a nie nazwa produktu.

Mapowanie pól i jednostek

Najwięcej pracy nie polega na napisaniu endpointu, ale na mapowaniu. Trzeba ustalić nazwy atrybutów, typy danych, jednostki, pola wymagane, słowniki wartości i relacje między produktami. „Waga” w ERP może oznaczać masę brutto w kilogramach, a w PIM masę netto w gramach. Bez słownika atrybutów integracja przeniesie chaos z jednego systemu do drugiego.

Przydatne jest zapisanie mapowania jako dokumentu, który mają obie strony: pole źródłowe, pole docelowe, typ, jednostka, przekształcenie, czy pole jest wymagane i co zrobić, gdy go brakuje.

Wersjonowanie danych

Dane produktu zmieniają się w czasie: nowy dostawca surowca, zmiana składu, nowa wersja instrukcji. Dla danych publikowanych w paszporcie produktu ważne jest, żeby dało się odtworzyć, co było prawdą w danym momencie.

Praktyczny model:

• Atrybuty dzielimy na wersjonowane (skład, parametry techniczne, dokumenty zgodności) i niewersjonowane (opisy marketingowe, zdjęcia poglądowe).
• Zmiana atrybutu wersjonowanego tworzy nową wersję danych produktu z datą obowiązywania.
• Poprzednie wersje pozostają dostępne do odczytu, zwłaszcza gdy produkty z wcześniejszych partii są już u klientów.
• API przekazuje numer wersji, a system docelowy odrzuca aktualizację starszą niż ta, którą już ma.

Dokumenty jako dane, nie załączniki

Deklaracje zgodności, karty charakterystyki, instrukcje i certyfikaty często krążą jako pliki bez metadanych. W zintegrowanym przepływie każdy dokument ma:

• typ dokumentu ze słownika,
• język,
• wersję i datę obowiązywania,
• powiązanie z produktem, wariantem lub partią,
• status (roboczy, zatwierdzony, wycofany),
• sumę kontrolną pliku, żeby wykryć podmianę.

Dzięki temu sklep może pokazać zawsze aktualną instrukcję w języku klienta, a DPPC – pełną historię dokumentów.

Transport: API, kolejki i statusy

Integracja produkcyjna musi obsługiwać błędy, limity, ponowienia i statusy synchronizacji. Każdy produkt ma w panelu widoczny stan: wysłany, przyjęty, odrzucony z powodem. Jak to zrealizować w Laravel, opisujemy w artykule Laravel API dla e-commerce B2B i PIM.

Bramka jakości przed publikacją

Między PIM a DPPC warto postawić automatyczną kontrolę kompletności. Dla każdej grupy produktów definiuje się listę pól wymaganych do publikacji: atrybuty, jednostki, tłumaczenia i typy dokumentów. Produkt, który jej nie spełnia, nie przechodzi dalej, a właściciel danych dostaje listę braków zamiast ogólnego komunikatu o błędzie. Ta sama reguła chroni sklep przed kartami bez zdjęć czy parametrów i ułatwia raportowanie, ile produktów w danej grupie jest gotowych do publikacji, a ile wymaga uzupełnienia.

Typowe błędy

• Ustalenie „źródła prawdy” dla całego produktu zamiast dla atrybutów.
• Łączenie rekordów po nazwie produktu.
• Brak wersji danych – nie wiadomo, co było opublikowane miesiąc temu.
• Dokumenty jako załączniki bez typu, języka i daty.
• Poprawianie danych w sklepie, bo „tak szybciej”.
• Brak informacji zwrotnej – system źródłowy nie wie, że rekord został odrzucony.
• Jednorazowy import „na start” bez planu dla późniejszych zmian.

Większość z tych błędów nie wynika z technologii, tylko z braku ustaleń między działami. Dlatego tabela właścicieli atrybutów i słownik pól są równie ważne jak kod integracji.

Następny krok

Zacznij od jednej grupy produktów i spisz dla niej tabelę atrybutów z właścicielem, jednostką i systemem źródłowym oraz listę identyfikatorów. To jeden warsztat z osobami z ERP, działu produktu i e-commerce. Jeśli chcesz przejść go z nami, zobacz, jak pracujemy przy DPPC i danych produktowych, albo napisz do nas.