On 17/07/13 00:49 +0200, Albert Cervera i Areny wrote: > 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 don't agree with this vision. 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. I guess you are talking about operation_routing [1] which are defined to 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. I don't understand. The synchronisation of the task will be done by the 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 just want to see a production as a big operations, you can. But 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. You have to create intermediate products if you want to control the flow 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. For me, it is not a valid argument to say: "it is done like that in this 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? Yes. > I think it is important that the definitions of those "super-boms" is > relatively simple. I don't understand what you name "super-boms". -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpjeKWnfUmsV.pgp
Description: PGP signature
