openerp-expert-accounting team mailing list archive

[David Mitchell <david@xxxxxxxxxxxxxxxxxx>]

OpenERP appears to be built with the “contra-accounting” approach. So the
rule is to reverse transactions (e.g. an invoice) you have to create a
“Credit Memo”. The default behavior for transaction reversal is to disallow
negative transactions - obviously with the code you identified below.

In many countries negative transaction lines are looked upon unfavorably by
auditors and the expectation is that transactions are reversed using contra
accounting. Based on our knowledge these countries include (but are not
limited to): United Kingdom, and the United States, etc. <--I believe Spain
falls here as well - but you would know better than us on this one.

Negative Accounting is known as Storno accounting.

Allowing Negative transactions are considered best practice in some
countries like:

   -

   Czech Republic
   -

   Poland
   -

   Romania
   -

   Russia
   -

   Slovakia
   -

   Ukraine

Some systems allow for transaction reversal by using negative values. In
this case they often have an “Allow Negative” option (boolean flag) –
associated with a particular accounting schema, and in some instances also
at the individual document level.

We actually see three flags present to drive storno logic:

Reversal Entry (boolean) – default off

Reversal Closing Entry (boolean) – default off

Reversal P&L General Ledger Accounts (boolean) – only available if Reversal
Entry boolean is True, default off.

This accounting only affects Profit/Loss statements and should have no
affect on Balance Sheets.


By default we believe OpenERP should default to contra accounting methods –
with the ability to enable negative transactions for specific countries with
configuration settings in the future

Other competitors support it  . . .OpenBravo supports both approaches. Exact
is another software package that supports both – referenced later in this
document.

Like your example, if a sales invoice document generates the following
transactions lines:

GL

Line Type

Debit

Credit

Receivables

Sales Invoice

1,000

0

Revenue

Sales Invoice

0

1,000


 In Countries where contra accounting is popular to reverse an entry – the
user would create a credit memo. In effect reversing the original Sales
Invoice Entry.

GL

Line Type

Debit

Credit

Receivables

Sales Invoice

0

1000

Revenue

Sales Invoice

1000

0


 TO REVERSE A TRANSACTION WITH STORNO Accounting – Negative Accounting

If the Allow Negative option is selected, when a transaction is reversed,
the system will allow the creation of the following negative transaction
lines.

GL

Line Type

Debit

Credit

Receivables

Sales Invoice

-1,000

0

Revenue

Sales Invoice

0

-1,000


 Exact software has a nice chart which shows some of the transactions and
their disposition between contra accounting and storno accounting. The issue
I believe that is larger is actually reporting on the P&L statement. This
provides a good overview.

http://www.exactsoftware.com/Docs/DocView.aspx?DocumentID
={d1e369f9-69d4-4782-8757-79bc0a637e8e}


 It would be curious to hear from the affected countries that adopt Storno
Accounting. Perhaps there is already a set of localized modules that allow
this to jumpstart the storno support in the ecosystem. Anyone??

Personally, I’d like to see the system stabilized using contra-accounting
first (and run really really well) – and then if there is demand – have the
system support storno accounting leveraging the work already done – if there
is any.

David Mitchell

President

NovaPoint Group LLC



 Storno accounting is obviously being supported by other “competitive
software applications”.


On Mon, Aug 30, 2010 at 4:14 AM, "Borja López Soilán (Pexego)" <
borjals@xxxxxxxxx> wrote:

>  Hi accounting experts.
>
> I have a question for you: *It is really needed that the debit and credit
> are positive?*
>
> (I posted the question on LP:
> https://answers.launchpad.net/openobject-addons/+question/123322; I will
> update it with the given answers)
>
>
> Currently on the OpenERP accounting we have some constraints like this one:
>
> _sql_constraints = [
>         ...
>         ('credit_debit2', 'CHECK (credit+debit>=0)', 'Wrong credit or debit
> value in model !'),
>     ]
>
> That 'credit_debit2' constraint is checking that the accounting entries are
> always positive. But the question is:
>
> Is it really needed? Why shouldn't we use negative entries?
>
> I mean, on Spain nothing prevents to use negative accounting entries, so a
> lot of accountants are used to do that on some specific cases, like some
> kinds of refunds (that also means that accounting programs usually allow the
> users to do it).
>
> So, on paper, to cancel this sale invoice:
>
>                         Debit      Credit
> (430) Customers         118
> (700) Sales                           100
> (477) Taxes                            18
>
>
> Some accountants would create accounting entries like this one if the
> invoice was just invalid (a cancel):
>
>                         Debit      Credit
> (430) Customers         -118
> (700) Sales                          -100
> (477) Taxes                           -18
>
>
> Instead of this other option that would be used mostly when doing a real
> refund of the goods:
>
>                          Debit      Credit
> (7080) Refunds             100
> (477) Taxes                 18
> (430) Customers                        118
>
>
> But currently on OpenERP the first option is not possible.
>
> I think that the "allow negative values" should be an option per journal,
> so in countries requiring positive values this can be enforced, but on
> countries that allow negative moves this check can be disabled.
>
> What do you think?
>
> --
> Borja López Soilánborjals@xxxxxxxxx
>
> Pexego Sistemas Informáticos S.L.
> Avenida de Magoi 66 - 27002 Lugo (España)
> Tel./Fax 982801517http://www.pexego.es
>
>
> AVISO LEGAL - CLÁUSULA DE PRIVACIDAD
> Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es usted el destinatario indicado, queda informado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>
>
> _______________________________________________
> 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
>
>