Last back orders does not generate proper OUT delivery note

Bug #856159 reported by Eric Caudal - www.elico-corp.com
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
New
Medium
OpenERP R&D Addons Team 2

Bug Description

How to reproduce in V6.
I create an order product 1 for 100 pces. Invoicing on delivery, partial picking allowed.
Output location is linked to Customer with Automatic Move.
When I confirm the SO, 2 documents are generated:
- INT708 =100 pces
- OUT150=100pcs , which is logical

I process the INT708 for 30 Pces =>
INT708 = 70 pces
OUT150=100 pces
OUT151=30 pces

I process again the INT708 for 30 Pces =>
INT708 = 40 pces
OUT150=100 pces
OUT151=30 pces
OUT152=30 pces

I process again the INT708 for 40 Pces=>
INT708 = 40 pces
OUT150=100 pces
OUT151=30 pces
OUT152=30 pces

So in total, I have
- one OUT150 for 100 pces,
- one OUT151 for 30 pces
- one OUT152 for 30 pces

 but I do not have one OUT for 40 pcs and I have one INT707 for 40 pcs which should be 100.

This is very annoying to control the deliveries and invoice properly.

Revision history for this message
Eric Caudal - www.elico-corp.com (elicoidal) wrote :

Actually we should end with the following:
INT708 = 0 pces (Not applicable)
OUT150=0 pces (Not Applicable)
OUT151=30 pces (To be invoiced)
OUT152=30 pces (To be invoiced)
OUT153=40 pces (To be invoiced) NEW Document

This would much more reasonable/understandable and easy to use by the users.

Amit Parik (amit-parik)
Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
importance: Undecided → Medium
status: New → Confirmed
Changed in openobject-addons:
status: Confirmed → In Progress
Revision history for this message
Kirti Savalia(OpenERP) (ksa-openerp) wrote :

Hello,
I have checked your issue But I am not able to get your point exactly.also I don't get your point about INT707, is this generated by the same SO or created manually? (as I see picking generated from sale are INT708, OUT150)
So would you please elaborate with more information on this.
I have attached video for more reference.
Thanks and waiting for your reply!

Changed in openobject-addons:
status: In Progress → Incomplete
Revision history for this message
Eric Caudal - www.elico-corp.com (elicoidal) wrote : Re: [Bug 856159] Re: Last back orders does not generate proper OUT delivery note

All those documents are generated automatically by the system, no manual
creation.
Your test works fine indeed: I will have to investigate more...
BR
Eric

Revision history for this message
Rucha (Open ERP) (rpa-openerp) wrote :

Hello Eric,

From comment #3, I am closing this bug for now,
there are still chances to make it open if you can provide more steps and configuration,
Don't hesitate to reopen if something is wrong with current behaviour,

Thanks for your response!

Changed in openobject-addons:
status: Incomplete → Invalid
Revision history for this message
Eric Caudal - www.elico-corp.com (elicoidal) wrote :

Hi,
I am not sure you understood my point properly (or I was not clear enough...).
If we have 3 deliveries and one transfer from the stock, we should have the following result:
INT => stock to output = 100

OUT => output to Customer =30
OUT => output to Customer =30
OUT => output to Customer =40
And be able to invoice from those 3 OUT documents.

This is not what the system is currently doing because we have the following:
INT708 = 40 pces
OUT150=100 pces
OUT151=30 pces
OUT152=30 pces

Which is what you get in your video (and what I test in demo.openerp.com) and this is incorrect.

Revision history for this message
Numérigraphe (numerigraphe) wrote :

Marking this as "new" again according to last comment.

Changed in openobject-addons:
status: Invalid → New
tags: added: partial-delivery
tags: added: chained-location
tags: added: ocb-stock-v1
no longer affects: ocb-addons
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.