CC Meeting Full 20070123

From ADempiere ERP Wiki
Jump to navigationJump to search

<hengsin> hi carlos, u have any agenda ?
<CarlosRuiz> Hi Hengsin, and everybody :-)
<CarlosRuiz> no, I don't have an agenda, the objective is to discuss sf trackers as you proposed initially
<hengsin> ic, I think we need to talk about how to reach 3.2, are we ready for that ...
<CarlosRuiz> let's wait just 3 minutes if others join
<hengsin> ok
-->| kontro ( has joined #adempiere-team
-->| kman (n=kman@ has joined #adempiere-team
-->| vpj-cd (n=vpj-cd@ has joined #adempiere-team
<vpj-cd> Hi
-->| moyses (n=moy@ has joined #adempiere-team
<hengsin> hi victor
<vpj-cd> You are here
<CarlosRuiz> Hi Victor, Karsten, Moyses and kman
<moyses> Hi all!
<CarlosRuiz> ok, we can start
<vpj-cd> hi everybody
<vpj-cd> yes
<karsten-thiemann> hey ho - let's go
<teo_sarca> hi all
=== vpj-cd is online.
<CarlosRuiz> we have 156 trackers open
<vpj-cd> ok
<hengsin> and most with priority 5 :)
<vpj-cd> ok
<teo_sarca> because is default :)
<vpj-cd> I review now
<CarlosRuiz> ok, there are a lot of bugs brought from Compiere 253b
<karsten-thiemann> 84 bugs
<CarlosRuiz> most of them I found don't apply for current trunk
<CarlosRuiz> they were solved by Compiere in 253d
<hengsin> carlos, so we can just close those ?
<vpj-cd> then we only need move from compiere?
<CarlosRuiz> it's moved because 311 started from 260a
<CarlosRuiz> we can take two paths:
<CarlosRuiz> verify one by one if Compiere have the patch closed because fixed in 253d or later
<vpj-cd> I think only the report by phib
<vpj-cd> are from compiere
<CarlosRuiz> yes, there are 29 bugs open reported by phib
<vpj-cd> another are of adempiere improves
<CarlosRuiz> or we can just close it and start working on new bugs
<CarlosRuiz> (sorry phib, I know that this was a hard work)  :-(
<CarlosRuiz> what do you think?
<CarlosRuiz> but none of them are closed in Compiere, i.e.
<vpj-cd> I am review
<CarlosRuiz> but none of them = but not all of them
<hengsin> carlos, I think those that are still open is not fix yet
<vpj-cd> all the traker from phib have the link to compiere
<vpj-cd> then we can review if this is fixed
<vpj-cd> and get the patch from compiere
<teo_sarca> does anybody identify some open bugs that actualy work ?
<vpj-cd> if this do not fixed then we need solve the problem
<hengsin> yes, what victor say should work.
<vpj-cd> ok then we need help the community
<CarlosRuiz> if it's fixed before 260a we have already the patch
<vpj-cd> we have pach the bug that this fixed in compiere
<vpj-cd> Fernando can review and patch from compiere
<vpj-cd> but we need somebody to make the last test
<vpj-cd> maybe somebody can to help
<moyses> I can help to test it...
<vpj-cd> Carlos , Low , and Me can fixed the adempiere bug
<CarlosRuiz> so, the task is something like:
<CarlosRuiz> a) if bug if closed in Compiere as fixed before 260a -> close it in Adempiere
<CarlosRuiz> b) if bug is opened -> left open in Adempiere
<CarlosRuiz> c) if bug is closed after 260a -> try to bring the patch
<vpj-cd> I review with Moyses
<hengsin> for c), I think it is safer, first upload the patch to the tracker item so we can review it first.
<vpj-cd> and we think all from have problem with management of transaction
<vpj-cd> this do not managent the transaction
<CarlosRuiz> but Compiere don't release the patch, this is a research task
<vpj-cd> is is severe problem when you use multi user
<vpj-cd> yes Carlos
<vpj-cd> we have access to svn from compiere
<vpj-cd> Fernando can set the diff and I and another can review if this is solve
<CarlosRuiz> ok, good
<hengsin> yes, carlos, we do a svn diff and upload to tracker for review
<vpj-cd> ok
<CarlosRuiz> ok
<vpj-cd> Low you told in the pass
<vpj-cd> the problem with the form is JJ o not control the transaction
<CarlosRuiz> BTW, talking about this
<CarlosRuiz> are we going to keep in sync with Compiere bugs?
<hengsin> many consistency issue ...
<vpj-cd> I think we should have 3.2 more stable that compiere
<vpj-cd> then I think we can release 3.1.4 to start the QA cicle with community
<vpj-cd> we can wait 2 or week
<CarlosRuiz> what I mean is
<vpj-cd> 3 week to receipt bugs
<vpj-cd> and release 3.2
<CarlosRuiz> I see 129 opened bugs on Compiere after 2006-09-24 (the date where phib made the task)
<vpj-cd> I think after this we have a version more stable that compiere
<CarlosRuiz> for sure Adempiere inherited most of those bugs and they are not fixed in Adempiere
<moyses> wow just 129 bugs opened... indeed we inherit them!
<karsten-thiemann> so we have to review and solve them
<vpj-cd> ok then we need
<vpj-cd> move to adempiere
<vpj-cd> the tracker
<karsten-thiemann> perhaps it would be good to identify the critical bugs first
<vpj-cd> and give a priority
<vpj-cd> yes karsten
<vpj-cd> is import we can give more time critical bugs
<vpj-cd> we can set priority 7 the critical bugs
<CarlosRuiz> ok, here the task is similar what phib did
<CarlosRuiz> but maybe enhanced
<vpj-cd> I think that Ramiro and Moyses can help to set the priority
<Ramiro> no problem
<CarlosRuiz> look for Compiere bug, test in Adempiere to replicate and open the bug if can be replicated
<vpj-cd> but we need see if they have time to this work :-)
<Ramiro> i can help doing that
<vpj-cd> Ramiro we want move all the open bug
<vpj-cd> from compiere
<CarlosRuiz> Victor, not just open bugs
<moyses> I can help with testing, opening and assigning bugs
<Ramiro> there are hundreds open in compiere
<vpj-cd> but we need ppl with know functional
<CarlosRuiz> I searched bugs opened since 2006-09-24 - open and closed
<vpj-cd> yes only open bugs
<moyses> who is going to fix it?
<vpj-cd> is rigth
<moyses> so how can we know the one responsible for fixing the bug
<vpj-cd> the I think first need move to adempiere and set a priority
<vpj-cd> then I think that Moyses and Ramiro have know to review
<vpj-cd> if is a severe bug
<CarlosRuiz> I think is better if the bug can be replicated in Adempiere before opening here
<vpj-cd> yes carlos is good idea
<CarlosRuiz> one big question: are we going to keep in sync the CM module?
<hengsin> hmm .. how does that work ?
<vpj-cd> mmm I know not if exist any improve
<CarlosRuiz> because there are a lot of bugs and enhancements on CM
<CarlosRuiz> yes, it has been improved since 260a
<vpj-cd> ok but I review and migrate
<vpj-cd> from 260a
<vpj-cd> the only need sync with 260b or
<vpj-cd> d
<CarlosRuiz> or we can work in CM just when someone is interested in
<vpj-cd> but I thimk the it do not is import now
<vpj-cd> no is critical
<hengsin> carlos, probably should based on commitment, if there are people willing to help
<vpj-cd> we can make this work after
<Ramiro> CM is just a nice to have feature
-->| vclark ( has joined #adempiere-team
<vpj-cd> yes include the chat
<CarlosRuiz> ok, so CM is not of our interest at this moment, we can delay the maintenance of this feature
<Ramiro> I really do not understand why Compiere develop it when there was so many areas for improvement
<vpj-cd> the CM is the a partner
<hengsin> carlos, for module that need maintainer, we can post to developer/open discussion forum looking for volunteer
<vpj-cd> the germany
<vclark> Hello everyone. I just joined.
<CarlosRuiz> Hi Vince
<vpj-cd> hello vincen
<vpj-cd> vince
<teo_sarca> hello
<vclark> CM was contributed by a partner in Germany
<CarlosRuiz> ok Hengsin, volunteer, or sponsor is ok
<Ramiro> that explains it
<vclark> Apparently a good relationship with Jorg because he doesn't normally take contribs.
<vpj-cd> yes we told the if is nessesary
<vpj-cd> to sync with compiere
<vpj-cd> or we can give time to open bug the compiere
<vpj-cd> I think is more important solve the sever but to functionality critical
<vpj-cd> the bug that have a impact in the main functionality
<hengsin> my take is we need first to prioritise the open bug in adempiere tracker
<CarlosRuiz> ok, so we have a new task of:
<CarlosRuiz> a) reviewing opened bugs in Compiere since 2006-09-24 (open and closed), testing in Adempiere if it can be replicated here
<CarlosRuiz> b) if closed try to bring the patch and open in Adempiere
<CarlosRuiz> c) if open in Compiere create the patch in Adempiere
<CarlosRuiz> another question:
<CarlosRuiz> are we going to do this same task periodically ?
<hengsin> yes, carlos, probably a good idea
<CarlosRuiz> it's better if someone keep monitoring compiere bugs and trying to replicate them here
<vclark> Victor - what do you mean by "fix the server?" Is there something specific that is critical, or are you speaking generally that it needs to be improved/better used.
-->| jsSolutions ( has joined #adempiere-team
<karsten-thiemann> and we need the possebility to patch an existing 3.2 version after we published it
<vclark> Definitely need patching of released versions. This has been a problem with Compiere.
<hengsin> yes, we should have 3.2.1, 3.2.2 etc ..
<vpj-cd> the critical bug are the cause some problem in the functionality
<vpj-cd> ie payment
<vpj-cd> shipment
<CarlosRuiz> yes, I think we can do that patching on tags
<vpj-cd> or accounting
<Ramiro> what problem is that victor?
<vpj-cd> ie I review with Moyses
<vpj-cd> the Shipment Manual
<vpj-cd> and Invoice Manual
<vpj-cd> JJ do not control of transaction
<moyses> those are critical problems...
<vclark> Are you talking about the generation processes?
<vpj-cd> then if you have 2 user with the same windows
<vpj-cd> the transaction are merge
<hengsin> victor, is that in the tracker ?
<Ramiro> who is the culprit within adempiere? what process?
<moyses> yes hengsin
<moyses> is in the tracker
<vclark> We have had problems in the past in high volume environments with workflows getting stuck. We got lots of corrupt data in M_InOut, like the wrong lines with headers. We thought it was related to workflow but maybe the problem you are stating here? Transactions merging?
<vpj-cd> the I think this problem exist all form
<moyses> yes vclark it sounds similar...
<hengsin> 'adempiere do not lock the registers' -> what does this mean ?
<vclark> Lock the records?
<Ramiro> sounds like a priority 7 to me
<karsten-thiemann> right
<vpj-cd> yes but Low fixed very this problem
<vpj-cd> I think is bat management the trasaction
<vpj-cd> I review and Low fixed and pach very problem with transaction
<vclark> I'm no Java architect, but I think "processing = 'Y' " is not real transaction management.
<vpj-cd> the problem is very transaction do not look
<hengsin> vclark, that should work as it is using database lock
<vpj-cd> lock
<vpj-cd> yes
<vpj-cd> I think the class trx made this work
<CarlosRuiz> I'm looking at line 397 and the trnxname and trx = null
<vpj-cd> yes he create a new transaction
<vpj-cd> the problem is when call the another process
<vpj-cd> a user can see the data from data base
<vpj-cd> same orden
<CarlosRuiz> no, if trxname is null, a generic transaction is used
<vpj-cd> this is see to 2 user same time
<vpj-cd> if the choose the same order
<CarlosRuiz> and even the process do a local commit when trxname is null
<vpj-cd> then adempiere generate transaction
<vpj-cd> but this can are merge
<CarlosRuiz> hmmm, is like an autocommit when trxname is null, for every statement
<vpj-cd> becouse JJ only control this set Selection field in 'Y'
<hengsin> yes, carlos, autocommit when trxname is null
<vpj-cd> yes when you use trxname then create a random name
<vpj-cd> to transaction
<CarlosRuiz> do you understand this code from VInvoiceGen???
<CarlosRuiz> // String trxName = Trx.createTrxName("IVG");
<CarlosRuiz> // Trx trx = Trx.get(trxName, true); trx needs to be committed too
<CarlosRuiz> String trxName = null;
<CarlosRuiz> Trx trx = null;
<vpj-cd> yes
<CarlosRuiz> the trxname generation was commented out
<vclark> Should this topic be deferred until we are ready to work on an abstracted persistence layer? Or is there a temporary "bandaid".
<vpj-cd> but the problem is in the table that see the user
<CarlosRuiz> Victor, there are no trx management if trxname is null
<CarlosRuiz> and worst every statement is committed
<vpj-cd> yes but if this null then
<vpj-cd> set random name
<CarlosRuiz> no, it isn't generated
<CarlosRuiz> at least not in VInvoiceGen
<vpj-cd> and is upload the context
<vpj-cd> an is use to all new objects
<vpj-cd> I know not this is problem we also have in process generate to workflow
<CarlosRuiz> hengsin, do you think the problem can be solved generating the trnxname instead of using null ?
<vpj-cd> but a good exaple the ba management of transaction is inventory
<hengsin> need to look at the whole process flow ...
<vpj-cd> I have some customer in production
<CarlosRuiz> same issue in VInOutGen
<CarlosRuiz> ok, let me explain my point
<vpj-cd> and always the mstorage do not sync with mtransaction
<vpj-cd> ok
<CarlosRuiz> this code from
<CarlosRuiz> String trxName = null;
<CarlosRuiz> Trx trx = null;
<CarlosRuiz> // Reset Selection
<CarlosRuiz> String sql = "UPDATE C_Order SET IsSelected = 'N' WHERE IsSelected='Y'"
<vpj-cd> yes I sorry carlos
<CarlosRuiz> + " AND AD_Client_ID=" + Env.getAD_Client_ID(Env.getCtx())
<CarlosRuiz> + " AND AD_Org_ID=" + Env.getAD_Org_ID(Env.getCtx());
<CarlosRuiz> int no = DB.executeUpdate(sql, trxName);
<CarlosRuiz> as the trxName is null
<CarlosRuiz> the UPDATE is executed in a generic transaction
<CarlosRuiz> and committed immediately
<CarlosRuiz> so if the process fails for some reason
<CarlosRuiz> the update is committed
<CarlosRuiz> so, it can happens partial commits
<CarlosRuiz> and the process C_InvoiceCreate is called without trxname too in that code
<CarlosRuiz> so I think that using a trxName can solve the problem
<CarlosRuiz> but precisely that code is commented out
<CarlosRuiz> so maybe JJ confront some problem with trx management within Forms that we must research
<CarlosRuiz> what do you think?
<vpj-cd> yes I think he had a problem with cicli transation
<vpj-cd> then the transaction is idle
<hengsin> yes, this is really bad ...
<vpj-cd> and he commnet and set only this
<hengsin> I'm not quite sure what C_Order.IsSelected use for ...
<vpj-cd> yes I is happen in all from :-(
<hengsin> to represent user selection ?
<CarlosRuiz> yes
<vpj-cd> Low, yes this that user select from screen
<vpj-cd> the problem is when 2 user see same data
<CarlosRuiz> but again this occurs outside trx
<hengsin> wow ... this is very serious then ...
<vpj-cd> and push the button same time :-)
<CarlosRuiz> so if two persons select different invoices
<CarlosRuiz> one is rewriting IsSelected from the other
<vpj-cd> ok same invoice
<CarlosRuiz> look at this on generateInvoice_complete
<CarlosRuiz> // Reset Selection
<CarlosRuiz> String sql = "UPDATE C_Order SET IsSelected = 'N' WHERE " + m_whereClause;
<CarlosRuiz> int no = DB.executeUpdate(sql, null);
<CarlosRuiz> log.config("Reset=" + no);
<vpj-cd> I think this also happen in payment selection
<CarlosRuiz> again using null as trxname
<vpj-cd> and print payment cheks
<CarlosRuiz> big concurrency problems
<teo_sarca> i think the field IsSelected field should disapear from C_Order table
<vpj-cd> and statemetn bank
<hengsin> this can only be correct if transaction is use but enable transaction also means big concurrency issue, we need better solution
<CarlosRuiz> because of record locking?
<teo_sarca> we can use and intermediate table (like T_Selection), what you think ?
<vpj-cd> I think this is bad disign in lock transaction
<vclark> I don't like T tables.
<CarlosRuiz> hengsin, I think record locking is ok
<moyses> that is what happens carlos indeed...
<vpj-cd> I think we need a the lock to lever record
<hengsin> yes, the reset selection statement will lock all record of a client if execute inside a transaction, it will be very bad ...
<moyses> you can have in the same invoice records from different orders, from different customers...
<vpj-cd> lever = level
<CarlosRuiz> it will occur at the end of the process
<vclark> As far as I can tell, these multi-select windows do not use workflow.
<CarlosRuiz> I mean the records will only be locked when the user press OK button
<vclark> Can it be implemented that way, then subsequent transactions first check to see if a doc is part of an active workflow?
<vpj-cd> we have somes stategy to lock the records
<CarlosRuiz> but it's preferrably to have locked users, than having corrupted data !!!
<vpj-cd> yes the problem this is bad inventory
<vpj-cd> this is sever problem when you workin onlyne
<hengsin> carlos, lookat line 400 of VInvoiceGen, it will slow down the system a lot ...
<vpj-cd> and try sell on line
<CarlosRuiz> uff, it locks complete C_Order
<hengsin> yes, i think deadlock and concurrency issue force JJ to disable the transaction as a temporary solution to get reasonable performance
<CarlosRuiz> but is irresponsible to generate corrupted data
<hengsin> t_selection should be use instead
<CarlosRuiz> the effort of fixing data later is bigger
<vpj-cd> yes Carlos is a sever problem
=== vclark <> ``Vince Clark
=== vclark: member of #adempiere-team
=== vclark: attached to ``
--- End of WHOIS information for vclark.
<vclark> Can someone post line 400? I think I'm looking at a newer code base.
<teo_sarca> i agree with hengsin !
<hengsin> tring sql = "UPDATE C_Order SET IsSelected = 'N' WHERE IsSelected='Y'"
<hengsin> + " AND AD_Client_ID=" + Env.getAD_Client_ID(Env.getCtx())
<hengsin> + " AND AD_Org_ID=" + Env.getAD_Org_ID(Env.getCtx());
<CarlosRuiz> I think Teo is right, the usage of T_Selection there is the best solution
<CarlosRuiz> Vince, that line will lock all C_Order records of the organization
<hengsin> even without that, concurrent processing of invoice is practically a painfull process
<CarlosRuiz> so the rest of users on the system can be locked to access C_Order while the process finish
<vclark> So are we in agreement that using IsSelected or Processing flags are bad way to handle trx?
<CarlosRuiz> perverse way  :-)
<hengsin> Processing are not so bad as it is just to indicate a record is being process ...
<vpj-cd> I think we need not lock the record until we are processing the transaction
<vclark> So our immediate options are what? T_Selection? That doesn't address concurrency problem does it?
<CarlosRuiz> but IsSelected is very bad because it doesn't indicate which window has the record selected
<vpj-cd> yes
<CarlosRuiz> but T_Selection implies a rewriting of a lot of code
<CarlosRuiz> on a lot of forms
<vpj-cd> my question is how jj solve the problem with other process
<vpj-cd> ie Payselection
<vpj-cd> Print cheks
<vpj-cd> or Generate Invoice from receipt
<CarlosRuiz> VPaySelect also manages trxname = null
<CarlosRuiz> but it doesn't manage isselected
<vpj-cd> because this the style of JJ then we have all from with same problem
<hengsin> hmm ... maybe just remove the reset code, put transaction in, makesure IsSelected is updated back to 'N' at commit time can achieve reasonable performance, what your think ?
<CarlosRuiz> sounds good
<vclark> Another problem on this topic that has to do with high volume.....
<vclark> We ran into this with a customer that generates lots of invoices from SO's.
<vclark> JJ uses m_whereClause frequently, which uses IN (1,2,3,etc)
<vclark> Problem is that IN is limited to 1000 values
<hengsin> some database only allow 255 values
<vclark> I think it works OK if you use IN (select from)
<vclark> But not hard written values.
<vclark> So I had to rewrite some code to put everything into an array and then loop thru it
<hengsin> this is really naive ...
<vclark> I have a "high level" question that I believe should drive decisions about these kind of technical issues...
<vclark> If I recall correctly the official position of the Adempiere community is to stop inheriting from Compiere as of 2.6.0a
<vclark> Is this correct, or are we still trying to stay synched?
<hengsin> yes, sync is stop
<vclark> Good.
<CarlosRuiz> I think we can synch just if a big enhancement appears
<vclark> Agreed.
<vpj-cd> yes only
<CarlosRuiz> but sync through patching, not whole system
<vpj-cd> we now have more stable to adempiere vs compiere
<vclark> So on very specific technical issues such as persistence, trx management, etc. we should take our own approach.
<CarlosRuiz> we did already
<vclark> In the roadmap, or already in code?
<CarlosRuiz> trx management was completely improved by hengsin
<vclark> Really? What was changed?
<CarlosRuiz> to allow WAN connection, is working now
<vpj-cd> yes the problem JJ with persistence he reinvent the wheel
<vclark> Ah. I saw that post.
<vclark> I tried using WAN with trunk from a few days ago and had problems.
<vpj-cd> yes Low fixed the transaction
<hengsin> vclark, what is the issue ?
<vclark> I'm logging in right now to recall.
<vpj-cd> I maked all my test with wan connection and working fine
<teo_sarca> works for me too...
<vpj-cd> vince maybe have ol version
<CarlosRuiz> and worked for me with oracle port closed in firewall
<CarlosRuiz> but looks like some processes still try to use a direct connection
<vpj-cd> I have another improve
<vpj-cd> to finacial report
<hengsin> wait, victor
<vclark> That was the problem. Direct connection.
<vpj-cd> ok
<vclark> I'm trying to find what I did that produced it.
<hengsin> log that is anyone come across any of those. It is not perfect for sure.
<hengsin> I mean raise a bug report for that
<vclark> If I can reproduce it I will post a bug.
<hengsin> so guys, what should we do for the IN limit issue ? any idea ?
<vclark> The code base I'm working with has many customizations so it is possible that our custom code is bad.
<vclark> at least bad for WAN
<hengsin> vlarck, let me guess, u get NPE under WAN ?
<CarlosRuiz> in oracle you can put an OR every 1000 values
<vclark> I think that was it.
<CarlosRuiz> but is an ugly approach
<vclark> IN is not a good approach as volume increases.
<vclark> Even with Oracle performance degrades.
<vclark> Although it is probably still faster than looping thru arrays.
<CarlosRuiz> that IN clause is heavily used in Financial Reports
<vpj-cd> how is solve this regulary
<vpj-cd> if you we can change to org
<vpj-cd> or?
<hengsin> so the only feasible changes we can do now, is keep a counter and use OR after certain count
<CarlosRuiz> and put all IN's within parenthesis
<CarlosRuiz> and the count depends on the database
<vclark> Purely from a database perspective the best solution is subqueries. But that requires first writing "selected" records to temp table.
<vclark> The solution I used was to create an array of objects. This may not be the most performant, but eliminates database issues.
<CarlosRuiz> yes,again T_Selection
<CarlosRuiz> we dropped support for oracle temporary tables
<CarlosRuiz> because temporary tables are different on each database
<vpj-cd> Postgresql also support
<vpj-cd> temporary tables
<hengsin> postgresql temporary table is by session
<hengsin> must be created at the start of each session
<vpj-cd> I think the best soluction is use a subselect
<vpj-cd> the IN generaly is use in rule validation
<vpj-cd> and query to security role
<vpj-cd> then we can fixed from origin
<hengsin> sorry, will be away for a short while
<vpj-cd> ok can I tell the problem with report financial :-) ?
<CarlosRuiz> Victor, the subquery approach implies rewriting a lot of code :-(
<CarlosRuiz> I think is the best approach
<CarlosRuiz> but at first we can have the counter to solve temporarily this issue
<vpj-cd> yes, Only think in the string are generate
<vpj-cd> to rule validation
<vpj-cd> and role security
<vpj-cd> this buil string use in
<CarlosRuiz> no, Vince said in selection forms
<CarlosRuiz> and in Financial reports the same problem -> IN with a lot of values
<vclark> I'm not sure about the financial reports. Does the IN clause get populated with values, or is it a subquery?
<vclark> I don't think the limitation applies to subqueries, but I could be wrong.
<CarlosRuiz> with values, taken from hierarchycal query of accounts
<vclark> OK.
<CarlosRuiz> no, subqueries have no limit
<CarlosRuiz> ok, Victor, what's the problem with Financial Report?
<vclark> I suppose it is possible to have > 1000 accounts?
<vclark> And lower limit with other db's
<CarlosRuiz> yep
<hengsin> 200 is a safer number
<vpj-cd> ok
<vclark> The rewrite to use an array instead of IN clause was pretty easy. Is anyone opposed to this approach?
<vpj-cd> the problem with financial report is the table
<vpj-cd> Fact_Acct_Balance
<vpj-cd> I think is process is un nesessary
<vpj-cd> we run a report with Moyses use 1 year of history records
<vpj-cd> this proces need more 8 hours to update table
<vpj-cd> the we replace Fact_Acct_Balance to view and now this work in some minutes
<vpj-cd> I think this can inprove some indexs
<CarlosRuiz> how many records in FACT_ACCT ?
<vpj-cd> yes
<vpj-cd> but Fact_Acct_Balance
<moyses> let me check it...
<vpj-cd> is generate from Fact_Acct
<vpj-cd> JJ only generate summary to dimension
<vpj-cd> I think we only need a good view with this summary
<moyses> 2 millions records...
<CarlosRuiz> meanwhile, hengsin made an improvement to not call update fact_acct_balance, always recreate
<CarlosRuiz> ufff, it's a lot of fact_Acct
<vpj-cd> yes
<vpj-cd> Moyses what is the time now take to
<vpj-cd> get a report?
<moyses> it is quite fast now...
<CarlosRuiz> I think it's a very good solution
<moyses> nothing compared to the time used previously
<CarlosRuiz> replace fact_acct_balance with a view, let me check where else is used that table
<vclark> There are really two different issues here.
<moyses> you should let it running over the weekend to get a report :)
<vclark> I like the approach of a view for financial reporting.
<vclark> Database should definitely be leveraged more for financial reporting.
<vclark> The other issue is how to retain information about a user selection
<CarlosRuiz> moyses, you tested in postgres or oracle?
<moyses> oracle...
<moyses> have not tried to migrate all this stuff to postgresq
<moyses> but it could a nice exercise...
<hengsin> how many records get inserted into fact_acct_balance ?
<moyses> well it seems that I dont use any more that table..
<moyses> but let me see..
<moyses> 365374
<hengsin> hmm ... that shouldn't take that long ...
<vpj-cd> the problem the process generate update
<vpj-cd> in the Fact_Acct_Balance
<vpj-cd> but I see the bad disign to JJ
<vpj-cd> becouse you do need create Fact_Acct_Balance
<vpj-cd> it is solve with a view
<hengsin> update is remove from trunk ..
<vpj-cd> the other problem is you have sure the the data is secure
<CarlosRuiz> I reviewed, fact_acct_balance is not used in other parts, it can be easily dropped
<vpj-cd> if the process update to Fact_Acct_Balance faild then you have error financial
<vpj-cd> yes Carlos
<vpj-cd> this step I maked
<hengsin> victor, I think it is best to file a bug/feature request and upload the view there
<vpj-cd> I rename table Fact_Acct_Balance to Fact_Acct_BalanceOLD
<vpj-cd> and I create my view
<vpj-cd> and after I delete Fact_Acct_BalanceOLD
<vpj-cd> ok fine then I will make this
<vpj-cd> ok
<CarlosRuiz> there are a lot of people with problems on slowness on financial reports
<CarlosRuiz> for sure a lot of people will test your solution if published
<CarlosRuiz> and get us feedback
<moyses> this will solve a lot of those problems...
<CarlosRuiz> good if we can have test in postgresql with 2 million records
<vpj-cd> yes until now moyses working this solution
<vpj-cd> Moyses we can review with postgresql
<CarlosRuiz> and a test generating 3 financial reports at the same time
<hengsin> ok, just check, looks like view should be a perfect replacement
<CarlosRuiz> Victor, did you add indexes to fact_Acct ?
<vpj-cd> we can use dlutils to migrate from oracle to postgresql
<vpj-cd> and test
<moyses> if somebody can guide me
<moyses> I will do the test...
<moyses> in order to migrate the huge oracle database to postgresql
<moyses> I will report my findings over the wiki
<vpj-cd> no I only cahnge to view
<vpj-cd> we mwked test with db of moyses
<CarlosRuiz> I think armenrz and Joel have the same problem
<vpj-cd> and any query is more fast that update to Fact_Acct_Balance
<vpj-cd> yes
<hengsin> yes, insert lots of record, rollback segment will kill performance
<CarlosRuiz> agree, for me is a good solution, just want to have feedback from other tester, but 2 million records sounds enough test :-)
<CarlosRuiz> one question
<CarlosRuiz> are you comparing with update fact_acct_balance or with recreate fact_acct_balance ?
<hengsin> and on oracle, you use materialise view to further enhance performance
<CarlosRuiz> I think we can reopen this feature request:
<vpj-cd> mmm
<vpj-cd> I do not remember
<vpj-cd> to Moyses maked test and we suppend the test
<CarlosRuiz> it's the same, mviews are tables
<vpj-cd> when we get 12 hours the process
<vpj-cd> :-(
<CarlosRuiz> fact_acct_balance was a materialized view managed internally
<CarlosRuiz> Compiere? Adempiere? which version used to test? 311?
<teo_sarca> btw, mviews are supported by Postgres ?
<hengsin> carlos, not the same, mview can have smart update logic coded into the database
<CarlosRuiz> yes, hengsin, I mean the same in storage
<hengsin> ok, but just want to highlight, if u are on oracle, that is the most performant solution
<CarlosRuiz> not necessarily, because refreshing the view will cause the same overhead of refreshing fact_Acct_balance currently
<CarlosRuiz> mviews based on group by queries are deleted and inserted completely on refresh
<CarlosRuiz> Teo, I think that mviews are not supported in postgres, but it's ok, it's an optimization approach for oracle
<hengsin> ok, that might hit the same wall ...
<moyses> postgresql are not supported by postgresql
<vpj-cd> yes postgresql do not suport mview :-(
<moyses> sorry about that...
<moyses> I mean mviws
<vpj-cd> Moy have you the view that we upload your db
<vpj-cd> I think we can show and confirm with all
<vclark> I need to go. Here is my position on the two topics that are active...
<vclark> I support the approach of a view for financial reports. Alternatively we could look at hrowing out the whole "fact_acct_balance" appraoch but probably too intrusive.
<vclark> Regarding selection windows...
<CarlosRuiz> must be this
<CarlosRuiz> CREATE OR REPLACE VIEW Fact_Acct_Balance
<CarlosRuiz> (AD_Client_ID, AD_Org_ID, C_AcctSchema_ID, DateAcct,
<CarlosRuiz> Account_ID, PostingType, M_Product_ID, C_BPartner_ID,
<CarlosRuiz> C_Project_ID, AD_OrgTrx_ID, C_SalesRegion_ID,C_Activity_ID,
<CarlosRuiz> C_Campaign_ID, C_LocTo_ID, C_LocFrom_ID, User1_ID, User2_ID, GL_Budget_ID,
<CarlosRuiz> AmtAcctDr, AmtAcctCr, Qty)
<CarlosRuiz> AS
<vpj-cd> vince I think do not is nesseary
<CarlosRuiz> SELECT AD_Client_ID, AD_Org_ID, C_AcctSchema_ID, TRUNC(DateAcct),
<CarlosRuiz> Account_ID, PostingType, M_Product_ID, C_BPartner_ID,
<CarlosRuiz> C_Project_ID, AD_OrgTrx_ID, C_SalesRegion_ID,C_Activity_ID,
<CarlosRuiz> C_Campaign_ID, C_LocTo_ID, C_LocFrom_ID, User1_ID, User2_ID, GL_Budget_ID,
<CarlosRuiz> COALESCE(SUM(AmtAcctDr),0), COALESCE(SUM(AmtAcctCr),0), COALESCE(SUM(Qty),0)
<vpj-cd> we only replave this view
<CarlosRuiz> FROM Fact_Acct a
<CarlosRuiz> GROUP BY AD_Client_ID,AD_Org_ID, C_AcctSchema_ID, TRUNC(DateAcct),
<CarlosRuiz> Account_ID, PostingType, M_Product_ID, C_BPartner_ID,
<CarlosRuiz> C_Project_ID, AD_OrgTrx_ID, C_SalesRegion_ID, C_Activity_ID,
|<-- karsten-thiemann has left ("Verlassend")
<CarlosRuiz> C_Campaign_ID, C_LocTo_ID, C_LocFrom_ID, User1_ID, User2_ID, GL_Budget_ID
<hengsin> yes, that is straight forward :)
<vclark> It is my opinion that these windows should not use IN clauses, and should not write data to the database just to read it back. Selections should be stored in java. That's my two cents :-)
<vclark> bye
<hengsin> bye, vince
<CarlosRuiz> bye, thanks Vince
|<-- vclark has left (Remote closed the connection)
<moyses> yes I have the view victor...
<teo_sarca> bye vince
<CarlosRuiz> Victor, I suggest you reopen the feature request :
<CarlosRuiz> upload the script for the view
<CarlosRuiz> wait for armen to test (to have a second opinion)
<CarlosRuiz> and if possitive (almost sure) - integrate into trunk
<CarlosRuiz> what do you think?
<CarlosRuiz> I trust moyses opinion, but just want a second test in other conditions
<teo_sarca> about fact_acct_balance, i don't know how is in your countries, but in mine we need initial amounts for each account. Does somebody share this problem ?
<hengsin> teo, u are talking about opening balance ?
<vpj-cd> yes I am create a new bug
<teo_sarca> yes
<vpj-cd> and set the armet an joel
<vpj-cd> as reference
<vpj-cd> and upload the pach and the view
<teo_sarca> we need year start, period start amounts
<vpj-cd> tou can test and if you agree you can set into trunk
<CarlosRuiz> ok, agree
<hengsin> ok
<vpj-cd> teo the open balance are create each time
<vpj-cd> in adempiere do no exist a table with balance
<CarlosRuiz> I think we can have the problem described by Teo when needing assets balance
<CarlosRuiz> in a year different from the initial
<teo_sarca> i have this problem with absolute each financial report !
<hengsin> teo, in adempiere, u get the opening balance from last year closing balance :)
<moyses> yes teo
<moyses> we have the same problem
<moyses> you need to close and open periods
<teo_sarca> hengsin, this is pain
<hengsin> yes, I know and it is unconventional
<teo_sarca> moyses, and when i close the open periods what happens ?
<moyses> teo...
<moyses> thats one problem that I see
<moyses> when you close the period
<moyses> adempiere should close some accounts
<moyses> and bring the balance to the next year
<vpj-cd> no is nessesary
<vpj-cd> I think
<vpj-cd> I explaint
<CarlosRuiz> Teo and Moyses, if I understand you, expenses and invoices are closed each year, but assets and liabilities are not closed, they have an initial balance
<vpj-cd> in other ERP
<CarlosRuiz> but Adempiere doesn't register the initial balance anywhere
<vpj-cd> the close yesr is only logical
<CarlosRuiz> did I understand correctly ?
<teo_sarca> nop !
<vpj-cd> no Carlos you need load the balance
<vpj-cd> this is generate to begin load
<vpj-cd> the invoice
<vpj-cd> o jurnal balance
<teo_sarca> nop, Adempiere doesn't register the initial balance anywhere .. i mean :)
<vpj-cd> but I explit the bes way
<teo_sarca> i am listening....
<vpj-cd> yes you need upload balance
<vpj-cd> to begin accounting
<CarlosRuiz> this behaves well the first year Victor
<CarlosRuiz> but second year you can have troubles with financial reports
<vpj-cd> ok
<vpj-cd> I explaint
<vpj-cd> if you are start with aempiere
<vpj-cd> Adempiere
<vpj-cd> we have 2 form to load begin balance
<vpj-cd> I make this form
<hengsin> victor, we are talking about subsequent year
<vpj-cd> firt I upload invoices ap, ar
<moyses> the problem for me is for example to close the first year
<vpj-cd> inventory
<moyses> and create the initial balance for the second year
<vpj-cd> ok
<CarlosRuiz> exactly, because there is not a "Amount Type" that summarizes all movements
<vpj-cd> good to secod yesr
<vpj-cd> is this my idea
<vpj-cd> is very easy
<hengsin> the only way I know off is to use formula to get last year closing balance as the current year opening balance
<vpj-cd> we know all account the income and expence are the income statement
<vpj-cd> this are set in cero each year
<vpj-cd> this maybe make to the fact always
<hengsin> sure
<teo_sarca> look, the balance for a period, in our country looks like this:
<teo_sarca> Account, YearStart_DR, YearStart_CR, PeriodStart_DR, PeriodStart_CR, Period_DR, Period_CR, ......
<vpj-cd> when report finacial detect a change year this begin only with balace this year
<teo_sarca> are you facing with this problem ?
<teo_sarca> and here the accountants ALWAYS have 2 or more periods open, to fix the balance :))
<vpj-cd> the sum of all accout the income statement and spense is my proffit an lost
<hengsin> teo, that is the normal practise in most country
<vpj-cd> teo yes
<vpj-cd> I make a 13 period
<vpj-cd> the 13 period is 1 the dicember
<vpj-cd> is 31 december to 31 dicember
<vpj-cd> the 12 period is 1 to 30 dicember
<teo_sarca> aha
<vpj-cd> in my 13 period I use to set my ajust
<vpj-cd> after I have finacial audit
-->| CarlosRui1 (n=Carlos@ has joined #adempiere-team
<hengsin> carlosrui1 ?
<CarlosRui1> I get disconnected, missed last part of discussion :-(
<CarlosRui1> do you have a conclusion about ?
<vpj-cd> Carlos we can say again if you want
<vpj-cd> ok
<vpj-cd> I think the colse year is only logical
<vpj-cd> we only need sum the income account and spense
<vpj-cd> we get profit and lost this year
<hengsin> year end closing is not logical, the profit/loss should be transfer to your retain earning/loss account
<CarlosRui1> yep
<vpj-cd> this is save in accout that is set in account default schema
<hengsin> compiere is missing this functionality
<vpj-cd> yes Low
<hengsin> the account is there but the posting never happen/not implemented
<CarlosRui1> expenses and incomes must be cleared
<vpj-cd> in another ERP is logical
<moyses> hengsin have the point!!
<vpj-cd> this in only calculate
<CarlosRui1> hengsin, we're developing this functionality sponsored by Idalica
<teo_sarca> here, i resolved the problem using triggers (but can be resolved from Java), that updates sumarization table, and then i generate the balance from that table... what you think ?
<vpj-cd> no the problem is the unsyc data
<hengsin> ic, carlos, good to hear that, a very basic things that somehow JJ doesn't implement.
<vpj-cd> can have problem with data
<vpj-cd> ok I can finish my explaint?
<teo_sarca> sure
<hengsin> yes :)
<teo_sarca> :)
<vpj-cd> ok is logican to me becouse
<moyses> :)
<vpj-cd> the profit and lost is calculate with a view
<vpj-cd> each to generate a report
<vpj-cd> this is very easy agin we only need sum the income and spense account
<vpj-cd> agin = again
<vpj-cd> ok
<vpj-cd> the is show as a var in memory to reports
<vpj-cd> any report
<vpj-cd> the traditional we need set all accout the income statement in cero each yesr
<vpj-cd> year but this no is practical
<vpj-cd> this are the reason:
<vpj-cd> 1.- the account need review
<vpj-cd> to some periods to get the exact profit or lost
<vpj-cd> if we maked a process with jultan then we need
<vpj-cd> make this always
<vpj-cd> becouse we need print the next balance report
<vpj-cd> if we have some change in period before
<vpj-cd> then we need recalculate this again is is a problem
<vpj-cd> when you have some year
<vpj-cd> becouse you need fixed all years
<vpj-cd> the the propietary erp solve this issue this way
<vpj-cd> the profit & lost is calculate always from Fact_Acct
<vpj-cd> we set this value in accout set account schema to profit and lost and use to any report in this session
<vpj-cd> we alway set the income and spense account in cero
<vpj-cd> the way if exist a ajust in before priod no is nessesary recalculate
<vpj-cd> and registe new jurnal
<vpj-cd> this is logical
<vpj-cd> this also allow all can continue working in ERP
<vpj-cd> and no is nessesary stop te operation to account close year
<vpj-cd> what do you thitnk
<vpj-cd> explaint I good :-)?
<teo_sarca> (still processing... :) )
|<-- CarlosRuiz has left (Read error: 110 (Connection timed out))
<CarlosRui1> this is the other CarlosRuiz :-)
<CarlosRui1> Victor, what happened when the earnings are paid to partners of the company
<CarlosRui1> I mean distributed or paid
<hengsin> victor, I understand that in reporting, u can always get the result through the use of formula, but retain earnng is a physical account and by accounting requirement, when the year is close, your profit/loss have to goes there
<vpj-cd> the same time now you use to generate begin balance
<moyses> indeed hengsin
<vpj-cd> current adempiere always calculate balance
<hengsin> and like carlos say, later, further transaction can be done on that account, like issue of divident, etc ...
=== carlosruiz is offline.
<vpj-cd> yes Low
<vpj-cd> we can always get the value the retain earnng an retuen to report
<vpj-cd> as we make to set all income accout in zero
<jsSolutions> sorry to jump in the middle
<hengsin> yes, that is what the year end closing is for ...
<vpj-cd> ok in the ERP propietary
<jsSolutions> but there is also a period type
<vpj-cd> we have a option add
<jsSolutions> called adjustment period
<jsSolutions> that matches what vpj-cd
<jsSolutions> mentioned earlier
<vpj-cd> this option called close year permanetly
<jsSolutions> make your adjustments in that 13th period
<jsSolutions> then you can report on per 12 for before adj
<vpj-cd> then here you set recors in the account
<jsSolutions> and per 13 for after
<vpj-cd> yes Joel
<jsSolutions> but doesn't work right
<vpj-cd> I say this
<vpj-cd> the discution is
<hengsin> ok, yet another incomplete functionality :)
<vpj-cd> yes
<vpj-cd> I am talk who we can solve :-)
<vpj-cd> in future
<CarlosRui1> I think as hengsin said, that year-end process is needed
<hengsin> also, right now it is pain to setup correctly to get the year opening balance, it should be easier.
<vpj-cd> yes but we need a logica
<CarlosRui1> it can't be logical, at some moment you must distribute earnings
<CarlosRui1> logical can be constructed via reports
<vpj-cd> becouse generaly the account need have final statement audit
<CarlosRui1> with formulas
<vpj-cd> the you can set yesr premanetly close :-)
<vpj-cd> yes this my point
<vpj-cd> only in report
<CarlosRui1> ok, so the process is needed, but we need a logical approach before closing definitely, I agree
<vpj-cd> the user do need know how we get the ata
<vpj-cd> data
<CarlosRui1> but I think Teo's problem is other
<CarlosRui1> Hengsin, please can you explain me what do you mean on: the year opening balance
<teo_sarca> the problem that is discussed here is a part of my problem
<teo_sarca> ...
<teo_sarca> year opening balance = the balance at year start (i suppose)
<hengsin> I means to get the current financial year's opening balance for asset and liabilities, it can be done but it is cumbersome
<CarlosRui1> how is it done currently?
<CarlosRui1> via export report and loading a GL Journal ?
<hengsin> ok, I'm talking in financial report, u can use formula to get last year closing balance as the current year opening balance
<vpj-cd> the open blance is load with GL Jurnal
<vpj-cd> but you need delete recor the fact_acct
<vpj-cd> you have 2 option build the open balance from detail ap,ar,inventory etc
<hengsin> in financial report, total balance with relative period -1, give you the current year's opening balance
<vpj-cd> or load a to begin balance GL journal
<vpj-cd> yes
<vpj-cd> I for example load each blalance
<vpj-cd> balance as GL journal
<CarlosRui1> ok, so the year-end process could load the "total balance with relative period -1" as a first movement on this year, and the problem is solved
<vpj-cd> jan , feb, and Y start in production in March
<vpj-cd> the the user can get report from jan
<hengsin> yes, carlos.
<vpj-cd> yes carlos
<hengsin> teo, is that how you doing it now ?
<vpj-cd> Carlos we can summary
<teo_sarca> no
<CarlosRui1> the problem will be (as Victor stated) if adjustment are made to previous year, but as Victor said - this must be a "close year permanently"
<teo_sarca> we use a custom table
<hengsin> ok, so what is your approach
<teo_sarca> that summarize the fact acct
<teo_sarca> and we update that table using triggers (ugly but it works)
<vpj-cd> I think is easy
<vpj-cd> we can development in engine finacial report
<teo_sarca> so, you can get the balance anytime
<vpj-cd> the set the valu the retain earnng to this can are print
<teo_sarca> but as i know the financial report is calculating the year balances using the fact_acct ...
<vpj-cd> teo you get your fist balance with GL journal
<teo_sarca> ok, the first balance, but the rest ?
<teo_sarca> and on closing period, the accountants are running the balance process all the day....
<vpj-cd> ok the rest is calculate to engine report
<vpj-cd> you need set you time comumn with data type corrent
<vpj-cd> you need know the type
<vpj-cd> begin balance
<vpj-cd> end balance
<vpj-cd> etc
<CarlosRui1> Teo, I think the initial balance approach will solve your problem, or even logically to add a column with the formula "total balance with relative period -1" as hengsin pointed
<vpj-cd> you need set the type in you report column
<vpj-cd> yes
<vpj-cd> you can efine the column as -1 and set type column in end balance
<teo_sarca> carlos, but this is not a time consuming process ?
<vpj-cd> this the begin blalance to next period
<vpj-cd> is easy
<vpj-cd> Teo if we solve this problem the
<vpj-cd> you can test
<vpj-cd> now Moyses use this pach and he have very records
<vpj-cd> we can test to corovorate the pach
<CarlosRui1> yes Teo, it can be very time consuming, but as Victor said, it must be tested the view approach
<vpj-cd> ok we can have a summery and a todo list ?
<CarlosRui1> ok, I'm worried about hengsin because is 2AM in Malaysia
<hengsin> yes, pretty late here :)
<CarlosRui1> who has the complete log of this chat? to publish in wiki. I get disconnected a while :-(
<hengsin> guys, needs your opinions on accepting the compiere bi project into adempiere
<CarlosRui1> I'm looking at hengsin, I'm going to answer your e-mail soon
<moyses> hegsing
<CarlosRui1> I mean, I'm looking at CompiereBI; hengsin
<moyses> can I take a look at it??
<moyses> I read something about it on the wiki
<hengsin> ok, we need a general approach to deal with subproject and related project. carlos, maybe u can define the rules and layout in svn for that
<moyses> but what about using other tools such as jasper intelligence or
<CarlosRui1> Moyses, is here:
<moyses> pentaho...
<vpj-cd> yes I review this proyect
<teo_sarca> if you reviewed it, what are your conclusions ?
<vpj-cd> but I think we should use penthao to solve BI
<hengsin> victor, one last question, on the issue of pljava installation, have u try gcj before ?
<vpj-cd> they use the modrian only
<vpj-cd> no low I always with Java sun distribution
<vpj-cd> CompiereBI is small
<hengsin> ic, victor, maybe u can try gcj, I think it can make installation simpler
<hengsin> carlos, would u make a summary of today's discussion ? if need the complete log, I can mail it to u
<CarlosRui1> please, I'm going to upload into wiki, and I'll make a summary there if you want
<vpj-cd> ok
<vpj-cd> yes hengsin I test
-->| Ramiro_ ( has joined #adempiere-team
<hengsin> ok, I 've to stop here, it is bed time ...
<vpj-cd> with gcj
<CarlosRui1> can you please send me the log before going to bed?
<vpj-cd> ok compierebi is small project
<vpj-cd> they use modrian
<vpj-cd> and copy the data to mysql
<vpj-cd> to make the cubes
<vpj-cd> and dimension
<vpj-cd> I think current functionality to performace is bether
|<-- Ramiro has left (Read error: 104 (Connection reset by peer))
<vpj-cd> better
=-= Ramiro_ is now known as Ramiro
<teo_sarca> personaly, i don't like the approach you described ...
<vpj-cd> I think we can use pentaho and build the contribution
<vpj-cd> to cubes and dimention
<vpj-cd> use penthoa
<teo_sarca> do you have some exerience with pentaho?
<vpj-cd> yes I review
<teo_sarca> and?
<hengsin> oops .. my log is not complete, anyone have the complete one ?
<vpj-cd> is more aventage
<vpj-cd> you can have a portal
<vpj-cd> and roles
<vpj-cd> you can set you dash board
<teo_sarca> yes, i have
<CarlosRui1> hmmm, maybe I can put my log, I just lost 3 minutes of chat
<CarlosRui1> or please, if Teo can send it to me
<vpj-cd> and grap of bar or pay
<teo_sarca> carlos, wait ....
<vpj-cd> I think the best opentin to BI in this moment is Pentaho
<vpj-cd> and we can build the stuff to compatible with adempiere
<vpj-cd> I think need review CompiereMonitor
<vpj-cd> this use AOP to change the bussines lolic in hot
<vpj-cd> this may more util
<vpj-cd> that compiereBI
<hengsin> bye all
<CarlosRui1> bye Hengsin, thank you very much, very productive the discussion