[5.0] SO not marked picked when 2nd delivery canceled

[Numérigraphe]

When we make a partial delivery for a sale order, OpenERP will create a 2nd picking.
If we cancel this picking, the sale order shows as 100% picked in the sale, which is correct.
However the box "picked" on the sale order form remains unchecked, when it should be checked.

Example : with demo data:
- take the packing for SO0005
- confirm the packing with 3 PC2s instead of 4
- cancel the second packing which gets created for this order

[Jan Verlaan (jan-verlaan)]

There is more wrong with partial delivery.
Have product in stock for 3 pieces and create sale order for 4 pieces.
Do the picking -> check availability => not enough material, status will not change => OK
Split line in 3 pcs => second line is created for 1 PCS in state "Available" => NOK should be status Confirmed!
Resulting in that the sales order status "picked" = 100% which is not the case.

Now I can manually cancel the availability back to status "Confirmed" for this 1 PCS picking line and next check availability will not process => OK is correct.
But the sales order will stay at status 100% picked, which is still incorrect. => NOK should be 75%

[Jan Verlaan (jan-verlaan)]

forgot to add that the sales order is in status "Done" => NOK should be in status "In process" as order is not finished yet.

[Jan Verlaan (jan-verlaan)]

SOLUTION for the split order line and their line status.
Change in /addons/stock/wizard/wizard_partial_picking.py row 161

        if data['form']['move%s' % move.id] <> 0:
            new_obj = move_obj.copy(cr, uid, move.id,
                {
                    'product_qty' : data['form']['move%s' % move.id],
                    'product_uos_qty':data['form']['move%s' % move.id],
                    'picking_id' : new_picking,
==> 'state': 'assigned',
                    'state': 'draft',
                    'move_dest_id': False,
                    'price_unit': move.price_unit,
                })
to
        if data['form']['move%s' % move.id] <> 0:
            new_obj = move_obj.copy(cr, uid, move.id,
                {
                    'product_qty' : data['form']['move%s' % move.id],
                    'product_uos_qty':data['form']['move%s' % move.id],
                    'picking_id' : new_picking,
==> 'state': 'draft',
                    'move_dest_id': False,
                    'price_unit': move.price_unit,
                })

No solution yet for the sales order status, which is still 100% picked => NOK

[Jan Verlaan (jan-verlaan)]

Regarding the Sales Order Status, when I manually set directly into the table sale_order the field state to "progress" and field shipped to FALSE, the correct progressbar status is displayed and I can process the sales order further without problems.
Only have to find out which code is the root of this problem.

[Numérigraphe (numerigraphe)]

Could you please have a look at this bug ? It may be related to #401801.

[Numérigraphe (numerigraphe)]

So we have a problem with partial delivery whether we make it by splitting lines or by confirming the packing, is that it ?

[Husen Daudi (husendaudi)]

How about this patch?
=== modified file 'sale/sale.py'
--- sale/sale.py 2009-05-15 15:17:59 +0000
+++ sale/sale.py 2009-07-21 11:16:10 +0000
@@ -100,8 +100,8 @@
                 p.sale_id in ('''+','.join(map(str,ids))+''')
             GROUP BY m.state, p.sale_id''')
         for oid,nbr,state in cr.fetchall():
- if state=='cancel':
- continue
+# if state=='cancel':
+# continue
             if state=='done':
                 res[oid][0] += nbr or 0.0
                 res[oid][1] += nbr or 0.0

If I make SO of 10 pcs and pick 5 pices. It will show 50% picking.
Now I am canceling other picking of 5 pcs.
It will show 50% picking because we made So of 10 pcs and pick 5 only.
so It should be shown 50%. Is it correct?

[Jan Verlaan (jan-verlaan)]

As in my opinion this is correct, hda. If no pickinglines are to be processed anymore due to the fact that 1 picking line is cancelled, order should be be set to status "Finished" with 50%.

But herewith we do still have a problem with splitting the lines.
When split the status of the splitted lines is now set to "Available" for both lines, while there is no inventory for the second line.
In my opinion this should be status "Confirmed" => See my patch proposal.

While testing I found that the SO status is set based on the LAST picking line. If the last pickingline is processed the SO status is set to "Done" regardless if the previous pickingline is NOT processed yet.
This is wrong. The status should be based on a check for all picking lines.
But here I can't find yet the problem in source code. Perhaps you know where to look?

[Numérigraphe (numerigraphe)]

I don't mind the order showing 100% picked. Actually it makes sense in our case - we cancel the 2nd packing when the customer would refuse the delivery. In that sense, the order is completely shipped indeed.
What we need however is the box "order picked" to be checked on the sale order, so that it doesn't show up in the list of current orders.

[Numérigraphe (numerigraphe)]

Jan Verlaan: I'm not sure your problem is the same as described in this bug. If it's not, could you please file a separate bug so that we can get both of them fixed ?

[Husen Daudi (husendaudi)]

 Numérigraphe :
Picked progress bar shows how much % goods are picked (Done) compare to actual sale order.
so count cancel is logical according to me.
Likewise If I create SO of 10 pcs and make invoice of 5pcs only then it will show 50% invoiced.

Jan:
I have 5 pcs in stock and I have picking of 10pcs.
Now I split line in 5 + 5 = 10 so i have 2 lines in picking.
so both must be available because I can pick any of the line.

case 2: when you split line it will just copy the state too.
means it its in draft state all split lines have state draft and same for confirm,available and done.

[Jan Verlaan (jan-verlaan)]

While debugging, we found a logical error that couses this error and the behavior Numérigraphe describes.

In stock.py def check_assign function _product_reserve is called for each picking line.
This function doesn't reserve anything, but is checking only the quantities in stock.
When picking line is splitted (same product) the first line checks with result ok and as nothing is updated in stock the second line will find the same stock quantities as the first line, but the first line should consume already.
When the total check for all lines is done, the database transaction is prepared and the stock updated. To late in this case.

We are programming now a solution for this, with extra functionality that will show the actual inventory when we want to split picking lines as proposal for user. There is some optimizing needed here as mentioned already in source code at def _product_reserve.

[Numérigraphe (numerigraphe)]

Jan Verlaan: we don't split lines ourselves, we just cancel packings. Does cancelling a packing make it silently split lines ?

[Jeroen van der Waal (jeroenvdwaal)]

Hi,

I am happy to provide this patch that fixes the problem described in entry #11/#12. The function _product_reserve in not reserving anything! Instead of doing a reservation, it just checks if it is possible to move the number of products from one location to another.

Therefore, I changed the name into something more appropriate, _product_available_test()

The main solution is just making the move-status 'assigned' when the assignment can be issued according to _product_available_test(). This status is very important, the algorithm for calculating available stock uses the move-status.

For short a test scenario:
- create order for one single produkt for which there are 10 items in stock (product A)
- in the order make one single order line for 20 items of product A
- confirm order
- go to outgoing products
- use the check availability button
- items can not be delivered, because the stock is too low.
- split the deliver into 10 / 10
- again use the check availability button
- one part is now available, the other not

Before this patch, both moves where marked as being available. As a result of this bug, a negative stock was possible. In some older documentation, this bug (tiny 4.X) is also described. So this patch may also solve for 4.X this problem

Kind regards,

Jeroen van der Waal
Gebar, The Netherlands

[Jan Verlaan (jan-verlaan)]

@ Numérigraphe, cancelling a package does not make silently a split.
But Jeroen and I are investigating the total flow with all possibilties regarding picking, partial picking, splitting lines and the responding status/progressbar in sales orders and invoices.
As we can see in source code, several solutions to different problems are tried to be solved in such a way that the total logic is lost. Several scenario's we have from real business are not programmed at all, resulting in wrong status of picking lines and sales orders.

We try to provide a patch that will cover all scenario's we can imaging, including yours. But it take some time to program/rewrite the solutions for the problems we have found and testing all the scenario's.
When the patch is delivered back to the community (in this treat) we hope (and guess) it will be incorporated in standard. You are more then welcome to give your feedback so we can make this part working too.

[Numérigraphe (numerigraphe)]

Thank you for your involvement. I'll be happy to give you feedback.

[Numérigraphe (numerigraphe)]

I also noticed that when I make a partial delivery, the wizard creates a new packing with all the products actualy sent, and leaves the products not shipped on the original picking.

I really expected the other way round and this is disturbing for our users because it means the packing they have actually processed has changed reference.

Would you like me to file a separate bug concerning this remark ?
Lionel.

[Jan Verlaan (jan-verlaan)]

There is a lot to be done here :-(
When cancel is used for the last picking line left to process, the "done" state will never be reached. There is no direct line in the workflow.

Also when have a manual transition from stock to out location (set at location record) to get a two step process for outgoing goods, all problems will start again for the outgoing deliveries. We have to dive further in this process.
Keep in touch.......

[Numérigraphe (numerigraphe)]

Jan Verlaan: thanks for investigating.
The problem seems complex, and unfortunately I have no time to look into it myself for the moment.
I filed a support request to Tiny using our support contract, I hope they can help resolve the issues:

<<
Explain your problem:
We filed a bug report concerning partial deliveries on https://bugs.launchpad.net/openobject-addons/+bug/399817
Jan Verlaan (Veritos) has joined the discussion and pointed to various weak points in the process. His lastest comment is "There is a lot to be done here".
So please have a look a this bug, and please do get in touch with Jan Verlaan as soon as possible.
>>

<<
Other commencts:
Partial deliveries are crucial to our business. To sum up our need, we make invoices from the packings, on quantities shipped. Most of our customers accept partial deliveries, but some refuse to get the missing products later and just want the second delivery canceled.
So, we need to be able to :
- make partial packing and have a second packing created. The order must NOT show as "picked" until the second packing is done.
- make partial packing and cancel the second packing. The order must show as "picked".
>>

[Jeroen van der Waal (jeroenvdwaal)]

For our customer we fixed partial deliveries, concerning the normal flow. Still work has to be done, but it is acceptable for our customer. More work is needed in the near future, so we like to continue fixing more of the problems.

Major problem within the current implementation is that many of the status-check-functions are not written to handle partial deliveries. So we improved the return status for some of the check functions. Because of that the workflow started to become acting as expected.

With the fixes attached the normal flow will work ok. A delivery can be splitted up in two or more partial deliveries. Also single order lines can be splitted up in two seperate lines.

While fixing the bugs stated in this launchpad entry, we discovered another bug when doing partial deliveries: a partial delivery picked, appeared in Stock Management->Delivery Order with quantities of the whole order instead of the the partial packed goods. So we currently do not use Delivery Orders, but we handle Outgoing Products as products being send.

Currently cancel is still not operable. Of course cancel a not yet splitted order works fine (as it did already), but cancel of a partial delivery is still not ok. The workflow hangs in a certain state which it should not be in(??). We need to investigate this more. For now, if a partial delivery is canceled, we use deliver and immediately returning the goods as a workaround.

I like to thank Jan Verlaan for testing and fixing some of the bugs. Also like to thank the firm Gebar in the Netherlands for supporting us create these fixes.

Kind regards,

Jeroen van der Waal
Gebar, the Netherlands

[Jan Verlaan (jan-verlaan)]

@pso, any update on this bugtracker? Can you apply the provided patch in comment 20? We are almost a month further and nothing has happened to incorporate this provided patch as far as we can see from outside.

[Numérigraphe (numerigraphe)]

The patch doesn't apply cleanly on the latest 5.0 addons. Could you please update it ?
Lionel

[Jan Verlaan (jan-verlaan)]

How longer the quality team will wait to adopt the patch, the more risk there is that the base code is changed and the patch needs rework.
Secondly the risk is there that the change in code base is solving only 1 bug, where we tried to solve a business process!

I'm a little bit disappointed that it takes so long to have an answer from the quality team if this patch will be incorporated or not. I think it solves a very important business process where partial pickings, cancellations and order-statuses are involved.

[Husen Daudi (husendaudi)]

Hello Jan and Jeroen,
Patch has been applied on stable addons revision : 2389 <email address hidden>
Sorry for late reply.
Still partiall delivery cancellation problem exist. We have to find some way out for that.

Thanks for the patch.

[Numérigraphe (numerigraphe)]

I just went through the instructions in the original bug report with a fresh demo DB, and unfortunately I found that the result is not better in the latest v5.0 addons (<email address hidden>).

Here is a PDF of the workflow instances on the order SO0005 after canceling the 2nd pickign. Notice how is has TWO active workflow instances. Is that supposed to happen ?

In case it may help you, I'm also going to attach a screen capture of the SO form and list views.

[Numérigraphe (numerigraphe)]

Screen capture of the order form. Please notice how "Picked" is not checked event though the list view shows "100% picked"

[Numérigraphe (numerigraphe)]

Please notice how the list view shows "100% picked".

[Numérigraphe (numerigraphe)]

This may be related to Bug #423726 "Picked boolean field ticked wrongly in sales order".

[Numérigraphe (numerigraphe)]

FYI this bug is not fxed by the patch proposed for Bug #423726.

[Numérigraphe (numerigraphe)]

I wrote a unit test scenario to demonstrate this bug: http://bazaar.launchpad.net/~numerigraphe/openobject-addons/unittest-5.0/annotate/head%3A/sale/test/bug399817.xml

[Vinay Rana (OpenERP) (vra-openerp)]

Hello guys,

Looking at the criticalness of the problem, it really needed some time to work for the solution.

However, we have chosen one solution and applied the patch here.

More options are still open, but concentrating 5.0.8 , this solution looks promising.

Would you please apply it and check?

Talking technically, the problem was that only on DONE packing, we were calling end of packing to Sale Order.

We still want a clear view for progress bar.
SO contains 10 products, 2 pickings: 1 is with 7 -DONE, 2nd is with 3 qty-Cancelled.
Progress bar should show 100%*as its all done) OR OR OR 70%(as 7/10 is really picked)?

Many thanks for your patience and responses.

Queries Invited.

[Numérigraphe (numerigraphe)]

vra (openerp) a écrit :
> We still want a clear view for progress bar.
> SO contains 10 products, 2 pickings: 1 is with 7 -DONE, 2nd is with 3 qty-Cancelled.
> Progress bar should show 100%*as its all done) OR OR OR 70%(as 7/10 is really picked)?
IMHO it should show 100%: the second packing is cancelled so no more
shipping is expected.
In our business we often have cutomers who refuse the second delivery,
and they do consider the order closed.
I find it convenient to use the partial packing wizard and be able to
cancel the second packing later on.
Lionel.

[Numérigraphe (numerigraphe)]

The patch you proposed does pass the xml test I proposed. I think it's fine.
For my own education, what does it fix in sale/sale.py?
Lionel.

[Ana Juaristi Olalde (ajuaristio)]

My 2 cents:
> SO contains 10 products, 2 pickings: 1 is with 7 -DONE, 2nd is with 3 qty-Cancelled.
> Progress bar should show 100%*as its all done) OR OR OR 70%(as 7/10 is really picked)?
I Agree with numerigraphe. We also have customers working like that. You send some goods and customer says it's enough and he does not wait for second delivery, so if you cancel second pack, order should appair 100% delivered. If you really need sending second pack, you will not cancel it.

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

Hello Lionel,

I correct the patch that, only stock/stock.py needs to be changed.

Earlier, we marched towards making the SHIPPED field, functional field and thus, they were few signs.

The correct patch has to be only of stock/stock.py.

Thank you to all for your patience and remarks.

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

I correct, its sale/stock.py.

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

It has been fixed by revision 2657 <email address hidden>.
Thanks.

[Vinay Rana (OpenERP) (vra-openerp)]

It has been fixed in trunk already.

Thanks.

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

Hello Satheesh,

Would you explain why was the status set to 'committed', has the bug generated again?

Please provide specific information.

Thanks.