Лимиты и бюджеты по объектам в ERPNext: Warn, Stop и отчёт по отклонениям

Бюджет по объекту в ERPNext задаётся документом Budget: сумма по статье расходов в разрезе Project или Cost Center, а режимы Stop, Warn и Ignore настраиваются отдельно для заявки, заказа и фактических расходов. Ниже: что именно считается, куда ставить Warn, а куда Stop, и почему лимит иногда молчит.

Как работает Budget в ERPNext: что именно он ограничивает

Budget в ERPNext считает деньги, а не количество. Лимит задаётся как сумма по статье расходов (счёту типа расходов, Expense Account) для конкретного проекта или центра затрат. Когда создаётся заявка, заказ или проводится счёт, система складывает уже потраченное и запланированное и сравнивает с лимитом. Превысили: либо покажет предупреждение, либо остановит документ. Всё это есть в коробке, дополнительно ничего ставить не нужно, а в нашей схеме внедрения ERPNext под ключ мы используем Budget как денежный предохранитель закупок объекта.

Важная граница, о которой надо знать сразу. Контроля «не более 12 тонн арматуры» штатный Budget не даёт: он видит рубли. Если вам нужно ограничение по объёму из спецификации договора, это другая задача и другой механизм, о нём у нас отдельный материал про контроль перерасхода по спецификации. Для объекта обычно нужны обе проверки: объём ловит лишнее количество, бюджет ловит завышенные цены и позиции вне спецификации.

Чтобы не терять нить, сведу в таблицу, что считает документ Budget при проверке (по коду ветки version-15 репозитория frappe/erpnext, сверено 01.10.2026). | Что сравнивается | Откуда берётся сумма | |---|---| | Фактические расходы | Проведённые проводки (GL Entry) по счёту и проекту или центру затрат | | Обязательства по заказам | Позиции проведённых Purchase Order, где сумма больше уже выставленной в счетах | | Заявки | Проведённые заявки на закупку: неоформленный остаток количества умножается на цену | | Лимит | Сумма в строке Budget Account за период |

Как привязать бюджет к объекту и статьям затрат

В документе Budget в поле Budget Against выбирается Cost Center или Project (в v15 это выпадающий список; другие измерения учёта подключаются как Accounting Dimension). Дальше указывается компания, финансовый год, и в таблице Budget Accounts перечисляются статьи расходов с суммой по каждой. Статья должна быть негрупповым счётом типа «прибыли и убытки»: на группу или балансовый счёт код выдаёт ошибку. Один и тот же счёт в одном бюджете дважды не вводится.

Практически я для каждого объекта завожу отдельный Project и один Budget на него. Строки: материалы, субподряд, механизмы, накладные. Лимит у каждого объекта свой, и это удобнее, чем общий бюджет компании, где перерасход одного объекта съедается недорасходом другого. Если вам ближе деление по подразделениям, берут Cost Center; про то, чем проект отличается от центра затрат и как не запутаться в двойном учёте, у нас есть отдельная статья про центры затрат и проекты.

Самая коварная настройка лежит не в Budget, а в карточке номенклатуры. Чтобы система знала, на какую статью падает материал, в Item Default нужен Expense Account (и центр затрат), либо он берётся из группы товаров. По коду v15 счёт ищется по цепочке: Item Default номенклатуры, затем группа товаров, затем счёт расходов по умолчанию в карточке компании. Если счёт не нашёлся вовсе, функция проверки завершается без ошибки, а если подставился счёт компании, которого нет в строках бюджета, сравнивать тоже не с чем. Лимит «молчит» не потому, что сломан, а потому что документ ему нечего сопоставить. Поэтому первое, что я проверяю на новом объекте, это что у каждой номенклатуры из спецификации счёт расходов задан и совпадает со строкой бюджета.

• Один Project на объект и один Budget на Project
• Строки Budget Accounts: материалы, субподряд, механизмы, накладные
• В каждой номенклатуре заполнен Expense Account
• Бюджет проведён (Submit), а не оставлен черновиком

Warn, Stop или Ignore: какой режим поставить на заявке, заказе и счёте

Режимы задаются в блоке Control Action. Для каждой стадии есть свои флажки и два действия: на превышение годового бюджета и на превышение накопленного за месяцы. Названия полей в v15 такие: Applicable on Material Request, Applicable on Purchase Order, Applicable on booking actual expenses и пары Action if Annual Budget Exceeded on MR/PO/Actual. По умолчанию годовое превышение стоит в Stop, накопленное месячное в Warn. Действия: Stop блокирует документ, Warn выводит оранжевое предупреждение и пропускает, Ignore не проверяет.

Есть жёсткое правило зависимости, зашитое в код: если включён контроль на заявке, должны быть включены контроль на заказе и на фактических расходах; если включён заказ, нужны фактические расходы. Это логично: нельзя следить за запросом и не следить за деньгами, которые потом реально уйдут. В ветке version-16 документ Budget устроен иначе: нет таблицы Budget Accounts, один бюджет относится к одному счёту (поля Account и Budget Amount), есть диапазон финансовых лет, периодичность распределения (Distribution Frequency), таблица Budget Distribution, ревизия бюджета (Revision Of) и отдельный контроль накопленных расходов (Applicable on Cumulative Expense). Названия самих действий Stop, Warn, Ignore остались. Поэтому я всегда сверяю поля на стенде той версии, которую ставлю клиенту, а при переходе с v15 на v16 бюджеты проверяю отдельно.

Мой типовой выбор такой. На заявке прораба ставлю Warn: прораб видит, что объект подходит к лимиту, но работа не встаёт, а заявка уходит руководителю с пометкой. На заказе поставщику ставлю Stop: деньги ещё не потрачены, но обязательство уже будет принято, и именно тут нужна жёсткая точка. На фактических расходах (счёт поставщика, проводка) Stop тоже оставляю, иначе закупка через прямой счёт окажется без контроля. Исключение для директора делается ролью: в карточке компании есть поле Exception Budget Approver Role, и пользователь с этой ролью получает вместо блокировки предупреждение.

Что считать «заказ против лимита» по времени, показывает инфографика после этого раздела; а ниже текстом: заявка проверяется в момент отправки (Submit) и учитывает уже проведённые заявки и заказы по этой номенклатуре, заказ проверяется при Submit с учётом неоплаченной части заказов, счёт и проводка проверяются как фактические затраты.

Почему лимит не сработал: черновики, версия и счёт расходов

Если заказ прошёл при очевидном превышении, причина почти всегда из короткого списка. Первая: документ ещё черновик. Проверка Budget срабатывает при проведении (Submit), а не при сохранении. Вторая: сам Budget не проведён. Бюджет в черновике лимиты не проверяет, это легко пропустить, когда его завели «на потом». Третья: в карточке номенклатуры нет счёта расходов или он не совпадает со строками бюджета (см. выше). Четвёртая: не включён флажок на нужной стадии, и документ этого типа просто не проверяется.

Пятая причина тоньше: проверка идёт по комбинации «счёт расходов плюс проект или центр затрат», поэтому в строках документа должен стоять тот же Project или Cost Center, что и в бюджете. Если снабженец не проставил проект в строке заказа, лимит объекта не увидит эту сумму. Шестая: фактические расходы проверяются на уровне проводок главной книги и только по счетам с корневым типом Expense, где указан проект, центр затрат или другое измерение учёта. Журнальная проводка без проекта или по счёту другого типа в бюджет объекта не попадёт.

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

Для самопроверки соберите дерево: заказ прошёл при превышении, значит проверьте по порядку: проведён ли документ, проведён ли бюджет, есть ли счёт расходов у номенклатуры, совпадает ли он с бюджетом, включён ли флажок на этой стадии. Это то же самое, что на схеме симптом, причина, действие.

Как смотреть отклонения: Budget Variance Report и расчёт остатка

Для обзора после работы есть стандартный отчёт Budget Variance Report. Фильтры: период с какого по какой финансовый год, периодичность (месяц, квартал, полугодие, год), компания и Budget Against (проект, центр затрат или другое измерение). Для каждого периода отчёт показывает колонки Budget, Actual и Variance, а флажок Show Cumulative выводит накопительный итог. Отчёт строится по проведённым данным, поэтому обязательства по ещё не оплаченным заказам в «Actual» не попадают.

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

Про карточки согласования. В сторонних описаниях (например, в руководстве erpnext.jp) встречается Approval Hub с карточкой Budget Status Card, где видны Total Budget, Amount Spent и Balance after approval. В коде frappe/erpnext версии 15 я такой карточки не подтвердил, поэтому не закладываю её в проект как «из коробки»: если вам нужен именно такой экран, проверьте на своей версии либо рассматривайте как доработку.

Расчёт на условных цифрах (см. инфографику): бюджет по материалам 1 000 000 ₽, потрачено 790 000 ₽, заказ на согласовании 260 000 ₽. Остаток до заказа 210 000 ₽, после заказа минус 50 000 ₽, перерасход 5 %. Заказ при режиме Stop не пройдёт; при Warn пройдёт с предупреждением, и руководитель решит.

Как «Лесной Дом Групп» настроила лимиты на три объекта (условный пример)

Условный пример, цифры вымышленные. Строительная компания «Лесной Дом Групп», 14 рабочих мест, три объекта одновременно: два каркасных дома и баня. Раньше лимиты жили в таблице у директора, и перерасход выяснялся после закрытия месяца. Мы завели три Project, на каждый по одному Budget с четырьмя статьями: пиломатериалы и метизы, кровля и изоляция, субподряд, механизмы. Режимы: на заявке Warn, на заказе Stop, на фактических расходах Stop. Директору назначили роль исключений в карточке компании.

Первый неприятный сюрприз случился в первую же неделю: заказ на гвозди и саморезы прошёл «мимо» лимита. Причина оказалась банальной: у крепежа в карточке номенклатуры не был задан счёт расходов, и проверка тихо ничего не нашла. Мы прошли по всем 160 позициям справочника, сверили счета с бюджетами, и такие случаи ушли. Второй сюрприз: снабженец заводил заказ без проекта в строках, и сумма не попадала в бюджет объекта. Решили шаблоном заказа: проект подтягивается из заявки.

Итог пилота за месяц (условно): две закупки остановлены на заказе с перерасходом от 3 до 9 процентов, обе ушли на повторное согласование, одна была урезана, вторая одобрена директором. Одно предупреждение на заявке прораб проигнорировал, но руководитель увидел его в письме. Главный результат не в рублях, а в том, что обсуждение «можно ли» происходит до заказа, а не после счёта. Обещать конкретный процент экономии для вашей компании я не буду: он зависит от дисциплины заявок и качества справочника.

Живой пример настройки, от Budget до предупреждения на заявке, покажем на демостенде erp-demo.itfresh.ru по запросу.

Где Budget не поможет

Первое ограничение: количество. Контроля по объёму спецификации штатный Budget не делает. Второе: основные средства. Budget привязан к счетам расходов и не позволяет выбирать счета активов, поэтому для техники и инвентаря нужны сторонние приложения или другой регламент. Третье: затраты проекта на карточке Project (total purchase cost) считаются из проведённых счетов поставщика, то есть появляются после проведения счёта, а не на заявке и заказе; для раннего контроля нужен как раз Budget.

Четвёртое: версии. Поля и логика между v15 и v16 различаются (в v16 один бюджет привязан к одному счёту, добавлены диапазон финансовых лет, периодичность распределения и ревизии), а накопленный месячный лимит считается либо по справочнику Monthly Distribution, либо, если он не выбран, поровну: одна двенадцатая годовой суммы за каждый прошедший месяц. Для стройки с сезонными пиками равные доли дают ложные предупреждения, поэтому распределение лучше задать. Прежде чем обещать заказчику конкретное поведение, откройте Budget на стенде своей версии. Пятое: Budget не заменяет согласование. Предупреждение видно пользователю, но решение принимает человек; для маршрута согласования смотрите материал про согласование договоров и заявок.

Частые вопросы