Почему в отчет о розничных продажах в УТ 11 попадают чеки только с одним видом цен?

При работе с конфигурацией 1С:Управление торговлей 11 (а также КА 2 и ERP) многие специалисты сталкиваются с ситуацией, когда при закрытии кассовой смены не все чеки ККМ попадают в итоговый документ Отчет о розничных продажах (ООРП). Особенно часто это происходит, если в течение смены по каким-то причинам в чеках фигурировали разные виды цен. В результате документ формируется не полностью, выручка "теряется", а складские остатки не списываются корректно.

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

Архитектура документа и методология учета

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

Реквизит ВидЦены находится в шапке документа. Это фундаментальное архитектурное решение разработчиков типовой конфигурации. Оно означает, что весь перечень товаров, указанный в табличной части Товары, продан по одному конкретному типу цен (например, "Розничная" или "Цена магазина №1").

Логика работы системы следующая:

1. В настройках Склада (или формата магазина) задается Розничный вид цены. Это "нормативная" цена для данной торговой точки.
2. При оформлении чеков на кассе ККМ система ожидает, что продажа идет именно по этому виду цен.
3. При закрытии смены обработка заполнения ООРП смотрит на настройку склада, берет оттуда основной вид цены и устанавливает его в шапку создаваемого отчета.

Соответственно, если в выборке чеков за смену встречаются документы с другим видом цены, система их намеренно игнорирует. Это не ошибка в коде (баг), а защита целостности данных (фича). Типовой механизм не умеет "смешивать" разные колонки прайс-листа в одном документе продажи, так как это нарушило бы логику ценообразования и анализа маржинальности в разрезе видов цен.

Технический анализ заполнения отчета

Давайте посмотрим, как это выглядит с точки зрения программиста. Автор темы на форуме верно заметил, воспользовавшись отладчиком, что алгоритм заполнения жестко фильтрует данные.

При нажатии кнопки "Закрыть смену" или запуске регламентного задания, система выполняет запрос к документам ЧекККМ. В этом запросе или при последующей обработке выборки происходит отбор. Упрощенно логику можно представить следующим псевдокодом:

// Получаем настройки склада
НормативныйВидЦены = Склад.РозничныйВидЦены;

// Создаем новый Отчет о розничных продажах
ООРП = Документы.ОтчетОРозничныхПродажах.СоздатьДокумент();
ООРП.ВидЦены = НормативныйВидЦены;

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

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

Откуда берутся "чужие" виды цен в чеках?

Возникает закономерный вопрос: если методология запрещает разные цены, как они вообще появляются в базе? В стандартном Рабочем месте кассира (РМК) 1С оперативно сменить вид цены крайне сложно или невозможно. Обычно "аномальные" чеки появляются по трем причинам:

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

Варианты решения проблемы

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

Решение 1: Методическое (Использование скидок)

Это самый правильный путь. В идеологии 1С цена — это база, а любые отклонения (акции, скидки для своих, уценка) должны оформляться через механизм скидок/наценок.

В этом случае:

• Во всех чеках остается единый ВидЦены (Розничная).
• Итоговая сумма уменьшается за счет автоматической или ручной скидки.
• Все чеки без проблем попадают в один Отчет о розничных продажах.

Если проблема возникает при обмене с внешним ПО, необходимо настроить правила конвертации так, чтобы разница в цене садилась именно как скидка, а не как подмена вида цены.

Решение 2: Программная доработка (Разбиение ООРП)

Если бизнес-процесс требует именно разных видов цен (например, жесткое разделение на "Розница" и "Мелкий опт" через одну кассу), вам придется дорабатывать процедуру закрытия смены.

Стандартный механизм не справится, поэтому потребуется создать Расширение конфигурации. Алгоритм действий программиста будет следующим:

1. Перехватить процедуру закрытия смены.
2. Сгруппировать все неархивные чеки за смену по полю ВидЦены.
3. В цикле по каждому уникальному виду цены создавать отдельный документ Отчет о розничных продажах.

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

Решение 3: Исправление "на лету" (Для разовых случаев)

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

1. Откройте список чеков ККМ за проблемную смену.
2. Найдите чеки с "неправильным" видом цены.
3. С помощью обработки Изменение выделенных элементов установите в них правильный (основной) вид цены. Внимание: это может изменить суммы документов, если цены отличаются!
4. Если суммы должны остаться прежними, придется вручную корректировать табличную часть, добавляя ручную скидку, чтобы подогнать сумму под факт.
5. После исправления чеков перезапустите процедуру закрытия смены или перезаполните ООРП.

Заключение

Проблема с попаданием чеков в отчет о розничных продажах в УТ 11 вызвана строгой архитектурой: один склад = один вид цены. Игнорирование чеков с другими ценами — это защитный механизм системы.

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