Зачем рознице поэкземплярный учёт, или как магазину подготовить кассу к нововведениям маркировки

Переход на разрешительный режим изменил базовую логику работы в рознице. И линейный штрихкод больше не гарантирует, что продажа будет совершена, как и раньше, в момент пробития чека. Потому что теперь кассовое ПО проверяет DataMatrix-код в базе Честного ЗНАКа. И если марка не принята на баланс, не соответствует товару или уже списана — продажа заблокируется.

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

Давайте вместе разбираться, как же выстроить поэкземплярный учёт (ПЭУ) без остановки торговли. В статье вы найдёте ответы на вопросы: какие именно процессы меняются, где ломается логистика, какое оборудование и софт реально нужны, и как обучить линейный персонал за один рабочий день.

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

ПЭУ уже охватывает 40+ товарных групп: от молочной продукции, одежды, обуви и воды до автозапчастей, стройматериалов, БАДов, детских игрушек и даже макарон с крупами. И Честный ЗНАК регулярно обновляет этот всё больше расширяющийся список.

Главное изменение, ломающее привычные процессы в рознице, — разрешительный режим на кассе. Это значит, что в момент пробития чека система в реальном времени запрашивает статус марки:

Подписывать ЭДО вслепую или «на доверии к поставщику» теперь экономически опасно. По отраслевой статистике и данным внутренних аудитов, до 5% кодов в оптовых поставках содержат пересортицу, дубли или ошибки агрегации. Человеческий фактор никто не отменял. И если вы подписали документы без сверки — значит взяли на себя ответственность за чужие ошибки. Исправлять потом придётся актами, перемаркировкой, простоями касс и даже реальными деньгами.

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

Устойчивость процесса зависит не от оборудования, а от жёсткого распределения ответственности и контроля на каждом этапе движения товара.

Распределение зон ответственности формирует структуру процесса, но работает только при одном условии — синхронизации физического движения товара с цифровым учётом. То есть ни один входящий документ не должен проводиться в учётной системе или подписываться в ЭДО, пока ТСД не передаст отчёт о фактическом сканировании каждого кода.

Этот этап выступает контрольной точкой, связывающей работу приёмщика, товароведа и кассира. Если его пропустить, разделённые роли теряют смысл, а статусы кодов маркировки в Честном ЗНАКе перестают соответствовать реальному движению товара.

Приведённый ниже регламент описывает полный цикл обработки маркированного товара: от загрузки УПД в учётную систему до вывода кода из оборота на кассе. Каждый этап представляет собой операционный контур с чётко определёнными входными данными, действиями персонала и точками синхронизации с Честным ЗНАКом и учётной базой.

Логика построена на исключении ручного переноса данных и обеспечении строгого соответствия физического перемещения товара его цифровому статусу.

Поставщик формирует УПД с кодами Data Matrix. Товаровед получает документ в учётной системе (1С, МойСклад или других) и передаёт задание на ТСД.

Интеграция должна работать в автоматическом режиме. Ручной перенос кодов в Excel или бумажные листы исключает контроль соответствия и увеличивает время обработки.

Приёмщик работает с ТСД. Сканирование проводится непосредственно при разгрузке:

ПО на ТСД сравнивает отсканированные коды с заданием. При расхождении система блокирует завершение приёмки и выводит ошибку на экран. Повреждённые или нечитаемые коды фиксируются отдельно и передаются на возврат.

После завершения сканирования данные возвращаются в учётную систему. Товаровед видит отчёт: план vs факт, расхождения, недовоз, пересорт. Документ подписывается в ЭДО только по факту.

Автоматическая корректировка УПД или формирование акта расхождений переводит товар на баланс магазина в системе маркировки.

Продавец или мерчендайзер использует ТСД для проверки кодов перед выкладкой. Сканирование показывает статус марки, остаток и цену. Это позволяет выявить повреждённые этикетки или «зависшие» позиции до момента обращения покупателя к кассе.

Кассир сканирует линейный штрихкод, затем код маркировки. Онлайн-касса через ОФД отправляет запрос в Честный ЗНАК. При корректной приёмке статус подтверждается, чек пробивается, марка списывается. Цепочка завершается.

Терминал сбора данных (ТСД) — это аппаратная часть системы для считывания штрихкодов. Сам по себе он не выполняет логические операции учёта, не сверяет коды с УПД и не синхронизирует данные с учётной системой. Для ведения поэкземплярного учёта требуется специализированное программное обеспечение, которое обрабатывает отсканированные DataMatrix-коды, управляет бизнес-процессами (приёмка, инвентаризация, внутренние перемещения), обеспечивает работу без постоянного подключения к сети и передаёт структурированные результаты в 1С или аналоги.

На рынке представлены готовые решения, адаптированные под требования Честного ЗНАКа и розничных сценариев. Например, решение «Магазин 15» на базе платформы Клеверенс реализует поэкземплярный учёт без кастомной разработки. При приёмке ПО автоматически сверяет отсканированные коды с заданием из УПД, раскрывает агрегированные упаковки, фиксирует пересорт и повреждения в реальном времени, а также формирует корректирующие документы для ЭДО. Интеграция с учётными системами и API маркировки реализована через готовые коннекторы, что исключает ручной перенос данных и снижает нагрузку на ИТ-инфраструктуру розничной точки.

Для стабильной работы связки требуется соблюдение следующих технических условий:

1. ТСД

2. ПО

Обязателен ли ПЭУ для небольшого магазина?

Да. Требования не зависят от масштаба бизнеса или системы налогообложения. ИП, работающий с маркированными категориями, обязан соблюдать те же правила, что и крупные сети.

Можно ли принять товар без ТСД?

Формально коды передаются в УПД, но физическая сверка без мобильного сканирования не обеспечивает соответствие фактических данных документу. Риск расхождений делает такую схему непрактичной.

Нужен ли отдельный ТСД для приёмки и кассы?

В большинстве случаев достаточно одного устройства на смену. Приёмка проводится утром, контроль полок и инвентаризация — в течение дня. Количество терминалов зависит от объёма поставок и размера торговой точки.

Что делать при блокировке продажи на кассе?

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

С чего начать внедрение?

Запустить пилот на одной товарной группе. Отработать связку «учётная система — ТСД — касса», зафиксировать расхождения с поставщиками, настроить уведомления. Масштабирование на весь ассортимент проводится после стабилизации процессов.

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

Готовые решения, такие как «Магазин 15» от Клеверенс, закрывают этот технический контур: они берут на себя интеграцию с 1С и API маркировки, управление офлайн-режимом и генерацию корректирующих документов. Это позволяет магазинам сосредоточиться на отладке внутренних регламентов, а не на поддержке кастомного кода. Внедрение до пикового периода и чёткое следование процессу переводят ПЭУ из зоны операционных рисков в инструмент прозрачного учёта и снижения издержек на расхождения.

Есть ли у вас опыт внедрения ПЭУ? Какие этапы вызывали наибольшие сложности? Как выстраивали работу с расхождениями? Делитесь практикой в комментариях.