При разработке отчетов на Системе компоновки данных (СКД), особенно для таких сложных конфигураций, как Управление торговлей 11.5, программисты часто сталкиваются с проблемой «размножения» данных. Суть проблемы заключается в том, что при добавлении в отчет детальных записей (например, поля Регистратор или ПериодСекунда), итоговые значения по остаткам (поля «Свободно», «Доступно», «К отгрузке») начинают многократно суммироваться, выдавая фантастические цифры вместо реальных складских остатков.
В этой статье мы подробно разберем, почему возникает этот эффект, и рассмотрим несколько проверенных способов решения задачи, от настройки ролей полей до изменения архитектуры запроса.
Для начала проанализируем ситуацию с точки зрения SQL-запроса, который СКД формирует «под капотом». Когда мы пытаемся объединить данные об остатках (которые хранятся в виртуальных таблицах остатков) и данные о движениях (из таблиц оборотов или регистраторов) в одном наборе данных, происходит левое соединение.
Представим ситуацию: на складе числится 10 единиц товара. За выбранный период по этому товару было сделано 5 различных документов (регистраторов). При выполнении запроса к каждой из 5 строк движений будет присоединено значение остатка «10». В результате в результирующей таблице СКД получит 5 строк, в каждой из которых в колонке «Остаток» будет стоять число 10. Если в ресурсах отчета для этого поля указана стандартная функция СУММА(Остаток), система честно сложит эти значения и покажет в группировке «Номенклатура» итог 50 вместо правильных 10.
Рассмотрим по шагам, как можно исправить это поведение.
Это самый правильный и «нативный» способ для СКД. Система компоновки данных обладает встроенным интеллектом для работы с остатками, но ей нужно подсказать, какие именно поля являются остаточными. Если мы правильно настроим роли, СКД перестанет использовать простое суммирование для итогов и будет вычислять их как значения на временную точку.
Выполним следующие действия:
Свободно и КОтгрузке).Конечный (или Начальный, в зависимости от смысла поля).ПериодСекунда или Регистратор), к которому привязан этот остаток.После этих настроек СКД поймет, что при детализации до регистратора значение остатка не нужно суммировать между собой внутри одной группировки более высокого уровня (например, по Номенклатуре). Система будет брать значение только из последней доступной записи периода.
Если запрос в отчете очень сложный, содержит много временных таблиц и объединений (как это часто бывает в типовых отчетах УТ 11.5), настройка ролей может не сработать корректно. В этом случае мы рекомендуем разделить получение данных на два независимых потока.
Проанализируем структуру такого решения:
Номенклатура, Характеристика и Склад. Здесь нет детализации до регистратора, поэтому данные будут точными.Затем перейдем на закладку «Связи наборов данных» и свяжем их по ключевым полям (Номенклатура, Склад). В этом случае СКД сначала вычислит агрегаты по первому набору, а детализацию из второго набора «подтянет» визуально. Математического умножения строк при этом не произойдет, так как ресурсы будут рассчитываться только на основании первого набора данных.
Иногда нам нужно, чтобы в детальных записях (в строках с документами) остаток вообще не отображался, чтобы не вводить пользователя в заблуждение, а в итогах по товару стояла верная цифра. Рассмотрим, как это настроить в ресурсах.
В окне редактирования ресурсов (закладка «Ресурсы») обратим внимание на колонку «Рассчитывать по...». По умолчанию там пусто, что означает расчет по всем доступным группировкам.
Мы можем явно указать список группировок, для которых будет выполняться расчет:
Свободно в список ресурсов.Сумма(Свободно).Склад, Номенклатура, Характеристика), но НЕ выбираем Детальные записи или Регистратор.В результате в строках с документами будет пустота (или ноль), а в итогах по товару отобразится корректная сумма. Однако стоит помнить, что этот метод лишь скрывает визуальное проявление ошибки, но не всегда исправляет общий итог по отчету, если не настроены роли полей.
Этот метод часто называют «костылем», но в простых отчетах он работает безотказно. Если вы понимаете, что остаток товара в рамках одной группировки (например, по конкретной номенклатуре на конкретном складе) всегда одинаков во всех строках регистраторов, можно заменить функцию суммы.
Вместо стандартного выражения ресурса:
Сумма(Свободно)
Используем выражение:
Максимум(Свободно)
Поскольку во всех строках одного товара значение остатка дублируется (например, везде стоит 10), функция Максимум выберет одно это значение, и сумма не «раздуется».
Важное предостережение: Будьте осторожны с этим методом при расчете общих итогов по складу. Максимум от всех товаров на складе даст вам остаток самого «крупного» товара, а не сумму всех товаров. Чтобы этого избежать, в поле «Рассчитывать по...» нужно комбинировать функции: для номенклатуры — Максимум, а для вышестоящих итогов — Сумма.
Рассмотрим пример сложного выражения из практики, когда нужно учитывать единицы измерения и избегать сложения разных величин. В системе может быть настроен параметр &КоличественныеИтогиПоЕдИзм. Выражение в ресурсах может выглядеть так:
ВЫБОР
КОГДА &КоличественныеИтогиПоЕдИзм И Количество(Различные ЕдиницаОтчета) > 1
ТОГДА 0
ИНАЧЕ Сумма(Свободно)
КОНЕЦ
Такой подход позволяет избежать математически неверного сложения «килограммов с штуками», что часто встречается в управленческом учете УТ 11.5.
Для исправления неверных итогов мы рекомендуем придерживаться следующего алгоритма:
ОстаткиИОбороты, убедитесь, что вы обращаетесь к полям КонечныйОстаток, а не пытаетесь суммировать поле Количество.Помните, что СКД — это мощный инструмент, который требует четкого определения ролей данных. Правильная типизация полей (остаток или оборот) — залог корректности ваших отчетов.