DPP-Поддържане на данните актуални: какво наистина изисква ESPR

Как правилно да актуализирате данните в Digital Product Passport според ESPR: ниво на партида и продукт, задължения към регистъра и практически архитектурни насоки.

от QR3 Redaktion

DPP-Поддържане на данните актуални: какво наистина изисква ESPR

От приемането на ESPR-Регламент (ЕС) 2024/1781 Digital Product Passport (DPP) е задължително право на ЕС. Това, което много компании подценяват, е, че DPP не е статичен документ, който се създава веднъж при пускането на пазара. Той трябва да се поддържа актуален през целия жизнен цикъл на продукта — а изискванията към това стават все по-прецизни.

Тази статия обяснява кои данни и кога трябва да се актуализират, как архитектурата на регистъра влияе върху модела за актуализация и кои технически модели се доказват на практика.

Какво казва регламентът за цикъла на актуализация

Статични и динамични полета с данни

Самата ESPR не посочва изрична честота на актуализациите, но определя, че DPP трябва да съдържа „актуална и точна информация“. Конкретизирането се извършва на секторно ниво — и тук проектът на JRC за полуфабрикати от желязо и стомана дава най-ясната досега картина.

Проектът систематично разграничава две нива на детайлност на данните:

Ниво Идентификатор Примерни данни Повод за актуализация
Ниво на партида (Lot) Номер на партидата Дял на рециклирания материал, състав на сплавта, PCF съгласно ISO 14067 При промяна в производството, нова партида
Ниво на продукт (Item) Сериен номер Размери, сертификати, декларации за съответствие При ресертифициране, изтегляне от пазара, ремонт

Това разграничение е решаващо за архитектурата на базата данни: данните за партидата обикновено се записват веднъж за всеки производствен цикъл и след това остават стабилни — освен ако при повторно изчисляване на въглеродния отпечатък не се получи коригирана стойност. Данните на ниво продукт, от друга страна, могат да се променят през целия период на използване, например когато дадено устройство бъде ремонтирано или сертификатът му бъде подновен.

Регламентът за батериите (ЕС) 2023/1542 вече познава това разграничение имплицитно: данните за капацитета, които се променят вследствие на деградация, трябва да се поддържат актуални — изискване, което трудно може да бъде изпълнено без ясна архитектура.

Регистърът като указател, а не като хранилище на данни

Често срещано недоразумение засяга ролята на централния DPP-регистър. Проектът на регламент за изпълнение относно DPP-регистъра изяснява: регистърът съхранява единствено уникалния идентификатор, крайната точка на резолвъра и кода на стоката — не самите данни от паспорта.

Това означава за управлението на актуализациите: съдържанието на паспорта и регистърът са отделни системи. Който актуализира данни за продукта, по правило не трябва да променя регистъра — освен ако крайната точка на резолвъра не се промени (например при смяна на системата). Консорциумът CIRPASS-2 изрично посочи този архитектурен модел в становището си по проекта за регистър и препоръча стандартът EN 18219 да бъде включен като задължителна референция в регламента за изпълнение — наред с другото, за да се гарантира оперативната съвместимост с GS1 Digital Link.

Сценарии за актуализация на практика

Сценарий 1: Нов въглероден отпечатък вследствие на смяна на доставчик

Специфичният за продукта въглероден отпечатък (PCF) се поддържа на ниво партида съгласно проекта на JRC за стоманата и трябва да се изчислява по съвместими с ISO-14067 методи. Ако производител на стомана смени енергийния си източник или доставчика на скрап, PCF на новата партида се променя — но не и този на вече доставените партиди.

Технически това означава: DPP-записът на старата партида остава непроменен. За новата партида се създава нов запис, който може да използва същата крайна точка на резолвъра, но носи нов номер на партидата като идентификатор.

# Beispiel: Neuen Chargen-Datensatz via API anlegen
curl -X POST https://api.example.com/dpp/lots \
  -H "Content-Type: application/json" \
  -d '{
    "lotId": "LOT-2026-0612-A",
    "productId": "GTIN-04012345678901",
    "pcf_kgCO2e_per_kg": 1.84,
    "pcf_method": "ISO-14067:2018",
    "recycled_content_pct": 42,
    "alloy_composition": {"C": 0.18, "Mn": 1.40, "Si": 0.25}
  }'

Сценарий 2: Изтичащ сертификат на ниво продукт

Декларациите за съответствие и сертификатите имат срокове на валидност. Веднага щом бъде издаден нов сертификат, DPP трябва да бъде актуализиран на ниво продукт. Тъй като крайната точка на резолвъра остава непроменена, актуализация на регистъра не е необходима — променя се само записът зад крайната точка.

// TypeScript-Beispiel: Zertifizierung aktualisieren
interface Certification {
  type: string;
  issuedBy: string;
  validUntil: string; // ISO 8601
  documentUrl: string;
}

async function updateCertification(
  itemId: string,
  cert: Certification
): Promise<void> {
  await dppClient.patch(`/items/${itemId}/certifications`, {
    body: cert,
  });
}

Сценарий 3: Миграция на резолвъра при смяна на системата

Ако дадена компания смени своя доставчик на DPP-услугата, крайната точка на резолвъра се променя. В този случай регистърът трябва да бъде актуализиран — и то за всеки засегнат идентификатор. Това е най-сложният тип актуализация, тъй като изисква запис в регистъра.

Препоръка: използвайте стабилен собствен резолвър (напр. dpp.ihrunternehmen.de) като междинен слой, който вътрешно препраща към съответния доставчик. Така крайната точка, въведена в регистъра, остава трайно стабилна.

Технически изисквания към системата за актуализация

Версиониране и одитна следа

ESPR не изисква изрично версиониране, но съчетанието от отговорност за продукта и митнически контрол прави одитната следа фактически неизбежна. Ако през 2030 г. митнически служител провери DPP на стоманена греда, произведена през 2027 г., трябва да може да се проследи кои данни са били валидни към момента на вноса.

Минимална схема за версионирана таблица на DPP:

CREATE TABLE dpp_versions (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  identifier   TEXT NOT NULL,          -- GTIN + Lot/Serial
  valid_from   TIMESTAMPTZ NOT NULL,
  valid_until  TIMESTAMPTZ,            -- NULL = aktuell gültig
  data         JSONB NOT NULL,
  changed_by   TEXT NOT NULL,
  change_reason TEXT
);

CREATE INDEX ON dpp_versions (identifier, valid_from DESC);

GS1 Digital Link разделя чисто идентификатора и резолвъра: QR кодът върху продукта кодира URL адрес като https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, който чрез GS1 резолвъра или собствен резолвър води към актуалния DPP-запис. Актуализациите на записа не изискват ново етикетиране — физическият носител остава непроменен.

TEKLYNX актуализира своя софтуер CODESOFT и вече поддържа схемите за кодиране GS1-„++“, с които уеб URL адреси могат да се записват директно в паметта на RAIN-RFID тагове — изискване, произтичащо от съчетанието на EN 18220 и стандарта GS1 Digital Link.

Управление: кой какво може да актуализира?

Наред с техническия въпрос възниква и въпросът за управлението: кои участници във веригата на доставки имат право да записват кои полета на DPP? Консорциумът CIRPASS-2 идентифицира тук критични аспекти на суверенитета над данните при трансгранични вериги на доставки.

Един практически модел разграничава три роли:

  • Производител (Creator): Записва всички полета при създаването; може да актуализира всички полета.
  • Упълномощен участник (Editor): Може да актуализира определени полета (напр. история на ремонтите, нови сертификати) — документирано със собствен идентификатор.
  • Читател (Reader): Може да чете всички публични полета, но няма права за запис.

Ecommerce Europe поиска в позиционния си документ относно прилагането на DPP да бъдат възможни и „частични DPPs“ за употребявани продукти — тоест записи, които актуализират само част от първоначалните полета. Това технически е възможно още днес, но все още липсва като формална категория в регламентите за изпълнение.

Заключение

Поддържането на данните в DPP-актуално състояние не е еднократна задача, а оперативен процес. Най-важните изводи от актуалното регулаторно състояние:

  1. Разделяйте партидата и продукта — стратегията за идентификаторите определя кои данни и кога трябва да се актуализират.
  2. Регистърът не е хранилище на данни — актуализациите на съдържанието на паспорта по правило не изискват запис в регистъра.
  3. Версионирането е фактически задължително — дори регламентът да не го изисква изрично.
  4. GS1 Digital Link отделя физическия носител от записа — това значително намалява усилията при актуализиране на данните.
  5. Ролите и отговорностите трябва да бъдат дефинирани предварително — кой какво може да записва и как се документира това?

Стандартите стават по-прецизни, първите пилотни проекти вече се изпълняват — който изгради правилно архитектурата сега, ще избегне скъпи корекции, когато влязат в сила секторните регламенти за изпълнение.

Източници

Свързани статии