Как настроить отгрузку по предоплате в рознице на 1С:Управление торговлей 10.3 согласно 54-ФЗ?

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

В этой статье мы подробно разберем, как правильно выстроить цепочку документов, почему возникают расхождения в Z-отчете и как доработать систему, чтобы чеки пробивались с правильными признаками способа расчета («Предоплата» и «Полный расчет»).

1. Разница между «Предоплатой» и «Авансом» по 54-ФЗ

Перед тем как перейти к настройке программы, разберем методологическую часть. Согласно законодательству, это два разных признака способа расчета:

• Предоплата (полная или частичная): применяется, когда в момент приема денег точно известен состав покупки (конкретные номенклатурные позиции, их цена и количество). В первом чеке обязательно должен быть выведен весь перечень товаров с признаком способа расчета «Предоплата 100%» или «Предоплата».
• Аванс: применяется, когда в момент получения денег точный список товаров неизвестен (например, при покупке подарочного сертификата или внесении фиксированной суммы на баланс). В чеке указывается признак «Аванс», а товарный состав может отсутствовать.

В рассматриваемом случае покупатель выбирает конкретные товары, которых временно нет на складе. Это классическая предоплата, поэтому в первом чеке обязательно должна присутствовать номенклатура.

2. Законная схема «Двух чеков»

Реализация товара по предоплате обязывает продавца пробить на онлайн-кассе два отдельных чека в разные моменты времени:

1. Чек №1 (При получении денег от клиента):
   • Признак способа расчета: «Предоплата 100%» или «Предоплата» (если вносится часть суммы).
   • Способ оплаты: «Наличные» или «Безналичные».
   • Этот чек подтверждает факт приема денежных средств.
2. Чек №2 (При передаче товара клиенту):
   • Признак способа расчета: «Полный расчет».
   • Способ оплаты: «Зачет аванса» (сумма наличными или картой в этот момент равна нулю).
   • Этот чек подтверждает факт отгрузки товара и закрытие долга перед покупателем.

3. Настройка и ведение цепочки документов в «1С:УТ 10.3»

Выясним, как должна выглядеть стандартная цепочка документов в системе для автоматического формирования правильных чеков.

Шаг 1. Оформление заказа и прием предоплаты

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

1. Создаем документ Заказ покупателя. В нем детально расписываем всю номенклатуру, количество и цены. Этот документ выступает спецификацией нашей сделки.
2. На основании созданного заказа вводим документ оплаты:
   • Приходный кассовый ордер (ПКО) — если клиент платит наличными.
   • Оплата от покупателя по платежной карте — если оплата производится банковской картой через эквайринговый терминал.

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

Шаг 2. Отгрузка товара и зачет аванса

Когда товар поступает на склад и клиент приходит его забирать, выполняем следующие действия:

1. На основании того же документа Заказ покупателя создаем документ Реализация товаров и услуг. При проведении документа система автоматически зачтет ранее полученный аванс по ПКО или эквайрингу.
2. Открываем форму документа Реализация товаров и услуг, переходим на вкладку «Фискализация данных» (или нажимаем кнопку «Чек» на панели инструментов) и пробиваем второй чек.
3. В кассовом аппарате этот чек пройдет со способом расчета «Полный расчет», а тип оплаты будет передан как «Зачет аванса» (физического движения денег по кассе не произойдет, но операция будет фискализирована).

4. Анализ технических проблем с Z-отчетом и закрытием смены

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

Проблема 1. ПКО пробивается, но суммы нет в Z-отчете кассы

Если чек из ПКО физически распечатался на фискальном регистраторе (на нем есть QR-код, заводской номер ККТ и фискальный признак документа), эти деньги физически обязаны попасть в сменный Z-отчет ККТ в графу «Наличные».

Если этого не происходит, возможны следующие причины:

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

Проблема 2. Сумма ПКО не попадает в Отчет о розничных продажах в 1С

Документ Отчет о розничных продажах (ОРП) в конце смены собирает данные только из проведенных документов «Чек ККМ». То, что суммы по ПКО туда не попадают — это абсолютно нормальное и правильное поведение системы.

Выясним почему: деньги по ПКО проводятся напрямую в кассу предприятия (счет 50.01) в момент оформления документа. Если бы эти суммы попадали еще и в ОРП, в бухгалтерском и управленческом учете произошло бы двоение выручки и остатка наличных в кассе.

Кассир в конце смены сверяет общую наличность в кассовом ящике со сводным показателем: Сумма по ОРП (розница) + Сумма по всем ПКО за день. Полученный итог должен в точности совпадать с Z-отчетом ККТ.

5. Техническая реализация и доработка кода

Если в вашей версии УТ 10.3 при печати чека из ПКО товары не переносятся автоматически, либо неверно определяется признак способа расчета, потребуется небольшая доработка кода.

Посмотрим на пример перегрузки процедуры печати чека. Нам необходимо перенаправить логику формирования XML-пакета для ККТ так, чтобы при наличии документа-основания (Заказа) табличная часть бралась из него:

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

Используя данный подход, вы сможете гарантировать корректность фискализации предоплат. Программа будет автоматически разделять платежи и отгрузки, формируя правильные признаки расчетов, что полностью обезопасит бизнес от штрафных санкций со стороны налоговых органов.