в какъв формат трябва да предоставя данните на продуктния паспорт

Какво конкретно трябва да направите

Какво се очаква от вас

Въпросът кой формат на файловете е задължителен — JSON, XML, PDF, специфична структура на API — възниква при всеки importor и производител, когато IT отделът начне да изгражда. Отговорът въз основа на текущия текст на ESPR е разумен: конкретен формат на файловете не е в регламента. Членове 10 и 11 на ESPR (Регламент (EU) 2024/1781) действително определят на какво трябва да отговаря дигиталния паспорт на продукта, но това се прави на ниво функционални и технически изисквания, а не на ниво "използвайте JSON-LD" или "предоставете XML файл според този схема". Развитието му се очаква чрез делегирани и изпълнителни акти, по група продукти.

Взаимната функциониналност е в центъра, не един специфичен формат

Член 10 на ESPR споменава взаимната функциониналност като основно изискване: паспортът трябва да бъде устроен по такъв начин, че системите на различни страни — надзорни органи, участници на пазара, потребители — да могат да прочетат данните. За компания от 10 до 100 служители това практически означава, че изборът на формат за съхранение и обмен може да бъде направен с сигурност едва когато делегираният акт за собствената категория продукти е наличен. До тогава е препоръчително да работите със структурирани данни (като например полета в база данни или ERP система), вместо да съхранявате данни само в разхвърлян документ или PDF, така че по-позднишното разкриване в окончателния формат да изисква по-малко преработка.

Паспортът трябва да бъде четлив чрез QR носител на данни

Член 11 на ESPR описва техническото функционирането на паспорта, включително връзката с носителя на данни на продукта. Това означава, че основните данни, в какъвто и да е формат, трябва да могат да бъдат разкрити в момента, когато някой сканира кода. Как тази връзка технически функционира и какви стандарти за идентификация играят роля при това, е описано на страницата за как QR кодът за продуктовия паспорт стига до моята електроника. За компании, които вече работят със GS1 баркодове, въпросът дали съществуваща структура за идентификация може да бъде преизползвана е значителен — че тема се връща на страницата за какво е GS1 Digital Link и дали е необходимо за паспорта на продукта.

Всеки продукт трябва да бъде уникално идентифицируем, независимо от формата на файловете

Независимо от това кой технически формат ще бъде предписан впоследствие, основното изискване е, че всеки продукт получава уникален идентификационен код. Това е отделно изискване, което не се променя, когато форматът на файла се определи по-късно. Компании, които вече започват структуриране на своите данни за продукти, правят добре, че включват тази идентификация като постоянна част. Как се изгражда това на практика, е обяснено на страницата за как да дадете на всеки продукт уникален идентификационен код.

Доставка на регистъра изисква своя собствена форма

Член 13 на ESPR въвежда регистъра на дигиталните продуктови паспорти, в които се вписват определени данни относно паспорта. И тук все още не е определено в кой точно формат на файла трябва да се извършва доставката — това ще бъде уточнено по-нататък. Ясно е обаче, че този регистър е отделен поток на доставка, различен от паспорта, който е достъпен чрез QR кода. Повече информация относно това, което трябва да се съдържа в него, е на страницата за какво представлява регистърът на дигиталните продуктови паспорти и какво трябва да съдържа.

Къде се допускат грешки в практиката

Твърде рано фиксиране в твърд формат. Някои компании вече разработват PDF паспорт, защото е бързо и узнаваемо, докато крайното изискване вероятно ще изисква структурирани, четими от машини данни. PDF е четим за хора, но не е автоматично подходящ за интероперабилност, която член 10 на ESPR си поставя за цел.

Данни разпръснати по множество системи без свързване. Информацията за продукта често се намира частично в ERP системата, частично в маркетингови документи, частично при външен доставчик. Без план да се събере всичко това, ще бъде трудно да се преключи бързо, когато задължителният формат е известен. Компании, които обмислят собствената си система да участва, намират повече информация за възможностите на страницата за свързване на продуктовия паспорт с собствена ERP или система за инвентар.

Объркване между самия паспорт и регистъра. Паспортът, който е достъпен чрез QR кода, и данните, които попадат в регистъра, не са автоматично идентични по форма или формат. Предположението, че един файл е достатъчен за двете цели, е риск, който е видлив едва когато изпълнителните акти станат конкретни.

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

Недостатъчно внимание на четимостта на дълг период. Формат на файл, който е разпространен сега, не трябва да остане такъв през по-дълъг период. Защото паспортът трябва да остане достъпен за определен период, изборът на формат е също въпрос за трайност — вижте обяснението за колко дълго трябва да остане наличен паспортът на продукта.

Какво можете да регистрирате

• Преглед на мястото, където данните за продукти се регистрират сега (ERP, PIM, електронни таблици, документи на доставчици) и в кой формат.
• Список на задължителните източници на данни по категория продукт, когато делегирания акт за тази категория е публикуван.
• Споразумения с доставчици и поддоставчици относно формата, в който доставят своите данни за продукти, така че свързването по-късно да е по-лесно.
• Вътрешен отговорник или екип, който следи разработката на техническите стандарти, тъй като член 11 на ESPR ще получи допълнителни спецификации по този въпрос.
• Документация на избрания идентификационен метод за всеки продукт, също независимо от крайния формат на файла.
• Преглед на изискванията към хостинга и достъпността, които заедно с формата определят как се организира техническата настройка на паспорта — вижте страницата за какви изисквания към хостинга действат.