2014-05-03 16:03 GMT+02:00 Cédric Krier <cedric.kr...@b2ck.com>: > On 03 May 12:47, Albert Cervera i Areny wrote: >> 2014-05-02 23:58 GMT+02:00 Cédric Krier <cedric.kr...@b2ck.com>: >> > On 02 May 23:20, Albert Cervera i Areny wrote: >> >> 2014-05-02 20:14 GMT+02:00 Cédric Krier <cedric.kr...@b2ck.com>: >> >> > On 02 May 19:16, Albert Cervera i Areny wrote: >> >> >> 2014-05-02 15:08 GMT+02:00 Cédric Krier <cedric.kr...@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» >> >> 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). > > A step (maybe named operation) must have a or many list of resources > because it represents the time the resources are used/reserved. > >> >> > - 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.. > > 3 options: > > - make different productions
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 Tel. 93 553 18 03 @albertnan www.NaN-tic.com
