Unable to get correct Extended Price on Sales Transactions

(0) Share

Report

Posted on by Community Member

I am having difficulty getting Sales Transactions extended price to calculate correctly for bulk sales where the unit price exceeds the decimal places for that item.

Qty	Unit Price	Extended Price
30	3.33	100.00

For example, if we sell something in bulk which has a real recurring Unit Price of $3.33333, you get a total of $99.90 if you enter the QTY and then the Unit Price. You can get around this by entering the QTY and then the Extended Price, and it will save and remain as $100.00 but back calculate the Unit Price to 2 decimal places.

When you transfer to FO or BO, it seems to only bring across the Qty and Unit Price, and recalculate the Extended Price back to $99.90. There seems no way to make the $100 carry across.

Is there any way to resolve this issue? The same issue exists on the purchase module however this isn't such a big deal for us.

Thanks

*This post is locked for comments

I have the same question (0)

All responses (3)

Answers (0)

Rosemary 10 on at

Like (0)

Report
Copy link

Link copied!

Hi Tania,

I just tested this in SOP, an item quantity of 30 at 3.33 and I got 99.90. Our decimal positions for currency is 2, we do not use multi currency. In either of the scenario described I got 99.90.

The system calculated the extended price, is it you are entering 100.00? If I enter 100.00 the unit price remains the same, 3.33. The FO did convert to SOP with the respective price.

I am not sure I understand what 'real recurring unit price' is?

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
Copy link

Link copied!

At Order level, I am entering the Extended Price of $100.00. When I transfer this to FO or BO, it brings across to the next document only the QTY of 3 and Unit Price of $3.33 and recalculates the Extended Price to $99.90. I save it, close, query the previous order I entered, and the order Extended Price is still $100.00. But the FO or BO results are $99.90.

By real Unit Price, I mean it is a value that has several decimal places, such as $3.33 recurring, but it only stores 2 decimal places and bring that across to the next document which is used to calculate an incorrect Extended Price.

I have tested this many times. Please try from Order level first.

Was this reply helpful? Yes No
Suggested answer

L Vail 65,271 on at

Like (0)

Report
Copy link

Link copied!

Hi,

This is a blog post I did addressing the need to go beyond 5 decimals:

How can you get Dynamics GP to calculate a unit price using more than five decimals?

Multicurrency to the rescue!

Since Multicurrency uses more precision when doing the translation, you can set up a new currency that will use many more decimals. Here’s how it went.

The problem:

The actual unit price of an item was $0.00491256. The system could only use the first five decimals, so they ended up with a price of .00491. If they were to sell 10,000 of these, the extended price would be $49.10 instead of the correct price of $49.13. Sure, GP can easily dispense with that extra 3 cents, but it’s a pain.

A solution:

Create a new currency (I’ll call it $NEW) with an exchange rate of .000001 set to multiply. Enter the sale using the $NEW currency. When the currency is translated into the functional currency, the desired value of $0.00491256 is used as the unit price.

When entering the transaction using the $NEW currency, you would use a unit price is $4,912.56. When the price is translated into USD, you end up with this: $4,912.56 * .000001 = .00491256. Problem solved.

Just as an aside, changing the unit of measure schedule was not a viable alternative in this case.

Kind regards,

Leslie

Was this reply helpful? Yes No