С «1С:Управление холдингом» (далее «УХ») довелось поработать на двух проектах (оба в Казани): Консолидация отчетности в холдинге «Ак Барс» (на редакции 1С:УХ 1.0) и «Централизованное казначейство» в группе «КамГэс» (на редакции 1С:УХ 1.1). В целом, от работы с системой смешанные чувства: из положительного: есть некоторые действительно нужные элементы:

• Портал сверки ВГО,
• Автоматические консолидационные корректировки,
• Двухуровневая система лимитирования: «БДДС – Договор – Заявка», универсальная схема Заявок на операцию, включающая операции БДДС, БДР, Бюджета ресурсов,
• Более понятное (по сравнению с 1С:Консолидацией) бюджетирование / лимитирование с использованием нормального регистра накопления «БДДС» (регистры «Значения показателей» используются, но не для целей бюджетирования) и др,

но во многих элементах чувствуется методическая сыроватость и недоработанность. Наиболее наглядно для меня это проявилось в подсистеме казначейства. Сразу стоит отметить, что проект по казначейству выполняли на редакции УХ 1.1.3, и закончили проект в ноябре 2015, а в начале декабря вышел первый релиз редакции УХ 1.2, в котором казначейство фирма «1С» значительно доработала:

• Полностью меняется Сводная таблица (обработка экземпляров отчетов),
• Значительно дорабатывается Платежный календарь,
• Добавлен документ «Реестр платежей» (правда, в «зачаточном» виде)
• Добавляется функционал разделения на обязательную и дополнительную аналитику,
• Добавляется функционал связанных договоров,
• Добавляется функционал запрета формирования платежных документов (ВЕТО).

Практически все указанные новые элементы релиза 1.2 пришлось реализовывать самостоятельно в ходе проекта «КамГэс», при этом в ходе обоих проектов имело место достаточно плотное общение с командой разработчиков УХ через ящик cpm@1c.ru, который в 2015 году, судя по всему, разбирал непосредственно руководитель разработки продукта – Станислав Митрохин с привлечением специалистов соответствующих направлений. Стоит отдать должное,- на большинство вопросов ответы приходили в течение суток.

Собственно, перейду к тому, что не понравилось:

В блоке «Консолидация отчетности» редакции 1.0:

1. В Портале сверки ВГО, если определена какая-то аналитика сверки (например, аналитика «Договор» для сверки ДЗ / КЗ), она всегда должна быть заполнена, соответственно, нельзя использовать показатели с разной аналитикой, например, «Задолженность перед поставщиками» и «Прочая задолженность» в одном «пуле» показателей «Кредиторская задолженность»,
2. В механизме автоматических консолидационных корректировок есть операция расчета и исключения «Нереализованной прибыли» (НРП), однако алгоритм данной операции не учитывает остатки ТМЦ и НРП на начало периода, а используются только обороты за период, что в целом не соответствует общим правилам расчета НРП,
3. В механизме автоматических консолидационных корректировок нельзя использовать дополнительную аналитику учета НРП, например, «Группы номенклатуры» (по-моему, там используется только аналитика «Счет учета»).

В блоке «Казначейство» редакции 1.1:

1. Довольно много «детских» болезней как в коде, так и в методике реализации. Это стало заметно, так как в ЛАДе имеется существенный опыт и разработки своего аналогичного продукта, и аналогичных проектов, соответственно, заметно, как разработчики УХ наступают на те же грабли. Исправление же этих «граблей» — на 90% «Проектный объем работ» (разработчики 1С устраняют некоторые замечания, но не так быстро, как этого требуют проекты).
2. Практически полное отсутствие RLS на данные договорного блока и казначейства. Официальная позиция разработчиков: «RLS — это проектный объем работ» была непонятна многим внедренцам, так как на каждом проекте корпоративного уровня этот вопрос серьезно прорабатывается, а основные уровни разграничения доступа: Организация / ЦФО (в строительстве можно добавить Проект) используется практически всегда. Проблема усугубляется тем, что при написании кода запросов к различным объектам, разработчики абсолютно «забыли» что RLS будет разрабатываться, и постоянно использовали обращения к объектам «через точку». А запросов этих в УХ много.
3. Отсутствовал (до редакции 1.2) документ «Реестр платежей», без которого не обходится ни одна корпоративная система казначейства.
4. Необходимо отслеживать управленческую аналитику (БДДС, лимитов) во всей (удлиненной) цепочке документов: БДДС – Договор – ЗНО – Платежка – Списание ДС – Отражение факта бюджетирования (документ создается и меняется обычно программно, что требует пристального к нему внимания), причем, управленческая аналитика в типовой конфигурации 1.1.3 теряется / неправильно заполняется практически на каждом шаге процесса, причем частично. Поэтому проверять надо самостоятельно все алгоритмы заполнения / изменения каждого документа в цепочке на каждом шаге.
5. Использование документа «Отражение факта в бюджетировании» реализовано «кривовато»: видимо его целью было разделение на управленческие и бухгалтерские документы, но обрабатываются казначеем именно Списания / Поступления ДС на скрытой (!!!) табличной части (которая иногда совсем «теряется» — при использовании некоторых видов операций этих документов) через обработку «Разнесение банковской выписки», а факт списания во всем регистре БДДС отражается именно документом «Отражение факта в бюджетировании».
6. Нельзя Заявку на расход ДС (Заявка на операцию) оплачивать частично, при чем ограничение в типовой конфигурации довольно «детское»: в списке документов «ЗНО» запросом вытягивается соответствующая Платежка и дата и № платежки выводится в колонку списка, и при вводе по ЗНО двух ПП в запросе возникает ошибка, которая не позволяет выводить список документов…

В общем проблем от применения УХ в части проекта централизованного казначейства, конечно, было больше, чем плюсов. Надеюсь, в редакции УХ 1.2 разработчики учли опыт, замечания и пожелания. Действительно интересно оценить улучшения редакции УХ 1.2 «на практике». И хотя основные проблемные места уже известны, со слабой командой, как и 1С:УХ типовом исполнении, на мой взгляд, пока не внедрить.