Как убрать строку Последующая оплата (кредит) в чеке 1С:УПП и избежать ошибки Чек оплачен не полностью

При работе в устаревших конфигурациях, таких как 1С:Управление производственным предприятием (УПП) на платформе 8.2 или 8.3 в режиме обычных форм, программисты часто сталкиваются с проблемой некорректного формирования чеков на онлайн-кассах. Одной из наиболее раздражающих заказчика проблем является появление строки «Последующая оплата (кредит)» в чеке при приеме частичной оплаты (аванса) или предоплаты. Попытка просто «вырезать» эту строку из кода приводит к блокировке пробития чека самой кассой с ошибкой «Чек оплачен не полностью». Рассмотрим подробно, почему это происходит и как правильно решить задачу с точки зрения кода и законодательства.

Почему возникает ошибка Чек оплачен не полностью?

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

Сумма всех товарных позиций = Сумма всех типов оплат.

В современных онлайн-кассах существует пять основных типов оплаты (тег 1081):

1. Наличные.
2. Безналичные (электронные).
3. Предварительная оплата (зачет аванса, внесенного ранее).
4. Последующая оплата (кредит) — сумма, которую клиент еще должен доплатить.
5. Иная форма оплаты (встречное предоставление, бартер).

Когда мы пытаемся пробить чек в 1С:УПП, система анализирует документ-основание (например, Заказ покупателя или Реализацию). Если сумма документа составляет 10 000 рублей, а клиент вносит только 2 000 рублей наличными, 1С по умолчанию формирует таблицу оплат, где 2 000 руб. — это «Наличные», а 8 000 руб. — это «Кредит». Если программист комментирует строку кода, добавляющую кредит в таблицу оплат, 1С отправляет в кассу товар на 10 000 руб., но оплату только на 2 000 руб. Касса видит «недостачу» в 8 000 руб. и выдает ошибку «Чек оплачен не полностью». Таким образом, просто удалив строку из кода, мы нарушаем логику работы ККТ.

Разница между Авансом, Предоплатой и Полным расчетом

Чтобы убрать строку «Кредит», нам необходимо изменить Признак способа расчета. Проанализируем три основных ситуации:

• Предоплата: используется, когда мы берем деньги за конкретный товар или услугу, которые еще не переданы клиенту. Сумма в чеке при этом должна быть равна сумме фактически внесенных денег. Кредит здесь не возникает.
• Аванс: используется, когда перечень товаров или услуг еще точно не определен. В чеке указывается только сумма платежа, а не детализация позиций. Кредит также отсутствует.
• Полный расчет: признак, который ставится в момент передачи товара или оказания услуги. Если в этот момент оплата вносится не полностью, касса обязана зафиксировать остаток как «Кредит».

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

Решение проблемы через изменение Признака способа расчета

Для исправления ситуации нам необходимо внести изменения в логику формирования данных для кассы. В типовой УПП за это отвечает процедура ПодготовитьДанныеДляФискализацииЧека. Найдем её в общих модулях или модулях менеджеров документов и проанализируем алгоритм заполнения таблицы оплат.

Рассмотрим пример кода, который позволит нам принудительно установить признак «Предоплата», если мы не хотим видеть кредит:

// В процедуре подготовки данных для ККТ
Если ЭтоЧастичнаяОплата Тогда
    // Устанавливаем признак способа расчета (Тег 1214)
    // 1 - Предоплата 100%, 2 - Предоплата частичная, 3 - Аванс
    ПризнакСпособаРасчета = 2; 
    
    // Важно: сумма позиций в чеке должна быть равна сумме внесенных денег
    // Если мы передаем список товаров из Заказа, их суммы нужно пропорционально уменьшить
    // до суммы фактического платежа, либо пробивать одной строкой как аванс.
КонецЕсли;

Выясним причину, по которой 1С:УПП может ошибочно считать оплату кредитом. Чаще всего это происходит из-за того, что в структуру ОбщиеПараметры передается полная сумма документа-основания. Чтобы убрать кредит, нужно гарантировать, что общая сумма в таблице товаров (TableGoods) совпадает с итогом по таблице оплат (TablePayments).

Алгоритм действий для программиста

1. Проанализируем документ, из которого пробивается чек. Если это ПлатежныйПриходныйОрдер или ОплатаОтПокупателяПлатежнойКартой, созданные на основании ЗаказаПокупателя, но до формирования РеализацииТоваровУслуг, то это Предоплата.
2. В коде формирования чека найдем место, где заполняется ПризнакСпособаРасчета. Вместо значения ПолныйРасчет (обычно это 4) установим значение ПредоплатаЧастичная (2).
3. Проверим заполнение таблицы товаров. Если мы хотим избежать кредита, то сумма всех строк в TableGoods должна в точности равняться сумме документа оплаты.
4. Если клиент настаивает на том, что это «Аванс» (когда услуги еще не оказаны и стоимость может измениться), следует передавать в кассу одну строку с наименованием «Аванс по заказу №...» и суммой платежа, установив ПризнакСпособаРасчета = 3.

Юридический аспект и 54-ФЗ

Важно предупредить клиента, что простое удаление строки «Кредит» при фактически оказанной услуге является нарушением 54-ФЗ. Если товар отгружен (создана Реализация) на 100 рублей, а оплачено 20 рублей, то закон обязывает указать в чеке 80 рублей как «Последующую оплату». Если же мы пробиваем чек на 20 рублей из ПКО (без отгрузки), то это предоплата, и никакого кредита в чеке быть не должно по закону.

Рассмотрим схему правильного документооборота в УПП для избежания «Кредита»:

• Шаг 1: Заказ покупателя (сумма 3000).
• Шаг 2: ПКО на основании заказа (сумма 1000). Пробиваем чек. В коде проверяем: так как реализации еще нет, ставим способ расчета «Предоплата». Сумма товаров в чеке = 1000. Результат: Кредита нет.
• Шаг 3: Реализация товаров и услуг. Пробиваем второй чек. В нем указываем способ оплаты «Зачет аванса» на 1000 руб. и «Наличные/Безналичные» на 2000 руб. Результат: Кредита нет.

Таким образом, решение задачи кроется не в комментировании строк формирования таблицы оплат, а в корректном управлении типами оплат и признаками способа расчета в зависимости от стадии сделки.