Мога ли да свържа цифровия продуктов паспорт с моята ERP или система за управление на складове?

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

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

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

Член 10 на ESPR (Регламент (ЕС) 2024/1781) описва дигиталния продуктен паспорт като набор от данни, които са четими и преносими чрез електронни средства. Това е различно изискване от „красива страница, която се отваря след сканиране на QR код". За предприятие с 10 до 100 служители това означава, че данните в паспорта трябва да бъдат достъпни и като структурирани данни — не само като текст на уеб страница. Дали и как това се свързва със собствена ERP или система за управление на запасите е избор на самото предприятие; регламентирането не налага свързване, но налага набор от данни, който позволява такова свързване.

Взаимодействието между системите е основен принцип, а не технически избор на доставчика

Член 11 на ESPR се отнася до техническия дизайн и функционирането на дигиталния продуктен паспорт и посочва взаимодействието като един от основните принципи, на които системата за паспорти трябва да отговаря. Това пряко засяга въпроса дали свързването със собствена система е възможно: паспорт, настроен в съответствие с този член, по принцип е предназначен за обмен на данни между системи, а не за затворена среда. На практика предприятието забелязва това особено при въпроса кои формати на данни и кодове за идентификация използва платформата и дали те съвпадат с тези, които вече използва собствената ERP система.

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

Свързването между продуктен паспорт и вътрешна система зависи от непрекъсната идентификационна кода за всеки продукт или партида. Без еднозначен кодекс за свързване свързването на ERP в практика е трудно да се автоматизира, дори и това да не е изрично посочено в текста на член 10 или 11. Как се изгражда и присвоява този идентификационен код е описано на страницата за как да дадете на всеки продукт уникален идентификационен код. За предприятие, което продава алуминий по партида, това е свързано и с въпроса дали регистрацията се извършва по партида или поштучно, което е по-подробно разработено на страницата за регистрация по партида или поштучно.

Паспортът остава, дори ако вътрешната система се променя

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

Където нещата се объркват в практиката

Няколко ситуации често се появяват при предприятия, които обмислят свързване между паспорт и собствена система:

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

Какво можете да документирате

За предприятия, които обмислят свързване между паспорта на продукта и собствена система, е практично да определят вътрешно следните точки — дори и ако свързването все още не е изградено:

• Кои полета в ERP или инвентарната система съответстват на кои полета в паспорта на продукта, включително идентификационния код, използван за всеки продукт или партида.
• Кой в предприятието е отговорен за актуализирането на данни, които се използват както вътрешно, така и в паспорта.
• Договореност относно момента, в който данните от вътрешната система се преговарят в паспорта, и момента, в който това явно не се случва автоматично.
• Документация относно това кой система служи като източник за кои данни — така че при проверка или въпрос от клиент да бъде ясно откъде идва цифра или характеристика.
• Обзор дали паспортът е настроен за единица или за партида, тъй като това определя как свързването с инвентарните редове може най-добре да бъде устроено.

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