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
- use percentage
- use a templating language
But I realy think it doesn't deserve a more complex schema than a text
field.
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/
pgptxlW0HVhpj.pgp
Description: PGP signature
