Contributors mailing list archives

contributors@odoo-community.org

Avatar

Re: Accounting: writing on debit/credit fields

by
Open Source Integrators, Daniel Reis
- 30/05/2019 08:22:05
Graeme, true but you underestimate how detail oriented accounting/finance people can be.

I’ve spend my share of time searching for 0.01 differences at the request of a CFO or Accounting Manager...

--dr 

No dia 29/05/2019, às 15:37, Graeme Gellatly <gdgellatly@gmail.com> escreveu:

Frederik,

In most jurisdictions discrepancies need to be material and this won't reach that standard. Even in a worst case of say 100% of transactions affected, and average move value of $1, with all debit moves out by 0.5 of a cent you are talking 0.5%. At $10 its 0.05%. But realistically only a max of 5-10% of transactions would be affected, so you are talking 0.005% max and that is being generous, even with low transaction values. For a normal case it would be closer to 0.0001%. I'd be surprised if anyone cares, even the German tax authorities.

Just sum the difference beforehand, compare it to submissions, and if need be, make an adjustment afterwards based on whatever standard you are subject to for Immaterial prior period misstatements. Just call it historical rounding errors or something. In any case, the nature of the error indicates it would manifest itself in the current period, before final statements are ready, so probably no issue. Especially since, on screen, it all looks the same.

On Thu, May 30, 2019 at 1:16 AM Frederik Kramer <frederik.kramer@initos.com> wrote:

Hi Alexis,

Thanks for having brought up this very important issue. From a pure accounting perspective thing may have a rather severe impact, though. Though not being a tax accountant myself (disclaimer) i doubt that changing the values on database level would be in line with general good practise of accounting (at least in Germany). So if you decide to change values on DB for historical consistency be advised to ask a tax accountant BEFORE you take action and minium document what you've done and why.

Cheers Frederik

Am 29. Mai 2019 14:51:56 MESZ schrieb Alexis de Lattre <alexis.delattre@akretion.com>:
Dear OCA friends,

Stéphane Bidoul and me would like to warn all Odoo developers about an important problem we found a few weeks ago with some of our customers using Odoo for their accounting. Let me explain the problem:

TL;DR: when you create/write an account.move.line, you MUST round the debit and credit before calling create/write.

If you are interested in the details, read on.

on account.move.line, the fields "debit" and "credit" are defined as fields.Monetary with currency_field='company_currency_id', cf

For a company with EUR currency, we have a decimal precision of 2. Technically, on a recordset of the EUR currency, the field decimal_places = 2.

The problem is the following: if you do:
self.env['account.move.line'].create({
   'account_id': 42,
   'name': 'TEST',
   'debit': 10.0 / 3,
   'credit': 0,
   })
then, in the database, you get:
o2_test1=# select id, debit, credit from account_move_line where id=2;
 id |       debit        | credit
----+--------------------+--------
  2 | 3.3333333333333335 |    0.0

Then, if you use the OCA trial balance (with the module account_financial_report from https://github.com/OCA/account-financial-reporting/tree/11.0/account_financial_report), as the trial balance is doing sums in SQL but displays values with 2 digits, the total sum of the balance is not 0, but has a value of a few cents.

So, when you create/write an account.move.line, you MUST round the debit and credit before calling create/write.

In the OCA account_cutoff_prepaid, we computed some pro-rata to make the cutoff and then generate an account.move, and the code of that module didn't call round() on debit/credit before creating the account.move.
This was reported in this bug report: https://github.com/OCA/account-closing/issues/107
It was fixed in v10 in this PR (still needs to be ported to other versions):
If you used account_cutoff_prepaid to generate journal entries, you certainly need to fix your debit/credit in the database. You can have a look at the script I used to fix the data and use it (at your own risks) :

We should also review all the OCA code that create account.move to see if the debit/credit are properly rounded before calling create/write.

So, for float fields with a decimal precision or monetary fields, the rounding is only done when you enter an amount via a form view, not when you call write/create nor when you read the data via a recordset. 
As you can see in the ORM in the Monetary class (same for Float), the method convert_to_cache() as a rounding logic, but not the convert_to_write(), cf :

We talked about this problem with Joss from Odoo SA ; he is now aware of this problem and will talk about it with his collegues.

--
Dr.-Ing. Frederik Kramer
Geschäftsführer
        
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
        
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
        
Email: frederik.kramer@initos.com
Web:   www.initos.com
        
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Reference