Stock in output location is incorrect with backorder

[Eric Caudal - www.elico-corp.com]

How to reproduce:
I create an sales order of 500 pieces with automatique step between output and customer location.
If I ship only 200 pieces, the backorder of 300 is created in the correct state, and an delivery note is created for 200 pieces from stock to output in done state (which allw invoicing). So far so good.

Problem is the output picking of 200 from output to customer is not created at that moment and the goods still appear in the output location, whereas physically there are not there anymore.

All final moves from output to customer locations are only done when all backorders are processed or cancelled, which can takes weeks or months.

In the meantime our stock in output location is not correct.

[Kirti Savalia(OpenERP) (ksa-openerp)]

Hello,

 I have checked the problem and found that it is wrong configuration.
 set the chaining type "Automatic No Step Added" instead of "Automatic Move".
 Can you please share your views and explain more about it.

Thanks and waiting for your reply!

[Eric Caudal - www.elico-corp.com (elicoidal)]

I do not want "Automatic No Step Added", I want "Automatic Move". I
want to be able to trace both moves internal and outgoing.

openerp

*Eric CAUDAL*, CEO
<email address hidden> <mailto:<email address hidden>>
Cell: + 86 186 2136 1670
*Elico Corp - OpenERP Ready Partner, Shanghai.*
http://www.openerp.net.cn

[Numérigraphe (numerigraphe)]

Confirming because Eric answered.

[qdp (OpenERP) (qdp)]

Hello Eric,

sorry but i'm not able to reproduce your bug. I've tried with "automatic no step added": i can see that the picking of 200 is created from stock to customer, so the stock in output is correct. I've tried also with "automatic move", there are 3 stock moves in total
* 200 from stock to output (done)
* 300 from stock to output (ready)
* 500 from ouput to customer (waiting)

according to me, this is not an abnormal situation although it could be addressed in a future version to ease the process (currently, if you want to resolve this 'exceptional case' you can split manually the move of 500 into 200 and 300, then check availability and deliver the move ready). I set this bug as whislist for our potential further roadmap.

thanks for you understanding,
Quentin

[Eric Caudal - www.elico-corp.com (elicoidal)]

Hi Quentin,
Thanks for your reply. I dont know if this is a bug or a limitation due
to current design but whatever you call it, the virtual stock is
incorrect even in your simple case: if you have still 500 from output
to customer when only 200 have been sent, your stock must be wrong.

Besides, this impact directly your procurement calculation which is as
well wrong. So you can call it "wishlist" to get rid of an annoying bug
that you cannot solve right away but this is definitively a bug and a
very annoying one.

Remarks:
- This is particularly annoying when I have to tell the customer in OPW
that this is not a bug when figures are obviously wrong.
- We cannot split the PO as the original order is 5oo and it is
referenced by the supplier for future backorder: this is completely
unrealistic on a business point of view (each order have a hundred line
that you should recalculate manually).
- You have the same problem for your POs arriving at input location
through chained locations.
- And finally I have to disagree with you as this case is not
exceptional when you deal with backorder, all the contrary.

Correct behavior should be after shipping 200 out of 500:

* 200 from stock to output (done) To be Invoiced
* 300 from stock to output (ready) To be Invoiced
* 200 from ouput to customer (done) Not applicable

* 300 from ouput to customer (waiting) Not applicable
In this case your real and virtual stock are correct and your
procurement calculation is correct

We are developing the functionality by ourself and if we get to a stable
solution, we will publish it in the community.

openerp

*Eric CAUDAL*, CEO
<email address hidden> <mailto:<email address hidden>>
Cell: + 86 186 2136 1670
*Elico Corp - OpenERP Ready Partner, Shanghai.*
http://www.openerp.net.cn

[qdp (OpenERP) (qdp)]

Hi again Eric,

to be more specific, here is where i disagree with you: "(...) the virtual stock is incorrect even in your simple case: if you have still 500 from output to customer when only 200 have been sent, your stock must be wrong.(...)" This is _not_ what you've done in OpenERP. You didn't deliver partially to your customer here, you just deliver partially to your _output_. So your further explanations are corrects but based on a wrong axiom.

Let suppose the following situation: your customer bought 2 products, but you can only move a product at a time from your stock to your output (where the trucks get loaded). So you partially deliver your first product. Should your truck already deliver this to the client? Are you sure it shouldn't wait for the second one to be delivered to the output location? Maybe in your case, where all products aren't available, yes. But in other companies you will agree that this may not be the case.

Finally let me say that i agree on the fact that it may not be easy to treat manually (depending on the frequency, nb of lines...). If you can propose a patch for that for the trunk, be sure that it would be welcome.

Quentin

[Eric Caudal - www.elico-corp.com (elicoidal)]

Hi again,
Your example indeed is a good one which is not my business case indeed:
we may have to think about a different chaining method on top of the
manual/automatic/automatic no step added. Something like "back-to-back
deliveries".
In arriving POs (which is actually in our case more important), I do not
see how to apply your example though: goods are only partially arrived
in our warehouse and accounted for the full quantity in our input location.
Eric

[Numérigraphe (numerigraphe)]

Another subtle problem with partial deliveries. Would you please mark this as "Opinion" so we can keep tracking progress?
Lionel Sausin

[Eric Caudal - www.elico-corp.com (elicoidal)]

Actually, we have corrected this bug for our customers.
We havenot yet released the module open source because it is still
under surveillance in production phase and it implies a regression (you
cannot use anymore old behavior).
Adding this functionality (true back-to-back orders) would imply to
refactor the whole stock logic about backorders workflow which we
initially did not intend to. It could be though interesting to add this
functionality on top of existing one in core module as I think it is a
basic one but that we need a heavy work that I am not sure OpenERP SA is
willing to start at the Eve of a release...

openerp

*Eric CAUDAL*, CEO
<email address hidden> <mailto:<email address hidden>>
Cell: + 86 186 2136 1670. Skype: elico.corp
*Elico Corp - OpenERP Ready Partner, Shanghai.*
http://www.openerp.net.cn

[Numérigraphe (numerigraphe)]

That looks like an good topic for a workshop during the community days.
Lionel Sausin.