Order Policy: 'postpaid' or 'Invoice on Order After Delivery' is missing

any news ?

It has been removed in this merge proposal: https://code.launchpad.net/~openerp-dev/openobject-addons/trunk-simplify_picking_invoice-sgo/+merge/96071

More precisely in the revision: http://bazaar.launchpad.net/~openerp-dev/openobject-addons/trunk-simplify_picking_invoice-sgo/revision/6656

It is not stated why it has been removed, except the following sentence in the merge proposal:
"2. Remove one selection postpaid which is no longer use. and also remove all postpaid related code demo data and yml file."

Which is obviously wrong, just ask to the OpenERP partners who is using this policy.

Hi OpenERP Team can you give us some feedback on this issue?
Indeed for e-commerce is the standard process for the customer, removing it and telling "it's no longer use" should be only an april fool's ! I still can not believe you remove it.

Please what do you plan to do? This kind of change are really scary and are really problematic for e-commerce projet !

Thanks for giving us some feedback ASAP. We need it for selling projet on V7, don't forget our customer is your customer too. In the futur you should not remove this kind of feature without asking the community.

Completely agree to Guewen and Sébastien - can't believe who's telling that it is not needed anymore.

Please add it as fast as possible again.

I agree with Felix, Guewen and Sébastien, I don't like this kind of changes without any previous communication. This is costing us always alot of time to find out an also now again Guewen had to dive into the code to check !

The nearest we can come was to check in the settings (accounting)

Create and open the invoice when the user finish a delivery order

But it is starting always a wizard, and that's not the same behavior the old users are used to.

Peter

> The nearest we can come was to check in the settings (accounting)
>
> Create and open the invoice when the user finish a delivery order

And that's not the same thing because it will create the invoice based on the delivery order, while the interest of postpaid was to create the invoice from the sale order, after the delivery.

Here is a copy of the answer I got from the OPW (I just kept the interesting part for this report).

> I have discussed this issue with R&D Belgium and following are the reasons for removal of this option:
> 1). The removed option "Invoice on Order After Delivery"(invoice after delivery based on sale order) was considered as advanced, not the most common, and possibly confusing.
> 2). Functionally speaking, it does nothing more than the option "Deliver and invoice on demand", anyway it requires a manual operation to create the invoice.
> Hence it was removed for OpenERP 7.0. However we can achieve this by using the "deliver first, and invoice on demand". And the person in charge of invoicing regularly tracks sale orders that have been fully delivered and not invoiced yet, and creates the invoices from there.

I don't know if it's clear for you., i jsut wanted to emphasize on:
1) it's still easily feasible by another way, there is no loss of feature
2) it simplifies the usability and the code not to consider that option as a fourth possibility of the invoicing policy.

Moreover, if you want to invoice after your deliveries but based on the sale order, it means that the guy who push the button to invoice is not the delivery man. It's thus more appropriate to have this option in the salesman application.

For your information, i removed the dead code and corrected the process related to the sale order in order to reflect our position on this point.

Thank you guys for your implication
Quentin

Hi Quentin, thanks for your answer on that topic.

Actually, the thing which is clear for me is that you removed the 'postpaid' order policy.

The things which is absolutely not clear is when you say:
"1) it's still easily feasible by another way, there is no loss of feature"
So I would be glad to know what is this other way (or do you really consider that creating them manually is an option?)

When you say:
"Moreover, if you want to invoice after your deliveries but based on the sale order, it means that the guy who push the button to invoice is not the delivery man. It's thus more appropriate to have this option in the salesman application."
When I read you saying that, it make me feel that you do actually do not know what the 'postpaid' order policy was doing. Using this order policy, there was no button to push on the delivery order (nor the sale order) to create the invoice, the invoice was automatically created when the delivery order was finished. So this option was definitely part of the salesman application and should still be. And that's the lost feature, the invoice is no longer created automatically, you need to create it manually (or again I would be glad to have your solution to do so if you are sure that there is no loss of feature).
(By the way in that spirit, when we are said that the responsible of invoices should search the sales orders to invoices and create the invoices manually, I could say that the accountant guy have to go the salesman application...)

Just kidding, if you really want to simplify the code, there are many places in OpenERP where you can do it without killing features.

Thanks,
Guewen

+1

I think it should be mandatory for developers that work with OpenERP that they do 5 days no development, but WORK with the program as a warehouse user / as a accountant (wooooo) as a manufacturing user and putting all the orders in ... I think they have enough inspiration for some months and OpenERP would become even better then it already is :-)

"there was no button to push on the delivery order (nor the sale order) to create the invoice, the invoice was automatically created when the delivery order was finished. "

Peter

Hello Guys.

I am almost very sorry with this kind of things, Simplify IS NOT take off features, please, Stop to do that....

100% of my customers use this feature.

The Scenario:

Sale Order 1 January,

1000 elements (products)

Shipping policy (In Notes)
You will send me 100 element for the next 10 months.
You will pay me every 3 month, but Just the Sent Goods.

Then......

Month 1 Sent 100
Month 2 Sent 100
Month 3 Sent 150 (because in the last month something logistically change)

Invoice people, go in them process of verify What is still pending to Invoice.

- He/She Go to Shipping pending to invoice.
- Make a quick Filter.
- Invoice them.

Now with the answer that qdp is giving.

- He/She Go to Shipping pending to invoice.
- Make a quick Filter.
- Count how much was delivered.
- Go to Sale Order.
- Make the invoice per line.
Stop... You need to go to Picking to verify How much did you sent....
- You review... verify... and ..... sorry i have a line of 1000 and the invoice need to ve corrected...
- Open The invoice.... Correct the quantity...
Stop... How much was sent?
- /
/ / / / / / / / /

Is it REALLY an useability improvement?????????????///

Sorry dudes you are becoming OpenERP in an Open??? because an ERP will not be anymore, if you continue taking off "Advanced features" this is an ERP for God Sake!!!!!!!

Hi there,

Just wanna say that I completely agree with Guewen. Taking of this feature isn't a simplification at all, but a real loss. I mean, you can't just decide to remove a workflow like this.

We (I mean the community here) build lot of thing based on that option that seems widely used. Please, take our concern into account here !

Thanks,

Joël

Hi again,

i see, and swear i understand your concern, that this decision is really making a shield rise among the community. I do not say that you're wrong and that we, almighty R&D, know better than you what you need. I'm just explaining what led us to the conclusion that this feature was not really needed and implied a bunch of code that could be full of doubtful operation (what if the procurement of one line was cancelled? what if the deliver was partial? what if an advance invoice was made before? what if the sale order also implied a service line? were all these cases also taken into account?...).

But maybe we were wrong, and we are open to review our judgment. We just need to understand what is your need behind this feature. In what real business case would you invoice after the delivery _based_ on your sale order rather on what you really delivered?

Note that we also add a filter and a menuitem that gives you what was already delivered and thus should be invoiced...

Thanks for keeping a constructive discussion, guys :-)

Thanks for being willing to reconsider this.

The invoice was created when the sale order was 'shipped'. The advance invoices were not allowed with this order policy. It was working fine and there was no much code. (roughly https://code.launchpad.net/~openerp-dev/openobject-addons/trunk-simplify_picking_invoice-sgo + http://bazaar.launchpad.net/~openerp/openobject-addons/7.0/revision/8973)

Use case: e-commerce (and it appears that OpenERP want to do its own e-commerce module, so will you anyway reintroduce it in 2 versions?)

 - A customer creates a sale order on the e-shop (service + products)
 - Delivery
 - Generate automatically the invoice from the sale order when the delivery orders are shipped, why?
    * invoicing from the delivery order would not include the service products!
    * invoicing from the delivery order would generate 2 invoices if there is 2 deliveries, but due to constraints with e-commerce e-shops, we want only 1 invoice for the whole sale order
    * the invoice needs to have the exact same amount than the sale order, whatever being actually sent to be consistent with the e-commerce sale order.

Now why do we want the invoice after delivery?
Because we still want to send the invoice (per letter or per mail) to the customer only when we have actually delivered him.
And we don't want to invoice him while we cannot deliver all the products.
And sometimes, the stock guys need to change a product in a delivery order, it has to be reflected in the invoice, but the final price should not change, so the invoice should be generated only after the delivery (the replacement of products here is done manually or with specific / community modules).

The point is :
 1. You agree that sometimes we need to invoice after the delivery.
 2. You agree that sometimes we need to create an invoice which is based on the quotation, because the quotation needs to be respected.
 3. But you think that we don't need to create an invoice based on a quotation after the delivery.
 4. And it appears that this is a common need at least for e-commerce.

Optional question:
How will the migration handle this type of change?

If I may chime in, the notion of "delivered sale order" is also subject to caution if the warehouse is configured with a manual chained move to Customer on the Out location. See https://bugs.launchpad.net/openobject-addons/+bug/1080617 for more on this.

On a side note, I want to precise that my intention is not to be harsh, and
I am really willing to have a constructive discussion. I could also
considerate a solution on our own side, just wondering if this option had
really nothing to do in OpenERP.

However, when you see such a shield rise, as you say, of the community, ask
yourself why. I think there is a huge frustration when such decision are
taken arbitrarily without any discussion with the community. You have an
ocean of knowledge and don't benefit from it.

No discussions before the changes but furthermore no communication after
them so the community ends up by discovering them one by one, searching an
other way to do the same thing, grep-ing the bzr logs to search hints, and
finally discovering despitely the loss of the feature.

This story repeats and repeats and that is a loss of time for everyone, you
and the community.

At least, a nice thing would be to maintain a (technical) changelog (not
the big doc with marketing details). (there have already been a discussion
on a change log for schema changes).

A simple line "removed the 'postpaid' order policy" would have help us.

By the way, I take the opportunity to say that some education needs to be
done in the commits messages, a message like "simplifies the order policies
as per needed" is totally unhelpful. That's also a reason why we have to
leave no stones unturned to figure out what happens.

Guewen

Regarding my last email, that's not a flame about OpenERP, I know that you
are all hard working with much efforts, but take it as an improvement
suggestion.

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 ...

Oups, I did not finish my comment.

So, v7 did the required clean up:

  - clean the invoicing method based on order to handle all use cases properly
  - deprecate the postpaid method that overlapped and did not handle most business use cases

But we miss one feature to invoice automatically.

  - if option 1/ works, it's ok
  - if not, I would suggest to do a merge proposal to implement option 2/

Thanks for taking the time to explain the reasons of the removal and to
propose solutions.
I will consider them next week and will give my feedback.
An other solution could be to integrate an automatism in the connectors
(magentoerpconnect, prestashoperpconnect) if the need is very specific to
sales orders imported from theses shops.

hi all,

Imagine you have a customer wich sale product with phantom BoM and compute product price with formula (like custom product Height, weight, etc...).

You have to invoice based on sale order because sum of component does reflect product price and the customer can decide to invoice after shipping.

So what is the good parameter to use in openerp V7.

I mean that postpaid method was good in 6.1.

We have no possibility to make it in V7.

thanks for your reply

stephane