Согласование заявок на закупку: маршрут прораб, руководитель, снабжение, бухгалтерия в ERPNext

Согласование заявок на закупку в ERPNext строится как маршрут по ролям: прораб подаёт, руководитель проверяет, снабжение заказывает, бухгалтерия оплачивает. Каждый видит свой шаг, решения остаются в журнале. Ниже: роли, пороги суммы, запрет самосогласования и то, чего из коробки нет.

Кто согласует закупку: цепочка ролей от прораба до бухгалтерии

Маршрут закупки в строительной компании я собираю из четырёх ролей и пяти документов. Прораб создаёт Material Request, то есть заявку на материалы, и привязывает её к объекту. Руководитель проверяет заявку или заказ. Снабженец превращает одобренную заявку в Purchase Order и ведёт поставки. Бухгалтер оформляет приёмку, счёт и заявку на оплату, которая проходит собственный короткий маршрут. Если вы только выбираете систему для такого процесса, начните со страницы про ERPNext для небольших компаний: там описан состав внедрения, а здесь я разбираю один его кусок, согласование.

Почему роли четыре, а не десять. Чем длиннее цепочка, тем чаще заявка стоит. Я видел схемы, где каждую закупку проверяют пять человек, и через месяц прорабы возвращаются к звонкам снабженцу. Для команды из пяти-восьми человек хватает последовательной цепочки без параллельных веток: один человек подтверждает потребность, один отвечает за деньги, остальные выполняют. Исключение составляют крупные закупки, для них добавляется второй согласующий по сумме, об этом в разделе про пороги.

Состояния документа в маршруте я называю так, чтобы их понимал прораб, а не только администратор: «Черновик», «На согласовании», «Согласовано», «Возвращено». Под ними лежат системные состояния документа ERPNext: 0 для черновика, 1 для проведённого, 2 для отменённого. Workflow добавляет поверх них свои названия и решает, какая роль может перевести документ дальше. Вот как это выглядит по ролям. | Роль | Что делает | Документ | Что видит | |---|---|---|---| | Прораб | подаёт заявку | Material Request | только свои объекты | | Руководитель | проверяет и согласует | заявка и заказ | все проекты | | Снабженец | формирует заказ, ведёт поставку | Purchase Order | закрепленные объекты | | Бухгалтер | приёмка, счёт, оплата | Purchase Invoice, Payment Request | данные своей компании |

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

Что видит и подтверждает каждый участник

Права в ERPNext работают на трёх уровнях, и согласование опирается на все три. Первый уровень — роль: она определяет, с какими типами документов человек работает и какие действия ему доступны (чтение, создание, запись, проведение, отмена). Второй — User Permissions: ограничение по значению ссылки, например по проекту или компании. Третий — права на уровне поля, когда одни поля скрыты или доступны только для чтения определённым ролям. Для маршрута закупки обычно хватает первых двух.

Самая частая ошибка на старте связана со вторым уровнем. Прорабу назначили роль, он создал заявку, но забыли добавить для него User Permission на его объект. В результате он видит заявки соседних объектов, а иногда и чужие суммы. Роль ограничения сама не создаёт: она только открывает тип документа. Поэтому после настройки я захожу под тестовым прорабом, очищаю кэш и проверяю три вещи: список заявок, выпадающие списки проектов и глобальный поиск. Подробнее о механизме можно прочитать в документации по User Permissions, она описывает и режим Applicable For, когда фильтр действует только на выбранные типы документов.

Матрица для строительной компании выглядит так (роли названы по-русски, настраиваются под компанию). | Действие | Прораб | Руководитель | Снабжение | Бухгалтерия | |---|---|---|---|---| | Создать заявку | да | нет | нет | нет | | Согласовать заявку | нет | да | нет | нет | | Создать заказ поставщику | нет | нет | да | нет | | Провести оплату | нет | нет | нет | да | | Видит объекты | свои | все | закреплённые | по компании |

Права на создание и на правку в Frappe разделены. Это удобно: прорабу можно оставить подачу заявок и отобрать право удаления, а согласующему дать право проведения без права создавать заявки. Ещё одна мелочь, которая экономит нервы: роль «Снабженец» и роль «Бухгалтер» не должны пересекаться в одном человеке, если компания хочет сохранить разделение между заказом и оплатой. В компании из шести человек это иногда один сотрудник, и тогда разделение держится на самом маршруте и журнале, а не на правах.

Как руководитель согласует за минуту: письмо с кнопками и рабочее место согласующего

Руководитель на объекте или в дороге не будет открывать десять вкладок. Поэтому согласование я стараюсь довести до одного действия. Первый способ штатный: Workflow умеет отправлять уведомление о доступных действиях, а в настройках маршрута есть опция «Send Email Alerts». По описаниям на форуме Frappe и в нашей базе знаний действия Workflow можно выполнять прямо из письма по подписанной ссылке, но на конкретной версии это стоит проверить на тестовом сайте: ссылки зависят от настройки исходящей почты и адреса сайта.

Второй способ — экран согласования. В нашей настройке руководитель открывает список заявок, которые ждут его решения, видит позиции, сумму, пометку о переборе по спецификации и комментарий прораба, и одной кнопкой согласует или возвращает заявку. Это не отдельный модуль ERPNext, а штатный Workflow плюс рабочий стол и фильтры, настроенные под роль; так он устроен и на демостенде, который мы показываем по запросу. Пакетное согласование, делегирование и другие удобства сверх этого — доработка, и если они вам важны, их нужно записать в техническое задание до старта.

Третий способ — мессенджер. Готового бота согласования в коробке нет. Рабочая схема из практики сообщества: сторонняя интеграция присылает согласующему сообщение с кнопками, а сама операция выполняется штатным Workflow. Безопасность здесь важнее удобства: обработчик обязан сверять идентификатор чата с пользователем, проверять его право на переход и статус документа, иначе повторное нажатие или чужая кнопка проведёт лишнее. Я включаю такой канал только после отдельной проверки и всегда с журналом действий.

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

Пороги по сумме: когда нужен директор

Обычная просьба заказчика: мелкие закупки руководитель закрывает сам, а всё, что дороже определённой суммы, идёт ещё и директору. В Workflow это решается условиями на переходах. В колонке Condition записывается выражение на простом Python, документация приводит пример вида doc.grand_total <= 100000. Сумма 100 000 ₽ здесь иллюстративная, порог вы задаёте сами.

# переход «Согласовать» (руководитель), заказ до порога
doc.grand_total <= 100000

# переход «Отправить директору», заказ выше порога
doc.grand_total > 100000

Условия переходов из одного состояния обязаны исключать друг друга. Если диапазоны пересекаются, у согласующего появятся две кнопки, и он нажмёт ту, которая ему удобнее. Поэтому границы записывают с разными знаками: «не больше» в одном условии и «больше» в другом, без перекрытия.

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

Какой порог ставить. Универсального числа нет, и я не буду называть «правильную» сумму. Я смотрю на выборку заказов за последние месяцы: какая доля закупок дешевле порога, сколько заказов ушло бы директору. Если директору попадает больше пятой части потока, порог занижен, и он станет узким местом. Если почти ничего, порог высокий, и директор не увидит значимых закупок. Начинаю с одного порога, через месяц смотрю статистику и двигаю.

Для оплаты используется отдельный маршрут: заявка на оплату (Payment Request) проходит своё согласование у бухгалтерии или директора. Разделение полезно: подтвердить заказ и подтвердить платёж — разные решения, особенно если поставщик меняет реквизиты. Тема фальшивых счетов от поставщиков заслуживает отдельного внимания, про неё есть материал про подмену счёта поставщика: в маршруте оплаты я оставляю шаг, где второй человек сверяет реквизиты.

Чего нет из коробки: самосогласование, параллельные маршруты, сквозные статусы

Самосогласование. В базе знаний сказано, что стандартный Workflow его не предотвращает. Уточню по официальному исходнику: у каждого перехода есть флажок «Allow Self Approval», и по умолчанию он включён. Если его снять, создатель документа не сможет выполнить этот переход, даже имея роль согласующего. Обсуждения на форуме добавляют нюанс: Administrator блокировку обходит, а условие вида doc.owner != frappe.session.user в колонке Condition скрывает только кнопку, но не заменяет саму проверку. Поэтому для запрета самосогласования я снимаю флажок на переходах «Согласовать» и проверяю, что автор заявки действительно не видит кнопку, а потом пробую обойти через другой путь.

Параллельное согласование. Workflow в Frappe устроен как конечный автомат: у каждого состояния есть набор переходов, у каждого перехода одна разрешённая роль. Параллельного согласования несколькими людьми («нужны подписи двух из трёх») и динамического назначения согласующего из поля документа из коробки нет, для этого пишут серверный скрипт или отдельное приложение. Для команды из пяти-восьми человек я такой сложности не создаю: последовательная цепочка плюс порог по сумме закрывают почти всё.

Ещё несколько ограничений, о которые я спотыкался. Чтобы разрешить правку строк уже проведённого заказа через Update Items при включённом Workflow, у текущего состояния маршрута в колонке Allow Edit должна стоять роль этого пользователя: так проверяет код ERPNext v15 (validate_workflow_conditions), иначе появится ошибка Insufficient Permissions. Чтобы документ можно было отменить через Workflow, нужно явно описать состояние со статусом 2 и переход в него: права Cancel в менеджере ролей этого не заменяют. Новая версия документа через Amend получает суффикс и может разорвать связи, поэтому правки после проведения я стараюсь делать через Update Items, а не через отмену и пересоздание.

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

• Allow Self Approval: снять на переходах согласования
• Параллельные маршруты: только доработкой
• Update Items при Workflow: роль в Allow Edit состояния
• Отмена: нужно состояние со статусом 2
• Сброс маршрута при правке: проверить на стенде

Как «Зелёный Контур» сократила путь заявки с письма до трёх кликов (условный пример)

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

После внедрения путь выглядит так. Прораб создаёт заявку, выбирая объект и позиции: первый клик, «Отправить». Руководитель получает уведомление, открывает документ и нажимает «Согласовать»: второй клик. Снабженец формирует заказ из согласованной заявки одной кнопкой: третий клик. Для заказов выше условного порога в 100 000 ₽ добавляется четвёртый шаг у директора, но таких заказов в примере немного, поэтому директор получает несколько уведомлений в неделю, а не десятки.

Что компания получила на практике, если оставить цифры за скобками. Статус заявки виден всем без звонков. Автор заявки не может сам её согласовать. Причина отказа записана в документе, и прораб читает её, а не гадает. История решений лежит в журнале документа, и через месяц можно ответить, кто и когда подтвердил закупку. А вот чего компания не получила: параллельного согласования и автоматического бота в мессенджере. Для восьми человек они и не понадобились.

Уроки этого примера пригодятся и вам. Сначала маршрут запускается на одном объекте и одном прорабе. Затем две недели собираются жалобы на форму заявки. Потом подключаются остальные. Порог суммы ставится по статистике, а не наугад. И обязательно проверяются три сценария отказа: возврат заявки, правка после частичного согласования и замена согласующего на время отпуска, когда роль должна быть назначена нескольким людям, чтобы маршрут не вставал из-за одного человека.

Чек-лист проверки маршрута перед запуском

Любой маршрут согласования я принимаю по короткому списку тестов, и вам советую то же самое. Это не формальность: большая часть проблем всплывает на третьем-четвёртом тесте, а не на «счастливом пути». Тесты проводятся на тестовом сайте под учётными записями реальных ролей, а не под администратором, потому что Administrator обходит часть ограничений и скрывает ошибки прав.

Список тестов по порядку. Прораб подаёт заявку по своему объекту и не видит чужие. Прораб пытается согласовать собственную заявку и не может. Руководитель согласует заявку до порога и после порога: во втором случае она уходит директору. Руководитель возвращает заявку с причиной, автор правит и подаёт снова. Снабженец формирует заказ только из согласованной заявки. В проведённом заказе меняется количество через Update Items. Бухгалтер получает заявку на оплату и согласует её по своему маршруту. На каждом шаге проверяется запись в истории документа.

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

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