Czy mogę połączyć paszport produktu z moim systemem ERP lub zarządzania zapasami?

Połączenie jest możliwe, forma nie jest określona w prawie

Tak, cyfrowy paszport produktu można w praktyce połączyć z systemem ERP lub magazynowym, jednak ESPR nie określa, jak to połączenie powinno wyglądać. Rozporządzenie stawia jednak wymagania dla samego paszportu: musi być techniczne skonstruowany w taki sposób, aby dane były czytelne maszynowo i aby systemy mogły je automatycznie odczytywać i przetwarzać, w oparciu o otwarte standardy zamiast zamkniętych formatów powiązanych z marką (artykuł 11 ESPR, Rozporządzenie (UE) 2024/1781). Wymóg ten jest skierowany do paszportu i nośnika danych, a nie do wewnętrznych systemów importera opon, hurtowni lub kierownika floty. To, czy i jak połączenie z konkretnym pakietem ERP działa, jest zatem kwestią ustrojenia technicznego strony opracowującej i hostującej paszport — w tym przypadku platformy takiej jak tyrepas.eu — a nie czymś, co prawo reguluje szczegółowo.

Dla kogo jest to istotne i dla kogo nie

To pytanie dotyczy przede wszystkim stron przetwarzających duże ilości opon, u których dane produktu już znajdują się w jakimś systemie: importerów zarządzających numerami artykułów, danymi partii i specyfikacjami technicznymi, hurtowni prowadzących zapasy dla typu opony oraz kierowników flot kojarzących opony z pojazadami. Dla nich połączenie jest przede wszystkim praktyczne: dane nie muszą być wprowadzane dwukrotnie, a informacje z paszportu mogą powrócić do własnego systemu.

Dla użytkowników końcowych, którzy jedynie kupują oponę i skanują kod QR, połączenie z systemem ERP nie ma znaczenia — czytają paszport, nie wprowadzają go. A dla mniejszych stron bez własnego systemu połączenie również nie wchodzi w grę: paszport można wówczas równie dobrze dostarczyć ręcznie i zapoznać się z nim, bez wpływu na jego ważność. Wymagania techniczne z artykułu 11 dotyczą poza tym samego paszportu, a nie pytania, czy dostawca usług paszportowych powinien oferować określone połączenie z konkretną marką ERP.

Brak stałej daty, ale jasna ścieżka działań

Data, kiedy obowiązek cyfrowego paszportu produktu dla opon dokładnie wchodzi w życie, nie jest jeszcze ustalona. W planie działań ESPR na okres 2025-2030 przewiduje się uaktualnioną ustawę delegowaną dla opon w 2027 r.; konkretna data wejścia w życie będzie znana dopiero po jej opublikowaniu. Do tego czasu dla opon nie obowiązują żadne obowiązkowe wymagania dotyczące samego paszportu, a zatem również nie sposobu, w jaki dane są dostarczane lub wymieniane.

To nie oznacza, że nie ma nic do robienia. Ogólne wymagania z artykułu 10 i artykułu 11 ESPR są już ustaleni jako ramy, w ramach których uaktualniona ustawa delegowana dla opon będzie dalej rozwijana: czytelność maszynowa, otwarte standardy i interoperacyjność nie są nowym wynalazkiem, który pojawi się dopiero w 2027 r., ale fundamentem, na którym buduje się reguły specyficzne dla opon. Kto już teraz zastanawia się nad połączeniem, nie buduje na ruchomych piaskach, chociaż brakuje jeszcze ostatecznej daty.

Jak to wygląda w praktyce

Pierwszym krokiem jest sprawdzenie, które dane już znajdują się w systemie ERP lub magazynowym, które będą musiały pojawić się w paszporcie: numer artykułu, dane partii lub partii, data produkcji, specyfikacje techniczne dla typu opony. Wiele z tych danych już istnieje, tylko że nie są jeszcze ustrukturyzowane dla paszportu.

Drugi krok to sprawdzenie, jaki format strona opracowująca i hostująca paszport akceptuje jako dane wejściowe. Ponieważ tyrepas.eu buduje paszport z danych producenta lub importera, pytanie praktyczne nie tyle dotyczy tego, czy połączenie jest możliwe, ale w jaki sposób dostarczanie danych przebiega najwygodniej: okresowy eksport z systemu ERP, plik ustrukturyzowany, czy inna ścieżka dostarczania.

Trzeci etap to zastanowienie się nad innym kierunkiem: odesłanie danych paszportu z powrotem do własnego systemu, na przykład aby manager floty pojazdów mógł powiązać informacje z paszportu z rejestracją pojazdu bez konieczności samodzielnego wyszukiwania paszportu za pośrednictwem kodu QR. To również kwestia technicznego dostosowania między systemem ERP a platformą, a nie obowiązek ustawowy.

Wreszcie ważne jest uwzględnienie okresu obowiązywania: paszport jest hostowany przez okres dziesięciu lat. Ktoś, kto ustanawia powiązanie, powinien również zastanowić się nad aktualizacjami w tym okresie — na przykład gdy dane produktu ulegną zmianie — aby powiązanie działało nie tylko przy pierwszym dostarczeniu, ale również przy późniejszych zmianach.

Podstawa prawna: artykuł 10 i 11 ESPR

Wymogi dotyczące samego cyfrowego paszportu produktu zawarte są w artykule 10 rozporządzenia ESPR (Rozporządzenie (UE) 2024/1781), który określa ogólne wymogi dotyczące paszportu. Artykuł 11 tego samego rozporządzenia odnosi się konkretnie do projektu technicznego i działania paszportu, ze szczególnym naciskiem na interoperacyjność i otwarte standardy, aby dane były czytelne maszynowo i wymienne. Oba artykuły odnoszą się do paszportu jako produktu, a nie do wewnętrznych systemów informacyjnych importerów, hurtowników lub menedżerów flot pojazdów — powiązanie z nimi stanowi wykonanie techniczne, które się do tego dołącza.

Jeśli ktoś chce teraz się przygotować, najlepiej jest zacząć od zmapowania własnych danych produktu i skontaktowania się z podmiotem, który będzie składać i hostować paszport dla opon, aby omówić, która trasa dostarczenia najlepiej pasuje do istniejącego systemu ERP lub magazynowego.

Na czym się to opiera

Samo rozporządzenie dostępne jest na EUR-Lex. Powołujemy się dla każdego stwierdzenia; nie musisz nam wierzyć.

Co konkretnie musisz zrobić

Co się od Ciebie oczekuje

Paszport musi być w stanie odbierać dane ze źródłowego systemu

Paszport produktu nie jest wpisywany ręcznie w oddzielny formularz — dane pochodzą skądś: z systemu ERP, pakietu do zarządzania zapasami, eksportu Excel od producenta lub ich kombinacji. Artykuł 10 rozporządzenia ESPR (Rozporządzenie (UE) 2024/1781) określa wymogi dotyczące danych, które muszą się znaleźć w paszporcie i jak są dostępne, ale nie przewiduje drogi, za pośrednictwem której przedsiębiorstwo dostarcza te dane. W praktyce dla importera opon lub hurtownika zatrudniającego od 10 do 100 pracowników oznacza to, że musi istnieć stały, powtarzalny sposób, aby produkty dane z własnego systemu trafiły do paszportu — a nie jednorazowe ręczne wprowadzenie, które przy kolejnej partii opon trzeba będzie wymyślić na nowo.

Połączenie musi odpowiadać unikalnemu kodowi identyfikacyjnemu produktu

Artykuł 11 rozporządzenia ESPR opisuje, w jaki sposób cyfrowy paszport produktu powinien funkcjonować technicznie, w tym połączenie między produktem a jego paszportem za pośrednictwem kodu identyfikacyjnego. System ERP lub zarządzania zapasami zwykle działa z własnymi numerami artykułów, jednostkowymi kodami lub kodami wewnętrznymi. Aby połączyć się z paszportem, ten kod wewnętrzny musi być zgodny z kodem identyfikacyjnym używanym przez paszport lub musi być do niego przetłumaczony. Przedsiębiorstwa, które już prowadzą jasny, unikalny kod dla każdego rozmiaru opony lub każdej partii w swoim systemie zarządzania zapasami, mają tu przewagę; przedsiębiorstwa pracujące z pozycjami zbiorczymi lub ogólnymi nazwami modeli często odkrywają dopiero podczas połączenia, że ich administracja wewnętrzna nie jest wystarczająco szczegółowa. Więcej informacji na temat tego kroku podstawowego znajduje się w jak przydzielić każdemu produktowi unikalny kod identyfikacyjny?

Zmiany w systemie źródłowym muszą odzwierciedlić się w paszporcie

System zarządzania zapasami nigdy nie jest statyczny: ceny się zmieniają, specyfikacje są aktualizowane, dostawca zmienia skład. Artykuł 10 wychodzi z założenia paszportu, który odzwierciedla aktualny stan rzeczy, o ile kategoria danych to wymaga. Dla przedsiębiorstwa oznacza to, że połączenie z własnym systemem musi działać nie tylko przy pierwszym wprowadzeniu, ale także przy późniejszych zmianach — w przeciwnym razie powstaje paszport, który był dokładny w momencie publikacji, ale teraz już nie jest.

Połączenie musi być możliwe do prześledzenia do źródła

Paszport pokazujący dane bez możliwości ustalenia, z którego systemu, którego eksportu lub której wersji te dane pochodzą, jest trudny do uzasadnienia podczas kontroli. Nie wynika to z żadnego konkretnego artykułu, ale z praktycznego aspektu artykułów 10 i 11 razem: dane muszą być poprawne I możliwe do weryfikacji. Dla przedsiębiorstw z połączeniem do ich systemu ERP oznacza to, że pożądana jest jakaś forma rejestrowania lub zarządzania wersjami — kiedy został przesłany jaki zestaw danych i przez kogo.

Gdzie psuje się to w praktyce

Hurtownia połączy moduł zarządzania zapasami systemu ERP jeden raz z paszportem podczas uruchomienia, ale zapomni, że nowe rozmiary opon dodane później nie będą automatycznie uwzględniane — paszport pozostaje zafiksowany na asortymencie z daty rozpoczęcia.

Importer używa w systemie ERP kodu zbiorczego dla całej linii produktów ("175/65R14 opona letnia, różne marki"), podczas gdy paszport musi działać z unikatowym kodem identyfikacyjnym dla każdego produktu. Połączenie tworzy wtedy jeden paszport dla produktów, które w rzeczywistości powinny mieć każdy swój własny paszport — patrz również jak rozmiar opony odnosi się do unikalnego kodu identyfikacyjnego?

Kierownik floty pojazdów otrzymuje eksport od producenta w formacie, który nie odpowiada własnemu systemowi zarządzania zapasami, i dane są ręcznie przepisywane do pliku pośredniego. Przy następnej dostawie ten plik pośredni nie jest aktualizowany, w wyniku czego paszport pokazuje starszą wersję specyfikacji niż ta, która faktycznie znajduje się w magazynie.

Przedsiębiorstwo połącza system ERP bezpośrednio z paszportem bez etapu pośredniego, a błąd w polu eksportu (na przykład zamieniona kolumna z rozmiarami opon) trafia niezauważony do wielu paszportów, ponieważ nikt nie weryfikuje połączonych danych po przesłaniu.

Importer uważa, że jedno sprzęgnięcie wystarczy dla wszystkich przyszłych wariantów modelu, podczas gdy w rzeczywistości dla każdego rozmiaru lub wersji potrzebne są oddzielne dane — pytanie, czy dane mogą być ponownie wykorzystane dla różnych rozmiarów opon tego samego modelu, pojawia się zbyt późno, patrz czy mogę użyć tych samych danych dla wielu rozmiarów opon tego samego modelu?

Co można teraz ustalić

Przegląd tego, który system (ERP, zarządzanie zapasami, portal dostawcy) jest źródłem dla którego pola danych w paszporcie, aby w razie pytania lub kontroli było od razu jasne, skąd pochodzi liczba lub specyfikacja.
Stała procedura transferu danych dla nowych produktów, w tym moment, w którym przydzielany i sprzęgany jest unikalny kod identyfikacyjny.
Umowa o tym, kto odpowiada za aktualizację paszportu, gdy dane w systemie źródłowym się zmienią — i w ramach którego procesu roboczego to się odbywa.
Krok kontrolny po każdym sprzęgnięciu lub eksporcie, w którym poprzez próbę losową sprawdzane jest, czy dane w paszporcie są zgodne z systemem źródłowym.
Dziennik lub historia wersji tego, co zostało przesłane i kiedy, aby zmiana była później możliwa do wyśledzenia.
Dokumentacja samego sprzęgnięcia technicznego (jakie formaty eksportu, które pola są mapowane, jakie oprogramowanie lub warstwa pośrednia jest używana), przydatna jako załącznik do wewnętrznych audytów.

Dla firm, które dopiero muszą ustalić, czy ich opony w ogóle podlegają temu obowiązkowi, jest to logiczny wcześniejszy krok — patrz czy cyfrowy paszport produktu dotyczy moich opon? Ci, którzy chcą wiedzieć więcej o roli paszportu w całym łańcuchu i gdzie sprzęgnięcie z własnym systemem się w to wpisuje, znajdą wyjaśnienie ogólne w czym jest cyfrowy paszport produktu dla opon?

To nie jest porrada prawna. Ta strona zawiera ogólne informacje na temat rozporządzenia, na którym opiera się ta platforma. Nie znamy Twojej sytuacji. W razie wątpliwości dotyczących Twojego konkretnego przypadku konsultuj się z prawnikiem lub właściwym organem nadzoru.

Napisane przy użyciu AI na podstawie powyższych źródeł, sprawdzone przez człowieka na 2026-08-22. Coś nie gra? Daj nam znać — korekty mają priorytet.