I don't know where the 4 came from...
>My final number calculated by Emerald is $200.04 no matter which way I
enter it.
If you can use enough decimal places it can work out, but I think Dale is
saying ver 2.5.285 only uses 2 places.
Emerald internally seems to track more decimal places than two (that's a
good thing), though I don't know how many. Appararently, the calculations
used to generate Invoice.Amount are rounding to 2 decimals in the wrong
place and that's why Emerald's MBR total is correct and Invoice.Amount is
not.
Josh
*********** REPLY SEPARATOR ***********
On 5/20/99, at 10:48 AM, PowerNet wrote:
>With our rates at $25 per month and annual at $200, you are paying for 8
months getting 4 free.
>You started from an odd number to begin with, our work out that way.
>It should be exactly 1/3 discount or 33.3333% which worked in the old
Emerald 2.5.278
>
>Dale! How many decimal places will Emerald 2.5.285 use to calculate the
discount?
>
>*********** REPLY SEPARATOR ***********
>
>On 5/20/99, at 10:31 AM, Josh Hillman wrote:
>
>>From: PowerNet <psc5@powersupply.net>
>>How do I fix the problem?
>>That is the million dollar question.
>>
>>
>>I had to do the same thing that you're doing to remove 2.5 cents off of
the
>>total value to make it a bit more even (that's what I was referring to in
my
>>message before). I wrote down the following, then used a calculator to
>>figure out the exact discount amount needed to do the trick. We have two
>>primary accounts that are discounted annually and semi-annually (didn't
have
>>to modify that one). One is normally $19.95/month and the other is
>>$24.95/month. Our annual discount is that you pay for 9.5 months and get
>>2.5 free.
>>
>>24.95 x 12 = 299.40
>>19.95 x 12 = 239.40
>>
>>9.5 / 12 = 0.79166666666666666666666666666667
>>Discount = 100 x (1 - 0.791667)
>> = 20.8333
>>
>>24.95 x 9.5 = 237.025
>>19.95 x 9.5 = 189.525
>>
>>Removing 2.5 cents from the two totals above would make the numbers fairly
>>nice:
>>237.025 --> 237.00
>>189.525 --> 189.50
>>So I needed to adjust the discount to compensate for the removal of the
2.5
>>cents.
>>(disireable discount divided by non-discounted...)
>>237.00 / 299.40 = 0.79158316633266533066132264529058
>>189.50 / 239.40 = 0.79156223893065998329156223893066
>>
>>Notice that the values are not the same, but they're very close. You can
go
>>with one or the other or interpolate between the two to come up with a
final
>>adjusted discount.
>>
>>Adjusted discount = 100 x (1 - 0.791583)
>> = 20.8417 (20.84168 rounded)
>>OR
>>Adjusted discount = 100 x (1 - 0.791562)
>> = 20.8438 (20.84377 rounded)
>>OR (via interpolation)
>>Adjusted discount = (20.8437... + 20.8416...) / 2
>> = 20.8427 (not 20.8428)
>>
>>20.84 causes an extra penny to be added to both accounttypes after
>>calculations, so that value isn't specific enough. I ended up using
20.8427
>>(the interpolated one) and both totals come up perfect:
>>237.00
>>189.50
>>
>>Josh
>>
>>*********** REPLY SEPARATOR ***********
>>
>>On 5/19/99, at 3:13 PM, Dale E. Reed Jr. wrote:
>>
>>>Josh Hillman wrote:
>>>>
>>>> We've got discounts for annual and semiannual payments for some of our
>>>> accounts also, but are not running into the problem you are. Our
numbers
>>>> are coming out perfect (Emerald 2.1.11 was off by about 3 cents).
>>>
>>>Emerald 2.5.284 and higher corrected a rounding problem that was
>>>present in Emerald 2.5.26x through 2.5.283. It would round the
>>>values read from the DB to two digits BEFORE the calculations,
>>>which cause major accuracy problems.
>>>
>>>> From what I can tell, Emerald is calculating everything correctly. I'm
>>>> using the same version that you are (on my testing machine)...
>>>
>>>After looking at his numbers, he was relying on the rounding
>>>for his numbers to come out correctly (and lower than they
>>>should have). Unfortunately, the fix is causing his numbers to
>>>have four more cents that he wants.
>>>
>>>
>>>--
>>>
>>>Dale E. Reed Jr. Emerald and RadiusNT
>>>__________________________________________
>>>IEA Software, Inc. www.iea-software.com