IDempiere/FullMeeting20140129

⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2014-01-29

CarlosRuiz: Morning
nmicoud: Bonjour
tbayen: Daarestiet!
CarlosRuiz: I think I can be here just half hour today
nmicoud: ok ; any subject you want to talk about ?
CarlosRuiz: open for suggestions :-)
posde: The weather?!
tbayen: Nothing special to talk about. I can inform the community that I am working on a better JasperReports plugin and on a SEPA/HBCI plugin (I believe this is only senseful in europe). If someone has knowledge or issues with JasperReports it is the right time to tell me.
CarlosRuiz: is sunny here at mornings, and usually raining at the afternoon :-)
nmicoud: tbayen : for your plugin, you may have a look at https://idempiere.atlassian.net/browse/IDEMPIERE-1200 ; which check the consistancy of the iban field
posde: tbayen, do you utilize hbci4java or something else?
nmicoud: Carlos, wdyt of https://idempiere.atlassian.net/browse/IDEMPIERE-917 ?
CarlosRuiz: tbayen, if you need to modify dictionary for the jasper plugin - you can use central IDs in case is integrated to trunk
tbayen: This week I decided to give hbci4java a try. It seems I will use that.
nmicoud: i've splitted the ticket into different patches (one per issue/improvement)
tbayen: posde, my first idea was to do a interface to hibiscus. But if direct hbci in idempiere works it will be the better integrated way.
posde: tbayen, yes. I am all for minimizing the amount of external dependencies.
posde: hibiscus does have nice infrastructure in place, though
tbayen: CarlosRuiz, nothing to change in the dictionary. It will be as non-intrusive as possible. It may be that I want to change some classes to collect some informations in the context that I can use in the report.
CarlosRuiz: good
tbayen: CarlosRuiz, I see that the legacy JasperReports code is very matured: Many small changes over the time to repair the one or the other issue. That makes the code very unreadable but it makes me feel that my code will take a long time until it is tested as well in all thinkable environments. I do not see it in trunk in the next time but as an suggested alternative.
tbayen: I use a kind of "virtual filesystem" to have all file access methods behave exactly the same way. :-)
CarlosRuiz: well - we always can as community to vote, then functional team to approve, then technical team to review and then release manager to integrate and then again community to test :DDD
CarlosRuiz: as -> ask
tbayen: nmicoud, CarlosRuiz : when we talk about sepa/iban: There are some places in the program where AccountNo is used (e.g. in the BankStatementMatcherMatcher interface). This will not work any more when we do no more use AccountNo but IBAN. I wonder if iban (in the sense of idempiere) IS an accountno and should not get an own column. I have either to change some interfaces or use the accountno column and make it wider (34 characters
tbayen: ).
nmicoud: in my instances, i've added iban fields.
nmicoud: so, i guess that could be done through migration scripts
CarlosRuiz: is not there IBAN field?
nmicoud: as it will be the "norm", at least in Europe
nmicoud: not on C_BP_BankAccount
tbayen: Yes, I have iban fields too. They are in the standard database. But e.g. the matcher (and possible other code) does not use them. Shall I change the matcher interface?
CarlosRuiz: bank account has BBAN and IBAN
CarlosRuiz: ah - nmicoud means bp bank accunt
nmicoud: yes
tbayen: Do you think it is better to create an IBAN field there and change some code to use it as an alternative to the AccountNo or is it better to write the IBAN in the AccountNo field (and make it a bit wider for that).
tbayen: ?
tbayen: There is an 1:1 relationship between iban and accountno. In germany the accountno is part of the iban.
CarlosRuiz: but both exists?
CarlosRuiz: if both exist then I think is better to have both
tbayen: You can extract the accountno from the iban and you can calculate the iban form the accountno and rountingno In most other countries too I think but this is not a law.
posde: and BIC
nmicoud: afair BIC is already on C_Bank
tbayen: In europe we change to iban at 2014-08-01. I do not know if anyone will care about the old AccountNo any more after that date. I think noone will.
tbayen: But some idempiere business logic cares. :)
nmicoud: think also about translations ; IBAN != account n° ; i would prefer to have both and hide 'old' ones
tbayen: So I will change business logic and interfaces if I see that they do not work with IBAN. Right?!?
CarlosRuiz: if can be derived from accountno maybe we don't need both fields - as you described they're interrelated
CarlosRuiz: but you know better about it
tbayen: The rule to calculate it is country-dependent. It will be much work to do this for all countries. And as I understand the standard it is not guaranteed that it can be calculated. I do not even know for sure if all countries can be calculated now.
CarlosRuiz: :-) in such case it sounds better to have independent field - sounds like dictionary core
CarlosRuiz: guys - got to go - I'll keep logging this session to publish it later
nmicoud: so - imho, those new fields should be linked to jira ticket 1200
CarlosRuiz: tbayen, week 2 of course was released - will need to go back to class
tbayen: ok. We will keep the AccountNo field that noone will use from August on. And you agree that I change business logic to use both fields where needed. Is this right?
tbayen: You will love me if in twenty years Colombia joins the european union. :^)
aguerra: hello every body!!!!
Not-002: [IDEMPIERE] hieplq updated IDEMPIERE-388
Not-002: [IDEMPIERE] Just memo. with gmail. use port 587, not 465
Not-002: [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-388
aguerra: if I download the verion 2 of the web, I have to apply i1.0z?
hieplq: hi aguerra. just i2.0. with develope branch add more i2.0z
aguerra: i got this error The program assumes build version 2.0.0.v20140124-2221, but database has build version ${env.ADEMPIERE_VERSION} 20080428-1232.
hieplq: it just is warning. you can use idempiere without worry about it
aguerra: ok ... thk a lot
aguerra: Sorry for the question, I wanted to know somebody knows how to export the menu tree of a development environment to production idempiere 2.0 or information howto
hieplq: maybe wrong. try import, export all record of "menu" window
nmicoud: i've try this some weeks ago and did not succedd. using 2Pack i've try to export as data type the content of AD_Menu and AD_TreeNodeMM (filtering on the correct AD_Tree_ID)
aguerra: nmicoud, how i can do that?
hieplq: Hi aguerra. open menu window. select export in menu. select file type is 2Pack
aguerra: hieplq, and Tree Maintenance?
hieplq: I don't know what's window for tree maintenance. but you can easy make new window with table AD_treeNodeMM
nmicoud: using 2 pack, you create a new package with 2 lines 1 - Type = data ; table = AD_Tree ; SQL = SELECT * FROM AD_Tree WHERE AD_Tree_ID = xxx 2 - Type = data ; table = AD_TreeNodeMM ; SQL= SELECT * FROM AD_TreeNodeMM WHERE AD_Tree_ID = xxx If it's not a success, could you please open a thread on google groups in order to share our experiences ?
aguerra: nmicoud, perfect!!!! thk a lot !!!!
nmicoud: yw ; but note that did not work for me. But imho, it should be
aguerra: I'll try and tell you
nmicoud: thanks
hieplq: wdyt a new feature "reset to factory setup". example, after use AD to customer some window, menu,.. I don't get best result. I just click reset to restore default setup (or prev save point)
nmicoud: would be hard to save everything. DB_Export and DB_Restore could do the trick, no ?
hieplq: DB_Export export all data. I want restore config data. backup and restore only table ralate to config data (AD data) is ok?
nmicoud: perhaps database could export only some tables ?