CarlosRuiz: full meeting

2012-03-07T15:22:03Z

full meeting

New page

⇐
[[IDempiere|Table of Contents]] |
[[IDempiere/Full Meeting Minutes|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

IDempiere/FullMeeting20120307 - Revision history

CarlosRuiz: full meeting