Workflow в ERPNext без программирования: состояния, переходы, условия по сумме

Workflow в ERPNext настраивается без кода: в DocType Workflow вы описываете состояния (States), переходы (Transitions), роли и условия вроде doc.base_grand_total < 100000. Ниже порядок настройки, правила для отмены и правки проведённых документов и ловушки, на которых я видел сбои.

Из чего состоит Workflow в ERPNext: документ, состояния и переходы

Workflow в ERPNext — конечный автомат, который вы привязываете к одному типу документа, например к Purchase Order. У него три части: сам документ, набор состояний и набор переходов между ними. Состояние описывает, на каком этапе согласования документ находится сейчас: черновик, на согласовании, утверждён, отменён. Переход описывает, кто и каким действием переводит документ из одного состояния в другое. Для малой команды, которую я сопровождаю в проектах ERPNext под ключ, такой машины хватает на большинство сценариев согласования закупок, и программист для этого не нужен.

Настройка идёт через DocType Workflow. По исходникам Frappe версии 15 в нём есть поля Workflow Name, Document Type, Is Active, Don't Override Status, Send Email Alert и Workflow State Field. Поле Is Active важнее, чем кажется: по описанию в коде, при включении все остальные Workflow на этот же тип документа становятся неактивными, поэтому на один DocType одновременно работает только один маршрут. Workflow State Field по умолчанию называется workflow_state; если такого поля у документа нет, Frappe создаст скрытое пользовательское поле само.

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

Роли в Workflow не заменяют права на сам документ. Если у сотрудника в Role Permissions Manager нет Read и Write на заказ поставщику, то даже в переходе, где указана его роль, он ничего не сделает. Это распространённая причина жалоб «кнопки нет на экране». Прежде чем тестировать маршрут, откройте менеджер прав и проверьте, что у каждой участвующей роли есть базовый доступ к документу. Общая логика ролей описана и в материале про матрицу доступа, только там речь о 1С.

Как заполнить States: Doc Status и «Only Allow Edit For»

Таблица States (в исходниках — Workflow Document State) содержит на каждую строку состояние и несколько настроек. Главная из них — Doc Status с тремя значениями: 0 означает сохранённый черновик, 1 — проведённый документ, 2 — отменённый. Именно Doc Status определяет, какие действия система применит при переходе: сохранит документ, проведёт его или отменит. Роль в поле «Only Allow Edit For» (поле allow_edit) определяет, кто может править документ, пока он находится в этом состоянии. Остальные видят его только на чтение.

Для заказа поставщику в небольшой фирме я обычно завожу четыре состояния. «Draft» с Doc Status 0: редактирует снабженец, роль Purchase User. «Pending Approval» с Doc Status 0: править может только руководитель закупок, роль Purchase Manager. «Approved» с Doc Status 1: документ проведён и закрыт от правок. «Cancelled» с Doc Status 2: итоговое состояние отмены. Названия состояний и действий можно писать по-русски, они создаются как отдельные справочные записи (Workflow State, Workflow Action Master). Я оставляю английские имена, чтобы они совпадали с документацией и форумом, а на экране пользователя переводом занимается интерфейс.

Есть ещё несколько полезных настроек строки состояния. Update Field и Update Value позволяют при входе в состояние записать значение в поле документа, например проставить признак «утверждено». Флажок Is Optional State помечает необязательные ветки, для которых система не создаёт задачу в списке действий. А Don't Override Status на уровне состояния нужен для вопроса, который я разберу ниже: с активным Workflow системный статус документа в списке подменяется состоянием маршрута.

| Состояние | Doc Status | Only Allow Edit For | Что может делать пользователь | |---|---|---|---| | Draft | 0 | Purchase User | Править заказ, отправить на согласование | | Pending Approval | 0 | Purchase Manager | Править суммы, согласовать или вернуть | | Approved | 1 | (никто) | Только читать, печатать, создавать приход | | Cancelled | 2 | (никто) | Только читать | Таблица — рабочий пример, роли и названия подставьте свои. Состояние Doc Status 1 само по себе проводит документ, поэтому по нему сразу становятся доступны складские и финансовые документы. В проекте это решение нужно принимать осознанно: если согласование многоступенчатое, проводить заказ на промежуточном шаге опасно.

Как написать Transitions и условие по сумме без пересечений

Таблица Transitions задаёт связи: исходное состояние (State), действие (Action), следующее состояние (Next State) и роль в поле Allowed. Когда пользователь открывает документ, система показывает ему только те переходы, у которых исходное состояние совпадает с текущим, роль входит в список его ролей и условие истинно. Это видно в функции get_transitions исходников Frappe. Обычная кнопка Submit при активном Workflow заменяется выпадающим меню Actions, в котором лежат доступные действия.

Ветвление по сумме делается полем Condition. Это короткое выражение на Python, которое вычисляется с доступом к документу в переменной doc. В версии 15 (функция get_workflow_safe_globals) разрешены frappe.db.get_value и frappe.db.get_list, объект frappe.session и утилиты дат now_datetime, add_to_date и get_datetime. Для двух порогов согласования я пишу так:

# Согласовать (Purchase Manager): заказ до 100 000 в валюте компании
doc.base_grand_total < 100000

# Согласовать (Director): заказ от 100 000 и выше
doc.base_grand_total >= 100000

Ключевое правило: условия переходов из одного состояния обязаны быть взаимоисключающими. Если у одного перехода стоит «до 100 000 включительно», а у второго «до 500 000», руководитель с обеими ролями увидит две кнопки сразу, а заказ на 90 000 можно будет согласовать двумя путями. Границы должны сходиться впритык: один знак строго меньше, второй больше или равно.

Почему base_grand_total, а не grand_total. Поле grand_total хранит сумму в валюте документа, и при заказе в юанях сравнение с порогом в рублях даст бессмыслицу. Поле base_grand_total пересчитано в валюту компании, так что порог остаётся в рублях. Эту ловушку упоминает и наша глава базы знаний: простое doc.grand_total не учитывает мультивалютность без конвертации. Для строительной и отделочной компании, которая закупает у российских поставщиков, разница обычно не видна, но стоит убедиться на тестовом заказе в иностранной валюте.

Отдельный флажок Allow Self Approval на строке перехода касается авторства. В коде apply_workflow есть проверка: пользователь может применить действие, только если он Administrator, либо флажок включён, либо он не владелец документа. Важно: в v15 этот флажок у нового перехода включён по умолчанию, то есть создатель заказа может сам его согласовать, если у него есть нужная роль. Хотите запретить — снимите флажок на переходе, и система будет отвечать «Self approval is not allowed». Для компании на 11 человек, где директор сам вносит заказы, флажок на переходе директора оставляют включённым, иначе директор окажется заблокирован собственным маршрутом. Если вам нужен более общий подход к процессам согласования вне ERPNext, посмотрите материал про маршруты согласования договоров.

• Исходное состояние и Next State заданы, действие названо понятным глаголом.
• Роль в Allowed есть и у неё есть права Read и Write на документ.
• Условия из одного состояния не пересекаются и покрывают все суммы.
• Сравнение идёт по base_grand_total, то есть в валюте компании.
• Для отмены заведено состояние с Doc Status 2 и переход в него.

Почему с Workflow пропадают статусы Partially Ordered

Типичное недоумение после включения Workflow на Material Request или Purchase Order: в списках исчезли привычные статусы вроде Partially Ordered или To Receive and Bill, вместо них висит Pending Approval. Причина в том, что кастомный Workflow подменяет в списке системный статус значением поля workflow_state. В главе нашей базы знаний это названо одной из главных ловушек, а на форуме Frappe есть обсуждения жалоб на пропавший сквозной прогресс по цепочке закупок.

Тут есть два пути, и я выбираю между ними по задаче. Первый — не вешать Workflow на каждый документ цепочки. Согласование нужно на заявке или заказе, а приход и счёт обычно идут без маршрута, и их статусы остаются системными. Второй путь — настройка Don't Override Status. В исходниках Frappe это флажок override_status на самом Workflow, а также avoid_status_override на строке состояния, с описанием «Если отмечено, статус Workflow не заменит статус в списке». Заводить его на всех документах я не спешу: проверьте на своём стенде, что именно вернётся в список в вашей версии.

Практика такая: я отдаю прорабу и снабженцу один понятный статус на экране и не накладываю маршруты там, где в них нет необходимости. Если руководитель хочет видеть, на каком этапе заказ, достаточно списка с полем workflow_state и фильтра по нему. Для сквозного прогресса по закупке (заказано, принято, оплачено) я оставляю системные статусы нетронутыми на приходе и счёте. А на Material Request стандартные статусы Draft, Pending, Ordered, Received, Issued остаются нужными прорабу и без кастомного маршрута.

Как разрешить правку и отмену после проведения

Проведённый заказ с Workflow нельзя поправить так же, как без него. Кнопка «Update Items» на проведённом заказе поставщику при активном Workflow выдаёт «Insufficient Permissions», пока в маршруте нет перехода для правки. Об этом пишут на форуме Frappe в обсуждениях правки позиций после проведения. Объяснение следует из кода: переход между двумя состояниями с Doc Status 1 вызывает сохранение уже проведённого документа. Поэтому я добавляю отдельный переход из «Approved» в «Approved» с действием Update и ролью Purchase Manager. Проверьте на стенде, что в вашей версии кнопка работает после такого перехода.

Отмена устроена строже. В Workflow нужно завести состояние с Doc Status 2 и переход в него. Без этого отмена не сработает, даже если у роли есть право Cancel. Валидация в исходниках запрещает три вещи: менять состояние отменённого документа, переводить проведённый документ обратно в черновик и отменять документ, который ещё не проведён. То есть из Draft в Cancelled перехода быть не может, нужно сначала провести. Для отказа на стадии черновика вернитесь в статус «Rejected» с Doc Status 0.

После отмены документ можно исправить через Amend: система создаёт новый документ, к имени которого добавляется суффикс (например, PO-0001-1), а связи с приходами и счетами нужно проверять отдельно. Про корректировку проведённых документов у нас есть отдельный разбор в ветке статей про ERPNext, здесь же важно одно: если Workflow не умеет Update и Cancel, пользователи начинают просить права администратора, а это самый плохой исход для маршрута согласования.

И наконец, на промежуточном состоянии с Doc Status 1 действуют последствия проведения. Если вы решили провести заказ уже на шаге «Одобрено руководителем отдела» и ждёте ещё подпись директора, то подчинённые складские и финансовые документы будут доступны до финального утверждения. В главе по эксплуатации это названо решением, которое нужно принимать осознанно. Моё правило: Doc Status 1 ставлю только на последний шаг, а все промежуточные согласования держу в статусе 0.

Ещё пять ловушек: валюта, права, обязательные поля, импорт, параллельные согласования

Первая ловушка — обязательные поля. Если вы проверяете заполненность на стороне браузера через Client Script, то при переходе через меню Actions эта проверка может не остановить смену состояния. Надёжнее настраивать зависимую обязательность (Mandatory Depends On) на поле или писать проверку в условии перехода. Это замечание из главы по Workflow, я рекомендую проверить на стенде: оформите документ без обязательного поля и попробуйте согласовать.

Вторая ловушка — импорт данных. По коду validate_workflow, если документ создаётся не в первом состоянии, а сразу в другом (как при импорте), система отвечает «Workflow State transition not allowed». Поэтому исторические заказы лучше загружать до включения маршрута или с первым состоянием списка. Третья — изменение согласованного документа: в главе отмечено, что правка Material Request после согласования не сбрасывает состояние Workflow на начальное автоматически, и это стоит помнить, если у вас две подписи.

Четвёртая ловушка — оповещения. Флажок Send Email Alert на самом Workflow отправляет письма с возможными действиями, а на строке перехода есть «Send Email To Creator». Если почта сервера не настроена, согласующие не узнают о задаче. Проверьте это на этапе настройки: об отдельной настройке уведомлений можно прочитать в статьях ветки про ERPNext. Пятая ловушка — Is Active: включение нового Workflow отключает все прочие на этом DocType, поэтому тестовый вариант на рабочем сервере нужно делать на отдельном сайте.

Теперь об ограничениях, которые надо знать заранее. Workflow из коробки не умеет параллельное согласование несколькими людьми: это конечный автомат, у перехода роль задана заранее. Он не выбирает согласующего динамически из поля документа, например «руководитель проекта этого объекта». Для таких сценариев нужен серверный скрипт или другое решение, и малой команде обычно достаточно последовательной цепочки. Для тех, кто сравнивает подходы, есть альтернатива Authorization Rule, которая блокирует документ по порогу суммы без маршрута, но без кнопок и состояний.

Как «Чистовая Линия» собрала маршрут за вечер (условный пример)

Условный пример: фирма отделочных работ «Чистовая Линия», 11 рабочих мест. Закупками занимаются два человека, утверждает директор. Проблема была знакомой: счета поставщикам согласовывались перепиской, и о заказе на крупную сумму директор узнавал, когда материал уже ехал на объект. Задача — простой маршрут для Purchase Order: до 100 000 ₽ согласует руководитель закупок, от 100 000 ₽ — директор. Числа условные, пороги в вашей фирме будут другими.

Настройка заняла один вечер на тестовом сайте. Завели четыре состояния (Draft, Pending Approval, Approved, Cancelled) и шесть переходов: отправка на согласование, возврат на доработку, два согласования с условиями по base_grand_total, правка Update для Purchase Manager и отмена из Approved. На втором прогоне выяснилось, что руководитель закупок может согласовать заказ, который сам же завёл: флажок Allow Self Approval включён по умолчанию. Его сняли на переходе руководителя закупок, а на переходе директора оставили, потому что директор сам вносит часть заказов. Ещё поймали пересечение условий: сначала стояло «до 100 000 включительно» и «от 100 000», и заказ ровно на 100 000 показывал две кнопки.

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

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