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