товар · роль · событие · статус
Маркировка:
от товара
до принятого
статуса
Не начинаем со сканеров и списка API. Сначала определяем товарную группу, роль компании, обязательное событие, уровень учёта, состав данных и подтверждение, которое должно вернуться пользователю в 1С.
Data Matrix — идентификатор, а не готовый бизнес-процесс. Требование становится управляемым, когда код связан с товаром, ролью, документом, событием, ответом системы и штатным сценарием исключения.
- 01Проверить товар и роль
- 02Провести одно событие
- 03Подтвердить статус
Короткий ответ
Не начинайте со сканера. Сначала определите товар, роль и событие.
Маркировочный сценарий возникает не из самого наличия кода. Он определяется тем, какая продукция проходит через компанию, кем компания является в цепочке, какое бизнес-событие происходит и какие сведения должны изменить статус товара в системе.
Один и тот же товарный поток содержит разные уровни работы. Сначала определяется применимость правил к продукции, затем роль участника, после — событие: заказ кода, ввод в оборот, передача, приёмка, продажа, иной вывод или возврат.
Практический вопрос звучит так: какие сведения должны быть переданы после конкретного бизнес-события и какой статус доказывает, что оно завершилось?Если ответ ограничивается фразой «код отсканирован», процесс ещё не описан.
Инженерный разбор идёт от товарного и договорного факта к настройке 1С и оборудования: сначала объём работ и ответственность, затем данные, документы, обмен, рабочее место и сценарий восстановления.
Пять проверок
Как определить обязательный сценарий до настройки 1С и закупки оборудования
Каждая проверка закрывает отдельную неопределённость. Если товар или роль определены неточно, последующие документы могут быть технически корректными, но относиться не к тому обязательству.
- 01Товар
Определить точную товарную группу, код продукции и дату применимости
Одного коммерческого названия недостаточно. Проверяются коды ТН ВЭД ЕАЭС и ОКПД2, вид упаковки, дата производства или ввоза, этап обязательности, остатки и исключения для конкретной товарной группы.
- 02Роль
Зафиксировать, кем компания является в конкретном товарном потоке
Производитель, импортёр, контрактная площадка, оптовик, розница, HoReCa и собственник товара выполняют разные действия. Одна организация может иметь несколько ролей, но в каждом сценарии должна быть определена одна ответственность за событие.
- 03Событие
Назвать событие, после которого сведения обязаны изменить состояние товара
Заказ и нанесение кода, ввод в оборот, агрегация, отгрузка, приёмка, розничная продажа, иной вывод из оборота, возврат и перемаркировка — это разные процессы, документы и основания.
- 04Учёт
Проверить уровень учёта, упаковку и состав передаваемых данных
Для конкретной группы и периода может требоваться поэкземплярный или объёмно-сортовой учёт. Отдельно фиксируются потребительская, групповая и транспортная упаковка, агрегация и связь между кодами разных уровней.
- 05Статус
Принимать операцию только по ответу системы и состоянию кода
Факт сканирования или отправки документа не означает успешную маркировочную операцию. Нужны принятый документ, корректный статус кода, отражение на балансе участника и сценарий обработки частичного отказа или ошибки.
Матрица событий
Четыре изменения состояния, которые нельзя смешивать в один «обмен с Честным знаком»
Карточка товара, получение кода, движение по цепочке и выбытие имеют разные основания, документы, данные и подтверждения.
Карточка товара и нормативная применимость
До первой операции должны быть определены товарная группа, GTIN, обязательные атрибуты, разрешительные документы и связь карточки с номенклатурой 1С.
Заказ, нанесение и проверка кода
Код должен быть заказан в правильном контексте, нанесён на нужный уровень упаковки, считан оборудованием и связан с товаром, серией или производственным заданием.
Ввод, передача и приёмка в товарной цепочке
Состояние меняется через документы ввода в оборот, отгрузки и приёмки. Важны собственник товара, ЭДО, состав кодов, агрегация и результат обработки документа каждой стороной.
Продажа, иной вывод, возврат и перемаркировка
Выбытие может идти через ККТ и ОФД либо отдельным документом с причиной. Возврат, повреждённый код, отмена вывода и повторный ввод требуют самостоятельных сценариев.
Система 1С
Что должно быть связано внутри системы — от номенклатуры до исключения
Типовая поддержка операций полезна только тогда, когда она встроена в реальные документы и роли. Отдельный маркировочный интерфейс не должен создавать вторую версию товарного факта.
- 01НСИ
Связать номенклатуру 1С с товарной группой, GTIN и упаковками
В карточке товара должны быть однозначны признаки маркировки, коды продукции, единицы измерения, варианты упаковки и обязательные атрибуты. Иначе документы формально создаются, но относятся не к тому объекту.
- 02Документы
Привязать маркировочное событие к исходному документу процесса
Производственное задание, поступление, реализация, УПД, кассовый чек или акт списания должны быть основанием операции, а не существовать отдельно от неё. Пользователь не должен повторно собирать тот же товарный состав вручную.
- 03Система
Соединить ЭДО, оборудование, ОФД и обмен с системой маркировки
2D-сканер, принтер, терминал сбора данных, касса, оператор ЭДО и интеграционные сервисы выполняют разные функции. Их выбирают после описания события, данных и места работы пользователя.
- 04Исключения
Сделать ошибку, возврат и частичную приёмку частью штатного процесса
Код может не читаться, документ — отклониться, состав — разойтись, упаковка — повредиться. Система должна сохранять основание, показывать статус и давать ответственному ролью допустимое следующее действие.
Типовые ошибки
Почему формально подключённая маркировка всё равно уходит в ручные исправления
Чаще всего проект закрывает идеальное сканирование, но не определяет границы товарных групп, подтверждённый статус и действия пользователей при исключениях.
Начинать проект с покупки сканеров и принтеров
Оборудование выбирается раньше товарной группы, роли и события. В результате оно может не поддерживать нужную скорость, упаковку, рабочее место или способ проверки кода.
Проектировать один маршрут для всех товарных групп
Сроки, атрибуты, разрешительные документы, способ учёта, операции и исключения различаются. Универсальная схема скрывает требования конкретной продукции.
Считать успешное чтение Data Matrix завершением операции
Сканер подтверждает чтение символов, но не принятие документа и не изменение статуса. Ошибка может появиться позже из-за карточки товара, владельца, баланса или состава события.
Автоматизировать только идеальный поток без возвратов и расхождений
Частичная приёмка, повреждённый код, возврат покупателя, отмена документа и перемаркировка возникают в реальной эксплуатации и требуют заранее определённых полномочий.
Первый проверяемый шаг
Разбор одного маркировочного события за 10 рабочих дней
Берём одну товарную группу, одну роль компании, одно обязательное событие и одно исключение. Проверяем применимость, данные, документы, оборудование, обмен и статус от исходного факта до принятого результата.
Паспорт товара
группа, коды, упаковка, сроки и исключения
Матрица ролей
участник, подписант, владелец данных и ответственность
Карта события
основание, документ, коды, ответ и итоговый статус
Модель упаковок
экземпляр, GTIN, агрегация и транспортный уровень
Путь события в 1С
НСИ, документы, ЭДО, оборудование и внешние сервисы
Протокол исключения
ошибка, возврат, расхождение и восстановление
Публичные основания
Почему сценарий проверяется по товарной группе и событию, а не по общему чек-листу
Дата проверки: 7 августа 2026 года. Официальные материалы подтверждают роли участников и типовую поддержку операций, но конкретные атрибуты, сроки и способ учёта определяются правилами товарной группы.
Граница заявления. Сервисы и конфигурации 1С поддерживают работу с маркированными товарами, однако наличие функции не доказывает готовность конкретного ассортимента. Применимость, данные, упаковка и события проверяются на актуальную дату по выбранной группе.
Короткие ответы
Что уточнить до запуска маркировки в 1С
Товарная группа, уровень учёта, роли, личный кабинет, ЭДО, оборудование и границы первого этапа.
Задать свой вопрос01Как понять, подлежит ли конкретный товар обязательной маркировке?
Проверяются актуальные правила товарной группы, коды ТН ВЭД ЕАЭС и ОКПД2, дата производства или ввоза, тип упаковки, этап обязательности и исключения. Коммерческое название товара само по себе не является достаточным основанием.
02Если на товаре есть Data Matrix, значит его всегда нужно учитывать поэкземплярно?
Нет. Способ учёта и состав сведений зависят от товарной группы, операции, периода и характеристик продукции. В одной системе могут одновременно существовать экземплярные коды, GTIN с количеством и агрегированные упаковки.
03Чем отличаются обязанности производителя, оптовика и розницы?
Производитель или импортёр обычно описывает товар, получает и наносит коды и вводит продукцию в оборот. Оптовый участник передаёт и принимает сведения через ЭДО. Розница принимает товар и выводит его из оборота при продаже через кассовую систему. Точный состав проверяется по товарной группе.
04Можно ли оставить операции маркировки в личном кабинете, а учёт вести в 1С?
Для редких ручных исключений это возможно, но постоянное разделение создаёт две версии статуса товара и повторный ввод данных. Рабочая система должна позволять восстановить маркировочное событие до документа 1С и увидеть ответ системы.
05С какого первого этапа лучше начинать внедрение?
С одного товара или небольшой однородной группы, одной роли компании, одного обязательного события и одного исключения. Такой первый этап проверяет данные, документ, оборудование, обмен, статус и восстановление без попытки охватить весь ассортимент.
На дату проверки официальный раздел 1С описывает роли производителей, импортёров, оптовых и розничных участников, интеграцию с «Честным знаком», ЭДО, ОФД и оборудованием. Материалы сообщества системы маркировки показывают, что способ учёта, атрибуты карточки товара и упаковочная иерархия зависят от конкретной товарной группы и операции.
Вопрос по маркировке
Есть товарная группа или операция, по которой непонятны обязательные требования?
Начнём с одного товара, одной роли и одного события. Проверим основание, данные, документ, оборудование, обмен и исключение — до большого проекта и массовой закупки техники.
- Сначала применимость и событие, потом интерфейс и оборудование
- Один товарный поток от исходного документа до статуса
- Обязательное исключение проверяется вместе с идеальным сценарием