Kan jag koppla produktpasset till mitt ERP- eller lagersystem?

Koppling är möjlig, formen är inte fastlagd i lagstiftningen

Ja, ett digitalt produktpass kan i praktiken kopplas till ett ERP- eller lagersystem, men ESPR föreskriver inte hur denna koppling ser ut. Förordningen ställer dock krav på själva passet: det måste vara tekniskt utformat så att data är maskinläsbara och så att system automatiskt kan läsa och bearbeta dem på basis av öppna standarder i stället för slutna, varumärkesspecifika format (artikel 11 i ESPR, förordning (EU) 2024/1781). Denna krav är riktad mot passet och datamedia, inte mot interna system hos en däckimportör, grossist eller fordonsflotteförvaltare. Huruvida och hur en koppling till ett specifikt ERP-paket fungerar är således en fråga om teknisk utformning hos den part som sammanställer och är värd för passet — i detta fall en plattform som tyrepas.eu — och inte något som lagstiftningen reglerar i detalj.

För vem detta är relevant, och för vem det inte är

Denna fråga är särskilt aktuell för parter som hanterar stora volymer däck och där produktdata redan finns någonstans i ett system: importörer som hanterar artikelnummer, partdata och tekniska specifikationer, grossister som för lager per däcktyp, och fordonsflotteförvaltare som kopplar däck till fordon. För dem är en koppling främst praktisk: data behöver då inte registreras två gånger, och passportsinformation kan återföras till det egna systemet.

För slutanvändare som endast köper ett däck och skannar QR-koden har koppling till ett ERP-system ingen roll — de läser passet, de matar det inte. Och för mindre parter utan eget system är koppling inte heller aktuell: passet kan då lika gärna levereras och läsas manuellt, utan att detta påverkar dess giltighet. De tekniska kraven i artikel 11 gäller dessutom själva passet som sådant, inte frågan om en leverantör av passtjänster måste erbjuda en specifik koppling till ett visst ERP-märke.

Inget fast datum ännu, men en tydlig arbetsväg

När förpliktelsen för ett digitalt produktpass för däck exakt träder i kraft är ännu inte fastställt. I ESPR:s arbetsprogram för perioden 2025-2030 väntas en delegerad handling för däck 2027; först med publicering av denna blir ett konkret ikraftträdandedatum känt. Till dess gäller det ingen obligatoriska krav för däck på själva passet och således inte heller på hur data levereras eller utbyts.

Det betyder inte att det inte finns något att göra. De allmänna kraven i artikel 10 och artikel 11 i ESPR är redan fastställda som ramverk för den delegerade handlingen för däck: maskinläsbarhet, öppna standarder och interoperabilitet är ingen ny uppfinnelse som först dyker upp 2027, utan grunden på vilken de däckspecifika reglerna byggs. Den som redan nu tänker på en koppling bygger således inte på sand, även om det definitivt datumet ännu saknas.

Hur detta hanteras i praktiken

Det första steget är att kontrollera vilka data som redan finns i ERP- eller lagersystemet och som senare måste återfinnas i ett pass: artikelnummer, parti- eller batchdata, produktionsdatum, tekniska specifikationer per däcktyp. Mycket av dessa data finns redan, de är bara ännu inte strukturerade för ett pass.

Det andra steget är att ta reda på vilket format den part som sammanställer och är värd för passet accepterar som inmatning. Eftersom tyrepas.eu bygger passet utifrån data från tillverkaren eller importören är den praktiska frågan inte så mycket om koppling kan fungera, utan i vilken form datainmatningen går mest praktiskt till: en periodisk export från ERP-systemet, en strukturerad fil, eller en annan leveransväg.

Det tredje steget är att överväga den andra riktningen: att återkoppla passiportdata till sitt eget system, till exempel så att en flottenansvarig kan länka passiortinformation till en fordonsregistrering utan att själv behöva söka upp passiorten via QR-koden. Detta är också en fråga om teknisk samordning mellan ERP-systemet och plattformen, inte om en laglig skyldighet.

Slutligen är det viktigt att beakta löptiden: ett passiport hostas under en tioårsperiod. Den som upprättar en koppling gör klokt i att också överväga uppdateringar under den perioden — till exempel när produktdata ändras — så att kopplingen fungerar inte bara vid första leveransen utan även vid senare ändringar.

Den lagstiftningsram som gäller: artikel 10 och 11 ESPR

Kraven på själva det digitala produktpassiorten anges i artikel 10 i ESPR (Förordning (EU) 2024/1781), som fastställer de allmänna kraven för passiorten. Artikel 11 i samma förordning behandlar specifikt den tekniska utformningen och funktionen av passiorten, med betoning på interoperabilitet och öppna standarder så att data är maskinläsbar och utbytbar. Båda artiklarna fokuserar på passiorten som produkt, inte på importörernas, grossisternas eller flottenansvariges interna informationssystem — kopplingen till dessa är en teknisk tillämpning som kommer därutöver.

Den som redan nu vill förbereda sig kan med fördel börja med att kartlägga sina egna produktdata och kontakta den part som kommer att sammanställa och hosta passiorten för däck, för att diskutera vilken leveransväg som bäst passar det befintliga ERP- eller lagersystemet.

Vad detta är baserat på

Själva förordningen finns på EUR-Lex. Vi hänvisar per påstående; du behöver inte tro på oss.

Vad du konkret måste göra

Vad som förväntas av dig

Passet måste kunna ta emot data från ett källsystem

Ett produktpasset skrivs inte in manuellt i ett separat formulär — data kommer från någonstans: från ett ERP-system, ett lagerhanteringsprogram, en Excelexport från tillverkaren eller en kombination därav. Artikel 10 i ESPR (förordning (EU) 2024/1781) ställer krav på vilka data som måste finnas i passet och hur dessa är åtkomliga, men föreskriver inte via vilket system ett företag ska tillhandahålla dessa data. För en däckimportör eller grossist med 10 till 100 anställda innebär detta praktiskt att det måste finnas ett fast, upprepningsbart sätt att få produktdata från sitt eget system till passet — inte en engångsöversättning som måste uppfinnas på nytt vid nästa däckparti.

Kopplingen måste matcha en unik identifikationskod per produkt

Artikel 11 i ESPR beskriver hur det digitala produktpasset tekniskt ska fungera, inklusive kopplingen mellan en produkt och dess pass via en identifikationskod. Ett ERP- eller lagersystem arbetar vanligen med egna artikelnummer, SKU:er eller interna koder. För kopplingen till passet måste denna interna kod sammanfalla med eller översättas till identifikationskoden som passet använder. Företag som redan för en tydlig, unik kod för varje däckstorlek eller batchmängd i sitt lagersystem har ett försprång här; företag som arbetar med samlingspartier eller allmänna modellnamn upptäcker ofta först vid kopplingen att deras interna administration inte är tillräckligt detaljerad. Mer om detta grundläggande steg finns i hur ger jag varje produkt en unik identifikationskod?

Ändringar i källsystemet måste återspeglas i passet

Ett lagersystem är aldrig statiskt: priser förändras, specifikationer uppdateras, en leverantör ändrar en sammansättning. Artikel 10 utgår från ett pass som återspeglar aktuell status i den omfattning som datakategorin kräver. För ett företag innebär detta att en koppling till sitt eget system inte bara måste fungera vid första inmatningen utan även vid senare ändringar — annars uppstår ett pass som var korrekt vid publicering men inte längre är det.

Kopplingen måste kunna spåras till källan

Ett pass som visar data utan att det går att spåra vilket system, vilken export eller vilken version dessa data kommer från är svårt att motivera vid en kontroll. Detta följer inte av en specifik artikel utan av den praktiska sidan av artiklarna 10 och 11 tillsammans: data måste stämma ÖCH vara kontrollerbar. För företag med en koppling till sitt ERP innebär detta att någon form av loggning eller versionskontroll är lämplig — när överfördes vilken uppsättning data och av vem.

Där det går fel i praktiken

En grossist kopplar lagerhanterings modulen från sitt ERP-system en gång till passet vid lanseringen, men glömmer att nya däckstorlekar som läggs till senare inte automatiskt inkluderas — passet förblir fast på sortimentet från startdatumet.

En importör använder i ERP-systemet en samlingsKOD för en hel produktlinje ("175/65R14 sommardäck, olika märken"), medan passet måste fungera per unik identifikationskod. Kopplingen ger då ett pass för produkter som egentligen var behöver sitt eget pass — se även hur förhåller sig däckstorlek till den unika identifikationskoden?

En wagenparkförvaltare får en export från tillverkaren i ett format som inte motsvarar sitt eget lagersystem, och data skrivs manuellt in i en temporär fil. Vid nästa leverans uppdateras denna temporära fil inte, vilket gör att passet visar en äldre version av specifikationerna än vad som faktiskt finns i lagret.

Ett företag kopplar ERP-systemet direkt till passet utan mellansteg, och ett fel i ett exportfält (till exempel en blandad kolumn med däckstorlekar) hamnar osedd i flera pass, eftersom ingen kontrollerar de kopplade data efter överföring.

En importör tror att en koppling är tillräcklig för alla framtida varianter av en modell, medan det faktiskt krävs separata data för varje storlek eller utförande — frågan om data får återanvändas för olika däckstorlekar av samma modell kommer då upp för sent, se kan jag använda samma data för flera däckstorlekar av samma modell?

Vad du kan dokumentera

En överblick över vilket system (ERP, lagerhantering, leverantörsportal) som är källan för vilket datafält i passet, så att det omedelbar är klart var en siffra eller specifikation kommer från vid en fråga eller kontroll.
En fast procedur för överföring av data för nya produkter, inklusive tidpunkten då den unika identifieringskoden tilldelas och kopplas.
En överenskommelse om vem som ansvarar för att uppdatera passet när data i källsystemet ändras — och enligt vilken process det sker.
Ett kontrollsteg efter varje koppling eller export, där data i passet stickprovsmässigt kontrolleras mot källsystemet.
En logg eller versionshistorik över vad som överfördes och när, så att en ändring senare kan spåras.
Dokumentation av själva den tekniska kopplingen (vilka exportformat, vilka fält som mappas, vilken programvara eller mellanvara som används), användbar som bilaga vid interna revisioner.

För företag som ännu inte har bestämt om deras däck alls omfattas av denna förpliktelse är det ett logiskt tidigare steg — se gäller det digitala produktpasset för mina däck? Den som vill veta mer om passtes roll i kedjan övergripande och var kopplingen med ett eget system passar in, hittar en allmän förklaring i vad är ett digitalt produktpass för däck?

Detta är ingen juridisk rådgivning. Denna sida ger allmän information om regelverket som denna plattform handlar om. Vi känner inte till din situation. Vid osäkerhet om ditt eget fall rådfrågar du en jurist eller behörig tillsynsmyndighet.

Skriven med AI baserat på källorna ovan, kontrollerad av en människa den 2026-08-22. Stämmer något inte? Låt oss veta — rättelser får förtur.