Почему в 1С:УТ 10.3 в чеке всегда печатается количество 1 вместо реального количества товара?

← На главную

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

Разбор программной логики формирования чека

Для начала проанализируем, как система 1С:УТ 10.3 формирует данные для передачи на фискальный регистратор. Рассмотрим ситуацию с точки зрения кода, который отвечает за заполнение строк чека. Основная логика в типовых решениях часто скрыта в общих модулях или обработках торгового оборудования.

Проанализируем фрагмент кода из модуля обработки ТОСервер, который упоминается при печати чеков из кассовых ордеров:


Функция ПечатьЧекаПКОРКО(Идентификатор, ЭтоРКО, Пароль, НомерЧека, НомерСмены,
                        ОписаниеПлатежа, СуммаНал, СуммаБезнал)
// ...
Для Каждого Позиция Из ОписаниеПлатежа Цикл
    Результат = Обработка.ПечататьСтроку(Объект,
                                        Позиция.Заголовок,
                                        1, // Вот здесь жестко передается количество 1
                                        Позиция.Сумма,
                                        0,
                                        НомерОтдела,
                                        Позиция.НДС);
КонецЦикла;

Как мы видим, в процедуре ПечатьЧекаПКОРКО параметр количества жестко ограничен единицей. Однако это лишь следствие. Основная причина кроется в том, как формируется таблица ОписаниеПлатежа. Выясним, почему система решает передать оплату именно таким образом.

Влияние признака способа расчета (Аванс vs Предоплата)

Согласно формату фискальных данных (ФФД 1.05 и выше), существует жесткое разграничение понятий "Аванс" и "Предоплата". Рассмотрим, как это реализовано в общем модуле ДенежныеСредстваСервер:


Пока ВыборкаАвансов.Следующий() Цикл
    СтрокаПозицииЧека = МенеджерОборудованияКлиентСервер.ПараметрыФискальнойСтрокиЧека();
    СтрокаПозицииЧека.ПризнакСпособаРасчета  = Перечисления.ПризнакиСпособаРасчета.Аванс;
    СтрокаПозицииЧека.ПризнакПредметаРасчета = Перечисления.ПризнакиПредметаРасчета.ПлатежВыплата;
    
    СтрокаПозицииЧека.Наименование = НСтр("ru = 'Оплата от:'") + " " + ДанныеДокумента.ПринятоОт;
    
    СтрокаПозицииЧека.Количество   = 1;
    СтрокаПозицииЧека.Цена         = ВыборкаАвансов.СуммаПереплаты;
    СтрокаПозицииЧека.Сумма        = ВыборкаАвансов.СуммаПереплаты;
    // ...
    ПозицииЧека.Добавить(СтрокаПозицииЧека);
КонецЦикла;

Проанализируем этот фрагмент. Если система определяет платеж как Аванс, она автоматически устанавливает количество равным 1. Это логично с точки зрения законодательства: аванс вносится тогда, когда перечень товаров еще окончательно не определен. В этом случае в чеке нельзя указать конкретную номенклатуру и ее количество, так как деньги просто "падают" на баланс контрагента.

Если же мы хотим видеть в чеке "Кабель — 5 метров", способ расчета должен быть "Предоплата полная" или "Предоплата частичная". В этом случае 1С обязана передать в чек детализацию по товарам.

Причина №1: Настройка ведения взаиморасчетов

Выясним, почему ПКО "считает", что он принимает аванс, а не оплату за конкретный товар. В 1С:УТ 10.3 это напрямую зависит от настроек Договора с контрагентом. Рассмотрим варианты настройки поля Ведение взаиморасчетов:

По договору в целом: Это самая частая причина проблемы. При такой настройке система не видит связи между конкретным счетом и оплатой в момент пробития чека. Все поступления денег по такому договору считаются общим котлом. Программа просто фиксирует факт прихода денег и, не имея возможности однозначно сопоставить их с товарными позициями, печатает чек на "Аванс" с количеством 1.
По заказам / По счетам: При этой настройке каждый платеж должен быть привязан к конкретному документу-основанию. Если ПКО оформлен на основании Заказа, программа "понимает", за какие именно товары пришла оплата, и может развернуть их в чеке с правильным количеством.

Рекомендация: Проанализируйте настройки договора. Если вам нужна детализация в чеках, переведите взаиморасчеты в режим По заказам или По счетам.

Причина №2: Отсутствие документа расчетов в ПКО

Даже если договор настроен правильно, важно проверить заполнение самого документа Приходный кассовый ордер. Перейдем на закладку Расшифровка платежа. Там должна быть заполнена колонка Сделка или Документ расчетов.

Если это поле пустое или в нем указан не тот документ, по которому была отгрузка/заказ, система вновь классифицирует платеж как аванс. Особенно это актуально, когда используется общий контрагент "Частное лицо". Поскольку на одном контрагенте висит множество долгов и оплат, программа без четкого указания Сделки не может понять, к какой позиции товара относятся эти деньги.

Решение 3: Использование документа "Чек ККМ"

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

В отличие от ПКО, Чек ККМ имеет полноценную табличную часть Товары. При его пробитии данные в драйвер кассы передаются напрямую из списка товаров, что гарантирует правильное отображение количества и цены. Если ваша деятельность напоминает розничную торговлю, попробуйте использовать именно этот механизм.

Программное исправление (для разработчиков)

Если бизнес-процесс невозможно изменить и требуется печатать детальные чеки именно из ПКО, потребуется небольшая доработка системы. Нам нужно изменить алгоритм сбора данных для чека в модуле ДенежныеСредстваСервер или в процедурах печати ПКО.

Рассмотрим пример логики, которую можно внедрить:


// В процедуре подготовки данных для чека
Если ЗначениеЗаполнено(ДанныеДокумента.ДокументОснование) Тогда
    // Если основание - Счет или Заказ, пробуем достать товары оттуда
    Если ТипЗнч(ДанныеДокумента.ДокументОснование) = Тип("ДокументСсылка.ЗаказПокупателя") Тогда
        Для Каждого СтрокаТовара Из ДанныеДокумента.ДокументОснование.Товары Цикл
            НоваяСтрока = ПозицииЧека.Добавить();
            НоваяСтрока.Наименование = СтрокаТовара.Номенклатура.Наименование;
            НоваяСтрока.Количество   = СтрокаТовара.Количество;
            НоваяСтрока.Цена         = СтрокаТовара.Цена;
            НоваяСтрока.Сумма        = СтрокаТовара.Сумма;
            НоваяСтрока.ПризнакСпособаРасчета = Перечисления.ПризнакиСпособаРасчета.ПредоплатаПолная;
        КонецЦикла;
    КонецЕсли;
КонецЕсли;

Важно: При таком подходе необходимо быть очень осторожным. Если сумма ПКО меньше суммы документа-основания, вам придется программно рассчитывать пропорциональное распределение суммы оплаты по каждой строке товара, чтобы общая сумма чека совпала с суммой принятых наличных. Также помните, что согласно ФФД, если товар передается покупателю одновременно с оплатой, признак должен быть Полный расчет.

Итоги

Мы проанализировали ситуацию и выяснили, что количество 1 в чеке — это не ошибка драйвера или случайная настройка, а базовая логика системы при работе с авансовыми платежами. Чтобы исправить это без программирования:

Используйте в договорах ведение взаиморасчетов "По заказам".
Всегда заполняйте поле "Сделка" в расшифровке платежа ПКО.
Убедитесь, что сумма оплаты не превышает сумму долга по заказу, иначе остаток все равно уйдет на "Аванс" отдельной строкой с количеством 1.

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