c2c-oerpscenario team mailing list archive

["Nhomar Hernandez \(Vauxoo\)" <nhomar@xxxxxxxxx>]

Hello Ferdinand.

You proposal is not bad, even almost all systems works with your
concept, because what @moylop260 did already is a really complex concept
in computational logic, called b_tree or something like that, so, no so
much programers understand it or know how apply it, this was the case
for the original programmer that write _compute method in openerp.....
But all the scenary was well designed to use it... ;-)

BUT, logic that have OpenERP right now is so so inefficient, even this
until now has been a really big problem, but, we in vauxoo have 3
customers with chart of account of 8000 and 16.000 accounts in charts,
in v5 v6 and preparing for v6.1, for this reason we know the behaviour
in three versions, and calculate a simple Balance has been a headache,
with 1 year of data and more than 100.000 moves we REALLY need
optimization to REALLY have our tree view of the chart of account
efficient and usable in an production enviroment, and financial reports
calculated quickly...., @moylop260 (our CTO in MExico) work this week in
Venezuela already with our CTO in Venezuela @humbertoarocha and myself
in find an Extraordinary solution and I think this was really the
solution.

I mean.....

Your Option is good.

THis patch and future merge is AMAZING.

We are really excited with the improve in speed and even tryton that
talk A LOT about good practices and this stuff don't have this feature.

-- Calculate 16000 balance in 1 second and show inmediatly on tree
view..... WAOOOOO i think it is amazing,


We invite to all community in try our method please, and try multicurrecny stuff and give us feedback to improve it.

WE want this for V6.1 ..........

Regards.....

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to OpenERP Project Group.
https://bugs.launchpad.net/bugs/887376

Title:
  [6.0 & 6.1] [account] def compute needs optimization

Status in OpenERP Addons (modules):
  Confirmed

Bug description:
  The def compute of account module no use parent_right & parent_left fields for calculate sum(debit) & sum(credit)
  and not in use recursive function's

  These is very slow with a big account chart and very much
  account_move_line

  This can optimizate using parent_left & parent_right

  Im working for a propose merge with the solution.

  Meanwhile i put a script sql with my idea

  	SELECT 	MIN(aa_tree_1.code) AS code,
  		SUM(account_move_line.debit) AS debit, SUM(account_move_line.credit) AS credit
  	FROM account_account aa_tree_1
  	INNER JOIN account_account aa_tree_2
  	   ON aa_tree_2.parent_left 
  	      BETWEEN aa_tree_1.parent_left AND aa_tree_1.parent_right
  	INNER JOIN account_move_line
  	  ON account_move_line.account_id = aa_tree_2.id
  	INNER JOIN account_move
  	  ON account_move.id = account_move_line.move_id
  	  AND account_move.state = 'posted'
  	GROUP BY aa_tree_1.id

  
  These script is functionally without consolidate account, but I'm working

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/887376/+subscriptions