← Back to team overview

openerp-expert-accounting team mailing list archive

[Bug 659540] Re: [trunk] account_cancel - naming issue

 

May be a good solution (as Borja suggested) would be to rename the
module to "account_delete", and everybody who can use it may do so.

I just want to recall that deleting invoices creates gaps in the
numbering and our chartered accountants and financial authorities here
in Austria require gapless numbering of about everything, because it's
the only way to prove formal completeness.

and to check in Christians Salamea modul as "account_cancel" when it
does what is says and what is needed by others.

I would be very happy if these basic accounting principles would make it
as standard (and not exception) in OpenERP.

-- 
[trunk] account_cancel - naming issue
https://bugs.launchpad.net/bugs/659540
You received this bug notification because you are a member of OpenERP
Accounting Experts, which is a direct subscriber.

Status in OpenObject Addons Modules: Confirmed

Bug description:
IMHO a serious accounting issue

./account.py:        'update_posted': fields.boolean('Allow Cancelling Entries', help="Check this box if you want to allow the cancellation the entries related to this journal or of the invoice related to this journal"),

what happens is that account_move and account_move_lines are deleted (not canceled).

http://www.iwp.or.at/Documents/GS-DV01.pdf (German) describes the basics of accounting and clearly states that
* 1.4 on page 7, that posted entries may not be altered in a way that the original posting can't be reproduced.

violating this principle might or will lead to the fact that the accounting can't be audited and will not be accepted by the fiscal authorities.
it will create gaps in ids as well as in name/ref fields and nobody will ever be able to reconstruct what happens as audittrail on account_move_line does not work (see other bug report) either

This should be clearly stated in the description.

Cancelling invoices must lead to an additional move with move_lines which revert the original move_lines. 
This and only this is the "normal" way which is accepted by fiscal authorities (at least here in Austria)