Kan jag koppla produktpasset till mitt ERP- eller lagersystem?
Koppling är möjlig, förutsatt att data tillhandahålls på strukturerad väg
Att koppla ett produktpass till ett ERP- eller lagersystem är i grunden möjligt, eftersom ESPR föreskriver att det digitala produktpasset tekniskt konstrueras så att datautbyte sker på ett interoperabelt och maskinläsbart sätt (artikel 11 i ESPR, Förordning (EU) 2024/1781). Det innebär att de data som redan finns i ett ERP- eller lagersystem — materialsammansättning, ursprung, komponenter, batch- eller serienummer — i princip kan vara källan från vilken passet konstrueras. Kopplingen ligger då inte i en direkt, live-anslutning mellan två system, utan i det faktum att samma data som redan hanteras internt tillhandahålls i ett lämpligt format för passet.
För vilka data detta fungerar, och för vilka inte
Detta handlar om data som redan finns registrerade någonstans och som är relevanta för passet för en specifik produkt: tekniska specifikationer, materialinformation, reparations- och underhållsdata, eller ursprungsinformation. För den typen av data är en strukturerad tillhandahållning från ett befintligt system logisk. Det handlar inte om en allmän, permanent systemkoppling som föreskrivs av ESPR — förordningen förpliktar ingen tillverkare eller importör att använda en specifik teknik, API eller programvarupaket. Artikel 11 handlar om den tekniska utformningen av själva passet: hur datakällan, registret och dataåtkomsten är organiserade. Den föreskriver inte hur ett företag organiserar eller exporterar sitt eget ERP-system. Det är också viktigt: vilka data som exakt ska finnas i passet varierar beroende på produktgrupp och regleras separat för varje produktgrupp genom en delegerad handling. Vad som för en produkt är ett relevant ERP-fält (till exempel en materialprocentsats) behöver inte gälla för en annan produktgrupp.
De tekniska kraven gäller redan, produktgruppernas innehål ännu inte överallt
ESPR själv, med de allmänna kraven på det digitala produktpasset (artikel 10) och dess tekniska utformning (artikel 11), är fastställd och utgör ramverket inom vilket varje produktpass i framtiden ska fungera. När en konkret produkt faktiskt behöver ett pass och vilka data som exakt ska ingå bestäms separat för varje produktgrupp. För många produktgrupper är denna utarbetning ännu inte publicerad eller ännu inte gällande. Tills det är fastställt för en produktgrupp vilka data som är obligatoriska finns det alltså ännu ingen konkret förpliktelse att inrätta en koppling eller dataflöde från ett ERP-system — det är dock klokt att redan veta var de relevanta data internt skulle komma ifrån, så att det inte behöver börjas från noll när en förpliktelse börjar gälla.
Hur detta hanteras i praktiken
Det första steget är att kontrollera vilka uppgifter som redan finns i ERP- eller lagersystemet och som är relevanta för vad ett paspoort typiskt innehåller: produktidentifiering, materialsammansättning, ursprung, komponenter, garanți- eller reparationsinformation. Därefter är det lämpligt att undersöka hur dessa uppgifter kan exporteras från systemet — som fil, som rapport eller via en strukturerad anslutning — i ett format som är läsbart och överförbart, i enlighet med den öppna och interoperabla utformning som artikel 11 föreskriver för paspoorten. Därefter är det viktigt att koppla uppgifterna till den unika produktidentifiering som paspoorten kräver enligt artikel 10, så att varje paspoort verifierat hör till rätt produkt. Eftersom ett paspoort måste vara aktuellt under hela produktens livslängd är det praktiskt att också överväga en återkommande process: hur förmedlas en ändring i ERP-systemet (till exempel en modifierad komponent eller en ny leverantör) vid en given tidpunkt i paspoorten. Det behöver inte nödvändigtvis ske i realtid — en periodisk inlämning, till exempel vid ändringar eller ny produktion, räcker i de flesta fall utmärkt. En plattform som sammanställer paspoort från inlämnade uppgifter, som prodpas.eu, tar emot dessa uppgifter vanligtvis just på detta sätt: som strukturerad inlämning från en tillverkares eller importörs befintliga register, inte som en permanent live-anslutning mellan två system.
Där detta följer från: artikel 10 och 11 i ESPR
Skyldigheten till interoperabilitet och maskinläsbarhet för det digitala produktpasset anges i artikel 11 i ESPR (förordning (EU) 2024/1781), som reglerar passpotets tekniska utformning och drift. Artikel 10 i samma förordning beskriver de allmänna krav som ett paspoort måste uppfylla, inklusive länkningen till en unik produktidentifiering. Tillsammans utgör dessa artiklar grunden för varför källuppgifter från ett befintligt system, om de tillhandahålls strukturerat, kan vara lämpliga som inmatning för ett paspoort — utan att förordningen föreskriver vilken teknik eller vilket system ett företag använder internt för detta.
Den som redan vill förbereda sig kan börja bäst med en översikt över vilka produktuppgifter som finns i sitt eget ERP- eller lagersystem och i vilket format dessa kan exporteras. När det blir klart för den egna produktgruppen vilka uppgifter ett paspoort måste innehålla är denna inlämning från det befintliga registret vanligtvis utgångspunkten för praktiken.
Var detta baseras på
- Förordning (EU) 2024/1781 (ESPR), artikel 11 (teknisk utformning och drift av det digitala produktpasset)
- Förordning (EU) 2024/1781 (ESPR), artikel 10 (krav på det digitala produktpasset)
Förordningen själv finns på EUR-Lex. Vi hänvisar för varje påstående; ni behöver inte tro på oss.
Vad du konkret måste göra
Vad som förväntas av dig
En länkning mellan ett ERP- eller lagersystem och produktpasset är inte en isolerad önskan som står skild från reglerna — sättet på vilket data tillhandahålls, görs tillgänglig och hålls aktuell berör direkt vad artikel 10 och artikel 11 i ESPR (förordning (EU) 2024/1781) föreskriver om det digitala produktpasset. För ett företag med 10 till 100 anställda som arbetar med flera produktgrupper är länkningen vanligtvis inte något "trevligt att ha" utan det enda praktiska sättet att uppdatera pass för hundratals eller tusentals artiklar.
Passet måste länkas till en unik identifieringskod
Artikel 10 i ESPR kräver att varje produktpass kan spåras till den produkt det tillhör via en unik identifieringskod. Det är omedelbar också nyckeln för en länkning med ett eget system: ERP- eller lagersystemet arbetar redan med artikelnummer, batchnummer eller SKU:er, och dessa måste överensstämma med den identifieringskod som används i passet. Utan denna otvetydig länkning uppstår risken att en uppdatering i det ena systemet inte längre kan återfinnas i det andra. Hur denna identifieringskod byggas upp och tilldelas beskrivs på sidan om hur varje produkt får en unik identifieringskod.
Den tekniska driften måste överensstämma med ett standardiserat system
Artikel 11 i ESPR behandlar den tekniska utformningen av passet: hur data lagras, görs tillgänglig och blir maskinläsbar. För en länkning med ett ERP-system innebär detta att utbytet inte kan utformas fritt utan måste överensstämma med en standard som maskiner på båda sidor kan läsa. I praktiken handlar det oftast om att arbeta med ett system som GS1 Digital Link, där en identifieringskod direkt hänvisar till rätt passuppgifter. Vad det innebär och om det är relevant för ett specifikt företag förklaras på sidan om vad GS1 Digital Link är och om det är nödvändigt för produktpasset.
Uppgifter som ändras måste förbli aktuella i passet
Ett ERP-system förändras ständigt: lagernivåer, batchuppgifter, sammansättningar, leverantörer. Inte all denna information hör hemma i produktpasset, men de uppgifter som väl gör det — såsom materialssammansättning, reparationsinformation eller hållbarhetsegenskaper — måste stämma när någon skannar QR-koden. En länkning med det egna systemet är för många företag det enda sättet att göra detta möjligt i stor skala istället för att uppdatera varje pass manuellt. Om och hur det kan göras automatiskt behandlas på sidan om att automatiskt uppdatera uppgifter i produktpasset.
Passet måste förbli åtkomligt, även oberoende av det egna systemet
Artikel 10 ställer krav på passens tillgänglighet. En länkning med ett ERP-system är användbar för att uppdatera uppgifter, men passet självt måste fortsätta att existera och vara åtkomligt även när det interna systemet ersätts, migreras eller fasas ut. Det kräver en separation mellan den plats där källdata finns (ERP-systemet) och den plats där passet är värdhostat och görs tillgängligt.
Där det går fel i praktiken
ERP-systemet ses som passet självt. Vissa företag tror att det räcker att exportera en produktöversikt från ERP-systemet till en PDF eller webbsida. Passet kräver dock en fast identifieringskod, bestående tillgänglighet och en standardiserad teknisk struktur — en export är sällan det.
Artikelnummer i ERP-systemet överensstämmer inte med passidentifieringen. När det interna artikelnumret inte motsvarar en-till-en identifieringskoden som står på QR-koden uppstår ett mismatch som bara märks när någon får fel pass när koden skannas.
En systemväxling bryter länkningen. Vid övergång till ett nytt ERP-system glöms ibland kopplingen till passet bort, vilket leder till att uppdateringar stannar medan passet förblir online med föråldrade data.
Lager- och batchdata publiceras av misstag. En koppling som är för brett utformad skickar ibland interna data till passet som inte är avsedda för offentlig konsumtion, såsom inköpspriser eller leverantörsnamn.
En produkt med flera pass särskiljs inte på rätt sätt. För produkter som faller under mer än en produktgrupp, eller som består av komponenter som var och en behöver ett eget pass, leder en enkel koppling på artikelnivå till förvirring om vilket pass som hör till vilken komponent. Se till detta de sidor som handlar om flera produktpass för en produkt och ett pass per komponent kontra för produkten som helhet.
Vad ni kan dokumentera
- En översikt över vilka fält från ERP- eller lagersystemet som automatiskt strömmas till passet, och vilka som inte gör det.
- Kopplingen mellan det interna artikelnumret eller SKU och den unika identifieringskod som används i passet.
- Avtal om vem som är ansvarig för att hålla data aktuell efter en ändring i källdatasystemet.
- En procedur för vad som händer med kopplingen vid en systemmigrering eller -byte, så att passet inte stannar.
- En kontroll av vilka data som får och inte får vara synliga för allmänheten via passet, innan kopplingen går live.
- Dokumentation av den använd standard för datautbyte, inklusive eventuell användning av GS1 Digital Link.
Detta är inte juridisk rådgivning. Den här sidan ger allmän information om den lagstiftning som denna plattform handlar om. Vi känner inte till er situation. Vid tvivel om er eget fall rådfrågar ni en jurist eller tillsynsmyndigheten.
Skriven med AI baserat på källorna ovan, kontrollerad av människa den 2026-08-22. Stämmer något inte? Låt oss veta — korrigeringar får företräde.