I was pricing out what the Home Monitoring will cost if I were to add all of my Windows and Doors. The pricing is not necessarily incorrect, but the entry sensor total is not rounded to 2 decimal places. See the Image Below.
I am using the Beta App, so not sure it exists in the Released version of the App.
That’s funny. In my programming classes I recall they were telling us these kind of problems happen all the time with businesses because they will choose a number type of “double” or “float” for currency fields and then when you do calculations (multiplication, etc) it doesn’t calculate exactly the way you expect it to, because technically speaking the double or float number isn’t kept to a precise value as intended, but they are stored as an exponent plus a fraction and is thus stored with as many bits as the computer has left after the storing the exponent, so the precision degrades more the larger the number becomes.
As an example, $160.01 isn’t stored as 160.0 1, it’s stored as the fraction 1.600999999999999996 with an exponent of 1*10^2. So as you multiply this value, it technically calculates incorrectly the larger it gets. I am having this same problem with a payroll system I manage because the devs encoded things using double or float designations and so everything is calculated screwy.
I believe that is the same thing happening here. For the most part it will ultimately round off to a correct number, or nearly correct…but it means someone didn’t set it all up correctly to be precise. Most databases will include an explicit money type to correct these issues and make sure it all calculates correctly,…but it apparently was used here. You’ll see this kind of thing happen a lot if you pay close attention. By default it can be difficult to make it precise since currency isn’t one of the default options with most basic programming.
I would have to agree, I also manage a development shop and an Emerging Technology Group. This is something that some developers lack the attention to pick the correct type. Or at least the correct rounding.
You would have expected something like this to be caught, the database may be setup correctly, but the front end developer may have converted it incorrectly.
I am sure you are right that it’s more likely that the database has it correct and the front end is wrong (though it’s possible the backend is wrong and the front end is just displaying it).
Either way, it was a good catch and it also always brings me a good chuckle to see it happen. Hopefully someone fixes it. At the very least they can just apply the correct rounding display and nobody will know the difference unless they order TONS of devices in the same order and suddenly show they got an extra penny off. If it worked, I’d say they deserve the small discount for such a high volume order anyway.