IDempiere/FullMeeting20120307
⇐ Table of Contents | Full Meeting Minutes | Full Meeting 2012-03-07
CarlosRuiz: Good morning
tbayen: Hi!
mindbender1: Hi CarlosRuiz
HarisHashim: Good morning
HarisHashim: .. err evening
mindbender1: Hi Everyone
emmie: Hi all!
CarlosRuiz: as usual - no agenda for the meeting
CarlosRuiz: just open chat for technical or functional discussions
CarlosRuiz: and I'll be checking pending JIRA issues in the meantime if there is no theme to chat :-)
emmie: well, I would like to talk about "patchs" and how to manage this issue
tbayen: I looked into the code for the JasperReports integration. Was this done by one person or is it code that grew over many steps? It seems to be worth to reorganize some things.
a42niem: hi all
CarlosRuiz: sure emmie - we can discuss
CarlosRuiz: tbayen - it was started somewhere for Compiere - we integrated it into Adempiere - and the it has grown with contributions from many
CarlosRuiz: emmie - how is your advance using getlistmodsrc.sh ?
hengsin: CarlosRuis, what's the topic ?
emmie: I downloaded the repo that you share me, I modified getlistmodsrc.sh
CarlosRuiz: hengsin, no fixed agenda - emmie wants to discuss about patches (for transition version) - and tbayen wrote it's worthy to reorganize some things on jasper integration
tbayen: The Jasper code has many special solutions.(for example URLs with https:, file:, resource: attachment:). I wonder if we need all these different codepaths that make it difficult to have a clean solution for loading of other files (subreports, images). Much of this code is nowwhere documented (but seems to work) But I know your opinion about backward compatibility.
hengsin: different codepath is not the issue, the issue is it is all mixed together.
emmie: but, when execute it, I have see a lots of "new files" in patches repo
tbayen: The other problem ist that it would take much time for me to test changes with URL types I do not use myself.
hengsin: we need to clean up the interface and separate the code path into different protocol implementation module
hengsin: well, that's part of the burden of an opensource world, you do have to test for things you don't actually use :) I've to do it all the times!
tbayen: hengsin, Yes, I would like to think about this. But we need the old code as "default" because I have no time (and see no sense) to implement and test old solutions I do not know of whether one person in the world is using it.
tbayen: If I reimplement ReportStarter.java and make some module to implement one kind of URL shall I do these things in the same package?
CarlosRuiz: tbayen, I think all of them are in use by different people - in my case the only one that I have never used is "resource:" (funny that I was who contributed that) :-)
hengsin: tbayen, that's not a requirement, if you want to refactor it, you are free to propose a new package structure.
hengsin: CarlosRuiz, do you think #2 of http://jira.idempiere.com/browse/IDEMPIERE-118 is a good idea ?
tbayen: I use only "resource" and can not see a reason to use the others. You are right - it's funny. Perhaps I can try to create a new "resource:" module and If I am finished we could together think how it can be transfered to the other ones. PErhaps You can help testing with real world examples.
hengsin: tbayen, we only use attachment: here, I think mostly contributed by me.
CarlosRuiz: tbayen, each one has its purpose - file is very useful when doing initial development, attachment is the easiest to send as deliverable for installation from a third party - lately I'm using http for reports shared in several servers
CarlosRuiz: hengsin, about "Average Costing: Negative inventory" - big issue
tbayen: Yes, I wanted to say I can not see a reason for me(!)
CarlosRuiz: will comment in jira ticket
tbayen: Thanks, I think my question is answered for the moment. I will think about it and tell you if I have some code that's worth looking into.
CarlosRuiz: sure tbayen - refactoring to clarify code is always a good thing - with the additional hassle of needing to test things being touched
CarlosRuiz: emmie - if you "pull -u" your repository - then the getlistmodsrc.sh must bring nothing - as I have executed and committed that very frequently
tbayen: In the first step I will try to touch only thinks I use myself.
tbayen: things
CarlosRuiz: yes tbayen - another option is you publish the patch and state which parts are not tested - and others can help with testing those parts
hengsin: CarlosRuiz, working on http://jira.idempiere.com/browse/IDEMPIERE-117 now, as usual, all comments are welcome.
emmie: no, I no pull in that way
CarlosRuiz: hengsin, I used M_CostDetail as the history table
emmie: I just clone your repo, I modified getlistmodsrc.sh to adapt it to my environment
emmie: and execute it...
CarlosRuiz: yep - you can execute "hg -v pull -u" in that repo periodically
emmie: when I have to do this "pull -u"?
CarlosRuiz: is to refresh your cloned repository with my changes
emmie: ah, ok
CarlosRuiz: hengsin, I used M_CostDetail for cost history in a custom implementation of average costing (very customized so it ended useless for contributing back to product)
CarlosRuiz: I needed to add some transactions to cost detail that were not being added
emmie: but, I suppose that this is not my problem...
CarlosRuiz: and I made a view from cost detail to show the "average costing kardex"
hengsin: you make any changes to m_costdetail ? it doesn't seems to have sufficient details to act as a history table.
CarlosRuiz: yes - I needed to add some trx that were missing
CarlosRuiz: and were needed for a kardex purpose
CarlosRuiz: emmie, it's right - executing getlistmodsrc.sh will create new files when they have not been patched before - and modify those that were already patched
emmie: well
emmie: so, after execute getlistmodsrc.sh
emmie: I try to generate jar
emmie: but I see that this jar file contains java source files too, is that correct?
CarlosRuiz: nope - not needed
CarlosRuiz: harmless, but not needed
emmie: I generate this jar with generaJar.jardesc
hengsin: CarlosRuiz, how do you sort m_costdetail to get a sequential movement view ?
emmie: ok, I will try to do that "as usual I do" (without .jardesc)
CarlosRuiz: strange - the jardesc states exportJavaFiles="false"
CarlosRuiz: hengsin -> order by m_costdetail_id did the trick
hengsin: CarlosRuiz - hmm, that also means the requirement to make sure all m_costdetail record is always process sequentially, I guess some additional changes need for that too ?
CarlosRuiz: yes - enabling cost immediate on client is required
CarlosRuiz: hengsin, about "Average Costing: Negative inventory" - I wrote the code to post negatives on the new account M_Product_Acct.P_AverageCostVariance
CarlosRuiz: but as I said it ended useless to contribute
CarlosRuiz: if you want I can pass that code to you for your analysis
CarlosRuiz: we also needed to cope with many other problems
CarlosRuiz: I implemented the "disallow negative inventory" (borrowed from Compiere) for warehouses
CarlosRuiz: but still you can have negative inventory in costing (even if you don't have it on warehouses)
CarlosRuiz: when the good are received and then delivered before matched
CarlosRuiz: in the end - I think the only way to manage that is posting the receipt with the price of the PO - and making it mandatory (you cannot receive goods without a previous PO)
CarlosRuiz: and then some consistency checks are needed - i.e. you cannot allow to change prices on PO (reopened) if the goods were already received
hengsin: when the good are received and then delivered before matched - my ideas is the accounting processor not to post the shipment when it detected that posting it will cause m_cost.currentqty to become negative
CarlosRuiz: but then you can have a problem for discontinued products - if they are never received again
hengsin: hmm ... shouldn't a negative stock situation should be corrected eventually ?
hengsin: discontinued doesn't means your stock level should be -ve
CarlosRuiz: yes - combined with the "disallow -ve inventory" it cannot happen
CarlosRuiz: negative in costing means not matched
CarlosRuiz: if we agree to post on receipt with PO price (and recalc cost there) - then matchinv is not needed and we would solve the problem
hengsin: yeah, not matched temporary but shouldn't that be resolved too later ?
CarlosRuiz: yes - hopefully the match will happen later - problem we found with that is that match could happen on next month
CarlosRuiz: WDYT about compelling some processes when using Average - i.e. if using average a receipt requires a PO - and PO price cannot be changed if the goods are already received
CarlosRuiz: IMHO that would solve the problem combined with the "disallow -ve inv" flag on warehouse
hengsin: do you means the situation where matchinv is needed for 2 way matching, i.e just recceiving and invoice, no po ?
CarlosRuiz: at this moment we accept receipts without a PO
CarlosRuiz: my proposal is to forbid that when using avg costing
CarlosRuiz: because we post receipts with PO price
hengsin: ok, no PO does make avg costing really difficult
hengsin: yeah, that sounds like a necessary constraint.
CarlosRuiz: match inv could still happen in case the invoice has a different price than PO - and in such case the posting will go to the P_AverageCostVariance account
hengsin: that one is simple, it is just a posting issue
CarlosRuiz: the problem then is to implement a mechanism to let the accountant move that variance to expenses (simple, a GL Journal can do that) - or to inventory (not simple, we need a doc to recalc costing)
hengsin: that should be a cost adjustment doc ?
CarlosRuiz: yes - could be
CarlosRuiz: I'm scheduled to add that
hengsin: i added the suggested cost history table structure to http://jira.idempiere.com/browse/IDEMPIERE-117 , overkill ?
CarlosRuiz: still don't get the difference with cost detail
a42niem: CarlosRuiz, some discussion on http://jira.idempiere.com/browse/IDEMPIERE-177 ?
hengsin: CarlosRuiz, it is just a simple table to capture the before and after value of m_cost. it make producing a cost movement view trivial at the expense of storage.
hengsin: i guess it is not needed if we can realiably produce that from m_costdetail
CarlosRuiz: well - we achieved to produce it from MCostDetail (with some changes as described)
CarlosRuiz: it was very difficult to let accountant understand why the order by cannot be dateacct :-)
CarlosRuiz: but finally we made it
CarlosRuiz: Hi Dirk, what if we use empty language as "all languages"
hengsin: note that with history table, it is also trivial to do a movement report for a date range
a42niem: Carlos, yes, makes sense
hengsin: CarlosRuiz, ok, can you share the your movement view somewhere so I can review it ?
CarlosRuiz: hengsin, that was tricky again - date range must be issued with the ProcessedOn date
CarlosRuiz: very tricky - if you change the order, then the calcs of the avgcost don't match
hengsin: CarlosRuiz, I'm just talking about reporting, not a recalc of cost :)
CarlosRuiz: yep
CarlosRuiz: I mean
CarlosRuiz: to let the report be consistent with the calculated cost
CarlosRuiz: you need to order by m_costdetail_id - and date ranges can break that
hengsin: I'm pointing out one of the motivation for the history table is the ease to produce cost movement report for a date range
CarlosRuiz: I'm fine with the history table - is harmless
CarlosRuiz: I don't see it useful for avg because m_costdetail is very similar
CarlosRuiz: but
CarlosRuiz: in standard costing
CarlosRuiz: can be very useful
CarlosRuiz: we don't have a mechanism to save changes on standard cost
hengsin: hmm .. isn't the date range reporting a useful thing to have ?
CarlosRuiz: yes - but I'm worried that date range can break the order by and make the numbers inconsistent
CarlosRuiz: it happened to us when developing the kardex
CarlosRuiz: hengsin, what do you think about IDEMPIERE-177 - Complete Window Customization functionality - contributed from Dirk - I tested and seems to be working fine - and backward compatible (if not filled nothing happens)
hengsin: alright, just to make it clear - the history record is save when the system process a m_costdetail record (MCostDetail.process), the old* value is captured at the start of the method and new* captured at the end of the method.
hengsin: I've not review iDempiere-177
a42niem: dumb question: how do i make a field read only ONLY after the record has been saved (like e.g. Client and Org behave in a window)?
CarlosRuiz: hengsin, what if we add the old* columns to M_CostDetail - it would have the same effect?
CarlosRuiz: a42niem, try the "updateable" flag
a42niem: silly me, thanks
hengsin: CarlosRuiz, just thinking separating reporting table from trx table might be a better for performance ?
hengsin: ok, so iDempiere-177 is to implement user customization using the existing ad_userdef* tables ?
CarlosRuiz: yes
hengsin: what would be the UI changes ?
CarlosRuiz: you can customize the behavior of a window/tab/field for a user or role or organization or company
CarlosRuiz: Dirk implemented it in java code, overwriting what is read from window/trl - tab/trl and ad_field_v/t
CarlosRuiz: and he implemented a precedence mechanism
CarlosRuiz: in case you have several customization records defined
CarlosRuiz: it goes from the most detailed (user) to the more general (client)
hengsin: so it is by editing directly records in the ad_userdef* table ?
banym1: hi all
CarlosRuiz: yes - adding records in window "Window Customization"
CarlosRuiz: Hi Dominik
hengsin: ic, so it is useful for implementor but not exactly a user facing tools then
a42niem: no, I see it useful for the client admin to change names or settings without needing the implementor
CarlosRuiz: yes - I think the idea is to allow changes of UI specific for tenant, org, role or user
CarlosRuiz: definitely not for end users - for client admin as Dirk stated - be implementor or IT people
a42niem: yes
hengsin: ok, that sounds good, +1 to integrate
a42niem: great
hengsin: now if some one will complete the ad_infowindow implementation will be great :)
CarlosRuiz: a42niem, do you want to work on the "optional lang" there? or want help on that?
a42niem: i think then it should go to the selection mechanism as well, WDYT?
CarlosRuiz: yep
a42niem: do you think caching is useful here? the repetition of the mechanism puts some burdon on window creation
CarlosRuiz: definitely
CarlosRuiz: I think you were caching it in the getAll method
CarlosRuiz: I thought
CarlosRuiz: ah no, not cached - yes definitely a good idea to save the array on the getAll
a42niem: how can i find out if cache reset has been used recently?
a42niem: otherwise the caching woul be valid until next logout i guess
CarlosRuiz: hmm - I don't have clear which caching is which
CarlosRuiz: the webui clear cache clear some tables - but some other requires a server clear cache
CarlosRuiz: it would be a good thing to document that
a42niem: process CacheReset calls Env.reset
CarlosRuiz: in this case it would be desirable to reset it with the webui clear cache
CarlosRuiz: so, you don't need to relogin
a42niem: so it could work using org.compiere.util.CacheMgt, i will look into that
CarlosRuiz: ok - I think is not necessary to upload the patches to JIRA if you have them on the pull request
CarlosRuiz: it confused me to know if they were equivalent :-)
a42niem: ok, it was just to give others the possibility to test
CarlosRuiz: sure - you can put a link to the pull-request
CarlosRuiz: https://bitbucket.org/CarlosRuiz_globalqss/adempiere361/pull-request/3/idempiere-177
CarlosRuiz: and is easy to extract the raw patches from there
CarlosRuiz: https://bitbucket.org/a42niem/adempiere361/changeset/d1a24c2e452c/raw/
a42niem: then i will use that in the future
CarlosRuiz: but I'm fine for whatever you prefer - just advising
CarlosRuiz: I've found the mechanism of pull request very useful
a42niem: yes, that makes it very easy to handle updates
CarlosRuiz: ok guys - I think we can declare this meeting ended - need to move out
CarlosRuiz: thanks a lot - it was a very good meeting touching many themes
CarlosRuiz: c u then - bye
CarlosRuiz: ah a42niem - one last thing before going
CarlosRuiz: if we make the language optional - then I think the Name columns must be optional too
CarlosRuiz: bye
