Новости

Специалисты компании BeringPro регулярно сталкиваются на проектах с ситуацией, когда у заказчика для раскрытия показателей в бюджетных формах используется больше шести аналитик. Но максимальное количество аналитик в группах раскрытия показателей отчетов 1С "Управление холдингом" — шесть. Возможностей типового решения в таком случае не хватает. В этой статье старший эксперт Роман Кайгородцев делится своим опытом расширения количества аналитик с минимальным объемом модификации типового функционала.

Постановка задачи 

Итак, представим проектную задачу: необходимо настроить вид отчета “Бюджет ЦФО”. Данный вид отчета имеет один показатель “БДР сумма” (строка отчета — БДР, колонка — Сумма). У данного показателя должны быть в группе раскрытия следующие аналитики: 

1. ЦФО (подразделение, ответственное за планирование и контроль данных доходов и расходов; по условиям задачи организационная единица, которая указывается в экземпляре отчетов, это группа ЦФО); 
2. МВЗ (подразделение, на чьи нужды планируются расходы); 
3. Юридическое лицо (организация Группы, по которой проходят доходы и расходы); 
4. Статья PL (статьи доходов и расходов); 
5. Статья ДДС (статьи движения денежных средств); 
6. Номенклатурная группа (группы услуг, которые оказывает компания клиентам); 
7. Проект (направление деятельности); 
8. Контрагент; 
9. Договор; 
10. Условия оплаты; 
11. Ставка НДС. 

Как мы видим, речь идет об 11 аналитиках. Но в типовом функционале мы можем настроить только шесть дополнительных аналитик у показателя:

Есть несколько распространенных способов обойти это ограничение без доработки конфигурации:

На форме вида отчета можно активировать флаг “Разделение по проектам”:

После этого при создании экземпляра отчета можно указать проект, которому соответствуют ВСЕ данные этого документа:

Очевидным минусом является то, что можно указать только один проект для всего документа. В нашем случае у записей показателя даже в одном экземпляре согласно требованиям заказчика могут быть разные значения аналитики “Проект”. 

Также важно сказать, что при указании аналитики на вкладке “Аналитики отчета” данная аналитика все равно занимает место в группе раскрытия показателя как обязательная!

2. Настройка раскрытия по валютам 

Еще одной возможностью увеличить количество аналитик является установка в группе раскрытия показателя флага “Использовать дополнительное раскрытие по валютам”:

В таком случае при вводе данных в экземпляр отчета по показателю можно будет указывать (или настроить заполнение) по дополнительной аналитике “Валюты” (справочник “Валюты”). 

В нашем случае все бюджетные данные заказчик вводит в одной валюте — “Руб.” — и валютное раскрытие не требуется. 

3. Использование реквизитов аналитики 

Пример: в справочнике “Договоры” есть реквизиты “Условие оплаты”, “Ставка НДС”, “Организация” и “Контрагент”. Если имеет место допущение, что во всех плановых данных будет заполнена аналитика “Договор” и в этих договорах обязательно будут заполнены все вышеперечисленные реквизиты, то в таком случае мы можем указать в группе раскрытия показателя только аналитику “Договоры”, а анализ данных в разрезе остальных вышеупомянутых аналитик проводить путем использования реквизитов договора. 

Такой способ является одним из самых распространенных. Но у него есть минусы: 

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

4. Добавление строк в структуру вида отчета 

Также одним из распространенных способов увеличить количество дополнительных аналитик показателя является следующий: значения аналитики, которой "не хватило места", указывают в виде строк отчета, соответственно, происходит увеличение количества показателей. К такому способу прибегают, когда значения аналитики редко корректируются заказчиком и малочисленны (классификаторы). 

Например, если у нас ограниченное и редко изменяемое количество статей PL, используемое в данном виде отчета, то на каждую статью можно создать отдельную строку отчета и, соответственно, отдельный показатель:

В таком случае мы можем не включать аналитику “Статья PL” в группу раскрытия показателей формы. У данного способа есть большой минус: при изменении состава значений аналитики придется корректировать структуру показателей отчета и источники данных показателей связанных форм. 

В нашем случае заказчик не ограничил список статей PL (могут быть все), которые можно вводить с помощью данного вида отчета. 

Таким образом, ни один из вышеперечисленных способов не подошел нам для выполнения поставленной задачи и потребовалось разработать свое решение по выходу из этой ситуации. ВАЖНО: заказчик выдвинул требования по более чем шести аналитикам только для показателей промежуточных видов отчетов (к ним относится “Бюджет ЦФО”). К специальным видам отчетов (например, Бюджет ФОТ и ВГО) и мастер-бюджетам (БДР и БДДС) таких требований нет, и количество аналитик в них не превышает шесть. 

Особенности реализации типового функционала 

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

1. Оказалось, что данные показателя записываются на тот регистр сведений, который соответствует количеству аналитик в группе раскрытия этого показателя. 

Речь идет про регистры сведений, начинающиеся с фразы “Значения показателей отчетов”:

Правила определения регистра сведений указаны в таблице ниже:

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

2. В случае создания многопериодного бланка можно настроить два варианта расположения полей с аналитиками: «Иерархия» и “Рядом”. 

Если указать расположение полей “Иерархия”, то значения всех аналитик будут сгруппированы по виду и указаны в одной колонке отчета:

Если указать расположение полей “Рядом”, то для значений каждой аналитики в отчете будет отдельная колонка:

ВАЖНО: только при расположении полей “Рядом” можно будет выводить отдельными колонками не только аналитики, но и реквизиты аналитик:

3. При настройке расположения полей в макете сводной таблицы нет возможности вывести в отдельные колонки реквизиты аналитик (только сами аналитики показателей):

После изучения особенностей типового решения было разработано проектное решение. 

Решение 

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

Вместо этого был добавлен новый справочник “Ключи аналитики”:

Ключ аналитики — сущность, в которой хранится уникальное сочетание значений всех требуемых для показателя бюджетных аналитик. Такого рода инструменты активно применяются в различных прикладных решениях фирмы 1С. Например, в 1С:Управление холдингом есть вот такой типовой справочник:

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

Внешний вид элемента нетипового справочника “Ключи аналитики”:

Далее был настроен вид корпоративной аналитики с типом значения, соответствующим новому справочнику:

Затем вместо шести аналитик в группу раскрытия показателя была добавлена только одна аналитика “Ключ аналитики”:

При настройке источников данных по данному показателю для сбора факта пришлось использовать способ получения “Произвольный запрос к текущей ИБ”, так как программа должна произвести сложный поиск подходящего ключа по сочетанию реквизитов:

Также была сделана доработка по созданию нового ключа в случае неудачного поиска подходящего при расчете значений показателей согласно источникам данных (общий модуль “АналитическийБланкУХСервер”) и при загрузке данных из Excel (общий модуль "ИмпортДанныхБланкУХ"). 

При настройке многопериодного бланка Бюджета ЦФО в расположении полей макета аналитик указали “Рядом”:

Благодаря этому удалось расположить в колонках не аналитики, а реквизиты аналитик:

В нашем примере в многопериодный бланк таким образом были добавлены колонки с реквизитами ключа “Договор” и “МВЗ”. 

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

При этом для ручного ввода данных в ячейку необходимо указать только ключ и значение показателя:

В таком случае после введения данных они сохраняются в регистре сведений “Значения показателей отчетов 1”. 

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

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

Что неинформативно и неприемлемо для заказчика. 

Поэтому пришлось доработать настройку расположения полей так, чтобы при расположении колонок “рядом” можно было указать реквизиты аналитик:

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

Выводы 

Благодаря нашему решению удалось достичь целей проектной задачи с минимальной модификацией прикладного решения: 

• Создан один справочник “Ключи аналитики”; 
• Доработан механизм сводной таблицы (для группировки по реквизитам аналитики); 
• Внесен один фрагмент кода в общий модуль “АналитическийБланкУХСервер”; 
• Внесен один фрагмент кода в общий модуль "ИмпортДанныхБланкУХ". 

На подготовку задания на доработки, реализацию и тестирование было потрачено 20 человеко-дней. 

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