При переходе на формат фискальных данных (ФФД) 1.05 пользователи конфигурации «Управление производственным предприятием» (УПП) редакции 1.3 часто сталкиваются с неприятной ситуацией. При попытке пробить чек из документа Приходный кассовый ордер (ПКО) касса либо выдает ошибку «неверный вид оплаты (постоплатой (Кредит))», либо пробивает чек на сумму, значительно превышающую фактический платеж, разбивая ее на наличные и последующую оплату (кредит).
В этой статье мы подробно разберем, почему возникает данная проблема с точки зрения методологии ФФД 1.05 и технических особенностей взаимодействия платформы 1С с драйверами АТОЛ, а также рассмотрим пошаговые варианты ее решения.
---
Для начала проанализируем логику работы ФФД 1.05. Когда мы создаем ПКО на основании документа Реализация товаров и услуг (РТИУ), система связывает оплату с конкретной отгрузкой. Предположим, общая сумма по накладной составляет 5 338,89 рублей, а клиент вносит в кассу только часть суммы — 2 500 рублей.
Согласно требованиям ФФД 1.05, если в момент совершения платежа происходит передача товара покупателю (или товар уже был передан ранее), в чеке обязательно должен быть отражен весь перечень товарных позиций на их полную стоимость. Фискальный накопитель не может просто принять 2 500 рублей без привязки к конкретным товарам, если ПКО выписан на основании расходной накладной.
В связи с этим система автоматически разбивает оплату в XML-пакете, отправляемом на кассу, на две составляющие:
С точки зрения законодательства это абсолютно корректное поведение. Проблема заключается в том, что кассовый аппарат или драйвер ККТ часто оказываются не готовы принять такую структуру платежа.
---
Выясним, почему ККТ выдает ошибку при попытке зарегистрировать чек с типом оплаты «Кредит». Как правило, к этому ведут три основные причины:
---
Рассмотрим самое правильное и надежное решение, которое не требует вмешательства в программный код 1С и позволяет вести учет в строгом соответствии с требованиями законодательства.
Выполним следующие шаги по настройке рабочего места:
После правильного сопряжения 32-битного драйвера и платформы 1С корректно передаст XML-сплит оплаты на кассу. Чек пробьется на всю сумму сделки с выделением кредитной части, а последующие оплаты по этому контрагенту будут закрывать долг без дублирования товарных позиций.
---
Если специфика вашей учетной политики не требует детального отражения передачи товаров в кредит на кассовом аппарате, и вам нужно просто зафиксировать поступление наличных средств в размере 2 500 рублей, проанализируем обходные пути в рамках стандартного функционала УПП 1.3.
Для того чтобы 1С не пыталась сопоставить платеж с товарной частью накладной и не рассчитывала остаток долга как «Кредит», выполним следующие действия:
В этом случае 1С классифицирует данный платеж как обычный аванс или общую оплату по договору. Программа сформирует XML-пакет без перечисления товарного состава накладной, и чек успешно пробьется на фактическую сумму 2 500 рублей с признаком способа расчета «Аванс» или «Частичный расчет».
---
Если бизнес-процессы требуют, чтобы ПКО обязательно создавался на основании конкретной реализации, но при этом чек ККТ должен пробиваться строго на сумму платежа без кредитных обязательств, нам придется внести небольшие изменения в программный код.
Проанализируем, где в УПП 1.3 формируется XML-пакет для передачи на кассу. Обычно этот код сосредоточен в общем модуле МенеджерОборудованияВызовСервера или в модуле обработки обслуживания ККТ (например, Обработка.АТOЛККТДокументы).
Найдем функцию, отвечающую за подготовку XML-данных (например, ПолучитьXMLПакетДляФискализацииЧека), и найдем фрагмент кода, где заполняется таблица видов оплат. Нам необходимо принудительно скорректировать заполнение оплат, исключив добавление строки с типом «Постоплата».
Посмотрим на пример программной доработки:
// Пример корректировки формирования таблицы оплат в общем модуле
// Находим место, где обходится коллекция платежей чека
ТаблицаОплат = Новый ТаблицаЗначений;
ТаблицаОплат.Колонки.Добавить("ТипОплаты", Новый ОписаниеТипов("Число"));
ТаблицаОплат.Колонки.Добавить("Сумма", Новый ОписаниеТипов("Число"));
// Предотвращаем разделение на Кредит
// Вместо распределения остатка долга в "Постоплату (Кредит)"
// принудительно устанавливаем только фактически полученную сумму ПКО
СуммаФизическогоПлатежа = ДокументОбъект.СуммаДокумента;
НоваяСтрока = ТаблицаОплат.Добавить();
НоваяСтрока.ТипОплаты = 0; // 0 - Наличные (или 1 - Безналичные/Электронные в зависимости от ПКО)
НоваяСтрока.Сумма = СуммаФизическогоПлатежа;
// Код, который добавлял строку постоплаты (Кредита), мы комментируем:
// Если СуммаЧека > СуммаФизическогоПлатежа Тогда
// СтрокаКредита = ТаблицаОплат.Добавить();
// СтрокаКредита.ТипОплаты = 3; // Постоплата
// СтрокаКредита.Сумма = СуммаЧека - СуммаФизическогоПлатежа;
// КонецЕсли;
При использовании такого изменения касса будет получать информацию о платеже только на фактически внесенную сумму ПКО, и ошибка «неверный вид оплаты» перестанет беспокоить пользователей, так как тип оплаты «Кредит» (индекс 3) больше не будет передаваться фискальному регистратору.
Обратите внимание: перед применением программных изменений обязательно проконсультируйтесь с вашей бухгалтерией и аудиторами, так как несоответствие товарного состава чека и суммы отгрузки в некоторых случаях может вызвать вопросы со стороны налоговых органов при проверках соблюдения 54-ФЗ.