Integracja DPP z ERP – API i wymiana danych

Integracja DPP z ERP nie polega na skopiowaniu całej bazy do kolejnego systemu. Najpierw trzeba wskazać, które dane pochodzą z ERP, PIM, PLM, MES lub od dostawców, a następnie zmapować je do stabilnego modelu DPP, zweryfikować i kontrolowanie publikować. Poniższy plan pokazuje zakres pilotażu przed indywidualną wyceną integracji.

Mapa systemów źródłowych DPP

Jak wygląda integracja DPP z ERP?

ERP zwykle dostarcza część identyfikatorów, danych organizacyjnych i transakcyjnych, ale nie cały paszport. Integracja pobiera dane z właściwych systemów źródłowych, mapuje je do modelu DPP, sprawdza kompletność, tworzy wersję paszportu i publikuje ją pod trwałym identyfikatorem.

Platforma DPP powinna być warstwą publikacji i zarządzania paszportami, a nie drugim ERP lub PLM. Właściciel każdego pola musi pozostać jednoznaczny.

Trzy warianty integracji danych z ERP

Właściwy wariant zależy od liczby produktów, częstotliwości zmian i możliwości systemu źródłowego. W pilotażu warto wybrać najprostszy przepływ, który pozwala sprawdzić model danych i odpowiedzialności.

CSV nie jest rozwiązaniem gorszym z definicji. Może być bezpiecznym początkiem, jeżeli import ma podgląd, walidację i nie nadpisuje danych bez potwierdzenia. API staje się potrzebne wtedy, gdy ręczna wymiana nie odpowiada skali lub częstotliwości zmian.

Który system jest źródłem danych DPP?

Podział zależy od architektury firmy, ale warto jawnie przypisać źródło nadrzędne dla każdej kategorii danych.

• ERP: identyfikatory, jednostki organizacyjne, dostawcy i partie
• PIM: opisy, klasyfikacje i informacje rynkowe
• PLM: konstrukcja, materiały, komponenty i dokumentacja techniczna
• MES: dane wykonania produkcji, zakładu i partii
• portale dostawców: deklaracje oraz dane komponentów
• platforma DPP: walidacja, prawa dostępu, publikacja i wersje paszportu

Architektura wymiany danych

Najprostszy przepływ obejmuje ekstrakcję danych, transformację do uzgodnionego schematu, walidację, publikację i monitoring. Aktualizacja w systemie źródłowym powinna uruchomić kontrolowany proces zmiany DPP, a błąd trafić do właściciela danych zamiast zostać cicho pominięty.

Gdy kolejne feedy tego samego dostawcy używają własnych nazw, jednostek i słowników, warstwa transformacji powinna mieć jawny zakres oraz wersję. Przeczytaj przewodnik po normalizacji danych dostawców do modelu DPP.

Od lipca 2026 r. opublikowane odniesienia do EN 18216:2026, EN 18222:2026 i EN 18223:2026 dają techniczny punkt odniesienia odpowiednio dla protokołów wymiany danych, API cyklu życia DPP oraz interoperacyjności systemu. Nie oznacza to, że każdy interfejs jest automatycznie zgodny — trzeba sprawdzić zakres właściwej normy i aktu produktowego.

Wymagania dla DPP API

ESPR zakłada dane otwarte, interoperacyjne i możliwe do przeniesienia. Techniczny kontrakt integracji powinien pozwalać utrzymać tę zasadę także po zmianie platformy.

• udokumentowane, wersjonowane endpointy i schematy
• stabilne identyfikatory oraz idempotentne operacje
• walidacja pól wymaganych i słowników
• historia zmian, korekt i statusów publikacji
• uwierzytelnianie, autoryzacja i rejestrowanie zdarzeń
• monitoring opóźnień, błędów oraz dostępności
• pełny eksport bez zamkniętego formatu dostawcy

Najczęstsze błędy integracji DPP

Problemy zwykle dotyczą odpowiedzialności za dane i obsługi wyjątków, a nie samego połączenia HTTP.

• traktowanie ERP jako źródła wszystkich pól
• brak właściciela danych po stronie biznesowej
• publikacja niepełnego rekordu bez jawnego statusu
• nadpisywanie historii przy korekcie
• łączenie modelu, partii i sztuki jednym identyfikatorem
• brak kolejki ponowień i procesu obsługi błędów
• adresy DPP zależne od jednego dostawcy bez planu migracji

Pilotaż integracji DPP z ERP

Dobry pilotaż obejmuje jedną reprezentatywną rodzinę produktów, co najmniej dwa systemy źródłowe i pełny cykl życia danych. Nie kończy się na pierwszym opublikowaniu rekordu.

• pobranie rzeczywistych danych z ERP i drugiego systemu
• walidacja braków i przekazanie błędu właścicielowi
• utworzenie identyfikatora oraz publikacja paszportu
• zmiana danych źródłowych i utworzenie nowej wersji
• odczyt publiczny i dostęp użytkownika uprawnionego
• korekta, wycofanie i pełny eksport danych

Integracja ERP/PIM w DPP Compliance

Nie deklarujemy gotowego konektora do każdego systemu ERP. SAP, Microsoft Dynamics, Comarch, enova365 i rozwiązania własne różnią się modelem danych, interfejsami oraz zakresem konfiguracji. Dlatego integracja ERP/PIM jest usługą wycenianą po analizie konkretnego środowiska.

Pierwszym rezultatem prac powinna być mapa: pole DPP → system źródłowy → właściciel danych → reguła walidacji → częstotliwość aktualizacji. Dopiero na tej podstawie można uczciwie wybrać CSV, API albo przepływ zdarzeniowy i oszacować pracochłonność. Zobacz zakres oferty wdrożenia i integracji DPP.

Najczęstsze pytania o integrację DPP z ERP

Czy wszystkie dane DPP powinny pochodzić z ERP?

Nie. ERP zwykle przechowuje identyfikatory, dane organizacyjne, dostawców i partie, ale skład materiałowy może znajdować się w PLM, opis w PIM, dane produkcyjne w MES, a deklaracje w portalu dostawców.

Czy integrację należy zacząć od API?

Nie zawsze. Najpierw trzeba potwierdzić zakres pól, jakość danych i właścicieli. Kontrolowany import CSV może szybciej zweryfikować model w pilotażu. API warto wdrażać tam, gdzie uzasadniają je skala, częstotliwość zmian i wymagany czas publikacji.

Ile kosztuje integracja DPP z ERP?

Koszt zależy od systemu, liczby źródeł, dostępnych interfejsów, jakości danych i obsługiwanych scenariuszy. Dlatego integracje ERP/PIM mają indywidualną wycenę po analizie, a nie jedną cenę dla wszystkich środowisk.

Czy połączenie ERP z platformą potwierdza compliance?

Nie. Integracja usprawnia przepływ i kontrolę danych, ale nie rozstrzyga sama, czy produkt spełnia wszystkie obowiązki prawne. Wymagania trzeba oceniać względem właściwego, aktualnego aktu produktowego.