Dziedziczenie danych DPP — które wartości trzymać na poziomie modelu, partii i egzemplarza?

Status funkcji: polityki dziedziczenia, podgląd propagacji i „Promote to parent” to projektowany kierunek DPP Compliance. Nie są jeszcze aktywnymi funkcjami samoobsługowymi. Poniższe reguły są wzorcem architektonicznym, nie gotowym automatem do stwierdzania zgodności prawnej.

W katalogu DPP pytanie „czy mamy wartość?” nie wystarcza. Trzeba też wiedzieć na jakim poziomie jest prawdziwa, skąd pochodzi i czy może być nadpisana niżej. Inaczej wspólny dokument będzie kopiowany do każdego SKU, a zmiana jednego pola może przypadkiem zmienić znaczenie opublikowanych paszportów.

Najpierw przeczytaj wyjaśnienie relacji rodzina–model–wariant–partia–sztuka, jeśli ustalasz strukturę katalogu. Tutaj skupiamy się na regułach pól i kontroli zmian.

Poziom DPP a miejsce przechowywania wartości to dwie różne decyzje

Art. 9 ust. 2 lit. d ESPR przewiduje, że odpowiedni akt delegowany wskaże DPP na poziomie modelu, partii lub sztuki. Nie wynika z tego, że każdą wartość trzeba fizycznie zapisać na tym samym poziomie w bazie. Paszport partii może korzystać z zatwierdzonych danych modelu i danych lokalnych tej partii — pod warunkiem, że system potrafi odtworzyć użyte źródła i opublikowany snapshot.

Szczegółowy zakres danych wynika z aktu właściwego dla grupy produktu i wersji profilu wymagań. Poniższa tabela to przykład projektowy, nie obowiązkowa lista pól każdego DPP.

Pięć jawnych polityk pola

W projekcie implementacyjnym trzeba rozstrzygnąć, czy LOCKED jest osobną polityką czy modyfikatorem INHERIT; nie może być niejasnego pierwszeństwa. COMPUTED nie oznacza też „AI zgadło wartość”. Wynik musi mieć deterministyczną regułę, wersję wejść i możliwość audytu. Polityki powinny być konfigurowane i wersjonowane, a nie zaszyte na stałe pod jeden sektor.

Wartość efektywna musi pokazywać swoje pochodzenie

Przykład odczytu pola dla partii:

Field: recycling_instruction
Effective value: „Oddziel tapicerkę od stelaża...”
Value owner: Product Family Oslo
Source revision: 4
Rule: INHERIT + OVERRIDE, profile v3
Path: Oslo → Oslo 60 → Oslo 60 Black → Batch 2026-09
Local override: none

Jeżeli wariant Black ma własną instrukcję, system pokazuje ją jako override wraz z autorem i rewizją, a nie udaje, że pochodzi z rodziny. Trzeba też odróżniać brak wartości od zatwierdzonego not applicable oraz od danych dostępnych tylko wewnętrznie. Dziedziczenie nie może samo zmienić klasy widoczności z prywatnej na publiczną.

Zmiana rodzica: najpierw preflight, potem zapis

Załóżmy, że instrukcja recyklingu na poziomie rodziny Oslo zmienia się z v4 na v5. Bezpieczny podgląd powinien odpowiedzieć:

182 warianty przejmą nową wartość
7 wariantów ma lokalny override — nie zmienią się
12 partii ma draft DPP do ponownej walidacji
24 opublikowane paszporty używają v4 — wymagają oceny wpływu

Lista dotkniętych rekordów musi zostać utrwalona wraz z ich wersjami. Jeżeli ktoś zmieni wariant między podglądem a zatwierdzeniem, operacja powinna się zatrzymać i przeliczyć wpływ. Użytkownik nie powinien zgadywać, czy kliknięcie „Zapisz” zmieniło jedno pole czy tysiące wartości efektywnych.

Zmiana kanonicznych danych nie aktualizuje automatycznie starych, opublikowanych DPP. Art. 9 ust. 1 ESPR wymaga danych dokładnych, kompletnych i aktualnych; to powód do oceny wpływu i, gdy potrzebne, opublikowania nowej wersji po review. Historyczny snapshot powinien pozostać audytowalny. Zobacz proces korekty DPP.

„Promote to parent”: jak usunąć 150 kopii bez utraty wyjątków?

Jeżeli 150 wariantów ma pozornie identyczną wartość, można zaproponować przeniesienie jej na model. Najpierw trzeba znormalizować jednostki i format, sprawdzić znaczenie oraz źródło wartości, a następnie pokazać diff. Po zatwierdzeniu równoważne kopie lokalne zostają zastąpione odwołaniem do rodzica; wartości odmienne pozostają override'ami albo blokują operację.

Promote to parent nie jest tym samym co masowa naprawa braków danych. Ta druga aktualizuje wiele rekordów, które już mają problem. Promocja zmienia strukturę źródła prawdy, żeby problem kopiowania nie wracał.

Jak traktować BOM, komponent i wersję rynkową?

Komponent używany w wielu modelach ma wiele relacji, więc nie powinien być wciskany w prostą linię rodzic–dziecko. Skład wyliczony z BOM wymaga wersji BOM, ilości, jednostek i identyfikatorów komponentów. Zmiana deklaracji materiałowej jednego komponentu może dotknąć kilka rodzin produktów — preflight musi śledzić tę zależność osobno.

Wersja rynkowa również nie jest automatyczną kopią fizycznych danych. Może wskazywać właściwy profil wymagań i wersję językową instrukcji. Zobacz, jak kontrolować tłumaczenia DPP względem wersji źródłowej.

Checklista przed pilotażem

1. Wybierz dwie wartości wspólne i dwie rzeczywiście lokalne dla wybranego produktu.
2. Zapisz dozwolony poziom źródła i politykę każdej wartości.
3. Przetestuj jeden override wariantu oraz zmianę wartości rodzica.
4. Sprawdź, czy Data Mapper wskazuje wartość efektywną i jej pochodzenie.
5. Odtwórz, które dokładnie rewizje znalazły się w opublikowanym DPP.

To test jakości modelu danych, a nie prawny test zgodności produktu. Jeśli źródła znajdują się w kilku ERP/PIM, zaplanuj mapowanie i pilotaż DPP na jednym reprezentatywnym modelu, zanim przeniesiesz cały katalog.