Почему в регистре партий нет организации, а в продажах нет склада в 1С:Управление торговлей и как построить отчет?

Программист 1С v8.3 (Обычные формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

При разработке аналитических отчетов по себестоимости, выручке и рентабельности в конфигурациях линейки 1С:Управление торговлей (редакции 10.3 / 2.3) разработчики часто сталкиваются с архитектурной особенностью: в регистре накопления ПартииТоваровНаСкладах присутствует измерение Склад, но отсутствует Организация, а в оборотном регистре Продажи есть Организация, но нет Склад. Выясним причину такого разделения и разберем практические способы построения отчетов с нужной аналитикой.

Архитектурная логика типовой конфигурации

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

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

Способ 1. Получение склада через регистратор или документ продажи в запросе

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


ВЫБРАТЬ
    ПродажиОбороты.Организация КАК Организация,
    ВЫБОР
        КОГДА ПродажиОбороты.ДокументПродажи ССЫЛКА Документ.РеализацияТоваровУслуг
            ТОГДА ВЫРАЗИТЬ(ПродажиОбороты.ДокументПродажи КАК Документ.РеализацияТоваровУслуг).Склад
        КОГДА ПродажиОбороты.ДокументПродажи ССЫЛКА Документ.ОтчетОРозничныхПродажах
            ТОГДА ВЫРАЗИТЬ(ПродажиОбороты.ДокументПродажи КАК Документ.ОтчетОРозничныхПродажах).Склад
        ИНАЧЕ НЕОПРЕДЕЛЕНО
    КОНЕЦ КАК Склад,
    ПродажиОбороты.Номенклатура КАК Номенклатура,
    ПродажиОбороты.КоличествоОборот КАК Количество,
    ПродажиОбороты.СтоимостьОборот КАК Выручка,
    ПродажиСебестоимостьОбороты.СтоимостьОборот КАК Себестоимость,
    ПродажиОбороты.СтоимостьОборот - ПродажиСебестоимостьОбороты.СтоимостьОборот КАК ВаловаяПрибыль
ИЗ
    РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, Авто, ) КАК ПродажиОбороты
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ПродажиСебестоимость.Обороты(&НачалоПериода, &КонецПериода, Авто, ) КАК ПродажиСебестоимостьОбороты
        ПО ПродажиОбороты.Организация = ПродажиСебестоимостьОбороты.Организация
            И ПродажиОбороты.Номенклатура = ПродажиСебестоимостьОбороты.Номенклатура
            И ПродажиОбороты.ХарактеристикаНоменклатуры = ПродажиСебестоимостьОбороты.ХарактеристикаНоменклатуры
            И ПродажиОбороты.ДокументПродажи = ПродажиСебестоимостьОбороты.ДокументПродажи

Рассмотрим важный нюанс: если в параметрах учета включена возможность указания склада в табличной части документов реализации (многоскладские накладные), извлечения склада из шапки документа недостаточно. В таком случае выполним соединение с табличной частью документа продажи по полям Номенклатура и ХарактеристикаНоменклатуры.

Способ 2. Использование структуры подразделений предприятия

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

  1. Создадим для каждой торговой точки отдельный элемент в справочнике Подразделения (например, «Магазин №1», «Магазин №2»).
  2. В документах реализации и розничных продаж укажем соответствующее подразделение.
  3. В регистре Продажи измерение Подразделение присутствует изначально, что позволяет получать любые отчеты по точкам продаж штатными средствами без сложных соединений в запросах.
  4. Использование подразделений также дает возможность настраивать права доступа на уровне записей (RLS) и распределенные информационные базы (РИБ) по магазинам.

Способ 3. Использование регистров регламентированного учета и розницы

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

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

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

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

  1. Сложность механизма списания. Потребуется полностью переписать алгоритмы проведения документов в общем модуле партионного учета. Без сложного механизма автоматических межфирменных продаж («Интеркампани») проведение документов реализации начнет блокироваться ошибками нехватки остатков по партиям конкретной организации.
  2. Необходимость полного перепроведения. Добавление новых измерений сделает невалидными исторические движения. Потребуется полное перепроведение всех документов движения товаров за все закрытые периоды.
  3. Снижение производительности. Увеличение количества измерений в оборотных регистрах увеличивает объем таблиц итогов СУБД и повышает риск блокировок при одновременной работе пользователей.
← На главную