На 20 юли 2026 г. Европейската комисия въведе в експлоатация регистъра за цифрови продуктови паспорти заедно с тестова среда. Така една абстрактна ESPR-компонента се превърна в система, която компаниите действително могат да изпробват. За производителите сега е особено важно да разграничават следното: регистърът е централен индекс, а самият продуктов паспорт остава децентрализиран.
Какво беше въведено в експлоатация на 20 юли
Регистърът приема уникални идентификатори на продукти, регистрационни данни и избрани метаданни. Пълната информация за продуктите продължава да се съхранява от отговорния икономически оператор или от упълномощен DPP-доставчик. Затова Комисията изрично описва регистъра като индексна услуга, а не като централизирана система за управление на съдържанието.
Регистрациите ще бъдат възможни чрез защитен потребителски интерфейс и API. Компаниите могат също да генерират електронно удостоверение за регистрация. Това е важно за B2B процесите, тъй като доставчиците и клиентите могат да докажат, че даден паспорт е вписан в системата на ЕС, без да дублират целия набор от данни.
Стартът не засяга само ESPR-продуктови групи. Комисията посочва също батерии, строителни продукти, играчки, перилни препарати и повърхностноактивни вещества за крайни потребители, доколкото съответното право на Съюза изисква цифров продуктов паспорт. Първият задължителен срок остава 18 февруари 2027 г. за определени батерии.
Регистърът, резолверът и източникът на данни са три различни слоя
Една надеждна DPP-система трябва ясно да разделя задачите:
- Регистърът на ЕС потвърждава, че са регистрирани идентификатор и предписаните метаданни.
- Резолверът насочва постоянния идентификатор на продукта към подходящия ресурс.
- Самият източник на данни предоставя актуално съдържание за хора и машини.
Това разделение не е подробност. Който съхранява всички данни единствено на собствена продуктова страница, все още няма интеграция с регистъра. И обратно, който регистрира само идентификатор, все още не предоставя използваем продуктов паспорт. Двете трябва да бъдат свързани чрез стабилни идентификатори.
За разрешаването на идентификаторите е подходяща отворена, постоянна връзка. Един GS1-Digital-Link-резолвер може да направи достъпни различни представяния чрез един и същ идентификатор: разбираема уебстраница, машинночетим JSON-LD или допълнителна документация. Носителят на данни върху продукта или опаковката остава стабилен, дори когато целевите системи се развиват.
Какво трябва да проверят компаниите в тестовата среда
Тестовата среда не е предназначена само за ръчен тест с едно щракване. Към нея трябва да се подхожда като към предварителен етап на продуктивната интеграция.
Организация и роли
Първо трябва да се изясни кое юридическо лице се регистрира, кой го представлява в системата и кои екипи имат право да създават или променят регистрации. Това засяга основните данни, съответствието, ИТ и евентуално външни доставчици на услуги. Личният тестов достъп не заменя модел на ролите за последващата експлоатация.
Идентификатори и детайлност
Продуктовият екип трябва да установи дали бъдещият паспорт ще се поддържа на ниво модел, партида или отделен екземпляр. Отговорът зависи от приложимото секторно законодателство. Тестът на регистъра е подходящият момент за съпоставяне на вътрешните продуктови идентификатори, GTIN, идентификаторите на партидите и използвания извън системата постоянен идентификатор.
API и възпроизводимост
Продуктивният процес изисква повече от един успешен POST. Регистрацията, актуализацията и обработката на грешки трябва да могат да се повтарят и да се протоколират. Това включва идемпотентни заявки, технически потвърждения и ясна връзка между записа в ERP, DPP и записа в регистъра. Един базиран на API DPP-процес намалява ръчните несъответствия, когато продуктите се създават в големи количества.
Разделяне на метаданните и специализираните данни
Данните в регистъра не бива да се превръщат във втори набор от продуктови данни. Определете кои полета са задължителни в регистъра и кои остават в децентрализирания паспорт. За всяка информация са необходими водещ източник, отговорно звено и правило за актуализиране.
Доказателства и мониторинг
Удостоверенията за регистрация трябва да се съхраняват заедно с времевия печат, използвания идентификатор и отговора на системата. Освен това е необходима проверка: съществува ли паспортът, достъпен ли е резолверът и съответстват ли все още метаданните в регистъра на статуса на продукта?
Защо митниците се нуждаят от собствена проверочна последователност
Регистърът подпомага митническите органи автоматично да проверят преди допускането за свободно обращение дали са налице валиден регистриран DPP и необходимият код на стоката. За вносителите това създава нова зависимост: идентификаторът на продукта, записът в регистъра и митническата декларация трябва да са съгласувани.
Затова грешката няма да стане видима едва на продуктова страница. Тя може да засегне граничния процес. Компаниите трябва още в тестовата среда да симулират потоците от данни от създаването на продукта до документацията за внос и да определят кой може бързо да коригира неправилна регистрация.
Практичен 30-дневен план за тестване
- Изберете реално юридическо лице и малък, представителен асортимент от продукти.
- За всеки продукт документирайте планираната DPP-детайлност и водещите идентификатори.
- Изпълнете пълен процес чрез потребителския интерфейс и, ако е релевантно, чрез API.
- Архивирайте заедно удостоверението за регистрация, отговора на резолвера и машинночетимите продуктови данни.
- Тествайте случаи на грешки: дублиран идентификатор, остарели метаданни, недостъпен хост за данни и изтеглен от пазара продукт.
- На основата на резултатите създайте оперативен модел с отговорности, мониторинг и път за ескалация.
Оперативният старт на регистъра все още не означава, че всички специфични за секторите изисквания за данни вече се прилагат изцяло. Той обаче измества дискусията от презентациите към проверими процеси. Компаниите вече могат да установят дали техните идентификатори, роли и API са съгласувани, преди да започнат да изтичат първите задължителни срокове.
