Community mailing list archives
Re: Sale and purchase workflowby
Jordi Ballester Alomar
On Wed, Sep 16, 2015 at 10:03 AM, Fabien Pinckaers <firstname.lastname@example.org> wrote:
> A lot of people are asking more information about the changes in sale > and purchase apps in Odoo 9, mostly the removal of the workflow. [...] > Compared to v8, all complex use cases work perfectly in v9: I find this point of view to be very self centered, and not taking the position of partners and integrators into account. Removing workflows and replacing state fields by computed fields is harmful for us. I am currently struggling with this in v8 already where a similar change was applied to stock.pickings.You miss the main point. The biggest design issue of sale.order was not workflow or not workflow. The main issue was that v8 tried to store the state of the sale document in a single "state" field. That's why we had strange states like "progress" vs "manual", "shipping except", ... (which was a design decision that came from the fact it is supported by a workflow)
By unbundling the status of a document from the workflow and state field, into orthogonal concepts, it's way cleaner:
I agree with Fabien here. I need to test deeply, buy seems to be a change for the better. Sticking a state to a sales or purchase order was simply a great error. In my previous experience handling Purchases and Sales with SAP, this "orthogonal concepts" approach was used. And it led to way more flexibility! IMHO we need to make sure that this solution is extensible.
- Invoice State: to invoice, fully invoiced, to upsell, nothing to invoice yet- Delivered State, per so line: to deliver, delivered- Order State: quotation, sent, sale orderAnd every transition is possible on all these dimensions, it's not just a linear workflow. (even if it's already invoiced, it can become "to invoice" again, ...)One could argue that we could have created three workflows for the sale order (or two for SO, one for SO lines); that way we keep the workflow while building around orthogonal concepts. But that would be a huge mess too.Workflows are good to define a path, but since we allow to edit sales order, there are no path anymore. (something that is fully delivered can become "to deliver" again) Most community modules that extend sale.order are big hacks (think about: modify a sale order, ...) mostly because the v8 implementation was unflexible, because of the workflow complexity.I understand this is a huge change for you. But if it's cleaner and easier in the core, it will also be cleaner in your own module. I am sure that most your community modules will be 2x shorter on v9 sales because of these cleanups. (actually, most of them will not even be necessary anymore)So, this will probably be a good proof that it's a good "technical" move. (and not only a good functional move)Why is this a problem: integrators have to integrate Odoo inside a customer's infrastructure. This often means performing actions at some given points in time. For instance, sending a message over the ESB when a picking is fully available, or when it has been done, and there are many more examples related to SO / PO. Replacing a workflow which provides us with easy extension points with a computed function means that we have to write some complex code essentially duplicating the computed function.Overwriting a function to trigger actions if not more complex than overwriting a workflow. And overwriting a computed fields "like To Invoice or To Deliver" is way easier than revamping a workflow to adapt to all possible transitions on all states.I agree that 5kloc less should be a good thing. I'm doubtful about "more features supported and no features removed".As usual, I recommend you to test the new solution deeply.If it's much cleaner in the core, it will also be much cleaner for you and your modules. Just try to port one of your module, you will be surprised how easy it is compared to v8.Thanks,--Fabien