Симптомы

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

Решение

Как это выглядит по шагам

1. Камера прочитала коды (или не прочитала).
2. Если чтение «нормальное» — линия спрашивает учётную систему, можно ли этот продукт.
3. Учётная система разбирает состав каждого кода, сверяет его с шаблоном и правилами, затем проверяет марки по бизнес-правилам.
4. Учёт отвечает: да (с комментарием) или нет (с текстом причин).
5. Линия по ответу ведёт продукт дальше как годный или как брак.

Если ответ от учёта не пришёл вовремя (ожидание около 5 секунд) или некому ответить — это отдельный сбой связи/клиентов, не «брак по марке».

---

Слой 1. Пока продукт ещё у камеры

Пока учёт даже не вызывали, отсекается плохое чтение:

Только после нормального чтения продукт переходит к проверке в учёте. Если к этому моменту продукт уже не в состоянии «прочитан» — запрос в учёт не уходит.

Ошибка отправки запроса в учёт — тоже сбой линии (на «часовой» сериализации конвейер могут остановить).

---

Слой 2. Контроль состава прочитанного кода

Это отдельный, очень важный этап: система не просто «увидела строку», а пытается понять, из каких частей состоит код и полный ли он.

Зачем это нужно

Код маркировки — не «просто штрихкод». В нём обычно есть:

• товарный идентификатор (GTIN) — «какой это товар»;
• серийный номер — «какой именно экземпляр»;
• иногда вес, даты, МРЦ и другие поля;
• для многих типов упаковки — криптохвост (код проверки) — «хвост» после основных полей, без которого код считается неполным.

Пока состав не разобран, нельзя надёжно сказать: это своя марка, полный ли код, тот ли тип упаковки.

Как система «разбирает» код

1. Сначала смотрит, не хелпер-код ли это (служебный код, не полноценная марка).
2. Если нет — пытается разобрать код по шаблонам для нужных видов продукции:
   • есть ли в нужных местах идентификаторы применения (например, признаки полей GTIN и серии);
   • совпадают ли длины кусков с описанием шаблона;
   • допустимы ли символы (алфавит) в каждом куске;
   • для части товарных групп — отдельные правила (табак/МРЦ, мех и т.п.).
3. Если полный разбор по шаблонам уже делали для похожего кода, может сработать упрощённый повтор: та же длина, то же начало, та же длина серии — состав копируется быстрее.
4. Из разбора собирается состав: GTIN, серия, признак криптохвоста, нормализованный вид кода, при наличии — вес и др.

Если код не лёг ни на один шаблон, в сведениях о марке выставляется признак: «не соответствует шаблону».

Если в разобранном составе есть криптохвост — признак: «включает криптохвост».

Что именно контролируется в составе

Когда на сериализации это превращается в брак

На основной форме сериализации (линия с камерой) после получения сведений о марке действует жёсткое правило:

если код не соответствует шаблону

или

код не включает криптохвост

→ продукт отклоняют с текстом вроде: «Не соответствует шаблону» (в причине показывают представление марки).

То есть для линии это выглядит одинаково: «код кривой / неполный», даже если технически причины две:

1. Шаблон — формат/набор полей не сошёлся.
2. Криптохвост — формат мог частично читаться, но нет кода проверки (часто камера «отрезала хвост», плохая печать, неполный Data Matrix).

Важно:

• На сериализации со взвешиванием в том же виде эта пара «шаблон + криптохвост» не дублируется — там упор на вес и одну марку, плюс остальные бизнес-проверки.
• На агрегации по заданию отдельно могут сказать проще: «Код маркировки не соответствует шаблону», если уже выставлен признак несоответствия.
• При печати этикеток неполный код (без кода проверки) могут запретить печатать — это соседний контур, но тот же смысл «без хвоста нельзя».
• В приёмке логика мягче по смыслу «нужен ли хвост»: для потребительской / групповой / набора криптохвост требуется; для прочих видов — можно без него. На сериализации линии правило жёстче: смотрят готовые признаки «шаблон / криптохвост» в сведениях о марке.

Что оператор видит на практике

Где это стоит в общей очереди проверок

На линии порядок такой:

1. Камера: есть ли вообще читаемый код.
2. Состав кода: шаблон + полнота (в т.ч. криптохвост).
3. Дальше — «чья марка», задание, повтор, срок, товар/характеристика/упаковка, число кодов в такте.

Если состав не прошёл — до «своей/чужой в базе» и задания часто даже не доходят с успехом: продукт уже в браке по формату.

---

Слой 3. Учёт: бизнес-проверки по маркам

Считанные с камеры вещи делятся так:

• Даты (если камера отдала даты) — не считаются марками, идут отдельно.
• Коды маркировки — основной объект проверки.
• При включённых хелпер-кодах — отдельно служебные коды (ожидается ровно один).

Повтор и «уже было»

Хелпер-коды (если включены)

Сама марка (после контроля состава)

Если все проверки прошли — продукт принимают. В ответе — представление марок; при агрегации на участке — ещё счётчик вроде «N из M» и код агрегата, если он уже есть.

После «принято»

• В режиме сериализации: марку регистрируют как принятую из производства, при необходимости с серией.
• Счётчик на экране растёт (сериализация или успешная валидация).
• Хелперы: один хелпер + одна марка → привязка.
• Если есть агрегация и отказов не было: коды в состав агрегата, при необходимости код агрегата, регистрация, проверка автозавершения.

---

Слой 4. Ответ линии: «годен» или «брак»

---

Если линия со взвешиванием

До обычных проверок марки:

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

Отдельной жёсткой пары «шаблон + криптохвост», как на основной сериализации, здесь нет.

Причина

Опишите причину появления проблемы - необязательное поле