openerp-expert-accounting team mailing list archive

[Nhomar Hernández <nhomar@xxxxxxxxx>]

Hello Guys.

We understand this right now thanks. It is so clear that with special
periods is the solution to work with this modules/improvements.

Our arguments are more related to the fact of: If the concept already exist,
and is well, why improve something than deep like the Opening/Closing
procedure?, for us is only a point of view, don't you think if the oiginal
concept used is well and so generic it should be easy to adopt for more
people with your modules???.

I mean:
Opening/closing information in concept are "special" moves organized in an
"special way" (Journals).
Periods are the way that the people divide the fiscal year in times,

IMHO - When i said "conceptual periods", and not "real periods" we were
trying to explain that a fiscal year can have several journals to organize
several moves... and two will be special "Journal of type situation in the
first period and last period " and this in conecpt is well, but a year has
12 periods or 24 periods or 4 periods I mean real periods without
overlapping.... It maybe is easiest to understand, We know this for your
great improvements should be a "wishlist", We aren't telling that your
concept is wrong "It works" we are telling that the original is better only.

BTW - This improve works from a reporting point of view better that the
original one, but the reason is because the original reports aren't well
implemented in the reports calcs and we think these reports _must_ be
improved, not create a new module concept.....

@Borja:
[[The "closing period" is a pretty straightforward concept and widely used
here: Most spanish accounting programs have special periods (like having 13
or more months per fiscal year, so you would use the 13th for closing moves;
this way you can print a report at the end of the year [month 12] or after
the closing [month 13]). So that 'conceptual' period, is a real tool
accountants were using before OpenERP.]]

Here in Venezuela too!!, and we always tried to say to the programers that
it was wrong, but how this are closed programs, we were unable to make
something about that, thanks God exists OpenERP right now ;-). In the past
this programs rules the market, in the future we should be braker rules ;-)

BTW we will work in this way you explain for now but we really think that is
prettiest a well fundamented concept that an easy way to jump a simple
principle.... ;-)

We want help to improve this two options in a configurable way, are you
agree with that??

Conclusion: We will use special period for now ;-)

IOH: When Humberto explains this
https://bugs.launchpad.net/openobject-addons/+bug/569216 other concept that
is not implemented by now is the "before Balance"

In this bug we talk about Opening Balance and Current period balance, but
there are a third information that should be considered. I mean....

Opening balance: Is clear what it is.
Before balance: balance for an account_account exactly before the period to
make the analysis.
Actual balance: Balance in the period to study.

If I _don't include_ the opening balance (Because I want to evaluate Fiscal
Periods Independently)

First Period "Before Balance" is 0,
Second period "Before balance" is the balance For the first one. and this
way successively

If I _include_ the opening balance

First Period "Before Balance" is equal to "Opening balance",
Second period "Before balance" is the balance For the first one more that
"Opening balance". and this way successively

In the IFRS - NIC and a lot of other standards this three concepts are in a
separate fields, and you in several cases will need to print this three
values toghether or in separate way.....

What do you think about that??

We can work in this concepts too!?



2010/4/27 Ferdinand Gassauer <office@xxxxxxxxxx>

> Am Dienstag 27 April 2010 09:51:11 schrieb Borja López Soilán (Pexego):
> > Humberto Arocha escribió:
> > > <
> https://blueprints.launchpad.net/openobject-addons/+spec/calculate-openi
> > > ng-balance-for-opening-entries-in-account-voucher>
> > >
> > > Even I came to realize that something I was pointing out to Borja in
> > > the recent bug posted was really pointing out account_account so It
> > > seems account_account needs some fixes regarding the things you point
> > > out here and the ones we are pointing out above,
> >
> > The problem is not just the account_account (ok, the __calculate method
> > needs to be improved in some ways), but the accounting reports:
> >
> >     * Some reports give you the option to filter by period or date:
> >           o If you just use special periods to mark the opening&closing
> >             moves, it is enough for you.
> >           o If you use situation journals (as Humberto and Nhomar) to
> >             mark the opening&closing moves... it just don't work.
> >
> >     * But some reports (like the "Chart of accounts" tree view wizard)
> >       just let you select the fiscal year:
> >           o If you don't make closing moves at the end of the year, just
> >             opening moves, then it mostly works for you: you just don't
> >             know what the initial balance was, but the final balance is
> >             alright.
> >           o If you make closing moves 'the Spanish way' (doing a move
> >             that sets everything to 0), that report is not useful
> >             anymore (it just shows 0!). There is no way to see the
> >             "balance before closing".
> >
> >
> > We have two options:
> >
> >     * All the reports should let you filter by periods/date *and*
> >       journals => You can use either special periods or situation
> >       journals for the opening and closing moves.
> >     * All the reports should let you filter by periods/date => You need
> >       to use special periods for the opening and closing moves (though
> >       that moves may also be on a situation journal).
>
> and we resolve the problems of redefined wizards
> ./account/wizard/wizard_account_chart.py
> ./account_simulation/wizard/wizard_account_chart.py
> ./account_financial_report/wizard/wizard_account_chart.py
>
> --
> Best Regards
>
> ChriCar Beteiligungs- und Beratungs- GmbH
> http://www.chricar.at/ChriCar/index.html
> Dr. Ferdinand Gassauer
> Official Tiny Partner
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-accounting<https://launchpad.net/%7Eopenerp-expert-accounting>
> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-accounting<https://launchpad.net/%7Eopenerp-expert-accounting>
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Saludos Cordiales

Nhomar G. Hernandez M.
+58-414-4110269
+58-212-6615932
+58-212-9536734 ext 124
+58-212-9512643
Web-Blog: http://geronimo.com.ve
Servicios IT: http://openerp.netquatro.com
Linux-Counter: 467724
Correos:
nhomar.hernandez@xxxxxxxxxxxxx
nhomar@xxxxxxxxxxxxxxx