Regression on 5.0.7? packing and payment done but order stays "in progress"

[Ana Juaristi Olalde]

Hi:

With last bazaar version 5.0.7 Making picking does not change order status. Order stays always "in progress". Inside order "picked" checbox stays without check even if progress bar is showing %100 picked.

This functionality was working in 5.0.6

Thank you!!!

Ana

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello, Ana, I'm confused myself by those workflows and regressions or simple
changes. In that case I believe (not 100% sure) that I reported the
regression and actually Fabien told me the scheduler has now to be run to
change the order status:
https://bugs.launchpad.net/openobject-addons/+bug/491375

I found it weird as I explained but so be it if big boss told it. What
happens if you run the scheduler? You could also make it run automatically
 at a regular intervals. So what does running the scheduler?
Can you also confirm if that's a duplicate or not? What do you think

Thanks

On Mon, Feb 8, 2010 at 7:29 PM, Ana Juaristi Olalde <email address hidden>wrote:

> Public bug reported:
>
> Hi:
>
> With last bazaar version 5.0.7 Making picking does not change order
> status. Order stays always "in progress". Inside order "picked" checbox
> stays without check even if progress bar is showing %100 picked.
>
> This functionality was working in 5.0.6
>
> Thank you!!!
>
> Ana
>
> ** Affects: openobject-addons
> Importance: Undecided
> Status: New
>
> --
> Regression on 5.0.7? packing and payment done but order stays "in progress"
> https://bugs.launchpad.net/bugs/519034
> You received this bug notification because you are subscribed to
> OpenObject Addons.
>
> Status in OpenObject Addons Modules: New
>
> Bug description:
> Hi:
>
> With last bazaar version 5.0.7 Making picking does not change order status.
> Order stays always "in progress". Inside order "picked" checbox stays
> without check even if progress bar is showing %100 picked.
>
> This functionality was working in 5.0.6
>
> Thank you!!!
>
> Ana
>
>
>

[Ana Juaristi Olalde (ajuaristio)]

Hi Raphaël

I think scheduler should only be executed if company buys to_stock. In
companies where they by to_order scheduler has no sense.

Executing scheduler sometimes causes duplicated procurement orders and
confusing operative. This is the case:

Manufacturing company. They only make prototipes. Each piece is different
from another. They only buy materials for an specific manufacturing order.
They have only few materials, low cost they mantain a minimal stock, but
their warehouse is not plenty of materials.

So... Try this. Define a final product (stockable, produce, to_order),
define a list of materials with an unique material ( stockable, buy,
to_order).
Make a sales_order
confirm
A manufacturing order is created. Thats correct.
Confirm the order (sometimes if you have got JIT installed, order is
generated on confirmed status. I don't like it very much, because is
generating purchase orders automatically without having a chance to review
planified BOM materials, or something. Nevermind)
Confirming the order, DRAFT purchase orders are generated.
Now... RUN SCHEDULER
You will see that your purchase order is duplicated. Then take all purchase
orders to one supplier and merge them. If you don't review you could be
asking two times or three material you need. This is a big problem. I think
scheduler should review existing draft supplier orders including that
product and recalculate total needed quantity. It would be a wishlist. I
don't remember but I think I reported by now.

So I don't like scheduler very much. I don't like procurement to_stock like
it is by now because is just launching to time exception so many
procurements, it's more complicated managing like that, than making it
manually. This is also reported by now. No big problem for me until some of
my customer has got a really standar manufacturing and buy agains stock.
Most of them combine buy to_order + jit by now and this configuration is
working quite well.

But about regresion.. it's true. I don't understand very well this workflow
changes on an stable version. I could understand them better on a new
version where new functionality is added.

in the other side... some weeks ago, there was a point where even if you
made picking of bought materials, Manufacturing order didn't change status
to ready to produce but it was staying on waiting materials. The only way to
bring orders to correct status was running scheduler. Today, it is working
perfectly on stable 5.0.7 without executing scheduler.

Wishing this could help. Thank you

Ana

2010/2/8 Raphaël Valyi - http://www.akretion.com <email address hidden>

> Hello, Ana, I'm confused myself by those workflows and regressions or
> simple
> changes. In that case I believe (not 100% sure) that I reported the
> regression and actually Fabien told me the scheduler has now to be run to
> change the order status:
> https://bugs.launchpad.net/openobject-addons/+bug/491375
>
> I found it weird as I explained but so be it if big boss told it. What
> happens if you run the scheduler? You could also make it run automatically
> at a regular intervals. So what does running the scheduler?
> Can you also confirm if that's a duplicate or not? What ...

[Sharoon Thomas http://openlabs.co.in (sharoonthomas)]

Ana & Raphael,

Can you try this out:

Go through your products in the specific sale order lines and look for the one which does'nt get to the state done.
Then open the product and in 'Procurements & Locations' Tab(Page) open its production location or procurement location and ensure has the following parameter set:

Automatic Move : 'Automatic Move' (How dumb??? it should have been a check box or rename the field name)

I think this solved my issue, but unsure of it.

This is the stupid little code that fails the workflow:

if (not line.procurement_id) or (line.procurement_id.state=='done'):
    if line.state != 'done':
        write_done_ids.append(line.id)
    else:
        finished = False

And my guess is that the line.state never becpomes done because the move is never complete? May be wrong!

[Jan Verlaan (jan-verlaan)]

I agree with Ana, running the scheduler to mark a order as "picked" has no mean. The scheduler doesn't pick materials, right? The scheduler doesn't make a order finished.
In several cases you, like Ana mentioned, you don't want to run the scheduler. A other example is a trade company with 60000 constantly changing products. They don't use the scheduler function, but manual procurement due to the fact that they can not maintain the minimal stock records, that is mandatory to have for the scheduler.

i.m.h.o the scheduler should not be in charge of setting order statusses for order is picked and putting the order status from in progress to another state. That's to late, it should be done by a workflow action, like the picking itself.
Wherefore do have workflow actions? For executing triggers I thought, including user-permissions.

this is a regression and I can not understand that a change like this is not communicated as it seems that it is changed not by accident!
Imaging you have procedures defined in you company that are based on the picking and order status, e.g. for invoicing. If you are not aware of such a change you will run directly into problems. When one discovers this change, you have to change internal procedure.
At least you want to know upfront so new procedure could be implemented upfront.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Again enough people insist that behavior change is weired enough so I flag it for Tiny to re-consider it before releasing 5.0.7 even if Fabien said once it was the expected behavior https://bugs.launchpad.net/openobject-addons/+bug/491375

[gpa(OpenERP) (gpa-openerp)]

Hello Ana,

1. Would you apply this patch for the your problem "Showing %100 picked."?
And notify us.

2. And for the second problem "SCHEDULER You will see that your purchase order is duplicated" I think it is invalid
Would you check this again?

Thanks

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

Hello Guys,

Here is an improved version of the patch.

Thanks.

[Ana Juaristi Olalde (ajuaristio)]

Hi everybody:

I tried the patch and it's not working for me.

Here they are the test cases I tried

1. Create a sales order with products procurement to_stock with enough stock to serve. Confirm order and pack the created packing list. Create manually the invoice from order with button, confirm invoice --> Order shows packing 100% and invoice 100% but status is "in progress". Related procurement is "done".

2. Create a sales order with products procurement to_stock without enough stock to serve. Confirm order and pack the created packing list forcing disposability. Again the same. Order status is "in progress", it is never set to done or finished.

I only tested the improved pack from Jay 31-03-2010

Thank you very much:

Ana

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

Hello Ana,

1. I wonder how it shows packing and invoice 100% ? Invoice is yet to be paid and packing is yet to be done. Check again please.

2. Here the packing is done, but not its related procurement/prodution order. Once they are comlpeted, picking will be shown 100%. SO state will be changed only when the invoice is paid. so, logically the order is Completed.

Tell me if we have gone wrong here.

Thanks.

[Ana Juaristi Olalde (ajuaristio)]

Hi Jay:

It has been my fault!! Sorry for inconvenience. You are totally right. I made packing but I didn't pay the invoice.

After paying, after make picking, the checkbox picked on order is set to true, after paying the checkbox paid on order is set to true and the order status is set to done, so patch it's working correctly.

Thank you very much!!

Ana

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

Thank you for the feedback Ana.
We appreciate your interest.
It has been fixed by revision 2695 <email address hidden>.
Thanks.