IDempiere/FullMeeting20120425

⇐ Table of Contents | 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