При внедрении системы маркировки «Честный ЗНАК» в конфигурациях на платформе 1С программисты часто сталкиваются с проблемой корректного считывания и передачи кодов маркировки (КИЗ/КМ). Основная сложность заключается в наличии в структуре кода непечатаемых символов-разделителей, которые могут «теряться» при передаче данных от сканера в программу или вызывать ошибки при попытке передать строку с клиента на сервер. В рамках данной статьи мы подробно разберем, как устроены эти коды, почему возникают ошибки и какими методами их можно устранить.
Для начала проанализируем, из чего состоит типичный код маркировки. Как правило, это строка формата GS1 DataMatrix, которая включает в себя несколько групп данных, разделенных идентификаторами применения (AI — Application Identifiers). Рассмотрим пример из обсуждения:
010290000158901722fg&&MjVs't=Om 918029 92CMCzg6MiKh7vzHwFKquDwm8fHpMpm+uv9kWvJ20eV7iEz4PlRzxPfHzi1vvPncBQor9Ww5tdhlnnJnFHfgdsa==
После нормализации эта последовательность разбивается на следующие логические блоки:
02900001589017.Важный нюанс: между этими блоками (особенно перед идентификаторами 91 и 92) по стандарту GS1 должен стоять специальный символ-разделитель GS (Group Separator), имеющий код ASCII 29. Именно он становится камнем преткновения для разработчиков 1С.
Проанализируем ситуацию, когда сканер считывает код, но в 1С данные приходят неполными или вызывают ошибку. Основная причина кроется в режиме работы сканера штрихкодов. Рассмотрим два основных режима:
Символ(29) сохраняется в строке, однако при попытке передать такую строку с клиента на сервер через обычные параметры процедур может возникнуть ошибка, так как XML-сериализатор (используемый платформой 1С) не всегда корректно обрабатывает низкоуровневые управляющие символы.Посмотрим на самый надежный способ передачи считанного кода между контекстами клиента и сервера. Чтобы избежать искажения непечатаемых символов, рекомендуется преобразовывать полученную строку в двоичные данные. Рассмотрим пример кода, который иллюстрирует этот подход:
// На клиенте получаем данные со сканера
ДанныеBase64 = Base64Строка(ДвоичныеДанныеИзСтроки(СчитанныйКодМаркировки, КодировкаТекста.UTF8));
// Передаем ДанныеBase64 на сервер
Результат = ОбработатьКодНаСервере(ДанныеBase64);
// На сервере выполняем обратное преобразование
Функция ОбработатьКодНаСервере(ДанныеBase64)
СтрокаКИЗ = СтрокаИзДвоичныхДанных(Base64Значение(ДанныеBase64), КодировкаТекста.UTF8);
// Теперь переменная СтрокаКИЗ содержит исходный код с символом GS (29)
...
КонецФункции
Такой подход гарантирует, что ни один байт информации не будет потерян или заменен при передаче через сетевые протоколы платформы.
Рассмотрим альтернативный, более простой в реализации метод, который часто применяют на практике. Если вы не хотите работать с двоичными данными на каждом этапе, можно временно заменить символ GS на уникальную текстовую метку, которую легко передать в виде обычной строки.
Проанализируем пример функции замены:
// Перед отправкой на сервер
ТекстовыйКод = СтрЗаменить(СчитанныйКод, Символ(29), "&Символ29");
// На сервере или перед записью в базу возвращаем символ обратно
ОригинальныйКод = СтрЗаменить(ТекстовыйКод, "&Символ29", Символ(29));
Внимание: этот метод удобен для внутренней логики программы, но помните, что при передаче данных в ГИС МТ или при печати на чеке ККТ вы обязаны вернуть оригинальный символ ASCII 29, иначе код будет признан невалидным.
Выясним, как организовать хранение этих данных в типовых конфигурациях (например, в УТ 11 или ERP). Хранить полный код маркировки (вместе с криптохвостом) в обычном строковом реквизите справочника — не лучшая идея из-за его длины и наличия спецсимволов.
Рекомендуется использовать объект ХранилищеЗначения. Рассмотрим, как это работает:
ХранилищеЗначения, что позволяет платформе автоматически сжимать данные и корректно обрабатывать любые символы.Строка) можно хранить хэш-сумму кода или только его уникальную часть (GTIN + Серийный номер).Важно помнить: для выбытия товара через онлайн-кассу (теги 1162/1163) требуется полный код. Если вы сохраните только GTIN и серийный номер (без криптохвоста), вы не сможете легально продать этот товар в дальнейшем, так как восстановить криптохвост без перемаркировки невозможно.
Проанализируем наиболее частые заблуждения, которые встречаются в обсуждениях:
GS на пробел или удалите его, сканер мобильного приложения «Честный ЗНАК» может распознать товар, но проверка подлинности (криптографическая подпись) провалится.NativeApi в режиме эмуляции COM-порта.Подведем итог: Работа с КИЗ требует особого внимания к деталям кодирования. Использование Base64 для передачи данных и ХранилищаЗначения для их хранения — это «золотой стандарт» разработки в 1С, который позволяет избежать большинства технических проблем с непечатаемыми символами.