DPP w ERP: jak zablokować publikację lub wysyłkę niegotowego produktu?

Status funkcji: DPP Compliance Gate opisany na tej stronie jest docelowym wzorcem integracji. Konfigurowalne Gate Policies, webhooki i gotowe połączenia z ERP, PIM lub WMS nie są obecnie oferowane jako aktywna funkcja samoobsługowa. Integracje są analizowane i wyceniane indywidualnie.

Dlaczego sam dashboard gotowości nie wystarcza?

Data Mapper odpowiada na ważne pytanie: czego brakuje w danych tego produktu? W procesie operacyjnym pojawia się jednak kolejne: czy system może teraz opublikować ofertę, aktywować SKU albo zwolnić wysyłkę?

Gdy skład materiałowy znajduje się w PLM, identyfikator w ERP, dokument od dostawcy w repozytorium, a status publikacji w platformie DPP, człowiek może zobaczyć problem zbyt późno. Release gate zamienia wynik wielu kontroli w jednoznaczną decyzję techniczną, którą potrafi odczytać inny system.

Nie oznacza to przekazania ERP decyzji prawnej. Gate sprawdza reguły zapisane w polityce organizacji i zwraca wynik operacyjny. Ostateczna odpowiedzialność za wymagania produktu oraz wykonanie następnej czynności pozostaje po stronie właściwych osób i systemów.

DPP Compliance Gate: PASS, WARN i BLOCK

Najprostszy kontrakt może zwracać trzy wyniki:

Każdy wynik powinien wskazywać wersję polityki, wersję danych produktu, czas oceny oraz listę przyczyn. Dzięki temu BLOCK nie jest czarną skrzynką, a PASS można później odtworzyć w audycie.

PASS nie oznacza „produkt jest prawnie zgodny”. Oznacza wyłącznie, że wskazany produkt spełnił reguły konkretnej, wersjonowanej polityki w danym momencie.

Co może sprawdzać polityka release gate?

Nie istnieje jedna uniwersalna lista dla wszystkich branż i procesów. Reguły powinny być konfigurowalne i powiązane z właściwym profilem wymagań, a nie wpisane na stałe do kodu.

Awaria połączenia, brak możliwości przeprowadzenia oceny albo przeterminowany wynik nie powinny być automatycznie zamieniane na PASS. Integracja musi rozróżniać decyzję biznesową od błędu technicznego i ustalić bezpieczne zachowanie dla konkretnego procesu.

Przykład: ERP tworzy SKU, ale brakuje evidence dostawcy

ERP tworzy SKU
→ DPP Compliance mapuje i waliduje dane
→ BLOCK: brak aktualnego supplier evidence
→ właściciel danych lub dostawca uzupełnia dokument
→ ponowna walidacja
→ PASS
→ podpisany webhook trafia do ERP
→ ERP może zwolnić SKU według własnej autoryzacji

To ostatnie rozróżnienie jest ważne. Platforma DPP przekazuje wynik, ale nie powinna samodzielnie wykonywać operacji w systemie klienta bez osobno zaprojektowanego, autoryzowanego adaptera.

Gdzie zastosować DPP release gate?

PIM lub e-commerce: przed publikacją oferty

System sprawdza, czy produkt ma właściwy identyfikator, wymagane dane, aktualny publiczny paszport i pola potrzebne w sprzedaży na odległość. BLOCK zatrzymuje publikację konkretnego SKU, nie całego katalogu.

ERP: przed zmianą statusu produktu

Gate może zostać powiązany ze statusem „gotowy do sprzedaży”, „released” albo innym etapem istniejącym w organizacji. Nazwa i skutki statusu powinny wynikać z procesu klienta, nie z założeń platformy DPP.

WMS: przed zwolnieniem wysyłki

Jeżeli organizacja wymaga kontroli na tym etapie, WMS może sprawdzić aktualny wynik dla właściwego modelu, partii lub sztuki. Trzeba wcześniej ustalić zachowanie przy braku odpowiedzi, opóźnieniu aktualizacji oraz wyjątkach zatwierdzonych przez uprawnioną osobę.

DPP: przed publikacją nowej wersji

Wewnętrzny gate może zablokować publikację, gdy wymagane pola, dowody albo approval nie są gotowe. To najprostszy punkt startowy, ponieważ nie wymaga jeszcze sterowania zewnętrznym systemem.

Approval Workflow a Compliance Gate

Te mechanizmy rozwiązują różne problemy:

• Approval Workflow odpowiada: kto przygotował, sprawdził i zatwierdził zmianę?
• Compliance Gate odpowiada: czy według wskazanej polityki następna operacja może zostać wykonana?

Gate może używać ukończonego approval jako jednego z warunków. Nie powinien jednak zastępować ról Contributor, Approver i Publisher ani historii decyzji.

Minimalna architektura integracji

Bezpieczny przepływ powinien zachować rozdzielenie systemów źródłowych od kanonicznego modelu DPP:

1. ERP, PIM, PLM, WMS lub portal dostawcy przekazuje zmianę z idempotency key.
2. Warstwa mapowania przekształca dane do kanonicznego modelu produktu.
3. Data Mapper ocenia dane względem wskazanej wersji profilu wymagań.
4. Gate Policy łączy wynik z publication state, evidence, approval i innymi warunkami.
5. Wynik zostaje zapisany z wersją polityki i pełnym śladem audytowym.
6. Transactional outbox publikuje zdarzenie o zmianie stanu.
7. Podpisany webhook trafia do uprawnionego systemu, który sam podejmuje autoryzowaną czynność.

Webhook powinien mieć stabilny identyfikator zdarzenia, podpis, ochronę przed replay i obsługę ponowień. Odbiorca musi móc bezpiecznie przetworzyć to samo zdarzenie więcej niż raz.

Czy prawo wymaga blokady w ERP lub WMS?

Nie ma ogólnego przepisu nakazującego każdej firmie wdrożenie statusów PASS, WARN, BLOCK albo technicznej blokady w ERP. Jest to sposób organizacji kontroli wewnętrznej.

Prawo produktowe może natomiast powiązać możliwość wprowadzenia określonego produktu do obrotu z dostępnością DPP. Przykładowo:

• art. 9 ESPR odnosi tę zasadę do produktów objętych właściwym aktem delegowanym;
• rozporządzenie (UE) 2026/405 przewiduje utworzenie DPP detergentu lub surfaktantu przed wprowadzeniem go do obrotu, przy czym zasadnicze stosowanie tych przepisów rozpocznie się 23 września 2029 r.;
• rozporządzenie (UE) 2025/2509 przewiduje utworzenie DPP zabawki przed wprowadzeniem jej do obrotu, a zasadnicza data stosowania to 1 sierpnia 2030 r.

Gate może pomóc egzekwować procedurę firmy dla produktów objętych właściwymi przepisami. Nie zastępuje jednak oceny zgodności, dokumentacji technicznej, wymaganych badań ani interpretacji konkretnego aktu.

Jak przygotować pilotaż?

Zamiast zaczynać od blokowania całej wysyłki, warto wybrać jeden proces i reprezentatywną rodzinę produktów.

1. Wskaż operację, którą Gate ma chronić.
2. Ustal poziom identyfikacji: model, partia albo sztuka.
3. Zdefiniuj maksymalnie kilka warunków, które rzeczywiście blokują proces.
4. Określ właściciela i działanie naprawcze dla każdego powodu BLOCK.
5. Ustal ważność wyniku oraz zdarzenia uruchamiające ponowną ocenę.
6. Przetestuj timeout, niedostępność zależności, powtórzony webhook i ręczny wyjątek.
7. Najpierw uruchom tryb obserwacyjny, porównaj decyzje z realnym procesem, a dopiero potem włącz techniczne blokowanie.

Status planów DPP Compliance

Ręczny status gotowości produktu jest rozważany dla planu Starter. Konfigurowalne Gate Policies i webhooki są zakresem rozwojowym Growth, a bezpośrednie gate’y w ERP/PIM/WMS — zakresem indywidualnych integracji Enterprise.

Nie są to obecnie aktywne funkcje publicznego planu Free ani gotowe elementy samoobsługowego Startera. Aktualna dostępność funkcji i planów jest opisana na stronie cennika DPP Compliance.

Najczęstsze pytania

Czy BLOCK zatrzyma wysyłkę automatycznie?

Tylko jeżeli WMS lub ERP ma osobno wdrożoną i autoryzowaną integrację, która interpretuje ten wynik. Sam status w platformie DPP nie steruje systemem klienta.

Czy PASS potwierdza compliance produktu?

Nie. Potwierdza spełnienie warunków konkretnej wersji polityki. Nie jest certyfikatem, opinią prawną ani pełną oceną zgodności.

Czy Gate może działać bez API?

Tak, pierwszy etap może być ręcznym punktem kontrolnym przed publikacją DPP. API lub webhook stają się potrzebne, gdy decyzję ma odczytać zewnętrzny system.

Czy wszystkie braki powinny blokować proces?

Nie. Organizacja musi jawnie podzielić warunki na blokujące i ostrzegawcze. Podział może różnić się między publikacją DPP, aktywacją oferty i wysyłką produktu.

Od czego zacząć integrację z ERP?

Od mapy: pole DPP → system źródłowy → właściciel → reguła → częstotliwość aktualizacji. Dopiero później należy ustalić kontrakt API, webhook i zachowanie systemu przy WARN, BLOCK lub błędzie technicznym.