Конструирование отчетов в 1С, где каждая ячейка рассчитывается отдельно. Примеры в 1С:ERP, 1С:УХ, СКД

Сегодня любому понятно, для чего нужен отчет. Огромные потоки информации кого хочешь собьют с толку, запутают и разнесут в клочья. Поэтому любую информацию человек пытается разложить по небольшим полочкам, клеточкам, квадратикам. А потом собрать из этих полочек – клеточек какую-нибудь картинку, которая ему объяснит, что же все-таки в этом мире происходит.

В этом подходе нет ничего нового, например, еще с прошлого века, чтобы положить “информационного слона” в холодильник, то есть в компьютер, его разбивают на множество нулей и единиц. Но человеку от этого не легче воспринимать информацию, слишком сильное дробление, так же, как и не дробление вообще, обстановку не проясняют. Поэтому после разбития информации ее начинают агрегировать, и на уровне таблиц баз данных человек уже вполне может воспринимать и анализировать оцифрованную информацию. Другое дело, что таблицы базы данных – это пока промежуточный вариант агрегации удобный скорее компьютеру, чем человеку.

На платформе 1С разработано много более предметно-ориентированных сущностей для хранения информации:

Но это агрегация системная и разобраться в ней, не зная языка запросов, простому пользователю, как правило, сложно. Да и с помощью языка запросов легко получить отчет, в котором все строки и все значения в строке по идентичным алгоритмам, например, берутся как строки и колонки физической таблицы с конкретными отборами. Если же каждая ячейка отчета вычисляется по своей формуле, то простым запросом к физической таблице или предметно-ориентированной сущности обойтись не удастся.

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

Есть, конечно, классические отчеты, к которым все пользователи данной предметной области привыкли: Семейство оборотно-сальдовой ведомости, Анализ счета, Анализ субконто для бухгалтера, Ведомость по товарам на складах для кладовщика, Платежный календарь для финансиста. Классические отчеты хороши тем, что дают достаточно информации, чтобы разбирать текущие ситуации, но не позволяют автоматизировать специфические расчеты в разрезе пользовательской аналитики. Еще достоинство классических отчетов – они стандартизируют мышление. И если пользователям нужна какая-то специфическая отчетность по международным стандартам или по статьям бюджета, то они, как правило, могут разложить свою потребность в терминах классических отчетов.

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

Настройка получения данных осуществляется при помощи обработки «Настройка правил получения фактических данных бюджетирования». Настройка может производиться в двух режимах:

Выбор сущности, выводимой в отчет, в данном случае влияет на вид остатка при формировании запроса.

Здесь можно видеть, к каким регистрам можно делать запрос при получении фактических данных:

Регламентированный учет – это ОСВ, регистр бухгалтерии Хозрасчетный. Обязательным элементом отбора в данном случае будет являться Счет, а дополнительными возможными – субконто этого счета и реквизиты регистра.

Международный учет – это ОСВ по МСФО, регистр бухгалтерии МСФО. Обязательным элементом отбора здесь также будет счет, а дополнительными – его субконто и реквизиты регистра.

Оперативный учет (хозяйственные операции) – информация отбирается в разрезе предопределенных сущностей ERP: хозяйственных операций и отборов по аналитикам этих сущностей.

Оперативный учет (статьи активов и пассивов) – информация отбирается в разрезе статей активов и пассивов отчета управленческий баланс и их аналитик.

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

Аналогичный механизм есть и в «1С:Управление холдингом», он унаследован из консолидации. Отчеты с ячейками, вычисляемыми по индивидуальным формулам, в УХ называются произвольными отчетами, а сами вычисляемые ячейки – показателями. Механизм получения показателей в УХ исторически значительно более развит, чем в ERP, и по предоставляемым возможностям настройки его можно сравнить с языком запросов.

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

Регистры сведений, имеющие ресурсы

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

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

Для источников данных настраиваются также соответствия аналитик вычисляемого показателя и аналитик источника для автоматического заполнения значений показателя в разрезе аналитики.

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

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

Запрос будет состоять из следующих частей:

1. Получение первичных данных из базы: остатков по регистрам, аналитики показателей и т.д. Эти данные лучше получать все вместе. Для этого нужно провести анализ всех формул вычисления ячеек отчета и составить общие критерии для отборов по регистрам и необходимым аналитикам.

2. Формирование временных таблиц для показателей отчета. Лучше каждый показатель складывать в свою временную таблицу, особенно если структура отчета недостаточно хорошо описана. Так будет легче добавлять новые условия отборов и просто ориентироваться в правилах вычисления показателей. Когда структура отчета устоится, можно будет оптимизировать получение некоторых данных для ускорения отчета.

3. Сборка отчета из временных таблиц показателей. Обычно сборка происходит при помощи конструкции «Объединить» или «Объединить все». Запрос лучше читается, когда в нем объединяется не больше 5-6 показателей одновременно. Так что лучше не торопиться, и объединение проводить по частям.

4. Формирование структуры строк и колонок отчета. Если есть возможность добавить в конфигурацию справочник или регистр сведений, то структуру отчета лучше хранить в базе с возможностью отдельного редактирования в пользовательском режиме. Но если мы хотим, чтобы конфигурация оставалась на поддержке, но такой возможности нет, то структуру отчета можно сформировать одной временной таблицей, в которой просто перечислить все строки и колонки отчета через конструкцию «Объединить». Можно также определить порядок следования строки колонок через дополнительное поле «Сортировка».

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