IDempiere/FullMeeting20131016

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