c2c-oerpscenario team mailing list archive

["Olivier Dony \(OpenERP\)" <726836@xxxxxxxxxxxxxxxxxx>]

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?
- I'm sure there are other examples...

I hope this shows why we don't want to automatically alter pickings
based on exceptions. All exceptions should be input/corrected manually
into the system, as they represent a change from the normal flows, and
human validation is required.


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?


PS: If you wonder, the forced assignation is used because it allows to
deliver the goods that have just been received for MTO, even when there
is a temporary error in the real stock level that makes the current
stock quantity a bit too low for normal assignation to work.

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/726836

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

Status in OpenERP Modules (addons):
  Triaged

Bug description:
  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