← Back to team overview

openerp-community team mailing list archive

Re: WMS feedback

 

Dear Eric and others,
Thank you all for this big and needed push forward.
We're in the process of restructuring our logistics using OpenERP, and mostly we agree with Eric's view.
My remarks so far are inlined bellow.
I am well aware that some of what we expose here is not supposed to be in the core, but rather in community projects.
Lionel

Le 22/06/2013 04:05, Eric Caudal a écrit :
*Processes*
(...)- A stock move that is leaving is not a stock move that is arriving: there is a delay in transport and a stock move should have an intermediate state "on the way". Ideally a transport delay grid between location should be necessary.
All our current carriers are able to send us data files telling us where the goods we sent are, with a "picked up" and a "delivered" status. So my intuition is that this would be easy to represent the transport status as additional stock moves in new virtual locations : - if you don't have an EDI in place with the carrier, use a single location for that carrier, linked to the customer location with a delay (already possible and documented if I remember correctly) - if you have an EDI, import the carrier's locations as virtual locations in OpenERP and import the stock moves reported by the carrier.
(...)
*
Physical inventory*
(...)*
*
Additional problems we've met :
- complex inventories (lots of locations, products and prodlots) are hard to enter in OpenERP. We've developed a module to make nested inventories, we hope to push it to the community project this summer. - there is no easy way to make an exhaustive inventory : goods not present in inventory are considered unchanged, instead of being considered absent. OpenERP SA's stock_inventory_alternative is not a good solution because it needs ALL inventories to contain all warehouses. To improve this, this summer we hope we can propose a module to optionally associate inventories with locations. - stock moves inserted before the date of effect of n inventory make the "posted moves" wrong (https://bugs.launchpad.net/openobject-addons/+bug/588154). Quants must be implemented with fixing that in mind. In the meantime we us a module to strictly forbid such moves to be inserted. - it would be a big help if OpenERP proposed easy-to-customize inventory counting sheets. It's useful for small businesses, and even for bigger ones when some financial authority insist on having a pen-and-paper trace of the inventory (our own statutory auditor does).

*Barcoding support*
(...)
Whatever solution is adopted must be generic and not force us to use any specific brand or vendor's hardware.
(...)
*Reports on Stocks level and value:*
- We need to be able to easily access stock level at given time (currently report is far too slow). I have the feeling that stock.quant should solve the problem though
We found contextual product list very efficient to do this. Just set the date, warehouse, location or shop in the context and the list gives you the exact stock level. Quants MUST preserve this feature.
- (...)What about a cost history table (with product_id, lot_id, company, price, date/time etc.). Every time a cost change, a new record is created: it allows a function to query anytime a cost for a company.
I suppose that storing the price in all the moves (or quants) would allow us to get the valuation of a single warehouse or location, which a history table can't do.
- We need to be able to access the value of the stock at a given time for a company(...)
Yes, all the more as it would allow the cost to be context-sensitive: that would let us use the product list to get the quantity AND price of any product at any given time.
- User must be able to easily know at which location/production lot is a product. Currently with high number of stock moves, stock report is useless.
In v6 there used to be links named "stock by location" on the product form and prodlot form that were easy to use. Have they been removed ?
- In general, it is not normal that for any stock level, all SM have to be computed. Intermediate calculation should be stored.
That can be quants, or maybe we could use the latest inventory as the starting point (that would fix Bug #588154 too).

*Expiry and PL*
- Expiry in production lot: sometimes it is a automatic calculation based on production date (...), sometimes on arrival date (...) or manual input. Setup on the product or category
Also, for some products the expiry date is precise to the second, and for some it's only precise to the month (or year ?).
Anyway, that would best fit in the community projects I suppose.
- You cannot probably force production lot in the SM management but you can surely do it in the interface to avoid SM with no PL
Same here, this varies a lot from one installation to another so it's rather a community project isn't it?

*Procurement*
(...)
The biggest problem we met is that procurements relate to a single Stock Move, which is not enough to account for chained moves, split moves etc. We probably need a many-to-many relationship. That would solve https://bugs.launchpad.net/openobject-addons/+bug/794412 and many similar issues.
(...)
Hope this help. We will publish during the summer a clean version of the modules developed so far in v7.
That's great, I'm looking forward to it.


Follow ups

References