1. Mailing Lists
  2. Contributors
  3. RE: Accounting: writing on debit/credit fields

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Accounting: writing on debit/credit fields

Re: Accounting: writing on debit/credit fields

Avatar

RE: Accounting: writing on debit/credit fields

by
johan
- 31/05/2019 09:56:52

Dear,

 

I like my reports to be penny correct. It gives me peace of mind. And of course there is no problem to write off these small differences at the closing of a periods. But indeed, you always get questions about it. And from 1 question, you get a 2e, 3e, … and in the end it cost you a lot of money -)

So I agree this better get fixed !

 

 

Best regards,

 

Van Hirtum Johan

 

Van: Frederik Kramer [mailto:frederik.kramer@initos.com]
Verzonden: donderdag 30 mei 2019 13:08
Aan: Contributors
Onderwerp: Re: Accounting: writing on debit/credit fields

 

Hi Daniel, hi Graeme,

When claiming it may bei "severe" i was not referring to the size of the miscalculation (which i totally agree, isn't material) but to the fact that it may be illegal to change the behaviour by programatically correcting the error for the future or even worse changing the figures in the past. At least without properly documenting root cause, changes taken and reasoning behind it. If you leave it as it is, it may be severe in the sense that official tax authorities may stumple upon this problem as the Canadian software most European member states license for their tax authorities does statistical analyis on pennies. If they find statistical deviations from documented standards, they start an in depth analysis. If it then turns out the program doesn't calculate correct, they would be at least allowed to estimate your turnover rather than to stick to your digital records. And in this case the company is worse off by orders of magnitude (at least in German accounting history). This in turn was, what i wanted to point out with (it might be severe, ask your tax accountant). If you ask me personally, chances that it really impacts many severly are pretty low but i won't be able to correctly judge if risk is lower if you change the code and the historical data or leave it (the data, not the code) and explain it if identifed, or entirely leave it as it is (code and data) and explain it it asked. The only thing i would ask people to avoid, is taking their own decision without expert advise on accounting in there country or even their region.

Best Frederik




Best Frederik

Am 30. Mai 2019 11:42:19 MESZ schrieb Graeme Gellatly <gdgellatly@gmail.com>:

Daniel,  

 

I think you are misunderstanding finance departments and my statement (which implicitly said talk to finance for the correct treatment for your jurisdiction). They don't care that there is a 1c difference per se, they care why there is a 1c difference and I am in total agreement with them that it matters. You must be able to explain the difference, and as long as it can be explained, and action (including no action) taken then it no longer matters. Dealing with errors, misstatements, adjusting events and there consequent treatment is a fact of life and why standards exist for dealing with them. In this case presented here, the amounts are certainly immaterial, probably current period, and easily dealt with as opposed to having a "rather severe impact".

 

On Thu, May 30, 2019 at 8:27 PM Daniel Reis <dgreis@sapo.pt> wrote:

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

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

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


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