Another "banker's rounding" problem

[Kent Multer]

A client just contacted me because a custom discount module generated a price of $1.64. The actual price was $1.645, and the VM rounded down instead of up, because it's hard-coded to use banker's rounding.

I guess bankers use this because of situations like computing interest on an account, where they multiply the balance by a very small number, again and again over many years. In a situation like that, the rounding errors could eventually add up to a non-trivial amount. But of course, most Miva users never do that.

Some years ago, Miva added a setting to the State Tax module to select normal rounding. But the store still uses banker's rounding for everything else. Is there a way to change that? If not, maybe it's time to add one? I think so. The problem has come up in the forums a number of times.

Do all the built-in discount modules use banker's rounding? If so, there may be a lot of stores generating these errors, and the users just never noticed, or shrugged it off.

Just one man's opinion ... Thanks --

[Keifer Hunniford]

Can you point to a precedent for changing here? MivaScript uses bankers rounding.. as does python, php, ruby.. I don't know the history on sale tax, but I imagine that feature was added to satisfy a legal requirement where some government body dictated that bankers rounding should not be used on sales tax. As far as I can tell, bankers rounding in computing is the accepted standard.

[Kent Multer]

Hi Keith, this is not the first time I've had a client report a problem because the store was generating numbers that are one penny off from what their in-house system produced. And a search of the forum shows that I'm not the only one. I didn't want to tell the client, "Your accounting software (or person) got it wrong; Miva's number is really correct."

[Keifer Hunniford]

This is the challenge though. Different systems having different rounding opinions. If we changed how we rounded discounts we would be one cent off from a completely different group of integrated systems. Can you show me somewhere else that this happens around discounts though? I know I have seen it around sales tax, but I've never seen that because of bankers rounding, but if you can point me in the right direction I'd like to see it. Where things are one cent off is much more likely to be around sales tax, where something like a taxjar or avalara is passing back to us a bunch of line items which have each been rounded, and a remote system is taking the entire total and applying a sales tax calculation to that as a single line item. That happens. That's not bankers vs standard rounding issue. That's an issue from the sum of rounded numbers.
A

[Kent Multer]

Yes, as you said, different systems use different kinds of rounding. That's why it seems like the users should be able to choose.

I'm not specifically aware of any other problems with this in discount modules; but as I wrote, it seems very possible that some users are having trouble with it. I think it's more likely to occur for stores that sell inexpensive "nuts and bolts" -type items in large quantities. I remember seeing a forum post from a user who had that situation.

In this case, my client's store sells a product with a list price of $4.70, and some customers get 65% off. 4.70 times 0.35 equals 1.645, so they want to charge $1.65, but the discount module is generating $1.64. This particular discount module is one that I wrote. It's fairly new to them, but it's been in use by another store for several years, and is performing flawlessly except for this problem.

I can modify the code, of course. But since this has come up before, I thought I'd ask about it. I honestly wasn't aware that banker's rounding is an industry standard. 4 years of Computer Science in college, and they never mentioned it ... Of course, that was a long time ago, back in the days of wooden computers and iron programmers ...

I'll pass this information on to the client and see what they think. Possibly they will want to join this thread. Thanks --

[Keifer Hunniford]

The "nuts and bolts" issue is not related to the rounding approach, it's got to do with what happens when you round very small numbers using any approach. I get that we're doing it one way, and the customer would prefer it the other way - I just don't see any precedent for rounding being a configurable setting, and I also see bankers rounding as the most common rounding strategy around money.