Dlaczego integracja DPP jest ważniejsza niż kolejna baza produktowa?
Firma może posiadać tysiące indeksów produktowych, wiele zakładów, wersji materiałowych i procesów. Jeśli przy każdej zmianie pracownik ma ręcznie poprawiać DPP, prędzej czy później powstanie różnica między paszportem a systemem źródłowym.
Dlatego dobrze zaprojektowany system DPP powinien rozróżniać:
System źródłowy
Miejsce, w którym dana rzeczywiście powstaje i jest utrzymywana – np. ERP, MES, PLM albo system jakości.
Warstwę integracyjną
Odpowiada za pobieranie, transformację, kontrolę i przekazanie danych do właściwego modelu DPP.
Warstwę DPP
Łączy wymagany model danych, identyfikatory, prawa dostępu, prezentację, historię i procesy rejestracyjne.
Najważniejsza zasada: DPP nie powinien tworzyć drugiego „źródła prawdy” obok ERP czy PLM. Powinien wiedzieć, skąd pobrać właściwą informację i jak ją przekształcić do wymaganej struktury.
Przykładowa architektura integracji DPP z systemami przedsiębiorstwa
Nie istnieje jeden techniczny schemat właściwy dla każdej organizacji. Architektura zależy od liczby systemów, wolumenu produktów, rodzaju danych, aktualizacji, ról użytkowników oraz konkretnego aktu regulacyjnego.
Warstwa DPP może w takim modelu pełnić funkcję orkiestratora: ustalać, skąd pobrać dane, mapować je do wspólnej struktury, przechowywać elementy wymagające własnego lifecycle, kontrolować uprawnienia i udostępniać paszport przez odpowiedni data carrier.
Dla przedsiębiorstwa oznacza to możliwość zachowania systemów, które już działają. Szczegółowy projekt powstaje dopiero po audycie danych i procesów.
Jaką rolę w DPP pełnią ERP, SAP, MES, PIM i PLM?
Te systemy nie są zamienne. Każdy może być właścicielem innego fragmentu informacji potrzebnych do Cyfrowego Paszportu Produktu.
| System | Typowe dane przydatne dla DPP | Przykładowa rola integracji |
|---|---|---|
| ERP / SAP | Indeksy, modele, dostawcy, partie, zakłady, kody produktowe, część danych materiałowych i handlowych. | Master / transactional data |
| MES | Partie produkcyjne, serie, procesy, parametry produkcji, genealogia produktu, powiązanie komponentów. | Production / item data |
| PIM | Opisy, parametry handlowe, dokumenty, multimedia, informacje udostępniane kanałom sprzedaży. | Product information |
| PLM | BOM, specyfikacje, wersje, materiały, dokumentacja konstrukcyjna, zmiany produktu. | Engineering / lifecycle |
| QMS / compliance | Deklaracje, certyfikaty, wyniki badań, dokumentacja zgodności i jakości. | Compliance data |
| Traceability | Genealogia, komponenty, partie, numery seryjne, zdarzenia i historia pochodzenia. | Identification / lifecycle |
| Serwis / CRM / FSM | Naprawy, wymiany części, status produktu, historia serwisowa – jeśli właściwe przepisy wymagają takich danych. | Lifecycle updates |
Nie wszystkie firmy mają wszystkie systemy. Integracja DPP nie polega na kupieniu ERP, PIM i PLM „pod paszport”. Projekt powinien wykorzystać rzeczywistą architekturę przedsiębiorstwa i uzupełnić tylko brakujące elementy.
API w Cyfrowym Paszporcie Produktu – gdzie naprawdę jest potrzebne?
DPP API nie jest jednym uniwersalnym interfejsem. W praktyce może oznaczać kilka różnych połączeń:
API systemów źródłowych
Pobieranie danych z ERP, SAP, MES, PIM, PLM lub systemów dostawców.
API warstwy DPP
Udostępnianie danych innym aplikacjom, portalom, systemom serwisowym i rozwiązaniom mobilnym.
API Registry
Automatyzacja rejestracji paszportów i odbierania informacji zwrotnych z unijnego DPP Registry.
API partnerów
Pobieranie wymaganych danych od dostawców lub udostępnianie informacji klientom B2B i innym uczestnikom łańcucha.
ESPR wymaga, aby dane DPP opierały się na otwartych standardach i – odpowiednio – były maszynowo odczytywalne, ustrukturyzowane, przeszukiwalne i przenoszalne za pomocą interoperacyjnej sieci wymiany danych bez vendor lock-in.
Komisja informuje również, że w ekosystemie DPP powstały standardy obejmujące m.in. API, protokoły wymiany danych, unikalne identyfikatory, data carriers, interoperacyjność i przechowywanie danych.
Najtrudniejsza część integracji DPP: mapowanie danych, nie samo połączenie API
Techniczne pobranie wartości z SAP albo MES jest dopiero początkiem. Trzeba jeszcze ustalić, czy dana odpowiada definicji wymaganej przez właściwy akt, ma poprawną jednostkę, format, słownik wartości, granularność i właściciela.
Wymagany element DPP
Zaczynamy od modelu danych właściwego dla kategorii produktu, a nie od listy pól istniejącej w ERP.
Źródło prawdy
Wskazujemy system, proces lub właściciela, który odpowiada za aktualną i poprawną wartość.
Transformacja
Mapujemy format, jednostki, słowniki, identyfikatory i relacje do struktury wymaganej przez DPP.
Walidacja
Sprawdzamy obecność danych, typ wartości, kompletność, zależności i poprawność przed publikacją lub rejestracją.
Aktualizacja
Ustalamy, co ma wyzwalać aktualizację DPP: zmiana modelu, partii, dokumentacji, serwisu, statusu produktu lub innego zdarzenia.
DPP Registry wykorzystuje również semantic repository zawierające maszynowo odczytywalne modele danych, definicje i słowniki. To zwiększa znaczenie poprawnego mapowania semantycznego.
Więcej o przygotowaniu informacji: Jakie dane są potrzebne do Cyfrowego Paszportu Produktu?.
Integracja DPP na poziomie modelu, partii i pojedynczego produktu
ESPR przewiduje, że konkretny akt produktowy określi, czy DPP odnosi się do modelu, partii czy pojedynczego egzemplarza. Ta decyzja radykalnie zmienia architekturę integracji.
| Poziom | Charakter danych | Typowe źródła | Wymagania integracyjne |
|---|---|---|---|
| Model | Dane wspólne dla rodziny / wersji produktu. | ERP, PIM, PLM, compliance. | Stosunkowo mała liczba obiektów, ale ważne wersjonowanie. |
| Partia | Dane związane z konkretną produkcją lub dostawą. | ERP, MES, WMS, traceability. | Potrzeba relacji model–partia i niezawodnych identyfikatorów partii. |
| Item / sztuka | Dane konkretnego egzemplarza i jego historii. | MES, serializacja, traceability, IoT/BMS, serwis. | Wysoki wolumen, automatyzacja, obsługa lifecycle i identyfikatorów jednostkowych. |
Im bardziej szczegółowy poziom, tym większe znaczenie ma automatyczna identyfikowalność i integracja zdarzeniowa.
Traceability i MES jako źródło danych o historii produktu
Jeśli DPP wymaga danych dotyczących konkretnej partii albo sztuki, samo ERP często nie wystarczy. Potrzebna może być historia produkcyjna: które komponenty wykorzystano, kiedy i gdzie powstał produkt, z jakiej partii materiału pochodził element i jakie zdarzenia dotyczyły konkretnego egzemplarza.
Właśnie tutaj system traceability i MES mogą dostarczać relacje niezbędne do zbudowania paszportu na odpowiedniej granularności.
Genealogia produktu
Powiązanie wyrobu z komponentami, surowcami, partiami i procesem produkcyjnym.
Zdarzenia lifecycle
Produkcja, kontrola, naprawa, wymiana, remanufacturing lub inne zdarzenia – jeśli mają znaczenie dla konkretnego DPP.
Zobacz szczegółowo: Traceability a DPP – identyfikowalność produktu i produkcji.
Integracja z DPP Registry przez API
DPP Registry działa od 20 lipca 2026 r. Komisja przewiduje możliwość rejestracji paszportów zarówno przez secure user interface, jak i application programming interface (API).
Dla organizacji zarządzającej dużą liczbą paszportów API pozwala zaprojektować automatyczny proces:
Registry sam nie przechowuje pełnego paszportu. System firmy nadal musi zapewniać dostępność właściwych danych DPP, natomiast Registry obsługuje unijny poziom rejestracji, identyfikatorów i wymaganych metadanych.
Ważne: architektura InviNets może zostać przygotowana do współpracy z aktualnym API i wymaganiami Registry. Nie oznacza to deklaracji, że każda istniejąca instalacja InviNets jest już produkcyjnie połączona z unijnym Registry.
Integracja DPP musi obsługiwać różne role, nie tylko publiczny QR
ESPR przewiduje różne prawa dostępu dla klientów, producentów, importerów, dystrybutorów, serwisów, podmiotów naprawczych, remanufacturerów, recyklerów, organów nadzoru rynku, celnych i innych uczestników.
Oznacza to, że integracja powinna potrafić rozdzielić dane na:
- informacje publiczne dostępne po zeskanowaniu data carrier,
- dane dostępne po uwierzytelnieniu użytkownika lub organizacji,
- dane udostępniane konkretnym rolom zgodnie z aktem produktowym,
- dane, których system DPP w ogóle nie powinien kopiować do warstwy publicznej.
W praktyce oznacza to potrzebę kontroli dostępu, logowania, wersjonowania i odpowiedzialności za źródła informacji.
Jak wygląda projekt integracji DPP krok po kroku?
Ustalenie wymagań dla produktu
Najpierw określamy właściwy akt, dane DPP, granularność, role dostępu i harmonogram. Bez tego nie wiadomo, co tak naprawdę ma być integrowane.
Mapa systemów i właścicieli danych
Tworzymy inventory ERP, SAP, MES, PIM, PLM, QMS, traceability, serwisu, plików, baz i zewnętrznych źródeł.
Macierz DPP → źródło
Każdy wymagany element łączymy z konkretnym źródłem prawdy, regułą transformacji i częstotliwością aktualizacji.
Projekt architektury
Dobieramy API, komunikację zdarzeniową, import, ETL lub inne mechanizmy adekwatne do wolumenu i charakteru danych.
Warstwa DPP
Budujemy model danych, identyfikację, dostęp, walidację, prezentację i historię potrzebną dla konkretnego produktu.
Registry i data carrier
Jeżeli właściwe przepisy tego wymagają, przygotowujemy proces rejestracyjny oraz powiązanie produktu z paszportem poprzez wymagany identyfikator i nośnik danych.
Pilot i obserwowalność
Testujemy ograniczony zakres, sprawdzamy logi, błędy, brakujące dane i czas propagacji aktualizacji.
Skalowanie
Rozszerzamy rozwiązanie na kolejne modele, partie, produkty, zakłady i systemy bez ręcznego odtwarzania całej architektury.
Najczęstsze błędy przy integracji Cyfrowego Paszportu Produktu
Ręczne przepisywanie danych
Tworzy drugie źródło informacji i zwiększa ryzyko rozbieżności z ERP, PLM lub MES.
„QR najpierw, dane później”
Nośnik jest ostatnim elementem dostępu, a nie początkiem architektury. Najpierw trzeba wiedzieć, jakie dane i identyfikatory obsługujemy.
Jedna tabela dla wszystkich produktów
Różne akty produktowe mogą wymagać innych danych, granularności i praw dostępu.
Zamknięty format
ESPR stawia na otwarte standardy, interoperacyjność i wymianę danych bez vendor lock-in.
Brak właścicieli danych
API nie rozwiąże problemu, jeśli organizacja nie wie, który system odpowiada za właściwą wartość.
Brak wersjonowania i logów
Przy aktualizacjach DPP trzeba wiedzieć, kiedy i dlaczego zmieniła się dana oraz jak wpłynęło to na paszport.
Nie dostosowuj firmy do sztywnej platformy DPP
InviNets może zaprojektować rozwiązanie wokół istniejących systemów, procesów i źródeł danych. Zaczynamy od architektury przedsiębiorstwa, a nie od założenia, że wszystko trzeba przenieść do jednej nowej aplikacji.
- audyt ERP / SAP / MES / PIM / PLM i źródeł danych,
- mapowanie wymagań DPP do systemów,
- projekt API i przepływów integracyjnych,
- identyfikacja modelu, partii i sztuki,
- warstwa dostępu i QR / data carrier,
- przygotowanie integracji z DPP Registry, gdy jest wymagana.
Powiązane przewodniki InviNets
- Cyfrowy Paszport Produktu (DPP) – główny pillar
- Wdrożenie DPP – system dla firm
- Harmonogram DPP – terminy i branże
- ESPR i DPP – przepisy i akty delegowane
- Cyfrowy Paszport Baterii – wymagania 2027
- DPP Registry – rejestracja i API
- Jakie dane są potrzebne do DPP?
- Traceability a DPP – identyfikowalność produktu
- Kto odpowiada za DPP? Producent, importer i dystrybutor
Integracja DPP z ERP, SAP, MES i API – najczęstsze pytania
Czy DPP można zintegrować z ERP?
Tak. ERP może być jednym z głównych źródeł danych modelowych, produktowych, dostawczych i transakcyjnych. Zakres integracji zależy jednak od tego, które informacje rzeczywiście są w ERP i które wymagania obowiązują dla produktu.
Czy integracja DPP z SAP wymaga modyfikacji SAP?
Nie zawsze. Możliwe jest zbudowanie zewnętrznej warstwy integracyjnej wykorzystującej dostępne mechanizmy wymiany danych i API. Konkretne rozwiązanie zależy od wersji SAP, architektury firmy i wymaganych danych.
Po co integrować MES z DPP?
MES może przechowywać dane o partiach, serialach, procesach i genealogii produktu. Jest szczególnie ważny, gdy DPP działa na poziomie partii lub pojedynczej sztuki albo wymaga informacji z procesu produkcyjnego.
Czy DPP ma jedno oficjalne API?
Nie należy traktować DPP jako jednego globalnego API. Interfejsy mogą istnieć między systemami firmy, warstwą DPP, partnerami i DPP Registry. Komisja udostępnia Registry z możliwością rejestracji przez API.
Czy DPP Registry przechowuje wszystkie dane produktu?
Nie. Registry przechowuje identyfikatory, dane rejestracyjne i wysokopoziomowe metadane. Pełne dane paszportu pozostają zdecentralizowane pod odpowiedzialnością operatora gospodarczego lub dostawcy usług DPP.
Czy można automatycznie rejestrować DPP w Registry?
Registry przewiduje API, więc architektura może automatyzować rejestrację i obsługę odpowiedzi. Szczegółowa implementacja musi być zgodna z aktualną dokumentacją i wymaganiami właściwymi dla produktu.
Czy kod QR powinien być generowany w ERP?
Nie ma takiej uniwersalnej zasady. ERP może dostarczyć identyfikator, ale data carrier może być generowany przez warstwę DPP, system etykietujący lub inne rozwiązanie. Ważne jest trwałe i jednoznaczne powiązanie produktu z właściwym paszportem.
Jak uniknąć vendor lock-in w DPP?
ESPR wymaga otwartych standardów i interoperacyjnego formatu. W projekcie warto rozdzielić dane źródłowe, warstwę integracji, model DPP i interfejsy, aby migracja lub podłączenie kolejnego systemu nie oznaczało utraty kontroli nad danymi.
Od czego zacząć integrację DPP?
Od właściwego aktu i wymaganych danych, następnie od mapy systemów oraz źródeł prawdy. Dopiero wtedy projektuje się API, transformacje i przepływy. Integracja bez modelu danych prowadzi zwykle do późniejszych przeróbek.
Wymagania techniczne DPP i Registry – źródła UE
- ↗ ESPR – rozporządzenie (UE) 2024/1781, art. 10–11: interoperacyjność, otwarte standardy i dane bez vendor lock-in
- ↗ Komisja Europejska – DPP Registry, architektura zdecentralizowana i dokumentacja
- ↗ Komisja Europejska – Registry, API, semantic repository i standardy DPP
- ↗ Rozporządzenie wykonawcze Komisji (UE) 2026/1778 – Registry i API