Как правильно пробить чек из документа «Реализация товаров и услуг» в 1С и почему пишется «В кредит»?

Многие начинающие специалисты и пользователи программных продуктов 1С (в частности, 1С:Управление торговлей) сталкиваются с неприятной ситуацией. При оформлении сделки создается документ РеализацияТоваровУслуг (РТУ), клиент вносит оплату наличными или картой, но при попытке распечатать чек прямо из формы реализации фискальный аппарат выдает чек с признаком способа расчета «В кредит» (или «Передача в кредит»).

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

Законодательный контекст: почему программа выбирает «В кредит»?

Для того чтобы понять логику системы 1С, обратимся к требованиям Федерального закона № 54-ФЗ и форматам фискальных документов (ФФД 1.05 и 1.2). Налоговая служба жестко контролирует реквизит «Признак способа расчета» (тег 1214).

Согласно методологии ФНС, хозяйственная операция разделяется на два независимых события:

1. Переход права собственности (отгрузка товара) — за это в системе отвечает документ РеализацияТоваровУслуг.
2. Движение денежных средств (оплата) — за это отвечают финансовые документы, такие как ПриходныйКассовыйОрдер (ПКО) или ЭквайринговаяОперация.

Если мы пытаемся пробить чек напрямую из документа реализации без предварительно зафиксированного в системе факта оплаты, программа «видит» только отгрузку товара. С точки зрения системы, товар передан клиенту, но деньги за него еще не поступили. По закону 54-ФЗ такая операция классифицируется как отсрочка платежа, поэтому на кассу передается признак способа расчета «Передача в кредит».

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

Стандартный документооборот в 1С: как пробить чек без ошибок

Рассмотрим правильную последовательность действий (методологию), которая заложена разработчиками 1С для корректного отражения расчетов и печати чеков.

Сценарий 1: Продажа при полной или частичной предоплате

Если клиент сначала платит деньги, а затем забирает товар, мы должны пробить два чека (чек на предоплату и чек на отгрузку с зачетом предоплаты):

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

Сценарий 2: Продажа через Рабочее место кассира (РМК) или Чек ККМ

Если розничные продажи происходят в потоковом режиме «здесь и сейчас», использование цепочки документов «Заказ — Оплата — Реализация» нецелесообразно. В этом случае мы должны использовать специализированные механизмы:

• Интерфейс РМК (Рабочее место кассира).
• Документ ЧекККМ.

При использовании этих механизмов оплата и отгрузка фиксируются одновременно в рамках одного чека, и на печать сразу выводится корректный признак «Полный расчет».

Различия в реализации функционала в разных конфигурациях

Проанализируем, почему в некоторых других решениях 1С работать с чеками проще, чем в 1С:Управление торговлей (УТ):

• 1С:Бухгалтерия (БП): При печати чека из документа реализации программа открывает форму предпросмотра чека. В этой форме бухгалтер может вручную скорректировать признак способа расчета (например, принудительно выбрать «Полный расчет») и указать способ оплаты (наличные или безналичные). Разработчики предполагают, что бухгалтер обладает достаточной квалификацией, чтобы контролировать этот процесс вручную.
• 1С:Управление нашей фирмой (УНФ): Здесь реализован механизм автоматического зачета авансов. Если к расходной накладной привязан платеж, программа автоматически понимает, что нужно пробить единый чек на «Полный расчет».
• 1С:Управление торговлей (УТ) / КА / ERP: Логика этих систем более жесткая и ориентирована на строгий корпоративный контроль, где менеджеры по продажам не должны иметь возможность вручную изменять фискальные признаки и искажать отчетность.

Технические варианты решения проблемы (для программистов)

Если бизнес-процессы компании требуют печати чеков «Полный расчет» строго из документа реализации (без создания цепочки заказов и чеков на предоплату), стандартный функционал нам не подойдет. Разберем технические пути решения этой задачи.

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

// Фрагмент логики определения признака способа расчета
Если ТипЗв = Тип("ДокументСсылка.РеализацияТоваровУслуг") Тогда
    // По умолчанию типовая конфигурация жестко устанавливает кредит
    ПараметрыЧека.ПризнакСпособаРасчета = Перечисления.ПризнакиСпособаРасчета.ПередачаВКредит;
КонецЕсли;

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

1. Использование механизма внешних расширений (без снятия конфигурации с поддержки)

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

В расширении можно реализовать:

• Добавление на форму РТУ переключателя «Способ оплаты» (Наличные / Карта).
• Подмену признака способа расчета при формировании XML-пакета для ККТ с «ПередачаВКредит» на «ПолныйРасчет».
• Автоматическое создание фонового финансового документа (ПКО или Эквайринговой операции) для того, чтобы в базе данных не зависала дебиторская задолженность.

2. Использование готовых расширений типа «Единый чек»

На рынке готовых решений для 1С существуют расширения, которые модифицируют форму печати чеков из финансовых документов (ПКО / Эквайринг), созданных на основании реализации. При проведении оплаты такое расширение позволяет поставить галочку «Единый чек». В результате программа связывает отгрузку и оплату «на лету» и пробивает один-единственный чек с признаком «Полный расчет», автоматически закрывая сделку и в базе, и на кассе.

Скрытые риски «упрощения» процесса для бизнеса

Прежде чем писать доработки или устанавливать расширения, позволяющие менеджерам пробивать «Полный расчет» напрямую из реализации в один клик, необходимо учесть критически важные риски:

1. Кассовый разрыв в базе данных 1С. Если система отправит в ОФД информацию о том, что касса приняла наличные или безналичные средства, но в самой базе 1С менеджер забудет создать финансовый документ (ПКО или Эквайринг), возникнет расхождение. На кассе деньги будут числиться, а по счетам учета в программе эти суммы не пройдут. У контрагента зависнет дебиторская задолженность, которую придется закрывать вручную.
2. Проблема изменения проведенных документов. Фискальный чек является документом строгой отчетности. После его пробития корректировать состав товаров в реализации категорически запрещено, иначе данные в вашей базе разойдутся с данными налоговой. Если вы настроите блокировку РТУ после печати чека, пользователи потеряют возможность исправлять случайные ошибки в документах отгрузки.

Резюме

Выбор оптимального пути зависит от масштаба вашего бизнеса и готовности нести риски:

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