[trunk] account_cancel - naming issue

[Ferdinand]

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)

[Borja López Soilán (NeoPolus) (borjals)]

> 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)

On Spain it is assumed that digital accounting entries are constantly being created and removed leaving gaps in their numeration. Anyway, at the end of the year (after fiscal year closing), the accounting journal must be printed with entries numbered sequentially. So, all the Spanish accounting software I know* has a wizard to allow the renumbering of entries on a given period.

  * Some examples of such wizards:
    ContaPlus: http://www.kami.es/pub/2009-09/renumeracion_asientos/facturaplus.png
    ClassicConta: http://www.kami.es/pub/2009-09/renumeracion_asientos/classicconta.png
    ContaSol: http://www.kami.es/pub/2009-09/renumeracion_asientos/contasol.png
    Primavera: http://www.kami.es/pub/2009-09/renumeracion_asientos/primavera.png

On the Spanish localization of OpenERP we had to create a wizard to allow such renumbering, it was released as the account_renumber module available on the extra-addons.

So, for Spain:
  - Deleting account_move/account_move_lines on a non-closed fiscal year is acceptable (and usual).
  - "update_posted" is always set to true.
  - On the fiscal year closing, the accounting entries are renumbered.

[Borja López Soilán (NeoPolus) (borjals)]

Maybe we should implement both options as separate modules:

  - One "account_cancel" module to allow canceling account movements and invoices without deleting them (we might use some "active" field automagic).

  - One "account_delete" module that allows deleting account movements and invoices like in the 5.0.

[Peter Langenberg (peter-langenberg)]

It's very important that it remains possible, for me it's ok that you have to install a separate module. Problem is that accountants want it and auditors don't want it.

But it's also possible to use the postgres client to change or remove lines in a database, so should the client also be forbidden ?

It's like with a car, if speed limit is 120 km, but it can drive faster if the user wants that, does this mean that those cars should be forbidden ?

Peter

[Hervé Proust - www.kazacube.com (hproust)]

+1

In the countries we work in (Morocco, Cameroon, ...), even though it is
not in the accounting standards, companies may want to put in place
journals with the "cancel entries" option.

The way it worked in V5 is satisfying for us, our customers and even for
our certified accountant (as long as, for him :), the cancel entries
option was not activated...)

Hervé

________________________________________________________________________

  Hervé PROUST
  Directeur Associé
Bureau : [phone]
Mobile Maroc : [phone]
Mobile France : [phone]
58

10, rue Ibnou Al Arif
20 100 Casablanca - Maroc
<email address hidden>
www.kazacube.com

-------- Message initial --------
De: Peter Langenberg <email address hidden>
Reply-to: Bug 659540 <email address hidden>
À: <email address hidden>
Sujet: [Openerp-expert-accounting] [Bug 659540] Re: [trunk]
account_cancel - naming issue
Date: Wed, 20 Oct 2010 17:54:02 -0000

It's very important that it remains possible, for me it's ok that you
have to install a separate module. Problem is that accountants want it
and auditors don't want it.

But it's also possible to use the postgres client to change or remove
lines in a database, so should the client also be forbidden ?

It's like with a car, if speed limit is 120 km, but it can drive faster
if the user wants that, does this mean that those cars should be
forbidden ?

Peter

[xrg (xrg)]

On Wednesday 13 October 2010, you wrote:
> Public bug reported:
>
> IMHO a serious accounting issue
>...that posted entries
> may not be altered in a way that the original posting can't be reproduced.
>
> violating this principle ... will not be accepted by the fiscal authorities.

Definitely agree.

On a production system, where OpenERP is used for /official/ [1] accounting, a
hard rule[4] must be imposed that accounting moves [2] should not be altered
or deleted.

That said, this rule might be useful for other models, too [3].

[1] Some installations chose to install OpenERP and then send the accounting
data to their chartered accountants, which do the official bookkeeping. In that
case, the "first-level" accounting is not bound by the law. For them, the hard
rule /need/ to be relaxed, because they would use OpenERP as a sandbox.

[2] Perhaps this could be per account (depending on country and book-keeping
"mode"). If they are "tax" or "invoice" or "expense/income" accounts, they
would be locked. If they are "petty-cash" ones, they could be relax. I repeat,
this is country-dependant (or better, chart-of-account-dependant).

[3] I can thing, at least, of the case for hospitals or medical entries, that
everything must be recorded and be able to audit. I think we have a rule also
for Hotel reservations, too, here.

[4] If implemented, it should be really *hard* to circumvent, because such a
loss would be violating the law. I was thinking of Pg. triggers or rules; yes,
that much. This way, it would ensure that the data is preserved, even if
somebody tries to mess with SQL.

[Ferdinand (office-chricar)]

On Saturday 06 November 2010 P. Christeas wrote:
> On Wednesday 13 October 2010, you wrote:
> > Public bug reported:
> >
> > IMHO a serious accounting issue
> >...that posted entries
> > may not be altered in a way that the original posting can't be reproduced.
> >
> > violating this principle ... will not be accepted by the fiscal
authorities.
>
> Definitely agree.
>
> On a production system, where OpenERP is used for /official/ [1] accounting,
a
> hard rule[4] must be imposed that accounting moves [2] should not be altered
> or deleted.
>
> That said, this rule might be useful for other models, too [3].
>
>
> [1] Some installations chose to install OpenERP and then send the accounting
> data to their chartered accountants, which do the official bookkeeping. In
that
> case, the "first-level" accounting is not bound by the law. For them, the
hard
> rule /need/ to be relaxed, because they would use OpenERP as a sandbox.
>
> [2] Perhaps this could be per account (depending on country and book-keeping
> "mode"). If they are "tax" or "invoice" or "expense/income" accounts, they
> would be locked. If they are "petty-cash" ones, they could be relax. I
repeat,
> this is country-dependant (or better, chart-of-account-dependant).
>
> [3] I can thing, at least, of the case for hospitals or medical entries,
that
> everything must be recorded and be able to audit. I think we have a rule
also
> for Hotel reservations, too, here.
>
> [4] If implemented, it should be really *hard* to circumvent, because such a
> loss would be violating the law. I was thinking of Pg. triggers or rules;
yes,
> that much. This way, it would ensure that the data is preserved, even if
> somebody tries to mess with SQL.
I have implemented such a trigger system already

IMHO you forgot to mention the role of implementing partners

If these have no chance to trace changes they are "lost", because nobody can
answer questions of clients if delteing and altering of data is arbitrary.
>
>
--
regards
Ferdinand Gassauer
ChriCar Beteiligungs- und Beratungs- GmbH
Official OpenERP Partner

[Ferdinand (office-chricar)]

In respect to
https://bugs.launchpad.net/openobject-addons/+bug/659540/comments/5
[1] transfer the accounting data to the chartered accountant

we are trying to just avoid this and ask the chartered accuntant to work with OpenERP .
as none of these companies offer a comprehensive ERP there seems to be a huge market for OpenERP, but for this OpenERP has to comply to accepted accounting rules.

[Cristian Salamea (ovnicraft)]

Hello about this we implement some changes in invoicing to accept in the best way the cancel process, adding a move_cancel_id in invoice and don't accept remove the move_id (in our country that is not accepted).
I let you our branch with this changes https://code.edge.launchpad.net/~ovnicraft/openobject-addons/cancel_process still in development process but show the concept clearly.

Best regards,

[Ferdinand (office-chricar)]

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.

[Cristian Salamea (ovnicraft)]

Completely agree with @Ferdinand and @Borja solution openerp-sa must rename the module to account_delete, i am working in my changes to separate them in a account_cancel module but now i cant merge official branch with my module

Regards,

[Fabien (Open ERP) (fp-tinyerp)]

they are cancelled (you can cancel manually)
only if you cancel from the invoice, it also delete.

[Ferdinand (office-chricar)]

@Fabien
I am astonished that you downturn legal requirements.

deleting posted account moves and move lines - regardless from where this is done - is illegal in most countries

[marcomarkiori (marcomarkiori)]

I think there is a bit of confusion between accounting and technical
requirements.
If I wrote my accounting manually on paper I would be required not to
modify without tracking my written entries.

Openerp allows me
- to avoid any modification/cancellation made in a journal (by default)
- to cancel or modify an entry by installing the account_cancel module
and by checking the option for the journals I want to enable.

By canceling an entry I turn a posted entry into a non-posted entry:
if I do so within the legal terms of posting or auditing I don't see
any sense in giving an accounting evidence of the change (e.g. in the
case I wrongly duplicated an invoice or wrote some non-sense).
I guess no auditor in Gemany nor in France nor in Italy would lose
time on tracking nonsensical bookings.
An IT auditor would instead be interested in finding out some
fraudolent use of that functionality.

In turn if I wanted to track any of the entries of my accounting
people in real-time I won't allow for those journals the cancel
functionality.
The only problem I honestly see in openerp is that it doesn't allow me
to record a credit note in the same journal I used to post the invoice
I want to adjust.

Anyway I don't see any 1.4 point in the german document you attached:
could you please specify the article or report the german proposition
to help my understanding?

Ciao

Marco

2011/11/2 Ferdinand @ Camptocamp <email address hidden>:
> @Fabien
> I am astonished that you downturn legal requirements.
>
> deleting posted account moves and move lines - regardless from where
> this is done - is illegal in most countries
>
>
> ** Changed in: openobject-addons
>       Status: Invalid => New
>
> --
> You received this bug notification because you are a member of OpenERP
> Accounting Experts, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/659540
>
> Title:
>  [trunk] account_cancel - naming issue
>
> Status in OpenERP Addons (modules):
>  New
>
> 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 le...

[Ferdinand (office-chricar)]

now (March 23rd. 2011) it's point 3.8. and page 5
********* quote ***********
Unveränderbarkeit
(20)
Eine Buchung darf nicht in einer Weise verändert werden, dass der ursprüngliche
Inhalt nicht mehr feststellbar ist. Daher sind spätere Veränderungen ausschließlich
so vorzunehmen, dass sowohl der ursprüngliche Inhalt als auch die Tatsache, dass
Veränderungen vorgenommen wurden, für einen sachverständigen Dritten in
angemessener Zeit nachvollziehbar sind. Ab dem technischen Buchungszeitpunkt
darf eine Buchung bei Verwendung der regulären Anwendungsfunktionalität nur
mehr über eine Stornobuchung rückgängig gemacht werden. Änderungen vor dem
technischen Buchungszeitpunkt sind hiervon nicht betroffen.
********* end quote ***********
I hope this is clear enough

Hence - account_move with state "Posted" most not be modified.

my point is - we should distinguish between cancel and delete

cancel - must be done using reversal postings - and this function is needed.
delete - must not be done/used. (especially not if partners are involved)
may be once the audit module works and traces deletion of account_move_lines it can be considered as a technically valid option. (but not accounting)

the module name suggests that it cancels, but it deletes posted moves

I also acknowledge, that it might be desirable to alter some less important fields in invoices, but this opens doors to fraud.

Because of this I also recommend to implement rules not to allow deletion of attached invoices, pickings, sales order, purchase order etc. once these are confirmed.

[Vadim - Enapps LTD (vadim-enapps)]

In the UK we dont have such fiscal laws and as such a flexible system is always preferred. at the end of the day - its upto the company who implements the system to install the extra module and allow the deletion of such records and/or allow end users full access to delete these.

If you dont want to allow deletion of account_moves then I believe this is very simple to implement and as such you will only be able to cancel the moves and not delete.

[Amit Parik (amit-parik)]

Hello,

For the sake of the clarity of launchpad and also this is not a major issue that's why I am closing this issue.

Please try with new version.

Thanks!