Tryton's rounding does not fit to German requirements

18 Aufrufe
Direkt zur ersten ungelesenen Nachricht

Udo Spallek

ungelesen,
08.11.2010, 13:07:0108.11.10
an tryton
Hi,

Tryton uses the round half to even method for currencies[1], aka bankers
rounding[2]. In Germany we use another rounding, called round half
up[3].

Example
-------

A net amount of an invoice has 1257,50 EUR. The tax is 19%.

Exact Total Amount = 1257,50 * 1,19 = 1496,425 EUR

Total Amount Tryton = 1496,42

Total Amount Germany = 1496,43

Questions
---------

* Are there other nations using round half up, like used in Germany?

* At least for Germany we need an upstream module which fix this issue.
Is such a module welcome? (I will write it and put on codereview.)

* The name of the module could be currency_round_half_up and just
overwrite the default value of the round method signature. Is this
the way to go?


[1]
http://hg.tryton.org/1.8/modules/currency/file/9087d8922511/currency.py#l163

[2] http://en.wikipedia.org/wiki/Rounding#Round_half_to_even

[3] http://en.wikipedia.org/wiki/Rounding#Round_half_up

Regards
--
Udo Spallek

------------------------------------
virtual things
Preisler & Spallek GbR
Munich - Aix-la-Chapelle

Windeckstr. 77
81375 Munich - Germany
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56

in...@virtual-things.biz
http://www.virtual-things.biz


Cédric Krier

ungelesen,
08.11.2010, 13:46:2908.11.10
an try...@googlegroups.com
On 08/11/10 19:07 +0100, Udo Spallek wrote:
> Hi,
>
> Tryton uses the round half to even method for currencies[1], aka bankers
> rounding[2]. In Germany we use another rounding, called round half
> up[3].
>
> Example
> -------
>
> A net amount of an invoice has 1257,50 EUR. The tax is 19%.
>
> Exact Total Amount = 1257,50 * 1,19 = 1496,425 EUR
>
> Total Amount Tryton = 1496,42
>
> Total Amount Germany = 1496,43
>
> Questions
> ---------
>
> * Are there other nations using round half up, like used in Germany?

I don't know.

> * At least for Germany we need an upstream module which fix this issue.
> Is such a module welcome? (I will write it and put on codereview.)

Yes of course.

> * The name of the module could be currency_round_half_up and just
> overwrite the default value of the round method signature. Is this
> the way to go?

Looks good.

--
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: cedric...@b2ck.com
Website: http://www.b2ck.com/

Phillip Heller

ungelesen,
11.11.2010, 14:35:2711.11.10
an try...@googlegroups.com

On Nov 8, 2010, at 12:46 PM, Cédric Krier wrote:

> On 08/11/10 19:07 +0100, Udo Spallek wrote:

<snip>


>
>> * The name of the module could be currency_round_half_up and just
>> overwrite the default value of the round method signature. Is this
>> the way to go?
>
> Looks good.

What about multi-national multi-company installations? Would it not be better to add as an attribute set within the company model, then retrieved from context whenever rounding is done?

Regards,

Phil

Udo Spallek

ungelesen,
12.11.2010, 10:31:0912.11.10
an try...@googlegroups.com
Sounds promising. But I am unsure if it is not better done in a separate
module. When you want to consolidate data of depending companies like a
headquarter with its daughter company you will have rounding differences
on using different rounding methods. I guess these differences needed to
take care in accounting. Because the small rounding differences could
create unbalanced balances in the headquarter company.

It is the same situation with the party module. One of our multi-company
interests (multi national education sector) request separate parties for
different companies. But some parties should be shown in all companies.
Nested companies should see their own parties and the parties of their
children companies. Some headquarter parties should be shown in all
companies.

Multi company setup can be very complicated and special. Most I'm
missing is a general idea of a flexible multi-company setup.
IIRC, I have started some general thoughts about this in the past, if
you or someone else is interested to discuss, I will share them.

But another idea could be to put the needed modification on rounding
inside the account_de_skr03 chart of accounts module. This has the big
benefit, to easily remove the code on migration, when we have a
multi-company solution. This is much more easy then removing an already
installed module in Tryton.

Cheers

Cédric Krier

ungelesen,
12.11.2010, 10:50:1712.11.10
an try...@googlegroups.com
On 12/11/10 16:31 +0100, Udo Spallek wrote:
> Am Donnerstag, den 11.11.2010, 13:35 -0600 schrieb Phillip Heller:
> > On Nov 8, 2010, at 12:46 PM, Cédric Krier wrote:
> >
> > > On 08/11/10 19:07 +0100, Udo Spallek wrote:
> > <snip>
> > >> * The name of the module could be currency_round_half_up and just
> > >> overwrite the default value of the round method signature. Is this
> > >> the way to go?
> > > Looks good.
> > What about multi-national multi-company installations? Would it not
> > be better to add as an attribute set within the company model, then
> > retrieved from context whenever rounding is done?
> Sounds promising. But I am unsure if it is not better done in a separate
> module. When you want to consolidate data of depending companies like a
> headquarter with its daughter company you will have rounding differences
> on using different rounding methods. I guess these differences needed to
> take care in accounting. Because the small rounding differences could
> create unbalanced balances in the headquarter company.

First, it is not an issue to have difference rounding method when
consolidating accounting because it is just reports (nothing legal).
Second, it should not have issue there because you only make sum. Except if
you have currency convertion but then you will have issue any way.

I find the idea good but it will require modification in all modules.

> But another idea could be to put the needed modification on rounding
> inside the account_de_skr03 chart of accounts module. This has the big
> benefit, to easily remove the code on migration, when we have a
> multi-company solution. This is much more easy then removing an already
> installed module in Tryton.

I perfer to not have code in account_xx modules. And more over, it is not
because you install account_de_skr03 that you are a German company.


For now, I would say that if someone need different rounding mechanism he just
have to write a small module and change the default value ofthe method. But
this module will not be part of the standard Tryton module set.

We need to work to define rounding method on company and use it when rounding.

Allen antworten
Antwort an Autor
Weiterleiten
0 neue Nachrichten