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. > 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. > > - 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. > - 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. > 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. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgpSN_Q7IbFJ0.pgp
Description: PGP signature
