Как программно вывести данные агента в чек на ККТ АТОЛ из 1С

При реализации агентских схем (комиссионная торговля, прием платежей в пользу третьих лиц) перед разработчиком 1С встает задача корректного отображения данных поставщика в кассовом чеке. Просто включить "галочку" в драйвере недостаточно — необходимо обеспечить передачу специфических тегов в соответствии с ФФД (форматом фискальных данных) для каждой позиции чека. В этой статье мы разберем, как правильно настроить программный вывод агента для ККТ АТОЛ.

Предварительная проверка фискализации ККТ

Прежде чем приступать к написанию кода в 1С, проанализируем состояние самой кассы. Если при первичной регистрации или перерегистрации ККТ в фискальном накопителе не был установлен признак «Агент» (или конкретный тип: комиссионер, поверенный), касса будет игнорировать любые данные об агенте, передаваемые программно. Это приведет либо к печати обычного чека без агентских реквизитов, либо к ошибке «Некорректное состояние ККТ».

Для проверки выполним следующие действия в утилите "Тест драйвера ККТ" (АТОЛ 10):

1. Перейдем в раздел «Запросы».
2. Выберем тип запроса «Параметры ККТ».
3. Найдем в списке признаков «Признак агента».

Если флаг отсутствует, потребуется перерегистрация кассы без замены ФН с установкой нужного признака деятельности.

Ключевые теги ФФД для агентской деятельности

Выясним, какие именно данные мы должны передать на кассу. Согласно требованиям ФФД (особенно для версий 1.05, 1.1 и 1.2), для агентских продаж критически важны следующие теги:

• Тег 1222: Признак агента по предмету расчета. Указывает, кем является продавец для конкретной позиции (например, комиссионером или иным агентом).
• Тег 1171: Телефон поставщика. Важно: для большинства типов агентов этот тег является обязательным. Без него чек может быть признан недействительным.
• Тег 1226: ИНН поставщика (владельца товара).
• Тег 1225: Наименование поставщика.

Реализация в 1С через Библиотеку стандартных подсистем (БСП)

Рассмотрим, как подготовить данные в 1С для передачи в драйвер. Современные конфигурации используют объект МенеджерОборудованияКлиент и структуру ПараметрыЧека. Основная ошибка заключается в попытке передать данные агента в "шапку" чека. На самом деле, если чек содержит хотя бы одну не агентскую позицию (смешанный чек), данные должны передаваться внутри массива ПозицииЧека.

Проанализируем пример кода для формирования структуры данных одной позиции:

// Создаем структуру для данных поставщика
ДанныеПоставщика = Новый Структура;
ДанныеПоставщика.Вставить("Наименование", "ООО Поставщик Плюс");
ДанныеПоставщика.Вставить("Телефон", "88005553535");

// Создаем структуру данных агента
ДанныеАгента = Новый Структура;
ДанныеАгента.Вставить("ПризнакАгента", 6); // 6 - значение для комиссионера по ФФД
ДанныеАгента.Вставить("ДанныеПоставщика", ДанныеПоставщика);
ДанныеАгента.Вставить("ИННПоставщика", "770000000000");

// Добавляем данные в строку чека
СтрокаЧека = Новый Структура;
СтрокаЧека.Вставить("Наименование", "Агентский товар");
СтрокаЧека.Вставить("Количество", 1);
СтрокаЧека.Вставить("Цена", 100);
СтрокаЧека.Вставить("Сумма", 100);
СтрокаЧека.Вставить("СтавкаНДС", "20");
СтрокаЧека.Вставить("AgentData", ДанныеАгента); // ВАЖНО: Ключ должен соответствовать стандарту БСП

ПозицииЧека.Добавить(СтрокаЧека);

Обратите внимание, что для драйверов АТОЛ версии 10 ключи внутри структуры могут называться AgentData и SupplierData. Если вы используете интеграционную компоненту, соответствующую стандартам 1С, система сама преобразует эти структуры в нужные теги.

Особенности работы через JSON-задания (Драйвер АТОЛ 10)

Если ваша интеграция реализована через прямую отправку JSON-заданий в драйвер (обходя стандартные механизмы БСП), структура объекта items должна выглядеть следующим образом. Разберем по шагам наполнение объекта:

{
  "type": "position",
  "name": "Комиссионный товар",
  "price": 500.0,
  "quantity": 1,
  "amount": 500.0,
  "tax": {
    "type": "none"
  },
  "agentInfo": {
    "type": "commissioner",
    "supplierInfo": {
      "phones": ["+79991234567"],
      "name": "ООО Склад-Опт",
      "inn": "1234567890"
    }
  }
}

В данном примере поле agentInfo.type принимает строковое значение (например, commissioner, none, agent), которое драйвер автоматически конвертирует в цифровой код тега 1222 для ФН.

Типичные проблемы и способы их решения

Проанализируем ситуацию, когда код написан верно, но данные в чеке не появляются. Выделим основные причины:

1. Старая версия прошивки ККТ: Для корректной работы с тегами 1.05/1.2 прошивка должна быть актуальной. Проверить это можно через отчет о конфигурации.
2. Отсутствие телефона: Если не передан тег 1171 (телефон поставщика), многие кассы АТОЛ в режиме ФФД 1.05 просто игнорируют весь блок агентских данных.
3. Конфликт настроек: Если в драйвере принудительно включена опция "Печатать только ИНН", то наименование поставщика (тег 1225) может не выводиться на бумажный чек, хотя в электронном виде в ОФД оно уйдет.
4. Использование FiscalString: Как отмечалось в обсуждении, некоторые старые методы печати строк (FiscalString) не поддерживают передачу тегов. Всегда используйте методы формирования чека через XML-пакет или JSON-задание.

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

Выясним причину, если касса выдает ошибку «Ошибка 0x34». Это часто означает попытку передать ИНН поставщика некорректной длины (например, с лишними пробелами или в неверном формате для физлица/юрлица). Всегда очищайте строку ИНН от лишних символов перед отправкой.

Таким образом, мы выяснили, что для вывода агента необходимо: правильно фискализировать кассу, сформировать вложенную структуру данных для каждой позиции в 1С и передать обязательный набор тегов (тип агента, ИНН и телефон поставщика).