Как найти и настроить автоматическую смену склада в Отчете о розничных продажах в 1С:Розница

← На главную

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

Механизм распределения продаж: почему меняется склад

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

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

Программа собирает все пробитые Чеки ККМ за смену.
При формировании Отчета о розничных продажах система обращается к регистру сведений РаспределениеПродаж.
Для каждой строки товара программа ищет правило: какой склад должен быть подставлен в зависимости от магазина, рабочего места и товарной группы.
Если правило найдено, склад в строке (или в шапке документа) заменяется на склад из настройки.

Изменение метаданных: свойство Проверка заполнения

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

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

Чтобы реализовать такую "универсальную" настройку (с пустой товарной группой), программисты прибегают к следующему изменению:

Открываем конфигуратор и находим объект РегистрСведений.РаспределениеПродаж.
Переходим на закладку Данные и выбираем измерение ТоварнаяГруппа.
В палитре свойств находим пункт Проверка заполнения и устанавливаем значение Не проверять.

Именно это изменение позволяет пользователю в режиме "1С:Предприятие" оставить поле "Товарная группа" пустым. Теперь система будет воспринимать эту запись как правило для всех товаров данного рабочего места.

Как настроить распределение продаж в интерфейсе

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

Перейдем в раздел Продажи — Настройки распределения продаж.
Создадим новую запись или отредактируем существующую.
Укажем Магазин и конкретное Рабочее место (кассу ККМ).
Поле Товарная группа оставим пустым (благодаря нашему изменению в конфигураторе программа не выдаст ошибку).
В поле Склад выберем тот торговый зал, с которого должны списываться продажи этой кассы.

Проанализируем приоритетность правил, по которой система выбирает склад:

Приоритет 1: Максимально точное совпадение (Магазин + Касса + Товарная группа).
Приоритет 2: Совпадение по магазину и группе (Магазин + Товарная группа), игнорируя кассу.
Приоритет 3: Универсальное правило (Магазин + Касса + Пустая товарная группа).

Где искать программный код подмены склада

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

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

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


Функция ПолучитьСкладРаспределения(Магазин, РабочееМесто, ТоварнаяГруппа) Экспорт
	Запрос = Новый Запрос;
	Запрос.Текст = 
		"ВЫБРАТЬ
		|	РаспределениеПродаж.Склад КАК Склад
		|ИЗ
		|	РегистрСведений.РаспределениеПродаж КАК РаспределениеПродаж
		|ГДЕ
		|	РаспределениеПродаж.Магазин = &Магазин
		|	И РаспределениеПродаж.РабочееМесто = &РабочееМесто
		|	И РаспределениеПродаж.ТоварнаяГруппа = &ТоварнаяГруппа";
	
	// Здесь логика подбора наиболее подходящего правила...
	Возврат РезультатЗапроса;
КонецФункции

В-третьих, если явных изменений в коде регистра нет, проанализируем Подписки на события. Посмотрите события ПередЗаписью или ПриЗаписи для документа ОтчетОРозничныхПродажах. Предыдущий специалист мог создать внешнюю обработку или подписку, которая "перехватывает" документ в момент создания и принудительно меняет склад, основываясь на своих алгоритмах.

Дополнительные проверки при диагностике

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

Проверим Журнал регистрации: Отфильтруем записи по конкретному документу ОРП. Посмотрим, не менялся ли склад спустя время после создания документа регламентным заданием или внешним пользователем.
Склады в карточке Кассы ККМ: У каждой кассы есть привязка к складу. Хотя распределение продаж имеет более высокий приоритет, иногда путаница возникает из-за неверно указанного основного склада в настройках оборудования.
Регистр "Настройка распределения выручки по секциям ФР": Не путайте его с распределением продаж. Этот регистр отвечает за то, на какой фискальный накопитель (если их несколько) уйдет сумма, а не с какого склада спишется товар в учете 1С.

Подведем итог: в большинстве случаев "загадочное" изменение склада в 1С:Розница 2.2 — это работа штатного механизма. Для его корректной настройки под нужды бизнеса часто требуется разрешить пустые значения в товарных группах регистра распределения через Конфигуратор, что и было успешно сделано в рассматриваемом случае.