Split Stock move breaks the destination moves logic logic

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

How to reproduce the bug
Context: have pull flow generating a 2 moves, linked together via move_dest_id field.
Create a stock picking with one move (quantity =10)
Split one stock move with new serial number
In the stock picking now there are 2 SM with same product and same move_dest_id and complementary quantities (7+3)
When processing the quantity in full, the second move in move_dest_id is still in waiting for another move

It seems due to the following code in stock/stock.py (action_done around line 2400):

            if move.move_dest_id.id and (move.state != 'done'):
                # Downstream move should only be triggered if this move is the last pending upstream move
                other_upstream_move_ids = self.search(cr, uid, [('id','!=',move.id),('state','not in',['done','cancel']),
                                            ('move_dest_id','=',move.move_dest_id.id)], context=context)
                if not other_upstream_move_ids:
                    self.write(cr, uid, [move.id], {'move_history_ids': [(4, move.move_dest_id.id)]})
                    if move.move_dest_id.state in ('waiting', 'confirmed'):
                        self.force_assign(cr, uid, [move.move_dest_id.id], context=context)
                        if move.move_dest_id.picking_id:
                            wf_service.trg_write(uid, 'stock.picking', move.move_dest_id.picking_id.id, cr)
                        if move.move_dest_id.auto_validate:
                            self.action_done(cr, uid, [move.move_dest_id.id], context=context)

The first move will always find the second move as other_upstream_move_ids and the last one as well so condition "not other_upstream_move_ids" never happens (as the moves are sent as done later on, outside the for loop)

[Rifakat Husen (OpenERP) (rha-openerp)]

Hi,

I have fixed it in, lp:~openerp-dev/openobject-addons/7.0-opw-603094-rha
Revision 9782, <email address hidden>

Please let me know if you face any problem. I will mark this bug report as Fixed Committed.

Regards,
Rifakat

[开阖软件 Jeff Wang (jeff.osbzr.com)]

Please merge this fix as soon as possible, I face the same problem in my client's production database.

User need 2 steps delivery, so I set the output location as chain mode "manually "

Then when a new sales order been confirmed, 2 picking generated, the first one is a internal picking , then chained to an delivery order.

When user transfer the internal picking, everybody see the product on Output location, but the delivery order keep on waiting.
Click on "Check Availableb" Button returns an error message 'Not enough stock, unable to reserve the products.'

With this patch, chained delivery order can be set as "Ready" right after the internal picking is Done.

I still do not understand why only moves on "confirmed" state is been check,why not check "waiting" state also. (stock/stock.py )

    def action_assign(self, cr, uid, ids, *args):
        """ Changes state of picking to available if all moves are confirmed.
        @return: True
        """
        wf_service = netsvc.LocalService("workflow")
        for pick in self.browse(cr, uid, ids):
            if pick.state == 'draft':
                wf_service.trg_validate(uid, 'stock.picking', pick.id, 'button_confirm', cr)
            move_ids = [x.id for x in pick.move_lines if x.state == 'confirmed'] <-------- don't you think we should add "or x.state=='waiting' " ?
            if not move_ids:
                raise osv.except_osv(_('Warning!'),_('Not enough stock, unable to reserve the products.'))
            self.pool.get('stock.move').action_assign(cr, uid, move_ids)
        return True

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

It has been fixed by OPW actually
Eric CAUDAL

Eric Caudal

On 04/09/2014 02:45 PM, 开阖软件 Jeff Wang wrote:
> Please merge this fix as soon as possible, I face the same problem in my
> client's production database.
>
> User need 2 steps delivery, so I set the output location as chain mode
> "manually"
>
> Then when a new sales order been confirmed, 2 picking generated, the
> first one is a internal picking , then chained to an delivery order.
>
> When user transfer the internal picking, everybody see the product on Output location, but the delivery order keep on waiting.
> Click on "Check Availableb" Button returns an error message 'Not enough stock, unable to reserve the products.'
>
> With this patch, chained delivery order can be set as "Ready" right
> after the internal picking is Done.
>
> I still do not understand why only moves on "confirmed" state is been
> check,why not check "waiting" state also. (stock/stock.py )
>
> def action_assign(self, cr, uid, ids, *args):
> """ Changes state of picking to available if all moves are confirmed.
> @return: True
> """
> wf_service = netsvc.LocalService("workflow")
> for pick in self.browse(cr, uid, ids):
> if pick.state == 'draft':
> wf_service.trg_validate(uid, 'stock.picking', pick.id, 'button_confirm', cr)
> move_ids = [x.id for x in pick.move_lines if x.state == 'confirmed'] <-------- don't you think we should add "or x.state=='waiting' " ?
> if not move_ids:
> raise osv.except_osv(_('Warning!'),_('Not enough stock, unable to reserve the products.'))
> self.pool.get('stock.move').action_assign(cr, uid, move_ids)
> return True
>

[Leonardo Donelli (learts92)]

@Eric Caudal:
Are you sure? I have the addons at the latest revision (10082) and that part of the code is still identical and the bug is not fixed.

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

Hi Leonardo,
I am not sure about the bugfixing from Odoo into core but we
definitively received a bug fixing here:

https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-opw-603094-rha/+merge/203273

Hope this helps
Eric CAUDAL

Eric Caudal
/CEO/

On 07/09/2014 04:16 PM, Leonardo Donelli wrote:
> @Eric Caudal:
> Are you sure? I have the addons at the latest revision (10082) and that part of the code is still identical and the bug is not fixed.
>

[Lionel Sausin - Initiatives/Numérigraphe (ls-initiatives)]

Has this been fixed ?

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

Yes long time ago
Eric CAUDAL

Eric Caudal
On 11/29/2014 12:26 AM, Lionel Sausin - Numérigraphe wrote:

> Has this been fixed ?
>