Hi, I can confirm that BOM concept is unknown in local micro-mechanics (first concentration world-wide) The French word for BOM "nomenclature" is understood as the details of ram material (iron cmposition) They do manage routes as "lists of operations"
regards Le 29/06/2011 13:43, Albert Cervera i Areny a écrit : > A Dimarts, 28 de juny de 2011 23:48:11, Cédric Krier va escriure: > >> On 28/06/11 11:27 -0700, Geoff Nordli wrote: > >> > I see there is a Manufacturing module planning document at: > >> > > >> > > >> > > >> > http://code.google.com/p/tryton/wiki/TrytonMRPIntegration > >> > > >> > > >> > > >> > Is there anyone actively working on this functionality for Tryton? > >> > >> I started the production module: > >> > >> http://codereview.appspot.com/4306055/ > >> > >> It is only the BOM definition but I hope to complete it with basic > >> production request and production order. > >> > >> If you want to discuss about development, you can come on tryton-dev@ > > > Now that Geoff has risen the discussion there's something I wanted to > discuss regarding the design of production in Tryton. > > > IMHO BoM should be considered as a way to help the user fill in > production orders but it should not be required. There are lots of > companies that produce things but they do not have a bill of materials. > Sometimes because they simply don't know the materials that they will > use in the production when it is started. I think it's important to keep > that in mind when designing production functionalities because this > probably means that the most important aspect is the production itself > and product traceability. > > > Also I do not like production orders in OpenERP. They are too high level > (and incomplete at the same time, which means they're far from ideal to > a lot of companies). What I envision is a very reduced version of a > production order which we could call "production move", "production set" > or simply "production". The idea is that it simply groups several stock > moves. It could look something like this: > > > class ProductionMove(ModelSQL, ModelView): > > "Production Move" > > _name = 'production.move' > > _description = __doc__ > > > consumed = fields.One2Many('stock.move', 'consumed_in', 'Consumed Moves'), > > produced = fields.One2Many('stock.move', 'produced_in', 'Produced Moves'), > > > ProductionMove() > > > Such a simple model could be used by a more complete production order > which could have a set of "Production Moves". This means that a full > production order could have some "Production Moves" already completed > and other "Production Moves" not completed yet. > > > This would be the model used for traceability functionalities too. So if > you wanted to know "which lots have been used to create lot X". The > traceability "system" would return the moves/lots consumed in the > appropriate "Production Moves". So if a single production order was > executed in several steps (ie has several production moves) we could > know which of those steps created the lot. This can be important for > companies in which production orders can take weeks to complete. Any > information regarding production planning should probably go to this > model instead of (or apart from) the higher level production order itself. > > > We've also found cases in which one would need (or benefit from) such > low-level production. Cases in which you don't need or want a production > order (no need for workflows, BoMs, etc) but where one needs products to > be transformed and traceability be kept. > > > Opinions? > > > -- > > Albert Cervera i Areny > > http://www.NaN-tic.com > > OpenERP Partners <http://www.NaN-tic.com> > > Tel: +34 93 553 18 03 > > > > http://twitter.com/albertnan > > http://www.nan-tic.com/blog > > -- > [email protected] mailing list -- Dominique Chabord - SISalp -- [email protected] mailing list
