production_route module

[Albert Cervera i Areny]

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
--
Albert Cervera i Areny
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com

[Albert Cervera i Areny]

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?

[Mathias Behrle]

* Albert Cervera i Areny: " [tryton-dev] Re: production_route module" (Sun, 20
Apr 2014 10:35:51 +0200):

[...]

I like very much the idea of putting the process as the central part of
production [1].

> 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?

I could imagine the route model more generic, not just production orientated.
If route is just a sequence of steps, it could be used also for workflows
where no products are involved (e.g. a service consisting of doing several
defined steps). Then no bom would be necessary for such a route. But that's
probably overkill instead of creating a separate model for such use cases.

> 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?
>

[1] http://commons.wikimedia.org/wiki/File:Production_process_model.png

--

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

[Albert Cervera i Areny]

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/

[Cédric Krier]

On 15 Mar 19:04, Albert Cervera i Areny wrote:
> For more information about the initial blueprint take a look at this thread [4].

I have a big problem with this proposal, it is the missing of a
blueprint.
I can not think or evaluate base on such large code base especially for
a so large feature. Code contains too much noize to be able to get a
clear picture.
So I'm missing a document which describes the goals/features and also
the design proposal of the implementation. A good place for it is the
wiki because we could collaborate on it.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Albert Cervera i Areny]

2014-05-02 15:08 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 15 Mar 19:04, Albert Cervera i Areny wrote:
>> For more information about the initial blueprint take a look at this thread [4].
>
> I have a big problem with this proposal, it is the missing of a
> blueprint.
> I can not think or evaluate base on such large code base especially for
> a so large feature. Code contains too much noize to be able to get a
> clear picture.
> So I'm missing a document which describes the goals/features and also
> the design proposal of the implementation. A good place for it is the
> wiki because we could collaborate on it.

Here's the wiki page. Tried to explain what we're trying to solve in
this first step as well as the approaches and some design decisions we
took so far:

https://code.google.com/p/tryton/wiki/ProductionProcesses

[Cédric Krier]

Ok better even if refering to existing code instead of having an
abstract modelisation is not very good.

Here are my remarks:


- «route», I realy dislike this word. I know it is the one used by
some industry but anyway.
- idem for «work center» and clearly it should be named «resource»
as the blueprint used it.
- I don't agree to define the time per quantity, it should always
based on the quantity of the BOM.
- I'm in complet disagreement with the «Processes». For me, it is
useless and lost cause to try to use a schema for this.

I'm still missing a simple Model design to clearly understand what is
proposed and how things are linked, assembled.

[Albert Cervera i Areny]

2014-05-02 20:14 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 02 May 19:16, Albert Cervera i Areny wrote:
>> 2014-05-02 15:08 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
>> > On 15 Mar 19:04, Albert Cervera i Areny wrote:
>> >> For more information about the initial blueprint take a look at this thread [4].
>> >
>> > I have a big problem with this proposal, it is the missing of a
>> > blueprint.
>> > I can not think or evaluate base on such large code base especially for
>> > a so large feature. Code contains too much noize to be able to get a
>> > clear picture.
>> > So I'm missing a document which describes the goals/features and also
>> > the design proposal of the implementation. A good place for it is the
>> > wiki because we could collaborate on it.
>>
>> Here's the wiki page. Tried to explain what we're trying to solve in
>> this first step as well as the approaches and some design decisions we
>> took so far:
>>
>> https://code.google.com/p/tryton/wiki/ProductionProcesses
>
> Ok better even if refering to existing code instead of having an
> abstract modelisation is not very good.
>
> Here are my remarks:
>
>
> - «route», I realy dislike this word. I know it is the one used by
> some industry but anyway.

Don't have a better name so far, but I'm open for suggestions.

> - idem for «work center» and clearly it should be named «resource»
> as the blueprint used it.

I like resource better too as it is much more generic, but wouldn't it
make sense to move it to another module? Or we just name it
"production.resource"?

> - I don't agree to define the time per quantity, it should always
> based on the quantity of the BOM.

That is a real help for users in some scenarios but I agree I can move
it to another module to keep the base simpler.

> - I'm in complet disagreement with the «Processes». For me, it is
> useless and lost cause to try to use a schema for this.

Why do you think it is useless? It allows the user to describe the
production process which is not possible with separate BOM and
Route's. Of course, I can add that as an extension as I already
started but I'd like to understand why you reject it so clearly.

>
> I'm still missing a simple Model design to clearly understand what is
> proposed and how things are linked, assembled.

I just updated the wiki.

>
> --
> Cédric Krier - B2CK SPRL
> Email/Jabber: cedric...@b2ck.com
> Tel: +32 472 54 46 59
> Website: http://www.b2ck.com/

[Cédric Krier]

On 02 May 23:20, Albert Cervera i Areny wrote:
> 2014-05-02 20:14 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> > On 02 May 19:16, Albert Cervera i Areny wrote:
> >> 2014-05-02 15:08 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> >> > On 15 Mar 19:04, Albert Cervera i Areny wrote:
> >> >> For more information about the initial blueprint take a look at this thread [4].
> >> >
> >> > I have a big problem with this proposal, it is the missing of a
> >> > blueprint.
> >> > I can not think or evaluate base on such large code base especially for
> >> > a so large feature. Code contains too much noize to be able to get a
> >> > clear picture.
> >> > So I'm missing a document which describes the goals/features and also
> >> > the design proposal of the implementation. A good place for it is the
> >> > wiki because we could collaborate on it.
> >>
> >> Here's the wiki page. Tried to explain what we're trying to solve in
> >> this first step as well as the approaches and some design decisions we
> >> took so far:
> >>
> >> https://code.google.com/p/tryton/wiki/ProductionProcesses
> >
> > Ok better even if refering to existing code instead of having an
> > abstract modelisation is not very good.
> >
> > Here are my remarks:
> >
> >
> > - «route», I realy dislike this word. I know it is the one used by
> > some industry but anyway.
>
> Don't have a better name so far, but I'm open for suggestions.

I like «Production Step»

> > - idem for «work center» and clearly it should be named «resource»
> > as the blueprint used it.
>
> I like resource better too as it is much more generic, but wouldn't it
> make sense to move it to another module? Or we just name it
> "production.resource"?

As it is something that could refer to many different things, I have for
now 2 things: an asset and an employee, we need an abstraction for the
production level.

> > - I don't agree to define the time per quantity, it should always
> > based on the quantity of the BOM.
>
> That is a real help for users in some scenarios but I agree I can move
> it to another module to keep the base simpler.

The important is the concistancy of the all.

> > - I'm in complet disagreement with the «Processes». For me, it is
> > useless and lost cause to try to use a schema for this.
>
> Why do you think it is useless? It allows the user to describe the
> production process which is not possible with separate BOM and
> Route's. Of course, I can add that as an extension as I already
> started but I'd like to understand why you reject it so clearly.

The production instructions, you describe target the user/human.
I see not advantage to try to use a schema for it. The best way to
communicate such instructions is with explanation text, just like for a
recipe. More over, the information system will have nothing to do with
such data.

> > I'm still missing a simple Model design to clearly understand what is
> > proposed and how things are linked, assembled.
>
> I just updated the wiki.

- I think Resource should not have a cost price.
- I don't see any benefit for OperationType. For me, the resources will
be enough to give a kind of "type".
- I don't see the point of 'production.route'. For me, the list should
be directly on the BOM because I can not imagine re-using a 'route'
for many BOM's.
- The 'production.route.operation' should have a list of resource
category.
- The cost price should be a company dependent.
- I'm wondering if instead of adding cost price on resource, it should
not be a link to a product asset or a group of employee on which such
information will be defined. And so the current resource will be the
serial number of the asset or the employee.
- Maybe resource should just be removed and replaced by two lists: one
for assets and one for group of employee.
- 'calculation', I think the name is not accurate. I think about
"coefficient" or "factor" with: "linear", "constant".
- In the model, it misses the definition of the models which will
receive a copy of the "route" on the production.

[Albert Cervera i Areny]

Given that we're talking about removing route, Production Step is
different from existing Route. So I understand you mean to replace
"Route Operation" by "Production Step".

But I think "Step" is more appropriate if we follow the Process design.

The reason is that we intentionally let "Route Operation" have only
one (many2one) Resource/Resource Category but allowing several Route
Operations point to the same Operation Type (we can find a better name
for that).

I think Step is a name for a given subprocess in the production. For
example, "Mixing" or "Cleaning". But that step can be executed by
several resources at the same time. Cleaning requires both Machine and
Employee to be allocated simultaneously.

So it would sound strange to me to have in a BOM two Steps that just
do the same (Cleaning) but that allocate different resources (of
course, we can also have a single step and then allow a one2many there
with several resources, although we discarded that design because it
was more complex, it is what we're proposing witht the process design
only adding the products).

>> > - idem for «work center» and clearly it should be named «resource»
>> > as the blueprint used it.
>>
>> I like resource better too as it is much more generic, but wouldn't it
>> make sense to move it to another module? Or we just name it
>> "production.resource"?
>
> As it is something that could refer to many different things, I have for
> now 2 things: an asset and an employee, we need an abstraction for the
> production level.
>
>> > - I don't agree to define the time per quantity, it should always
>> > based on the quantity of the BOM.
>>
>> That is a real help for users in some scenarios but I agree I can move
>> it to another module to keep the base simpler.
>
> The important is the concistancy of the all.
>
>> > - I'm in complet disagreement with the «Processes». For me, it is
>> > useless and lost cause to try to use a schema for this.
>>
>> Why do you think it is useless? It allows the user to describe the
>> production process which is not possible with separate BOM and
>> Route's. Of course, I can add that as an extension as I already
>> started but I'd like to understand why you reject it so clearly.
>
> The production instructions, you describe target the user/human.
> I see not advantage to try to use a schema for it. The best way to
> communicate such instructions is with explanation text, just like for a
> recipe. More over, the information system will have nothing to do with
> such data.

I has something to do with that data. Let me put an example:
Let's say you create a BOM which outputs 100L of painting. For
producing those, among other things you'll need 80L of water. So you
would create a BOM with 80L of water on the inputs and 100L of
painting on the outputs. The problem is that the production process
looks like:

Mix 10 minutes 25L of water with 1L dye.
Later add 1L of another component and mix for 20 minutes.
Then Mix 25 more L of water for 15 minutes.
etc.

When we create a production of 50 L (instead of 100L as it was
described in the BOM), the advantage of using the process approach is
that we'll get the proportions of water to be used in each step.
Otherwise, how can one create those instructions? If you attach a
document (or just put it in a notes field) you completely lose the
ability to offer the user those calculations. You need to tell the
user put 25% of the water of the BOM in the first step and mix for 10
minutes, adding burden and possible mistakes to the user..

[Mathias Behrle]

* Albert Cervera i Areny: " Re: [tryton-dev] production_route module" (Fri, 2
May 2014 19:16:34 +0200):

Thanks for the blueprint. Before diving into deeper modelling I would like to
return first to the basics. I think, if the basics are agreed upon, the rest
will be solved much more easily. So here are my 2¢:

From a very generic point of view a production needs:

a) resources
b) a sequence of steps
c) the result

a) can be of kind
- human
- machine
- material
- instruction (what to do, how to do it)
- ...?

b) will mostly require a time dimension, some production step
could even be to only assign time for e.g. drying time.


Currently the resource of materials is covered by the production module, all
others are necessary features to represent a full production process.


I would like to put the sequence of steps (b) in the center of the conception,
because a step can afford a subset of resources. So ideally I would see it like:

Production (as the container of one whole process)
-> consisting of several Production Steps (or subprocesses)
A Production Step should be able to describe all needs and expectations
of this single step.

My impression of the discussion so far is, that if we have Production Steps
with all kinds of resources attached we should meet all requirements.

Do we agree on that?

[Cédric Krier]

A step (maybe named operation) must have a or many list of resources
because it represents the time the resources are used/reserved.

3 options:

- make different productions
- use percentage
- use a templating language

But I realy think it doesn't deserve a more complex schema than a text
field.

[Albert Cervera i Areny]

I do agree but I guess Cédric does not :)

[Albert Cervera i Areny]

That really explodes the number of products to manage as you'll need a
different output on each step.

> - use percentage
> - use a templating language

I think these two are probably linked (you need to specify a
percentage in the template). I think I'd rather go towards the process
idea but as an extension of the bom + steps in a separate module.

> But I realy think it doesn't deserve a more complex schema than a text
> field.

Ok. I'll update the blueprint with your remarks.

[Albert Cervera i Areny]

I think each resource may have a different cost, even if several of
them are on the same category. If it is a human resource we could pick
that information from the employee, though.

> - I don't see any benefit for OperationType. For me, the resources will
> be enough to give a kind of "type".

It was added to allow have a set of existing Operations and track the
real resources used in a given operation. Without this, we will just
be able to know the cost in the production, but not if our estimate
per operation was accurate. The idea is that the list of operations in
the production have a Many2One to operation type and to the resource
used.

I've updated the wiki with several of your comments and I've added how
tracking the operations on the production could look like. I think
this can help discuss the OperationType issue.

> - I don't see the point of 'production.route'. For me, the list should
> be directly on the BOM because I can not imagine re-using a 'route'
> for many BOM's.

Ok for me.

> - The 'production.route.operation' should have a list of resource
> category.

You mean just a list of resource categories (many2many)? I think the
time must be linked to the resource/category (one of them only). So
Cleaning will take 5 minutes for the machine + 10 minutes from an
employee.

> - The cost price should be a company dependent.

Agreed.

> - I'm wondering if instead of adding cost price on resource, it should
> not be a link to a product asset or a group of employee on which such
> information will be defined. And so the current resource will be the
> serial number of the asset or the employee.
> - Maybe resource should just be removed and replaced by two lists: one
> for assets and one for group of employee.

I think it should not just be a list (many2many) but we need to know
the time (constant or linear) that will be used each resource, so I
see a resource as a model to encapsulate several kind of, well,
resources :) Maybe resource could jut have:

- a Selection for type (employee, asset, tool?, whatever)
- Reference to the object
- Cost as a function field calculated depending on the Selection type
and the Reference object
- UOM for cost / time

(In fact, I think the selection should go into the resource.category)

> - 'calculation', I think the name is not accurate. I think about
> "coefficient" or "factor" with: "linear", "constant".

I'm not very fond of coefficient/factor but agree with linear/constant.

> - In the model, it misses the definition of the models which will
> receive a copy of the "route" on the production.

Don't understand this one. Please, update the wiki as you see.

As I said, I also added to the wiki how tracking time operation time
information should be handled. This will bring other important stuff
such if Work should be linked with all this.

[Cédric Krier]

That's a too deep dream.

> > - I don't see any benefit for OperationType. For me, the resources will
> > be enough to give a kind of "type".
>
> It was added to allow have a set of existing Operations and track the
> real resources used in a given operation.

resources used for an operation are the resources.

> Without this, we will just
> be able to know the cost in the production, but not if our estimate
> per operation was accurate.

Wrong. The extimation is on the BOM, the reallity is on the production.

> The idea is that the list of operations in
> the production have a Many2One to operation type and to the resource
> used.
>
> I've updated the wiki with several of your comments and I've added how
> tracking the operations on the production could look like. I think
> this can help discuss the OperationType issue.
>
>
> > - I don't see the point of 'production.route'. For me, the list should
> > be directly on the BOM because I can not imagine re-using a 'route'
> > for many BOM's.
>
> Ok for me.
>
> > - The 'production.route.operation' should have a list of resource
> > category.
>
> You mean just a list of resource categories (many2many)? I think the
> time must be linked to the resource/category (one of them only). So
> Cleaning will take 5 minutes for the machine + 10 minutes from an
> employee.

Please explain how this can be.

> > - I'm wondering if instead of adding cost price on resource, it should
> > not be a link to a product asset or a group of employee on which such
> > information will be defined. And so the current resource will be the
> > serial number of the asset or the employee.
> > - Maybe resource should just be removed and replaced by two lists: one
> > for assets and one for group of employee.
>
> I think it should not just be a list (many2many) but we need to know
> the time (constant or linear) that will be used each resource, so I
> see a resource as a model to encapsulate several kind of, well,
> resources :) Maybe resource could jut have:

Not related to my comment.

> - a Selection for type (employee, asset, tool?, whatever)
> - Reference to the object
> - Cost as a function field calculated depending on the Selection type
> and the Reference object
> - UOM for cost / time
>
> (In fact, I think the selection should go into the resource.category)
>
> > - 'calculation', I think the name is not accurate. I think about
> > "coefficient" or "factor" with: "linear", "constant".
>
> I'm not very fond of coefficient/factor but agree with linear/constant.
>
> > - In the model, it misses the definition of the models which will
> > receive a copy of the "route" on the production.
>
> Don't understand this one. Please, update the wiki as you see.

Estomation is on BOM, reality is on production.
We miss the reality.

> As I said, I also added to the wiki how tracking time operation time
> information should be handled. This will bring other important stuff
> such if Work should be linked with all this.

I don't understand why you create OperationTracking when just Operation
is enough.

[Albert Cervera i Areny]

I think we're not understanding each other here. Better talk about the
curent model proposal.

>> The idea is that the list of operations in
>> the production have a Many2One to operation type and to the resource
>> used.
>>
>> I've updated the wiki with several of your comments and I've added how
>> tracking the operations on the production could look like. I think
>> this can help discuss the OperationType issue.
>>
>>
>> > - I don't see the point of 'production.route'. For me, the list should
>> > be directly on the BOM because I can not imagine re-using a 'route'
>> > for many BOM's.
>>
>> Ok for me.
>>
>> > - The 'production.route.operation' should have a list of resource
>> > category.
>>
>> You mean just a list of resource categories (many2many)? I think the
>> time must be linked to the resource/category (one of them only). So
>> Cleaning will take 5 minutes for the machine + 10 minutes from an
>> employee.
>
> Please explain how this can be.

If the employee needs to clean the machine + something else or prepare
for cleaning. Of course, we can also add a new step for "prepare for
cleaning" if we decided to use a m2m.

>> > - I'm wondering if instead of adding cost price on resource, it should
>> > not be a link to a product asset or a group of employee on which such
>> > information will be defined. And so the current resource will be the
>> > serial number of the asset or the employee.
>> > - Maybe resource should just be removed and replaced by two lists: one
>> > for assets and one for group of employee.
>>
>> I think it should not just be a list (many2many) but we need to know
>> the time (constant or linear) that will be used each resource, so I
>> see a resource as a model to encapsulate several kind of, well,
>> resources :) Maybe resource could jut have:
>
> Not related to my comment.

Again, probably do not understand. Let's define the model.

Do you want to add what your model would look like in the wiki and
continue the discussion from there?

>> - a Selection for type (employee, asset, tool?, whatever)
>> - Reference to the object
>> - Cost as a function field calculated depending on the Selection type
>> and the Reference object
>> - UOM for cost / time
>>
>> (In fact, I think the selection should go into the resource.category)
>>
>> > - 'calculation', I think the name is not accurate. I think about
>> > "coefficient" or "factor" with: "linear", "constant".
>>
>> I'm not very fond of coefficient/factor but agree with linear/constant.
>>
>> > - In the model, it misses the definition of the models which will
>> > receive a copy of the "route" on the production.
>>
>> Don't understand this one. Please, update the wiki as you see.
>
> Estomation is on BOM, reality is on production.
> We miss the reality.

Added.

>> As I said, I also added to the wiki how tracking time operation time
>> information should be handled. This will bring other important stuff
>> such if Work should be linked with all this.
>
> I don't understand why you create OperationTracking when just Operation
> is enough.

That was discussed in a previous thread. I think it was proposed by
you :) The idea is to be able to add times as they're executed.

Anyway, in base Operation could be enough and if we need to record
several times or start/stop, those can be extended in another module.
I don't see a problem with that.

>
> --
> Cédric Krier - B2CK SPRL
> Email/Jabber: cedric...@b2ck.com
> Tel: +32 472 54 46 59
> Website: http://www.b2ck.com/

[Sergi Almacellas Abellana]

El divendres 2 de maig de 2014 0:50:08 UTC+2, Albert Cervera i Areny va escriure:

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

[Albert Cervera i Areny]

One point is that currently a bom does not allow to have the same
product more than once. However, that constraint could be removed in
the process module. Note, however, that you'd need to change some
other stuff from the BOM, though. Also, the route sequence should be
managed correctly.

> 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?

Not really. If we can live with just one BOM and route, for me it's better too.

> 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.

Agreed.

> - No need to compute factor on the process, as it only defines the order.

This is required anyway because as I said you can have the same
product more than once in a process. The compute factor function could
be changed in the BOM which looks probably better.

[Cédric Krier]

On 04 May 10:53, Albert Cervera i Areny wrote:
> Again, probably do not understand. Let's define the model.
>
> Do you want to add what your model would look like in the wiki and
> continue the discussion from there?

I did not edit the wiki, I let you the authority.
Here is the design I have:


class BOM:
operations = fields.One2Many()


class OperationTemplate:
bom = fields.Many2One()
sequence = fields.Integer()
description = fields.Text()
time = fields.Float()
operator = fields.Selection(['linear', 'constant'])
asset_resources = fields.One2Many()
employee_resources = fields.One2Many()


class AssetResource:
product = fields.Many2One()


class EmployeResource:
group = fields.Many2One()


class Production:
operations = fields.One2Many()


class Operation:
production = fields.Many2One()
sequence = fields.Integer()
description = fields.Text()
time = fields.Float()
assets = fields.One2Many()
employees = fields.One2Many()


class OperationAsset:
product = fields.Many2One()
lot = fields.Many2One() # Optional


class OperationEmployee:
group = fields.Many2One()
employee = fields.Many2One() # Optional

[Albert Cervera i Areny]

2014-05-09 18:13 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 04 May 10:53, Albert Cervera i Areny wrote:
>> Again, probably do not understand. Let's define the model.
>>
>> Do you want to add what your model would look like in the wiki and
>> continue the discussion from there?
>
> I did not edit the wiki, I let you the authority.
> Here is the design I have:

Looks good to me in general. However I'd like to re-introduce the
OperationType concept. Design and reason below:

>
>
> class BOM:
> operations = fields.One2Many()
>

class OperationType:
description = fields.Text()

>
> class OperationTemplate:
> bom = fields.Many2One()
> sequence = fields.Integer()

operation_type = fields.Many2One()

> time = fields.Float()
> operator = fields.Selection(['linear', 'constant'])
> asset_resources = fields.One2Many()
> employee_resources = fields.One2Many()
>
>
> class AssetResource:
> product = fields.Many2One()
>
>
> class EmployeResource:
> group = fields.Many2One()
>
>
> class Production:
> operations = fields.One2Many()
>
>
> class Operation:
> production = fields.Many2One()
> sequence = fields.Integer()

operation_type = fields.Many2One()

> time = fields.Float()
> assets = fields.One2Many()
> employees = fields.One2Many()
>
>
> class OperationAsset:
> product = fields.Many2One()
> lot = fields.Many2One() # Optional
>
>
> class OperationEmployee:
> group = fields.Many2One()
> employee = fields.Many2One() # Optional

The reason for adding OperationType is because it allows the same you
have with a product. Let me explain:

Currently you can design a BOM and start producing. During production
employees introduce the real quantities of products consumed. This
allows the manager later aggregate historic data to check if the
planned quantities for each of the products were actually the
quantities planned and so he can change the bom accordingly if needed.

With operation type you can create the operations in the BOM and
during production employees introduce the real time spent but if we
just have a "description" we cannot make any analysis of where we're
spending most of our time. We just know that a given machine or
employee group is spending more time than expected but not doing what.

>
> --
> Cédric Krier - B2CK SPRL
> Email/Jabber: cedric...@b2ck.com
> Tel: +32 472 54 46 59
> Website: http://www.b2ck.com/

[Cédric Krier]

On 09 May 18:36, Albert Cervera i Areny wrote:
> 2014-05-09 18:13 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> > On 04 May 10:53, Albert Cervera i Areny wrote:
> >> Again, probably do not understand. Let's define the model.
> >>
> >> Do you want to add what your model would look like in the wiki and
> >> continue the discussion from there?
> >
> > I did not edit the wiki, I let you the authority.
> > Here is the design I have:
>
> Looks good to me in general. However I'd like to re-introduce the
> OperationType concept. Design and reason below:

Ok so my answer is:

> >
> >
> > class BOM:
> > operations = fields.One2Many()
> >
> >

> > class OperationTemplate:
> > bom = fields.Many2One()
> > sequence = fields.Integer()

> > time = fields.Float()
> > operator = fields.Selection(['linear', 'constant'])
> > asset_resources = fields.One2Many()
> > employee_resources = fields.One2Many()
> >
> >
> > class AssetResource:
> > product = fields.Many2One()
> >
> >
> > class EmployeResource:
> > group = fields.Many2One()
> >
> >
> > class Production:
> > operations = fields.One2Many()
> >
> >
> > class Operation:
> > production = fields.Many2One()
> > sequence = fields.Integer()

template = fields.Many2One()

[Albert Cervera i Areny]

The problem is that it makes the "route" part of the BOM less
flexible. See your own answer when I proposed this here:

https://groups.google.com/d/msg/tryton-dev/X5do2teK0mU/qP0Mw7oixM8J

were you said "But it prevents evolution of the Route."

Which I think was completely right. That's why I think OperationType
is a better solution.

[Cédric Krier]

Ok if OperationType is not required by default.

[Albert Cervera i Areny]

2014-05-09 19:07 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:

On 09 May 18:36, Albert Cervera i Areny wrote:
> 2014-05-09 18:13 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> > On 04 May 10:53, Albert Cervera i Areny wrote:
> >> Again, probably do not understand. Let's define the model.
> >>
> >> Do you want to add what your model would look like in the wiki and
> >> continue the discussion from there?
> >
> > I did not edit the wiki, I let you the authority.
> > Here is the design I have:
>
> Looks good to me in general. However I'd like to re-introduce the
> OperationType concept. Design and reason below:

Ok so my answer is:

> >
> >
> >     class BOM:
> >         operations = fields.One2Many()
> >
> >

> >     class OperationTemplate:
> >         bom = fields.Many2One()
> >         sequence = fields.Integer()

> >         time = fields.Float()
> >         operator = fields.Selection(['linear', 'constant'])
> >         asset_resources = fields.One2Many()
> >         employee_resources = fields.One2Many()

There is a problem with this design and it is that it does not show how many resources are required. Let's say that you have a process that requires one machine and two people for a whole hour to produce a unit.

You could set:

time = 1 hour

operator = linear

asset_resources = [machine_type_1]

employee_resources = ??

[Cédric Krier]

> employee_resources = [employee_type1, employee_type1]

[Albert Cervera i Areny]

My bad. I was thinking of m2m instead of o2m.

[Albert Cervera i Areny]

2014-05-09 18:13 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 04 May 10:53, Albert Cervera i Areny wrote:
>> Again, probably do not understand. Let's define the model.
>>
>> Do you want to add what your model would look like in the wiki and
>> continue the discussion from there?
>
> I did not edit the wiki, I let you the authority.

I've just updated the wiki. We will hopefully make a new review soon.

[Cédric Krier]

On 09 Jun 18:04, Albert Cervera i Areny wrote:
> 2014-05-09 18:13 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> > On 04 May 10:53, Albert Cervera i Areny wrote:
> >> Again, probably do not understand. Let's define the model.
> >>
> >> Do you want to add what your model would look like in the wiki and
> >> continue the discussion from there?
> >
> > I did not edit the wiki, I let you the authority.
>
> I've just updated the wiki. We will hopefully make a new review soon.

I think we should not put a lot on OperationAsset because:

- it adds an extra dependecy
- there are not yet a clear link between asset from account_asset
and lot from stock_lot

[Albert Cervera i Areny]

2014-06-09 18:33 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 09 Jun 18:04, Albert Cervera i Areny wrote:
>> 2014-05-09 18:13 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
>> > On 04 May 10:53, Albert Cervera i Areny wrote:
>> >> Again, probably do not understand. Let's define the model.
>> >>
>> >> Do you want to add what your model would look like in the wiki and
>> >> continue the discussion from there?
>> >
>> > I did not edit the wiki, I let you the authority.
>>
>> I've just updated the wiki. We will hopefully make a new review soon.
>
> I think we should not put a lot on OperationAsset because:
>
> - it adds an extra dependecy
> - there are not yet a clear link between asset from account_asset
> and lot from stock_lot

Maybe that could be added by another module which adds the field and
the dependency.

We could create a stock_lot_asset. For me it should add a m2o on
account.asset and o2m from on stock.lot. The reason would be that a
single asset can be paid in several invoices.

[stephan....@googlemail.com]

Just one note: I guess BOM stands for bill of materials. I think from the class definition in the wiki it would be appropriate to call the class SOP for standard operation procedure because it fulfills the requirements for a process description according to quality management standards like ISO 9001.

[Albert Cervera i Areny]

2014-06-17 11:02 GMT+02:00 <stephan....@googlemail.com>:

Just one note: I guess BOM stands for bill of materials. I think from the class definition in the wiki it would be appropriate to call the class SOP for standard operation procedure because it fulfills the requirements for a process description according to quality management standards like ISO 9001.

I also have my concern about naming it "BOM". However I think SOP is not correct either because it doesn't really describe a process but simply contains the products that will be consumed, the ones that will be created and the machines and people involved. 

[Stephan Patzwaldt]

Am Dienstag, 17. Juni 2014 15:55:24 UTC+2 schrieb Albert Cervera i Areny:

2014-06-17 11:02 GMT+02:00 <stephan....@googlemail.com>:

Just one note: I guess BOM stands for bill of materials. I think from the class definition in the wiki it would be appropriate to call the class SOP for standard operation procedure because it fulfills the requirements for a process description according to quality management standards like ISO 9001.

I also have my concern about naming it "BOM". However I think SOP is not correct either because it doesn't really describe a process but simply contains the products that will be consumed, the ones that will be created and the machines and people involved. 

I think with the sequence and the description fields the model as defined in the wiki [1] is sufficient to describe a process step by step. In fact it isn't even limited to production processes, also maintenance or even training of employees could be documented with this model if product fields are allowed to be empty. So it is a full ressource workload and cost documentation module or - to put it simply - a resource activity module. There could be added a category field to the BOM/SOP class to tag the type of processes (e.g. production, start up, maintenance, ...) .

[1] https://code.google.com/p/tryton/wiki/ProductionProcesses

[Cédric Krier]

On 18 Jun 02:33, Stephan Patzwaldt wrote:
> Am Dienstag, 17. Juni 2014 15:55:24 UTC+2 schrieb Albert Cervera i Areny:
> >

> > 2014-06-17 11:02 GMT+02:00 <stephan....@googlemail.com <javascript:>>:

> >
> >> Just one note: I guess BOM stands for bill of materials. I think from the
> >> class definition in the wiki it would be appropriate to call the class SOP
> >> for standard operation procedure because it fulfills the requirements for a
> >> process description according to quality management standards like ISO 9001.
> >>
> >
> > I also have my concern about naming it "BOM". However I think SOP is not
> > correct either because it doesn't really describe a process but simply
> > contains the products that will be consumed, the ones that will be created
> > and the machines and people involved.
> >
>
> I think with the sequence and the description fields the model as defined
> in the wiki [1] is sufficient to describe a process step by step. In fact
> it isn't even limited to production processes, also maintenance or even
> training of employees could be documented with this model if product fields
> are allowed to be empty. So it is a full ressource workload and cost
> documentation module or - to put it simply - a resource activity module.
> There could be added a category field to the BOM/SOP class to tag the type
> of processes (e.g. production, start up, maintenance, ...) .

Maybe just using a Reference field.

> [1] https://code.google.com/p/tryton/wiki/ProductionProcesses

[Albert Cervera i Areny]

2014-05-09 18:13 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
> On 04 May 10:53, Albert Cervera i Areny wrote:
>> Again, probably do not understand. Let's define the model.
>>
>> Do you want to add what your model would look like in the wiki and
>> continue the discussion from there?
>
> I did not edit the wiki, I let you the authority.
> Here is the design I have:
>
>
> class BOM:
> operations = fields.One2Many()
>
>
> class OperationTemplate:
> bom = fields.Many2One()
> sequence = fields.Integer()
> description = fields.Text()
> time = fields.Float()
> operator = fields.Selection(['linear', 'constant'])
> asset_resources = fields.One2Many()
> employee_resources = fields.One2Many()
>
>
> class AssetResource:
> product = fields.Many2One()
>
>
> class EmployeResource:
> group = fields.Many2One()

Do you think it is ok to add EmployeeGroup to company module?

[Albert Cervera i Areny]

2014-06-09 18:04 GMT+02:00 Albert Cervera i Areny <alb...@nan-tic.com>:
> 2014-05-09 18:13 GMT+02:00 Cédric Krier <cedric...@b2ck.com>:
>> On 04 May 10:53, Albert Cervera i Areny wrote:
>>> Again, probably do not understand. Let's define the model.
>>>
>>> Do you want to add what your model would look like in the wiki and
>>> continue the discussion from there?
>>
>> I did not edit the wiki, I let you the authority.
>
> I've just updated the wiki. We will hopefully make a new review soon.
>

While working on this I have an issue with how we should calculate
costs of assets in operations in the production. If we consider the
asset must be a product with type == 'assets' then we probably need to
define somewhere the cost per hour we want to assign to it.

Should we do that in the product form? Any other ideas on how we
should manage this?

[Cédric Krier]

I think so.

[Cédric Krier]

It should not be on the product because the cost for the usage of an
asset depends of the kind of usage you will have of this asset.
So for me, if needed, it should be added to the AssetResource.