Comment 9 for bug 770243

Hi Olivier,

Allow me to provide some context to the original question and the use case scenario.
Our NovaPoint client in the US is a retail distributor.
They have a large warehouse location (200,000+ sq ft warehouse), and as a result have multiple rows, multiple stops, and several numbers of heights for products and raw materials. Hence the 4000+ locations.

The material handlers need to know specifically where products are for efficient picking and movement of goods and replenishment (stocking primary picking locations). The material receivers need to be able to quickly record products in locations when received as ell.

Transactions volumes are >1,000+ orders per day and are a mix of single product sales and Assembly (sales) kits (kits made up of several products - pulled together at picking). NOTE: We have a new assembly Sales BOM code in lp:openerp-usa that allows for the proper inventory treatment of Sales kits and define assembly BoM as another BOM type. So actually product movements and shipments involve 4000-8000 items a day on sales orders by themselves.

Shipment of goods have 90% same day order-shipping.

The inventory turns are very quick.
Inventory locations are also very dynamic (meaning that product does not have a static "Primary location" which is why OpenERP standard inventory locations needed to be modified - it is based on a relatively static "here is the one location of a product in your warehouse") - with the warehouse setup for efficient picking. Throughput of picking is very important in larger retail distributors.

Products that are frequently shipped are stored in close proximity to packaging stations for efficient picking and warehouse operations. Then products may have multiple overstock locations as well (up to 20 additional locations for a single product).

OpenERP is not setup to support a dynamic warehouse environment so we created a new module in lp:openerp-usa to handle this - including replenishment of primary locations in a warehouse from overstock locations. With this we established replenishment points for each location (not to be confused with reorder points which consider when products should be "re-ordered") under the roof.

This enhancement set should address Raphael's issue #2.

Also - picking reports have also been modified to better help execute quick picking.
We allow the warehouse manager to designate which orders are assigned to a picker.
You'll see this modification in the code as well.
This includes displaying and printing a consolidated picking list that we created so each individual pickers can pull multiple orders in a single picking run. <-- Again this is all about efficiency.

Typically, there is a separate warehouse material handler in place and all they do is look to replenish the primary locations. There is a new replenishment report as well - and setup in the system that allows the material handlers to quickly enter the stock moves. (we see this enhanced going forward as well with a mobile app/bar code for efficiency).

Does this help to outline the use case of the original question of supporting multiple locations?

We actually see this environment as typical in many organizations and hope OpenERP would evaluate our code in lp:openerp-usa for consideration in the base product. The flow seems to work well at least for retail distributors.

A final part of the use case - Shipping.
We also added a "free" shipping module - with UPS shipping integration.

If you, or others need additional information about retail distribution or these modifications feel free to contact NovaPoint Group directly via the following email david (at) novapointgroup.com.

All the best,

Dave