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 specifies: """ 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 less. - 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:-(. Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4