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. > - 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. Without this, we will just be able to know the cost in the production, but not if our estimate per operation was accurate. 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. > - The cost price should be a company dependent. Agreed. > - 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: - 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. 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. -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com
