ЕРП, замороченная отчётность внутри группы, но похоже на бюджетирование, да

А ты смотрел, как там сделаны настройки бюджетов? :)

Смотрел, не могу сказать что до конца разобрался, но нам много чего "особенного" надо, с блэк джеком, дамами и прочим. Решили не ломать и построить свой велосипед)

Я в смысле кода не все разобрал пока, что оно может рантайм представляем)

Там несколько уровне получения данных. На самом низшем, там детерминированный какой-то источник, ну т.е. однозначно вычисляемый и определяемый. Вам надо в эту сторону выруливать - т.е. если ты пошел в вывод в тз, это правильно, нужно как-то добиться, чтобы в пользовательских настройках СКД, не было вообще никаких итогов, а ты сам бы их детерминированно вычислял. Тогда бы у тебя забот не было.

Хм, пожалуй пойду опять открывать бюджетирование, сеньк, может что действительно подчеркну для себя

Ресурс Сумма можно и в ручную проверять перед формированием отчета. Если нет - программно добавлять.

А почему через таблицу значений криво?
Выводите детальные записи и по ним сумму.

С этим нет проблем, так и делаем перед проверкой что пора вываливаться в исключение. А программно его туда вкручивать нет смысла: нет в выводимых ресурсах значит возможно нет и в запросе, а значит скд не корректна

Юзеры хотят группировки по различным аналитикам

А как группировки протеворечат таблице значений?

Кроме того, что может быть немного медленно?

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

В этом случае у вас другие отчеты выступают источниками данных. Раз они источники, то берите из них сырые данные. И уже обрабатываете. Группировки в них не должны нести ценности для вас. Если там хитрая логика расчета показателей, придетя её все равно дублировать.

можно проверять по доступным полям выбора. Вот если и там нет - схема не прошла валидацию и выдавать исключение.

При формировании отчета можно очищать заданную пользователем структуру, и формировать только по детальным записям. Либо наоборот, только по самой верхней группировке.
Чтобы лишний раз не насиловать БД, можно сначала данные отчета в ТЗ по детальным записям, оттуда получить нужные данные, и по ТЗ построить схему компоновки на лету и передать туда пользовательские настройки.
Ну и самый крайний случай - програмно выводить отчет и ловить нужные цифры в нужно группировке.

обертка эта в итоге показывает все 10 отчетов пользователю или только собирает по ним данные?

И то и другое умеет

если не показывать, то можно забить на пользовательские группировки (если собираемые данные от них не зависят), и рассматривать как источники с детализаций, как тут и предложили: https://t.me/ssl1c/50050

Да, всё перечитал, переосмысливаю, спасибо. Видимо архитектуру рихтанем

Можно еще упростить себе задачу: сначала требуемые данные в буферный регистр консолидировать а с него уже строить нужный отчет. Вряд ли вам нужна именно "оперативная" отчетность с точностью до часа. Скорее всего, суточная оперативность подойдет. Регистр можешь спроектировать под твой супер-мега отчет, чтобы элементарной схемой получать с него данные. Скорее всего, такое решение будет проще в обслуживании/разборе косяков, чем налету дергать 100500 компоновок, их анализировать, на основе анализа делать еще одну мега-хрень.

Не, за участие поклон конечно но так точно не. Там важна фрагментация отчётов. Т.е. их действительно смотрят и по отдельности и расшифровывают и т.д. И самое главное требования к отчётности не часто но меняются, т.е. часть из 100500 отчётов завтра могут изменить источники данных или применяемые отборы или вовсе кануть в лету

А итоговый отчет содержит какие-то группировки или там просто плоская таблица?

Там все плоское