tax should be calculated against actual charge (after rounding)

Bug #1022477 reported by Michael
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
citrusdb
Confirmed
Undecided
Unassigned

Bug Description

If the calculated charge for (e.g.) an hourly rate service has a fractional element
then it is rounded to the nearest whole number of cent.
However the tax is calculated against the original, fractional charge.
This means the tax charged is incorrect.
For example, suppose a telephone call would cost 23.556c. This rounds to 24c.
A tax at 23% should be 24 * 0.23 = 5.52c, which rounds to 6c.
What appears is 5c - because it is calculated 23.556 * 0.23 = 5.41c, rounded to 5c).
The revenue don't care what we would have charged if we could charge fractions
of a cent, they calculate tax against the actual charge.
And a customer who is charged more tax than he expects may also question us.

A closely associated problem is that the actual usage is not shown on the
invoice because it is the usage that is adjusted to produce a whole numbered
charge.
This is obscure and misleading: a customer who checks the reported usage
may think we're measuring usage incorrectly and complain.
If he could see the actual usage, he would readily understand that the charge
has been rounded to the nearest cent.
It is especially confusing where, to round the charge, the usage is adjusted
to a figure that is also not a round number (because the rate is not a round
number).
In fact, if this problem were corrected then the first problem (with the tax
calculation) might be less of an issue, since anyone checking could do the
multiplication for himself to see what the fractional charge was.

While it may be argued that neither the revenue nor customers will, on average,
be out of pocket, we would much prefer not to have to explain these quirks to
them.

Revision history for this message
Michael (nabl) wrote :

Note that the current behaviour becomes even more
obviously wrong when two successive lines on an invoice
show the same usage and the same charge but a
different tax figure (because in one case the usage has
been invisibly rounded up and in the other it has been
invisibly rounded down).

Changed in citrusdb:
status: New → Confirmed
Revision history for this message
Paul Yasi (paul-citrusdb) wrote :

You are the first person I know to try and use this like a telecom rating engine for amounts with partial pennies.

Revision history for this message
Paul Yasi (paul-citrusdb) wrote :

The other way to "fix" this may be to add a check that would dissallow partial penny rates on things, it's certainly not a feature many people need.

Revision history for this message
Paul Yasi (paul-citrusdb) wrote :

If this calculation is changed then it would probably have to be done in versoin 3 since it's a major change to the way it would do billing calculations.

Revision history for this message
Michael (nabl) wrote :

Perhaps I should have asked before I started creating a
configuration package for CitrusDB whether it had ever
been used in a telecoms-style context.
Though in fact I did mention in it in my message to the
mailing list on 23 May.
It is essential for our application that we able to define
rates in fractions of a cent - so prohibiting that is
certainly not a fix.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.