i hvilket format skal jeg levere produktpasdata

Hvad du konkret skal gøre

Hvad der forventes af dig

Spørgsmålet om hvilket filformat der er obligatorisk — JSON, XML, PDF, en bestemt API-struktur — kommer til hver importør og producent, når IT-afdelingen begynder at bygge. Svaret på grundlag af den aktuelle ESPR-tekst er nuchter: et konkret filformat fremgår ikke af forordningen. Artikel 10 og artikel 11 i ESPR (Forordning (EU) 2024/1781) fastslår ganske vist krav til det digitale produktpas, men det sker på niveauet for funktionelle og tekniske krav, ikke på niveauet "brug JSON-LD" eller "indsend en XML-fil i henhold til dette skema". Denne udfyldning forventes via delegerede og gennemførelsesretsakter pr. produktgruppe.

Interoperabilitet står i centrum, ikke ét specifikt format

Artikel 10 i ESPR nævner interoperabilitet som et kernekrav: passet skal være struktureret således, at systemer fra forskellige parter — tilsynsmyndigheder, markedsaktører, forbrugere — kan læse data. For en virksomhed på 10 til 100 medarbejdere betyder det praktisk, at valget af et lager- og udvekslingsformat først med sikkerhed kan træffes, når den delegerede retsakt for egen produktkategori foreligger. Indtil da er det tilradeligt at arbejde med strukturerede data (tænk på felter i en database eller ERP-system) i stedet for kun at opbevare data i et løst dokument eller PDF, så en senere offentliggørelse i det endelige format kræver mindre efterbehandling.

Passet skal være læseligt via QR-databæreren

Artikel 11 i ESPR beskriver den tekniske funktionen af passet, herunder forbindelsen med databæreren på produktet. Det betyder, at de bagvedliggende data, uanset hvilket format, skal kunne frigøres på det tidspunkt, hvor nogen scanner koden. Hvordan denne forbindelse teknisk fungerer, og hvilke identificeringsstandarder der spiller en rolle herved, beskrives på siden om hvordan kommer QR-koden til produktpasset på min elektronikFor virksomheder, der allerede arbejder med GS1-stregkoder, er spørgsmålet om en eksisterende identificeringsstruktur kan genbruges relevant — dette emne vender tilbage på siden om hvad GS1 Digital Link er, og om det er nødvendigt for produktpasset.

Hvert produkt skal være entydigt identificerbart, uafhængigt af filformatet

Uanset hvilket teknisk format der senere bliver foreskrevet, er det underliggende krav, at hvert produkt får en unik identifikationskode. Det er et separat krav, der ikke ændres, hvis filformatet senere bliver fastlagt. Virksomheder, der allerede nu begynder at strukturere deres produktdata, gør klogt i at medtage denne identifikation som en fast del. Hvordan det i praksis bliver opbygget, er forklaret på siden om hvordan du giver hvert produkt en unik identifikationskode.

Levering til registret kræver sin egen form

Artikel 13 i ESPR introducerer registret over digitale produktpasporter, hvori visse oplysninger om paspporten optages. Her er der heller ikke fastlagt, i hvilket nøjagtigt filformat denne levering skal finde sted — det vil blive nærmere præciseret. Det er dog klart, at dette register er en separat leveringsstrøm ved siden af paspporten, der er tilgængelig via QR-koden. Mere om, hvad der skal indgå heri, står på siden om hvad det europæiske register over digitale produktpasporter er, og hvad der skal være i det.

Hvor det går galt i praksis

For tidlig fastlæggelse i et stift format. Nogle virksomheder lader nu allerede et PDF-pasport bygge, fordi det er hurtigt og genkendelig, mens det endelige krav sandsynligvis kræver strukturerede, maskinelæsbare data. En PDF er mennesker-læsbar, men ikke automatisk egnet til den interoperabilitet, som artikel 10 i ESPR har til formål.

Data spredt over flere systemer uden forbindelse. Produktoplysninger er ofte delvist i ERP-systemet, delvist i marketingdokumenter, delvist hos en ekstern leverandør. Uden en plan for at samle dette, bliver det vanskeligt at skifte hurtigt ud, når det obligatoriske format bliver kendt. Virksomheder, der overvejer at lade deres eget system deltage, finder mere om mulighederne på siden om at koppel produktpaspporten til et eget ERP- eller lagersystem.

Forvirring mellem selve paspporten og registret. Paspporten, der kan konsulteres via QR-koden, og de oplysninger, der indgår i registret, er ikke automatisk identiske i form eller format. At antage, at en fil er tilstrækkelig til begge formål, er en risiko, der først bliver synlig, når udførelseshandlingerne bliver konkrete.

Ingen hensyntagen til flere produktniveauer. For produkter, der sælges i sammensatte emballager, eller hvor et apparat består af flere dele med deres eget pasport, er spørgsmålet om, hvordan dataformaterne hænger sammen, endnu mere komplekst. Dette spiller f.eks. ind ved en æske med flere apparater i og ved produkter, der har brug for flere produktpasporter.

Utilstrækkelig opmærksomhed på læsbarheden på længere sigt. Et filformat, der er almindeligt nu, behøver ikke at blive det over en længere periode. Fordi paspporten skal være tilgængelig i en bestemt periode, er valget af format også et spørgsmål om holdbarhed — se forklaringen om hvor længe et produktpas skal forblive tilgængeligt.

Hvad du kan dokumentere

• Et oversigt over, hvor produktdata allerede nu registreres (ERP, PIM, regneark, leverandørdokumenter) og i hvilket format.
• En liste over obligatoriske datakilder pr. produktkategori, så snart den delegerede handling for den pågældende kategori er offentliggjort.
• Aftaler med leverandører og underleverandører om det format, hvori de leverer deres produktdata, så tilslutning senere bliver lettere.
• En intern ansvarlig eller team, der følger udviklingen af de tekniske standarder, da artikel 11 i ESPR vil få nærmere specifikationer herom.
• Dokumentation af den valgte identifikationsmetode pr. produkt, også uafhængigt af det endelige filformat.
• Et oversigt over kravene til hosting og tilgængelighed, der sammen med formatet bestemmer, hvordan paspporten teknisk bliver sat op — se siden om hvilke hosting-krav gælder.