С внедрением разрешительного режима (РР) процесс продажи маркированной продукции существенно усложнился. Теперь недостаточно просто считать код маркировки (КМ) и отправить его в чеке. Система требует обязательной предварительной проверки КМ в системе «Честный ЗНАК» непосредственно перед формированием фискального документа. Если проверка возвращает отрицательный результат, продажа должна быть заблокирована. Разберем подробно, как это реализовать на уровне программного кода и настроек оборудования, основываясь на опыте работы с ККТ АТОЛ и платформой 1С. Для интеграции без самостоятельной разработки с нуля можно использовать готовое решение для проверки кодов маркировки в 1С.
В обычном режиме ФФД 1.2 касса отправляет уведомление о реализации маркированного товара в ОФД, который затем передает данные в систему маркировки. Проверка происходит «постфактум». В разрешительном режиме кассовое ПО (или сама ККТ) должно выполнить запрос к CDN-площадкам «Честного ЗНАКА» до момента закрытия чека. Рассмотрим этот механизм подробнее.
Важно понимать, что при РР контроль осуществляется не только по формальным признакам корректности кода, но и по статусу товара в системе (принадлежит ли товар продавцу, не выведен ли он уже из оборота, не истек ли срок годности). Для обеспечения этой логики нам потребуется актуальное программное обеспечение.
Проанализируем технические требования к оборудованию. Использование устаревших прошивок — самая частая причина ошибки Неверный формат команды или некорректного заполнения тегов. Для корректной работы разрешительного режима на устройствах АТОЛ (например, АТОЛ 77Ф или FPrint-22ПТК) необходимо обеспечить следующие условия:
Перед тем как переходить к коду, выясним, как касса общается с системой маркировки. Для запросов в разрешительном режиме используется токен участника оборота (Cloud Token). Его необходимо сгенерировать в личном кабинете «Честного ЗНАКА» и прописать в настройках 1С или передавать в драйвер. Для пошаговой настройки кассового места в конфигурации 1С пригодится инструкция по настройке РМК для разрешительного режима.
Кроме того, кассовое ПО должно уметь работать с CDN-площадками. Это распределенная сеть серверов, которая позволяет максимально быстро получить ответ. Список этих площадок динамический, и его нужно периодически обновлять через API «Честного ЗНАКА».
Разберем последовательность действий при продаже товара. Если вы используете «свой механизм продаж» (самописный интерфейс кассира), стандартный вызов метода формирования чека не сработает. Вы должны реализовать сессию регистрации КМ. Рассмотрим пошагово правильный алгоритм:
Посмотрим на пример логики реализации этой последовательности на языке 1С (через методы драйвера):
// Пример упрощенной логики работы с драйвером АТОЛ 10
РезультатОткрытия = ОбъектДрайвера.openModelRegistrationSession();
Если РезультатОткрытия = 0 Тогда
// Устанавливаем параметры КМ (код маркировки в Base64 или Hex)
ОбъектДрайвера.setParam(ОбъектДрайвера.LIBFPTR_PARAM_MARKING_CODE, КодМаркировки);
ОбъектДрайвера.setParam(ОбъектДрайвера.LIBFPTR_PARAM_MARKING_CODE_TYPE, ТипМаркировки);
// Запускаем запрос
ОбъектДрайвера.beginMarkingCodeCheck();
// Цикл ожидания ответа (асинхронно)
Для Итератор = 1 По 10 Цикл
ОбъектДрайвера.getMarkingCodeCheckStatus();
Статус = ОбъектДрайвера.getParamInt(ОбъектДрайвера.LIBFPTR_PARAM_MARKING_CODE_CHECK_STATUS);
Если Статус = 1 Тогда // Проверка завершена
Прервать;
КонецЕсли;
// Пауза 200-500 мс
Приостановить(0.2);
КонецЦикла;
// Получаем результат
РезультатПроверки = ОбъектДрайвера.getParamInt(ОбъектДрайвера.LIBFPTR_PARAM_MARKING_CODE_VALIDATION_RESULT);
Если РезультатПроверки = 1 Тогда // Проверка пройдена
ОбъектДрайвера.acceptMarkingCode();
Иначе
ОбъектДрайвера.declineMarkingCode();
Сообщить("Товар запрещен к продаже системой маркировки!");
КонецЕсли;
ОбъектДрайвера.closeModelRegistrationSession();
КонецЕсли;
Выясним причину, по которой часто возникает ошибка при записи тегов. В разрешительном режиме критически важно корректно заполнять структуру чека данными, полученными от системы маркировки. Вместо устаревшего тега 1260, в чеке должны фигурировать результаты проверки в тегах 1262–1265:
Если вы вручную формируете структуру чека, убедитесь, что драйвер АТОЛ получает эти данные автоматически после вызова acceptMarkingCode(). В противном случае ОФД может отклонить чек.
Рассмотрим подробнее сроки и специфику. Разрешительный режим вводится поэтапно. На текущий момент он обязателен для табака и пива в кегах. Для организаций, торгующих разливным пивом, обязателен также учёт оборота слабоалкогольной продукции, для которого настраивают автоматический обмен данными между 1С и ЕГАИС с целью проверки сведений об импортёрах или производителях. Однако, начиная с 2024 года, он расширяется на молочную продукцию, воду, антисептики, БАДы, одежду и обувь.
Проанализируем поведение системы при отсутствии связи. Законодательство допускает режим «Аварийной продажи». Если в течение 1.5 секунд ответ от системы маркировки не получен, касса может разрешить продажу с соответствующим признаком в чеке. Однако это допустимо только при условии, что кассовое ПО зафиксировало попытку запроса.
Для успешного внедрения разрешительного режима выполните следующие действия:
openModelRegistrationSession и асинхронный getMarkingCodeCheckStatus.Помните, что первый запрос после включения кассы или долгого простоя может отрабатывать дольше обычного (проблема "первого запроса"). Рекомендуется выполнять фоновый "прогревочный" запрос при открытии смены, чтобы подгрузить необходимые библиотеки и списки CDN-площадок.