Community mailing list archives

community@mail.odoo.com

Re: Sale and purchase workflow

by
Elmatica AS, Luis Alberto Panozzo
- 09/16/2015 11:17:20
As a user who had considered migrating to V9 in due time (accounting being such a change as it is) and now seeing this less-than-trivial modification a couple of weeks before going live with my sales roll-out, I simply can not believe this has been done without extensive consultation with the community. 
Yes, Odoo SA is the "owner" of the Odoo ERP but one of its main strengths is the community behind it. Yes, you own the ball but in order to have a game, you need the rest of the team to be there.
Having such Odoo heavyweights issuing less than fantastic opinions as I have seen in this thread really gives me pause.
Pedro, Nhomar, Ana, Wouter and many more are expressing different levels of concern.  That should NOT be there had this been done in a more consensual way. 

Is that Odoo 9 Documentation spreadsheet the extent of the documentation that will be available regarding this issue??????

In a certain way I feel that high-sounding statements notwithstanding, the end-users have been left out of the equation. This may eventually be great for Odoo and partners to sell more service. But what level of reliability is there if every year I need to start almost a-new on my ERP will all the changes chipped in and no clear migration path?

Please enlighten me and tell me our decision to deploy Odoo was a sound one that will not require bottomless pockets.


Luis Panozzo (Lp)
Technology Manager
Elmatica AS
luis.panozzo@elmatica.com
Skype: luispanozzo

On 16 September 2015 at 14:52, Fabien Pinckaers <fp@odoo.com> wrote:

We are in version 7 here. I can agree that the workflow has created an issue. Though, once tweaked and trained for the staff, it isn't so bad. Am I right in saying that in 9, it allows up to "done" status to edit the order? Presume this is adjustable? I wouldn't want people here tweaking a sales order after delivery, but before invoicing.


It's more subtle than that.

- Shipped Quantities: can only be changed if it's a service whereas the delivery is tracked manually. Otherwise, it's computed (from delivery orders or timesheets) and you can not modify it.

- Ordered Quantities: freezed when it's done. (you can mark as done when you want or even set an automated action that "set done" every order when it's confirmed, the v7/v8 behaviour). The quantities can only be changed from the "Sales Order" menu, not the "Quotation" one. Usually sales people work in the quotation menu, not sales order. So, they should not make changes "by mistake". (you can even make the menu accessible to managers only if you want)

Note 1: changing Ordered quantities may not have an impact on the invoicing. As an example, if you sell physical goods, you probably invoice based on delivered quantities. In this case, the ordered quantity (the only field you can update) has no impact on the invoicing.

Note 2: for the price, the price can not be changed once the line has been partially invoiced (it's per line). But you can add some lines, or set their quantities to 0. (if you want to make a price change)

If you want the exact same behaviour than v7/v8 (not being able to change anything), you just need to set the order_lines in readonly, through the view editor.

This seems like the correct direction, certainly from my older 7 experience. I have yet to had chance to play with version 9, but I presume the customisation via the web front end "developer mode" is still available in 9?

Yes.

 

-- 
Fabien



On 16/09/15 06:47, Fabien Pinckaers wrote:
<blockquote cite="mid:CANRftau828E6ynruB7FSmKBX2WTWopJZQ2oegFzEFTYiTzOjFA@mail.gmail.com" type="cite">

Hello,

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.

In short, we did a huge cleanup of the sale.* and purchase.* modules while porting them to the new API. The result in 5000 lines of code removed, for more features supported, and no feature removed.

Why?

The v8 sale module had a lot of issues:

- not possible to modify a sale order (open orders)
- no way to handle inter-company invoicing based on delivery/receptions (only one of the two invoices was generated)
- not possible to invoice kits based on deliveries
- too many different ways to incoice customers: based on sale order, based on sale order lines, based on support contracts, based on regular contracts, based on expenses, based on delivery orders, final invoice on timesheets, ...
- those different invoice methods could not be mixed in a single sale order (sell physical products with a support contract on timesheets)
- some of these invoicing methods were very complex to configure: to invoice on timesheet, you had to: 1/ create a SO, 2/ create a contract, 3/ set a product on the employee form, 4/ set the analytic_user_function to know to role of the user, 5/ invoice from the contract...
- contracts (based on analytic accounts) are a pain. They are complex to understand (support contracts vs regular contracts) and to manage on a regular basis. (e.g. How do you make a quotation for a new support contract?)

*How?*

Complete rewrite the sale and purchase modules. We cleaned all the legacy code while porting everything to the new API. The net result is 5000 lines of python code removed. Less lines of code for more features is a good sign of something that is technically clean.

*What are the main changes?*

In addition to the quantity ordered field on sale order lines, you have three new fields: Qty Delivered, Qty Invoiced, Qty to Invoice. Qty delivered can be set manually (milestones of a project you invoice manually) or computed based on timesheets or delivery orders. The two others fields are always computed.

The product has a new field "Invoice Method": based on quantities ordered, based on quantities delivered (could be timesheets), based on time and material (reinvoice costs or expenses).

So, whatever the products/services, you always generate invoices based on sales order. All other methods disappeared, you can do everything from the sale order.

The meaning of "Done" in sales order in different. In v8, done means "delivered and invoiced". In v9, done means "you can not change the order anymore". Delivered and Invoiced are written on SO lines, not in the status.

We removed the workflow because it was a mess. For example, in version 8, the "state" field was used for the SO state (quotation --> sale order) as well as the invoice state and delivery state (done=delivered and invoiced). We splitted this in several computed fields:

  - State: Quotation --> Sent  --> Sale Order
  - Invoice State: Nothing to Invoice, To Invoice, Fully Invoiced, Upselling Opportunity
  - Delivered: quantities are set on SO lines

More over, as the user can edit the SO at any step, workflows were not useful anymore. It's also much faster now.

*What are the improvements?*

Compared to v8, all complex use cases work perfectly in v9:

- single point of invoicing: sale order --> super easy
- you can mix any kind of services and invoice everything at once from the sale order: pre-paid support contract, project invoiced on milestones, physical products, extra travel and expenses, etc.
- the system manages upselling opportunities (when delivered quantities > ordered quantities). Example: you sell a support contract of 25h, when you arrive at 30h on timesheets, the sale order switch to "Upselling Opportunity"
- inter-company rules with invoice for both the supplier and the customer, based on delivered quantities
- invoice kits, based on delivered quantities
- handle correctly unit of measures: sell a support contract by "Pack 40h", work by hours in your timesheets
- modify a confirmed SO: it will handle delivery and invoicing correctly
change prices on a confirmed SO: some lines are readonly or not based on what have already been invoiced
- more efficient management of deposits
- 3 ways to track services: manually (set milestones as done), timesheet on contract (the v8 method), timesheets on tasks
- correctly handle the right product when a user do timesheet (defined by the SO line): you can work as a senior developer or on a support contract --> no need for analytic_user_function anymore

What about purchases?

We also reviewed purchase orders with a similar concept (Qty delivered, Qty invoiced) In v8, you had three methods to generate draft invoices: based on PO, based on PO lines, based on receptions. It's much easier in version 9, there are 0 methods :)

We don't pre-generate draft invoices anymore, but you can select POs when you create a vendor bill: it will fill all invoice lines automatically based on what can be invoiced (received products or services).

No more problem of merge, partial invoices, control of quantities if received in several steps, ...



It's very difficult to explain such a huge change in just a small email.

So I hope this small email helps,

You can get more information in the documentation, some docs have been updated to the new process (check the sale tab): https://docs.google.com/spreadsheets/d/12Xg70FiWQH0LJXsRWVNDO1TwQbhPvV4UFm2UdAAHPrQ/edit#gid=576547174

Thanks,

-- 
Fabien

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe