CarlosRuiz: full meeting

2012-04-25T15:34:06Z

full meeting

New page

⇐
[[IDempiere|Table of Contents]] |
[[IDempiere/Full Meeting Minutes|Full Meeting Minutes]] |
Full Meeting 2012-04-25


'''''CarlosRuiz''''': Good morning 
'''''Nicolas_''''': Bonjour ! 
'''''a42niem''''': good afternoon :) 
'''''CarlosRuiz''''': hehehe - I would better start greeting with "good day" 
'''''CarlosRuiz''''': I installed bonfire on jira.idempiere.com 
'''''CarlosRuiz''''': seems interesting to report issues and decorate attached screenshots 
'''''CarlosRuiz''''': you can get the plugin for your browser at http://jira.idempiere.com/secure/GetBonfire.jspa 
'''''a42niem''''': Unfortunately we do not currently support your browser :( 
'''''CarlosRuiz''''': which browser Dirk? safari? 
'''''Edwin_Ang''''': hi everyone 
'''''a42niem''''': galeon 
'''''CarlosRuiz''''': ah, according to atlassian it supports Internet Explorer, Firefox, Chrome, and Safari 
'''''CarlosRuiz''''': Hi Edwin_Ang 
'''''a42niem''''': galeon uses the mozilla engine but seems different enough 
'''''Edwin_Ang''''': what is the current topic? 
'''''CarlosRuiz''''': open agenda 
'''''a42niem''''': iceweasel works 
'''''CarlosRuiz''''': Nicolas_, about IDEMPIERE-63 I think your comment is correct - C_DocTypeTarget_ID in those two documents 
'''''Nicolas_''''': so, we put it in main version ? 
'''''CarlosRuiz''''': as I understand the case is just for already complete docs 
'''''Nicolas_''''': yes 
'''''Nicolas_''''': you complete a doc, then you reactivate it, and complete it again 
'''''CarlosRuiz''''': hmmm - maybe we don't need that flag 
'''''CarlosRuiz''''': I don't see a valid case to allow changing doctype when "Overwrite Sequence on Complete" is enabled and the document was previously completed 
'''''a42niem''''': a customer just had that problem when he started with a wrong doctype which had not been noticed 
'''''Nicolas_''''': Legally, it apply only for customer invoices, which don't allow holes in sequence 
'''''Nicolas_''''': but for other document (such as journals) it could be useful to not have hole 
'''''a42niem''''': trying to correct it she did not get the correct number because a new number for the order was prevented 
'''''CarlosRuiz''''': yep - but invoices cannot be reactivated - so we don't have that problem on invoices - just orders and gl journals 
'''''CarlosRuiz''''': precisely Dirk found problems with the reactivate - and now Nicolas_ found more problems when reactivated and changing doctype 
'''''CarlosRuiz''''': I think we better can consider it as a bug and just fix it -> avoid change of doctype if the ProcessedOn is already filled 
'''''a42niem''''': seconded 
'''''a42niem''''': i proposed to her to create a copy and void the wrong one in that case and she was happy with that 
'''''Nicolas_''''': it should work ; but if i remember well, if you create a new invoice, save it, then change doctype (with a different sequence like credit memo), save it, and then select the first doctype, you will have an hole (Invoice 1, CreditMemo 1, Invoice 2) ; Invoice 1 is lost 
'''''CarlosRuiz''''': yes - that happens if you don't use the "Overwrite Sequence on Complete" feature 
'''''CarlosRuiz''''': and also you can delete the invoice 
'''''CarlosRuiz''''': that's the purpose of the feature to avoid those holes 
'''''Nicolas_''''': you're right, this problem was found when using Compiere 
'''''CarlosRuiz''''': this is how we implemented the fix with Dirk https://bitbucket.org/CarlosRuiz_globalqss/adempiere361/changeset/492d67b3ccb9 
'''''CarlosRuiz''''': but we forgot the other docs that can be reopened (GL Journal, Payroll) 
'''''Nicolas_''''': the fix that was applied on orders could be applied on every document ; now, reactivations are not implemanted, but maybe they will be available in the future ?? 
'''''CarlosRuiz''''': agree Nicolas_ 
'''''CarlosRuiz''''': all setDefiniteDocumentNo methods can be patched the same way 
'''''CarlosRuiz''''': Edwin_Ang, about IDEMPIERE-247 - what is your idea? remove tables? classes? go back to old BOM structures? 
'''''Edwin_Ang''''': i am planning to study the manufacturing light solution first 
'''''Nicolas_''''': so, if the DocType is 'isOverwriteSeqOnComplete', then each time you're completing a document, we will check if it has already been processed (ProcessedOn column) ; if yes, no modiification, if no, we call 'getDocumentNo(getC_DocType_ID(), get_TrxName(), true, this);' ? 
'''''Edwin_Ang''''': study the database structure 
'''''Edwin_Ang''''': see if they use the same tables as libero 
'''''Edwin_Ang''''': but i don't see any migration scripts in their contribution_adaxa project in sourceforge 
'''''Edwin_Ang''''': i see some xml file commits in migration folder but can't find anything in that 
'''''Edwin_Ang''''': any idea? 
'''''CarlosRuiz''''': no Nicolas_ - I think better we put the validation on beforeSave of the docs and avoid saving if the doctype changed and processedon is not null and isOverwriteSeqOnComplete=Y 
'''''Nicolas_''''': yes, agree 
'''''CarlosRuiz''''': Edwin_Ang, I think the xml is about ad_migration tool 
'''''CarlosRuiz''''': I asked Paul and he told me we could create the migration scripts if we enable the log migration script flag and apply the xml with ad_migration tool 
'''''Edwin_Ang''''': ah.. ic 
'''''Edwin_Ang''''': but i checked their commit destination and find nothing there 
'''''Edwin_Ang''''': i don't know if there's a feature for hidden files in mercurial :D 
'''''CarlosRuiz''''': let me check in sf 
'''''CarlosRuiz''''': Edwin_Ang, this is the initial code http://adempiere.hg.sourceforge.net/hgweb/adempiere/contribution_adaxa/rev/0135328548b6 
'''''Edwin_Ang''''': they are all java classes 
'''''Edwin_Ang''''': i can reverse engineer from X classes 
'''''CarlosRuiz''''': and these are the migration scripts -> http://adempiere.hg.sourceforge.net/hgweb/adempiere/contribution_adaxa/rev/76cc541a1669 
'''''Edwin_Ang''''': but should i do it that way? 
'''''CarlosRuiz''''': but that migration script were patched later 
'''''Edwin_Ang''''': ow ok 
'''''CarlosRuiz''''': patched -> http://adempiere.hg.sourceforge.net/hgweb/adempiere/contribution_adaxa/rev/ef85ebbed608 
'''''CarlosRuiz''''': and here they moved to use xml files instead of scripts -> http://adempiere.hg.sourceforge.net/hgweb/adempiere/contribution_adaxa/rev/1269a2308ec6 
'''''CarlosRuiz''''': last two -> http://adempiere.hg.sourceforge.net/hgweb/adempiere/contribution_adaxa/rev/3c76468aa116 
'''''CarlosRuiz''''': http://adempiere.hg.sourceforge.net/hgweb/adempiere/contribution_adaxa/rev/a236451d7438 
'''''CarlosRuiz''''': now - what I understand is that adaxa moved back to old BOM structures 
'''''CarlosRuiz''''': in old structure one product can have just one BOM 
'''''CarlosRuiz''''': Steven told me would be worthy to add multiple BOMs (compiere 330 also did that) 
'''''CarlosRuiz''''': in compiere330 you can have multiple BOMs and you mark one to be the master and that is what you use for pricing 
'''''Edwin_Ang''''': somehow i am confused with the project 
'''''Edwin_Ang''''': i can see each changeset in my workbench 
'''''Edwin_Ang''''': but how the files are not there? 
'''''CarlosRuiz''''': you're probably sit in the wrong branch 
'''''CarlosRuiz''''': hg update adaxa 
'''''Edwin_Ang''''': ahh... i am very dumb! 
'''''Edwin_Ang''''': just realize it 
'''''Edwin_Ang''''': :D 
'''''Edwin_Ang''''': so so dumb 
'''''Edwin_Ang''''': ok.. got it 
'''''Edwin_Ang''''': so the plan is just bring in manufacturing light 
'''''Edwin_Ang''''': and then remove libero 
'''''Edwin_Ang''''': r u ok with dat? 
'''''Edwin_Ang''''': i am planning to remove everything 
'''''CarlosRuiz''''': yes - we're ok with that 
'''''Edwin_Ang''''': all application dictionary entries, database tables, and the codes 
'''''CarlosRuiz''''': our idea is that libero mfg must be moved to be an OSGi extension if somebody wants to reallly stabilize it and maintain it 
'''''Edwin_Ang''''': yes.. that is also what i'm thinking of 
'''''CarlosRuiz''''': in the meantime - it is ok to remove it 
'''''Edwin_Ang''''': ok.. one question about forking 
'''''CarlosRuiz''''': now - same problem as before - we need to be careful and provide proper migration script for the BOM structures 
'''''Edwin_Ang''''': previously, i forked your globalqss361 for fixed assets development 
'''''CarlosRuiz''''': I mean - if somebody has BOMs in 360/361 - that must be preserved 
'''''Edwin_Ang''''': later i use the same fork for bug fixing 
'''''Edwin_Ang''''': can i use that same fork for this work? 
'''''CarlosRuiz''''': good question 
'''''a42niem''''': my experience is to use a clone of the fork for my work 
'''''a42niem''''': then i can commit parts to the fork 
'''''a42niem''''': and create a pull request 
'''''CarlosRuiz''''': my work of receiving contributions on transition and migrating them to iDempiere is becoming very complicated :-( 
'''''a42niem''''': why that? 
'''''CarlosRuiz''''': because parts of the code are diverging - so it's becoming too manual work for some classes 
'''''CarlosRuiz''''': I like the transition version as it keep the project moving and you can keep contributing to transition and I make those contributions end into iDempiere 
'''''CarlosRuiz''''': but I think very soon the extra work will become too heavy - and we need to start doing work directly on iDempiere - just announcing for you to start preparing that :-) 
'''''a42niem''''': you mean idempiere is diverging? 
'''''CarlosRuiz''''': mostly the business classes are the same 
'''''CarlosRuiz''''': but for example zk webui is different - and it will become more different when Heng Sin integrate zk6 work very soon 
'''''a42niem''''': hm, can we probably backport stuff to 361? 
'''''CarlosRuiz''''': anyways - I'm not too concerned as we're close to start a feature freeze on transition and idempiere 
'''''Edwin_Ang''''': sorry, but i haven't understand you yet :p 
'''''Edwin_Ang''''': is that fork of mine still usable or i should create a new one? 
'''''CarlosRuiz''''': Edwin_Ang, still usable - you just need to do "hg pull -u" to update it and work there 
'''''Edwin_Ang''''': hmm.. so i need to update my fork first rite? 
'''''CarlosRuiz''''': yes - it's easier to create a pull request if you updated your fork 
'''''Edwin_Ang''''': ok then 
'''''Nicolas_''''': Carlos, do you have solution for my questions with idempiere-236 (centralized ID) 
'''''CarlosRuiz''''': Nicolas - I think I prefer on SystemIDs 
'''''CarlosRuiz''''': public final static int REFERENCE_DATATYPE_ACCOUNT = 25; 
'''''CarlosRuiz''''': and on DisplayType 
'''''CarlosRuiz''''': public static final int Account = REFERENCE_DATATYPE_ACCOUNT; 
'''''Nicolas_''''': ok, all id are centralized in SystemID and DisplayType will call it 
'''''Nicolas_''''': And for DocAction ? 
'''''CarlosRuiz''''': yes - we don't have a choice with DocAction :-) 
'''''Nicolas_''''': ok, just wanted to know if there was a tip ; i'll update classes and upload them 
'''''CarlosRuiz''''': I see an interface can extend another - but not implement it 
'''''CarlosRuiz''''': but I think is clearer just to keep it as you did 
'''''Nicolas_''''': ok, fine 
'''''Nicolas_''''': i got another issue this week with auto generated Element (i've created idempiere-109 ticket some week ago) ; any idea on how we can deal it ? 
'''''CarlosRuiz''''': Nicolas_, another approach could be to change SynchronizeTerminology and avoid generating elements for that 
'''''Nicolas_''''': that would the easier, but i'm wondering if this behaviour could have benefits ? 
'''''Nicolas_''''': maybe generating element automatically could bu useful ? 
'''''CarlosRuiz''''': I have had problems in past with auto-generated elements conflicting with official elements on new migration scripts 
'''''CarlosRuiz''''': another thing that is not consistent is that filling ad_element must fill name and description same as in column and field 
'''''Nicolas_''''': so, the easier the better, we should delete that part of SynchronizeTerminology ! 
'''''Edwin_Ang''''': just checked jira and came across IDEMPIERE-170 
'''''Edwin_Ang''''': carlos, what do you think about my comment on cash payment? 
'''''CarlosRuiz''''': ... reading ... sorry I missed it before 
'''''Edwin_Ang''''': after some deep thinking, internally we choose to use payment, allocation, and bank statement for cash payment 
'''''Edwin_Ang''''': and ignore cash journal completely 
'''''Edwin_Ang''''': i know there's a long debate about this 
'''''Edwin_Ang''''': but what do you think about cash journals? 
'''''Edwin_Ang''''': :) 
'''''CarlosRuiz''''': I already deprecated it in all my installations - and I asked several big implementors and none of them is using cash journals 
'''''CarlosRuiz''''': cash journals have several problems - but the most annoying is that BP balances are not updated until the cash is closed 
'''''CarlosRuiz''''': so, your comment on IDEMPIERE-170 is deprecated also? 
'''''Edwin_Ang''''': i also hate the fact that each cash transaction is recorded as cash line 
'''''Edwin_Ang''''': i go with the deprecate option 
'''''Edwin_Ang''''': but i think we must develop AP to cover the business case that i've explained in my comment 
'''''CarlosRuiz''''': like a multiBP AP Invoice ? 
'''''Edwin_Ang''''': yes 
'''''Edwin_Ang''''': i think that is a very common requirement in retail 
'''''CarlosRuiz''''': I would propose to open a new ticket "MultiBP Invoice" and analyze it there 
'''''CarlosRuiz''''': that could be probably useful also if you do just one single payment for your whole payroll 
'''''Edwin_Ang''''': yep 
'''''Edwin_Ang''''': btw.. is payroll a working module? 
'''''Edwin_Ang''''': have never tested it yet 
'''''CarlosRuiz''''': well - it's very basic - an engine applying rules 
'''''CarlosRuiz''''': properly configured it do what is expected 
'''''CarlosRuiz''''': initial configuration is the problematic part - and, as we don't have demo data, most people need to study and figure out how to make it work 
'''''Edwin_Ang''''': ahh.. if no bug fixing is required then i might give it a look 
'''''Edwin_Ang''''': thx! 
'''''Edwin_Ang''''': btw.. i got to go now 
'''''Edwin_Ang''''': it's already midnite in jkt 
'''''CarlosRuiz''''': bug fixing was mostly done in Ecuador and Venezuela on our transition version 
'''''CarlosRuiz''''': bye Edwin_Ang - thanks for attending 
'''''Edwin_Ang''''': bye Carlos 
'''''CarlosRuiz''''': I'm going out too - thanks for the meeting everybody - c u later

IDempiere/FullMeeting20120425 - Revision history

CarlosRuiz: full meeting