Как правильно настроить получение данных по периодам в СКД и избежать лишней детализации?

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

Причина избыточной детализации: коварный параметр «Авто»

Проанализируем ситуацию, описанную автором темы. При использовании виртуальной таблицы ОстаткиИОбороты регистра накопления ПартииТоваровНаСкладах, в параметрах таблицы часто оставляют значение периодичности по умолчанию — «Авто». Рассмотрим подробнее, как это работает в механизмах 1С.

Когда в СКД выбран параметр «Авто», система сама решает, какую минимальную периодичность использовать, исходя из полей, которые вы задействовали в настройках компоновки. Если вы случайно добавили в выбранные поля, группировки или даже в сортировку поле Регистратор или ПериодСекунда, СКД автоматически «развернет» виртуальную таблицу до уровня отдельных записей. В итоге вместо одной строки за месяц вы получите десятки строк по каждой накладной.

Решение проблемы: Чтобы жестко ограничить выборку, в тексте запроса в параметрах виртуальной таблицы необходимо явно указать нужную периодичность. Вместо пустого значения или «Авто», укажем Месяц:

ВЫБРАТЬ
    ПартииТоваровНаСкладахОстаткиИОбороты.Номенклатура,
    ПартииТоваровНаСкладахОстаткиИОбороты.КоличествоНачальныйОстаток,
    ПартииТоваровНаСкладахОстаткиИОбороты.КоличествоКонечныйОстаток,
    ПартииТоваровНаСкладахОстаткиИОбороты.КоличествоОборот,
    ПартииТоваровНаСкладахОстаткиИОбороты.ПериодМесяц
ИЗ
    РегистрНакопления.ПартииТоваровНаСкладах.ОстаткиИОбороты(&НачалоПериода, &КонецПериода, Месяц, , ) КАК ПартииТоваровНаСкладахОстаткиИОбороты

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

Проблема «пустых» месяцев: как сохранить остатки при отсутствии оборотов

Второй вопрос автора касается классического поведения виртуальных таблиц: если за конкретный месяц не было ни одного прихода или расхода (Оборот = 0), то виртуальная таблица ОстаткиИОбороты просто не вернет строку за этот месяц. Однако остаток-то на складе есть! Разберем по шагам, как решить эту задачу с помощью штатных средств СКД без написания сложных запросов с объединениями.

Для этого нам понадобится механизм дополнения периодов. Выполним следующие действия в конструкторе схемы компоновки данных:

1. Перейдем на вкладку «Настройки».
2. Выберем группировку, отвечающую за период (например, по полю ПериодМесяц).
3. В нижней части настроек найдем вкладку «Иерархия и другие настройки» или свойства группировки.
4. Установим параметр «Тип дополнения» в значение Месяц.
5. Укажем «Начало дополнения» и «Конец дополнения» (обычно это параметры отчета &НачалоПериода и &КонецПериода).

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

Настройка ролей полей для корректных итогов

Выясним причину еще одной частой ошибки: когда при суммировании по периодам итоги по остаткам считаются неверно (просто складываются). Чтобы этого не происходило, необходимо правильно настроить Роли полей на вкладке «Набор данных»:

• Для поля КоличествоНачальныйОстаток в колонке «Роль» нужно указать тип НачальныйОстаток и обязательно связать его с полем периода.
• Для поля КоличествоКонечныйОстаток указываем тип КонечныйОстаток.
• Для поля периода (например, ПериодМесяц) указываем роль Период и порядковый номер (например, 1).

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

Оптимизация: когда не стоит использовать «Партии товаров»

Посмотрим на ситуацию с точки зрения производительности. В УТ 10.3 регистр ПартииТоваровНаСкладах является одним из самых тяжелых. Если ваша задача — получить только количество проданного товара и остатки без учета себестоимости и конкретных документов закупки, мы рекомендуем использовать другие регистры:

• ТоварыНаСкладах — для получения оперативных остатков и оборотов в количественном выражении (работает значительно быстрее).
• Продажи — для анализа оборотов реализации.

Обращение к «Партиям» оправдано только тогда, когда вам критически важно видеть данные в разрезе поставщиков или документов поступления.

Важное замечание по использованию ПРЕДСТАВЛЕНИЯ

В тексте запроса автора встречается конструкция ПРЕДСТАВЛЕНИЕ(Номенклатура). Рассмотрим, почему в СКД этого лучше избегать. Система компоновки данных умеет самостоятельно получать представления для любых ссылочных полей. Если вы принудительно преобразуете номенклатуру в строку через функцию ПРЕДСТАВЛЕНИЕ() прямо в запросе, вы потеряете возможность:

1. Переходить из отчета в карточку номенклатуры (расшифровка).
2. Обращаться к свойствам объекта (например, Номенклатура.Артикул) в настройках отчета.
3. Использовать стандартные механизмы оформления 1С.

Совет: Просто выбирайте поле Номенклатура как ссылку, а СКД сама отобразит его наименование там, где это нужно.

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