Переход на формат фискальных данных (ФФД) 1.2 принес немало технических сложностей для разработчиков и системных администраторов. Одной из наиболее частых проблем является отсутствие в печатной форме чека признака [M+], что свидетельствует о том, что проверка кода маркировки в системе «Честный Знак» (ГИС МТ) не была выполнена должным образом. Разберем детально механику формирования чека, назначение новых тегов и выясним, как правильно передавать данные из 1С в драйвер ККТ.
Проанализируем процесс взаимодействия 1С и кассового аппарата. В старых форматах (1.05) 1С просто передавала код маркировки в составе данных о товаре, и касса транслировала его в ОФД. В ФФД 1.2 процедура стала интерактивной. Теперь процесс выглядит следующим образом:
Если на любом из этих этапов происходит сбой или передаются неполные данные, в чеке вместо заветного [M+] мы увидим [M] (проверка не проводилась или проведена локально) или [M-] (проверка не прошла).
Рассмотрим структуру фискальных данных. Согласно приказу ФНС, в ФФД 1.2 появились новые реквизиты:
Многие программисты пытаются найти формирование этих тегов непосредственно в коде 1С (например, в 1С:Розница). Однако, как показывает практика, эти теги заполняются самим драйвером ККТ. Проанализируем ситуацию: 1С передает XML-пакет драйверу, в котором содержится структура чека. В этой структуре для каждой позиции должен быть указан атрибут MarkingCode. Драйвер, видя этот код и имея в памяти результат предварительной проверки, автоматически подставляет значения в теги 2102 и 2106 перед отправкой данных в фискальный накопитель.
Выясним причину, по которой признак проверки может отсутствовать. Чаще всего это происходит из-за того, что в фискальную строку (структуру чека, передаваемую в драйвер) не передается полный код маркировки в формате Base64. Рассмотрим пример логики исправления:
При формировании XML-пакета для драйвера необходимо убедиться, что поле MarkingCode заполнено строкой кода маркировки, закодированной в Base64. Если 1С передает код в «чистом» виде или не передает его вовсе в момент фискализации (полагаясь только на предварительную проверку), драйвер не сможет связать позицию в чеке с результатом проверки в ГИС МТ. Для корректного распознавания и передачи кода маркировки можно использовать обработку для восстановления невидимых символов GS в марке.
Рассмотрим, на что нужно обратить внимание в коде конфигурации (например, в модулях интеграции с библиотекой подключаемого оборудования — БПО). Для корректной фискализации маркированного товара в ФФД 1.2 структура данных позиции чека должна содержать правильно заполненный признак способа расчета и тип номенклатуры. Но ключевым является заполнение кода маркировки.
Посмотрим на пример логики формирования данных для драйвера:
// Пример заполнения структуры для маркированного товара
ДанныеПозиции = Новый Структура;
ДанныеПозиции.Вставить("Наименование", "Товар маркированный");
ДанныеПозиции.Вставить("Количество", 1);
ДанныеПозиции.Вставить("Цена", 100);
// Критически важный момент:
// MarkingCode должен быть передан в формате Base64
ДанныеПозиции.Вставить("MarkingCode", Base64Строка(ПолныйКодМаркировкиБинарный));
Важно помнить, что MarkingCode в ФФД 1.2 — это не просто строка DataMatrix, а структура, которую драйвер ожидает в определенном формате. Если вы используете актуальные версии БПО, система делает это автоматически, но при наличии доработок или использовании устаревших драйверов (например, Атол версии ниже 10.9), этот механизм может нарушаться. Для самостоятельного внедрения механизма подойдёт шаблон интеграции и обработки маркировки под ФФД 1.2.
Иногда возникает ситуация: в печатном чеке гордо красуется [M+], ОФД видит все теги (2102 со значением 0, 2106 со значением 15), но в личном кабинете «Честного Знака» документ не появляется. Разберем, почему это происходит:
Подводя итог, для стабильной работы маркировки выполним следующие шаги:
MarkingCode в составе XML-пакета чека в формате Base64.Соблюдение этих технических нюансов гарантирует корректное выбытие товаров и отсутствие претензий со стороны контролирующих органов.