Как реализовать передачу кодов маркировки в 1С при переходе на ФФД 1.2 для ККТ Атол

Переход на формат фискальных данных (ФФД) 1.2 в старых конфигурациях 1С, таких как УПП 1.3 или УТ 10.3, представляет собой сложную задачу для разработчика. В отличие от предыдущих форматов, ФФД 1.2 требует не просто передачи строки кода маркировки, а выполнения полноценной процедуры проверки КМ через фискальный накопитель и систему «Честный Знак». Рассмотрим подробнее, как адаптировать программный код и XML-структуры для корректной работы с оборудованием Атол.

Разберем принципиальные отличия ФФД 1.2 от ФФД 1.05/1.1

Проанализируем ситуацию: раньше для передачи маркированного товара в чек достаточно было заполнить тег 1162 (через структуру GoodCodeData). При переходе на ФФД 1.2 этот механизм кардинально изменился. Теперь касса должна сначала отправить запрос на проверку кода маркировки в ОФД, получить ответ и только после этого разрешить продажу с признаком [М+].

Если вы попытаетесь использовать старый метод формирования XML, вы неизбежно столкнетесь с ошибкой «Неподдерживаемый тип кода товара». Это происходит потому, что ККТ под управлением ФФД 1.2 ожидает иную типизацию данных и структуру атрибутов.

Как правильно кодировать и передавать марку

Выясним причину основных ошибок при передаче данных. Код маркировки (КМ) необходимо передавать целиком, включая так называемый «криптохвост» (ключ проверки и имитовставку). Если передать только серийный номер и GTIN (короткий код), проверка в ОФД может вернуть статус [М-], что будет означать отрицательный результат проверки.

Рассмотрим пошагово процесс подготовки данных:

1. Считываем код сканером в «сыром» виде (со всеми спецсимволами, такими как GS — ASCII 29).
2. Преобразуем полученную строку в формат Base64. Это обязательное условие для передачи через XML-инвентарь драйвера Атол.
3. Используем правильный атрибут в XML-структуре в зависимости от типа товара.

Новая структура XML для GoodCodeData в ФФД 1.2

Посмотрим на пример кода, который часто использовался в старых версиях УПП и который перестал работать:

// Старый вариант (не работает в ФФД 1.2)
ЗаписьXML.ЗаписатьНачалоЭлемента("GoodCodeData");
ЗаписьXML.ЗаписатьАтрибут("StampType", "1520");
ЗаписьXML.ЗаписатьАтрибут("MarkingCode", КодМаркировки);
ЗаписьXML.ЗаписатьКонецЭлемента();

Для ФФД 1.2 нам необходимо изменить наименование реквизита. Проанализируем допустимые значения атрибутов:

• KMK — используется для табачной продукции.
• GS1.M — используется для обуви, одежды, шин и других товаров, маркируемых по стандарту GS1 (полный код с криптохвостом).
• GS1.0 — сокращенный код (без криптохвоста), использовать крайне не рекомендуется для розничных продаж.
• MI — для изделий из меха (Киз).

Таким образом, правильная реализация для обуви (как в рассматриваемом случае) будет выглядеть следующим образом:

Если НЕ ПустаяСтрока(РеквизитКодаТовара) Тогда
    // РеквизитКодаТовара должен быть предварительно сконвертирован в Base64
    ШтрихкодBase64 = Base64Строка(Новый Картинка(Новый ДвоичныеДанныеИзСтроки(ПолныйКМ))); 
    
    ЗаписьXML.ЗаписатьНачалоЭлемента("GoodCodeData");
    // Используем атрибут GS1.M для полной марки обуви
    ЗаписьXML.ЗаписатьАтрибут("GS1.M", XMLСтрока(ШтрихкодBase64));
    ЗаписьXML.ЗаписатьКонецЭлемента();
КонецЕсли;

Важные технические условия для работы с Атол

Помимо корректного программного кода, необходимо убедиться в выполнении системных требований. Рассмотрим их подробнее:

1. Лицензия на маркировку: На кассах Атол должна быть активирована подписка (лицензия) на работу с маркировкой. Без неё драйвер будет возвращать ошибку «Неподдерживаемый тип кода товара» даже при идеально правильном XML.
2. Версия драйвера и компоненты: Для работы с ФФД 1.2 требуется интеграционная компонента 1С версии не ниже 3.0 (поставляется с ДТО 10.9.x и выше). Если в вашей УПП 1.3 используется старая компонента ATOL_KKT_10 версии 2.x, её необходимо заменить.
3. Прошивка ККТ: Касса должна быть прошита под актуальную версию (платформа 5.0), поддерживающую ФФД 1.2.

Алгоритм проверки кода маркировки

Рассмотрим подробнее процесс «общения» с кассой. В ФФД 1.2 мы не просто печатаем чек, а реализуем следующий цикл:

1. Команда очистки: Перед началом работы с чеком рекомендуется вызвать метод ClearMarkingCodeValidStatus для очистки результатов предыдущих проверок в буфере ККТ.

2. Запрос статуса: Касса отправляет данные в ОФД. В коде 1С мы должны дождаться ответа. Это делается через методы beginMarkingCodeCheck и последующий getMarkingCodeCheckStatus.

3. Анализ результата: Если проверка прошла успешно, в объекте GoodCodeData передаются параметры для печати. В чеке появится заветный символ [М+].

Если вы работаете через типовые обработки обслуживания 1С (ATOLKKT.epf), убедитесь, что в функции СформироватьXMLПакетДляЧека логика заполнения GoodCodeData соответствует новым требованиям. Если конфигурация сильно изменена, как в случае автора темы, лучшим решением будет точечная доработка модуля формирования XML-строки с использованием условий по версии ФФД.

Почему может возникать ошибка парсинга XML?

Проанализируем ситуацию, когда возникает ошибка Syntax error: value, object or array expected. Это часто случается, если в атрибут GS1.M попадает пустая строка или некорректно сформированный Base64. Убедитесь, что при конвертации в Base64 вы используете именно двоичные данные считанного кода, а не просто строку GTIN. Также проверьте, чтобы в XML не попадали запрещенные символы управления, которые сканер может добавлять в начало или конец строки кода.

Используйте метод XMLСтрока() для подготовки данных перед записью в атрибут, это поможет избежать проблем с типизацией данных внутри XML-пакета, передаваемого драйверу.