Данная статья будет полезна в первую очередь интеграторам, пытающимся начать или продолжить внедрять программный продукт БИТ.Финанс. Изучив наш опыт, вы сможете избежать многих ошибок, сэкономить свое время и бюджет заказчика.
Типовое внедрение информационной системы – это устоявшийся современный тренд при внедрении любой 1C-ной конфигурации. Многие компании-интеграторы пытаются подстраиваться под этот тренд как могут, стараясь внедрять БИТ.Финанс с минимальным количеством доработок. Но чаще всего неопытность все равно приводит к доработкам там, где нет в этом необходимости.
К нам в компанию Прайм Финанс за последние 2 года обратились 8 клиентов, у которых уже был внедрен БИТ.Финанс. Ключевыми причинами, по которым они обратились к нам, было недовольство интегратором или недовольство самой системой, при этом второе являлось следствием первого. Анализ выполненных настроек и доработок показал следующие типовые ошибки интеграторов:
- Разработка механизмов, при наличии аналогичных типовых.
- Нерациональное использование типовых механизмов.
Что не стоит дорабатывать:
1. Отчет «Обороты по статьям» для произвольного определения порядка статей в отчете. Основное его назначение – это выверка и проверка данных в регистре «Обороты по бюджету (БИТ)», с чем он отлично справляется в типовом варианте.
Чтобы получить произвольную последовательность статей в отчете, пользователь может сформировать «Отчет по бюджету» или «План-фактный анализ по бюджету», которые берут структуру статей из справочника «Бюджеты». Сортировка групп и статей внутри групп определяется типовым реквизитом «Кодификатор».
2. Механизмы проведения документов по регистрам БИТ без перепроведения по другим регистрам. Для этих целей существует типовая обработка «Групповая трансляция и редактирование доп. аналитик».
3. Механизмы создания документов «Заявка на расходование ДС» на основании документов «Списание с расчетного счета» для списания лимитов. Некоторые интеграторы разрабатывают этот механизм с целью добиться списания лимитов из регистра «Контрольные значения бюджетов». Мы своим клиентам рекомендуем не осуществлять платежи без заявок. Без заявок должны осуществляться только безакцептные платежи (комиссии и подобное). Если и есть требование заказчика списывать лимиты по платежам без заявок, то рациональнее использовать типовой механизм трансляции данных. Он на основании данных из регистра «Обороты по бюджетам» формирует движения в регистр «Контрольные значения по бюджетам». Таким образом, задача решается типовыми средствами системы и без создания лишних документов.
4. Механизмы загрузки данных из сторонних систем. Еще с версии 2.8 в системе есть типовой механизм «Источники данных», позволяющий загрузить в БИТ.Финанс любые данные из любых других 1С-ных систем. При этом есть механизмы, которые позволяют преобразовывать загружаемые данные по требованию пользователя.
5. Механизмы для переноса неизрасходованных лимитов из прошлого месяца в текущий. Решение доступно в типовом функционале, достаточно лишь установить периодичность контроля «Год» в сценарии и ежемесячно перепроводить документ «Установка контрольных значений» с периодом планирования +1 месяц.
6. Отображение в документе «Заявка на расходование ДС» остатка по статье. В документе есть закладка «Информация», в которой есть все необходимые данные. Многие об этой вкладке не знают, потому что при небольшом разрешении экрана она не помещается на экранную форму документа.
7. Механизмы трансляции. Все задачи, связанные с трансляцией, можно решить типовыми средствами.
8. Формирование движений по расходным статьям с минусом в регистр «Обороты по бюджетам». Движение в этом регистре с минусом должно означать не движение по расходной статье, а сторно, и только сторно.
Какие типовые механизмы не стоит использовать или стоит использовать «с умом»:
1. Не используйте типовую трансляцию для документов ДДС. Вы будете вынуждены настроить механизмы трансляции, когда столкнетесь с возвратами ДС и курсовыми разницами.
2. Не используйте типовую настройку формирования движений на плане счетов «Бюджетирование». Через полгода-год возникнет ситуация, когда нужно будет разнести одну статью на два вида проводок и придется или дорабатывать систему, или настраивать трансляцию.
3. Не используйте типовой документ «Актуализация бюджета», если используется хоть одна дополнительная аналитика, помимо статьи. Для целей актуализации бюджета лучше использовать иные механизмы.
4. МХО для сбора факта в типовых документах. У клиента должна быть уверенность в корректности работы системы и формировании отчетности, для этого вы должны обеспечить наследственность данных между БУ и УУ. При МХО факт формируется на основании документа, без учета иных факторов (правила зачета авансов, ДЗ, КЗ, партии и т.д.), а трансляция формирует движение или набор движений на основании движения в регистре источнике, что дает однозначное понимание того, как возникло движение в УУ и на основании какой проводки БУ.
5. Права доступа на уровне записи. Прежде чем включать права доступа необходимо сопоставить программно-аппаратные мощности сервера клиента, количество пользователей, плановое количество документов каждого типа в системе через 3 года, а также плановое количество записей в регистре сведений «Ограничения прав доступа на уровне записей». Для верных выводов у Вас должна быть накоплена статистика снижения производительности при включении RLS.
Что действительно стоит дорабатывать:
1. В типовой конфигурации движения сверхбюджетных документов по регистру «Контрольные значения бюджетов» формируются не всегда корректно.
Пример: Если выбраны аналитики для контроля Статья + Проект, и в момент проведения документа «Заявка на расходование ДС», система ищет в регистре «Контрольные значения бюджетов», выбранные в документе сочетания аналитик. Если комбинация не найдена, то формируются движения с пустыми аналитиками. Возникают ситуации, когда сверхбюджетные платежи не расходуют лимиты по отдельным аналитикам. Если описанные ситуации являются критичными для Ваших клиентов, смело дорабатывайте.
2. Документ «Актуализация бюджета», если он укладывается в методологию учета Заказчика. Документ требует доработки для корректной отработки следующих механизмов:
- расчет разницы между планом и фактом;
- корректное приравнивание плана к факту по кнопке «Актуализировать»;
- корректный перенос плановых данных.
3. Механизмы автоматического переноса неисполненных документов планирования на оперативный день. Так как отчет «Платежный календарь» работает только с текущей даты и вперед, то все документы планирования, которые остались в прошлых периодах, не попадают в отчет, поэтому данные механизмы требуют доработки для целей корректного формирования отчета «Платежный календарь».
4. Механизмы актуализации данных в документе «Дополнительные условия по договору». Данные для подсистем бюджетирование и казначейство должны формироваться на основании информации из договорного блока там, где это возможно. В связи с этим в графиках платежей и начислений должны быть максимально оперативные и точные данные. Типовой механизм актуализации графиков в БИТ.Финанс максимально примитивен и не отвечает большинству требований бизнеса, поэтому мы часто его дорабатываем, а также настраиваем механизмы бизнес-процессов для их контроля и индикации необходимости их актуализации.
5. Оптимизация работы механизма визирования. Сложные маршруты, большое количество документов, одномоментно находящихся на визировании (от 300), большое количество пользователей (от 500), участвующих в визировании, все эти факторы ввиду особенностей работы механизмов, приводят к медленной работе формы визирования и обработки «Рабочее место визирование». Есть несколько методик оптимизации типовых настроек, таких как использование максимально простых маршрутов, которые запускаются по произвольному условию в регистре «Назначение алгоритмов» и оптимизация прав установки виз, но не всегда их достаточно. В этом случае приходится дорабатывать регистр, который всегда хранит права установки виз для конкретных документов и пользователей. Таким образом, возможность установки визы не рассчитывается системой в момент открытия документа, а берется готовая из регистра.
6. Оптимизация работы документа «Форма ввода бюджета». Часто большие объемы данных в одном документе приводят к его медленной работе. Мы рекомендуем решать эти проблемы путем тонкой настройки программно-аппаратного комплекса Заказчика, но не всегда это возможно, особенно, если используется виртуализация. В этом случае приходится дорабатывать документ с точки зрения повышения оптимальности его работы.
7. Доработка отображения ФИО пользователя, которому доступна виза. Просто удобный функционал для пользователя, который очень часто дорабатываем своим клиентам.
8. Разработка АРМ. Разработка автоматизированных рабочих мест для различных ролей пользователей – это классическая задача для всех проектов, в которых Исполнитель заботится об удобстве работы пользователей. Цель доработки добиться минимизации количества кликов и времени, которые необходимы пользователю, чтобы открыть или найти необходимый объект метаданных в системе.
Таким образом, изучайте типовые механизмы и придумывайте оптимальные алгоритмы их использования. БИТ.Финанс – это набор гибких, удобных механизмов, благодаря которым можно решить большинство поставленных задач. И да прибудут с Вами типовые конфигурации.
Если есть комментарии\вопросы или Вы не согласны с нами - добро пожаловать в комментарии, в споре рождается истина!
