ERPNext Foundation ERPNext Cloud User Manual Blog Discuss Frappé* Donate

Let Us Make ERPNext a professional workflow alternative for real business use cases, your ideas count


#1

The current workflow system is mainly built on the following 2 core concepts/mechanism

  • conditional state transition map, i.e state machine
  • assign user by fixed role defined per transition

for simple business case, this workflow system is simple enough and very powerful. but a lot of improvements needed in order to handle real world workflow in a multi business unit(BU) and multi company context, like this below typical purchase requisition workflow:

  1. Requester fill the basic requisition info,
    on header, choose the responsible buyer
    on item table, input item, description, qty, budget price, and select cost object

    system create workflow action for all cost object owners derived from items.

  2. cost object owner approves the request
    system only complete the workflow action if not the last approval, on the other hand if the last approval, create workflow action for buyer to do sourcing

  3. buyer input mandatory sourcing info such as vendor, price , tax etc
    system create workflow action for finance manager if amount <= 5000, otherwise create workflow action for purchase manager.

  4. finance manager approve,
    if amount <=5000, request is approved/released

  5. other further approval steps such as by purchase manager, operation manager and CFO needed if amount >5000.

To handle the above business case, at least the following improvements to the current workflow system needed

  1. support dynamic assign users based on selected user or role from the business document other than assign users by fixed role in workflow definition
  2. support multi user approval in parallel, e.g multi cost object owners who are linked to different items
  3. support delegate workflow for users on leave or on business trip
  4. support forward workflow to other colleague in case the requester selected wrong buyer, or the system assigned workflow handler decided to forward it to other person
  5. support adding additional checker( ad hoc pre-checker) to double check, then return back to the approver
  6. support dynamic field status per workflow state: mandatory, read only, hidden per workflow state, e.g make it mandatory to maintain sourcing info such vendor , price, tax for buyer.
  7. support multi workflow per doctype and common workflow cross multi doctypes, for example 2 separate workflows, 1 for simple service PR(purchase Requisition) and the other for assets PR, if only one workflow, it will make it too difficult to maintain. this feature need to also support workflow revision, in other word, instead of updating existing workflow, create new workflow (new revision) to be used by new documents, on-going old documents still follow the rules defined in the already assigned old workflow.
  8. Allow add comment for each workflow action, make comment as mandatory when Reject, also pass comment to workflow action
  9. Send email notification to document owner when workflow reached the final state/finished.

Compared to independent professional workflow platforms, ERPNext is more powerful on handling complicated form layout design and business logic via custom script and back-end ORM, if the above features added, ERPNext can be a good alternative workflow system?

any comments and further improvement ideas? any other business workflow business cases?


#2



#3

Design highlight

Modelling

  • Workflow Transition

Added following fields
Assign User Mode
Doc Field
User
Multi User Action Mode

  • Workflow Action

Added following fields
Action Source
Previous User
Actions

  • Workflow Field Status

Workflow
Workflow State
Field Status Detail

  • Workflow Field Status Detail

Doc Field
Mandatory
Read Only
Hidden

  • Workflow Assignment

Company
Document Type
Condition
Workflow

  • Delegation

Type
Delegator
Delegatee
Valid From
Valid To
Is Active

Business Logic-back end
workflow.doctype.workflow_action.workflow_action.py
create user action

  1. check the delegation table, replace the user if valid delegation record exist
  2. concatenate the possible actions by fields: action name, transition name and allow self approval into workflow actions field, e.g Approve:transition1:1

model.workflow.py

apply_workflow

  1. add parameter transition_name, use transition name instead of action to locate to the correct transition
  2. handle the 2 common actions: forward and add additional checker, complete the current workflow action, create new user action for the selected user, no transit to next state
  3. handle multi user parallel approve, if not the last approve, simply complete the workflow action without transit to the next state

desk.form.load.py

  1. get_docinfo : retrieve the current doc’s workflow

Business Logic - front end

form.workflow.js

  1. show help button based on whether there is open workflow actions, even if there is no actionable workflow actions for the current user, the help button should be available for user to check the current workflow status: who is the current approver.

  2. retrieve available open actions for the current user via get_user_actions( in stead of get_transition) to populate the action and help buttons accordingly

  3. in show actions, add the two common buttons: forward and add additional checker

  4. overwrite the field status per applicable workflow field status

model.workflow.js

  1. change all relevant methods’s input parameter from doctype to doc,

form.js

  1. change workflow relevant call parameter from doctype to doc

save.js

  1. change workflow relevant call parameter from doctype to doc

#4

pull request submitted https://github.com/frappe/frappe/pull/7866, please kindly show your support the PR by upvote or add comments/feedback.

Many thanks.


#5

To learn to upvote [Tutorial] How to upvote Github issues for non developers


#6

@szufisher, this is a great idea. I believe Frappe should be able to function as a business process manager tool in its own right. Just to extend the ideas in a few of the points you’ve raised:

  • It should also be possible to perform the dynamic assignment of users based on a custom table so that rather than hardcoding approval amounts within the workflow definition, approval ranges and the corresponding approval users can be specified in a custom table

  • docfield parameter specification should use the pattern used in other areas of the app e.g. doc.items[] or doc.items[1] and should allow for python expressions for more complicated lookups

Regards,
Chude


#7

PR is under review by core team, feedback and support from community is needed