При оформлении оптовых и розничных продаж в программных продуктах 1С на платформе ERP-класса (включая 1С:Управление торговлей 11, 1С:Комплексная автоматизация и 1С:ERP) пользователи часто сталкиваются с неожиданным поведением системы. При попытке пробить фискальный чек из документа Приходный кассовый ордер (ПКО), созданного на основании Реализации товаров и услуг (РТУ), на печать выводится признак способа расчета «Оплата кредита» (Тег 1214) и признак предмета расчета «Платеж» (Тег 1212) вместо ожидаемого «Полного расчета» и «Товара». Более того, в таком чеке может полностью отсутствовать информация о ставках и суммах НДС.
В этой статье мы подробно разберем, почему программа ведет себя именно так с точки зрения методологии учета и законодательства (54-ФЗ), какие налоговые риски это несет для бизнеса и как исправить ситуацию как стандартными, так и техническими методами.
---
Для того чтобы понять логику системы, нам необходимо проанализировать, как устроена подсистема взаиморасчетов в 1С:УТ 11. Программа строго ориентируется на хронологическую последовательность проведения документов и состояние задолженности контрагента.
Рассмотрим стандартную цепочку действий пользователя:
Реализация товаров и услуг. С этого момента в системе фиксируется переход права собственности на товар к покупателю. Поскольку оплаты еще не было, у покупателя возникает долг перед нашей организацией.Приходный кассовый ордер для приема наличных денег.В момент пробития чека из ПКО встроенный алгоритм 1С анализирует регистры расчетов. Система видит: товар уже отгружен (документ РТУ проведен ранее), то есть право собственности перешло к клиенту до момента фактической оплаты. Следовательно, с точки зрения гражданского законодательства и требований ФФД (форматов фискальных данных), эта операция классифицируется как погашение задолженности за ранее переданный товар.
Согласно требованиям ФНС для ФФД 1.05, 1.1 и 1.2:
---
Многие компании привыкли работать по упрощенной схеме: они оформляют отгрузку и оплату одновременно (день в день), но фискальный чек пробивают только один раз — из ПКО. Чек из документа Реализации они не бьют вообще.
В результате возникает критическая ошибка ведения кассового учета:
Для налогового инспектора эта картина выглядит как грубое нарушение правил применения ККТ (ч. 4 ст. 14.5 КоАП РФ): зафиксирован факт платежа по какому-то обязательству, но сама продажа товара и начисление НДС по кассе не проходили. Это гарантированный повод для камеральной проверки и штрафов.
---
Если мы хотим оставаться в рамках стандартного функционала программы и не прибегать к программированию, у нас есть несколько путей решения.
Если клиент сначала платит деньги, а затем забирает товар, необходимо поменять порядок документов в системе:
Приходный кассовый ордер. Пробиваем из него чек. Система увидит, что отгрузки еще не было, и автоматически присвоит чеку признак «Предоплата 100%» (или «Аванс») с корректным выделением НДС.Реализация товаров и услуг и бьем чек из него. Программа поймет, что произошел зачет ранее полученных средств, и распечатает чек с признаком «Полный расчет», где в качестве способа оплаты будет указан «Зачет аванса».Если отгрузка и оплата происходят одновременно, попробуем пробивать чек непосредственно из документа Реализация товаров и услуг. В этом случае система сформирует один чек, в котором будет указан признак «Полный расчет», а в типе оплаты внизу чека будет написано «Наличными» (или «Безналичными» в зависимости от настроек), так как отгрузка и оплата закрываются одновременно в рамках одной транзакции. Для упрощения этой задачи можно использовать расширение для создания чеков ККМ на основании реализации.
В актуальных версиях 1С:УТ 11.4 и 11.5 разработчики добавили интерактивное окно «Предпросмотр чека» перед его физической отправкой на ККТ. Если в вашей базе включена эта опция:
<Авто> выберите вручную значение «Полный расчет».Если ваши продажи ориентированы на конечного покупателя, который оплачивает и забирает товар в один момент, классическая оптовая схема (РТУ + ПКО) является избыточной. В таких случаях правильнее использовать функционал розничной торговли:
---
Что делать, если обновлять конфигурацию нет возможности, менеджеры категорически отказываются менять параметры вручную через предпросмотр чека, а учет требует проведения ПКО строго после РТУ? В этом случае проблему можно решить технически, внедрив небольшое расширение конфигурации. При необходимости можно воспользоваться готовым расширением для 1С:УТ для коррекции признаков расчета и заполнения НДС.
Нам необходимо перехватить процедуру подготовки данных для фискализации чека и принудительно подменить признаки расчета, если ПКО и связанная с ним Реализация проведены в один день. Проанализируем пример кода расширения, который модифицирует структуру данных перед отправкой на ККТ:
&Вместо("ПодготовитьДанныеДляПробитияЧека")
Процедура Мой_ПодготовитьДанныеДляПробитияЧека(ПараметрыЧека, ДокументСсылка)
// Сначала вызываем стандартную обработку системы
ПродолжитьВызов(ПараметрыЧека, ДокументСсылка);
// Проверяем, что чек бьется именно из Приходного кассового ордера
Если ТипЗнч(ДокументСсылка) = Тип("ДокументСсылка.Приходный кассовый ордер") Тогда
// Анализируем табличную часть подготовленного чека
Для Каждого СтрокаЧека Из ПараметрыЧека.ТабличнаяЧасть Цикл
// Если алгоритм 1С ошибочно установил Оплату кредита
Если СтрокаЧека.СпособРасчета = ПредопределенноеЗначение("Перечисление.СпособыРасчетаПоККТ.ОплатаКредита") Тогда
// Принудительно меняем способ расчета на Полный расчет
СтрокаЧека.СпособРасчета = ПредопределенноеЗначение("Перечисление.СпособыРасчетаПоККТ.ПолныйРасчет");
// Корректируем признак предмета расчета с "Платежа" на "Товар" (или Услугу)
СтрокаЧека.ПризнакПредметаРасчета = ПредопределенноеЗначение("Перечисление.ПризнакиПредметовРасчетаПоККТ.Товар");
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецПроцедуры
Важное примечание для разработчика: Принудительная подмена признаков в коде обязывает вас гарантировать, что НДС в табличной части также рассчитан корректно. При изменении способа расчета на «Полный расчет» драйвер ККТ потребует передать валидную ставку НДС (например, 20% или 10%), иначе касса выдаст ошибку формата данных. Убедитесь, что ваше расширение также заполняет реквизит СтавкаНДС в структуре товарных строк чека на основе данных из документа-основания.
Выбор конкретного решения зависит от бизнес-процессов вашей организации. Если объемы продаж небольшие, достаточно использовать ручной выбор в окне предпросмотра чека или пробивать чеки из документа Реализации. Для высоконагруженных розничных точек лучшим выбором станет доработка логики проведения ПКО с помощью расширения конфигурации.