2014-04-20 10:35 GMT+02:00 Albert Cervera i Areny <alb...@nan-tic.com>:
> 2014-03-15 19:04 GMT+01:00 Albert Cervera i Areny <alb...@nan-tic.com>:
>> Hi,
>> I just uploaded a review [1] for module production_route which should
>> be part of the functionality of a previous review for a
>> production_operation [2] module. The division of production_operation
>> into several modules was discussed here [3].
>>
>> So let me explain most important changes of the new proposal:
>> - The route does not bind to productions because that should be done
>> in a separate (production_operation) module. This module should be
>> used for documenting processes only.
>> - By now I kept WorkCenter in this module. For me it is ok to move it
>> to production_operation, although now it is just not required.
>> - Cédric had concerns on production_operation linking production
>> operations to route operations because it prevented evolution of the
>> route. On the other hand I was concerned about not having such link
>> for possible after-production analysis. That is solved by creating a
>> "production.operation.type" model where all possible operation types
>> would be defined ("painting", for example). This way, route operations
>> link to operation types and production operations will also link to
>> operation types. So it will be possible to make routes evolve while
>> keeping some information for later analysis in productions.
>> - I've constrained operations to managing time only. In the end any
>> other thing does not make much sense as any other measure (such as
>> cycles) can eventually be converted to time. Also, if we want to add
>> planning later, the only valid measure is time.
>> - I've added an important missing point and that is how time links to
>> a given production. It is now possible to say that an operation takes
>> 5 minutes no matter how many items we're manufacturing *or* that it
>> takes 5 minutes for the workcenter to create 2 items, for example.
>> This is important from a documentation point of view (the main purpose
>> of the module) as well as for the future production_operation module.
>> - Instead of linking the route to the product or a bom, by now I've
>> left it as the most simple manner: just defining the unit of measure
>> of the product to be produced. This is the unit of measure that should
>> be taken into account when defining the time information explained in
>> the previous point. A link to a product or bom should be added. I'm
>> thinking of adding it to 'product.product' as a Many2Many or to
>> 'product.product-production.bom'. Opinions?
>> - There was some discussion about the possibility of creating an
>> employee group or something like that. I think we need to decide if we
>> add the workcenter type to work center categories. And if such
>> employee group or category is appropriate and if so, to which module
>> it should be added.
>> - The module works with 3.0. I would later migrate it to trunk.
>>
>>
>> For more information about the initial blueprint take a look at this thread
>> [4].
>>
>> [1] http://codereview.tryton.org/4411002/
>> [2] http://codereview.tryton.org/1311002/
>> [3] https://groups.google.com/d/msg/tryton-dev/X5do2teK0mU/4M-wMcKXsEIJ
>> [4] https://groups.google.com/d/msg/tryton-dev/njRiRaecLTQ/oneecYq6tyEJ
>
> I've just updated the patch to link route with the product but I'm not
> yet satisfied with it. The reason is I think route and bom cannot be
> disconnected if we want them to be useful to describe the real
> production process. Even if the link is between bom and route (instead
> of route and bom to product) current models are not able to describe
> the complete recipe, if we take the cooking analogy.
>
> In cooking we do have the bom as we currently have it in Tryton (that
> is, the ingredients) but there is no route without products. That is,
> you cannot say you "need to spend 10 minutes mixing" and "15 minutes
> in the frying pan". You must say which ingredients of the bom must be
> mixed and which ones must be put in the frying pan. Of course, there
> may be some exceptions where all the components of the bom are used
> for all operations but that is only for the simpler cases.
>
> Let me put a simplified real example of the steps necessary for
> producing paint colors:
>
> - Put the container on the scale
> - Add the following components in the following order:
> - P1 50Kg
> - P2 4Kg
> - P3 2Kg
> - P4 500g
> - P5 300g
> - P6 100g
> - Check total weight
> - Add the following components while mixing:
> - P7 50Kg
> - P8 2Kg
> - Mix during 10 minutes
> - Add the following components while mixing:
> - P1 4Kg
> - Mix during 10 minutes
> - Add the following components while mixing:
> - P10 1Kg
> - Mix during 15 minutes
>
> For me, it would be possible to describe that easily by simply adding
> a new model to current production module that contains several
> "production.bom" model. Here I rename existing "production.bom" into
> "production.process.step" because I think it would be more
> appropriate:
>
> class Process:
> __name__ = 'production.process'
> steps = fields.One2Many('production.process.step')
> inputs = fields.Function(fields.One2Many('production.bom.input'))
> outputs = fields.Function(fields.One2Many('production.bom.output'))
>
> class Step:
> __name__= 'production.process.step'
> name = fields.Char('name')
> description = fields.Char('Description')
> inputs = fields.One2Many('production.bom.input')
> outputs = fields.One2Many('production.bom.output')
>
> Another module could add operation-related information to
> 'production.process.step':
>
> class Step:
> __name__ = 'production.process.step'
> operations = fields.One2Many('production.route.operation')
>
> It is also possible to add the Process concept in another module
> instead of current production one but I think it is simpler this way.
> For example, production module adds a m2o from production to bom which
> should be replaced by a link to process if it is created in a separate
> module.
>
> Before taking that road I'd like to have some feedback. Anybody sees a
> need of route without bom link? If so, how would you achieve a
> reasonable user interface when the link is necessary? Pros and cons
> for keeping it in/out of main production module?
Here's a first draft of what it could look like if we wanted to keep
processes as an extension to production_route. As I said, I don't
think it is the way to go, but it is doable:
http://codereview.tryton.org/10281002/
--
Albert Cervera i Areny
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com
