openerp-expert-accounting team mailing list archive

[Ferdinand Gassauer <office@xxxxxxxxxx>]

Am Mittwoch 31 März 2010 17:25:49 schrieben Sie: ( Borja López Soilán)

> Ferdinand Gassauer escribió:
> > Am Mittwoch 31 März 2010 14:21:43 schrieben Sie:
> >
> > Hello here come the 2 modules needed
> >
> > pleas read the module description
> >
> > after installing these modules you'll get probably wrong balance carried
> > forward values
> >
> > in "Financial Journals" you have to check "is opening balance journal"
> > for the journal which now holds the closing and opening moves
> > and update the module
> >
> > Camp2camp and OpenERP (Quentin) are aware of the problems as they are
> > going to rewrite the accounting reports for V6 (planned for July)
> 
> I just took a first look to your code, some thoughts:
> 
>     * The part about having a account_account_period_sum table looks
>       like the account_account_totals table I was talking on my mail.
>       That's more or less what I expected. But:
>           o I would also store the 'non confirmed' amounts into the
>             account_period_sum. Just adding draft_debit and draft_credit
>             fields for the amounts with non-confirmed moves. That would
>             make it compatible with the standard OpenERP account
>             debit/credit/balance function fields (that may filter moves
>             based on the state).
>             An (easier to implement) alternative would be to have sums
>             not just by period, but by period and state.
Both is easily possible
> 
>     * I don't really get why we add the account_period_sum_id to
>       account_move_line. The account_move_line already has the period_id
>       and account_id, that should be enough to do the 'JOIN' with
>       account_account_period_sum.
In our old system we had an unlimited number of closing periods - I thought it 
is necessary to link the moves_lines to these special periods - may be it's 
possible to find another solution.
> 
>     * I don't like having my periods named '200901', '200904'. On Spain
>       only big companies need to use monthly periods, most companies use
>       quaterly periods (09Q1, 09Q2... or 1T09, 2T09...). I don't see the
>       need to force the usage of such names. I would make all the
>       computations based on the period date.
Intersting - here only very small companies with yearly turnover less then EUR 
30.000,- may report quaterly.
> 
>     * I don't understand why we need an special 'opening balance'
>       journal. I mean, in order to get the current amounts to carry on,
>       we can just order the periods by "date_start, date_end". So an
>       opening period (2009-01-01 to 2009-01-01) goes before the first
>       month of the year (2009-01-01, 2009-01-31), and the closing period
>       (2009-12-31, 2009-12-31) goes after the last month of the year.
>       Using special periods instead of more journals looks more
>       intuitive to me.
I need the 'opening balance' journal because I do not add theses moves to the 
period sums, because these are added on a permanent basis to the special 
period '00'

> 
>     * You don't refactor the account.account __compute method. Just
>       changing this method, to make the use of the precalculated values
>       when possible: use account_account_period_sum if the user filters
>       by account, period, fiscal year or state; use the standard
>       account_move_line query otherwise. That would speed up a lot all
>       the accounting reports and wizards without touching a single line
>       of code in them (less work for camp2camp :) ).
refactoring is beyond my capabilities. 

best would be to use the calculated values 
* if the aggregate table exists and only periods are requested  
* else use existing code.

> 
> I'm now thinking about making a prof-of-concept module that does just
> what I said: refactor the __compute method to use the period sums table.
> But I don't know if I'll have time soon.
> 
> Anyway, thanks for your module and ideas, I hope some of them are
> implemented on OpenERP 6 :)
> 

-- 
Best Regards

ChriCar Beteiligungs- und Beratungs- GmbH
http://www.chricar.at/ChriCar/index.html
Dr. Ferdinand Gassauer
Official Tiny Partner