Czy mogę powiązać paszport produktu z moim systemem ERP lub zapasami?

Powiązanie jest możliwe w granicach formatu danych

Powiązanie między cyfrowym paszportem produktu a własnym systemem ERP lub zarządzania zapasami jest zasadniczo możliwe, ale sposób jego realizacji zależy od kształtu technicznego ustaleonego dla paszportu. ESPR (Rozporządzenie (UE) 2024/1781) określa w artykule 10 wymogi, którym musi odpowiadać cyfrowy paszport produktu, a w artykule 11 jego budowę i działanie techniczne. Z tego wynika, że paszport musi być maszynowo czytelny i wymienny — nie że każdy producent może dowolnie budować własne powiązanie z jakimkolwiek systemem, jak mu się podoba. W praktyce powiązanie przebiega poprzez platformę, która opracowuje i hostuje paszport, oraz poprzez format danych, który zostanie na to uzgodniony.

Dla kogo jest to istotne i dla czego nie

To pytanie dotyczy producentów i importerów półfabrykatów aluminium, którzy muszą dostarczać dane do paszportu produktu — producentów profili, odlewni, producentów opakowań aluminiowych. Dla nich istotne jest, czy istniejące dane produkcyjne (skład materiału, numery partii, pochodzenie, specyfikacje techniczne) mogą automatycznie przechodzić do paszportu, zamiast być ręcznie przepisywane. Nie chodzi o pytanie, czy przedsiębiorstwo zobowiązane jest do zbudowania powiązania ERP — takiego obowiązku nie ma. ESPR reguluje, co paszport musi być w stanie robić (interoperacyjny, maszynowo czytelny, dostępny poprzez nośnik danych, taki jak kod QR), a nie sposób, w jaki pojedyncze przedsiębiorstwo organizuje swoje własne oprogramowanie wewnętrzne. Przedsiębiorstwo bez systemu ERP może dostarczać dane równie dobrze poprzez formularz lub plik; przedsiębiorstwo z rozbudowanym systemem ERP może potencjalnie dostarczać te dane efektywniej, ale nie jest do tego zobowiązane.

Kiedy to ma zastosowanie: data nie jest jeszcze ustalona

Nie ma jeszcze ustalonej daty wejścia w życie tych obowiązków dla półfabrykatów aluminium. Akt delegowany, który musi to konkretnie uregulować dla tej grupy produktów, jest zgodnie z planem pracy Komisji Europejskiej na lata 2025–2030 oczekiwany w 2027 roku. Dopiero wraz z tym aktem będzie jasne, które pola danych są obowiązkowe, w jakim formacie i jakie specyfikacje techniczne do wymiany — dlatego dopiero wtedy będzie precyzyjnie jasne, jak powiązanie z systemem ERP może wyglądać technicznie. Do tej pory ustalone jest, że artykuł 10 i artykuł 11 ESPR stanowią ogólne ramy: interoperacyjność i maszynowa czytelność są punktem wyjścia, konkretne wypełnienie techniczne nastąpi później. Gdy tylko akt delegowany zostanie opublikowany, oczekiwana data wejścia w życie zostanie tutaj uzupełniona.

Co to oznacza dla podejścia

Dla tych, którzy chcą już teraz się do tego przygotować, logiczna kolejność jest następująca: najpierw sporządzić przegląd danych dotyczących produktu aluminiowego, które znajdują się już we własnym systemie — skład, pochodzenie, dane partii, cechy techniczne. Następnie warto sprawdzić, czy dane te są dostępne w ustrukturyzowany, eksportowalny sposób (eksport do pliku, powiązanie poprzez interfejs) zamiast tylko na papierze lub rozproszone między kilka działów. Potem chodzi o dostosowanie do formatu, jaki wymaga platforma opracowująca paszport: alupas.eu opracowuje paszport na podstawie danych dostarczonych przez producenta lub importera, a sposób techniczny realizacji dostarczania — wpisanie ręczne, wysłanie pliku lub zautomatyzowane powiązanie — jest kwestią, która będzie uzgodniona z platformą, gdy tylko specyfikacje techniczne z aktu delegowanego będą znane. Przedsiębiorstwo, które już teraz na bieżąco przechowuje dane swojego produktu w przejrzysty i ustrukturyzowany sposób, będzie musiało później wykonać mniej pracy, aby dostarczyć te dane, niezależnie od tego, czy nastąpi to poprzez powiązanie ERP, czy inaczej.

Na czym to opiera się: artykuł 10 i 11 ESPR

Artykuł 10 ESPR opisuje wymogi, którym musi odpowiadać cyfrowy paszport produktu, w tym dostępność danych i połączenie z nośnikiem danych. Artykuł 11 dotyczy w szczególności projektowania technicznego i funkcjonowania systemu paszportów: sposób rejestracji, przechowywania i wymiany danych, mając na uwadze interoperacyjność między różnymi systemami i podmiotami w łańcuchu dostaw. Oba artykuły pozostawiają konkretne normy techniczne i formaty późniejszym przepisom wykonawczym; ustalają jednak zasadę, że paszport musi być czytelny maszynowo i niezależny od systemu, co stanowi podstawę dla każdego przyszłego połączenia z systemem zewnętrznym, takim jak pakiet ERP.

Kto chce teraz się przygotować, powinien uporządkować własne dane produktu w strukturyzowany i cyfrowy sposób, aby dostawa — w jakiejkolwiek formie — była później kwestią podłączenia zamiast ponownego konfigurowania.

Na czym to jest oparte

Samo rozporządzenie znajduje się na EUR-Lex. Powołujemy się na każde stwierdzenie; nie musisz nam ufać.

Co konkretnie musisz zrobić

Co się od ciebie oczekuje

Paszport musi być przesyłalny jako zestaw danych, nie tylko jako ekran

Artykuł 10 rozporządzenia ESPR (Rozporządzenie (UE) 2024/1781) opisuje cyfrowy paszport produktu jako zbiór danych czytelny i przesyłalny za pośrednictwem środków elektronicznych. Jest to inne wymaganie niż „ładna strona, która otwiera się po zeskanowaniu kodu QR". Dla przedsiębiorstwa zatrudniającego od 10 do 100 pracowników oznacza to, że dane zawarte w paszporcie muszą być dostępne również jako dane ustrukturyzowane — nie wyłącznie jako tekst na stronie internetowej. To, czy i w jaki sposób zostaną powiązane z własnym systemem ERP lub systemem magazynowym, to wybór dokonywany przez przedsiębiorstwo; przepisy nie nakazują powiązania, ale wymagają zestawu danych, który się do tego nadaje.

Interoperacyjność między systemami jest zasadą, a nie wyborem technicznym dostawcy

Artykuł 11 rozporządzenia ESPR dotyczy projektu technicznego i funkcjonowania cyfrowego paszportu produktu i wymienia interoperacyjność jako jedną z zasad, którym musi odpowiadać system paszportu. Bezpośrednio dotyczy to pytania, czy powiązanie z własnym systemem jest możliwe: paszport skonfigurowany zgodnie z tym artykułem jest z założenia przeznaczony do wymiany danych między systemami, a nie jako zamknięte środowisko. W praktyce przedsiębiorstwo zauważa to głównie w kontekście pytania, jakich formatów danych i kodów identyfikacyjnych używa platforma oraz czy są one zgodne z tym, co już stosuje własny system ERP.

Unikalny kod identyfikacyjny jest połączeniem między paszportem a własną administracją

Powiązanie między paszportem produktu a systemem wewnętrznym zależy od jednoznacznego kodu identyfikacyjnego dla każdego produktu lub partii. Bez jednoznacznego klucza powiązania powiązanie ERP w praktyce trudno jest zautomatyzować, chociaż nigdzie wprost w tekście artykułu 10 lub 11 się to nie pojawia. Jak ten kod identyfikacyjny jest budowany i przydzielany, opisano na stronie dotyczącej sposobu nadania każdemu produktowi unikalnego kodu identyfikacyjnego. Dla przedsiębiorstwa sprzedającego aluminium partiami jest to również związane z pytaniem, czy rejestracja odbywa się na poziomie partii czy poszczególnych sztuk, co jest bardziej szczegółowo opisane na stronie dotyczącej rejestracji partiowej lub indywidualnej.

Paszport pozostaje, nawet jeśli zmieni się system wewnętrzny

System ERP jest w pewnym momencie zastępowany, migrowany lub aktualizowany. Paszport produktu jako taki nie zmienia się automatycznie — jest hostowany przez dziesięć lat niezależnie od tego, co dzieje się wewnętrznie z administracją zapasów. To rozróżnienie jest istotne przy konfiguracji powiązania: powiązanie jest wygodą dla własnej działalności biznesowej, a nie zastępstwem dla obowiązku utrzymania dostępności paszportu. Więcej na temat okresu przechowywania znajduje się na stronie dotyczącej jak długo paszport musi pozostać dostępny.

Gdzie w praktyce się nie udaje

Kilka sytuacji pojawia się regularnie u przedsiębiorstw rozważających powiązanie między paszportem a własnym systemem:

System ERP jest postrzegany jako źródło, podczas gdy paszport powinien być źródłem. Po opublikowaniu danych paszport jest weryfikowalną prawdą dla świata zewnętrznego. Zmiany w systemie wewnętrznym nie przechodzą automatycznie, a kto to myli, ryzykuje, że paszport i własna administracja mogą się rozmijać.
Mutacje zapasów są mylone ze zmianami paszportu. System zapasów wewnętrznych zmienia się codziennie: ilości, lokalizacje, statusy partii. Paszport produktu rejestruje cechy produktu, a nie aktualną pozycję zapasów. Kto przeplata te dwa rodzaje danych w jednym powiązaniu, tworzy niepotrzebną złożoność — a czasem nieuzasadnione zmiany do paszportu, który został już opublikowany. Jak dokładnie ta zmiana po publikacji działa, opisano na stronie dotyczącej zmiana danych po publikacji.
Powiązanie jest budowane bez uwzględnienia kodu identyfikacyjnego platformy. Jeśli wewnętrzny numer artykułu nie odpowiada kodowi stosowanemu w paszporcie, powstaje ręczne tłumaczenie, które w praktyce w dużej mierze unieważnia powiązanie.
Zakłada się, że połączenie ERP zapewni również fizyczny kod QR na produkcie. To są dwa odrębne komponenty: połączenie danych reguluje wymianę informacji, a umieszczenie nośnika na samym aluminium jest oddzielnym procesem. W tej sprawie zobacz jak kod QR trafia na produkt.
Zakłada się, że własny system będzie generował „paszport Dopóki delegowany akt dotyczący aluminium nie zostanie opublikowany, nie jest ustalone, który format danych będzie dokładnie obowiązkowy. Połączenie może być przygotowywane, ale założenie, że własny system ERP będzie w przyszłości samodzielnie spełniać wszystkie wymagania, jest przedwczesne.

Co można dokumentować

Dla firm rozważających połączenie między paszportem produktu a własnym systemem praktyczne jest ustalenie poniższych punktów wewnętrznie — również jeśli połączenie nie będzie jeszcze budowane:

Które pola w systemie ERP lub magazynowym odpowiadają którym polom w paszporcie produktu, łącznie z wykorzystywanym kodem identyfikacyjnym na produkt lub partię.
Kto w przedsiębiorstwie jest odpowiedzialny za utrzymywanie aktualności danych, które są zarówno wykorzystywane wewnętrznie, jak i znajdują się w paszporcie.
Ustalenie dotyczące momentu, w którym dane z systemu wewnętrznego są przejmowane do paszportu, oraz momentu, w którym to wyraźnie nie następuje automatycznie.
Dokumentacja określająca, który system jest źródłem dla którego wariantu danych — aby w przypadku kontroli lub zapytania od odbiorcy było jasne, skąd pochodzi dana cyfra lub cecha.
Przegląd tego, czy paszport jest sporządzony na sztukę czy na partię, ponieważ to określa, jak najlepiej może być zorganizowane połączenie z liniami magazynowymi.

Te punkty nie ustalają wyniku i nie stanowią gwarancji, że połączenie będzie zgodne z wymogami technicznymi zawartymi w delegowanym akcie — tekst ten jeszcze nie istnieje. Zapewniają one jednak, że przedsiębiorstwo, gdy wymogi techniczne staną się konkretne, nie będzie musiało od zera ustalać, które dane należą gdzie.

To nie jest porada prawna. Ta strona zawiera ogólne informacje o przepisach, 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 za pomocą AI na podstawie powyższych źródeł, sprawdzone przez człowieka 2026-08-22. Coś nie gra? Powiadom nas — korekty mają pierwszeństwo.