Re: [Emerald] calculating termed-discount values

PowerNet ( (no email) )
Thu, 20 May 1999 11:55:54 -0400

My billing person really likes some features added to 2.5.285.
The rest of the program seems to be working, and now this.
It is a major inconvenience to use 2 different Emerald exe's just to get=
through the billing every day.

John

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

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

>From: PowerNet <psc5@powersupply.net>
>>By your formula, I come up with 33.3334% discount. When I enter that in
>Emerald Administrator, it makes no difference.
>
>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 =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