No, it’s not the latest Dr. Seuss book.  It’s dealing with rounding of numbers, and in this case currency within  eCommerce websites.

Rounding has been part of computer languages as early as FORTRAN and C, which started back in the 1950s.  Unfortunately for developers during those times, various forms of rounding had to be coded specifically for each instance.  Since then, however, more modern programming languages allow for various rounding options in much easier fashions.

eCommerce sites often integrate with multiple downstream systems.  The DOD EMALL — the largest Government eCommerce site for federal buyers — is no different.  Recent efforts within DOD EMALL have been to compare all uses of currency within the application, as well as to review their uses in downstream systems.

How many versions of rounding can there be?  Well, there are numerous forms of rounding, including round-up, round-down, round-ceiling, round-floor, round-half-even, round-half-up, and round-half-down.  It really depends on how complex you want (or need) things to be.  Software developers may be wondering why their code isn’t acting as expected, and will be seeking answers. As a DOD-contracted IT-provider for the DOD EMALL, Partnet has used several rounding functions, but here are a couple of examples:

The first example is the one you probably learned when you were a child. Round-Half-Up goes to the nearest neighbor —  less than 5 rounds down, equal to or greater than 5 rounds up.

Round-Half-Up Examples
Initial Value 2 Digits of Precision
3.2277 3.23
3.22277 3.22
3.22255 3.22
3.275 3.28

Round-Half-Even is different, as it rounds to the nearest neighbor value (less than 5 rounds down, greater than 5 rounds up), but if it is 5, then it rounds to the nearest even number (either by staying or going up).

Round-Half-Even Examples
Initial Value 4 Digits of Precision
3.22223 3.2222
3.222347875 3.2223
3.222247875 3.2222

So why is rounding a big deal?  If you round a value one way in one system, but then round another way with the same value in another system, you end up with different numbers.

Also, if you are dealing with multiple quantities, the sequence in which you perform the functions is important.  If you multiply then round, you may get a different number than if the sequence were vice versa.  Within eCommerce sites, you may have items that cost a fraction of a penny.  There may be items sold for $0.004 that when ordered in a bulk of 10, is computed as $0.04.  To prevent those  items from being free ($0.00), you would want to multiply the quantity before rounding.

And remember, you are dealing with currency, so those different numbers represent real money!  Even if it’s only off by a couple of pennies — if your application processes thousands of transactions per day (as the DOD EMALL does) . . . well, those numbers add up quickly!

So, how do we fix it?  Obviously, the best way is to stop it up front.  Follow the System Development Life Cycle (SDLC).  Gather your business requirements, document your implementation plan, perform design reviews, perform code reviews, and perhaps most importantly, perform your end-to-end testing!  End-to-end testing is critical to make sure that all systems work well together and you acheive the desired result.

One thing is for sure . . . . don’t spend a day working with round-half-even and other rounding types and then go home and try to balance your budget!