Håll din digitala produktpass uppdaterat: så fungerar uppdateringsflödet

Varför en uppdatering av ett digitalt produktpass är mer än att ändra ett databasfält

Ett digitalt produktpass (DPP) är inget statiskt dokument. Det följer en produkt genom hela dess livscykel — från tillverkning via detaljhandel, vidare till reparation och slutligen till återvinning. Det här kravet följer direkt av förordningen om ekodesign för hållbara produkter (ESPR), som har gällt sedan april 2024 och som fasas in stegvis över produktkategorier.

För företag innebär det: att skapa ett DPP en gång räcker inte. Reparationsuppgifter tillkommer, certifikat löper ut, leveranskedjedata förändras. Samtidigt får ändringshistoriken aldrig gå förlorad — revisorer och marknadskontrollmyndigheter måste kunna spåra vem som ändrade vad och när.

Den här artikeln går igenom den tekniska och organisatoriska processen för en DPP-uppdatering: vilka fält som kan ändras, vilka som inte kan det, hur GS1 Digital Link passar in i bilden och hur du strukturerar en massuppdatering över en stor produktkatalog.

Vad som kan ändras — och vad som inte kan det

Oföränderliga kärndata

Vissa identifierare låses efter den första certifieringen. GTIN (Global Trade Item Number) identifierar en produkt unikt inom GS1-systemet och kan inte bytas ut i efterhand. På samma sätt betraktas ett serienummer som oföränderligt när det väl har tilldelats ett fysiskt objekt. Det är inget förbiseende — det är medvetet utformat så: spårbarheten längs leveranskedjan är beroende av exakt denna stabilitet.

Den primära resolver-posten för QR-koden — det vill säga den URL som en GS1 Digital Link pekar på — bör inte heller ändras när den väl har tryckts på förpackningen. I stället uppdaterar du destinationen bakom resolvern, inte själva koden. Detta är den avgörande fördelen med dynamiska QR-koder jämfört med statiska: den tryckta koden förblir densamma medan underliggande data kan utvecklas.

Uppdaterbara fält

Följande datakategorier är vanligtvis avsedda för uppdateringar:

• Reparations- och underhållsdata: Vilka komponenter byttes ut, när och av vem?
• Certifikat och dokumentation av överensstämmelse: Utgångsdatum, nya provningsrapporter
• Återvinningsinstruktioner: Kan ändras när ny infrastruktur för slutet av livscykeln tas i drift
• Koldioxidavtryck: Förfinas under leveranskedjans gång (t.ex. när faktiska transportdata finns tillgängliga)
• Återförsäljar- och distributionsdata: Nya marknader, nya distributionspartner

ESPR kräver att denna information ska vara "aktuell, fullständig och korrekt" — utan att ange ett konkret uppdateringsintervall. I praktiken rekommenderar branschorganisationer som EURATEX kvartalsvisa genomgångar för textilsektorn, särskilt eftersom leveranskedjorna förändras snabbt under rådande förhållanden.

Det tekniska uppdateringsflödet i detalj

Steg 1: Dokumentera ändringsbegäran

Innan ett enda databasfält ändras behöver ändringsbegäran läggas in i ett ärendehanteringssystem. Vem ändrar vad, och på vilken grund (nytt certifikat, leverantörsbyte, reparation)? Detta är inte byråkrati för sin egen skull — det är grunden för det revisionsspår som marknadskontrollmyndigheter kan komma att kräva.

Steg 2: API-anrop eller massimport

För enskilda produkter är en riktad PATCH-begäran till DPP-API:et rätt tillvägagångssätt. Ett minimalt exempel i TypeScript:

const response = await fetch(
  `https://api.qr3.app/v1/passports/${passportId}`,
  {
    method: "PATCH",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${API_KEY}`,
    },
    body: JSON.stringify({
      sustainability: {
        carbonFootprintKgCO2e: 4.2,
        updatedAt: new Date().toISOString(),
        updatedBy: "supplier-audit-2025-q2",
      },
    }),
  }
);

if (!response.ok) {
  throw new Error(`Update fehlgeschlagen: ${response.status}`);
}

För att uppdatera många produkter samtidigt är en massimport effektivare. Du laddar upp en CSV- eller JSON-fil som bara innehåller de fält som ska ändras — inte hela passet. Detta minimerar felkällor och håller nyttolasten liten.

curl -X POST https://api.qr3.app/v1/passports/bulk-update \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: multipart/form-data" \
  -F "file=@updates_q2_2025.csv" \
  -F "dryRun=true"

Flaggan dryRun=true är viktig: den validerar filen utan att skriva något. Först efter manuellt godkännande utlöses den faktiska importen.

Steg 3: Versionshantering och revisionsspår

Varje lyckad ändring skapar en ny versionsrad. Det underliggande databasschemat följer en enkel princip — append-only:

INSERT INTO passport_versions (
  passport_id,
  version_number,
  changed_fields,
  changed_by,
  changed_at,
  previous_hash,
  new_hash
)
VALUES (
  $1, $2, $3::jsonb, $4, NOW(), $5, $6
);

Hash-mekanismen säkerställer att efterhandsmanipulation kan upptäckas. Varje version refererar till hashen för den föregående — likt en blockkedja, men utan en publik kedjas overhead.

Steg 4: Invalidera resolver-cachen

Efter en uppdatering måste GS1 Digital Link Resolver invalidera sin cache för den berörda GTIN-/serienummer-posten. Annars ser användare som skannar QR-koden fortfarande inaktuella data. Typiska cache-TTL:er är 5–15 minuter; för tidskritiska uppdateringar (t.ex. ett produktåterkallande) bör en omedelbar invalidering utlösas via API.

Särskilda hänsyn för textilindustrin

Den europeiska textilindustrin står under avsevärd press. EURATEX rapporterar att sektorn har krympt tredje året i rad — fabriker stänger, leveranskedjor flyttas. Det är just under sådana perioder som DPP-relevanta ändringar hopar sig: en leverantör faller bort, en annan tar över, certifikat behöver utfärdas på nytt.

ESPR:s delegerade förordning för textilier (prioritet från 2026 och framåt) kräver bland annat information om fibersammansättning, produktionsland och återvinningsbarhet. Alla dessa är fält som kan ändras vid ett leverantörsbyte. Företag bör därför redan nu etablera processer som automatiskt utlöser en begäran om DPP-uppdatering när en sådan ändring inträffar — i stället för att behandla det som manuellt efterarbete.

Ett pragmatiskt tillvägagångssätt: webhook-integration med ditt affärssystem (ERP). Så snart en ny leverantör skapas i ERP-systemet och kopplas till en produkt avfyras en webhook som startar ett DPP-uppdateringsflöde.

// ERP webhook handler (simplified)
app.post("/webhooks/supplier-change", async (req, res) => {
  const { productId, newSupplierId, effectiveDate } = req.body;

  await dppUpdateQueue.add({
    passportId: await resolvePassportId(productId),
    fields: {
      supplyChain: {
        primarySupplier: newSupplierId,
        supplierChangeDate: effectiveDate,
      },
    },
    requiresReview: true, // Manual approval before publishing
  });

  res.status(202).json({ queued: true });
});

Styrning: Vem får ändra vad?

En DPP-uppdatering är ingen trivial teknisk uppgift. ESPR håller den ekonomiska aktör som släpper ut produkten på marknaden ansvarig för att uppgifterna är korrekta. Det innebär att inte varje anställd bör kunna redigera godtyckliga fält.

En rollbaserad modell rekommenderas:

Den här tabellen täcker tre meningsfulla dimensioner (roll, fält, godkännande) — den är medvetet strukturerad, inte uppsvälld.

Slutsats: Uppdateringar är normen, inte undantaget

Det digitala produktpasset är inget engångsdokument för efterlevnad som du bockar av och glömmer. Det lever. När du väl har förstått det bygger du processer från start som stöder uppdateringar — med tydligt ägarskap, teknisk versionshantering och automatiserade utlösare från ERP-systemet.

Textilindustrin är ett särskilt tydligt exempel: i en sektor som strukturellt står under press och där leveranskedjor förändras ofta är ett robust uppdateringsflöde inte ett trevligt tillägg — det är en operativ nödvändighet. ESPR:s regulatoriska krav och dess tillhörande delegerade förordningar kommer bara att skärpa dessa krav under de kommande åren.