В этом году вышло сразу несколько статей о практике работы с новой системой маркировки “Честный знак”. Написаны они “айтишниками” IT-отделов компаний-участников оборота, что отражает их взгляд на ход пилотного проекта и первые дни запуска боевой системы.
Систему часто критиковали и критикуют, в основном из-за частых изменений API, багов личного кабинета и белых пятен в некоторых процессах.
Мы решили, пусть и не первыми, опубликовать свой опыт и свои мысли об этом новом амбициозном проекте государства, в котором мы активно участвуем.
Кратко о нас
Клеверенс занимаемся софтом для мобильных работников, в основном под специальное оборудование терминалов сбора данных (ТСД) и регистраторов выбытия (РВ).
Кому-то может показаться, что вот есть лес, в лесу дерево, на дереве жук, а на жуке живет микроб, и ниша софта для ТСД — это про микробов на жуке.
На это можно ответить, что мобильность персонала — очень крупный растущий рынок, а специальное железо с готовым софтом — это вообще будущее всего текущего железа. В конце концов, любая реально прорывная штука — это результат многих лет труда в узкой нише (см. известное интервью Андрея Дороничева про мобильный YouTube).
В основном продукты Клеверенс продаются с уже готовой интеграцией со всеми стандартными конфигурациями типа УТ, УПП, ERP, КА, EYA, Розница и т.п., а также с отраслевыми типа Штрих-М и Далион, которые (интеграции) мы сами же пишем и поддерживаем (например, Склад 15).
Что такое система маркировки и “Честный знак”
Грубо говоря, это государственно-частный интернет вещей на штрихкодах и RFID для тотального прослеживания движения единиц товаров.
По системе маркировки существует очень много информации, главным ресурсом является сайт «Честный знак».
Отношение участников рынка к маркировке
Не секрет, что отношение участников рынка к маркировке полярное. От “Россия, вперед!” и “Идея хорошая, но реализация подкачала” до “опять маленьких обижают”.
Из плюсов называется обеление рынка и контроль цепочек поставок. Из минусов — снятие с ЕНВД при торговле маркированным товаром.
Практически весь крупный бизнес за маркировку. Мелкие предприниматели, которые хотят работать красиво и в белую — тоже за маркировку, для них это конкурентное преимущество перед серыми рынками.
Против маркировки в основном малый и средний бизнес, который считает всё это лишней нагрузкой для себя.
А мелкий бизнес ждет обновлений от 1С и надеется, что его просто не заметят и не будут трогать.
Претензии в основном формулируются как “снова душат малый бизнес” или “у вас столько денег и людей, могли бы сразу сделать то-то и то-то”, “бизнес-процесс такой-то не продуман”. Хотя именно на малый бизнес и его процессы были потрачены основные деньги — это сайт с личным кабинетом участника, облачный регистратор эмиссии кодов и т.п.
Отдельно стоит позиция айтишников, о ней ниже.
При этом информационный портал «Честного знака», на котором публикуется информация, сделан просто отлично. Например, где найти информацию на английском языке? Вот тут https://chestnyznak.ru/en/. А на китайском? Вот тут https://chestnyznak.ru/cn/.
Проблемы на старте, о которых все говорили
Пока шел пилот, в системе было много багов. В основном их успели излечить до 1 июля 2020.
Обещали, что на старте будет работать лучше ЕГАИСа, и в целом правда доступность сервиса выше. Из хорошего: выбытие работает почти всегда. ЕГАИСу на это понадобилось 3 года.
Сейчас в табаке и обуви система всегда доступна, всё отрабатывает быстро, кроме редкого выключения на технологические работы вечером на пару часов.
Но ключевая проблема на старте была в том, что “не запрягши не поедешь”, а 99% числа участников оборота (по количеству) тупо игнорировали эту систему, не регистрировались, не давали нагрузку, ждали судного дня, а потом требовали переноса сроков.
Еще летом 2019 года мы тестировали нагрузку в нашей “Кировке” и смотрели, как маркировка отреагирует на заказ и выпуск 10 млн кодов, единоразово (сейчас уже так делать нельзя). Процесс занял меньше 10 минут.
Но тогда в системе было зарегистрировано крайне мало участников, и было видно, что народ начнет шевелиться чуть ли не в самый последний день.
Об этой проблеме все знали, к ней готовились, но когда подошел дедлайн по обуви, всё равно случился коллапс. Некоторые УОТы кинулись выписывать себе бесплатные коды на остатки на 20 лет вперед, это в пике дало увеличение нагрузки на сервера в х40 раз. Такие игрища, конечно, даром не пройдут, потому что система цифровая и, что называется, “все ходы записаны”.
К сожалению, пострадали и пионеры маркировки — это те компании, которые с первого дня были в пилоте маркировки, добросовестно старались, но в конце тоже просили о переносе сроков.
Тут надо сказать, что государственная система — это не айфончик, чтобы с первого дня продаж вызывать восторги. И цель её создания была не в том, чтобы собирать лайки от айтишников или снимать видео-обзоры по типу “вот когда выйдет, тогда и посмотрю, решу для себя, надо ли покупать”.
Почему-то люди ждут, что с первого дня система будет работать так, как будто ей уже 5 лет в продуктиве.
До сих пор встречаются и вот такие ошибки:
Т.е. требования к правильности заполнения карточек товаров в 1С выросли теперь многократно.
Вообще, если ждать по такой логике, когда всё будет идеально, то надо всё переносить на 2030-й, а лучше на после покорения Марса, ага.
Позиция айтишников
Позиция айтишников не “за” и не “против”, а “дайте”. Требуют заранее анонсировать все изменения, требуют лучшей документации, больше тестовых примеров, песочниц, меньше ограничений.
В целом в проекте много разного железа и международных стандартов, что приносит классическим айтишникам одни только боль и страдания.
Айтишники — очень въедливые и умные люди, со своим мнением по любому вопросу. И никакого единого мнения по поводу маркировки, кроме претензий по работе API, в общем-то нет.
API системы меняется чаще, чем этого хотелось бы для сценария “сделал и забыл”. Но при этом считается, что в API надо надобавлять еще кучу методов для работы с групповыми упаковками (агрегатами), для упрощенной авторизации и т.п., но это опять означает изменние API.
Например, для работы стандартных концигураций 1С очень важно, чтобы в API был быстрый и надежный метод получения содержимого агрегатов той продукции, которая отгружена тому участнику, который её принимает (это касается и лекарств, и сигарет, и шин).
Мы сами айтишники, и у нас такая же двойная позиция, что в API не хватает методов, но при этом API меняется слишком часто. Тут, как говорится, “флаг расистский, но это наша история”.
В общем, API улучшать надо, но желательно предупреждать об этом за 1-2 месяца и давать людям время на внесение изменений в свои системы. А то было время, когда на боевом контуре табачной маркировки стояла более новая версия API, чем в тестовом контуре.
Технические аспекты маркировки
Технические проблемы, с которыми сталкиваются айтишники, в основном сводятся к следующему списку:
- Сисадминские вопросы с УКЭП, которые были и будут до тех пор, пока есть фрагментация по версиям операционных систем и браузеров
- Кодерские вопросы, которые нельзя решить путем гугления на StackOverflow, потому что система новая и уникальная
- Внедренческие вопросы, когда люди пользуют “online barcode generator” или “сканер в разрыв клавиатуры”, а потом удивляются, почему вышла ерунда
Чтобы составить собственное мнение можно почитать техночат в телеге.
Система маркировки построена на международных стандартах, за исключением части с криптографией. Это отлично и достойно похвалы.
Посмотрите, тут и Java, и Reactive (RxJava), и Spring и даже Netflix:
К сожалению, средний айтишник никаких стандартов не читает ни про что не изучает, а сразу лепит свои велосипеды из бесплатных компонентов про генерацию штрихкодов, печать, бизнес-процессы и т.п.
Первая же трудность — распечатать штрихкод маркировки в своём дизайне. Из коробки “Честный знак” предоставляет бесплатный инструмент, но с ним никто, конечно, разбираться не стал, ведь есть “online barcode generator” и встроенные редакторы отчетов в 1С/SAP/NAV/DAX.
Правда скажем, в личном кабинете были свои проблемы с этим редактором этикеток:
Засада в том, что современный штрихкод — это не просто графическое представление символов (об этом у нас выйдет отдельная статья). Сразу всплыли проблемы префиксов, разделителей, кодировок, обязательных непечатемых символов и прочее такое, про что никто знать не знал и разбираться не хотел.
Пример со спецсимволом GS (ASCII 29)
Пример со спецсимволом FNC1 (ASCII 232)
Скриншот сделан из приложения «Чекмарк».
Откуда взялись спецсимволы? Из международного стандарта! «Честный знак» сделали всё по стандарту, и участникам оборота товаров тоже надо бы почитать стандарт.
Т.к. системная интеграция — это не про программы, а про людей и про то, как они пишут и читают спецификации, то наличие этих спец символов сразу привело к некоторому разногласию при обмене штрихкодами.
Например, могли, особо не вчитываясь в спецификации, добавлять в штрихкод строку из 4 символов “FNC1” вместо одного символа ASCII 232 (FNC1). А еще, при обмене между подсистемами такие символы часто фильтруются и теряются, до печати доходят уже без таких символов, при этом в обычных текстовых редакторах спец. символы часто не отображаются и люди удивляются, почему же что-то не так, если штрихкоды совпадают.
Так же, если не указывать символ FNC1 в штрихкоде, некоторое оборудование или ПО может не понять что это такое и как его разбирать, т.к. этот символ вначале штрихкода как раз указывает на то, что это формат GS1 DataMatrix.
Один из последних примеров, на котором споткнулись почти все, было появление скобок и знаков препинания в серийном номере.
Откуда в серийном номере скобки и знаки препинания? Из стандарта! Стандарт GS1 позволяет их использовать. Т.к. серийный номер в длину имеет всего 13 символов, а товаров под маркировку очень много, приходится использовать все доступные символы.
Отдельные лулзы — скобки в серийном номере. Они там разрешены стандартом, но никто их не ждал. В так называемой человеко-читаемой форме представления (HID) скобки имеют специальный смысл: они обрамляют номера значимых групп символов. Например, “(21)” означает, что дальше в строке будет идти серийный номер.
Если наивно думать, что в штрихкоде закодирована просто строка человеко-читаемых символов, то в строке “(21)abcd12(3)d(1,(91)” серийным номером видится строка “abcd12”, а часть про “(1,” кажется вообще ошибкой. На самом деле серийный номер тут “abcd12(3)d(1,”, а после запятой стоит нечитаемый символ GS. И дело не в том, что серийный номер должен быть 13 символов (потому что формально длина серийника в GS1 DataMatrix может быть другой, и в шинах, например, она бывает 20 символов).
Дело именно в невидимом GS, который надо учитывать, и который в полях любой учетной системы не выводится, не принимается для ввода и вообще запрещен (и в обычном Блокноте его тоже не видно, не выводится, нужен Notepad++).
В итоге фирма 1С решила в новой версии стандарта на сканеры и ТСД передавать все штрихкоды в Base64.
Сейчас почти исправили свои компоненты печати штрихкодов, наверное. Кто вообще читает стандарты, правда?
На проверку, домашнее задание: вот эта тема, что если поле фиксированной длины, то GS вставлять не нужно, а если длина переменная, и значение поля не максимальной длины, то вставлять нужно. На самом деле это правило работает не так. Спецсимвол GS не вставляется только если AI начинается с пары цифр из этой вот таблицы:
А во всех остальных случаях вставляется. Ваш код генерации/разбора ШК работает так же?
А еще наличие неожиданных символов приводит вот к таким ошибкам:
Еще одна проблема — сканирование штрихкода маркировки ламерскими средствами типа “сканер в разрыв клавиатуры”. До маркировки самой большой проблемой было, что где-то обрезается или вставляется лишний ноль. Со введением новых кодов маркировки тулзы со сканированием выведены на совершенно новый уровень.
Зачастую это не проблемы самого сканера или его настроек, а проблемы с отсутствием опыта и понимаем принципов штрихкодирования. Решается сейчас повсеместным переводом работы сканеров в режим COM-порта.
Например, при подключении сканера «в разрыв клавиатуры» (или при эмуляции такого режима), а также при подключении сканера как HID-устройства, возможны проблемы с заменой одних символов в считанном штрихкоде на другие или пропадание определенных символов.
Схема подключения сканера в разрыв клавиатуры
При работе в указанных режимах сканер передаёт компьютеру не сами символы из штрихкода (sic!), а коды нажатий клавиш клавиатуры, которые нужно было бы нажать, чтобы набрать на клавиатуре символы из этого штрихкода.
При этом очевидно, что одной клавише клавиатуры может соответствовать сразу несколько возможных символов, в зависимости от языка раскладки и нажатий клавиш-модификаторов (Shift, Caps Lock, Alt и Ctrl).
Например, при нажатии на вот эту клавишу в нижней правой части клавиатуры:
результатом может быть любой из символов ‘?’, ‘/’, ‘,’ или ‘.’, в зависимости от выбранной раскладки и использования клавиш-модификаторов. Какой конкретный введётся символ — определяется настройками клавиатуры операционной системы, а не сканером.
Именно из-за этого вместо одних серийников на кассе выбывают совершенно другие, либо код вообще “не найден”.
Кстати, этих проблем можно было бы избежать, если бы в серийный была чексумма, когда по последней цифре можно проверить, правильный ли код, правильно ли он считался/ввелся. У расчетных счетов, ИНН, номеров карт, у EAN13, у всего последняя цифра является чексуммой для проверки, чтобы люди и машины не ошибались при вводе.
Очевидно, тут понадеялись на то, что DataMatrix самопроверяемый, плюс есть криптохвост. Но одно дело весь штрихкод, самопроверяемый, и другое дело огрызок кода с серийником, который вообще могли ввести с клавиатуры.
Отдельные споры айтишников вызвал так называемый «криптохвост».
«Криптохвост» — это необходимая часть штрихкода маркировки, благодаря которой можно по симметричному ключу проверить, что серийный номер единицы товара не высосан из пальца.
Криптохвост есть только в штрихкоде и не хранится в базе маркировки, чтобы никакой хакер не мог подломить базу и печатать чужие штрихкоды.
Т.е. это своеобразная цифровая подпись. Но т.к. штрихкод не резиновый, а товаров много, то длина этой цифровой подписи небольшая, что не позволяет пользоваться открытыми для всех ключами шифрования.
Конечно, все серийные номера лежат в базе данных маркировки, но если проверять по ней в онлайне, то при любом падении интернета сразу встанут все склады и магазины.
Криптохвост призван решить эту проблему, но пока (на лето 2020 года) не заработал в полную силу.
Дело в том, что криптография российская и привязана к железкам. Но альтернативы российской крипте всё равно нет, государственная российская система не может использовать иностранную крипту, это будет дыра. Поэтому придется терпеть российскую, это разумно и не сложно.
Вообще криптография - тема очень сложная. Информации много и очень тяжело найти описание того, как нужно подписать или зашифровать данные в конкретном случае.
С этим столкнулись все, кто попробовал интегрироваться с API маркировки. Было очень много вопросов в чатах типа “Почему не авторизуется?”, “Как подписать?”, “Поделитесь примером!”, “Подпись сформировали но приходит отказ, почему?” и много других.
Чаще всего ошибки были банальны. Например, после подписи изменяли данные, либо терялся пробел или как-то несущественный символ, но для подписи это критично, и после отправки в API приходил отказ без объяснений, т.к. подпись не проходила проверку.
К счастью в чатах чаще всего помогали и отвечали на такие вопросы. В целом, все эти проблемы лечатся или уже были излечены к 1 июля 2020.
В части “Честного знака” к 1му июля 2020 весь процесс от производства товара до его выбытия через кассу или доставку интернет-магазина был продуман, расписан, протестирован и запущен в боевом контуре. Например, у нас есть видеоролик такого сквозного процесса для молочной продукции.
Что мы сами думаем о маркировке
Мы в Клеверенсе думаем, что софтовые проблемы не главное. Хуже то, что участники оборота товаров до сих пор не понимают сути изменений. Это гораздо большая проблема, чем софтверные баги.
Люди относятся к маркировке как к еще одному бухгалтерскому отчету, который можно составлять сидя у компа в 1С/SAP/NAV/DAX, корректировать, менять задним числом и т.п. Типа пользоваться будут бухгалтеры и логисты, а айтишники должны “запилить” под это нужные модули и обработки.
Главный запрос наших клиентов в том, чтобы склад/китайцы/тетямаша что-то насканировали, а потом это “корректно” загрузилось в 1С/SAP/NAV/DAX. И мы это успешно делаем.
Но это очевидная ошибка, которая вскроется, когда компании начнут сводить остатки друг с другом, а государство начнет штрафовать.
Что такое на самом деле система маркировки
Маркировка товаров — это система отражения реальных движений.
Реальные проблемы маркировкой
Это чисто наше IMHO.
Все реальные проблемы автоматом вытекают из того, для чем на самом деле является система маркировки, а именно, системой отражения реальных движений.
Во-первых, реальный учет движений противоречит текущим принципам учета по всей цепочке, когда всё учитывается по SKU, по партии или по среднему. Задним числом сводить и исправлять — наше всё.
Учетная система в любой компании — представляет собой причесанную и исправленную сказку о том, как всё здорово получилось после 100500 созвонов, исправлений, перепроведений и вычищения ошибок.
На одной из расширенных встреч у крупного иностранного дистрибутора лекарств только после часа обсуждения главный логист, наконец, округлил глаза и сказал “это что же, разные штрихкоды у каждой пачки?”. А слова “уникальный”, “серийный номер”, “каждый экземпляр”, “всё сканировать” и т.п., видимо, пролетели мимо.
Во-вторых, реальный учет движений противоречит текущим бизнес-практикам и принципам разделения ответственности.
Даже если компания крупная и у сотрудника нет прав на правку каких-то документов — есть телефон, можно позвонить или написать тому, кто может поправить.
Или, например, документы подписываются КЭП директора каким-то низовым сотрудником, а если есть двухэтапная аутентификация, то через пересылку SMS. В системе маркировки есть блок про пользователей и их права, можно выдывать всем отдельные КЭП, но люди этого делать не спешат.
Это явная проблема, которая будет решаться предоставлением всё больших прав и инструментов учета тем простым сотрудникам, которые находятся прямо рядом с маркированным товаром.
Сверх того, правила расчета себестоимости или учета движений в учетной системе основаны на усреднениях и упрощениях типа FIFO/LIFO и средней цены. И те принципы учета, которые повсеместно десятилетиями применяются от производства до розницы, основаны на этих упрощениях и идут в разрез с реальным прослеживаем уникальных единиц.
Из-за этого на практике получается, например, что в систему маркировки товары отправляются по FIFO/LIFO, а реально отгружается то, что стояло ближе в выходу.
Это тоже решается специальным оборудованием и софтом для простых сотрудников, которые по роду своей работы не могут сидеть у компа.
Еще одна проблема — это попытка “натянуть сову на глобус” и втащить коды маркировки во все стандартные документы ERP, чтобы там их видел бухгалтер, логист или ответственный менеджер.
Хотя смотреть ему на них не за чем, сделать он с ними ничего не может.
И правда, ну как может бухгалтер или менеджер, глядя в монитор может понять, что там вчера насканировал склад, и почему тут выделенные красным расхождения по трем штучкам сигарет из тысяч?
Это тоже решается инструментами для низового персонала с доступом ко всей нужной информации.
Ну т.е. это не технические проблемы каких-то систем, которые в целом к 1 июля 2020 уже были исправлены, а вопросы перестройки работы компаний на новые рельсы.
Выводы
Самый главный плюс маркировки в том, что государство заставило всех цифровизироваться и переходить на ЭДО с цифровыми подписями и криптографией.
«Прилив поднимает все лодки», и переход всего рынка на общие рельсы дает большой синергетический эффект.
Всем удачной автоматизации!
