$25 x 12 =3D$300 discounted @ 33.3333 % =3D $200.04
$20 x 12 =3D $240 discounted at 20% =3D $200.00
Now will this work as a fix and not distort any other information. I=
hesitate to say distort reports, because they don't work correctly either.
Will this work?
*********** REPLY SEPARATOR ***********
On 5/21/99, at 1:07 PM, Josh Hillman wrote:
>From: Dale E. Reed Jr. <email@example.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).
>>200 / 12 =3D 16.66666....
>>However, 16.66 * 12 =3D 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=
>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=
>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=
>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
>I'm just bouncing ideas around. Maybe I've been in the realm of
>science/engineering too long and am used to deeper precission...