Kan jeg knytte produktpasset til mit ERP- eller lagersystem?

Kobling er mulig, formen er ikke fastsat i lovgivningen

Ja, et digitalt produktpas kan i praksis kobbles til et ERP- eller lagersystem, men ESPR foreskriver ikke, hvordan denne kobling skal se ud. Forordningen stiller dog krav til selve passet: det skal være teknisk opbygget således, at data er maskinlæsbar, og at systemer automatisk kan læse og behandle dem på grundlag af åbne standarder i stedet for lukkede, mærkebundne formater (artikel 11 i ESPR, Forordning (EU) 2024/1781). Dette krav er rettet mod passet og databæreren, ikke mod de interne systemer hos en bandimportør, großhandel eller wagenparkforvaltning. Om og hvordan en kobling til en specifik ERP-pakke fungerer, er således et spørgsmål om teknisk indretning hos den part, der sammensætter og hoster passet — i dette tilfælde en platform som tyrepas.eu — og ikke noget, som loven regulerer helt ned i detaljer.

For hvem dette er relevant, og for hvem det ikke er

Dette spørgsmål er især relevant for parter, der behandler store mængder bander, og hvor produktdata allerede findes et sted i et system: importører, der administrerer varenumre, partidata og tekniske specifikationer, großhandler, der fører lager over bandtype, og wagenparkforvaltninger, der kobbler bander til køretøjer. For dem er en kobling især praktisk: data skal ikke indtastes dobbelt, og pasoplysninger kan flyde tilbage til eget system.

For slutbrugere, der kun køber et band og scanner QR-koden, spiller kobling til et ERP-system ingen rolle — de læser passet, de fodrer det ikke. Og for mindre parter uden eget system er kobling heller ikke relevant: passet kan lige så godt leveres og konsulteres manuelt uden, at det påvirker dets gyldighed. De tekniske krav i artikel 11 omhandler desuden selve passet som sådan, ikke spørgsmålet om, hvorvidt en leverandør af pasprodukter skal tilbyde en specifik kobling til et bestemt ERP-mærke.

Endnu ingen fast dato, men en klar arbejdsgang

Hvornår forpligtelsen til et digitalt produktpas for bander træder i kraft, er endnu ikke fastsat. I ESPR's arbejdsplan for perioden 2025-2030 forventes en delegeret handling for bander i 2027; først med offentliggørelsen heraf bliver en konkret ikrafttrædelsesdato kendt. Indtil da gælder der ingen bindende krav til selve passet for bander, og således heller ikke til den måde, hvorpå data leveres eller udveksles.

Det betyder ikke, at der intet at gøre er. De almene krav i artikel 10 og artikel 11 i ESPR ligger allerede fast som rammen, inden for hvilken den delegerede handling for bander udfyldes nærmere: maskinlæsbarhed, åbne standarder og interoperabilitet er ikke noget nyt, der dukker op i 2027, men fundamentet, hvorpå de bandespecifikke regler er bygget. Den, der nu tænker på en kobling, bygger således ikke på dybt vand, selvom den definitive dato stadig mangler.

Hvordan dette håndteres i praksis

Det første skridt er at afgøre, hvilke data, der allerede findes i ERP- eller lagersystemet, som senere skal fremgå af et pas: varenummer, parti- eller batchdata, produktionsdato, tekniske specifikationer pr. bandtype. Mange af disse data findes allerede, de er blot endnu ikke struktureret til et pas.

Det andet skridt er at finde ud af, hvilket format den part, der sammensætter og hoster passet, accepterer som input. Fordi tyrepas.eu opbygger passet ud fra data fra fabrikanten eller importøren, er det praktiske spørgsmål ikke så meget om kobling kan lade sig gøre, men i hvilken form datalevering forløber mest hensigtsmæssigt: en periodisk eksport fra ERP-systemet, en struktureret fil eller en anden leveringsrute.

Det tredje trin er at tænke på den anden retning: tilbageføring af pasportdata til dit eget system, for eksempel så en flådeadministrator kan knytte pasportinformationer til en køretøjsregistrering uden selv at skulle søge paspoorten via QR-koden. Dette er også et spørgsmål om teknisk koordinering mellem ERP-systemet og platformen, ikke om en juridisk forpligtelse.

Endelig er det vigtigt at tage hensyn til varigheden: et pas bliver hostet i en periode på ti år. Den, der etablerer en forbindelse, gør klogt i også at tænke på opdateringer i løbet af denne periode — for eksempel når produktdata ændres — så forbindelsen ikke kun fungerer ved den første levering, men også ved senere ændringer.

Det juridiske grundlag: artikel 10 og 11 i ESPR

Kravene til selve det digitale produktpas er fastsat i artikel 10 i ESPR (Europa-Parlamentets og Rådsforordning (EU) 2024/1781), som fastlægger de generelle krav til paspoorten. Artikel 11 i samme forordning omhandler specifikt det tekniske design og funktionen af paspoorten med vægt på interoperabilitet og åbne standarder, så data kan læses og udveksles maskinelt. Begge artikler vedrører paspoorten som produkt, ikke importørernes, distributørernes eller flådeadministratorernes interne informationssystemer — forbindelsen til disse er en teknisk gennemførelse, der kommer oven i købet.

Den, der allerede nu vil være forberedt, kan bedst begynde med at kortlægge sine egne produktdata og kontakte den part, der skal sammensætte og hoste paspoorten for dæk, for at drøfte, hvilken leveringsrute der bedst passer til det eksisterende ERP- eller lagersystem.

Where this is based on

The regulation itself is on EUR-Lex. We refer per claim; you do not have to believe us.

Hvad du konkret skal gøre

Hvad der forventes af dig

Passet skal kunne modtage data fra et kildesystem

Et produktpasport bliver ikke skrevet manuelt ind i en løs formular — dataene kommer fra et eller andet sted: fra et ERP-system, en lagerstyringspakke, en Excel-eksport fra producenten eller en kombination deraf. Artikel 10 i ESPR (Forordning (EU) 2024/1781) stiller krav til, hvilke data der skal være i passet, og hvordan de er tilgængelige, men foreskriver ikke, via hvilket system en virksomhed leverer disse data. For en dæktimportør eller en grossist med 10 til 100 medarbejdere betyder det i praksis, at der skal være en fast, gentagelig måde at få produktdata fra eget system til passet på — ikke en engangsindtastning, der skal genopfindes ved næste dækparti.

Koblingen skal passe til en entydig identifikationskode pr. produkt

Artikel 11 i ESPR beskriver, hvordan det digitale produktpasport skal fungere teknisk, herunder koblingen mellem et produkt og dets pasport via en identifikationskode. Et ERP- eller lagersystem arbejder normalt med egne artikelnumre, SKU'er eller interne koder. For koblingen til passet skal denne interne kode stemme overens med eller oversættes til den identifikationskode, som passet bruger. Virksomheder, der allerede fører en klar, entydig kode pr. dækstørrelse eller pr. batch i deres lagersystem, har en fordel her; virksomheder, der arbejder med samlede poster eller generelle modelnavne, opdager ofte først ved koblingen, at deres interne administration ikke er detaljeret nok. Mere om dette grundlæggende trin findes på hvordan giver jeg hvert produkt en unik identifikationskode?

Ændringer i kildesystemet skal afspejles i passet

Et lagersystem er aldrig statisk: priser ændres, specifikationer opdateres, en leverandør ændrer en sammensætning. Artikel 10 bygger på, at et pasport afspejler den aktuelle situation, for så vidt den pågældende datakategori kræver det. For en virksomhed betyder det, at en kobling med eget system ikke kun skal virke ved første indlæsning, men også ved senere ændringer — ellers opstår der et pasport, der var korrekt på tidspunktet for offentliggørelse, men ikke længere er det.

Koblingen skal kunne spores tilbage til kilden

Et pasport, der viser data uden at det stadig er muligt at spore, hvilket system, hvilken eksport eller hvilken version disse data kommer fra, er svært at retfærdiggøre ved en kontrol. Dette følger ikke af en særlig artikel, men af den praktiske side af artikel 10 og 11 sammen: data skal være korrekte OG kontrollerbare. For virksomheder med en kobling til deres ERP betyder det, at en form for logning eller versionsstyring er ønskelig — hvornår er hvilket datasæt overført, og af hvem.

Hvor det går galt i praksis

En grossist kobler lagerstyring-modulet fra ERP-systemet en gang til passet ved lancering, men glemmer, at nye dækstørrelser, der tilføjes senere, ikke automatisk medtages — passet bliver hængende på sortimentet fra startdatoen.

En importør bruger i ERP-systemet en samlet kode for en hele produktlinje ("175/65R14 sommerdæk, forskellige mærker"), mens passet skal virke pr. entydig identifikationskode. Koblingen giver så ét pasport for produkter, der egentlig hver skal have sit eget pasport — se også hvordan forholder dækkenes størrelse sig til den unikke identifikationskode?

En wagenparkforvalter modtager en eksport fra producenten i et format, der ikke svarer til eget lagersystem, og dataene bliver manuelt omskrevet til en mellem-fil. Ved næste levering opdateres denne mellem-fil ikke, så passet viser en ældre version af specifikationerne end det, der faktisk ligger på lageret.

En virksomhed kobler ERP-systemet direkte til passet uden mellemled, og en fejl i et eksportfelt (f.eks. en forvekslet kolonne med dækstørrelser) kommer umarkeret ind i flere pasporter, fordi ingen kontrollerer de koblede data efter overførsel.

En importør tror, at en enkelt kobling er tilstrækkelig for alle fremtidige varianter af en model, mens der faktisk kræves separate data for hver størrelse eller udførelse — spørgsmålet om, hvorvidt data må genbruges til forskellige dækstørrelser af samme model, kommer så for sent på dagsordenen, se kan jeg bruge de samme data til flere dækstørrelser af samme model?

Det du kan dokumentere

Et overblik over hvilket system (ERP, lagerstyring, leverandørportal) som er kilden til hvilket datafeld i passet, så det ved et spørgsmål eller kontrol straks er klart, hvor et tal eller en specifikation kommer fra.
En fast procedure for overføring af data ved nye produkter, herunder det tidspunkt, hvor den unikke identifikationskode tildeles og kobles.
En aftale om, hvem der er ansvarlig for at opdatere passet, når data i kildesystemet ændres — og inden for hvilken arbejdsgange det sker.
Et kontroltrin efter hver kobling eller eksport, hvor der stikprøvevis kontrolleres, om dataene i passet stemmer overens med kildesystemet.
En logbog eller versionhistorie over, hvad der blev overført og hvornår, så en ændring senere kan spores.
Dokumentation af selve den tekniske kobling (hvilke eksportformater, hvilke felter der mappes, hvilken software eller mellemlag der bruges), som kan bruges som vedhæftning ved interne revisioner.

For virksomheder, der stadig skal afgøre, om deres dæk overhovedet falder under denne forpligtelse, er det et logisk tidligere trin — se gælder det digitale produktpaspoort for mine dæk? Virksomheder, der gerne vil vide mere om passets rolle i kæden som helhed, og hvor koblingen med deres eget system passer ind, finder en generel forklaring i hvad er et digitalt produktpasport til dæk?

This is not legal advice. This page provides general information about the regulations that this platform deals with. We do not know your situation. If in doubt about your own case, please consult a lawyer or the competent supervisory authority.

Written with AI based on the sources above, checked by a human on 2026-08-22. Is something wrong? Let us know — corrections take priority.