Каталог решений - Пример разработки регламентированного отчета

Отчет проектируем в расширении (в нашем случае префикс — реготч).

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

Создаем в расширении новый отчет РегламентированныйОтчет_реготч_КлассификацияОбязательств. Начинаться наименование источника должно так. Теперь его можно зарегистрировать в базе данных через команду обновления рег. отчетов.

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

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

Скажем, что в нашем случае в итоге код формы редакции отчета сократился примерно (в тысячах строк) с 14 до 3, модуля объекта — с 4 до менее 1 (был взят такой немаленький отчет).

В контексте нашего примера типичная структура отчета состоит из:

— Основная форма отчета — то служебное окошко, в котором при создании отчета выбирается организация, период и соответствующая редакция отчета.

— Форма редакции отчета. Здесь происходит заполнение отчета. На форме расположен табличный документ, куда выводятся данные отчета.

— Макет(ы) редакции отчета. Табличные документы с именованными ячейками.

— Экземпляр документа Регламентированный отчет, где хранятся данные отчета.

Кроме того, отчет может иметь различные служебные формы и макеты.

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

Добавим в метод ТаблицаФормОтчета модуля менеджера отчета его редакции, и также добавим их в метод ДеревоФормИФорматов.

Настроим основную форму отчета (например, периодичность).

Пусть наш отчет будет отображать информацию о дебиторской и кредиторской задолженности контрагентов, и пусть отчет состоит из трех разделов: титульного, первой таблицы и второй таблицы. Первая таблица будет с заданным количеством колонок и строк, вторая — с заданным количеством колонок, но произвольным числом строк. Зададим имена ячеек и тип их значения там, где это необходимо. У второй таблицы имена ячеек таблицы будут сформированы программно.

Где-то в закромах формы мы заместили типовой код по формированию структуры разделов.

На форме редакции отчета данные отчета будут храниться в реквизите СтруктураДанных. Формат структуры претерпевал некоторые изменения по мере разработки и окончательный вид принял после реализации выгрузки, повторяя структуру пакета XDTO.

Для хранения показателей первой таблицы мы используем структуру ЯчейкаОтчета, а для хранения второй таблицы — массив СтрокаОтчета.

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

При выводе раздела в табличный документ происходит обратный процесс — значения структуры данных помещаются в области ячеек табличного документа.

Табличный документ второй таблицы, в силу того, что количество строк неизвестно, конструируется динамически.

Условно взаимодействие структуры данных можно представить следующим образом.

Для заполнения отчета создадим обычный отчет на СКД реготч_КлассификацияОбязательств. Текст запроса отчета будем использовать для заполнения отчета в модуле менеджера.

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

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

Поскольку состав строк второй таблицы не фиксирован, добавлена возможность добавления / удаления строк.

Логично, что раз отчет формируется на основании другого отчета, то второй используется для расшифровки первого. Для открытия отчета с заданными параметрами, отбором и проч. созданы 2 общих модуля: реготч_ОтчетыСервер и реготч_ОтчетыКлиентСервер.

Для выгрузки и загрузки отчета был создан пакет XDTO с нехитрой структурой. Стоит заметить, что процедуры выгрузки и загрузки отчета в нашем случае интегрированы с механизмом рег. отчетности, так что мы просто заместили код оригинального отчета своим. Впрочем, не обошлось без модификации формы справочника ЭлектронныеПредставленияРегламентированныхОтчетов.

Пример отчета был реализован, как сказано, копированием компонентов типового отчета с их последующей модификацией — в том числе чтобы не переносить с нуля элементы инфраструктуры взаимодействия с блоком рег. отчетности. Он содержит три раздела с двумя таблицами, может быть сохранен в список рег. отчетов, выгружен / загружен (в своем формате xml), распечатан, а также у него может быть изменен статус. При редактировании зависимых ячеек выполняется расчет итогов. В настройках отчета может быть выбрана единица измерения.

Протестировано на конфигурации Бухгалтерия предприятия, редакция 3.0 (3.0.158.23).