'delivery orders': after processing partial state stays 'available'

Bug #782080 reported by Steffi Frank (Bremskerl, DE)
32
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Confirmed
Low
OpenERP Publisher's Warranty Team

Bug Description

6.0

addons revno 4578 (merge)
server revno 3422
client-web revno 4605

steps to reproduce
- create sales order with product 'to produce' and 'MTO', confirm
- MO: start production
- MO: produce partial qty
- Delivery orders: you find the OUT/123 for SOxxxxx in state 'available' (correct)
- process, but change qty to produced qty, validate
- you find a new picking.list in state 'done' with partial qty (correct)
- the original picking.list OUT/123 stays in state 'available' (which now is wrong)

summary: - partial delivery in 'delivery orders': state stays 'available'
+ 'delivery orders': after processing partial state stays 'available'
Amit Parik (amit-parik)
Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
importance: Undecided → Low
status: New → Confirmed
Changed in openobject-addons:
status: Confirmed → In Progress
Changed in openobject-addons:
status: In Progress → Confirmed
Changed in openobject-addons:
status: Confirmed → In Progress
Changed in openobject-addons:
status: In Progress → Confirmed
Revision history for this message
Steffi Frank (Bremskerl, DE) (steffi-frank) wrote :

hm... I'm afraid I don't understand this swapping between confirmed and in progress - could anybody explain?

Revision history for this message
Thibault Delavallée (OpenERP) (tde-openerp) wrote :

Hello,

The flow has been updated since the bug and the DO state seems now to be correctly handled. Could you please check if your bug can still be reproduced with the current version ?

Best regards,

Thibault Delavallée.

Changed in openobject-addons:
importance: Low → Undecided
status: Confirmed → New
importance: Undecided → Low
Revision history for this message
Numérigraphe (numerigraphe) wrote :

I don't think this bug is related to manufacturing at all. You will encouter the same bug when doing partial delivery as soon as the move line is marked "available" (consumable products for example).

Steffi Frank, in your example I don't think the stock move should have been marked "available" in the first place, because the desired quantity is, well, not produced so not available. You should file another bug report for that.

Lionel.

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

I'm not toot sure if this bug is valid or not.
The problem boils down to: what should we do when goods were assigned but not delivered? Should we release them and let the scheduler assign them to other stock moves? Or should we keep the goods assigned, that is reseved for future delivery?

Experts, could you please share your opinions ?
Lionel Sausin.

tags: added: delivery partial
Revision history for this message
Numérigraphe (numerigraphe) wrote :

For sales delivery, our own opinion is that the assignment shoudl be kept. Say you assigned quantity 10000 for a sale order but the truck is full that day and you can only send 80000: you don't want the remaining 20000 others to be sent to another customer.

For purchase receptions, I think the assignment can be kept too for the sake of simplicity.

That is of course considering that moves only get "assigned" in due conditions, that is you don't force assignment or hit a bug in another module.

Lionel.

tags: added: partial-delivery
removed: delivery partial
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello,

I still faced the same problem, that's why I am again setting this bug as a "Confirmed" state.

Thank you!

Changed in openobject-addons:
status: New → Confirmed
tags: added: ocb-stock-v1
Changed in openobject-addons:
assignee: OpenERP R&D Addons Team 2 (openerp-dev-addons2) → OpenERP Publisher's Warranty Team (openerp-opw)
tags: added: maintenance
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers