El divendres 2 de maig de 2014 0:50:08 UTC+2, Albert Cervera i Areny
va escriure:
2014-04-20 10:35 GMT+02:00 Albert Cervera i Areny
<alb...@nan-tic.com <javascript:>>:
> 2014-03-15 19:04 GMT+01:00 Albert Cervera i Areny
<alb...@nan-tic.com <javascript:>>:
>> 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/
<http://codereview.tryton.org/4411002/>
>> [2] http://codereview.tryton.org/1311002/
<http://codereview.tryton.org/1311002/>
>> [3]
https://groups.google.com/d/msg/tryton-dev/X5do2teK0mU/4M-wMcKXsEIJ
<https://groups.google.com/d/msg/tryton-dev/X5do2teK0mU/4M-wMcKXsEIJ>
>> [4]
https://groups.google.com/d/msg/tryton-dev/njRiRaecLTQ/oneecYq6tyEJ
<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/
<http://codereview.tryton.org/10281002/>
AFAIU the steps justs define the order in which the products must be
consumed and the operations must be done. The process will become the
initial version of the production.
Just give a review on the code and have some remarks:
- You link boms and routes with steps, but i think that this is to
complex and its sufficient to link one process with on bom and one route.
Can you put some example where you need more than one bom/route per
process and you will not need another production to produce the
intermediate products?
If you don't have any problems with the first point, this will simplify
the following thinks:
- No need t hide bom and route for the production, just make readonly
and fill with the values of the process.
- No need to compute factor on the process, as it only defines the order.
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
