Jak zintegrować Cyfrowy Paszport Produktu (DPP) z systemem ERP i usprawnić zarządzanie danymi?

W projekcie trzeba połączyć kilka elementów: kartotekę produktu w ERP, informacje z pozostałych źródeł, właściwą wersję paszportu i identyfikator umieszczony na produkcie. Rejestr DPP przechowuje identyfikatory, dane rejestracyjne i określone metadane, a szczegółowe informacje produktowe pozostają w systemach podmiotu odpowiedzialnego lub dostawcy usługi DPP.

Cyfrowy Paszport Produktu (Digital Product Passport, DPP) zapewnia dostęp do informacji o produkcie w zakresie określonym dla danej grupy produktów.

PIM (System zarządzania informacją o produkcie) pomaga połączyć dane z różnych źródeł, uzupełnić atrybuty i przygotować informacje do publikacji w paszporcie oraz kanałach sprzedaży.

Architektura integracji: Dlaczego ERP potrzebuje bufora (PIM) do obsługi DPP?

Przy projektowaniu integracji warto ustalić, za które dane odpowiada każdy z systemów. W proponowanej architekturze ERP pozostaje systemem referencyjnym (System of Record) dla przypisanych mu informacji operacyjnych: zakupów, transakcji, dostawców, zleceń i ewidencji partii. W organizacji produkcyjnej może również przechowywać produkcyjne zestawienie komponentów, czyli BOM. Dokumentacja konstrukcyjna i jej wersje mogą pochodzić z PLM, a dane o rzeczywistym wykonaniu produktu z systemu obsługującego produkcję.

PIM łączy dane operacyjne z opisami materiałów, instrukcjami, dokumentacją, treściami w różnych językach i zatwierdzonymi wynikami analiz środowiskowych. Pozwala przygotować spójny zestaw informacji o produkcie gotowy do publikacji. Więcej o tym podziale odpowiedzialności piszemy w artykule wyjaśniającym, dlaczego ERP nie zastąpi systemu PIM.

Bufor oznacza tutaj warstwę przygotowania i kontroli informacji produktowej. Transport danych, kolejki komunikatów i ponawianie nieudanych operacji należą do warstwy integracyjnej. W PIM definiuje się atrybuty i powiązania między danymi, sprawdza ich kompletność oraz zatwierdza informacje do publikacji. Zakres tych funkcji zależy od wybranego rozwiązania i jego konfiguracji. Przykładowo Pimcore udostępnia narzędzia do importu, mapowania i przekształcania danych oraz kontrolowania ich publikacji.

Docelowy przepływ może wyglądać następująco:

ERP + PLM + dane dostawców + dokumentacja i wyniki LCA → warstwa integracyjna → PIM → usługa DPP

Dalej następują dwa powiązane działania:

Usługa DPP → rejestr UE: identyfikatory i wymagane dane rejestracyjne

Produkt lub opakowanie → nośnik danych, np. kod QR → właściwy paszport

W takim modelu klient odczytuje zatwierdzone informacje z usługi DPP. Obsługa skanowania kodów i udostępniania dokumentacji pozostaje oddzielona od bieżącej pracy ERP.

Decyzja o zastosowaniu PIM zależy od zakresu projektu. Przy niewielkim katalogu i prostych wymaganiach część zadań związanych ze zbieraniem i sprawdzaniem danych może wykonywać sama aplikacja DPP. Rozbudowany system PIM jest szczególnie przydatny, gdy trzeba łączyć informacje z wielu źródeł oraz obsługiwać różne rynki, wersje językowe i kanały publikacji.

Punktem odniesienia dla zgodności produktowej, czyli EU compliance, jest ESPR: Rozporządzenie w sprawie ekoprojektu dla zrównoważonych produktów. Rozwija ono unijne zasady ekoprojektu, określane także jako EU Ecodesign, których wcześniejszą podstawą była dyrektywa unijna 2009/125/WE. Wymagania dla poszczególnych grup produktów są konkretyzowane w odpowiednich aktach delegowanych.

Co trafia z systemu ERP do Cyfrowego Paszportu Produktu? Mapowanie danych

Mapowanie określa, jak pole z systemu źródłowego zostanie wykorzystane w docelowym modelu informacji. Powinno obejmować jego znaczenie, jednostkę, źródło, powiązanie z produktem i reguły aktualizacji.

ERP dostarcza część informacji potrzebnych do przygotowania DPP. Zakres publikacji wynika z właściwego aktu delegowanego lub regulacji sektorowej. Przepisy mogą również określić, czy paszport odnosi się do modelu, partii czy pojedynczego egzemplarza.

Poniższa tabela przedstawia przykład mapowania danych z ERP do modelu PIM/DPP. Poszczególne pozycje trzeba dopasować do rzeczywistych danych firmy oraz wymagań dotyczących jej produktów.

Dane podstawowe i identyfikatory (SKU, GTIN, dane producenta)

Integrację warto oprzeć na trwałych identyfikatorach. Nazwa produktu może zmienić się wraz z aktualizacją oferty, tłumaczeniem lub przyjętą konwencją nazewnictwa. Klucz łączący rekordy powinien zachowywać jednoznaczne powiązanie między systemami.

W firmie korzystającej z kilku baz ERP ten sam SKU może wymagać dodatkowego kontekstu, np. identyfikatora spółki lub systemu źródłowego. Dlatego w mapowaniu należy rozróżnić wewnętrzny klucz kartoteki, identyfikator produktu używany w łańcuchu dostaw i identyfikator rejestracji paszportu.

W mapowaniu danych producenta warto uwzględnić nazwę podmiotu, adres i wymagane dane kontaktowe oraz powiązać je z odpowiednimi produktami. Trzeba też ustalić, czy kartoteka kontrahenta w ERP opisuje producenta, dostawcę czy importera, ponieważ te role wymagają odrębnego oznaczenia.

GS1 Digital Link pozwala zapisać identyfikatory GS1, m.in. GTIN, w postaci umożliwiającej połączenie produktu z informacją online. Kod QR jest nośnikiem, a GS1 Digital Link określa sposób zapisania identyfikatora w adresie internetowym.

Zestawienie komponentów (BOM) i skład surowcowy

BOM pokazuje, jakie komponenty i w jakich ilościach składają się na produkt. Przy przygotowaniu DPP trzeba ustalić, czy wykorzystujemy strukturę konstrukcyjną, produkcyjną czy zapis komponentów rzeczywiście użytych w danej partii.

W mapowaniu należy połączyć kod komponentu z jego opisem materiałowym i dokumentacją. Przykładowo oznaczenie MAT-017 może wskazywać konkretny rodzaj tworzywa. Informacje o udziale recyklatu lub właściwościach środowiskowych wymagają dodatkowego, potwierdzonego źródła.

Warto też zdefiniować przeliczniki jednostek. Zapis masy w gramach można przeliczyć na kilogramy według ustalonej reguły. Wyliczenie udziału materiału w gotowym produkcie wymaga określenia podstawy obliczenia, zakresu komponentów i sposobu uwzględnienia opakowania w obliczeniach.

Wyniki LCA i ślad węglowy produktu powinny pochodzić z odpowiedniej analizy lub zweryfikowanego źródła. PIM może powiązać je z właściwą wersją produktu. Szerzej opisujemy ten obszar w artykule o tym, jak przebiega integracja danych LCA z systemem PIM.

Dane produkcyjne i logistyczne (partie, numery seryjne, zakłady)

Przy paszportach na poziomie partii lub egzemplarza szczególnie ważne jest powiązanie danych z momentem produkcji. System powinien zachować informację, która wersja komponentów, materiałów i dokumentów dotyczyła konkretnego wyrobu.

Przykładowo po zmianie dostawcy kolejna partia może mieć ten sam kod handlowy, ale inne dane materiałowe. Integrację należy zaprojektować tak, aby nowy rekord nie nadpisywał informacji dotyczących wcześniejszej produkcji.

Przy dużej liczbie egzemplarzy warto pozostawić szczegółową ewidencję produkcyjną w systemie, który ją obsługuje. PIM i usługa DPP mogą przechowywać potrzebne powiązania oraz zatwierdzony zakres danych przeznaczony do publikacji.

Dokumenty i certyfikaty dostawców

Dokument zakupowy pomaga wskazać dostawcę i konkretną dostawę. Do potwierdzenia właściwości materiału potrzebne mogą być odrębne certyfikaty, deklaracje lub raporty.

W modelu danych warto więc uwzględnić rodzaj dokumentu, wystawcę, wersję, okres ważności i produkty lub materiały, których dotyczy. Sam plik może pozostawać w repozytorium dokumentów lub DAM, a PIM przechowywać jego opis i powiązania.

Równie ważne jest rozróżnienie kraju dostawcy, kraju wysyłki i kraju pochodzenia materiału. Każde z tych pól ma inne znaczenie i powinno być mapowane oddzielnie. Sposób pozyskiwania brakujących informacji omawiamy w artykule o tym, dlaczego dane od dostawców blokują gotowość do DPP.

Wzorce synchronizacji: Integracja w czasie rzeczywistym (API) vs. procesy wsadowe (Batch)

Wybór sposobu synchronizacji obejmuje dwie decyzje: jak przesyłamy dane i kiedy uruchamiamy ich przetwarzanie. API może obsługiwać zarówno pojedyncze zmiany, jak i duże porcje danych pobierane według harmonogramu. Integracja wsadowa może korzystać z plików albo z API.

Takie rozróżnienie widać również w dokumentacji narzędzi: enova365 łączy WebAPI z harmonogramem zadań, a Pimcore umożliwia uruchamianie importów ręcznie, cyklicznie lub po dostarczeniu danych do odpowiedniego interfejsu.

REST API udostępnia operacje i zasoby systemu zewnętrznym aplikacjom. GraphQL API pozwala określić zakres pobieranych pól, co może być przydatne po stronie PIM. Przykładowo Pimcore Datahub udostępnia interfejs GraphQL i pozwala ograniczać dane dostępne w poszczególnych konfiguracjach.

W większych środowiskach występują również interfejsy OData. W integracjach SAP spotyka się ponadto IDoc i BAPI. Dostępność tych mechanizmów zależy od produktu, wersji i modelu wdrożenia; dokumentacja SAP rozróżnia interfejsy dostępne w rozwiązaniach lokalnych i chmurowych.

Przy wymianie plikowej Excel może służyć do przygotowania i kontroli danych, a CSV lub XML do ich przekazywania. W projekcie warto z góry ustalić nazwy kolumn, kodowanie znaków, format dat, separator dziesiętny i sposób zapisu identyfikatorów. GTIN powinien zachować wszystkie cyfry, także początkowe zera.

Osobną kwestią jest format publikowanego paszportu. JSON-LD umożliwia powiązanie pól z jednoznacznie zdefiniowanymi pojęciami i identyfikatorami. Może wspierać interoperacyjność danych, jeśli przyjęty model DPP wykorzystuje ten format. Ostateczny format i słowniki trzeba dopasować do właściwych wymagań oraz specyfikacji usługi publikacyjnej.

Praktycznym rozwiązaniem jest często model mieszany: podstawowe dane produktu trafiają do PIM cyklicznie, nowa partia uruchamia aktualizację po zatwierdzeniu produkcji, a dokument środowiskowy zostaje opublikowany po akceptacji osoby odpowiedzialnej za jego treść.

Jak zintegrować DPP z ERP w 5 krokach

Krok 1: Audyt i mapowanie luk w danych

Pierwszym zadaniem jest wskazanie produktów objętych projektem, ich źródeł danych oraz obowiązujących lub przygotowywanych wymagań. Warto zacząć od jednej rodziny produktowej, która obejmuje typowe dla firmy warianty, dokumenty i procesy.

Dla każdego atrybutu należy ustalić system źródłowy, właściciela, sposób pobrania i wymaganą częstotliwość aktualizacji. Podczas audytu należy również sprawdzić, czy dostępne informacje rzeczywiście opisują produkt na potrzebnym poziomie: modelu, partii lub egzemplarza.

Rezultatem audytu powinna być mapa danych wskazująca brakujące informacje oraz osoby odpowiedzialne za ich uzupełnienie. Jeżeli pole „materiał” w ERP zawiera wewnętrzny kod, podczas integracji należy powiązać go ze słownikiem materiałów i dokumentacją.

Już na tym etapie należy przetestować eksport lub odczyt reprezentatywnego zestawu danych z używanej wersji ERP. Pozwala to wykryć ograniczenia interfejsu przed rozpoczęciem właściwego wdrożenia.

Krok 2: Wprowadzenie PIM jako warstwy czyszczącej i harmonizującej

Kolejny krok obejmuje zaprojektowanie modelu produktu, materiałów, dokumentów oraz ich powiązań. Do tego dochodzą słowniki, przeliczniki jednostek i zasady rozstrzygania rozbieżności między źródłami.

W proponowanym procesie rekord przechodzi przez kolejne stany:

Dane odebrane → sprawdzone → uzupełnione → zatwierdzone → gotowe do publikacji

Automatyczne kontrole mogą wykrywać brak jednostki, nieznany kod materiału, niepowiązaną partię lub wygasający dokument. Zadanie uzupełnienia brakującej informacji trafia do osoby odpowiedzialnej za dane.

Narzędzia importu PIM mogą ograniczyć zakres ręcznej pracy. Pimcore Data Importer obsługuje m.in. CSV, JSON, XML i XLSX, konfigurowalne mapowanie oraz podgląd przekształcanych danych. Funkcje te wymagają przygotowania reguł odpowiadających rzeczywistemu modelowi produktu.

Krok 3: Wybór metody połączenia (API / ESB / iPaaS)

Sposób połączenia warto dobrać do liczby systemów, dostępnych interfejsów i wymagań dotyczących aktualności danych.

Przy niewielkiej liczbie połączeń można rozważyć dedykowany moduł integracyjny. W rozbudowanej organizacji rolę pośrednika może pełnić ESB, czyli szyna integracyjna, lub iPaaS, czyli platforma integracyjna dostępna jako usługa. W projekcie należy przypisać tej warstwie konkretne zadania: przekazywanie komunikatów, przekształcanie formatów, rejestrowanie błędów i ponawianie przesyłania danych.

Instalacja modułu integracyjnego powinna obejmować testy jego działania po przerwaniu połączenia, ponownym przesłaniu tego samego rekordu lub otrzymaniu starszej wersji danych.

Dostosowanie integracji powinno obejmować zabezpieczenie przed duplikatami, kontrolę wersji, minimalne uprawnienia kont technicznych i wskazanie osób odpowiedzialnych za obsługę błędów. Potwierdzenie odczytu z ERP, zatwierdzenie w PIM i publikacja DPP powinny być rejestrowane jako odrębne etapy.

Zakres tych prac wpływa na budżet projektu. Zakres tych prac wpływa na budżet projektu. Szczegółowy podział kosztów wdrożenia DPP przedstawiamy w osobnym artykule.  

Krok 4: Powiązanie partii i egzemplarzy z GS1 Digital Link

Poziom identyfikacji należy ustalić na podstawie wymagań właściwych dla produktu. Serializacja, czyli nadawanie identyfikatora każdemu egzemplarzowi, jest potrzebna przy obsłudze paszportów jednostkowych. Przy paszportach na poziomie partii kluczowe jest prawidłowe powiązanie produktu z numerem partii.

W standardzie GS1 identyfikator GTIN może zostać uzupełniony numerem partii lub numerem seryjnym. Przykładowy adres zgodny ze strukturą GS1 Digital Link dla partii może wyglądać następująco:

https://id.example.com/01/09521234000006/10/B2026-001

W tym przykładzie 01 oznacza GTIN, a 10 numer partii. Dla numeru seryjnego stosuje się identyfikator zastosowania 21.

Projekt powinien określić, który system nadaje identyfikator, kiedy zostaje on powiązany z produktem i jak trafia do drukarki etykiet. Może to nastąpić na linii produkcyjnej, podczas pakowania albo w innym kontrolowanym etapie procesu.

Należy również przetestować skanowanie gotowego oznaczenia. Kod powinien prowadzić do właściwego paszportu, a po zmianie dokumentacji zachowywać powiązanie z odpowiednią partią. Wybór nośnika, jego umiejscowienie i wymagany poziom identyfikacji wynikają z właściwych przepisów.

Krok 5: Weryfikacja podmiotu, publikacja i rejestracja DPP

Rejestr DPP wraz ze środowiskiem testowym został uruchomiony przez Komisję Europejską 20 lipca 2026 roku. Rejestracja jest dostępna przez interfejs użytkownika oraz API, co umożliwia jej włączenie w firmowy proces publikacji.

Na tym etapie trzeba zapewnić organizacji dostęp do rejestru i nadać odpowiednie uprawnienia osobom oraz usługom działającym w jej imieniu. Rozporządzenie wykonawcze (UE) 2026/1778 przewiduje weryfikację tożsamości podmiotów z wykorzystaniem określonych środków, powiązanych m.in. z eIDAS. W przypadku osoby prawnej, która zgodnie z przepisami musi mieć siedzibę w UE, przewidziano np. kwalifikowaną pieczęć elektroniczną albo kwalifikowane elektroniczne poświadczenie atrybutów. Sposób weryfikacji zależy od rodzaju podmiotu.

Następnie usługa DPP udostępnia zatwierdzony paszport i przekazuje wymagane informacje do rejestracji. Rejestr sprawdza m.in. zgodność semantyczną danych oraz właściwy poziom identyfikacji, a po pomyślnym zakończeniu weryfikacji zwraca identyfikator rejestracji.

W integracji warto zapisać osobno status publikacji paszportu i status jego rejestracji. W razie odrzucenia rejestracji należy ustalić przyczynę błędu i ją usunąć. Proces musi też uwzględniać kopię zapasową oraz utrzymanie dostępności paszportu przez wymagany okres. ESPR przewiduje obowiązki w obu tych obszarach.

Integracja z polskimi systemami ERP: Comarch, enova365, Symfonia, InsERT i Asseco

Integracja DPP z systemami ERP jest możliwa w wielu środowiskach, które udostępniają potrzebne dane przez wspierane interfejsy lub eksporty. O wykonalności decyduje jednak konkretny zakres: dostęp do identyfikatorów, komponentów, partii, dokumentów i zmian zachodzących w czasie.

Poniższe systemy pokazują różne sposoby integracji dostępne na polskim rynku. Dokumentacja producentów potwierdza mechanizmy wymiany danych; gotowość konkretnego wdrożenia do obsługi DPP trzeba sprawdzić na rzeczywistej konfiguracji.

W przypadku Comarch ERP Optima dokumentacja eksportu cennika opisuje możliwość eksportu kartotek towarowych, danych producentów i marek oraz receptur towarów złożonych przy odpowiednich modułach i ustawieniach. To konkretna podstawa do przygotowania mapowania danych produktowych.

Dla Comarch ERP Altum producent dokumentuje wykorzystanie modułu API przy współpracy z Comarch BPM. Ten przykład potwierdza istnienie mechanizmu integracji, natomiast połączenie z PIM/DPP wymaga określenia odrębnego zakresu i sposobu dostępu.

enova365 udostępnia WebAPI umożliwiające komunikację z aplikacjami zewnętrznymi. Dokumentacja opisuje również harmonogram zadań, co pozwala rozważyć zarówno obsługę żądań przez API, jak i cykliczną wymianę danych.

W systemie Symfonia ERP ważne jest dopasowanie WebAPI do konkretnego programu oraz licencji. Dokumentacja rozróżnia m.in. WebAPI Handel i WebAPI Finanse i Księgowość, a zgodność wersji stanowi osobny warunek działania integracji.

W Subiekcie GT punktem integracji może być Sfera dla InsERT GT, udostępniająca obiekty i mechanizmy programu. Producent wskazuje technologie COM i OLE Automation oraz odrębne zasady licencjonowania. Projekt powinien uwzględnić środowisko uruchomienia tego połączenia.

Asseco ERP obejmuje kilka linii produktowych. Asseco opisuje otwarte API i rozwiązania integracyjne, ale dostęp do konkretnej kartoteki, dokumentu czy partii należy potwierdzić dla Softlab, Merit lub Wapro używanego przez klienta.

W praktyce określenie „wdrożenie DPP w systemie ERP” oznacza więc dostosowanie istniejącego środowiska do przekazywania danych, identyfikatorów i statusów wykorzystywanych przy obsłudze paszportu. Po przygotowaniu eksportu danych odbiór integracji powinien potwierdzić poprawność powiązań, aktualizacji i obsługi błędów.

Korzyści operacyjne: Jak integracja z DPP podnosi jakość danych w całej firmie

Łączenie DPP z systemami ERP warto wykorzystać do uporządkowania zasad pracy z informacją produktową. Efekty integracji warto mierzyć na podstawie codziennej pracy z danymi.

Po zmianie dokumentu zespół powinien wiedzieć, których produktów on dotyczy. Po wykryciu błędu powinno być jasne, w którym systemie trzeba poprawić dane i kto za to odpowiada. Zatwierdzona zmiana powinna trafiać do właściwych odbiorców bez ponownego ręcznego przygotowywania tych samych danych.

Do oceny działania integracji można wykorzystać następujące mierniki:

Dane przygotowane na potrzeby DPP w systemach ERP i PIM mogą służyć również e-commerce, katalogom B2B i obsłudze serwisowej. Każdy kanał otrzymuje właściwy zakres danych z kontrolowanego procesu publikacji.

Jak Tandemite pomaga połączyć ERP, PIM i DPP w spójny ekosystem?

Tandemite wspiera porządkowanie danych produktowych, projektowanie modeli PIM i integrację systemów. W ramach audytu Product Data X-Ray analizuje m.in. kompletność informacji, źródła danych, identyfikowalność, dokumentację oraz gotowość do publikacji DPP.

Projekt ERP-PIM-DPP warto rozpocząć od oceny używanych systemów i prześledzenia typowego dla firmy procesu: od kartoteki produktu lub danych o partii w ERP do zatwierdzonego paszportu. Na tej podstawie można określić zakres integracji, potrzebne zmiany w PIM oraz zasady późniejszej aktualizacji i kontroli danych.

Przed rozpoczęciem prac warto sprawdzić, jak wybrać partnera IT do wdrożenia systemu PIM, zwracając uwagę na doświadczenie w modelowaniu informacji i łączeniu systemów źródłowych.

Skorzystaj z bezpłatnej konsultacji z Tandemite, aby omówić integrację DPP z systemem ERP oraz zakres audytu danych.