Довольно часто перед программистами и аналитиками встает задача адаптации типовых конфигураций под специфические нужды финансового отдела. Рассмотрим типичную ситуацию: финансовому директору для удобного сведения управленческой отчетности в Excel требуется изменить иерархию в справочниках «Статьи ДДС», «Статьи затрат» и «Прочие доходы и расходы». Возникает идея отказаться от стандартной иерархии групп и элементов в пользу иерархии элементов. Давайте проанализируем эту ситуацию, разберем возможные риски для конфигурации 1С:Бухгалтерия 3.0 (БП 3.0) и посмотрим на безопасные пути решения.
На первый взгляд может показаться, что смена типа иерархии — это простая настройка, которая сделает дерево справочника более гибким. Пользователи на форумах иногда отмечают, что в старых версиях системы (например, БП 2.0) подобное изменение проходило без видимых катастроф для стандартных отчетов. Однако давайте разберем по шагам, что произойдет "под капотом" современной 1С:БП 3.0.
При переходе на иерархию элементов техническое понятие «группа» (или папка) полностью исчезает. Абсолютно все узлы справочника становятся равноправными элементами, просто одни из них подчинены другим. Выясним причину, почему это критично:
ЭтоГруппа, пользователь физически не может выбрать папку в документе (например, в авансовом отчете или банковской выписке), чтобы отнести на нее затраты. Система этого не позволит. Если мы установим иерархию элементов, любой родительский узел станет доступным для выбора в документах. Рядовые пользователи неизбежно начнут ошибочно "вешать" суммы напрямую на обобщающие родительские элементы.Рассмотрим подробнее влияние на поддержку конфигурации. В БП 3.0 в обсуждаемых справочниках программно заложено огромное количество алгоритмов и предопределенных элементов. Они необходимы для корректного автоматического списания НДС, учета курсовых разниц, формирования регламентированного Отчета о движении денежных средств и многого другого.
Изменение типа иерархии — это грубое вмешательство в структуру метаданных. Проанализируем, к чему это приведет при сопровождении базы:
Посмотрим на ситуацию со стороны обмена данными. Если у вас настроена синхронизация с другими конфигурациями (например, 1С:ЗУП, 1С:УТ или 1С:ERP), изменение иерархии неизбежно сломает типовые правила конвертации.
Типовые правила ожидают стандартную структуру. При попытке загрузить справочник из другой базы, система будет искать именно группу. Не найдя ее, обмен либо выдаст ошибку, либо начнет плодить дубли элементов в корне справочника.
Также могут возникнуть скрытые ошибки в программном коде. В типовых общих модулях БП 3.0 могут быть прописаны алгоритмы, опирающиеся на поиск именно групп. Например, разработчики часто используют следующий метод:
ИскомаяГруппа = Справочники.СтатьиЗатрат.НайтиПоНаименованию("Общехозяйственные расходы", Истина);
Если ИскомаяГруппа.Пустая() Тогда
// Обработка ошибки
КонецЕсли;
Второй параметр в методе НайтиПоНаименованию со значением Истина означает поиск именно среди групп. В справочнике с иерархией элементов такой поиск всегда будет возвращать пустую ссылку. Это приведет к непредсказуемым ошибкам при проведении документов или при выполнении ресурсоемких регламентных операций закрытия месяца.
Поскольку конечная цель задачи — удобство сведения данных в Excel для финансового директора, ломать архитектуру конфигурации совершенно не обязательно. Давайте рассмотрим альтернативные инструменты, которые позволят решить задачу безопасно и эффективно.
В 1С можно включить типовой механизм дополнительных реквизитов. Мы можем создать для нужных статей новое свойство, например, назовем его УправленческаяСтатья или ГруппаДляExcel. Финансовый директор сможет самостоятельно классифицировать и сгруппировать статьи так, как ему удобно, заполняя это свойство. Выводить эту группировку можно во всех стандартных отчетах, просто добавив дополнительный реквизит в настройки группировок.
Любой стандартный отчет (например, «Анализ субконто») мы можем настроить пользовательскими средствами так, чтобы иерархия выводилась не привычным ступенчатым «деревом», а отдельными плоскими колонками: «Уровень 1», «Уровень 2», «Элемент». Выгрузив такой отчет в Excel, руководитель получит идеальную плоскую таблицу (так называемую flat table), по которой очень легко строить сводные таблицы (Pivot) без пустых строк и лишних отступов.
Гораздо дешевле в разработке и безопаснее для системы написать один специализированный внешний отчет под конкретные форматы и требования финансового директора. Этот отчет будет собирать данные из типовой структуры и "на лету" трансформировать их, выгружая сразу в готовый файл нужного формата, совершенно не затрагивая структуру метаданных всей бухгалтерской базы.
Если проблема заключается в сопоставлении плановых укрупненных данных с детальным фактом, как отмечают специалисты на форумах, разумнее добавить в нужных родительских группах элементы с названиями «Прочие расходы...». Классификаторы плановых и фактических данных должны быть единообразными. Затраты относятся на эти выделенные элементы, сохраняя логику типовой конфигурации.
Подводя итог, проанализируем сделанные выводы: прямое изменение типа иерархии в таких системных справочниках как «Статьи затрат» или «Статьи ДДС» в современной 1С:Бухгалтерия 3.0 несет в себе критические риски для целостности данных, обновлений и обменов. Задачи по удобному отображению управленческих данных для выгрузки в Excel всегда следует решать на уровне построения отчетов, настройки дополнительных реквизитов СКД или создания внешних печатных форм, сохраняя типовую архитектуру базы данных нетронутой.