С введением обязательной национальной системы маркировки товаров «Честный Знак» перед многими разработчиками и администраторами систем на базе 1С:Предприятие 7.7 встала сложная техническая задача. Поскольку платформа 1С 7.7 была разработана задолго до появления современных требований к маркировке, в ней отсутствует встроенный механизм для работы с двумерными штрихкодами (2D-штрихкодами), такими как DataMatrix. В этой статье мы подробно разберем, как решить эту задачу с помощью внешних компонент, проанализируем наиболее эффективные библиотеки и научимся обходить известные системные ошибки генерации.
Для генерации изображения штрихкода по текстовой строке в среде 1С 7.7 традиционно рассматриваются два основных кандидата:
СоздатьОбъект("ActiveX"), однако имеет ряд ограничений по плотности упаковки данных и масштабированию.Проанализируем практический опыт использования обеих компонент. Разработчики отмечают, что при кодировании одинакового объема данных (например, стандартного криптохвоста маркировки объемом 64 байта):
Поэтому в качестве базового и наиболее надежного решения мы выберем именно FormEx.dll.
Рассмотрим, как интегрировать генерацию DataMatrix в конфигурацию 1С 7.7. Для этого нам понадобится сама библиотека FormEx.dll версии не ниже 2.0.5.147 (желательно от 13.02.2020 или новее).
Выясним процедуру подключения компоненты. В глобальном модуле или непосредственно в обработке печати необходимо загрузить внешнюю компоненту:
Если ЗагрузитьВнешнююКомпоненту("FormEx.dll") = 0 Тогда
Предупреждение("Не удалось загрузить компоненту FormEx.dll! Печать DataMatrix невозможна.");
Возврат;
КонецЕсли;
После успешной загрузки нам становится доступен объект Сервис, который предоставляет метод НарисоватьШтрихкод(). Посмотрим на полный синтаксис этого метода:
НарисоватьШтрихкод(<Картинка>, <ТипКода>, <ЗначениеКода>, <ПрятатьТекст>, <eci>, <input_mode>, <УголПоворота>, <output_options>)
Разберем назначение ключевых параметров этого метода:
GS1_MODE).Проанализируем пример готовой процедуры вывода штрихкода в печатную форму:
Процедура ВыводШтрихкодаВТаблицу(ТаблицаМакета, ИмяКартинки, ТекстШтрихкода)
// Получаем объект картинки из области макета
Картинка = ТаблицаМакета.ТекущийОбъект;
// Создаем объект Сервис из FormEx
Сервис = СоздатьОбъект("Сервис");
// Вызываем генерацию штрихкода.
// 71 - тип DataMatrix, 0 - без текста, 0 - eci по умолчанию, 2 - режим GS1_MODE
Сервис.НарисоватьШтрихкод(Картинка, 71, ТекстШтрихкода, 0, 0, 2);
// Устанавливаем режим рисования картинки:
// 3 - масштабировать с сохранением пропорций
Картинка.РежимРисования(3);
КонецПроцедуры
Чтобы эта процедура сработала, на макете вашей печатной формы должен быть размещен элемент типа "Рисунок" (тип "Картинка"). В свойствах этого рисунка в поле "Текст" необходимо прописать вызов нашей процедуры, например: ВыводШтрихкодаВТаблицу(Таб, "ДК", СтрокаКодаМаркировки).
Обычный штрихкод DataMatrix отличается от государственного стандарта маркировки GS1 DataMatrix. В GS1-коде в самом начале должен присутствовать невидимый управляющий символ FNC1. Если сгенерировать штрихкод как обычную текстовую строку, сканеры на кассах не распознают его как код маркировки.
При использовании FormEx в режиме input_mode = 2 (GS1_MODE), библиотека Zint ожидает строку, в которой идентификаторы применения (AI) заключены в квадратные скобки. Например, строка кода маркировки для передачи в компоненту должна иметь следующий вид:
[01]04680049338249[21]HOA%DamnoJefc[91]8039[92]Криптохвост
Компонента автоматически обработает квадратные скобки, удалит их из финального текста, вставит управляющий символ FNC1 (код ASCII 232) в начало кода и правильно расставит разделители групп данных GS (символ с кодом ASCII 29) перед блоками переменной длины. Это гарантирует 100% считываемость кода любыми 2D-сканерами и кассовым ПО.
В процессе промышленной эксплуатации FormEx версий конца 2019 года многие программисты столкнулись с неприятным плавающим багом: примерно один из 100–200 сгенерированных кодов визуально отрисовывался некорректно — штрихкод выглядел обрезанным, как будто вывелась только верхняя левая четверть изображения (так называемый «эффект 1/4 кода»). Разумеется, такие коды не считывались сканерами.
Выясним причину этой проблемы. Сбой происходил на стыке передачи графического контекста из библиотеки оптимизации изображений Zint в графическую подсистему Windows (GDI) через функции отрисовки FormEx. В определенных комбинациях символов в криптохвосте алгоритм сжатия Zint рассчитывал нестандартный размер сетки модулей, что приводило к сдвигу масштабирования.
Решение проблемы: Данная ошибка была полностью локализована и исправлена разработчиком FormEx (АЛьФом) в официальном релизе компоненты от 13 февраля 2020 года. В этой сборке была обновлена внутренняя библиотека Zint и переписан механизм передачи графического буфера. Если вы столкнулись с подобной проблемой, вам достаточно просто обновить файл FormEx.dll в каталоге вашей базы данных до актуальной версии.
Еще одна частая проблема, обсуждаемая разработчиками при использовании альтернативных компонент (в частности, устаревших версий Ocvita Barcode), — это самопроизвольное появление лишнего третьего знака равенства «=» в конце считанного штрихкода (в оригинальном коде Честного Знака должно быть ровно два знака «=» на конце криптохвоста из 88 символов).
Эта ошибка обусловлена неверной обработкой финального выравнивания байт-падинга (padding) в алгоритме Base64 старых версий ActiveX-компонент. При передаче строки в компоненту без явного указания длины или при неверном режиме кодирования, двоичный упаковщик некорректно округлял битовую последовательность до байтовой границы и дописывал лишний символ-заполнитель. При использовании FormEx.dll последних версий с включенным GS1_MODE данная проблема исключена, так как ядро Zint строго соблюдает стандарты ISO/IEC 16022 по упаковке данных DataMatrix ECC 200.
Чтобы штрихкоды стабильно считывались на складе и на кассе ККТ, соблюдайте три простых правила при настройке вывода на печать:
Картинка.РежимРисования(3) (масштабирование) позволяет вписать код в рамки этикетки, однако при сильном нелинейном растяжении пиксели могут искажаться. Старайтесь делать геометрические размеры картинки на макете пропорциональными физическому разрешению вашего принтера этикеток (например, кратными 203 DPI или 300 DPI).