Bezpieczny import CSV do DPP – preflight, diff i rollback

Dlaczego poprawny CSV może nadal być niebezpieczny?

Walidacja pliku odpowiada na pytanie, czy dane można odczytać. Nie potwierdza jeszcze, że zapis da oczekiwany efekt biznesowy. Plik może mieć prawidłowe kodowanie, nagłówki i typy, a mimo to wyczyścić istniejącą wartość, zmienić identyfikator, połączyć niewłaściwy wariant albo nadpisać dane nowsze od danych źródłowych.

Ryzyko rośnie, gdy jeden import aktualizuje wiele produktów lub łączy dane z kilku systemów. Dlatego import DPP trzeba traktować jak kontrolowaną zmianę katalogu, a nie zwykłe wgranie arkusza.

Pięć kroków bezpiecznej zmiany danych

Rekomendowany proces to:

Preflight → Diff → Approve → Apply → Rollback

Nie jest to literalna sekwencja narzucona przez ESPR. To praktyczny wzorzec projektowy, który pomaga chronić integralność, historię i dostępność danych DPP.

Co powinien pokazać preflight importu CSV?

Dobry podgląd nie kończy się na liczbie poprawnych wierszy. Powinien podsumować rzeczywisty wpływ, na przykład:

250 rekordów
184 zostaną utworzone
51 zostanie zaktualizowanych
12 jest zablokowanych
3 zawierają potencjalnie destrukcyjne zmiany

Dla każdej pozycji użytkownik powinien móc zobaczyć produkt, pole, wartość obecną, wartość proponowaną, źródło oraz przyczynę ostrzeżenia. Preflight pozostaje read-only: nie tworzy produktu, nie rezerwuje miejsca w limicie i nie zmienia wyniku gotowości.

Jeżeli dane od dostawcy wymagają tłumaczenia nazw pól, słowników lub jednostek, normalizacja powinna zakończyć się przed wyliczeniem diffu. Zobacz, jak rozdzielić mapowanie pól, wartości i jednostek.

Field-level diff: które zmiany wymagają uwagi?

Nie wszystkie aktualizacje mają takie samo ryzyko. System powinien odróżniać:

• utworzenie nowego produktu
• uzupełnienie pustego pola
• zmianę istniejącej wartości
• brak rzeczywistej zmiany
• konflikt z nowszą rewizją
• operację zablokowaną
• zmianę potencjalnie destrukcyjną

Do ostatniej kategorii należą przede wszystkim zmiana stabilnego identyfikatora, wyczyszczenie danych, zmiana kategorii lub profilu wymagań, odłączenie evidence oraz modyfikacja informacji użytej w publicznym DPP.

Pusta komórka nie może automatycznie znaczyć „usuń”

W imporcie trzeba rozdzielić co najmniej cztery przypadki:

• kolumna nie istnieje — import nie zarządza tym polem
• komórka jest pusta — znaczenie zależy od jawnie wybranego trybu
• wartość ma być wyczyszczona — potrzebna jest wyraźna operacja i ostrzeżenie
• pole nie dotyczy produktu — to odrębny stan, nie pusty tekst

Domyślny import nie powinien usuwać produktu, wariantu ani dokumentu. Jeżeli organizacja potrzebuje archiwizacji, musi to być osobna operacja z właściwym uprawnieniem i raportem wpływu.

Zatwierdzenie i próg dużej zmiany

Kliknięcie „Importuj” powinno zatwierdzać konkretną checksumę planu zmian. Jeżeli od podglądu produkt, profil albo mapowanie uległy zmianie, wykonanie musi zostać zatrzymane i ponownie przeliczone.

Dodatkowa akceptacja jest potrzebna, gdy import przekracza uzgodniony próg, np. aktualizuje znaczną część katalogu, czyści wiele pól, zmienia identyfikatory albo dotyka danych publicznych. Próg powinien być wersjonowaną polityką, a nie ukrytą stałą interfejsu.

Idempotencja i raport wykonania

Idempotency key chroni przed podwójnym wykonaniem tego samego żądania po timeoutach i ponowieniach. Nie zastępuje jednak kontroli wersji. Apply powinien także sprawdzić, czy rekord bazowy nadal ma rewizję używaną w preflight.

Końcowy raport musi pokazywać każdy produkt jako:

• success
• failed
• skipped
• conflict

Częściowego wykonania nie wolno przedstawiać jako pełnego sukcesu. Użytkownik musi wiedzieć, które rekordy wymagają poprawienia i bezpiecznego ponowienia.

Jak działa Undo import?

Rollback nie powinien kasować historii. Bezpieczny mechanizm zapisuje checkpoint przed wykonaniem, a następnie tworzy nowe rewizje przywracające poprzednie wartości.

Automatyczne cofnięcie trzeba zatrzymać, jeżeli po imporcie ktoś ręcznie zmienił produkt, powstała nowa wersja DPP albo dodano inną zależność. System powinien wtedy pokazać konflikt do review, zamiast nadpisać nowszą pracę.

Opublikowany paszport pozostaje niezmienny. Rollback danych produktu może przygotować nowy draft lub ponowną ocenę, ale nie przepisuje historycznej wersji dostępnej z kodu QR.

Ten sam wzorzec dla API, ERP i PIM

Integracja ciągła wymaga tych samych zabezpieczeń co CSV, tylko udostępnionych maszynowo:

• endpoint dry-run zwracający plan i diff
• obowiązkowy klucz idempotencji dla operacji zapisu
• expected version i ochrona przed starszym źródłem
• limit wielkości oraz próg zmiany
• kolejka ponowień i dead-letter queue
• status zdrowia integracji i ostatniego poprawnego przetworzenia
• możliwość ponowienia wyłącznie błędnych rekordów

Decyzja wykonawcza Komisji (UE) 2026/1736 publikuje odniesienia m.in. do EN 18216:2026 dla protokołów wymiany danych, EN 18222:2026 dla API cyklu życia DPP i EN 18223:2026 dla interoperacyjności systemu. Same tytuły norm nie potwierdzają zgodności konkretnego importera — szczegółowy zakres trzeba ocenić względem tekstu normy i właściwych wymagań produktowych.

Checklista przed uruchomieniem importu DPP

1. Pobierz szablon dla właściwej domeny i wersji profilu.
2. Ustal, które kolumny tworzą rekord, aktualizują go lub pozostają bez wpływu.
3. Wykonaj preflight bez zapisu.
4. Przejrzyj wszystkie blokady i potencjalnie destrukcyjne różnice.
5. Potwierdź dokładny plan zmian, a nie tylko nazwę pliku.
6. Zachowaj raport wykonania oraz checkpoint.
7. Ponownie oblicz readiness dla zmienionych produktów.
8. Sprawdź drafty przed utworzeniem kolejnej publicznej wersji DPP.

Safe Import w DPP Compliance

Import CSV jest elementem planu Starter, ale pełny workflow Preflight → Diff → Approve → Apply → Rollback jest zakresem rozwoju produktu. Nie deklarujemy dry-run API, automatycznego rollbacku ani Integration Health jako funkcji dostępnych obecnie. Ta strona opisuje wymagany model bezpieczeństwa, według którego należy rozwijać kolejne ścieżki aktualizacji danych.