Blueprint: Production Operation
Code Review - New issues: albert-nan
Cédric Krier
> URL: http://codereview.tryton.org/978003/
I think this blueprint tries to solve too much things at once.
I see a first goal:
In current production module, we manage the ingredient but there is no
receipt.
So the goal is to provide on the production order the steps to follow to
produce the outputs. The steps look like the BOMOperation of the
blueprint. But I think it is more about collecting information than
assign operations. Each steps must collect which machine was used by who
(could be many) and how much time (I think about start and stop times
with many laps). Also I think those steps are sequencial and not
parallelizable (as the BOMRouteLine suggest).
A second goal:
In current module, there is no order for production except the planned
date. I think you try with the BOMRouteLine to manage as kind of order
inside the production order. But for me, the production order must be a
simplest order which is performed sequentially. If there are needs for
parallelism, it should be done by creating many production orders.
But I understand there is some missing features to get this design
works:
- we need to be able to sort the production within the same day. I
don't it should be done with predecessor and successor but just
with a sequence. The system make a proposal and the user can
change it. This is a very difficult topic and I think the first
step is to allow users to do it manually before trying to
computerize it.
- we need to be able to ouput a production into a temporary location
which will be the input of the next production. I think it could
be done with a similar design as production_stock_location (even
extend it)
Also a minor goal:
In current module, the assignation and process of the input moves are
done at once for all moves. There could be cases (for example: long
running production) where the users wants to proceed line by line. I
don't see any difficulties to implement 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
A Dissabte 13 Juliol 2013 12:15:25, Cédric Krier va escriure:
> On 11/07/13 16:00 -0000, Code Review - New issues: albert-nan wrote:
> > URL: http://codereview.tryton.org/978003/
>
> I think this blueprint tries to solve too much things at once.
>
> I see a first goal:
>
> In current production module, we manage the ingredient but there is no
> receipt.
> So the goal is to provide on the production order the steps to follow to
> produce the outputs. The steps look like the BOMOperation of the
> blueprint. But I think it is more about collecting information than
> assign operations. Each steps must collect which machine was used by who
> (could be many) and how much time (I think about start and stop times
> with many laps). Also I think those steps are sequencial and not
> parallelizable (as the BOMRouteLine suggest).
I don't think they should be sequential. For a single production several processes can be done in parallel by two separate machines or people and then join them together to finish the production. In fact, it is very similar to projects where two subprojects or tasks can be executed in parallel too.
Production planners, such as frePPLe which we will hopefully integrate at the end, need that information in order to calculate resource usage and schedules.
> A second goal:
>
> In current module, there is no order for production except the planned
> date. I think you try with the BOMRouteLine to manage as kind of order
> inside the production order. But for me, the production order must be a
> simplest order which is performed sequentially. If there are needs for
> parallelism, it should be done by creating many production orders.
In fact we also discussed this approach with Àngel here at NaN·tic. If we take that road, we will also need a "production group" or allow having subproductions (similar to project + subprojects) in order to help the user have an overview.
Note that users will need to consider the production as the whole set of operations so we need a way to define the full BOM and workflows including those parallel operations.
It is also important to note that considering the "parallel" case different from the sequential one and treating it as a different production has the problem that forces the creation of the intermedite product as a product in the product.product table. In some cases that can highly increas the number of products to be managed which I think it is not desireable. The fact that you first mix the egg and the salt before creating the omelet, doesn't mean you really want the "product + salt" product to be created.
> But I understand there is some missing features to get this design
> works:
>
> - we need to be able to sort the production within the same day. I
> don't it should be done with predecessor and successor but just
> with a sequence. The system make a proposal and the user can
> change it. This is a very difficult topic and I think the first
> step is to allow users to do it manually before trying to
> computerize it.
At a first draft I put predecessor/successor in a second module so I'm ok for removing them. Specially because I do not aim for Tryton to be able to do production planning in the short term. For me, being able to store all the necessary information to feed a specialized appliaction is just perfect. What I think it is important is that we do not suppose that they will be executed sequentially.
> - we need to be able to ouput a production into a temporary location
> which will be the input of the next production. I think it could
> be done with a similar design as production_stock_location (even
> extend it)
I guess you mean stock_product_location, don't you?
I think it is important that the definitions of those "super-boms" is relatively simple.
> Also a minor goal:
>
> In current module, the assignation and process of the input moves are
> done at once for all moves. There could be cases (for example: long
> running production) where the users wants to proceed line by line. I
> don't see any difficulties to implement it.
I don't see any problems with this either. It is also the outputs that may be desireable to not be executed at once.
--
Albert Cervera i Areny
Consultor funcional
Tel. 93 553 18 03
@albertnan
www.NaN-tic.com
Avís legal >>
Cédric Krier
> A Dissabte 13 Juliol 2013 12:15:25, Cédric Krier va escriure:
> > On 11/07/13 16:00 -0000, Code Review - New issues: albert-nan wrote:
> > > URL: http://codereview.tryton.org/978003/
> >
> > I think this blueprint tries to solve too much things at once.
> >
> > I see a first goal:
> >
> > In current production module, we manage the ingredient but there is no
> > receipt.
> > So the goal is to provide on the production order the steps to follow to
> > produce the outputs. The steps look like the BOMOperation of the
> > blueprint. But I think it is more about collecting information than
> > assign operations. Each steps must collect which machine was used by who
> > (could be many) and how much time (I think about start and stop times
> > with many laps). Also I think those steps are sequencial and not
> > parallelizable (as the BOMRouteLine suggest).
>
> I don't think they should be sequential. For a single production several
> processes can be done in parallel by two separate machines or people and then
> join them together to finish the production. In fact, it is very similar to
> projects where two subprojects or tasks can be executed in parallel too.
I also think it is a management mistake to give one order to two
employees that must work separatly and join their effort later.
You miss something to synchronise their work.
A production should be the *simpliest* operation that you want to
modelise in the system.
> Production planners, such as frePPLe which we will hopefully integrate at the
> end, need that information in order to calculate resource usage and schedules.
be executed sequentially.
[1] http://frepple.com/documentation/modeling-guide/operation/#OPERATION_ROUTING
> > A second goal:
> >
> > In current module, there is no order for production except the planned
> > date. I think you try with the BOMRouteLine to manage as kind of order
> > inside the production order. But for me, the production order must be a
> > simplest order which is performed sequentially. If there are needs for
> > parallelism, it should be done by creating many production orders.
>
> In fact we also discussed this approach with Àngel here at NaN·tic. If we take
> that road, we will also need a "production group" or allow having
> subproductions (similar to project + subprojects) in order to help the user
> have an overview.
availability or not of the products.
And a production planning is not a simple tree, it is graph but storing
this graph is a mistake for me because it is highly volatile because the
vertices are not fixed (depends of the availability of the products).
> Note that users will need to consider the production as the whole set of
> operations so we need a way to define the full BOM and workflows including those
> parallel operations.
if you want to have control on parallel operations, you must create a
production for each operation.
> It is also important to note that considering the "parallel" case different
> from the sequential one and treating it as a different production has the
> problem that forces the creation of the intermedite product as a product in
> the product.product table. In some cases that can highly increas the number of
> products to be managed which I think it is not desireable. The fact that you
> first mix the egg and the salt before creating the omelet, doesn't mean you
> really want the "product + salt" product to be created.
of the operations at this level. Because you need a synchronisation
mechanism which will be this intermediate product.
> > But I understand there is some missing features to get this design
> > works:
> >
> > - we need to be able to sort the production within the same day. I
> > don't it should be done with predecessor and successor but just
> > with a sequence. The system make a proposal and the user can
> > change it. This is a very difficult topic and I think the first
> > step is to allow users to do it manually before trying to
> > computerize it.
>
> At a first draft I put predecessor/successor in a second module so I'm ok for
> removing them. Specially because I do not aim for Tryton to be able to do
> production planning in the short term. For me, being able to store all the
> necessary information to feed a specialized appliaction is just perfect. What
> I think it is important is that we do not suppose that they will be executed
> sequentially.
software".
We must stick to our design goal which is the KISS principle.
> > - we need to be able to ouput a production into a temporary location
> > which will be the input of the next production. I think it could
> > be done with a similar design as production_stock_location (even
> > extend it)
>
> I guess you mean stock_product_location, don't you?
> I think it is important that the definitions of those "super-boms" is
> relatively simple.