З 1 липня 2019 року в Росії введено обов'язкове маркування групи товарів. З 1 березня 2020 року під цей закон мало потрапити взуття. Не всі встигли підготуватись, і в результаті запуск перенесли на 1 липня. Lamoda серед тих, хто встиг.
Тому ми хочемо поділитися досвідом з тими, хто ще тільки має маркувати одяг, шини, парфуми і т.д. У статті описано низку галузевих стандартів, деяку нормативну документацію та особистий досвід. Стаття призначена в першу чергу для інтеграторів і розробників, які тільки мають розбиратися в цьому проекті.
Зверніть увагу, що нормативна база часто змінюється, і автор не має можливості постійно оновлювати матеріал. Тому на момент прочитання частина інформації може вже застаріти.
Особистий досвід отриманий автором як у рамках роботи з проекту Datamatrix в Lamoda, так і при розробці власної безкоштовної програми для маркування BarCodesFx.
З 1 липня 2019 року в Росії діє закон про обов'язкове маркування. Закон поширюється не так на всі групи товарів, і терміни набрання чинності обов'язковим маркуванням для товарних груп різняться. Нині під обов'язкове маркування потрапляють тютюн, шуби, взуття, ліки. Найближчим часом буде вводитися для шин, одягу, парфумів та велосипедів. Кожна група товарів регулюється окремою ухвалою уряду (ППР). Тому деякі твердження, правильні взуття, можуть бути неправильними інших груп товарів. Але можна сподіватися, що технічна складова не сильно змінюватиметься для різних товарних груп.
маркуванняОсновна ідея маркування – кожній одиниці товару присвоюється індивідуальний номер. За цим номером можна відстежити історію конкретної одиниці товару з виробництва чи імпорту до країни, до вибуття на касі. Звучить красиво, але на практиці вкрай складно реалізовано. Детальніше концепт описаний на офіційному сайті чесного знаку.
Загальноприйняті терміни та поняття
УОТ - Учасник обороту товарів.
ЦРПТ - Центр розвитку перспективних технологій. Приватна фірма, єдиний держ. підрядник за проектом маркування. Працює за схемою державного приватного партнерства (ДПП). Інформації про інших учасників тендеру щодо проекту, як і власне про сам тендер, на жаль, немає.
ТГ - товарна група. Взуття, одяг, шини та ін.
GTIN - По суті, артикул з урахуванням кольоро-розміру. Видається в GS1 або нацкаталог для кожного імпортера або виробника на його товар. Попередньо виробник чи імпортер має описати цей товар.
ППР - Постанова уряду РФ. Для взуття – 860.
КМ - Код маркування. Унікальний набір символів, наданий конкретної одиниці товару. Для взуття складається з GTIN, серійного номера, коду перевірки та криптохвісту.
GS1 - Міжнародна організація, що видає GTIN-и. Також укладачі низки стандартів з маркування.
Нацькаталог - Аналог GS1, розроблений ЦРПТ.
Криптохвіст - аналог цифрового підпису, що підтверджує легальність КМ. Обов'язково має бути в датаматриксі на марці. Зберігання у текстовому вигляді заборонено. Після роздрукування марки має бути видалено згідно з договором із ЦРПТ. Невідомо жодного випадку реального використання.
СУЗ - Станція управління замовленнями. Система, в якій замовляються КМ для товару.
ЕДО - електронний документооберт.
УКЕП - Посилений кваліфікований електронний підпис.
Терміни та поняття в рамках даної статті
ЧЗ - Чесний знак.
ЛК - особистий кабінет.
Марка - Надрукований код маркування.
Процес виглядає наступним чином: спочатку учасник (УОТ) випускає електронний підпис (УКЕП), реєструється в чесному знаку (ЧЗ), описує товар у нацкаталогу або GS1, отримує GTIN на товар. На сайті чесного знаку ці кроки докладно розписані, тому на них не зупинятися.
Замовлення та отримання кодів
Після отримання GTIN-ів учасник (УОТ) робить замовлення кодів (КМ) у системі СУЗ.
Важливо, але не очевидно.
- В одному замовленні можна запросити коди максимум для 10 GTIN-ів. У принципі, незрозуміле обмеження. Імпортеру з 14 000 GTIN-ами доводиться створювати 1400 замовлень.
- В одному замовленні можна запропонувати максимум 150 000 кодів.
- Є обмеження на 100 замовлень у роботі. Тобто, одночасно в обробці може бути не більше 100 замовлень. Якщо буде більше 100, API почне повертати помилку замість списку замовлень. Єдиний спосіб усунути цю помилку – закрити частину замовлень через веб-інтерфейс. API не містить параметра для часткового відображення замовлень.
- Є ліміт за кількістю звернень – не більше 10 запитів на секунду. За моїми даними, у документах це обмеження не фігурує, але воно є.
З особистого досвіду роботи із замовленнями кодів маркування КМ через API системи СУЗ.
- Запит (сам json) необхідно підписувати ГОСТ-івським підписом. Це робота з криптопро. Треба уважно стежити, щоб використовуваний фреймворк чи бібліотека ні на байт не змінили початковий json. Інакше підпис одразу перестає бути валідним.
- Підпис замовлення. Замовлення може бути підписане будь-яким підписом, будь-яким клієнтом. Якщо підпис валідний, то система СУЗ її прийме. Під час інтеграції вдалося підписувати запит чужим підписом, випущеним на тестовому УЦ. Бойовий контур СУЗ-а замовлення обробив та випустив коди. На мій погляд, це дірка у безпеці. На баг-репорт розробники відреагували подивимося. Сподіваюся, виправили.
Тому будьте дуже уважні, якщо на одному робочому місці працює більше одного юр. особи. Сьогодні СУЗ прийме ці запити, а завтра запити перевіряють ще раз і відкликають половину кодів через чужий підпис. І в принципі, формально мають рацію.
- Автопідписання замовлень - це функціонал більш недоступний у СУЗ. Для його роботи потрібно завантажувати закриту частину ключа в особистому кабінеті чесного знака. Це компрометація ключа. І згідно з чинним законодавством, у разі компрометації посиленого кваліфікованого електронного підпису власник має поінформувати свій посвідчувальний центр (УЦ) та відкликати УКЕП. Якщо цей функціонал повертатимуть, уважно слідкуйте, щоб закрита частина ключа не залишала комп'ютер.
- У лютому центр розвитку перспективних технологій (ЦРПТ) мовчки ввів обмеження кількості запитів до API СУЗ. Не більше одного запиту на секунду. Потім так само зненацька і мовчки це обмеження зняв. Тому рекомендую закласти у систему можливість обмежувати кількість запитів до API ЦРПТ у разі рецидиву. Зараз є інформація про ліміт у 10 запитів на секунду.
- Також у лютому без попередження значно змінилася поведінка API СУЗ. API має запит на отримання статусу замовлень. У статусі вказувалися буфери та його стан. Один GTIN = один буфер. Там же вказувалося, скільки кодів доступне для отримання буфера. Одного дня у всіх буферів кількість стала -1. Довелося через окремий метод опитувати стан кожного буфера окремо. Натомість одного запиту довелося робити одинадцять.
Структура кодів
Отже, коди замовлені та згенеровані. Їх можна забрати через api у текстовому вигляді, у pdf як етикетки для друку та як csv файл із текстом.
Про API вже було написано вище. Щодо двох інших способів. Спочатку СУЗ дозволяв забрати коди лише один раз. І якщо забирався pdf-файл, то отримати коди в текстовому вигляді можна було лише пересканувавши всі датаматрикси з pdf. На щастя, додали можливість кілька разів забирати коди, і ця проблема вирішилася. Протягом двох днів коди ще доступні для повторного скачування.
Якщо забираєте в CSV форматі, то ніколи, за жодних обставин, не відкривайте його в екселі. І нікому не дозволяйте. У екселі є функція автозбереження. У момент збереження ексель може непередбачуваним чином видозмінити ваші коди. Рекомендую використовувати notepad для перегляду кодів.
Якщо відкрити файл із СУЗ до notepad++, можна побачити рядки такого виду. Третій код – невалідний (у нього відсутні роздільники GS).
Партнери надсилали нам коди для маркування свого товару. Неозброєним поглядом видно, які файли формувалися за допомогою екселю – до 5% кодів були невалідними.
Настійно рекомендую почитати про GS1. В описі стандарту є відповіді на багато питань щодо формування DataMatrix.
Код ідентифікації складається з GTIN та серійного номера. Відповідно до стандарту GS1 їм відповідають ідентифікатори застосування (ІП) 01 та 21. Зверніть увагу, ідентифікатори застосування не є частиною GTIN та серійного номера. Вони вказують на те, що після ідентифікатора застосування (ІП) йде GTIN або серійний номер. Це особливо важливо під час програмування касового ПЗ. Для заповнення тега 1162 потрібні саме GTIN та серійний номер, без ідентифікаторів застосування.
Для УПД (універсального передавального документа) та інших документів, навпаки, найчастіше потрібна запис повністю з ідентифікаторами застосування.
У стандарті GS1 прописано, що GTIN має фіксовану довжину 14 знаків і може складатися тільки з цифр. Серійний номер має змінну довжину та описаний на 155 сторінці стандарту. Там є посилання на таблицю з символами, які можуть зустрічатися в серійному номері.
Оскільки серійний номер має змінну довжину, то роздільник GS свідчить про його закінчення. У таблиці ASCII у нього код 29. Без цього роздільника жодна програма не зрозуміє, коли закінчився серійний номер, і почалися інші групи даних.
Детальніше про код маркування (КМ) можна прочитати в .
Для взуття серійний номер зафіксований у 13 знаків, однак його розмір може у будь-який момент змінити. Для інших товарних груп (ТГ) довжина серійного номера може бути різною.
Генерація DataMatrix
Наступний крок – це перетворення даних у DataMatrix код. У постанові уряду РФ 860 зазначений ГОСТ, згідно з яким необхідно формувати DataMatrix. Також у ППР 860 зазначено обов'язкове використання ідентифікаторів застосування. Зверніть увагу, що у стандарті DataMatrix немає поняття «ідентифікатори застосування». Вони є лише у стандарті GS-1 DataMatrix. Виходить, що ППР 860 неявно зобов'язує використовувати саме GS-1 DataMatrix. На щастя, стандарти схожі. Основна відмінність: у GS-1 DataMatrix перший символ має бути FNC1. Символ GS не повинен стояти на першому місці в DataMatrix, тільки FNC1.
FNC1 не можна просто взяти і додати до рядка як GS. Його має додавати програма, що генерує DataMatrix. На ресурсах Альянс Форти викладено декілька , за допомогою яких можна перевірити правильність згенерованих DataMatrix кодів.
Важливо. Додаток чесний знак приймає невалідні DataMatrix. Навіть QR-коди. Той факт, що марка розпізналася та інформація про товар відобразилася, не є показником, що DataMatrix сформовано правильно. Навіть при заміні криптохвоста додаток ЧЗ розпізнав марку та відобразив дані щодо товару.
Пізніше ЧЗ випустили як правильно генерувати коди Через велику кількість кодів з помилками вони визнали коди без FNC1 валідними, але все-таки рекомендують генерувати GS-1 DataMatrix.
На жаль, досить великий відсоток датаматриксів від партнерів приходив помилково. Завдяки поясненням від ЧЗ було повністю вирішено питання "Чи можна торгувати таким товаром після 1 липня чи ні?". Спойлер – можна.
Друк
Зверніть увагу на спосіб друку марок. Під час друку на термопринтері марка швидко вицвітає, і цей товар вже не можна продавати. Марка, що не читається, — це порушення ППР 860. Що веде до вилучення товару, штрафів, кримінальної відповідальності.
Використовуйте термотрансферний друк. У цьому випадку марка не так сильно схильна до вицвітання. Від матеріалу етикетки також залежить, наскільки марка схильна до механічних пошкоджень. Якщо код не зчитується через механічне пошкодження, це рівнозначно відсутності марки з усіма наслідками.
Вибирайте принтер із запланованих обсягів друку. Настільні принтери не розраховані на друк 100 000 етикеток на день.
Зупинка та старт друку підвищують знос принтера. Деякі програми надсилають завдання на друк по одній етикетці. Такими програмами краще не скористатися.
Робота з документами
Після того, як марки роздруковані та наклеєні, всі подальші операції з ними відбуваються через документи чи особистий кабінет чесного знаку.
При роботі з великою кількістю кодів можна створювати XML файли, в яких будуть потрібні коди, і завантажувати ці файли через API або веб-інтерфейс особистого кабінету.
XSD схему можна завантажити в розділі "допомога" в ЛК ЧЗ.
Зверніть увагу на такі моменти.
- Xsd схеми в ЛК ЧЗ містять помилки у валідації ІПН та обмеження на довжину рядка. Тільки виправивши помилки, можна скористатися схемами. На щастя, помилки очевидні, тож це зробити не складно.
- Схема найчастіше і двох частин — загальна всім типів документів і окрема конкретного типу. Загальна схема додана через імпорт до конкретної. Обидві схеми розміщені у розділі допомоги у ЛК ЧЗ.
- Правила екранування для КМ відрізнятимуться від загальноприйнятих для XML, про це написано в офіційній документації від ЧЗ, зверніть на це увагу. Ось на 4 сторінці всі правила.
- Не слід намагатися ввести 150 000 кодів одним файлом. За словами очевидців, файли більше 30 000 зазвичай проходять.
- Xml файл можуть загорнути з помилкою “помилка валідації xml”, а через п'ять хвилин той самий файл прийняти без проблем.
- Якщо у файлі виявляється вже введений код код, то файл введення в обіг, швидше за все, не приймуть.
- Документи відвантаження та приймання використовуються як тимчасове рішення. Надалі їх планують скасувати та перейти на УПД згідно з ППР 860.
- Міф про 60 днів. Ходить думка, що не введені в обіг коди згоряють через 60 днів. Це міф, джерело невідоме. Коди «згоряють», лише якщо ви не забрали їх із СУЗ протягом 60 днів. Термін життя забраних кодів не обмежений.
Висновок
При розробці мого безкоштовного додатка для маркування BarCodesFX, спочатку було зроблено інтеграцію з API СУЗ. Коли чесний знак вдруге змінив логіку роботи API, від інтеграції довелося відмовитися. Сподіваюся, надалі ЧЗ вдасться стабілізувати розробку та API, т.к. для некомерційного продукту мені дуже витратно щодня перевіряти ще раз, чи не було змін в API, і оперативно доопрацьовувати.
При введенні маркування уважно ознайомтеся з нормативною документацією по товарній групі ТГ, правильно друкуйте GS1-DataMatrix і будьте готові до будь-яких непередбачених змін з боку чесного знака ЧЗ.
Альянс Форта створив інформаційний простір (, у телеграмі, семінари, вебінари), де ви можете знайти корисну та актуальну інформацію з маркування у всіх галузях.
Джерело: habr.com