← На главную

Рассмотрим распространенную задачу, с которой часто сталкиваются при внедрении управленческого учета в 1С:ERP. Допустим, у нас есть потребность установить лимит расхода денежных средств (ДС) на родительское подразделение (например, «Департамент ИТ»), а контролировать этот лимит мы хотим по всем его дочерним подразделениям («Отдел разработки», «Отдел поддержки» и так далее). Выясним причину, по которой это нельзя сделать простым нажатием одной кнопки, и разберем по шагам доступные способы решения.

Почему типовой механизм не понимает иерархию напрямую?

Проанализируем ситуацию с точки зрения архитектуры системы. В 1С:ERP алгоритмы контроля лимитов работают по принципу строгого соответствия аналитик. Если мы установили лимит на аналитику «Родительское подразделение», то при проведении документа ЗаявкаНаРасходованиеДенежныхСредств от имени «Дочернего подразделения», система будет искать остаток лимита именно для дочернего узла. Не найдя точного совпадения, программа выдаст ошибку превышения или полного отсутствия доступных средств.

Встроенного «каскадного» или иерархического контроля сверху-вниз в типовой ERP нет. Полноценный иерархический контроль является прерогативой систем класса CPM (например, 1С:Управление холдингом).

Казначейство или Бюджетирование: выбор подсистемы

В 1С:ERP существует два взаимоисключающих способа контроля лимитов. Разберем подробнее каждый из них:

1. Простое лимитирование (через Казначейство). Здесь жестко зашито всего 3 аналитики контроля: Организация, Подразделение, СтатьяДДС. Контроль осуществляется строго в рамках месяца. Настроить контроль по группе подразделений через этот механизм невозможно в принципе.
2. Расширенное лимитирование (через Бюджетирование). Этот режим позволяет использовать до 6 произвольных аналитик (включая партнеров, договоры, направления деятельности и любые кастомные поля). Именно гибкость бюджетирования позволит нам реализовать обходной путь решения задачи.

Что изменилось в контроле лимитов в 1С:ERP 2.5?

Посмотрим на изменения в редакции 2.5. Фирма «1С» существенно переработала механизм, добавив алгоритм «Контроль лимитов 2.5». Старый алгоритм остался под названием «Контроль лимитов 2.4».

Главные отличия нового механизма:

1. Фактические данные теперь собираются не по корреспондирующим регистрам остатков, а по аналитическим оборотным регистрам.
2. Остатки лимитов рассчитываются динамически прямо в момент проведения документа контроля (например, заявки), причем система гораздо корректнее обрабатывает суммы, заявленные «сверх лимита».

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

Решение задачи: Использование ЦФО (Центров финансовой ответственности)

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

1. Создание дополнительного реквизита: Зайдем в настройки дополнительных реквизитов и сведений. Добавим для справочника СтруктураПредприятия новый дополнительный реквизит, назовем его «ЦФО» (Центр финансовой ответственности). Тип значения можно задать как дополнительное значение, либо ссылкой на сам справочник подразделений, если вы хотите указывать в качестве ЦФО именно родительское подразделение.
2. Заполнение реквизита: Пройдемся по всем подразделениям. Для дочерних подразделений (например, «Отдел разработки» и «Отдел поддержки») в реквизите «ЦФО» укажем единое значение, соответствующее их группе (например, «Департамент ИТ»). Таким образом, разные элементы структуры предприятия будут ссылаться на один общий центр ответственности.
3. Настройка аналитики бюджетирования: Перейдем в ПВХ (План видов характеристик) АналитикаСтатейБюджетов. Добавим созданный дополнительный реквизит «ЦФО» в качестве доступной аналитики для подсистемы бюджетирования.
4. Настройка правил лимитирования: В модели бюджетирования и в правилах получения факта настроим использование новой аналитики. Бюджет лимитов (документ ЭкземплярБюджета) будем формировать и утверждать не в разрезе подразделений, а в разрезе ЦФО.

Теперь при проведении заявки на расходование от любого подчиненного подразделения, система через механизм расширенного бюджетирования определит его ЦФО, обратится к регистрам лимитов и успешно спишет сумму из общего «котла» родительского департамента.

Единственный минус данного подхода, который отмечают на практике — в типовых отчетах по бюджетам группировка будет идти по аналитике ЦФО, а уже под ней будут выводиться организации и документы. Однако это легко нивелируется настройкой вариантов отчетов.

Альтернативные пути решения: доработка и правила факта

Если вариант с ЦФО по каким-то причинам не подходит, рассмотрим альтернативные методы.

Доработка (создание документа перераспределения). Если компания не хочет усложнять аналитику бюджетирования, можно написать небольшое расширение конфигурации. В этом случае создается кастомный документ (например, «Распределение лимитов группы»). Логика следующая:

1. Лимит устанавливается на родительское подразделение штатным документом.
2. При создании заявки от дочернего подразделения, система (через подписку на событие или расширение модуля проведения) проверяет наличие остатка у родителя.
3. В случае успеха технически формируются движения в служебном регистре, которые «спускают» часть лимита на дочернее подразделение в момент проведения заявки.

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

Подводя итог, проанализировав все возможности, мы рекомендуем использовать подход с дополнительным реквизитом «ЦФО». Он позволяет обойтись без написания программного кода, остается в рамках типовой логики 1С:ERP и легко масштабируется при изменении структуры компании.