I’m having a problem with a Crystal Report calculating order values. The report is exaggerating unit prices by 10x for every extra decimal place in the unit price of the item, as defined in the alternate price list item. So for an item that has 4 decimal places in it’s price, the Crystal Report will show a price of $1845.00 each, when it’s actually $18.4500.

Unfortunately I cannot just take the total order value / number of units ordered, as I’m interested in knowing the order value for orders that were already invoiced. When an invoice is closed the order value of course goes to $0.

Also, I tried doing an if formula that referenced the # of decimal places in the alternate price list item. This didn't work, as Crystal wouldn't let me link the Orders and Invoice database to the Alternate Price List database with the required info.

I know Adagio has issues with always assuming that the decimal place is 2 places away from the right. Is there a ‘turn off implied decimal place’ or something like that?

I was hoping there is someone out there that has solved this problem before.

Alternatively, it would work if I could find away to generate total original order value.

Thanks!

Hi Acrylon,

There is a field on the Sales Order Details record table called 'Unit Decimals' - near the end of the list - that stores the number of decimals of the unit price. Note that this is not used for the Extended Order Price or Extended Invoice Price fields, because these values are stored with the current number of decimals, which is probably 2 for you.

What you would have to do is create a formula that re-calculates the original order price by calculating the qty originally ordered times the unit price, and 'convert' the unit price using the Unit Decimals field. Essentially, all unit prices have to be divided by 100 for those that use 4 decimals, which is 10 ^ 2 (10 to the power of 2), or 10 ^ (4-2). More generally, the formula would be something like:
{Unit Price} * 10 ^ (2-{Unit Decimals})
which will multiply the unit price by 0.01 for those that use 4 decimals, and by 1.0 for those that use 2 decimals.

I don't agree with your statement that Adagio has issues with assuming 2 decimal places, but rather the program stores most currency values in the number of decimal places as the currency, which for most everybody in North America will be 2 decimals.