Добрый день!
Есть большой отчет на СКД.
Есть ответственный, кто его строит.
Смысл в том, что снабженцы хотят фиксировать построенный отчет раз в день, чтобы прикрыть свои филейные части.

Сделал Справочник с реквизитом (хранилище значений).
Табличный документ сохраняется/открывается. Но не работают никакие расшифровки.
Есть ли возможность сохранить в базе Отчет на СКД со всеми настройками, расшифровками и прочее.
Т.е. как будто его только что построили, а по факту развернули сохраненный.

подниму

(1) расшифровки работают через события, в mxl их конечно нет
в регламентированной отчетности для хранения расшифровок напилина туча кода


поэтому очевидный вариант - сделать на СКД отчет со всеми группировками, заменив тем самым, расшифровку и хранить его, а для просмотра сворачивать на пару уровней выше

может быть стоит сохранять в хранилище исходную таблицу значений, а в нужный момент - давать её СКД в качестве источника данных

+(3) у нас тоже такое применяется, только хранятся данные в регистре сведений. И со временем, когда данные становятся неактуальными, регзаданием оттуда удаляются уже ненужные строки, чтоб регистр не раздувался

Можно нарисовать свою форму для показа сохраненного отчёта. И в нём ловить и отрабатывать события.

(5) можно, что сделано в регламентированной отчетности, объём кодирования велик

(6) Тут уже или шашечки, или...
Если у бизнеса есть потребность и за неё готовы заплатить...

Вроде как процессор компоновки данных сериализируется.
После инициализации процессора компоновки данных можно выгрузить его в xml. В нем будет все.

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

(8) Так там же новые данные будут уже. А ТС, как я понял, нужны зафиксированные на конкретный момент

(9) возможное решение

(10) После инициализации процессора компоновки в нем уже и данные все есть.

+(9) Еще очень важное уточнение - расшифровка будет работать по _текущим данным базы_, т. е. вполне может не совпадать с выведенными данными отчета.

Если хочется по другому - то нужно сохранять не только сам отчет, но и все исходные данные, по которым он строится.

(13) если сохранять исходные данные, то зачем сохранять отчет? по исходным данным и строить отчет. И все расшифровки будут работать в стандартном режиме.

тут уже напрашиваются OLAP кубы

Расшифровка отчета это считай новый отчет только детализации больше и отборов больше, то есть данные расшифровки получаются в момент запроса расшифровки. поэтому никак это нельзя хранить .ты захлебнещся в данных.
я бы копнул в другую сторону.

большой это что?
отчет так тяжел аналитически, что долго формируется?
или отчет содержит оч большое количество данных?

объясню зачем спрашиваю. в первом случае вероятно имеет смысл подумать над тем чтобы определить новые метаданные для такого тяжелого отчета. тем самым сделать отчет быстрым по формированию данных и расшифровок.

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

спасибо за ответы
(16) отчет громоздкий. строится долго. но не в этом дело.
Смысл этого отчета - расчет потребности на момент времени.
После этого отчет отдается в отдел МТО и с ней работают снабженцы.
И они хотят себя подстраховать, чтобы недозакупить или наоборот. Цифры им должны даваться такие, что их никто не может менять после "сохранения".

(17) это всем понятно,вопрос в каком виде кэшировать данные в самом отчете или в приблуде

вариантов туча, можно и документ склепать с ТЧ и в них защёлкивать, как это сделано в бюджетировании ERP или УХ