Model, wariant, partia i sztuka w Digital Product Passport — jak nie duplikować danych DPP?

Status funkcji: hierarchia Product Family → Model → Variant → Batch → Item i kontrolowane dziedziczenie opisane poniżej są propozycją architektury rozwijanej dla DPP Compliance, nie aktywną funkcją samoobsługową. Obecny katalog i Data Mapper nie oznaczają jeszcze automatycznego dziedziczenia między produktami.

Jeden produkt handlowy może występować w kilku kolorach, partiach i tysiącach egzemplarzy. Jeśli instrukcję recyklingu, dane producenta czy skład materiałowy skopiujesz do każdego rekordu, jedna późniejsza poprawka zamieni się w setki ręcznych zmian. Jeśli natomiast jeden link DPP przypiszesz bez rozróżnienia do wszystkich wariantów, klient może trafić do paszportu niewłaściwego produktu.

Rozwiązaniem jest jawna struktura produktów i reguły, które mówią, skąd pochodzi każda wartość. Nie chodzi o to, aby każda firma zawsze tworzyła pięć poziomów. Chodzi o wybór właściwego poziomu dla identyfikacji, danych i publikacji.

Czy przepisy wymagają DPP na poziomie modelu, partii czy sztuki?

Art. 9 ust. 2 lit. d rozporządzenia ESPR (UE) 2024/1781 przewiduje, że właściwy akt delegowany dla grupy produktów określi, czy paszport ma być ustanowiony na poziomie modelu, partii czy sztuki, i zdefiniuje te poziomy. Przepisy o DPP Registry przewidują walidację poziomu szczegółowości względem właściwych reguł unijnych. Nie istnieje więc jeden uniwersalny wybór dla całego katalogu.

Product Family i Variant są użytecznymi pojęciami modelu danych firmy, ale sam ESPR nie nakazuje przechowywania ich w jednej konkretnej hierarchii. Wymagania i dane trzeba rozstrzygać według właściwego aktu produktowego, jego wersji, rynku oraz przyjętego poziomu DPP. Sama hierarchia nie jest certyfikatem zgodności.

Pięć poziomów na przykładzie krzesła

To przykład projektowy, nie lista obowiązkowych pól dla mebli. Nie wolno automatycznie utożsamiać SKU z poziomem wymaganym prawem dla paszportu. Oferta e-commerce może mieć osobne SKU każdego wariantu, podczas gdy obowiązujący akt produktowy określi inny poziom DPP. Powiązanie wariantu oferty z właściwym identyfikatorem i publicznym adresem paszportu musi być jawne. Zobacz DPP dla e-commerce.

Co dziedziczyć, a czego nie kopiować?

Wspólną instrukcję recyklingu można utrzymywać raz na poziomie rodziny, jeżeli rzeczywiście odnosi się do wszystkich jej modeli. Dane producenta można przypisać modelowi, a wariantowi pozwolić z nich korzystać. Skład materiałowy może być inny dla wariantu czarnego i białego; wtedy nie powinien być bezmyślnie odziedziczony z rodziny. Data produkcji jest faktem partii, a numer seryjny — sztuki.

Nawet wspólna wartość może mieć wyjątki. Jeśli jeden wariant ma inną instrukcję demontażu, potrzebuje widocznego override'u, nie ukrytej kopii. Użytkownik powinien widzieć:

Recycling instruction: inherited from Product Family Oslo, revision 4
Variant Oslo 60 / Black: local override, revision 2

Szczegółowe zasady przypisania pól i bezpiecznej zmiany wartości opisujemy w przewodniku o dziedziczeniu danych DPP.

A co z komponentami i rynkami?

Drzewo produktów nie wystarczy do wszystkich zależności. Jeden komponent może trafić do wielu modeli, a materiał może występować w kilku komponentach. To relacje Product → Component → Material, które wymagają osobnego śledzenia wersji i pochodzenia. Podobnie wersja na rynek DE nie musi być kopią produktu PL: może wymagać lokalnego języka, innego zakresu dokumentów lub innej wersji profilu wymagań. Przeczytaj o wersjach językowych DPP.

Co się dzieje po zmianie danych wspólnych?

Zmiana instrukcji na poziomie rodziny może dotyczyć setek wariantów i partii. Przed zapisem zespół powinien otrzymać listę rekordów dziedziczących wartość, wyjątków z override'em, dotkniętych draftów i już opublikowanych DPP. Przykładowy podgląd:

182 warianty dziedziczą instrukcję
7 wariantów ma własny override — nie zmienią się
24 opublikowane DPP używają poprzedniej wartości — wymagają oceny korekty

To nie jest polecenie „automatycznie opublikuj 24 paszporty”. Art. 9 ust. 1 ESPR wymaga dokładnych, kompletnych i aktualnych danych DPP. Organizacja powinna ocenić wpływ zmiany, a w razie potrzeby przygotować i zatwierdzić nową wersję. Historycznego snapshotu nie wolno po cichu przepisać. Zobacz, co zrobić po wykryciu błędu w opublikowanym DPP.

Od czego zacząć projekt katalogu?

W pilotażu wybierz jedną rodzinę produktu z dwoma wariantami i jedną partią. Spisz stabilne identyfikatory, pola wspólne, pola specyficzne i źródła danych. Dopiero potem wybierz poziom DPP według właściwego profilu i aktu. Przetestuj zmianę wspólnej instrukcji oraz wyjątek jednego wariantu: czy wiadomo, które rekordy się zmienią i które paszporty wymagają przeglądu?

Jeśli w ERP/PIM informacje są rozproszone, usługa wdrożeniowa DPP pomaga ustalić model, mapę źródeł i zakres pilotażu bez wymiany systemów źródłowych.

Najczęstsze pytania

Czy każdy wariant potrzebuje osobnego DPP?

Nie da się odpowiedzieć jednolicie dla wszystkich produktów. Właściwy akt określa poziom paszportu; wariant handlowy nadal musi prowadzić do właściwego identyfikatora i informacji.

Czy zmiana danych rodziny automatycznie aktualizuje publiczny paszport?

Nie powinna. Wartość efektywna w katalogu może się zmienić, ale opublikowany DPP powinien pozostać historycznym snapshotem do czasu jawnej nowej publikacji.

Czy DPP Compliance już obsługuje taką hierarchię?

Nie jako aktywną funkcję samoobsługową. Ten artykuł opisuje docelowy wzorzec danych i pytania, które warto rozstrzygnąć przed rozbudową katalogu.