Comment 18 for bug 1160835

We removed this option for 3 reasons;

  1/ because it was confusing for users and usually led to a wrong use of it
  2/ because it was not "functionally" correct
  3/ for useability reasons, it's the same feature than manual invoices

More details:

1/ Confusing and led to a wrong use of it.

Companies selling physical products usually invoice based on delivery, not on order.
If I buy 5 books to amazon and they deliver me only 3, they will invoice me 3 books, not 5!

Please note that invoicing based on delivery orders allow to:
  - add extra services in the invoice
  - group several delivery orders in one invoice (or not, it's an option)
  - manage advance invoice,
  - manage delivery cancellations or extra quantities delivered.

2/ Because it was not functionnally correct in v6.1

This method led to a lot of incorrect invoicing scenario, e.g.:

   - A customer order 5 products, the company delivers 3 and cancels the backorder.
     An invoice is sent for 5 products, which is not legal!
   - A customer order 5 products, a procurement was cancelled (e.g. I cancel a purchase order),
     An invoice is sent even if we did not deliver the products, it's illegal too!
   - A customer order 5 products, I deliver 3 and I will deliver the 2 others in 3 months
     It was just impossible to invoice the 3 products with the v6.1 approach, even with a manual operation

3/ Useability issue

We noticed a lot of problems with "Invoice based on order after delievry" because, as soon as you confirmed your sales order, the user did not had any control over the process later, if there are exceptions in the delivery. It's important to be able to control the process manually in case of exceptions in the delivery.

You can do the same process with "Manual invoicing based on sales order":
  - filter on orders that have been delivered but not invoiced
  - trigger invoicing for all these orders

But it's much better:
  - it handles advance invoices
  - it allow invoicing a few lines or items and the balance at the end
  - you can control manually the invoicing in case of any exception (partial delivery, ...)

So, I guess it was a good idea to remove duplicated code and rely on only one method that works for all business cases rather than two methods doing the same thing but one that was broken in several scenarii.

The only advantage of postpaid was that it created the invoice automatically.

3 solutions, by order of preference:

Option 1/ I did not tested it, but if you go to the menu "order lines to invoice", you can create all invoices for every line that has been delivered in one action. It should work in v7 natively. This is what most ecommerce should do:
      - you invoice based on sales order, not delivery orders
      - you invoice all orders at once, when it's delivered
      - you can manage all exceptions (partial delivery, cancelled deliveries, ...)

Option 2/ Add a filter "orders to invoice" on sales order. Add a wizard to invoice all selected orders automatically --> it just calls the "invoice whole order" on every selected order. This reflects exactly what 'postpaid' was doing (it's just 2 clicks before reviewing all draft invoices) but it's not the way companies work in the real life (they need to be able to invoice only 3 products on 5 and cancel 2 products, or deliver and invoice two later)

Option 3/ On sales order, add a checkbox for manual invoice "trigger invoicing automatically when all lines have been delivered."

As a summary:

1/ the way to produce the invoice (based on order / based on deliveries) should be independant from the fact that it's triggered automatically or manually. We should have only one code to invoice based on order and one to invoice based on deliveries.
2/ we needed to deprecate postpaid: wrong in several scenarii, feature overlap with manual
3/ manual invoicing from order is a much better alternative as it handles all use cases efficiently
3/ there 3 alternatives to produce automatically invoice based on orders

My 2 cents;

Now, as qsp