2014-05-03 22:03 GMT+02:00 Cédric Krier <cedric.kr...@b2ck.com>: > On 03 May 18:31, 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» >> > >> >> > - 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 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. > > 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.
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.kr...@b2ck.com > Tel: +32 472 54 46 59 > Website: http://www.b2ck.com/ -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com
