Почему при пробитии чека по платежной карте в УТ 10.3 печатается «Последующая оплата (кредит)» вместо «Электронными» и как это исправить?

Программист 1С v8.3 (Обычные формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция

При адаптации старых конфигураций 1С:Управление торговлей 10.3 под требования онлайн-касс (ФФД 1.05 и ФФД 1.2) разработчики часто сталкиваются с неприятной проблемой. При пробитии чека из документа «Оплата от покупателя платежной картой» (ОПК) на фискальном документе выводится тип оплаты «Последующая оплата (кредит)» (или «Постоплата»), хотя фактически расчет был произведен безналичными средствами, и на чеке должно быть напечатано «Электронными» (или «Безналичными»).

В этой статье мы подробно разберем, почему возникает это расхождение, проанализируем механизм взаимодействия 1С с Библиотекой подключаемого оборудования (БПО) и выясним, какие изменения необходимо внести в код конфигурации для корректной фискализации безналичных платежей.

Выясняем причину проблемы: почему число «1» превращается в «Кредит»

В старых версиях конфигураций 1С и драйверов ККТ (времен ФФД 1.0) типы оплат передавались в кассу в виде простых целочисленных индексов:

0 — Наличные
1 — Безналичные (электронные, платежная карта)
2 — Кредит / Постоплата
3 — Аванс / Предоплата

Однако с переходом на форматы фискальных данных ФФД 1.05 и выше архитектура взаимодействия изменилась. Современная БПО больше не отправляет числовые индексы видов оплат напрямую в драйвер ККТ. Вместо этого в общий модуль передается структура данных чека, на основе которой БПО формирует стандартизированный XML-пакет (так называемый CheckPackage). Внутри этого пакета суммы распределяются по специальным атрибутам тега <Payments>:

Cash — для наличных расчетов;
ElectronicPayment — для безналичных (электронных) расчетов;
PrePayment — для предварительной оплаты (аванса);
PostPayment — для последующей оплаты (кредита);
Barter — для встречного предоставления.

Для того чтобы БПО правильно определила, в какой именно атрибут XML-пакета нужно поместить сумму, поле ТипОплаты в таблице оплат должно содержать не просто число, а **ссылку на системное перечисление** ПеречислениеСсылка.ТипыОплатыККТ.

Если в коде подготовки данных чека жестко прописано числовое значение (например, СтрокаОплаты.Вставить("ТипОплаты", 1);), БПО при попытке сопоставить тип данных не находит соответствия с элементами перечисления ТипыОплатыККТ. В результате проверка типов завершается неудачей, и система распределяет платеж по алгоритму «по умолчанию» (часто сваливая сумму в PostPayment, что касса интерпретирует как «Кредит»).

---

Пошаговое руководство по исправлению кода в УТ 10.3

Для исправления этой ошибки нам необходимо заменить числовые идентификаторы типов оплат на соответствующие предопределенные значения перечисления 1С. Рассмотрим пошагово, как это сделать.

Шаг 1. Поиск процедуры подготовки данных

Перейдем в конфигуратор и найдем процедуру, отвечающую за подготовку параметров фискализации для документа «Оплата от покупателя платежной картой». Обычно она располагается в модуле объекта самого документа или в общем модуле, отвечающем за интеграцию с ККТ. Нам нужна процедура:

ПодготовитьДанныеДляФискализацииЧекаОПК(Ссылка, ОбщиеПараметры)

Шаг 2. Анализ исходного кода формирования таблицы оплат

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


// Оплаты    
СуммаТипаОплаты = СуммаДокумента;
Если СуммаТипаОплаты <> 0 И СуммаТипаОплаты <> Неопределено Тогда
    СтрокаОплаты = Новый Структура();
    СтрокаОплаты.Вставить("ТипОплаты", 1); // Исходная проблемная строка
    СтрокаОплаты.Вставить("Наименование", "Платежная карта");
    СтрокаОплаты.Вставить("Сумма", СуммаТипаОплаты);
    ОбщиеПараметры.ТаблицаОплат.Добавить(СтрокаОплаты);
КонецЕсли;

Здесь мы видим явное присвоение числового значения 1 свойству ТипОплаты. Это и приводит к некорректному поведению при формировании XML-пакета.

Шаг 3. Внесение изменений в код

Заменим жестко прописанное число 1 на обращение к предопределенному значению перечисления ТипыОплатыККТ.Электронно. Измененный фрагмент кода должен выглядеть так:


// Оплаты    
СуммаТипаОплаты = СуммаДокумента;
Если СуммаТипаОплаты <> 0 И СуммаТипаОплаты <> Неопределено Тогда
    СтрокаОплаты = Новый Структура();
    
    // Заменяем число 1 на предопределенное значение перечисления
    СтрокаОплаты.Вставить("ТипОплаты", ПредопределенноеЗначение("Перечисление.ТипыОплатыККТ.Электронно"));
    
    СтрокаОплаты.Вставить("Наименование", "Платежная карта");
    СтрокаОплаты.Вставить("Сумма", СуммаТипаОплаты);
    ОбщиеПараметры.ТаблицаОплат.Добавить(СтрокаОплаты);
КонецЕсли;

Важное примечание: Если в вашей конфигурации перечисление ТипыОплатыККТ не интегрировано в глобальный контекст через ПредопределенноеЗначение, вы можете обратиться к нему напрямую через менеджер перечислений:

Перечисления.ТипыОплатыККТ.Электронно ---

Шаг 4. Проверка ПКО и РКО (наличные расчеты)

Аналогичную ревизию кода необходимо провести для документов «Приходный кассовый ордер» (ПКО) и «Расходный кассовый ордер» (РКО). Убедимся, что при фискализации наличных расчетов вместо числа 0 передается соответствующее значение перечисления.

Найдем процедуру подготовки данных для ПКО и проанализируем код. Вместо устаревшей строки:

СтрокаОплаты.Вставить("ТипОплаты", 0);

Необходимо использовать корректное присвоение:

СтрокаОплаты.Вставить("ТипОплаты", ПредопределенноеЗначение("Перечисление.ТипыОплатыККТ.Наличные")); ---

Что еще важно проверить в настройках торгового оборудования?

Если после внесения изменений в программный код касса все равно продолжает выводить неверный тип оплаты, выполним диагностику на уровне драйвера ККТ и параметров подключения.

Таблица типов оплат в драйвере ККТ. Подключимся к компьютеру с установленной кассой и запустим утилиту «Тест драйвера ККТ» (для АТОЛ это «Тест драйвера ККТ 10.х», для Штрих-М — «Тест драйвера ФР»). Перейдем в настройки свойств ККТ и найдем раздел «Параметры оборудования» -> «Оплата» (или «Таблицы» -> «Типы оплат»). Убедимся, что под индексом, соответствующим электронным платежам (обычно это строка №1 или №2 в зависимости от модели), задано наименование «Электронными» или «Безналичными».
Настройки интеграционной компоненты в 1С. В режиме «1С:Предприятие» перейдем в меню Сервис -> Торговое оборудование -> Подключение и настройка оборудования. Откроем параметры нашей ККТ. В некоторых версиях драйверов присутствует флаг «Исправление типа оплаты» или таблица сопоставления типов платежей 1С и ККТ. Проверим, чтобы сопоставление для «Электронно» указывало на корректный номер типа оплаты в драйвере.
Актуальность внешней компоненты. Убедимся, что версия внешней компоненты интеграции (файлы AtolKiDriver10*.dll или аналогичные для Штрих-М), загруженная в базу 1С, соответствует версии установленного на рабочем месте драйвера ККТ. Расхождение версий часто приводит к искажению структуры передаваемых XML-данных.

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

← На главную