IDempiere/FullMeeting20130102

⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2013-01-02

CarlosRuiz: Good Morning
Deepak: Good Morning and Happy New year
CarlosRuiz: :-) yes - it seems it will be great
CarlosRuiz: hehehe - I said "it will" - when we're already on it
buildmaster: Project iDempiere build #641: SUCCESS in 6 min 35 sec: http://jenkins.idempiere.com/job/iDempiere/641/
buildmaster: hengsin: IDEMPIERE-369 Master Detail layout improvements. Fixed click on row indicator not working in header grid view. Single click instead of double click to maximize selected detail tab. Not to auto switch to form view for the detail record icon and the click to maximize selected tab action.
CarlosRuiz: Deepak, reading here the ASI email - do you want to check that?
Deepak: Yes
Deepak: Carlos, Me and Hengsin disccuss about complication of ASI and agreed that we should simplify it
Deepak: But we should decide approach
CarlosRuiz: yep - reading your discussion here
CarlosRuiz: ASI is actually used for three things - product attributes + instance attributes + fake FIFO
CarlosRuiz: AFAIR product attributes are just saved at product table / not on storage
CarlosRuiz: storage is for instance attributes and the fake FIFO
CarlosRuiz: what we would like on that ticket is to avoid the fake FIFO instance
Deepak: I am not sure whether system maintain product attribute set instance on storage or not
hengsin: instance attributes, yes
Deepak: If product ASI are only used on product, then our solution is simplified
hengsin: Carlos, how about serial management ? part of the issue is on how should that be captured on shipment line.
Deepak: I have added DateMaterialPolicy on inoutLineMA while it had ASI already
CarlosRuiz: yes, serial management is a problem, maybe a common form to capture serials on the different documents that require it?
Deepak: So we do not need ASI on shipment line now, but can create multiple inoutLineMA with each serial information
Deepak: Issue with current design is that Attribute tab on different window use different tables to store it
CarlosRuiz: I think the intention of JJ was to support the ASI on both tables
CarlosRuiz: if you defined the ASI on line the is used there / if not, then the MA tables are filled
Deepak: for example M_Inventory has M_InventoryLineMA
Deepak: If line has qty=1 then ASI on line is sufficient for serial
Deepak: But it is not when qty>1
Deepak: We need to force user to enter each ASI
CarlosRuiz: it depends
Deepak: For Lot/Batch they can use same ASI
CarlosRuiz: in some cases the system can suggest the serials
CarlosRuiz: instead of asking the user
CarlosRuiz: that is the case where the MA would be useful
CarlosRuiz: you complete the doc and the system advise which serials or lots to take, and the operator goes and pick them
Deepak: ahh, Agree
CarlosRuiz: which makes the serialization process too complex is that there are too many use cases for different industries
Deepak: So yes, if user has created MA then use them otherwise fill them
Deepak: Do you think we should add a property to force user to fill MA
Deepak: I mean client configurable properties
Deepak: Yes, That is truth. There are chance we missed something as different industries works differently
CarlosRuiz: there is M_AttributeSet.MandatoryType
CarlosRuiz: but I think it's incomplete on the use cases
CarlosRuiz: for serialization maybe we would need to start describing the different processes that we intend to support and how:
CarlosRuiz: - use serials since purchase order
CarlosRuiz: - use serials on material receipt, not in PO
Deepak: Yes, We can say at time of inwards
CarlosRuiz: - use serials on a special serialization inventory move process (not in MR neither PO)
CarlosRuiz: - define the serials on production
CarlosRuiz: - define the serials on sales order
CarlosRuiz: - define the serials on shipment
Deepak: I did not get why we need to use serials on SO?
CarlosRuiz: sounds like in general / in any doc that touches stock can use serials or not
CarlosRuiz: the difference is where the company define the serial on the stock
CarlosRuiz: or, in which documents the serial must be mandatory
Deepak: Defining serial on SO is confusing as it may not follow material policy
hengsin: deepak, if you are the main distributor or manufacturer, you can be the one to assigned serial to product and that can happens right before you ship them out.
Deepak: So as I understand, If say we have poduct having serial attribute set, On MR if user has proveded serial at time of creation of MR then we use same. But if serial are missing on MR Line then we create new serial for items we recieved?
Deepak: Is above assumption true?
hengsin: defining serial on so means you have allocated a specific instance to your customer. in that case, yes, it doesn't follow fifo or lifo material policy.
CarlosRuiz: nope Deepak, it depends / there are cases where all the inventory is managed internally without serial, and serialized just when shipping
CarlosRuiz: and there are cases where the company decides to manage the inventory with serial always / even on the material receipt
CarlosRuiz: and there is another case where you can receive bulks of serialized items (without assigning the serial on material receipt) and then assign the serials on a special serialization process
Deepak: Supporting all this 3 vaiants are complecated but possible
CarlosRuiz: we don't have that serialization process actually, so it needs to be simulated with internal use doc
Deepak: But we may need to add some configuration flag, So that can be controlled
CarlosRuiz: I'm thinking if maybe an InstanceMandatory flag on doctype could do the trick
CarlosRuiz: but wondering if maybe you would like to have some instance attributes mandatory and not others
CarlosRuiz: in such case we would need a new table to define which attributes are mandatory on which documents
Deepak: For example, product X needs to be recieved with serialization only while Y can be recieved without serial and it need to be serialized by system at time of shipping
CarlosRuiz: yep
Deepak: As industries has always two kinds of product, So we can not make them Tenant specific.
Deepak: So what we can do is make it Attribute Set specific
Deepak: We can define flag like System Serializable, If set then only system do serialization
Deepak: If not set on AS then it just expect serials entered at time of reciept or production
Deepak: Second flag we can add is serialized at time of shipment
Deepak: If this flag is selected then serialization done at time of shipment otherwise it will be done at MR
Deepak: So two points of having material serialized
Deepak: When I mention MR, It should be MR/Production
CarlosRuiz: the actual M_AttributeSet.MandatoryType supports three values
CarlosRuiz: 1 / not mandatory
CarlosRuiz: 2 / always mandatory
CarlosRuiz: 3 / when shipping
Deepak: ahk
CarlosRuiz: but I think that's not enough
CarlosRuiz: maybe a new detail table there that defines in which doc base type is mandatory an attribute set
CarlosRuiz: if defined there as mandatory / then we force the capture of instance attributes on lines of the documents
CarlosRuiz: and in case of serials we can allow to define the serials in a special form (barcode reader friendly)
Deepak: how we can allow configuration for whether do serialization or not?
Deepak: Should it on new table we are going to create or it should be centrally on AS?
CarlosRuiz: do you mean where do we define that the special form can be used?
Deepak: When I mention serialization, I mean generating new serial number instead of entered by users
Deepak: So say on product X we want to generate serials while on product Y we want user to enter them
CarlosRuiz: ah - that's actually defined in attribute set
Deepak: ohk
CarlosRuiz: when you want to generate serials you define a serial control
Deepak: So no needs for extra configuration. Presence of serial controls says that system can generate serials
Deepak: Do we need all 3 values on new table which says what document type needs serial?
Deepak: Or just Mandotory/Not mandatory is sufficient?
Deepak: Sorry there is no 3rd option now
Deepak: Any other points Carlos regarding serial?
CarlosRuiz: not that I recall
CarlosRuiz: looking the attribute set window
CarlosRuiz: there is a table to "exclude"
CarlosRuiz: based on table and IsSOTrx (not doc type)
CarlosRuiz: maybe we could follow similar approach but to "include"or "make mandatory"?
Deepak: Do system consideting exclude tab?
Deepak: I have not seen any trace for same yet
CarlosRuiz: I just found a reference on the attribute panel - if it's excluded it behaves different
Deepak: ahk
Deepak: I have to leave now.
CarlosRuiz: Thanks Deepak
Deepak: Thanks everybody