How to have 3 decimal places for Unit Price in Purchase Order line details? If possible, what impact will it have on the overall process Specially financials.
Would appreciate a quick response.
What does Microsoft says about it?
*This post is locked for comments
The far bigger problem arises when you have a strong base currency -e.g. Oman where the GL needs to post to 3 significant decimal places,
This is a challenge because the 2 dec logic- is in the kernel classes in p code and is company wide - even if you try to code this company journals are another headache, bank accounts need to be reconciled to 3 places etc.
If you manage to change it then how many form and report fields sizes are affected?
Microsoft has been struggling with this for years and a resolution is not yet on the horizon
Hi Abubaker
This inventory model is working correctly with roundings.
In a purchase transaction you can have e.g. 3 items for a total cost of $ 10. The items a sold one by one. Then AX will reduce based on an average cost price. This is initial rounded 3.33, but becomes 3.34 for the second item. The third item is costing 3.33 again. Due to A internal (re)calculations the order might be different, so e.g. the third can have the 3.34 cost value.
Hi Andre Arnaud,
We are using Weighted average.
I agree with the others - the price should be setup per e.g 100 or 1000.
Eg. on the Po-line it may be custom to think of the "Unit Price" per 1, but actually it's per the quantity stated in field "Price unit" in tabpage "Price and discount" (where it is often 1).
But it is possible to setup purchase prices per e..g 1000 rather than 1. Both in Price agreements and on po-lines. E.g. a Price of 12,23 per 1000 will give a "per 1" Price of 0,01223.
Hi Abubaker,
The cost and rounding should be managed correctly by AX. I have not seen issues before when you are using prices with a unit of 100.
What inventory costing model are you using?
Thank you. How would I match my total value of PO if I use 2 decimal places instead of 3 because purchase quantity is not in our hands. Small difference in cost will result in major change in the overall cost. A point difference will create a bigger overall impact.
Any alternative to adjust PO value if changing decimal is not recommended.
I agree with André: Ax shows the number of decimals bases on the property of the EDT, but sometimes stores the value more precise in the DB. As you can image, it's a matter of time before postings do no longer balance and/or rounding issues occur.
If you wish to read more on the noOfDecimals property, check sjakalax.blogspot.be/.../noofdecimals-property.html.
And you might also want to check this thread : community.dynamics.com/.../76024.aspx
When you increase it for some parts, still some rounding will be done on 3 decimals and will post it with 3 decimals in the ledger. It looks like the system has 2 decimals for accounting entries, but in the database it will be 3 then. This can cause serious issues when performing the year end closing and create opening transactions.
So agree with Tom and Rik. Don't modify AX, but use the workaround described by Tom. This is how it is implemented at more customers. If you need to display 3 digits on e.g. the order and invoice document, you can customize it to have it presented only on those document. Also on the forms you can create an edit method to display 3 digits, but in the database it will store the prices per 10 or 100.
Microsoft does not say much about this. If you customize it, you can't blame them. They do not support your customizations, only the basic application.
I tried modifieing the EDT in AX 2009 giving it more decimal places. Caused breakage througout the application.
Attempted it another time in AX 2012. The system is a little more robust because most EDT's are related. However because of this you might see unexpected beheviour in other places. It worked but I decided it was too risky for a PRD enviroment.
Summary, I would not attempt unless you got enough time to thoroughly test your modifications.
Hi,
You could just increase the number of decimals on the EDT, but I wouldn't go there.
Rather use the possibility to define a price per 10 or 100 pcs for example.
This will give implicitly more decimals in price calculation.
100 pcs cost 12,23€ > so 1 pcs costs 0,1234€, but Ax would ony show 0,12
If you'd order 100 pcs, the unit price would still be 0,12, but the total price should be 12,23 nevertheless.
I believe it should work like that (but didn't tested this out while writing this).
bye
Tom
André Arnaud de Cal...
292,160
Super User 2025 Season 1
Martin Dráb
230,962
Most Valuable Professional
nmaenpaa
101,156