openerp-community team mailing list archive

["Lionel Sausin, de la part de l'équipe informatique Numérigraphe" <informatique@xxxxxxxxxxxxxxxx>]

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.