Re: production_operation: Initial commit (issue 1311002)

[Albert Cervera i Areny]

2013/10/25 <albert....@gmail.com>:
> http://codereview.tryton.org/1311002/

I just created this codereview which aims to implement a minimal
"Production Operation" as previously discussed [1]. The patch is not
finished but I'd like to get some feedback before resuming the
development.

As always, comments are very welcomed.

[1] https://groups.google.com/forum/#!topic/tryton-dev/njRiRaecLTQ

PS: I know that setup.py should be changed if we agree in the design
to go into Tryton.

--
Albert Cervera i Areny
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com

[Cédric Krier]

On 25/10/13 11:12 +0200, Albert Cervera i Areny wrote:
> 2013/10/25 <albert....@gmail.com>:
> > http://codereview.tryton.org/1311002/
>
> I just created this codereview which aims to implement a minimal
> "Production Operation" as previously discussed [1]. The patch is not
> finished but I'd like to get some feedback before resuming the
> development.
>
> As always, comments are very welcomed.

Here are somes:

- The cost_price on WorkCenter should be only for machine as
cost_price is already managed in timesheet_cost.
I'm also wondering if the machine should not be linked to
something similar to employee like asset product (or lot).

- I think Route should be linked to Product, just like Bom's are
link to Product.

- When I see the RouteOperation are linked to WorkCenter, I think
there is something wrong. It should be linked to a kind of
WorkCenter because you don't define the employee or the machine to
use at this level but which kind of employee (capabilities) or
which kind of machine. In some way, it could be the
WorkCenterCategory (but will require to move the type on it).

- I don't think it is necessary to link Operation to the
RouteOperation. It is just like we don't link to stock moves to
the BOMInput/Output.

- Following the previous point, I will add on Operation in more of
the WorkCenter, the WorkCenterCategory (with domain contraint).

- I think the cost should be stored on the Operation, because it
could change over time on the WorkCenter definition.

- What do you think about renaming OperationLine into
OperationHistory?

- I think OperationLine has too much information by default
(especially because they could be added later by customization).
work_center sounds useless.
quantity and uom don't seem to have a clear definition.

- I'm wondering if the WorkCenter should not be stored on the
OperationLine instead of the Operation. For example, the Operation
could be done by two employees.

- I think the module should be split in two parts. One with the
“template”: WorkCenterCategory, Route, RouteOperation, Operation.
And a second with the details: WorkCenter, OperationHistory.
Because I think small production will want to show the Operations
but doesn't want to track cost of it.

--
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/

[Albert Cervera i Areny]

2013/10/25 Cédric Krier <cedric...@b2ck.com>:

> On 25/10/13 11:12 +0200, Albert Cervera i Areny wrote:
>> 2013/10/25 <albert....@gmail.com>:
>> > http://codereview.tryton.org/1311002/
>>
>> I just created this codereview which aims to implement a minimal
>> "Production Operation" as previously discussed [1]. The patch is not
>> finished but I'd like to get some feedback before resuming the
>> development.
>>
>> As always, comments are very welcomed.
>
> Here are somes:
>
> - The cost_price on WorkCenter should be only for machine as
> cost_price is already managed in timesheet_cost.
> I'm also wondering if the machine should not be linked to
> something similar to employee like asset product (or lot).

You suggest to have two separate modules production_operation and
production_timesheet, for example? That would sound good to me.

> - I think Route should be linked to Product, just like Bom's are
> link to Product.

Hard to say. I think we can easily find two cases:

- The route must be linked to the BOM
- The route must be linked to the Product (you can use any combination
of BOM and Routes)

> - When I see the RouteOperation are linked to WorkCenter, I think
> there is something wrong. It should be linked to a kind of
> WorkCenter because you don't define the employee or the machine to
> use at this level but which kind of employee (capabilities) or
> which kind of machine. In some way, it could be the
> WorkCenterCategory (but will require to move the type on it).

In my original design I allowed to link to WorkCenter OR
WorkCenterCategory. I think we can easily find both use cases: the
need to hav specific workcenters and to have categories. Maybe I
should stick to the original idea.

> - I don't think it is necessary to link Operation to the
> RouteOperation. It is just like we don't link to stock moves to
> the BOMInput/Output.

Linking improves traceability and allows later analysis of deviations.
For example, to see that the planned value is always optimistic and
thus correct it.

> - Following the previous point, I will add on Operation in more of
> the WorkCenter, the WorkCenterCategory (with domain contraint).

Sounds good.

> - I think the cost should be stored on the Operation, because it
> could change over time on the WorkCenter definition.

True. Maybe when Operation workflow "starts" we could store it.

> - What do you think about renaming OperationLine into
> OperationHistory?

I agree that OperationLine is not a good name but I think History is
still somewhat confusing. Maybe OperationTracking? [1]

> - I think OperationLine has too much information by default
> (especially because they could be added later by customization).
> work_center sounds useless.
> quantity and uom don't seem to have a clear definition.

That's because it is not finished. My idea is that the category of
work_center UOM is a constraint to the kind of UOMs allowed here. I
left start and end date but I think those should go to a customization
module. This way we allow core module to keep track of information
without constraining it to just time. Possibly we will want to use
cycles for some machines.

> - I'm wondering if the WorkCenter should not be stored on the
> OperationLine instead of the Operation. For example, the Operation
> could be done by two employees.

Tricky question. One could also add a new operation...

> - I think the module should be split in two parts. One with the
> “template”: WorkCenterCategory, Route, RouteOperation, Operation.
> And a second with the details: WorkCenter, OperationHistory.
> Because I think small production will want to show the Operations
> but doesn't want to track cost of it.

I don't really see a great advantage. As I understand you mean that
they can just "document" the production process in the ERP but don't
really keep track of what is really happening. In my experience
companies already have their processes documented elsewhere and don't
think they'll put it in the ERP if it is not for making real use of
them. They can even have the docs as attachments of the BOM if they
want.

Thanks for the feedback!

[1] http://www.thefreedictionary.com/track

[Cédric Krier]

On 25/10/13 23:35 +0200, Albert Cervera i Areny wrote:
> 2013/10/25 Cédric Krier <cedric...@b2ck.com>:
> > On 25/10/13 11:12 +0200, Albert Cervera i Areny wrote:
> >> 2013/10/25 <albert....@gmail.com>:
> >> > http://codereview.tryton.org/1311002/
> >>
> >> I just created this codereview which aims to implement a minimal
> >> "Production Operation" as previously discussed [1]. The patch is not
> >> finished but I'd like to get some feedback before resuming the
> >> development.
> >>
> >> As always, comments are very welcomed.
> >
> > Here are somes:
> >
> > - The cost_price on WorkCenter should be only for machine as
> > cost_price is already managed in timesheet_cost.
> > I'm also wondering if the machine should not be linked to
> > something similar to employee like asset product (or lot).
>
> You suggest to have two separate modules production_operation and
> production_timesheet, for example? That would sound good to me.

Not really but to use timesheet_cost.
In some way, when a Operation for a employee is registered, a timesheet
line could be created. (Probably grouped for the all day).

> > - I think Route should be linked to Product, just like Bom's are
> > link to Product.
>
> Hard to say. I think we can easily find two cases:
>
> - The route must be linked to the BOM

In this case, it will limit the usage of Route. I think there is high
probability that when a product has many BOMs indeed the Route is the
same because it is just the raw materials that change.

> - The route must be linked to the Product (you can use any combination
> of BOM and Routes)

Yes I was thinking about combination. So we could add on Route the
allowed BOMs that can be used with.
I think a Route could have many BOMs but the opposite a BOM could not
have many Routes (low probability).

> > - When I see the RouteOperation are linked to WorkCenter, I think
> > there is something wrong. It should be linked to a kind of
> > WorkCenter because you don't define the employee or the machine to
> > use at this level but which kind of employee (capabilities) or
> > which kind of machine. In some way, it could be the
> > WorkCenterCategory (but will require to move the type on it).
>
> In my original design I allowed to link to WorkCenter OR
> WorkCenterCategory. I think we can easily find both use cases: the
> need to hav specific workcenters and to have categories. Maybe I
> should stick to the original idea.

I don't think so. I think it is just a too simplicification when there
is only one WorkCenter for a WorkCenterCategory. But it is a practice
that will prevent the growth of the entreprise when 2 WorkCenter will
exist.
Or it could be that it is an configuration error where
WorkCenterCategories have been defined with not enough granularity.

> > - I don't think it is necessary to link Operation to the
> > RouteOperation. It is just like we don't link to stock moves to
> > the BOMInput/Output.
>
> Linking improves traceability and allows later analysis of deviations.

But it prevents evolution of the Route.

> For example, to see that the planned value is always optimistic and
> thus correct it.

Is it not a premature design optimisation?

> > - What do you think about renaming OperationLine into
> > OperationHistory?
>
> I agree that OperationLine is not a good name but I think History is
> still somewhat confusing. Maybe OperationTracking? [1]

Why not.

> > - I think OperationLine has too much information by default
> > (especially because they could be added later by customization).
> > work_center sounds useless.
> > quantity and uom don't seem to have a clear definition.
>
> That's because it is not finished. My idea is that the category of
> work_center UOM is a constraint to the kind of UOMs allowed here. I
> left start and end date but I think those should go to a customization
> module. This way we allow core module to keep track of information
> without constraining it to just time. Possibly we will want to use
> cycles for some machines.

+1

> > - I'm wondering if the WorkCenter should not be stored on the
> > OperationLine instead of the Operation. For example, the Operation
> > could be done by two employees.
>
> Tricky question. One could also add a new operation...

I think it is too much complex to let the user add operation.
Also you will diverge from the Route.
And at least for the employee, it sounds logical to store it at this
level because it is the user who is encoding the information.

> > - I think the module should be split in two parts. One with the
> > “template”: WorkCenterCategory, Route, RouteOperation, Operation.
> > And a second with the details: WorkCenter, OperationHistory.
> > Because I think small production will want to show the Operations
> > but doesn't want to track cost of it.
>
> I don't really see a great advantage. As I understand you mean that
> they can just "document" the production process in the ERP but don't
> really keep track of what is really happening. In my experience
> companies already have their processes documented elsewhere and don't
> think they'll put it in the ERP if it is not for making real use of
> them. They can even have the docs as attachments of the BOM if they
> want.

But why prevent one to use it just for documentation. Such company will
be happy to be able to leav the external documentation for an integrate
one without having to manage the complexity of all the tracking.

I have also one more remarks:

- While rethinking about Operation and WorkCenter, I'm wondering if
an (Route)Operation should not be composed by a just list of
machines (or just one) and on the Tracking there will be the
employee (optional because some machine works without operator).

This is because I think with the current design, most of the time
it will require to encode similar Tracking for the employee and
the machine.

[Albert Cervera i Areny]

2013/10/26 Cédric Krier <cedric...@b2ck.com>:

Taking into account the employee is necessary for planning production
costs. In order to sell a product to be produced we'll need that
Tryton is able to help the user get the planned cost and that includes
not only the materials but also machine usage and employee's time at
their hourly price.

> This is because I think with the current design, most of the time
> it will require to encode similar Tracking for the employee and
> the machine.

I think the Route must include the planned resources (just like BOM
includes the planned materials) but then in the production users will
introduced actual resource and material quantities used.

[Cédric Krier]

On 15/11/13 15:37 +0100, Albert Cervera i Areny wrote:
> 2013/10/26 Cédric Krier <cedric...@b2ck.com>:
> > On 25/10/13 23:35 +0200, Albert Cervera i Areny wrote:
> >> 2013/10/25 Cédric Krier <cedric...@b2ck.com>:
> >> > On 25/10/13 11:12 +0200, Albert Cervera i Areny wrote:
> >> >> 2013/10/25 <albert....@gmail.com>:
> >> >> > http://codereview.tryton.org/1311002/

> > I have also one more remarks:
> >
> > - While rethinking about Operation and WorkCenter, I'm wondering if
> > an (Route)Operation should not be composed by a just list of
> > machines (or just one) and on the Tracking there will be the
> > employee (optional because some machine works without operator).
>
> Taking into account the employee is necessary for planning production
> costs. In order to sell a product to be produced we'll need that
> Tryton is able to help the user get the planned cost and that includes
> not only the materials but also machine usage and employee's time at
> their hourly price.
>
> > This is because I think with the current design, most of the time
> > it will require to encode similar Tracking for the employee and
> > the machine.
>
> I think the Route must include the planned resources (just like BOM
> includes the planned materials) but then in the production users will
> introduced actual resource and material quantities used.

Here I think you are doing a mistake. If I keep your analogy, employee
should be close to lot than material.
If you want to be able to compute an estimation of the cost time, you
must have a kind of employee group, not the real employee.

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

2013/11/15 Cédric Krier <cedric...@b2ck.com>:

That sounds good to me, that's why we introduced WorkcenterCategory.
The thing is that somehow we should be able to put human
hours/resources in the Route.