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.
_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : openerp-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
