Від 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, щільністю та якістю друку.
• Облікова система: довідники для генерації кодів, схема обміну та поведінка застосунку при недоступності сервісу.
• Обмеження щодо зв'язку: зони без мережі, обсяг даних за зміну, вимоги до офлайн-черги та синхронізації.
• Регламент друку: принтер, матеріал і спосіб нанесення — від цього залежить, чи витримає мітка реальну експлуатацію.

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