purchse order - invoiced - wrong value used to compare

[Ferdinand]

invoiced shows only 86% -
Example
Order
* qty = 100
* price = 10
* subtotal = 1000

Picking = 100% received
* qty = 100
* price = 10
* subtotal = 1000

Invoice = 95% invoiced
* qty = 100
* price = 9,5
* subtotal = 950

IMHO also for "invoiced" the qty has to be used - not the final subtotal.

95% would be interpreted as 5% will still be invoiced - which is obviously not the case.

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Ferdinand,

We would like to know more about your aim in changing the price at Invoice(but not at PO).

If I am right, everywhere total has to be considered as its related to Invoice. If I get 100% amount as equal to what appears on PO, I set it as 100% invoiced. Isnt it?

If its a picking, qty has to be taken into consideration.

Please share your views.

Thanks.

[Ferdinand (office-chricar)]

It's not uncommon, that the price changes slightly between PO and Invoice - think of daily price adjustments - and we hopefully agree, that we have to take the invoice price in any case.

so it's possible to have a 100% qty delivered and a price/amount which is below or above (example 105%) of what was ordered
IMHO OpenERP just shows 95% or 100% but not 105% .

the text "Invoiced" together with 95% indicates somehow that not all qty ordered/delivered is invoiced, which may also happen.

I still think that if 100% qty is invoiced i'd like to to see 100% invoiced

nevertheless I agree it is very interesting to see price differences - but these should be called "Price difference" like -5% or +5% in the example above

[gpa(OpenERP) (gpa-openerp)]

Hello Manufacturing Expert,

Can you share your views?

Thanks.

[Ferdinand (office-chricar)]

And also accounting experts

[Dukai Gábor (gdukai)]

I agree with Ferdinand. In our case, the price is often adjusted in the invoice and the PO - invoice subtotals don't match.

[Grzegorz Grzelak (OpenGLOBE.pl) (grzegorz-og.pl)]

I also know businesses that PO or SO don't need much invoices and Picks (stock moves).

Partners can agree that prices can be changed everyday. Seller of course is publishing the prices (fe, in web or on phone call with small negotiations) so Purchaser knows them but he doesn't waste a time to enter them into system. You can imagine order sent without prices but with clause "according to current day pricelist". In such case in current OpenERP functionality purchase operator would have some "average" referential prices which he doesn't mind. So then he receives invoices with prices which don't match PO.

The same could be with quantities. Partners can cooperate that they send order every day and they don't mind differencies in deliveries. Only matching of picking with invoice is important.

Lets divide it to cases:

SO:

Prices - If you sale you have to have pricelist up to date (no excuse) otherwise system doesn't work. And invoices match SO. This case doesn't exist.

Quantities - So you received order from customer. You have agreement with customer that if you send only part of order he will not complain. You both agree to not waste a time for order confirmation. In current OpenERP functionality such order hangs with some fulfilment percentage.

PO:

Prices - it is the case Ferdinand showed. Let say you agree with Seller that you sent order without any confirmation and Seller call you only if prices are different. When prices are lower than you ordered Seller will not call you. In current OpenERP functionality we can imagine that you should leave PO as not confirmed and you confirm it yet when Seller call or invoice arrive. But you don't have confirmed incoming Picking for warehouse worker in such case.

Quantities - It is not important for your business that you don't receive one or two products from 100 ordered. Or you receive less than you expect. (fe. you will not waste a time for confirming order when it would be lack of one kind of cake when you have 80 kinds on shelfs). In current OpenERP functionality order hangs.

So we can imagine real business that partners don't want to confirm prices or quantities.

However I don't think system should show us performance bar as Ferdinand suggested. I can agree that it can change but after particular order human acceptance. I mean when operator see that he has old order with price or quantity difference he should be able to decide "this order is fulfiled as in current state". And after such intervention (button click probably) order can show 100% or maybe something more meaningful. Maybe special state (like "exceptional done"). Principle is that Pick moves quantities have to be equal to invoice quantities otherwise button shouldn't work. So button should remove or decrease confirmed moves from pick lists.

All workflow (Procurement orders?) should be closed accordingly. And later on we can design reports showing what was different. Prices ordered versus invoiced, and quantities ordered versus picked. Fe Even when we agree with our customer that we can send less products than ordered to him without confirmation we should know how much sale we have lost.

[Ferdinand (office-chricar)]

On Friday 16 April 2010 00:00:04 Grzegorz Grzelak (Cirrus.pl) wrote:
>
> Lets divide it to cases:
>
> SO:
>
> Prices - If you sale you have to have pricelist up to date (no excuse)
> otherwise system doesn't work. And invoices match SO. This case doesn't
> exist.
>
> Quantities - So you received order from customer. You have agreement
> with customer that if you send only part of order he will not complain.
> You both agree to not waste a time for order confirmation. In current
> OpenERP functionality such order hangs with some fulfilment percentage.

in some business (forestry, agriculture) it is common that the customer
determines quantity and quality and hence the price of the product - and this
sometimes some month after delivery.

--
regards
Ferdinand Gassauer
ChriCar Beteiligungs- und Beratungs- GmbH
Official OpenERP Partner

[Grzegorz Grzelak (OpenGLOBE.pl) (grzegorz-og.pl)]

Ok, so it means that case SO - not confirmed prices also exists.

After further consideration I vote that:
- picked performance bar should show data as now,
- invoiced performance bar should show data of invoiced quantity (not amount as now)
- it should be some indicator for price differences (no values just indicate that this order should be checked in detail)

And when picked is 100% and all picked quantity is invoiced the bar "invoiced" should show 100% and order should change to done (as Ferdinand expects).

But we still should have possibility to close order waiting for goods when less than 100% is picked and it is exceptional human decision to stop order at this stage. System should only check if all picked quantity is invoiced (wizard?)

Another consideration we should make for case that picking is exceptionally increased comparing to order (another wizard?)

I think such functionality will better cover real business. Do we agree?

[Husen Daudi (husendaudi)]

Hello All,

Some opinions.
When we confirm PO we have picking and we have 2 possibility to create invoice.
1> from picking
2> from PO.

In PO we have progress bar to check received qty. and generally we create invoice based on received qty.
As per Ferdinand's suggestion if we change invoiced progress bar based on qty. both received and invoiced will show same value when picking is completely done and invoice is created.
So invoiced bar based on price is useful to check price fluctuation or negotiation % on invoice.

Regards,
HDA

[Amit Parik (amit-parik)]

Hello, DR Ferdinand,

Thanks for your suggestion. It is not feasible to make it general the way you wanted the flow of invoices which are generated from SO and PO. So i am closing this bug for the sake of clarity in launchpad.

Thanks.