# Re: [Emerald] calculating termed-discount values

Josh Hillman ( (no email) )
Fri, 21 May 1999 13:07:24 -0400

From: Dale E. Reed Jr. <daler@iea-software.com>
>Emerald carries the decimals to atleast 4 places. But as I noted
>earlier, you have to come up with a line item (per month) cost
>to use with the quantity (12 months) to get the line item total.
>The line item cost has to be a dollar value, which is currently
>limited to normal currency (pennies).
>
>Working backwards:
>
>200 / 12 = 16.66666....
>
>However, 16.66 * 12 = 199.92 and 16.67 (the rounding Calculation that
>Emerald 285 is using) is 200.04. If you look closely at your 278
>invoice, the numbers simply do *NOT* add up, and a smart customer will
>see that right away.

This may sound like a stupid question, but is there a real reason to make
the monthly amount (in the case above, 16.66 or 16.67) be restricted to 2
decimal places (obviously corresponding with pennies)? If there's a termed
discount involved with an account, then the customer isn't going to be
paying \$16.67 (or 16.6666667)--they're going to be paying the full term
amount of 200.0x.

So in the case above, the normal monthly rate could really be \$20.000000 and
the annual discounted rate could be \$16.666667 (which is quite a bit
different from 16.67 when calculating an annual total). Nothing at all
would ever come out different with non-termed-discounts, but those that are
affected by termed discounts have a lot more room to allow the admin to
tweak the totals, so the customer woulnd't see "Amount Due: \$200.04" (or
\$199.92) -- it'd be \$200.00 (currently not possible because of the monthly
rate rounding).

I'm just bouncing ideas around. Maybe I've been in the realm of
science/engineering too long and am used to deeper precission...

Josh