CarlosRuiz: full meeting

2013-01-02T15:22:11Z

full meeting

New page

⇐
[[IDempiere|Table of Contents]] |
[[IDempiere/Full Meeting Minutes|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

IDempiere/FullMeeting20130102 - Revision history

CarlosRuiz: full meeting