CarlosRuiz: full meeting

2013-10-16T17:27:25Z

full meeting

New page

⇐
[[IDempiere|Table of Contents]] |
[[IDempiere/Full Meeting Minutes|Full Meeting Minutes]] |
Full Meeting 2013-10-16


'''''CarlosRuiz''''': Good Morning 
'''''PedroRozo''''': Good Morning Carlos and group 
'''''nmicoud''''': Bonjour 
'''''nmicoud''''': Any idea for this https://groups.google.com/forum/?fromgroups#!topic/idempiere/o8F3HIKo2yo ? 
'''''tbayen''''': Daarestiet! 
'''''CarlosRuiz''''': Hi Thomas 
'''''CarlosRuiz''''': nmicoud, what do you mean with reactivate? 
'''''nmicoud''''': i complete a payment and then i find an error ; so i want to reactivate it in order to change something (date, amt, ...) and then complete it again 
'''''CarlosRuiz''''': I think the easiest way is to do it in a model validator 
'''''norbertbede''''': hi all 
'''''nmicoud''''': no, because, MPayment.reactivateIt generate a countrr document 
'''''nmicoud''''': i have to overwrite the method 
'''''CarlosRuiz''''': so, you don't want to reactivate it - what you want is to enable changing some fields on a completed doc 
'''''CarlosRuiz''''': I was doing a POC for something similar 
'''''CarlosRuiz''''': for https://idempiere.atlassian.net/browse/IDEMPIERE-149 
'''''CarlosRuiz''''': after analyzing the business cases of IDEMPIERE-149 we arrived to the conclusion that most of reversals are not needed - and we could allow changing some harmless info on completed docs 
'''''CarlosRuiz''''': the issue is to define which fields are "safe" - what is the scope of such "safety" - and processing the impact of changing a field - for example reposting acct if you change the date 
'''''ocurieles_dcs''''': Hi to all :D 
'''''nmicoud''''': i guess safe fields are those which have no impact on accounting ; like SalesRep on invoices 
'''''CarlosRuiz''''': I did a POC implementing a button that opened a form with the fields allowed to be changed 
'''''CarlosRuiz''''': Hi Orlando 
'''''nmicoud''''': but description should be not safe as it is used for description on Fact_Acct 
'''''CarlosRuiz''''': even impacting accounting is safe if the period is still open 
'''''CarlosRuiz''''': description field is always updatable on most documents 
'''''nmicoud''''': that lead to issues because people change it after posting docs and don't see the 'new' description on Fact_Acct 
'''''nmicoud''''': perhaps those safe/not safe fields could do what i want 
'''''tbayen''''': Is my understanding true that accounting fact lines are never changed or deleted? Things like voiding, storno, etc. always create new lines. True? 
'''''nmicoud''''': yes 
'''''nmicoud''''': there is no update on fact_acct 
'''''nmicoud''''': only insert or delete 
'''''tbayen''''': delete? In which case are fact lines deleted? 
'''''nmicoud''''': when you repost a document, lines are deleted and then inserted 
'''''CarlosRuiz''''': nmicoud, I'll try to find the POC I did (it was some time ago) and upload a proposal there to gather community ideas 
'''''nmicoud''''': or when you launch the ResetFactAcct process 
'''''nmicoud''''': ok Carlos, thanks 
'''''nmicoud''''': another subject ;) ; i installed red1's plugin for ui mobile. And i was wondering if a list could be added on AD_Role. So that we can reserve some role to swing or web or mobile or future Android app ? 
'''''CarlosRuiz''''': a list? 
'''''nmicoud''''': so we can affect a role to a single way of login ; eg, role A is for swing only, role B is for web and role C is for mobile ; D is for all 
'''''nmicoud''''': and then on login panels we only display the available roles 
'''''nmicoud''''': as some stuff are not available in mobile or in swing, it could lead to error to show them in menu and role 
'''''CarlosRuiz''''': swing vs zk I think is just a few forms 
'''''nmicoud''''': and info windows 
'''''nmicoud''''': and new designs for window 
'''''CarlosRuiz''''': yes - but info windows and general windows keep working without problem 
'''''nmicoud''''': yes 
'''''CarlosRuiz''''': maybe mobile plugin can add a column AD_Role.IsMobileEnabled 
'''''nmicoud''''': it was my 1st idea 
'''''nmicoud''''': and i was thinking of a more general stuff 
'''''nmicoud''''': but AD_Role.IsMobileEnabled will do the job 
'''''aguerra''''': hi for everybody !!!! 
'''''nmicoud''''': hi 
'''''CarlosRuiz''''': hi 
'''''ocurieles_dcs''''': hi 
'''''ocurieles_dcs''''': @CarlosRuiz, we have created a form to pay multiple invoices with multiple payment methods, I think it would be interesting to integrate the core 
'''''CarlosRuiz''''': it sounds good - a plugin? 
'''''ocurieles_dcs''''': also another form to enter a product serial massively at a reception or physical inventory 
'''''ocurieles_dcs''''': yes a plugin 
'''''CarlosRuiz''''': with barcode scanner? 
'''''ocurieles_dcs''''': yes 
'''''CarlosRuiz''''': excellent! 
'''''ocurieles_dcs''''': I see it more as an improvement of the core 
'''''CarlosRuiz''''': probably it is - just that released initially as plugin is easier for anybody to test and vote - if it's already done as plugin then it will be very easy to publish 
'''''aguerra''''': vote 1 
'''''CarlosRuiz''''': time to setup an "idempiere market" 
'''''CarlosRuiz''''': :-) 
'''''ocurieles_dcs''''': sure 
'''''CarlosRuiz''''': I think it would be great if you can open a JIRA ticket and attach there code or URLs pointing to repos - and screenshots if you prefer too 
'''''PedroRozo''''': Carlos/group is there any central wiki for those new plugins/extensions/verticals .. so we can start to publish as well ? 
'''''CarlosRuiz''''': not yet - good idea at least start with a wiki page with those - meanwhile we have a more formal solution 
'''''ocurieles_dcs''''': https://bitbucket.org/dcs_bitbucket/serial-plugin/admin 
'''''ocurieles_dcs''''': ok no problem 
'''''ocurieles_dcs''''': maybe in the wiki - plugins 
'''''CarlosRuiz''''': maybe http://wiki.idempiere.org/en/Category:AvailablePlugins ? 
'''''ocurieles_dcs''''': sound good 
'''''ocurieles_dcs''''': Ready http://wiki.idempiere.org/en/Category:AvailablePlugins 
'''''ocurieles_dcs''''': i write the intro and put some plugins to start 
'''''CarlosRuiz''''': I think we can also provide a service on ci.idempiere.org to compile and publish p2 repos for open plugins 
'''''PedroRozo''''': good .. we will publish there as well ... 
'''''CarlosRuiz''''': maybe a template for published plugin pages is good too 
'''''CarlosRuiz''''': company/developer - URL for sources - URL to download - URL to p2 repo if available - install instructions (if something else is needed beyond install)- basic documentation (or link to) ... 
'''''CarlosRuiz''''': I think in a marketplace is very important people to add comments and "rate the plugin and service" 
'''''ocurieles_dcs''''': yes 1+ 
'''''ocurieles_dcs''''': letś rock 
'''''ocurieles_dcs''''': Carlos can you check the jira ticket 1436 
'''''CarlosRuiz''''': maybe something like 
'''''CarlosRuiz''''': http://primelife.ercim.eu/results/opensource/57-mediawiki-reputation-extension 
'''''ocurieles_dcs''''': Angel attach the code to solve this issue 
'''''ocurieles_dcs''''': you answer this: Seems like a Duplicate of IDEMPIERE-775 
'''''CarlosRuiz''''': I reviewed yesterday and marked it as duplicate 
'''''CarlosRuiz''''': GL Distribution is an independent process - I think Doc_ classes must not take care of distribution 
'''''ocurieles_dcs''''': yes but the other ticket don't have solution 
'''''CarlosRuiz''''': we tested a solution on one customer - adding C_DocType_ID as a virtual column and AFAIR it needed a minor fix to work 
'''''CarlosRuiz''''': but it could be also to hardcode the getC_DocType_ID for those 7 documents 
'''''nmicoud''''': and why not adding a 'real' column C_DocType_ID ? 
'''''CarlosRuiz''''': feasible too - just that is more work 
'''''nmicoud''''': eg: for some accounting reports, i need to display the translated name of the document ; no problem when it is invoices, payments, ... and when it is bank statement or allocation => hardcoded 
'''''CarlosRuiz''''': I guess JJ design is that those are not really documents - but link/match relations 
'''''nmicoud''''': would be easier for everybody to add it (and use the IsDefault column on C_DocType to determine how to fill value) 
'''''nmicoud''''': right 
'''''CarlosRuiz''''': the C_DocType_ID virtual column solution worked - but I don't recommend it 
'''''CarlosRuiz''''': the needed work to add those 7 C_DocType_ID columns: 
'''''CarlosRuiz''''': - migration script for the 7 new columns 
'''''CarlosRuiz''''': - migration script to fill existent records 
'''''CarlosRuiz''''': - then make the new columns mandatory 
'''''CarlosRuiz''''': - change code to fill with the default as NMicoud suggested 
'''''CarlosRuiz''''': - change rv_unposted and maybe rv_unprocessed? 
'''''CarlosRuiz''''': am I forgotting something? 
'''''nmicoud''''': > check to have a single record for those table in c_doctype ? 
'''''nmicoud''''': update gardenworld ? 
'''''CarlosRuiz''''': maybe we can allow multiple doctypes - just use the default if there are several 
'''''CarlosRuiz''''': thinking that maybe extensions could use a non-default doctype for something 
'''''CarlosRuiz''''': gardenworld would be updated with the script to fill existent records 
'''''nmicoud''''': what i meant was : a single (and not 0) doctype should be marked as isDefault 
'''''CarlosRuiz''''': yep 
'''''nmicoud''''': ok, just to be sure :) 
'''''CarlosRuiz''''': seems like rv_unposted and rv_unprocessed don't have that column 
'''''CarlosRuiz''''': neither rv_fact_acct 
'''''CarlosRuiz''''': ah - here are summarized the rating extensions 
'''''CarlosRuiz''''': http://www.mediawiki.org/wiki/Category:Rating_extensions 
'''''ocurieles_dcs''''': what we need to do this ? 
'''''CarlosRuiz''''': ? 
'''''ocurieles_dcs''''': to create the website 
'''''ocurieles_dcs''''': and do it ? 
'''''ocurieles_dcs''''': I can provide the hosting 
'''''ocurieles_dcs''''': and a resource to develop the site 
'''''ocurieles_dcs''''': wdyt? 
'''''CarlosRuiz''''': I don't have experience with such apps 
'''''CarlosRuiz''''': IMHO it sounds great - but if it's too much work I would start simple - maybe categorization/comments/ratings on wiki 
'''''CarlosRuiz''''': it needs some administrative work to avoid what happens with adempiere wiki 
'''''CarlosRuiz''''': where most people put company names there contributing zero to the project 
'''''CarlosRuiz''''': so - some administrative work to at least check the plugins are real - and have open source code published 
'''''CarlosRuiz''''': about the rating extension on wiki - maybe tbayen can ask Thomas Thiessen if is feasible to test some 
'''''tbayen''''': I can install this but atm I have no time for testing. 
'''''CarlosRuiz''''': I think talk page is enough for feedback/comments 
'''''CarlosRuiz''''': and rating can be with reputation extension - or this one http://www.mediawiki.org/wiki/Extension:W4G_Rating_Bar 
'''''tbayen''''': I like the idea to use things we already have like wiki and such but if ocurieles_dcs prefers to spend his resources to do it in another way we should talk about what is best. 
'''''CarlosRuiz''''': sure - I'm not against something better :-) 
'''''ocurieles_dcs''''': @ tbayen the ideal is not wasting resources, we can use the wiki and a remedy to keep the day our site 
'''''ocurieles_dcs''''': maybe the first plugin placing people excited and there is a lot of work in this 
'''''ocurieles_dcs''''': @tbayen and @CarlosRuiz just start with something simple, I'll talk this afternoon with one of my employees to coordinate this 
'''''aguerra''''': I can help Mr ocurieles 
'''''tbayen''''': A wiki based solution will at least be good as a prototype. We can build a template for description, documentation, discussion etc. and learn how to do it best. When we have this for some months and some plugins we could see if we need a more specialized software. 
'''''tbayen''''': If you need a mediawiki plugin for that please contact me. 
'''''CarlosRuiz''''': I have already three plugins to put there :-) LCO 
'''''ocurieles_dcs''''': We also have some payroll, LVE and some improvements we created as plugin 
'''''ocurieles_dcs''''': thanks @tbayen sure 
'''''tbayen''''': I like the idea of a rating extension in the wiki. The Rating bar looks cool but I did not review all possibilities. ocurieles_dcs, please can you review the rating extension and choose one to install which fits best your needs. 
'''''CarlosRuiz''''': there are a lot obsolete - or with obsolete prerequisites 
'''''ocurieles_dcs''''': ok, let me check 
'''''aguerra''''': Mr CarlosRuiz What do those 3 plugin?? 
'''''CarlosRuiz''''': https://groups.google.com/d/msg/idempiere/rJkTL_C6-3I/9rnSkL2JPt8J 
'''''ocurieles_dcs''''': some plans for the 2014 idempiere conference ? 
'''''xolali''''': brazil 2014 it must be 
'''''aguerra''''': Venezuela margarita island :-) 
'''''ocurieles_dcs''''': noo Venezuela Noooo 
'''''tbayen''''': ocurieles_dcs, where do you come from? 
'''''ocurieles_dcs''''': hahaha i wanna I want to get away from my wife 
'''''ocurieles_dcs''''': I want to get away from my wife 
'''''ocurieles_dcs''''': I From Venezuela @tbayen 
'''''ocurieles_dcs''''': Neighbor Carlos 
'''''aguerra''''': I like too!!! 
'''''CarlosRuiz''''': :-D Hope your wife don't read the meeting logs :-D 
'''''tbayen''''': ah, ok. I understand that. It had pres and cons to have my wife with the conference. ;-) I believe most visitors liked the "pre"s. Perhaps we should attract more female programmers. ;-) 
'''''ocurieles_dcs''''': but we need to plan ahead for a currency problem we have in our country 
'''''aguerra''''': for us, not for them!!! 
'''''xolali''''': am thinking this time around a conference in south america will be great because of the user base there 
'''''tbayen''''': xolali, after last conference we said next in Brazil and then in Ghana. Isn't it true? 
'''''xolali''''': an brazil comes to mind because there is a world cup and we can have a conference and also enjoy the atmosphere 
'''''xolali''''': Yes @tbayen 
'''''ocurieles_dcs''''': I like the idea of brazil, then with more reason you have to plan ahead for the World Cup will be difficult to find accommodation 
'''''tbayen''''': Hmmm... I do not like to mix the conference and the world cup. Hotels will be expensive and the attention will be parted. But I would give this decision to someone who wants to invite us. 
'''''ocurieles_dcs''''': yeah is complicated 
'''''ocurieles_dcs''''': Maybe in Colombia ? WDYT @CarlosRuiz ??? 
'''''xolali''''': Yeah, thats true accomodation will be expensive. Well, we need a host in brazil first then we can sort out the rest 
'''''CarlosRuiz''''': Colombia classified to world cup - but I would not talk technical there :-DDD 
'''''ocurieles_dcs''''': or USA.. 
'''''aguerra''''': ok San Francisco ? 
'''''ocurieles_dcs''''': Wherever it is, this time NOT lose me 
'''''tbayen''''': I have to say that on normal conferences Carlos always wants to code the whole day! 
'''''CarlosRuiz''''': hahahahaha 
'''''xolali''''': we need a host first, someone who will invite us. Thomas was great the last time. Organisation is key 
'''''CarlosRuiz''''': tbayen wanted me to code all day - but I just wanted to taste german beers :-D 
'''''ocurieles_dcs''''': hey come back to work, this is the multi-payment plugin https://bitbucket.org/dcs_bitbucket/multipayment-plugin 
'''''tbayen''''': CarlosRuiz, I read IDEMPIERE-149. There is definitely a market for such a functionality. But this does not conform to laws and accounting rules. (This is the reason why there is a market.) You should not do this in core but as a plugin. 
'''''ocurieles_dcs''''': @aguerra maybe in Germany will can drink something 
'''''CarlosRuiz''''': Orlando - I'm glad you're publishing real open source here 
'''''CarlosRuiz''''': https://bitbucket.org/dcs_bitbucket 
'''''CarlosRuiz''''': tbayen, my idea is to make it configurable 
'''''CarlosRuiz''''': is just if you allow - and the fields you allow - and applying the consequences you define 
'''''CarlosRuiz''''': and fields must be open under certain conditions 
'''''CarlosRuiz''''': I didn't find a good way to model it - the rules are too per-each-implementation 
'''''tbayen''''': I do not talk about changing some fields under some circumstances. IDEMPIERE-149 is about the disapperance of a whole invoice, isn't it? 
'''''CarlosRuiz''''': so, in the end I thought it can be modeled as a plugin - search which fields are modifiable based on pluggable java code 
'''''CarlosRuiz''''': yes - we changed the scope of that one 
'''''CarlosRuiz''''': I mean - in a POC we discussed what is the root cause of having hundreds of reversed documents on a typical starting implementation 
'''''CarlosRuiz''''': and even hundreds also on established implementations too 
'''''ocurieles_dcs''''': @CarlosRuiz thanks, this is nothing compared with your work 
'''''tbayen''''': Many people are interested in letting Invoices disappear but you should not propagate this possibility and let this function not open in a standard configuration. So if someone activates it to break the law he has to do it by his own purpose and not by accident. 
'''''CarlosRuiz''''': we thought the root cause is about doing some minor changes to harmless (or at least controllable) fields that are not allowed by the application 
'''''CarlosRuiz''''': if we open the ability to change completed docs - in a controlled way - then we expect the reversed documents will dramatically decrease 
'''''tbayen''''': You are right - as a programmer, implementor and tester I see the problem of hundreds of wrong Invoices. But as an studies accountant and with knowledge of germany tax laws I am frightened. 
'''''CarlosRuiz''''': reversed documents are not a problem - they work fine - and I'm fine with them - but having hundreds of reversed documents just because the activity field was left empty - make a lot complex the accounting revision 
'''''tbayen''''': And as a tax payer I am hopeful. ;-) Haha! 
'''''tbayen''''': There is no easy way to connect the reversed documents and filter them out. What if there is a kind of matchcode in the accounting facts so you can identify the original and reversed documents and filter them for normal output. (Or you could even delete these lines if you are really brave). 
'''''CarlosRuiz''''': there is an easy way - I think there is a reversal_id on those tables 
'''''tbayen''''': add one column to the accounting facts "reverseline" with a reference to the exact same but reversed accounting fact line. 
'''''tbayen''''': I think the reversal_id is in the invoice, not in the accounting facts. Perhaps the accounting facts view has to be extended. 
'''''tbayen''''': But there are so many types of documents to get the reverse_id from. This will be a rather complicated view. 
'''''norbertbede''''': @carlos - nominate next topic to discuss: preventive maintenance module integration to the core 
'''''norbertbede''''': are someone tested interested on this ? 
'''''norbertbede''''': i playing with it - and plan to make repair order solution 
'''''norbertbede''''': but some objects should be reusable 
'''''norbertbede''''': what others say to that suggestion ? 
'''''CarlosRuiz''''': IMHO it sounds perfect for an extension 
'''''norbertbede''''': ok. it's ok. but then what i miss here at extensions, missing common software concept 
'''''norbertbede''''': so lot of people create solutions and not reuse existing well implemented components to resources, requeste, wflow etc 
'''''norbertbede''''': just create a one more plugin 
'''''norbertbede''''': lets say 
'''''norbertbede''''': i analyse how to implement idempiere at service-repair company for agro-equipments. 
'''''norbertbede''''': i did the realisation study 
'''''norbertbede''''': and looks lot of components are allready in the system but missing small some elements 
'''''CarlosRuiz''''': you can add those specific elements in the extension 
'''''norbertbede''''': e.g. project module with a facelifting has lot of parts - so why to create new one - just create on top of PM module window repair orders and make missing wowkflows and fit behaviours to reqs 
'''''norbertbede''''': ok. 
'''''norbertbede''''': that also mean community not plan to improve existing components for other verticals ? or make it better 
'''''norbertbede''''': i tried talk yesterday with red1 about the mentioned maintenance module and we failed, at the end i got a presentation about plugins 
'''''norbertbede''''': want to talk on right platform discusss about business features 
'''''norbertbede''''': really neaded move forward ID to the first class sw not only at technology level 
'''''norbertbede''''': i believe i'm not too silly here 
'''''norbertbede''''': with my ideas 
'''''tbayen''''': It is the question to do your improvements the right way (the plugin way). I feel there is a lack of documentation how to do it right to turn your own database customizations into a plugin. 
'''''norbertbede''''': in my case - preventive maintenance - the concept is good direction but no really usable. needs lot of improvement. so ia can improve it and nominate it to update or waht 
'''''xolali''''': it will be good if you have a use case documentation. then someone can help with the plugin 
'''''edilsondneto''''': heloo, my friends 
'''''tbayen''''': Hi edilsondneto! :-) 
'''''CarlosRuiz''''': Hi Edilson 
'''''CarlosRuiz''''': norbertbede, I think you're right about it can become messy and it could be more ordered if people construct over already created plugins 
'''''CarlosRuiz''''': that's precisely why I decided to split the LCO in three independent plugins 
'''''CarlosRuiz''''': to make at least two of them fully reusable in other countries 
'''''xolali''''': hi edilson 
'''''norbertbede''''': if that plugin approach is prio1 then need more docs, and marketplace 
'''''norbertbede''''': with explanation 
'''''norbertbede''''': is initiative on that ? 
'''''norbertbede''''': because people will see what exists what not, documentation layouts should be standardised etc. 
'''''norbertbede''''': aka salesforce.com marketplace 
'''''norbertbede''''': that should be done on top of WP plugins 
'''''norbertbede''''': lets talk 
'''''CarlosRuiz''''': yep - that was talked in today's meeting - ocurieles_dcs volunteered to start a wiki category and check rating system 
'''''ocurieles_dcs''''': hi @norbert 
'''''norbertbede''''': hi 
'''''ocurieles_dcs''''': hi @norbertbede is time to create a plugin marketplace 
'''''ocurieles_dcs''''': this is our repo https://bitbucket.org/dcs_bitbucket for plugins 
'''''ocurieles_dcs''''': you can reuse that, but nobody know about that. 
'''''norbertbede''''': first important think is define meta structure which could describe the plugin not just for cool developers but also for business consultants 
'''''ocurieles_dcs''''': where is @red1... red1 fell asleep 
'''''norbertbede''''': like name, author, business reqirements, processes covered, how to meet standard idempiere, version, forum, rating, reviews 
'''''norbertbede''''': etc 
'''''ocurieles_dcs''''': has a birthday hangover 
'''''ocurieles_dcs''''': sure that we talk early 
'''''tbayen''''': The plugin pages should be only for business consultants, implementors and users. The developer pages should be linked. But they are extra pages. Developer pages are much older and written in an indivudual style of the developer. The plugin description pages should be in a common, unified style. 
'''''ocurieles_dcs''''': I agree 
'''''ocurieles_dcs''''': for humans :D 
'''''norbertbede1''''': like me

IDempiere/FullMeeting20131016 - Revision history

CarlosRuiz: full meeting