Блог компании клеверенс

Число зверя, штрихи смерти насколько все это реально? Можно ли зашить в штрихкод видеоролик или фото голой Эммы Уотсон? Бывают ли неправильные штрихкоды, и что вообще значит неправильный штрихкод?

В Клеверенсе мы разрабатываем платформу Mobile SMARTS для создания мобильных решений по учету маркированного товара и постоянно сталкиваемся с детскими ошибками в маркировке. Обычно они вызваны простым нежеланием людей хоть немного разбираться в теме.

Наша платформа тоже не идеальна, но кое-что в своём деле мы понимаем. Статья не к тому, что типа мы крутые и разбираемся, а все вокруг не крутые и не разбираются, нет. У каждого свои задачи, мы тоже часто лажаем. Просто тема набирает популярность и выходит в массы, а любые ошибки стоят денег.

Сначала для затравки расскажем про кассовый штрихкод, а затем про загадочный GS1 DataMatrix, который используется в проекте тотальной маркировки товаров.

Сама статья больше развлекательная, всё изложенное при желании легко гуглится, но может и побудить кого-то изучить тему глубже.

Загадочные цифры под штрихкодом

Цифры под штрихкодом что это такое? Знающие люди говорят, что тут всё просто: именно эти цифры зашиты в штрихкод. Девушка на кассе вбивает в программу цифры под штрихкодом и вуаля товар найден.

К сожалению, это заблуждение. Цифры под штрихкодом не зашиты в штрихкод. Для разговоров у камина сойдет, а для айтишника беда.

Это распространенное заблуждение приводит к тому, что когда встает задача распечатать штрихкод, человек гуглит бесплатный онлайн генератор штрихкода, пихает в поле эти самые цифры, и получает проблему на ровном месте.

Надписи под штрихкодом называются Human readable interpretation (HRI). Одно только название уже должно наводить на мысль, что тут не всё в порядке.

В самом мягком варианте вера в то, что цифры под штрихкодом повторяют содержимое штрихкода это примерно как верить в то, что название файла определяет его содержимое. Типа: Переименовала ваш файл в .doc, но он всё равно не открывается.

Рассмотрим подробнее, где тут собака зарыта.

Кассовый штрихкод

Пример про кассовый штрихкод для затравки. Он на самом деле не вызывает никаких проблем, потому что за 50 лет использования в софте и оборудовании были вставлены 1000 костылей, чтобы обойти все проблемы (ну почти). Зато он хорошо иллюстрирует вопрос.

Вот в этих двух штрихкодах (EAN-13) ниже, под которыми написано 4601200000003 и 0123456789128, в обоих нет штрихов для первой цифры. В первом штрихкоде нет штрихов для 4 (она закодирована другим способом), а во втором штрихкоде вообще в принципе нет лидирующего нуля, хотя он и напечатан под штрихкодом.



Да-да, именно первой цифры, а не последней (чексуммы) как можно было бы подумать. Последняя цифра (чексумма) в полосках этих штрихкодов как раз-таки есть, иначе затея с чексуммой не будет работать.

Рассмотрим поближе, что тут происходит.

В первом приведенном штрихкоде (4601200000003) в начале идут две длинные полосочки, они кодируют начало штрихкода, далее идут штрихи и пропуски для цифры 6, затем про цифры 0, 1, 2, 0 и 0, две длинные полосочки в центре говорят про середину, затем пять одинаковых групп штрихов и пропусков кодируют 00000, далее идут штрихи и пропуски для цифры 3 и завершающие две длинные полоски про конец штрихкода. Итого, в штрихкоде есть штрихи только про 601200000003. Цифра 3 (последняя) в полосках штрихкода есть, а первой 4 нет! Откуда же взялась 4?

Дело в том, что 4 закодирована грязным хаком. Для неё не хватает места, и вообще всё это большой исторический казус.

Изначально такие кассовые штрихкоды появились в США, там они состоят из 12 цифр и называются UPC (Universal Product Code). Для переноса технологии в Европу и адаптации стандарта Европе нужны были дополнительные цифры, потому что американские 12 все уже были заняты.

Первым товаром, приобретенным по штрих-коду на этикетке, стал блок из 10 жевательных резинок Wrigley Juicy Fruit. Это произошло в супермаркете Marsh города Трой (Огайо) в четверг, 26 июня 1974 года в 8.01 утра. В историю вошли и имя покупателя, и имя кассира, открывших новую страницу розничной торговли. Теперь упаковка жвачки, которая тогда обошлась в 67 центов, вместе с чеком хранятся в музее американской истории Смитсоновского института.

Чтобы расширить емкость, можно было бы просто добавить еще немного штрихов и пропусков, но в те времена это серьезно ухудшало считываемость. Поэтому вместо того, чтобы просто увеличить штрихкод в ширину, был применен хак.

По американскому стандарту любая из цифр штрихкода может быть записана: а) обычными штрихами и пропусками; б) их зеркальным отражением; в) инверсией черного и белого; г) зеркальной инверсией. Всё это нужно для того, чтобы можно было печатать инверсные штрихкоды (белым по черному) и сканировать штрихкод вверх ногами (зеркальное отражение в случае штрихкода то же самое, что и поворот на 180).

В американском штрихкоде (который на 12 цифр) первые 6 цифр кодируются обычными штрихами, а вторые 6 цифр инвертированными штрихами (где черные штрихи заменены на белые полоски и наоборот). Это сделано для того, чтобы понимать, перевернут штрихкод или нет, нормально я его сканирую или вверх ногами (и затем декодировать цифры в правильном порядке, а не задом наперед).

В новом европейском штрихкоде (который на 13 цифр), первая цифра (например, 4) кодируется не штрихами, а путем перетасовывания способов кодирования следующих за ней 6 цифр из первого блока (второй блок из 6 оставили в покое).

Например, следующая за четверкой 6 выводится как обычно, штрихи следующего за ней 0 выводятся в обратном порядке (зеркально), следующие за ней 1 и 2 выводится снова в обычном виде, следующие два 0 снова зеркально. Общая длина штрихкода и число штрихов в результате этого трюка не меняется.

Для американского сканера такая белиберда не имеет смысла, а для Европы это тайный знак того, что в штрихкоде закодирована еще одна цифра! (да, мы всегда знали, что европейцы извращенцы).

Для всех цифр от 1 до 9 были придуманы такие правила тасовки способов кодирования. Для 0 ничего нет, т.е. 13-значный штрихкод с лидирующим нулем визуально ничем не отличается от 12-значного штрихкода без этого лишнего ноля (EAN-13 с лидирующим нулем эквивалентен UPC-А).

Из этого получается первый прикол, что если перед нами американский штрихкод (в котором варианты кодирования не перетасованы), то американский сканер читает 12 цифр, а условный европейский сканер может считать, что в нем есть лидирующий 0, и считывать лишний ноль (т.к. для кодирования ноля не предусмотрено никакой перетасовки, этого лидирующего нуля очевидно в принципе нигде нет в штрихкоде).

Конечно, мир давно глобализован, поэтому американский сканер и европейский сканер это просто условности. Сканер один и тот же, но у него есть настройка: нужно ли ему в принципе считывать EAN-13 (Европа) или читать только UPC-А (США), а если считывать EAN-13, то надо ли добавлять лишний ноль к американским штрихкодам UPC-А.

С этим связана одна распространенная проблема при внедрении штрихкодирования: когда в базе данных у компании либо нет нолей в начале штрихкодов, а сканер считывает с лишним нолем, либо наоборот, в базе данных есть ноль в начале, а сканер его не считывает (хотя, что там считывать, этого ноля в принципе в штрихкоде нет).

Казалось бы, сложно накосячить в использовании EAN-13/UPC. Тем не менее, люди делают следующие ошибки:

Сохраняют штрихкод в учетной системе без чексуммы (последнего знака).
Забывают обрабатывать присутствие/отсутствие лидирующего нуля при разработке алгоритма поиска по штрихкоду.
Требуют ввода 13 символов, а потом приходят сигареты с EAN-8 (с вводом маркировки табака станет неактуально, но пока так).
Не оставляют положенных широких белых полей справа и слева от штрихкода.

В наших программных продуктах, таких как Магазин 15 или Склад 15, построенных на платформе Mobile SMARTS, мы решаем эту проблему очень просто: сканер устройства всегда автоматически настраивается на возврат ноля, а поиск товара по базе данных производится два раза: и с нолем, и без ноля (чтобы уж точно найти товар).

Сканер мы стараемся настраивать программно, без участия человека. Если сканер нельзя настроить программно то это всегда проблема, потому что по умолчанию сканером может обрезаться не только 0 (который в начале), но еще и чексумма (которая в конце), тогда в программу придут не 13, а уже 11 символов, зачастую даже без указания типа штрихкода (такие замечательные сканеры тоже бывают).

В этом случае мы бессильны улучшить результат. 11 символов могли прийти от сканирования любого другого типа штрихкода, мы не можем считать все штрихкоды как EAN-13. Чтобы настроить сканер, человеку придется сканировать с листа настроечные штрихкоды или заходить в какие-нибудь меню, а всё это источники ошибок.

GS1 DataMatrix

Этот пример стал популярным благодаря введению обязательной маркировки товаров. История полна граблей, велосипедов и трупиков мелких животных, как сарай вашей бабушки.

Ну ладно, допустим с EAN-13 можно придраться и сказать, что первая цифра всё-таки есть в штрихкоде, просто она закодирована не совсем штрихами (хотя для лидирующего 0 это и не так).

Возьмем тогда другой пример, штрихкод GS1 DataMatrix "(21)abba01(01)04601200000003":



В этом штрихкоде внутри нет ни скобок, ни символа 0, ни буквы a, ни переноса строки.

Что тут происходит?

Во-первых, никакие скобки в штрихкод не кодируются, они печатаются только для удобства прочтения человеком. Это снова называется Human readable interpretation (HRI), привет, кожаный мешок.

Во-вторых, в штрихкоде есть специальные управляющие символы, которые должна расставить та программа, которая формирует данные для штрихкода. Не какая-то бесплатная opensource программа, написанная умными очкариками, а ваша программа, та самая, которую пишете Вы, мой друг. В этот раз символы, которые нужно вставить, не имеют отношения к коррекции и т.п., а размечают данные, которые нужно закодировать в штрихкод.

В самом начале в штрихкод вставляется управляющий символ, который называется FNC1 и имеет код 232, что соответствует либо странному печатаемому символу "" (ANSI), либо русской букве и (Windows-1251), смотря какую кодировку использовать. Этот символ говорит, что у нас не просто абы какой DataMatrix, а именно GS1 DataMatrix, данные в котором имеют определенный формат: массив данных из пар (код поля, значение поля).

Этот управляющий символ FNC1 попадает в самое начало штрихкода, но его нельзя передать в штрихкод в составе данных.

Кроме того, непечатаемые символы, вполне очевидно, нельзя копипастить в составе строки, хаха! Страдай, кожаный мешок!

Указание, нужен префикс или не нужен, обычно передают как отдельную настройку (галочку) в программу формирования штрихкода. Если передать префикс как часть данных, то получим либо ошибку, либо два префикса в штрихкоде (в зависимости от используемой программы).

Далее, поскольку в штрихкоде внутри нет скобок, то уже непонятно, где кончается одно поле и начинается другое, где тут номера полей. Без скобок получается 21abba010104601200000003 (тут 01 встречается три раза, ха-ха).

Где заканчивается 01 из значения поля (21) и начинается настоящее (01)?

Это решается следующим способом:

По стандарту GS1 поля имеют формат. Не абы что, а формат значения. Например, значение для (01) должно состоять из 14 цифр и баста (нельзя 13 цифр, нельзя 12 цифр, нельзя не цифры). А поле (21), наоборот, имеет переменную длину, разрешены цифры, латинские буквы обоих регистров, знаки препинания и даже (опачки!) скобки.

Если после значения для (21) штрихкод не закончился, и там еще что-то есть, то в данные вставляется разделитель (это может быть снова или FNC1, или непечатаемый символ GS с кодом 29).

А общее правило звучит так: спецсимвол GS не вставляется, только в случае если AI начинается с пары цифр из этой вот таблицы:



Для всех остальных полей GS1 (не из этой таблицы) в конце значения нужно вставлять GS.

Т.е., мы получим FNC121abba01GS0104601200000003 (только помним, что первый FNC1 мы не будем передавать в программу формирования штрихкода, а второй GS это не строка GS, а один символ с кодом 29).

Эти требования именно про данные, а не про штрихкод DataMatrix, потому что в штрихкод DataMatrix можно положить любые данные, они прекрасно закодируются и прочитаются. Тут речь о GS1 DataMatrix, который имеет определенный формат, и ваша программа должна соблюсти этот формат, прежде чем подавать данные в штрихкод.

Вообще говоря, в мире существуют программы печати штрихкодов, которым можно скармливать данные со скобками и они сами всё разрулят. Но это специализированный софт, который стоит денег, а не тот бестолковый и бесплатный онлайн-генератор штрихкодов, которым вы пользуетесь.

И наконец. То, как это будет напечатано и то, как это будет отсканировано, две большие разницы. То, как данные печатаются под штрихкодом, и как они передаются сканером это в чистом виде настройки принтера и сканера.

В нашем примере мы закодировали в штрихкод поля порядке: сначала (21), потом (01), а на изображении под штрихкодом распечаталось сначала (01), потом (21). Это снова называется Human readable interpretation (HRI), и порядок вывода в подписи соответствует правилу потому что так принято.

Сканер штрихкодов тоже имеет свои настройки, которые заставляют его переставлять поля, вставлять скобки и другие символы, переносить строки и т.п.

В большинстве случаев сканер прочитает наш штрихкод как 21abba01GS0104601200000003. Никакого лидирующего FNC1, никаких скобок, GS не печатаемый и не виден в Блокноте (нужно использовать хотя бы Notepad+).

И принтер, и сканер могут делать со штрихкодами что хотят: добавлять и убирать символы, менять их местами ради соответствия гайдлайну или для совместимости со сторонней программой.

Что еще интересно: в этом штрихкоде только 16 байт данных (на 24 символа без скобок).

Вот что тут происходит:

пары подряд идущих цифр кодируются одним байтом;
все отдельно стоящие цифры, не парные, а также все символы из таблицы ASCII (а это символы с кодами с 0 по 127, без русских букв, и печатаемые, и непечатаемые) кодируются в штрихкод как (значение байта символа)+1.

Т.е. чтобы закодировать a, нужно записать в штрихкод b, чтобы закодировать 1, нужно записать 2 и т.д., именно поэтому прямо в самом штрихкоде нет байта 97 (значение буквы a в ASCII).

Итого, в приведенном штрихкоде закодировано в байтах 232, 151, 98, 99, 99, 98, 131, 232, 131, 134, 190, 142, 130, 130, 130, 133. И это еще до кодов коррекции и паддинга!

Непонимание процесса кодирования приводит к тому, что, например, для начавшейся обязательной маркировки обуви люди печатают на принтер неправильно сформированные данные и получают неправильные штрихкоды, которые выглядят вполне нормально, читаются приложением Честный знак, но данные в них неверные, как минимум это не GS1 DataMatrix.

Штрихкоды неправильно напечатаны, неправильно читаются, и такая обувь не считается правильно промаркированной.

В своем софте Кировка мы боремся с этим следующим образом: для печати принимаем в качестве исходных данных любой мусор, пытаемся распарсить его как GS1 DataMatrix, разбираем на косточки. Если всё прошло удачно, то конвертируем в правильный формат, чтобы принтер это понял; а при сканировании перепроверяем данные от сканера, делая таким образом вывод о правильности печати.

Для этого нам, конечно, приходится работать на нативном уровне и со сканером мобильных устройств, и с принтерами, чтобы всё это было правильно ими интерпретировано, а мы собирали максимально полную информацию.

Выполним еще одно упражнение: посмотрим, какого размера должен быть штрихкод GS1 DataMatrix для хранения кода маркировки обуви и легпрома.

На сайте Честного знака написано, что код маркировки обуви должен содержать следующие поля (для легпрома те же требования):

Кода товара, 14 цифровых символов (GTIN).
Индивидуального серийного номера единицы товара, который генерируется оператором системы или участником оборота товаров, 13 символов (s/n).
Ключ проверки, предоставляемый оператором системы, 4 символа.
Код проверки, предоставляемый оператором системы, 88 символов.

Для каждого из этих полей в данных для штрихкода должен быть указан идентификатор применения GS1 (AI, application identifier).


Таблица codeword для DataMatrix.



Как видно, размер данных в теории может меняться в широких пределах от 68 до 118 байт. На практике разброс меньше, длина ближе к 118, потому что в серийном номере и в криптокоде мало цифр и много знаков препинания, включая скобки.

Согласно GS1 DataMatrix Guideline, такие данные укладываются в штрихкоды размером от 36х36 до 44х44 (колонок и строк битов, не миллиметров). В миллиметрах размер будет зависеть от разрешающей способности принтера (обычно это 203-600 dpi).


Таблица из GS1 DataMatrix Guideline

Пожалуй, достаточно.

А как же голая Эмма Уотсон? Рассмотрим в следующей статье.

В этом году вышло сразу несколько статей о практике работы с новой системой маркировки Честный знак. Написаны они айтишниками IT-отделов компаний-участников оборота, что отражает их взгляд на ход пилотного проекта и первые дни запуска боевой системы. Например, вот и вот.

Систему часто критиковали и критикуют, в основном из-за частых изменений API, багов личного кабинета и белых пятен в некоторых процессах.

Мы решили, пусть и не первыми, опубликовать свой опыт и свои мысли об этом новом амбициозном проекте государства, в котором мы активно участвуем.

Может показаться, что статья каша, но маркировка в целом такая каша и есть, очень много аспектов сходятся в одном месте.

Кратко о нас

Клеверенс занимаемся софтом для мобильных работников, в основном под специальное оборудование терминалов сбора данных (ТСД) и регистраторов выбытия (РВ).

Кому-то может показаться, что вот есть лес, в лесу дерево, на дереве жук, а на жуке живет микроб, и ниша софта для ТСД это про микробов на жуке.

На это можно ответить, что мобильность персонала очень крупный растущий рынок, а специальное железо с готовым софтом это вообще будущее всего текущего железа. В конце концов, любая реально прорывная штука это результат многих лет труда в узкой нише (см. известное интервью Андрея Дороничева про мобильный YouTube).

В основном продукты Клеверенс продаются с уже готовой интеграцией с учетными системами, которые (интеграции) мы сами же пишем и поддерживаем (например, Склад 15).

Весь софт и железо стараемся обкатывать на реальных производствах, складах, магазинах и т.д. Например, когда проект маркировки обуви только начинался поехали в Китай, чтобы обкатать бизнес-процессы, параллельно сняли видео об этом.

Что такое система маркировки и Честный знак

Грубо говоря, это государственно-частный интернет вещей на штрихкодах и RFID для тотального прослеживания движения единиц товаров.

По системе маркировки существует очень много информации, главным ресурсом является сайт Честный знак.

Отношение участников рынка к маркировке

Не секрет, что отношение участников рынка к маркировке полярное. От Россия, вперед! и Идея хорошая, но реализация подкачала до опять маленьких обижают.

Из плюсов называется обеление рынка и контроль цепочек поставок. Из минусов снятие с ЕНВД при торговле маркированным товаром.

Практически весь крупный бизнес за маркировку. Мелкие предприниматели, которые хотят работать красиво и в белую тоже за маркировку, для них это конкурентное преимущество перед серыми рынками.

Против маркировки в основном малый и средний бизнес, который считает всё это лишней нагрузкой для себя.

Претензии в основном формулируются как снова душат малый бизнес или у вас столько денег и людей, могли бы сразу сделать то-то и то-то, бизнес-процесс такой-то не продуман. Хотя именно на малый бизнес и его процессы были потрачены основные деньги это сайт с личным кабинетом участника, облачный регистратор эмиссии кодов и т.п.

Отдельно стоит позиция айтишников, о ней ниже.

При этом информационный портал Честного знака, на котором публикуется информация, сделан просто отлично. Например, где найти информацию на английском языке? Вот тут. А на китайском? Вот тут.

Проблемы на старте, о которых все говорили

Пока шел пилот, в системе было много багов. В основном их успели излечить до 1 июля 2020.

Обещали, что на старте будет работать лучше ЕГАИСа, и в целом правда доступность сервиса выше.

Сейчас в табаке и обуви система всегда доступна, всё отрабатывает быстро, кроме редкого выключения на технологические работы вечером на пару часов.



Но ключевая проблема на старте была в том, что не запрягши не поедешь, а 99% числа участников оборота (по количеству) тупо игнорировали эту систему, не регистрировались, не давали нагрузку, ждали судного дня, а потом требовали переноса сроков.

Еще летом 2019 года мы тестировали нагрузку в нашей Кировке и смотрели, как маркировка отреагирует на заказ и выпуск 10 млн кодов, единоразово (сейчас уже так делать нельзя). Процесс занял меньше 10 минут.

Но тогда в системе было зарегистрировано крайне мало участников, и было видно, что народ начнет шевелиться чуть ли не в самый последний день.

Об этой проблеме все знали, к ней готовились, но когда подошел дедлайн по обуви, всё равно случился коллапс. Некоторые УОТы кинулись выписывать себе бесплатные коды на остатки на 20 лет вперед, это в пике дало увеличение нагрузки на сервера в х40 раз. Такие игрища, конечно, даром не пройдут, потому что система цифровая и, что называется, все ходы записаны.

К сожалению, пострадали и пионеры маркировки это те компании, которые с первого дня были в пилоте маркировки, добросовестно старались, но в конце тоже просили о переносе сроков.

Тут надо сказать, что государственная система это не айфончик, чтобы с первого дня продаж вызывать восторги. И цель её создания была не в том, чтобы собирать лайки от айтишников или снимать видео-обзоры по типу вот когда выйдет, тогда и посмотрю, решу для себя, надо ли покупать.

Почему-то люди ждут, что с первого дня система будет работать так, как будто ей уже 5 лет в продуктиве.

Вообще, если ждать по такой логике, когда всё будет идеально, то надо всё переносить на 2030й, а лучше на после покорения Марса, ага.

Позиция айтишников

Позиция айтишников не за и не против, а дайте. Требуют заранее анонсировать все изменения, требуют лучшей документации, больше тестовых примеров, песочниц, меньше ограничений.

В целом в проекте много разного железа и международных стандартов, что приносит классическим айтишникам одни только боль и страдания.

Айтишники очень въедливые и умные люди, со своим мнением по любому вопросу. И никакого единого мнения по поводу маркировки, кроме претензий по работе API, в общем-то нет.

API системы меняется чаще, чем этого хотелось бы для сценария сделал и забыл. Но при этом считается, что в API надо надобавлять еще кучу методов для работы с групповыми упаковками (агрегатами), для упрощенной авторизации и т.п., но это опять означает изменение API.

Мы сами айтишники, и у нас такая же двойная позиция, что в API не хватает методов, но при этом API меняется слишком часто. Тут, как говорится, флаг расистский, но это наша история.

В общем, API улучшать надо, но желательно предупреждать об этом за 1-2 месяца и давать людям время на внесение изменений в свои системы. А то было время, когда на боевом контуре табачной маркировки стояла более новая версия API, чем в тестовом контуре.

Технические аспекты маркировки

Технические проблемы, с которыми сталкиваются айтишники, в основном сводятся к следующему списку:

• Сисадминские вопросы с УКЭП, которые были и будут до тех пор, пока есть фрагментация по версиям операционных систем и браузеров
• Кодерские вопросы, которые нельзя решить путем гугления на StackOverflow, потому что система новая и уникальная, несмотря на использование открытого ПО
• Внедренческие вопросы, когда люди пользуют online barcode generator или сканер в разрыв клавиатуры, а потом удивляются, почему вышла ерунда

Посмотрите, тут и Java, и Reactive (RxJava), и Spring и даже Netflix:



Чтобы составить собственное мнение можно почитать техночат в телеге.

Авторизация

Авторизация в ИС МП происходит в 2 этапа.

Сначала нужно запросить некий псевдослучайный ключ, который нужно подписать и отправить на урл /api/v3/auth/cert/ (причем на момент написания этого материала в конце url обязательно должен был стоять слэш /, иначе не работало, что выглядит странно).

Получение ключа происходит так (нужно подставить нужный хост, их много разных, в зависимости от того, песочница это или боевой, одежда или что-то другое):

// получаем на /api/v3/auth/cert/key ключ и данные, необходимые для авторизацииvar uri1 = new Uri("<нужный хост>/api/v3/auth/cert/key")var randomDataResponse = REST.Invoke<RandomDataResponse>(uri1, "GET", timeout);

Затем нужно подписать этот псевдослучайный ключ при помощи выбранного КЭП и отправить в ГИС МТ, чтобы получить в ответ авторизационный токен.

Для этого ищем сертификат КЭП по выбранному пользователем отпечатку (certificateThumb). Сертификат находится в данном случае в Личных локальной машины. Также контекст сертификата должен быть связан с хранилищем ключевой пары (такие сертификаты отмечены иконкой ключика в списке сертификатов в оснастке windows):



Получение сертификата в коде для формирования подписи:

X509Certificate2 cert = null;using(store = new X509Store(StoreName.My, StoreLocation.LocalMachine)){    store.Open(OpenFlags.ReadOnly);    cert = from c in store.Certificates where string.Compare(c.Thumbprint, certificateThumb, true) == 0 select c;}

Подписываем таким образом:

// данные для подписиvar content = new ContentInfo(randomDataResponse.Data);var signedCms = new SignedCms(content, false);// настраиваем сертификат для подлиси, добавляем датуvar signer = new CmsSigner(SubjectIdentifierType.IssuerAndSerialNumber, cert);signer.SignedAttributes.Add(new Pkcs9SigningTime(DateTime.Now));// формируем подписьsignedCms.ComputeSignature(signer, false);var sign = signedCms.Encode();

Подписанное CMS-сообщение (sign) это и есть та проверочная подпись, которую нужно отправить для авторизации, предварительно преобразовав в формат Base64.

var tokenRequest = new TokenRequest();tokenRequest.UUID = randomDataResponse.UUID;tokenRequest.Data = Convert.ToBase64String(sign);// получаем токен на /api/v3/auth/cert/var uri2 = new Uri("<нужный хост>/api/v3/auth/cert/")var tokenResponse = REST.Invoke<TokenResponse>(uri2, "POST", tokenRequest);

В ответ приходит JWT токен, закодированный в Base64.

К слову, отправляемые документы в дальнейшем подписываются таким же образом, только формируется так называемая открепленная подпись:

var signedCms = new SignedCms(content, true);

Вспомогательные классы (со схемой, идентичной XSD-схемам документов из API):

/// <summary>/// Ответ на запрос GET /api/v3/auth/cert/key для авторизации./// </summary>public class RandomDataResponse{    /// <summary>    /// уникальный идентификатор сгенерированных случайных данных, тип string    /// </summary>    [Newtonsoft.Json.JsonProperty(PropertyName = "uuid")]    public string UUID { get; set; }    /// <summary>    /// случайная строка, тип string    /// </summary>    [Newtonsoft.Json.JsonProperty(PropertyName = "data")]    public string Data { get; set; }}/// <summary>/// Данные для запроса авторизационного токена./// POST /api/v3/auth/cert//// </summary>public class TokenRequest{    /// <summary>    /// uuid - уникальный идентификатор подписанных данных из /api/v3/auth/cert/key    /// </summary>    [Newtonsoft.Json.JsonProperty(PropertyName = "uuid")]    public string UUID { get; set; }    /// <summary>    /// подписанные УКЭП зарегистрированного участника случайные данные в base64    /// </summary>    [Newtonsoft.Json.JsonProperty(PropertyName = "data")]    public string Data { get; set; }}/// <summary>/// Ответ на запрос авторизационного токена./// POST /api/v3/auth/cert//// </summary>public class TokenResponse{    /// <summary>    /// Авторизационный токен в base64-строке    /// </summary>    [Newtonsoft.Json.JsonProperty(PropertyName = "token")]    public string EncodedTokenBase64 { get; set; }}

Если вам удалось авторизоваться вы прошли небольшой квест.

Проблемы с генерацией и чтением штрихкодов

Система маркировки построена на международных стандартах, за исключением части с криптографией. Это отлично и достойно похвалы.

К сожалению, средний айтишник никаких стандартов не читает, ни про что не изучает, а сразу лепит свои велосипеды из бесплатных компонентов про генерацию штрихкодов, печать, бизнес-процессы и т.п.

Первая же трудность распечатать штрихкод маркировки в своём дизайне. Из коробки Честный знак предоставляет бесплатный инструмент, но с ним никто, конечно, разбираться не стал, ведь есть online barcode generator и встроенные редакторы отчетов в 1С/SAP/NAV/DAX.

Засада в том, что современный штрихкод это не просто графическое представление символов (об этом у нас выйдет отдельная статья). Поэтому сразу всплыли проблемы префиксов, разделителей, кодировок, обязательных непечатемых символов и прочее такое, про что никто знать не знал и разбираться не хотел.

Пример со спецсимволом GS (ASCII 29)



Пример со спецсимволом FNC1 (ASCII 232)



Скриншоты сделаны из приложения Чекмарк.

Вот кусок исходного кода Чекмарка, который выполняет разбор штрихкода, отсканированного камерой и разобранного нашей платформой:

var km = BarcodeData.GS1;if (km.Contains("01") && km.Contains("21")){    if ((km.Contains("17") || km.Contains("7003")) && !km.Contains("10"))    {        ПризнакМолока = true;        if ((km.GetValue("01").Length == 14) && (km.GetValue("21").Length == 7 ||              km.GetValue("21").Length == 13) && (km.GetValue("17").Length == 6 ||              km.Getvalue("7003").Length == 10) && (km.GetValue("93").Length == 4))        {             ЭтоМолоко = true;             MSG2 = "Является KM ЧЗ молочной продукции.";             if (km.GetValue("21").Length == 7)                 MSG2 = "Является КМ ЧЗ групповой упаковки молочной продукции.";        }        else        {             // Проверка наличия группы в коллекции для отображения (EntriesRows)             // В случае отсутствия - добавляем группу с пустым содержимым             EntriesRows = ПоискАI(EntriesRows, Al = 93, BarcodeData);             MSG2Error = "Не является КМ Ч3! Имеет признаки КМ молочной продукции.";             Msg = "<b>#N005</b>" + Msg;         }    }    else if (km.Contains("8005") || km.Contains("93"))    {         ПризнакТабачногоБлока = true;         if (km.GetValue("01").Length == 14 && km.GetValue("21").Length == 7 &&              km.GetValue("8005").Length == 6 && km.GetValue("93").Length == 4)         {             ЭтоТабачныйБлок = true;             MSG2 = "Является КМ ЧЗ табачного блока.";         }         else         {             EntriesRows = ПоискАI(EntriesRows, AI = 8005, BarcodeData)             EntriesRows = ПоискАI(EntriesRows, Al = 93, BarcodeData)             MSG2Error = "Не является КМ Ч3! Имеет признаки КМ табачного блока.";             Msg = "<b>#N004</b>" + Мsg;         }    }    else if (km.Contains("92") && km.Contains("92").Length > 66)    {        ПризнакОбуви = true;        if (km.GetValue("01").Length == 14 && km.GetValue("21").Length == 13 &&            km.GetValue("91").Length == 4 && km.GetValue("92").Length == 88)        {            ... (и т.п.) ...

Откуда взялись спецсимволы? Из стандарта. Честный знак сделали всё по стандарту, и участникам оборота товаров тоже надо было читать стандарт.

КСТАТИ: Проверку корректности содержимого DataMatrix можно произвести только с помощью сканирования камерой (даже если сканировать с ТСД, нужен доступ к камере). Потому что все сканеры штрихкодов в соответствии со стандартном не должны возвращать 1в1 то, что они считали, как минимум должны выбрасывать первый символ FNC1. В целом, сканеры могут добавлять или убирать важные символы штрихкода при сканировании, переставлять блоки местами, в зависимости от настроек, всё это мешает проверке.

Т.к. системная интеграция это не про программы, а про людей и про то, как они пишут и читают спецификации, то наличие этих спец символов сразу привело к некоторому разногласию при обмене штрихкодами.

Например, могли, особо не вчитываясь в спецификации, добавлять в штрихкод строку из 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++).

Наличие таких спец символов накладывает ограничение на передачу и хранение данных штрихкодов, их нужно экранировать или кодировать, например в Base64.

КСТАТИ: существует стандарт на хранение и передачу таких штрихкодов в виде строки (ISO/IEC 15424-2018), но почему-то им никто не пользуется. Данные штрихкода GS1 DataMatrix, хранимые в виде строки, должны начинаться на ]d2.

Сейчас почти все исправили свои компоненты печати штрихкодов (наверное). Но кто вообще читает стандарты, правда?

На проверку, домашнее задание: вот эта тема, что если поле фиксированной длины, то GS вставлять не нужно, а если длина переменная, и значение поля не максимальной длины, то вставлять нужно. На самом деле это правило работает не так. Спецсимвол GS не вставляется только если AI начинается с пары цифр из этой вот таблицы:


А во всех остальных случаях вставляется. Ваш код генерации/разбора ШК работает так же?

Еще одна проблема сканирование штрихкода маркировки ламерскими средствами типа сканер в разрыв клавиатуры. До маркировки самой большой проблемой было, что где-то обрезается или вставляется лишний ноль. Со введением новых кодов маркировки тулзы со сканированием выведены на совершенно новый уровень.

Зачастую это не проблемы самого сканера или его настроек, а проблемы с отсутствием опыта и понимаем принципов штрихкодирования.

Например, при подключении сканера в разрыв клавиатуры (или при эмуляции такого режима), а также при подключении сканера как 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 уже были исправлены, а вопросы перестройки работы компаний на новые рельсы.

Выводы

Самый главный плюс маркировки в том, что государство заставило всех цифровизироваться и переходить на ЭДО с цифровыми подписями и криптографией.

Прилив поднимает все лодки, и переход всего рынка на общие рельсы дает большой синергетический эффект.

Всем удачной автоматизации!