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