Czy mogę połączyć paszport produktu ze swoim systemem ERP lub inwentaryzacji?

Połączenie staje się konkretne dopiero wraz z normą techniczną

Bezpośrednie połączenie między cyfrowym paszportem produktu a systemem ERP lub inwentarzowym nie jest w tej chwili możliwe, ponieważ specyfikacje techniczne tego nie zostały jeszcze ustalone. ESPR (Rozporządzenie (UE) 2024/1781) zawiera jednak w artykułach 10 i 11 podstawę: paszport musi być interoperacyjny, oparty na otwartych standardach i czytelny maszynowo. Oznacza to, że zautomatyzowana wymiana z systemami biznesowymi jest ostatecznie założeniem wyjściowym, a nie wyjątkiem. Jednak to, jak w praktyce będzie wyglądać ta wymiana — jaki format pliku, jaki interfejs, jakie uprawnienia dostępu — wynika dopiero z działań delegowanych dla każdej grupy produktów. Dla żelaza i stali takie działanie jeszcze nie istnieje.

Do czego to się stosuje, a do czego nie

Chodzi o pytanie, czy systemy będą mogły automatycznie pobierać dane z paszportu lub zapisywać je w nim. Dotyczy to technicznego ustanowienia samego paszportu, tak jak opisane jest w rozporządzeniu: jak jest zbudowany, kto ma do niego dostęp i w jakiej formie dane są dostępne. Nie chodzi o pytanie, czy konkretny pakiet ERP jest odpowiedni, ani o konkretne API lub format danych — te wybory nie zostały jeszcze podjęte. Nie chodzi również o obowiązek posiadania paszportu; jest to odrębny temat, który jest wypełniany dla każdej grupy produktów. To, co tutaj opisane, to wyłącznie zasada, że paszport musi być czytelny maszynowo i interoperacyjny — sposób, w jaki zasada ta zostanie konkretnie wdrożona dla żelaza i stali, pozostaje otwarty.

Jeszcze brak stałej daty, jeszcze brak stałej normy technicznej

Nie ma jeszcze daty, od której techniczny standard połączenia dla żelaza i stali będzie obowiązywać, ponieważ standard ten jest częścią działania delegowanego, które ma się jeszcze ukazać. Zgodnie z planem pracy ESPR na okres 2025-2030 pierwsze działanie delegowane oczekiwane jest w 2026 roku, a obowiązki obowiązują z 18-miesięcznym okresem przejściowym. Dopóki to działanie się nie pojawi, ustalono, że paszport musi być interoperacyjny i czytelny maszynowo (artykuły 10 i 11), ale nie w jaki sposób będzie to technicznie wdrażane. Do tego czasu paszport w praktyce funkcjonuje jako dokument do odczytania przez człowieka poprzez nośnik danych QR, a nie jako zautomatyzowany strumień danych do systemu zewnętrznego.

Co to oznacza dla podejścia

Dla osób, które już teraz myślą o połączeniu ze swoim systemem, kolejność jest następująca. Po pierwsze: nic nie trzeba jeszcze budować, ponieważ nie ma standardu, do którego można by budować. Po drugie: uporządkowanie własnych danych produktu jest już teraz warte pracy, niezależnie od ostatecznej formy technicznej — przejrzysty, spójny zestaw danych na produkt (pochodzenie, skład, certyfikaty) jest podstawą, na której będzie opierać się każdy przyszły mechanizm połączenia. Po trzecie: gdy tylko pojawi się działanie delegowane dla żelaza i stali, wyjaśni ono, jaki format i jaka metoda dostępu mają zastosowanie, i dopiero wtedy można zaprojektować konkretne połączenie. Po czwarte: do tego czasu paszport pozostaje dostępny za pomocą kodu QR, który jest dołączony do produktu, co dla większości codziennych transakcji w handlu stali i przetwórstwie metalu jest już wystarczające — połączenie z systemem ERP jest wtedy efektywnym skokiem na później, a nie warunkiem możliwości pracy z paszportem teraz.

Skąd to wynika: artykuły 10 i 11 ESPR

Artykuł 10 rozporządzenia ESPR (Rozporządzenie (UE) 2024/1781) opisuje wymogi, które musi spełniać cyfrowy paszport produktu, w tym interoperacyjność i stosowanie otwartych standardów. Artykuł 11 dotyczy technicznego projektu i funkcjonowania paszportu, takich jak rejestry, dostęp do danych i sposób działania paszportu. Oba artykuły zawierają zasadę, że paszport musi być odpowiedni do przetwarzania maszynowego, jednak jego wdrożenie — rzeczywista specyfikacja techniczna dla grupy produktów — zostaje przekazana delegowanym aktom, które mają się jeszcze pojawić. Dla precyzyjnego sformułowania tekst oficjalny rozporządzenia jest wiążący.

Kto chce się do tego przygotować już teraz, powinien zadbać o to, aby dane dotyczące własnych produktów były gromadzone w ustrukturyzowany i kompletny sposób, aby po opublikowaniu standardu technicznego mogły być bez większych trudności dostosowane do tego, co zostanie wówczas ustalone. Ta strona zostanie zaktualizowana zaraz po opublikowaniu delegowanego aktu dla żelaza i stali oraz gdy zostaną znane szczegóły techniczne.

Na czym opiera się ta informacja

Samo rozporządzenie znajduje się na EUR-Lex. Informujemy o każde stwierdzeniu; nie musisz nam ufać.

Co konkretnie musisz zrobić

Czego się od Ciebie oczekuje

Dane muszą być czytelne maszynowo i prznoszone

Artykuł 10 rozporządzenia ESPR (Rozporządzenie (UE) 2024/1781) stanowi, że dane zawarte w cyfrowym paszporcie produktu muszą być dostępne w ustrukturyzowanym formacie czytelnym maszynowo. To jest jednocześnie punkt zaczepienia dla integracji z własnym systemem: dane czytelne maszynowo są w zasadzie również odpowiednie do automatycznego przesyłania do lub z systemu ERP lub magazynowego. Dla przedsiębiorstwa zatrudniającego od 10 do 100 pracowników oznacza to przede wszystkim, że pytanie "czy to można powiązać" nie jest przede wszystkim pytaniem prawnym, lecz technicznym: jaki format wykorzystuje paszport, a czy własne oprogramowanie potrafi ten format odczytać lub zapisać. Zob. również stronę dotyczącą w jakim formacie muszę dostarczyć dane dla paszportu produktu.

Paszport musi być zgodny z jednolitą strukturą techniczną

Artykuł 11 rozporządzenia ESPR dotyczy projektowania technicznego i funkcjonowania paszportu oraz odnosi się do specyfikacji technicznych, które Komisja będzie dalej opracowywać. Dla praktyki integracji oznacza to, że nie można po prostu dostarczać lub pobierać "własnego pliku": u podstaw leży ustrukturyzowana struktura, prawdopodobnie oparta na istniejących systemach identyfikacji. Kto już teraz pracuje z systemem kodowania artykułów, powinien sprawdzić, jak ten system będzie zgodny ze sposobem przydzielania unikalnych kodów identyfikacyjnych — zob. jak przydzielam każdemu produktowi unikalny kod identyfikacyjny. System ERP, który już pracuje z jednoznacznymi, stabilnymi kodami produktów, jest w korzystniejszej pozycji do połączenia niż system, w którym kody różnią się w zależności od zamówienia lub klienta.

Połączenie odbywa się za pośrednictwem nośnika, a nie bezpośredniego połączenia bazy danych

Artykuł 11 opisuje również, że paszport jest dostępny za pośrednictwem nośnika danych na produkcie. Jest to ważny punkt dla oczekiwań, które przedsiębiorstwo może mieć wobec "połączenia": nie chodzi o bezpośrednie połączenie bazy danych między dwoma przedsiębiorstwami, ale o łańcuch, w którym nośnik danych (zazwyczaj kod QR) odwołuje się do zapisanego paszportu. Połączenie z systemem ERP lub magazynowym znajduje się zatem po obu stronach: przy dostarczaniu danych produktu z własnego systemu do strony, która kompiluje paszport, i przy odczytywaniu danych paszportu (na przykład przy zakupie stali) do własnego systemu. Więcej informacji o tym nośniku znajduje się na stronie jak kod QR dokumentu produktu trafia na moją stal.

Dane muszą pozostać aktualne tak długo, jak długo istnieje paszport

Z artykułu 10 wynika również, że dane w paszporcie muszą być poprawne i aktualne tak długo, jak długo paszport istnieje. Dla powiązania z systemem inwentaryzacji oznacza to, że jednorazowe dostarczenie zwykle nie wystarczy: jeśli właściwości partii stali ulegną zmianie lub zostanie odkryta błąd, musi istnieć sposób powiadomienia miejsca, w którym paszport jest hostowany. Przedsiębiorstwa, które połączą swoje systemy ERP, powinny również zwrócić uwagę na to, jak długo ta aktualność musi być utrzymywana — zobacz jak długo produktpaszport musi pozostać dostępny.

Gdzie dzieje się źle w praktyce

Wewnętrzne kody artykułów są mylone z oficjalną identyfikacją produktu. System ERP zna produkt pod wewnętrznym kodem SKU, podczas gdy paszport wymaga innego, unikatowego kodu identyfikacyjnego. Bez tabeli tłumaczeniowej między nimi dochodzi do zamieszania przy powiązaniu, szczególnie jeśli jeden kod wewnętrzny obejmuje wiele partii.

Zmiany w zapasach nie są przenoszone do danych paszportu. System inwentaryzacji rejestruje na przykład, że partia stali została przytopiona, podzielona lub połączona, ale ta zmiana nie dociera do paszportu automatycznie. Ma to duże znaczenie dla pytania, czy stal jest rejestrowana na partię czy na sztukę — zobacz czy rejestruję stal na partię czy na sztukę — ponieważ jednostka rejestracji w systemie ERP musi odpowiadać jednostce, na której opiera się paszport.

Pliki eksportowe z systemu ERP nie są zgodne z wymaganym formatem. Wiele pakietów ERP eksportuje domyślnie w formacie Excel, CSV lub we własnej strukturze XML. Bez wcześniejszego uzgodnienia taki plik okazuje się niezgodny z formatem niezbędnym dla paszportu, co skutkuje opóźnieniami i dodatkową pracą ręczną.

Zakłada się, że połączenie działa również bez połączenia internetowego. Niektóre systemy inwentaryzacyjne na halach produkcyjnych działają częściowo offline, na przykład na terminalu magazynowym. Rodzi to pytanie, czy sam paszport musi być również dostępny bez połączenia; jest to odrębne pytanie niezależne od połączenia z systemem ERP. Patrz czy paszport produktu musi działać bez połączenia internetowego.

Prawa dostępu między systemami nie są regulowane. Połączenie oznacza, że dane przepływają między dwoma lub więcej systemami, często za pośrednictwem strony trzeciej hostującej paszport. Jeśli nie zostanie ustalone, kto może przeglądać, modyfikować lub przekazywać dane, powstaje niejasność dotycząca odpowiedzialności w przypadku błędu — pytanie związane z tym, jak dane są zabezpieczane w trakcie przesyłu, patrz jak zapewniam bezpieczeństwo danych w paszporcie produktu.

Co możesz dokumentować

Przegląd pól w systemie ERP lub inwentaryzacyjnym, które odpowiadają polom w paszporcie produktu, wraz z tabelą tłumaczenia między kodami artykułów wewnętrznych a unikalnym kodem identyfikacyjnym produktu.
Opis formatu eksportu używanego przez własny system oraz porównanie z formatem niezbędnym dla paszportu.
Umowy ze stroną, która opracowuje lub hostuje paszport, dotyczące częstotliwości i sposobu wymiany danych: jednorazowo podczas tworzenia, czy bieżąco w przypadku zmian.
Procedura przekazywania zmian w zapasach, podziale partii lub właściwościach produktu do danych paszportu, wraz z określeniem, kto za to odpowiada.
Przegląd pracowników w firmie mających dostęp do połączenia między systemem własnym a paszportem oraz przysługujące im uprawnienia.
Umowa dotycząca tego, co się dzieje z połączeniem i przepływem danych, jeśli paszport produktu zostanie zmieniony, wycofany lub zastąpiony.

To nie jest porady prawna. Ta strona zawiera ogólne informacje na temat przepisów, których dotyczy ta platforma. Nie znamy Twojej sytuacji. W razie wątpliwości dotyczących Twojego przypadku skonsultuj się z prawnikiem lub właściwym organem nadzoru.

Napisane przy użyciu AI na podstawie źródeł powyżej, sprawdzone przez człowieka dnia 2026-08-22. Coś się nie zgadza? Daj nam znać — korekty mają pierwszeństwo.