[5.0 and 6.0] location_id wrong in stock.picking 'IN'

[Sebastien LANGE - http://www.Syleam.fr]

1. Install stock_location module
2. Open HDD1 product and go to "Logistics Flows" tab and add a new "Pushed Flow" with :
 - Source location : Stock
 - Destination location : Shelf 1
 - Automatic move : Automatic No Step Added
 - Shipping type : Getting Goods
 - Invoice status : Not Applicable
3. Go to "Information" tab" and change Procurement method to "Make to order"
4. Save product
5. Create a new sale order with the product HDD1
6. Launch Schedulers "Compute Scheduler"
7. The Scheduler create a new purchase order for this product
8. Confirm purchase order and receipt this product "Incoming Shipments"
9. The destination location or this product is Shelf 1
10. The Delivery Order is now "Available" but the Source Destination is "Stock" <= it's wrong, the source must be "Shelf 1"

Please find a patch for V6 and v5

[Amit Parik (amit-parik)]

Hello Sebastien,

Have you changed your location stock as a shelf1 instead of stock.

If in your warehouse configuration location stock="Stock" then in delivery order the source location will be set as a "stock" .

Thanks.

[Sebastien LANGE - http://www.Syleam.fr (alnslang)]

No, I've not changed because it's to OpenERP to change it not the user.

OpenERP must be able to find the location of the product. In this instance, OpenERP change state to "Assigned" automatically on stock.picking type 'out' in a bad source location. It allowed me to get out product to the location "Stock " without telling me when my product was "Shelf1" location. My stock is now Wrong. If OpenERP is not capable of choosing the right location, change of software.

For information, I'm not used "Force assign".

Please try my explain in demo database for understand the bug.

I'll maintain the patch for my customers.

Thanks

[Olivier Dony (Odoo) (odo-openerp)]

Hello Sebastien,

Thanks for the detailed bug description and the proposed patch.
The behavior you describe can indeed be reproduced by following the steps you gave, and the patch you propose will certainly change it to the behavior you would prefer.

However, it's not so clear that this behavior is desired in all cases, because it causes alteration of source location of chained moves, which may have unexpected consequences, for example when locations are manually altered by a user.
We are analyzing the consequences to see if your patch (or a corrected version where force_assign is correctly called) can be safely applied. Otherwise, we could simply be consider that if you configure a pushed flow that alters your MTO flows, you need to configure other push/pull rules to correct the flows so that all stock levels are correct.

What is clear however, and might help you, is that when using Make-To-Order flows, it is almost always more appropriate to combine them with _pulled_ flows rather than _pushed_ flows. This is because MTO is itself a pulled flow.
In the example you described, you could perhaps get a more appropriate behavior by doing the following scenario:

1. Install stock_location module
2*. Open HDD1 product and go to "Logistics Flows" tab and add a new *PULLED* Flow with :
 - Name: HDD1 are obtained in Stock by pulling them from Shelf1
 - Destination location : Stock
 - Type of procurement: Move (we are getting them from another location)
 - Source Location: Shelf 1
 - Shipping type : Internal (the move from Shelf1 to Stock is Internal)
 - Procure Method: MTO (we want the goods to be ordered directly in Shelf1, not just wait until there is some)
 - Invoice status : Not Applicable
3. Go to "Information" tab" and change Procurement method to "Make to order"
4. Save product
5. Go to Warehouse/Configuration and delete the minimum stock rule for HDD1 in Stock (as it makes no sense in this example)
6. Create a new sale order with the product HDD1
7. Launch Schedulers "Compute Scheduler"
8. The Scheduler create a new purchase order for this product
9. Confirm purchase order and receipt this product "Incoming Shipments"
10. The destination location of this product is Shelf 1
11: Go to Warehouse/WH Management/Internal Moves and confirm the internal move from Shelf1 to Stock (which correctly pulls the HDD from Shelf1 into Stock, which is the location in your warehouse from where goods are supposed to be sent to customers)
12. The Delivery Order is now "Available" and the Source Location is "Stock" <= it's correct
13. Go to Warehouse/Reporting/Inventory Analysis and notice that stock levels are correct in Stock and Shelf1.

This requires the confirmation of one additional internal move, though. Other configurations are possible as well.

In any case, we'll follow-up on this bug according to what our analysis gives, as explained above.
Any feedback from anyone on this topic is appreciated of course.

[Sebastien LANGE - http://www.Syleam.fr (alnslang)]

Hello Olivier,

Thank you for your detailed explanations. Indeed your example works fine.

I'll take another example. The product HDD1 is normally handled in stock but a customer requests a quantity of 1000 PCE and then you decide to do an order for him "on order" and not "stock". To do this you will indicate on your sales order this product you order and not stock. OpenERP will generate a purchase order with 1000 pieces. In receipt, you decide to put it in a location stamp upon receipt (eg cross-docking). You valided this receipt, OpenERP will automatically assign these products for preparation.
This case is a classic case in warehouses. Cross-docking has been developed in the wms module (lp: wms) for a customer that has exactly this problem.

It's not possible to add internal movement for this, I think.

[Olivier Dony (Odoo) (odo-openerp)]

Le 02/03/11 19:38, Sebastien LANGE - http://www.Syleam.fr a écrit :
> I'll take another example. The product HDD1 is normally handled
 > in stock but a customer requests a quantity of 1000 PCE and then
 > you decide to do an order for him "on order" and not "stock".
> To do this you will indicate on your sales order this product
 > you order and not stock. OpenERP will generate a purchase order
 > with 1000 pieces.

Yes, this is a valid case, but one thing to keep in mind is that
Make-To-Order is a procurement concept, not a picking concept.
MTO means that you want the required goods to be ordered instead
of taken from stock.
However MTO does not guarantee that the goods that have been ordered
will be those that are delivered to the customer for which they
were ordered, as many manual changes could be involved between
those 2 operations.

Unlike other ERP systems, OpenERP goes the extra mile to try to
assist you for the pickings related to the MTO, by chaining the
stock moves so that traceability is nicely propagated.
However it cannot guarantee this, it can only prepare documents
with default values, and these may need to be manually corrected
before validated!

The "golden rule" for WM in OpenERP is that all exceptions must be
manually input into the system, as all enterprises will want
different behaviors for different cases.
See below for counter-examples.

> In receipt, you decide to put it in a location
 > stamp upon receipt (eg cross-docking). You valided this receipt,
 > OpenERP will automatically assign these products for preparation.
> This case is a classic case in warehouses.
 > Cross-docking has been developed in the wms module (lp: wms) for
 > a customer that has exactly this problem.

In this case, you have received the goods in a different location,
not the expected Stock location of the warehouse for which you
ordered the goods. This is an exception, so you need to manually
correct the destination location of the incoming picking, otherwise
OpenERP cannot know about it. I guess we agree so far.

Now the chained delivery picking is marked available to let the delivery
workers know that the goods are now available. Of course when
they go to pick the goods, they will notice that the goods are in fact
in another location. As a result, they should also correct the outgoing
picking's source location before validating it, so all stock levels
are correct.

I understand that you would like OpenERP to automatically change the
source of the chained delivery picking according to the previous
picking, but this will not be a valid way to handle the situation for
some companies. Here are a few reasons why this could be wrong:

- if the incoming goods were manually scrapped because they were bad,
you don't want to modify the delivery picking to take the goods from
scrap!
- if the delivery picking has already been printed by the delivery
workers, they may not notice this change done behind their back
- if there are multiple incoming pickings, e.g. if the picking was split
or if it was a production with multiple goods, there may still be only
one common delivery picking.
Will you change its source if only one incoming picking was redirected...

[Sebastien LANGE - http://www.Syleam.fr (alnslang)]

Hi Olivier,

> After analyzing the above carefully, we think there is one thing
> that might be an improvement: when the source location of a chained
> picking is not the same as the destination location of the previous one,
> we could use the normal assignation instead of the forced assignation,
> and turn the next procurement into Make-to-stock (just like when an
> upstream procurement is cancelled)
> This way, if the goods were put into a child location as in your
> example, the normal assignation will take them in the child location.
> And if the goods were scrapped, it will not find them at all and will
> have to wait until new goods are received in the correct location.

> What do you think?

Ok for this improvement but how to ensure that it has taken the right product (MTO)?