От Code128 до Data Matrix: штрих-коды в мобильных приложениях

Почему генерация штрих-кодов в приложении даёт нечитаемый код

Метка печатается, приложение не сообщает об ошибке — а штрих-код не читается на кассе, складе или турникете. Причина почти всегда не в сканере: генерация штрих-кодов в приложении — это цепочка «кодирование данных → отрисовка → печать → состояние носителя», и разрыв на любом звене даёт один и тот же симптом при совершенно разных исходных данных.

Первый слой — кодировка. Code 128 переключает подмножества под цифры и латиницу, кириллицу он не поддерживает; EAN-13 принимает только фиксированную длину с контрольной цифрой. Если приложение передаёт в генератор произвольную строку, тот молча подставит ближайший символ или растянет данные — метка выглядит правдоподобно, а оборудование её отклоняет.

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

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

Эффект внедрения: скорость выпуска и доля нечитаемых меток

Эффект внедрения измеряем до старта: фиксируем базовую линию по трём метрикам — сколько времени занимает выпуск партии этикеток, какая доля сканов уходит на повторное считывание и что происходит с маркировкой, когда связь пропадает. Те же цифры снимаем после запуска, поэтому разговор идёт о замере, а не об ощущении «стало удобнее».

Скорость выпуска и печати этикеток

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

Снижение доли нечитаемых меток и возвратов

Символика подбирается под задачу: Code128 — где важны плотность и цифро-буквенный состав, Data Matrix — где нужна устойчивость к загрязнению и повреждению площадки. До печати макет проверяется по требованиям GS1: зоны покоя, контрольная сумма, уровень коррекции ошибок. Доля возвратов на пересканирование уходит с двузначных значений до единиц процентов, а класс отказов сканирования меняется — вместо «метка не читается вовсе» остаются редкие считывания со второй попытки.

Сценарий без связи проектируется по тем же правилам: справочник меток и очередь считанных кодов хранятся на устройстве, а при возврате в зону покрытия синхронизируются с сервером. Простой из-за маркировки перестаёт быть отдельной статьёй простоев — линия продолжает печатать и принимать сканы, даже когда сеть недоступна.

Режимы генерации штрих-кодов: офлайн, на устройстве, на сервере

Код собирают в четырёх точках: на самом устройстве, на сервере по запросу, заранее пакетом или во внешнем сервисе. Выбор задаёт не вкус, а связность канала, тираж этикеток и требования к печати — на складе без сети серверная схема не работает вовсе.

Линейные и двумерные символьные наборы: что выбрать

Линейные Code128 и EAN занимают одну строку и уверенно читаются сканером на расстоянии, но вмещают немного — их берут для товарных этикеток. Двумерные Data Matrix и QR держат на порядок больше данных и восстанавливаются при повреждении части площади, поэтому их выбирают для маркировки и билетов. Оба класса собираем одной библиотекой (ZXing) — приложение не тянет два кодировщика.

Вывод кода: экран, термопринтер, файл для печати

Это три разных формата, и требования к ним расходятся. Экрану достаточно растровой картинки с запасом белого поля; термопринтеру нужен монохром и явно заданный размер модуля, иначе код «плывёт» при печати; для партии — векторный файл, который не теряет резкость при масштабировании.

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

Этапы внедрения: от аудита сценариев до передачи команде

Работа идёт последовательными этапами, и каждый заканчивается артефактом, который можно проверить: карта сценариев, схема кодирования, спецификация печати, собранный модуль. Классический риск здесь — приложение «вроде сканирует», но на складе часть меток не читается и данные расходятся с учётной системой.

1. Аудит сценариев маркировки. Разбираем, где и чем сканируют: приёмка, отгрузка, инвентаризация, кассы. Фиксируем типы кодов, объём данных в метке и ограничения учётной системы.
2. Проектирование схемы кодирования. Подбираем форматы под задачу и носитель — одномерные для длинных номеров, двумерные для мелких этикеток. Проверяем кодировку символов и разделители.
3. Настройка печати меток. Задаём размер, коррекцию ошибок и тихую зону под конкретный принтер и материал. Контраст проверяем на отпечатке, а не на экране.
4. Реализация генерации в приложении. Собираем отрисовку кода, вывод на экран, выгрузку в документ и печать, включая работу без сети.
5. Приёмка на устройствах заказчика. Прогоняем на реальном парке техники с разными камерами и автофокусом, а не на одном флагмане.
6. Передача команде. Отдаём документацию, наборы тестовых меток и регламент повторной проверки при изменениях.

Проверка на реальных устройствах и при плохом освещении

Отдельный прогон — слабый свет, блики от ламината, потёртая или мокрая этикетка, съёмка под углом. Смотрим не «читается или нет», а на каком расстоянии и с какой попытки срабатывает захват, и подбираем плотность кода так, чтобы оставался запас по читаемости.

Что остаётся в проекте: схемы, конфигурации, регламенты

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

Документация и регламенты

• Документация по кодированию — допустимые символы, длина, контрольный разряд, поведение при обрезке данных: по ней генерацию воспроизводит новый разработчик.
• Регламент печати меток — материал и размер этикетки, поля покоя, минимальный контраст, периодичность проверки читаемости, ответственный за расходники.
• Схемы интеграции с учётной системой — какие справочники источник истины, в каком виде приходит партия, как откатывается неудачная выгрузка.
• Профили печати под конкретные модели принтеров и сканеров: шаблоны, калибровка, настройки — замена оборудования становится правкой профиля.
• Порядок обновления схемы — как добавить тип кода или поле, не сломав уже наклеенные метки, и проверить совместимость со сканерами в парке.

Передача и обучение сотрудников

• Исходный код с историей изменений и сборкой, воспроизводимой на чистом окружении.
• Инструкции для сотрудников — для оператора печати, склада и поддержки: один-два экрана, скриншоты, чек-лист «метка не читается».
• Журнал типовых сбоев — замятие, смазанный оттиск, расхождение с учётной системой — с готовым порядком действий.

После передачи поддержка печати и приложения идёт силами заказчика, а мы подключаемся на изменениях схемы.

Кейс склада: доля нечитаемых меток упала, скорость выпуска выросла

Складской учёт держался на этикетках, которые печатались из учётной системы без контроля качества кода. Терминалы сбора данных брали примерно каждую пятую метку только со второй-третьей попытки: узкие штрихи сливались, вокруг кода не оставалось свободной зоны, часть этикеток шла на термобумаге с низким контрастом. Кладовщик сканировал почти вслепую, а расхождение всплывало уже на отгрузке — вплоть до сорванных рейсов.

Что было до и что стало после

Что изменили: генерацию кодов перенесли в само приложение и зафиксировали профиль печати — шаг модуля, свободная зона и контраст подбирались под конкретную модель сканера. Для маркировки выбрали Data Matrix, добавили проверку контрольной суммы и валидацию макета до отправки на печать: битая этикетка не покидает принтер, а оператор не тратит смену на перепечатку.

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

Что делать, если метки уже печатает сторонний сервис?

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

Первый путь — оставить сервис и обвязать его своей прослойкой. Мы ставим между приложением и сервисом обмен с очередью и повторами: запрос на код уходит заново при сбое, готовые метки отдаются из локального хранилища, расхождения фиксируются отдельно. Ограничение остаётся у сервиса: его доступность становится вашей доступностью, а смена символики или добавление поля упирается в чужие сроки.

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

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

Выбор сводится к одному вопросу — кто хранит реестр номеров. Если учётная система остаётся источником истины, а отрисовка метки уходит в приложение, переход делается по частям и на любом шаге обратим: ранее напечатанные этикетки продолжают читаться, новые печатаются уже своим кодом.

Частые сомнения: совместимость сканеров, печать, офлайн

Сомнения обычно всплывают не на демонстрации, а на складе или в цеху: сканер не читает код с новой партии этикеток, принтер «плывёт» к концу рулона, у кладовщика пропала связь в дальнем помещении. Любой из этих случаев останавливает отгрузку целиком, поэтому проверяем их до старта разработки, а не после запуска.

Ниже — вопросы, которые задают чаще всего. Ответы описывают, как именно мы закрываем каждый случай: в логике приложения, в настройках оборудования и в приёмочных проверках.

Что будет, если пропадёт интернет?

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

Как добиться читаемой термопечати и совместить несколько типов кодов?

Калибровка — это подбор трёх связанных параметров: плотности печати, скорости протяжки и зазора между этикетками. После настройки печатаем контрольный лист с кодами разного размера и проверяем считывание на сканерах, а параметры закрепляем в профиле принтера, чтобы они не сбивались при смене рулона. Шаблоны кодов при этом задаются настройками: склад и участок могут работать на разных форматах, а версия шаблона пишется в журнал печати — видно, каким именно напечатана этикетка.

Обсудим задачу: какие данные нужны для оценки и плана

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

• Сценарии сканирования: камера телефона или отдельный сканер, дистанция и угол, освещение, темп смены и паузы на подтверждение.
• Парк устройств: модели и версии операционной системы, доля старых аппаратов, наличие терминалов сбора данных.
• Образцы текущих меток: фотографии и макеты этикеток с типами Code128 и Data Matrix, плотностью и качеством печати.
• Учётная система: справочники для генерации кодов, схема обмена и поведение приложения при недоступности сервиса.
• Ограничения по связи: зоны без сети, объём данных за смену, требования к офлайн-очереди и синхронизации.
• Регламент печати: принтер, материал и способ нанесения — от этого зависит, выдержит ли метка реальную эксплуатацию.

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