Re: [Emerald] calculating termed-discount values

PowerNet ( (no email) )
Thu, 20 May 1999 11:51:45 -0400

Did you post this on the beta list? I am not a member of that list yet.
My understanding was that this ver 2.5.285 was released on Monday and is no=
longer beta.

Any ideas?

John

*********** REPLY SEPARATOR ***********

On 5/20/99, at 11:37 AM, Josh Hillman wrote:

>From: PowerNet <psc5@powersupply.net>
>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
>
>
>I just duplicated your pricing scheme on my test computer. I changed the
>Annual discount to 33.3333 and an AccountType that has a normal monthly
>charge of 25.00 ended up totaling 200.00 without any problems.
>
>Actually, I just now found what you're talking about.
>
>Emerald shows 200.00 for the total all throughout the program, but when an
>invoice is generated, there must be some kind of calculation problem
>(rounding?) that's bumping up the Invoices.Amount value to 200.04. I=
don't
>have any taxes set anywhere in my system, so it's not related to that.=
Here
>are a couple of my findings:
>
>Montly MBR
>Rate Discount Total Invoice.Amount
>---------------------------------------------
>25.00 33.3333 200.00 200.04
>24.95 20.8427 237.00 237.00
>19.95 20.8427 189.50 189.48
>19.95 16.6667 99.75 99.72
>
>Follow-ups on this should actually be going to the Emerald beta mailing
>list...
>
>Josh
>
>*********** 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 =3D 299.40
>>19.95 x 12 =3D 239.40
>>
>>9.5 / 12 =3D 0.79166666666666666666666666666667
>>Discount =3D 100 x (1 - 0.791667)
>> =3D 20.8333
>>
>>24.95 x 9.5 =3D 237.025
>>19.95 x 9.5 =3D 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 =3D 0.79158316633266533066132264529058
>>189.50 / 239.40 =3D 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 =3D 100 x (1 - 0.791583)
>> =3D 20.8417 (20.84168 rounded)
>>OR
>>Adjusted discount =3D 100 x (1 - 0.791562)
>> =3D 20.8438 (20.84377 rounded)
>>OR (via interpolation)
>>Adjusted discount =3D (20.8437... + 20.8416...) / 2
>> =3D 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