kan jeg bruge min eksisterende produktdatabase til produktpasset

Ja, som kilde — men ikke som pas selv

En eksisterende produktdatabase kan normalt tjene som kilde for de data, der skal ind i et digitalt produktpas, men databasen selv er ikke et produktpas. Produktpas'et er et specifikt dataformat, der er knyttet til en unik bærer (normalt en QR-kode) pr. produkt eller produktmodel, med faste krav til struktur, tilgængelighed og integration med andre systemer som f.eks. EU-registreringsregisteret. De oplysninger, der allerede er i et ERP-system, PIM-system eller Excel-liste — materialer, dimensioner, artikelnumre, leverandør, sammensætning — er præcis den slags data, der senere skal være i et pas. Disse data behøver derfor ikke at blive indsamlet på ny, men de skal konverteres til det rigtige format og knyttes til den rigtige bærer.

For hvilke data dette virker, og for hvilke det ikke gør

Data, der er faste pr. produkt eller produktmodel — såsom materialesammensætning, oprindelse, dimensioner, garantiinformation eller vedligeholdelsesinstruktioner — egner sig godt til genbrug fra en eksisterende database. Disse data er en del af det, som artikel 9 i ESPR (Forordning (EU) 2024/1781) beskriver som kernen i det digitale produktpas: information, der skal være tilgængelig pr. produkt via en databærer. Hvor en eksisterende database ofte ikke finder svar, er den tekniske struktur, som artikel 10 i ESPR foreskriver: et unikt produktidentifikationsnummer, en forbindelse til registreringsregisteret, og et format, der kan læses på ensartet måde af markedsaktører, tilsynsmyndigheder og forbrugere. En intern database er normalt indrettet til eget virksomhedsdrift — lagerbehandling, ordrebehandling — og ikke til ekstern, standardiseret læsning som foreskrevet i artikel 11 i ESPR for pas'ets tekniske funktion. Det er forskellen mellem "dataene findes allerede" og "pas'et findes allerede": det første er ofte tilfældet, det sidste sjældent.

Hvornår dette bliver relevant

Spørgsmålet om, hvorvidt en eksisterende database er egnet, bliver først konkret, når forpligtelsen for møbler træder i kraft, og det tidspunkt ligger endnu ikke fast. Som også er forklaret på siden om hvornår produktpasset bliver obligatorisk for møbler er den delegerede handling for møbler endnu ikke offentliggjort; den afgør først præcis hvilke data, der er obligatoriske, og hvilket format, der hører til. Indtil da er der ingen juridisk forpligtelse til at føre et pas, men det betyder ikke, at at vente er den eneste mulighed. Det, der indtil da allerede står fast, er den generelle struktur fra selve ESPR — artikel 9, 10 og 11 — som tegner rammen for, hvorindenfor den delegerede handling for møbler senere skal udfyldes.

Sådan skal det håndteres i praksis

Det første skridt er at kontrollere, hvilke data, der allerede foreligger, og hvor: materialesammensætning, oprindelse, dimensioner, og evt. allerede eksisterende certificeringer eller testrapporter. Mange af disse oplysninger ligger ofte spredt over forskellige systemer — et ERP for lager, et PIM for produktinformation, løse dokumenter for certificeringer. Et andet skridt er at vurdere, om disse data er konsistente og aktuelle på produktmodelniveau, fordi pas'et kræver entydig information pr. produkt, ikke pr. ordre eller pr. batch. Et tredje skridt er at kontrollere, hvilke data, der mangler; det er ofte netop de data, der bliver bedt om specifikt til pas'et, såsom reparations- eller demonteringsoplysninger, og som normalt ikke er standard i et salgs- eller lagersystem. For dem, der gerne vil sætte gang i det nu, selv uden at de præcise krav ligger fast, beskriver siden om hvad du allerede kan gøre, mens reglerne endnu ikke er definitive flere forberedende trin, der kan tages uden risiko. For et overblik over fremgangsmåden i rækkefølge, fra dataindsamling til anbringelse af databærer, se siden om produktpas'et trin for trin en logisk fortsættelse.

Et opmærksomhedspunkt ved samlinger med mange varianter — farver, betjening, bentyper — er at en eksisterende database ofte administrerer disse varianter som separate SKU'er uden et delt grundlag. Pasporet kræver netop en klar forbindelse mellem det, der er delt inden for en samling, og det, der adskiller sig per variant, noget som får særlig opmærksomhed på siden om oprettelse af pas til en samling med mange farve- og stofvarianter.

Det juridiske grundlag: artikel 9, 10 og 11 i ESPR

Artikel 9 i ESPR (forordning (EU) 2024/1781) fastslår, at et produkt med et digitalt pas skal forsynes med en datadrager, hvorigennem oplysninger om produktet er tilgængelige. Artikel 10 beskriver de materielle krav, som disse oplysninger skal opfylde, herunder koblingen til et unikt identifikationsnummer og registreringsregisteret. Artikel 11 handler om den tekniske drift: hvordan pasporet skal være læseligt og udvekslingsbart mellem forskellige parter i kæden. Samlet set fastslår disse artikler, at et produktpas ikke blot er en database med produktoplysninger, men et særligt udformet lag derovenpå — bygget på data, der ofte allerede eksisterer, men suppleret og struktureret efter krav, der stadig skal fastlægges pr. produktgruppe.

Den, der nu gerne vil afgøre, om egne møbler senere vil være omfattet af denne forpligtelse, kan teste det på siden om hvorvidt det digitale produktpas gælder for specifikke møbler, og den, der først ønsker at vide, hvad et produktpas materielt set helt præcis er, finder det på siden om hvad et digitalt produktpas for møbler er. Det mest praktiske trin nu er: at inventarisere og ordne eksisterende produktdata pr. produktmodel, så tillægget senere kan begrænses til det, der rent faktisk mangler.

Hvad dette er baseret på

Forordningen selv er tilgængelig på EUR-Lex. Vi henviser pr. påstand; du behøver ikke tro os.

Hvad du konkret skal gøre

Hvad der forventes af dig

Mange virksomheder med 10 til 100 medarbejdere har allerede en produktdatabase: et ERP-system, et PIM-system eller simpelthen et omfattende Excel-ark med artikelnumre, materialer, dimensioner og leverandørdata. Spørgsmålet er ikke, om den database er brugbar, men om dataene i den opfylder det, som ESPR forventer af et digitalt produktpas. Det er to forskellige ting.

Indholdet skal stemme overens med det, som den delegerede retsakt forlanger

Artikel 9 i ESPR (forordning (EU) 2024/1781) beskriver det digitale produktpas som en samling produktoplysninger, der er tilgængelige via en datadrager. Præcis hvilken information det skal være, fastsættes pr. produktgruppe i en delegeret retsakt. For møbler er den endnu ikke offentliggjort. I praksis betyder det, at en eksisterende database ofte indeholder en del af de ønskede data — materialsammensætning, oprindelse, dimensioner — men sjældent alt. Reparationsoplysninger, genbrugsinstruktioner eller data om genanvendelighed findes typisk ikke som standard i et ERP-system, der er indrettet til lagerledelse og fakturering.

Dataene skal strukturelt kunne knyttes til en datadrager

Artikel 11 i ESPR stiller krav til det tekniske design: pasporet skal være tilgængeligt via en datadrager (såsom en QR-kode), og dataene skal tilbydes på en struktureret, maskinelt læsbar måde. En database, der kun bruges internt og ikke er indrettet til at etablere en unik, varig forbindelse per produkteksemplar eller -model med en datadrager, opfylder det ikke automatisk. For en virksomhed af denne størrelse betyder det typisk, at der er behov for et ekstra lag mellem den eksisterende database og omverdenen: et system, der henter de rigtige data fra databasen, strukturerer dem korrekt, og knytter dem til en QR-kode, der forbliver tilgængelig i ti år.

Tilgængeligheden skal opfylde kravene i artikel 10

Artikel 10 i ESPR omhandler, hvem der må se hvilke data, og hvor længe disse skal være tilgængelige. En intern database er normalt ikke indrettet til offentlig eller delvis offentlig tilgængelighed, endsige til en opbevaringsperiode, der er uafhængig af, om virksomheden selv stadig eksisterer. Det kræver en separat løsning ved siden af den eksisterende database, ikke en erstatning for den.

Hvor det går galt i praksis

En producent går ud fra, at fordi alle tekniske specifikationer allerede er i ERP-systemet, så "ruller pasportet bare ud". I praksis mangler netop de felter, som ESPR sandsynligvis kommer til at bede om, såsom reparations- og demonteringsoplysninger, og disse skal stadig udfyldes manuelt.

En importør arbejder med en database fra producenten fra et land uden for EU og antager, at disse data kan bruges én-til-én. Kildedataene har ofte ikke den struktur eller sproget, som er nødvendigt, og importøren har som markedsdeltager i EU et eget ansvar for rigtigheden af de data, der til sidst kommer ind i pasportet.

En projektindretningsvirksomhed har sin egen artikeldatabase pr. kundeprojekt, men denne er ikke forbundet med en individuel datadatabase pr. produkt. Ved en kontrol viser det sig, at der ikke er en direkte, stabil forbindelse mellem et solgt møbel og de tilhørende pasportdata.

En virksomhed opdaterer sin egen database regelmæssigt, f.eks. ved en materialændring, men glemmer, at pasportet for allerede solgte produkter dermed ikke længere stemmer overens med det fysiske produkt. Den interne database er en "levende" fil, mens pasportet skal være en pålidelig fastlæggelse på tidspunktet for salget.

En virksomhed med mange farve- og stofvarianter administrerer disse varianter som et separat felt inden for én produktkode, mens pasportet muligvis har brug for forskellige data pr. variant — tænk på en anden procentdel af materiale ved et andet stofvalg. Den, der beskæftiger sig hermed, finder mere information om denne specifikke komplikation ved hvordan opretter jeg pas til en møbelkollektion med mange farve- og stofvarianter.

Det, du kan fastsætte

Et overblik over, hvilke data der allerede er i den eksisterende database, og hvilke af disse der sandsynligvis er relevante for et produktpasport — baseret på hvad artikel 9 og 10 i ESPR (Forordning (EU) 2024/1781) giver som retning, selvom den nøjagtige liste pr. produktgruppe endnu ikke er fastsat.
En note om kilden til og pålideligheden af hver enkelt datapoint: er det selv fastslået, eller overtaget fra en leverandør eller producent andetsteds i værdikæden.
En arbejdsgang for at holde styr på ændringer i produktdata, så det er klart, hvilken version af dataene der hører til hvilket solgt produkt.
Aftaler med leverandører om, hvilke data de leverer, og i hvilket format, især når den egne database er afhængig af deres input.
Et overblik over produktvarianter og de data, der kan være forskellige pr. variant, især ved farve- og stofudviklinger.

Den, der gerne vil strukturere dette nu, også uden at den delegerede retsakt er der, finder en tilgang i hvad kan jeg gøre nu, mens reglerne endnu ikke er definitive. Og for den, der vil vide, hvordan denne registrering passer ind i resten af processen, findes et overblik i hvordan tackler jeg produktpasset for møbler trin for trin.

En eksisterende produktdatabase er således sjældent værdiløs, men også sjældent tilstrækkelig i sig selv. Den danner i de fleste tilfælde et brugbart udgangspunkt: grunddataene er der, strukturen og forbindelsen til en datadatabase normalt ikke. Det er klogt at vurdere disse to ting separat — hvad der allerede er data for, og hvad der stadig er nødvendigt for at få disse data til at blive til et pasport.

Dette er ikke juridisk rådgivning. Denne side giver generel information om den regulering, som denne platform handler om. Vi kender ikke din situation. Hvis du er i tvivl om dit eget tilfælde, skal du konsultere en jurist eller den relevante tilsynsmyndighed.

Skrevet med AI på basis af kilderne ovenfor, kontrolleret af mennesker den 2026-09-05. Stemmer der noget ikke? Giv os besked — rettelser får prioritet.