Community mailing list archives
Re: Sale and purchase workflowby
Fabien Pinckaers (fp)
Simple example: we used to have action_done on sales orders that we could overwrite when an order was fully delivered and invoiced, now how could we trigger on that event programatically (not using inefficient automated actions)?
Good example: on a workflow, you can extend: action_done, invoiced, received, sent. That's it! You have basically ~4 hooks you can extend, nothing more. That's not what I call extensible. We often need to extend on much more complex events than this.
Automated actions are as inefficient as workflows: they both evaluate a status at every write on the document. But the difference is that Automated Actions allows an unlimited way to hook yourself. (and performance is still better than workflows) You can even hook on 'temporal events', example: Is still in "To Invoice" state after 3 months after validation of SO.
And the action is much easier since you just change fields, you don't need to sync the workflow and put it in a consistent state.
I also think it's better if you can extend programatically. (which is, by the way, against a workflow approach whereas it's the workflow that should trigger the code and not the other way around --> even if we often had to do it the other way around because workflows were too constraining)
There are several approaches to hook in the code. Use the one that fits your use case:
- extend on the action, not the event (easy if you want to change the behaviour of an action, just a method to overwrite)
- extend on the recompute of the computed field (easy if you want to trigger something new on a change: e.g. if the invoice_status changed, just a method to overwrite)
- extend on write/create (not super clean, but basically the same than what the workflow was doing)
- extend the trigger of the change of the computed field (extend @depends)
Since the status of the document is defined by computed fields, you have more consistencies guarantees. Whereas with workflows, you continuously have to sync both the fields and the workflow to stay in a consistent state. (which is a mess when developing, and painful to debug). --> You have an unnecessary redundancy between the values of the fields (state,. ..) and the state of the workflow.
From any point of view (document consistency, extensibility, ease of development, ease of customization without development), I don't see a single advantage of using workflows for sale & purchase.
For other needs, workflow may be interesting. But sale & purchase are too advanced to be managed by a single workflow.