[Python-Dev] prePEP: Money data type
aleaxit at yahoo.com
Fri Oct 17 18:44:47 EDT 2003
On Friday 17 October 2003 11:33 pm, Batista, Facundo wrote:
> #- I don't think these are the rules in the European Union
> #- (they're popular
> #- in statistics, but, I suspect, not legally correct in
> #- accounting). I can try
> #- to research that, if you need me to.
> Please. Because I found it in FixedPoint, and researching, think that in
> Argentina that's the way banks get rounded money.
Found it -- article 5 of the Council Regulation which established the Euro
a few years ago is titled "Rounding" and specifies (I quote selectively):
shall be rounded up or down to the nearest cent ... If ... a result ... is
exactly half-way, the sum shall be rounded up.
The regulation goes on to show cases in which two conversions back
and forth (EUR to/from older currencies) can lose or gain a cent, and
such difference cannot be invoked to dispute the correctness of payments. The
difference must be allowed as a 'tolerance' insofar as it results from the
application of the European Regulation.
This 'tolerance' should also be incorporated in data processing programmes,
especially accounting programmes, in order to avoid problems connected with
the reconciliation of amounts.
The Visual Basic FAQ, for example, explicitly warns that VB does *NOT*
respect the legal requirements of Euro conversion rules. The Euro rules
are summarized in the FAQ as:
When rounding to an x number of decimals, the last decimal must be:
- Rounded down (i.e. left alone) when the following decimal (if any) is 4 or
- Rounded up when the following decimal is 5 or more.
while VB's rules are:
If after the digit that is to be rounded, the digits following are exactly
equal to 5, the value is rounded to the NEAREST EVEN NUMBER.
(I _think_ it means "the digit ... is", NOT "the digits ... are"). In fact,
follow-ons clarify that VB isn't fully coeherent on these rules (hah).
But the point remains: rounding half a cent to even rather than always
up violates European Union law; nor can the "tolerance rule" be invoked,
because it's specifically limited to one-cent discrepancies that "result
from the application of the European Regulation", while this one would
result from the _violation_ thereof. Oh BTW, other sites quite explicitly
state that the rule applies throughout the EU, _not_ only to countries
that have adopted the Euro.
FWIW, Rogue Wave's Money class lets you specify _either_ rounding
approach -- ROUND_PLAIN specifies EU-rules-compliant rounding,
ROUND_BANKERS specifies round-to-even, for exactly in-between
amounts. Offhand, it would seem impossible to write an accounting
program that respects the law in Europe AND the praxis you mention
at the same time, unless you somehow tell it what rule to use.
Sad, and seems weird to go to such trouble for a cent, but accountants
live and die by such minutiae: I think it would not be wise to ignore them,
PARTICULARLY if we name the type so as to make it appear to the
uninitiated that it "will do the right thing" regarding rounding... when there
isn't ONE right thing, it depends on locale &c:-(.
More information about the Python-Dev