Big Decimal Problem

[lpopejoy]

I do service contracts for printers. The price is charged per print, so the price is normally .01869 or something like that. I can create the item with the correct charge, but I cannot get it to actually charge the correct amount when I try to add the charge to an account.

This is really a big problem for me!

Any suggestions?

Thanks,

Luke Popejoy

[Support Team]

Re: Big Decimal Problem

Hi Luke,

The Item price is always stored in the database as is, with all the numbers after decimal point (you can see this by clicking the item price in the charge window). When the charge is created, the total amount for the charge is calculated according to the exact item price, and the total result is rounded to 2 number after the decimal point.

For example:
If you enter 10 * 0.01869 this will result in a total of 0.19 for the charge
If you enter 100 * 0.01869 this will result in a total of 1.87 for the charge
If you enter 1000 * 0.01869 this will result in a total of 18.69 for the charge

You can customize the charge report to show the exact item price, with all the numbers after the decimal point by right-clicking the Charge Price/Rate field, going to Display Format and add the numbers to the format (e.g. "#,0.00000;-#,0.00000").

I hope this makes it clearer.

Ethan

[lpopejoy]

Re: Big Decimal Problem

I'm testing this out, it looks like the problem is being caused because I setup special item pricing for those items. When you do that, it limits the number of decimals to two places.

Correct?

Thanks,

Luke

[Support Team]

Re: Big Decimal Problem

Actually this is not correct (it only looks like it in the display...).

When using the custom pricing it stores the full number, with all the numbers after the decimal point, in the item's custom price. If you create a charge using this item, the correct item price will be calculated, using the numbers after the decimal point. Note that when you create the charge and select this item in the charge window, you can focus on the item's price field (move your cursor to it), and you will then see the full price in this field.

I hope this makes it clearer.

Ethan

[lpopejoy]

Re: Big Decimal Problem

Ok, I just tested this again...

When setting custom pricing in a contract, it does NOT allow you to use any more than two decimals. You can type them in, but they are truncated when the data is saved.

With a regular item, I see what you mean - and though it appears the the price has been truncated - when you click in the field, you can see the correct price. However, this is not the behavior for custom pricing - at least in my testing. Perhaps you could show me what I need to do differently!

Thanks,

Luke Popejoy

[Support Team]

Re: Big Decimal Problem

Hi Luke,

Thanks for the additional input. The custom pricing item price does save all the numbers after the decimal point. It just doesn't display it this way in the custom pricing window (it truncates it in the display, but the real number is saved in the database).

To see the full number when using a custom item, you should create a charge using this item for the account, so it will use the custom item. In the charge window, after selecting the item, you should use the TAB and go to the charge's Price field. Once the cursor is focused on this field, you will see the full price (e.g. 0.1678).

I hope you this clarifies this issue. I have logged your feedback to fix the custom items display (which truncates the number), but I assure you the real number is saved in the database.

Ethan

[lpopejoy]

Re: Big Decimal Problem

Ah! Now I understand what is happening. When I created the custom pricing, I would save it and then go back into the item to check. I would click "OK" after viewing the pricing which would save the truncated pricing to the DB. If you view the item after creation, you must click "Cancel" instead of "ok" to prevent saving the truncated pricing.

Thanks for your help!

Luke Popejoy

[Support Team]

Re: Big Decimal Problem

Hi Luke, yes, sounds like this may cause this behavior. Thanks for the update on this.

Ethan