Почему в 1С:Розница (РИБ по рабочему месту) не формируется отчет по продажам в течение дня?

← На главную

Многие пользователи и администраторы конфигурации 1С:Розница сталкиваются с неочевидным поведением системы при использовании распределенной информационной базы (РИБ). Разберем классическую ситуацию: в магазине настроен узел РИБ по рабочему месту. Кассиры в течение дня успешно пробивают документы ЧекККМ, они появляются в центральной базе магазина, но если попытаться сформировать стандартный отчет по продажам (например, «Анализ продаж» или «Оценка валовой прибыли»), он будет абсолютно пустым. При этом после того, как кассир закрывает смену, формируется ОтчетОРозничныхПродажах, и все данные чудесным образом появляются в отчетах.

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

Архитектурная причина: как работает РИБ по рабочему месту

Чтобы понять, почему стандартные отчеты не показывают данные внутри дня, посмотрим на устройство самого плана обмена. План обмена «РИБ по рабочему месту» (в отличие от полноценного «РИБ по магазину») изначально спроектирован разработчиками фирмы 1С как максимально облегченный, так называемый «кассовый» узел.

Главная цель такого узла — обеспечить быструю, автономную работу рабочего места кассира (РМК), чтобы никакие проблемы с локальной сетью, интернетом или загрузкой центрального сервера не мешали пробивать чеки покупателям. Для оптимизации скорости и минимизации объема передаваемых данных из состава этого плана обмена принудительно исключены все «тяжелые» учетные регистры. Самое важное для нас — в этот обмен не входит регистр накопления Продажи.

Разберем по шагам, что происходит в базе:

В течение дня касса пробивает документы ЧекККМ.
При синхронизации (обмене) сами эти документы передаются в центральную базу магазина. Вы видите их в журнале.
Однако из-за ограничений плана обмена движения этих документов по регистру Продажи отсекаются (в центральной базе они не создаются).
Все типовые отчеты по выручке строятся исключительно на основе данных регистра Продажи, который пока пуст. Именно поэтому отчет формируется пустым.
Когда смена закрывается, статусы документов меняются (они становятся архивными и окончательно обнуляют свои движения даже на кассовом узле).
Система автоматически генерирует сводный документ ОтчетОРозничныхПродажах. Этот сводный документ уже проводит итоговые движения в регистр Продажи, и только после этого суммы продаж становятся доступны для типовых отчетов.

Решение 1: Использование внешнего отчета по чекам

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

Рассмотрим, как можно написать простой запрос для внешнего отчета, который будет собирать данные по пробитым чекам. Мы будем обращаться к табличной части Товары документа ЧекККМ и фильтровать только те документы, которые имеют статус открытой смены.


ВЫБРАТЬ
    ЧекККМТовары.Номенклатура КАК Товар,
    СУММА(ЧекККМТовары.Количество) КАК Количество,
    СУММА(ЧекККМТовары.Сумма) КАК СуммаПродажи
ИЗ
    Документ.ЧекККМ.Товары КАК ЧекККМТовары
ГДЕ
    ЧекККМТовары.Ссылка.Дата МЕЖДУ &НачалоПериода И &КонецПериода
    И ЧекККМТовары.Ссылка.СтатусЧекаККМ = ЗНАЧЕНИЕ(Перечисление.СтатусыЧековККМ.Пробитый)
СГРУППИРОВАТЬ ПО
    ЧекККМТовары.Номенклатура
УПОРЯДОЧИТЬ ПО
    СуммаПродажи УБЫВ

Такой внешний отчет (добавленный через раздел «Дополнительные отчеты и обработки») позволит вам суммировать информацию в реальном времени сразу после завершения сеанса обмена с кассовым узлом.

Решение 2: Просмотр итогов в журнале документов

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

Зайдем в раздел программы, где располагаются розничные продажи, и откроем список документов ЧекиККМ. Настроим список так, чтобы видеть только нужные чеки:

Установим отбор по дате (за текущий день).
Установим отбор по статусу документа (только «Пробитые»).
Выделим все документы в списке (сочетание клавиш Ctrl+A).
Обратим внимание на нижнюю часть окна платформы — система автоматически покажет количество выделенных документов и общую сумму по ним (если в списке выведена колонка с суммой документа).

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

Решение 3: Изменение архитектуры кассовых узлов

Если контроль выручки и остатков в течение дня критически важен, а сеть между компьютерами работает стабильно, лучшим выходом будет отказ от использования плана обмена «РИБ по рабочему месту».

Рассмотрим альтернативную схему работы:

Создаем единую базу магазина (с использованием обмена «РИБ по магазину» с центральным офисом, если это сеть).
Рабочие места кассиров (РМК) больше не являются отдельными базами.
Кассы подключаются к базе магазина напрямую по локальной сети с помощью Тонкого клиента 1С или через терминальный доступ (RDP).

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

Дополнительный нюанс: Контроль остатков при РИБ по рабочему месту

Обсуждая РИБ по рабочему месту, нельзя не упомянуть еще одну важную рекомендацию разработчиков платформы. При использовании этой схемы обмена фирма 1С рекомендует отключать жесткий контроль остатков при пробитии чека на кассе.

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