How can i change the number of decimal places to three for Price and Quantity

(0) Share

Report

Posted on by Community Member

Hi All,

One of our clients wanted higher precision on their quantity and pricing. Currently in Ax it is rounding off after two digits we wanted to move to 3 decimal places. This is important for the client because they deal with copper in tonnes, so an accuracy level of two digits could mean they will loose copper in Kg's.

Also similarly for the price a accuracy of 3 decimal places will give my client a better profit.

I did look around for existing options..but there wasn't any clear direction.

1. Changing the regional settings will affect the number of decimals.

Yes but it's effect is limited. The date format, currency grouping and separators come from the regional settings but not the number of decimal places. This is not true completely because i can see the fields that Extend amountMST are having decimal places based on the regional settings.

If you look at the RealBase EDT, it says "Auto" for number of decimals where is the value for this AUTO picked up from ?

2. Is it ok to change the realbase edt to have the required number of decimals ? Does this have any impact on the business logic ?

So i'm not sure what is the approach to take here. I hope this is a very common scenario in implementations. What is the general approach here ? any body has done this before ?

Thanks in advance for help.

Regards

Kamal

*This post is locked for comments

I have the same question (0)

All responses (22)

Answers (0)

Evaldas 1,800 on at

Like (0)

Report

Take a look at Unit table's field UnitDecimals. It could help you with quantities.

Unfortunately, I know nothing about pricing precision.

Was this reply helpful? Yes No
Suggested answer

DG 1,226 on at

Like (0)

Report

Hi Kamal,

The property 'number of decimal' only dictates the number of decimals to show in fields in the AX UI and not how it is saved in DB.

The AX internally saves all real values with 15 decimal places precision. After that, it rounds off. Option 2 looks better. If you don't want to do it across AX real fields, then change the property only in their respective base EDTs and not realbase.

Regards,

Deepak

Was this reply helpful? Yes No
Fabricio Noriega 110 on at

Like (0)

Report

I agree with Deepak. After you have changed the EDT just do some validation tests. In theory this should work.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi Deepak,

Thanks for your inputs.

Though Ax stores 15 decimal places, it stores only the rounded value. The client is not bothered about what it displays but what it uses to calculate. So the problem would still continue to exist. But if you change the edt this doesn't happen it starts rounding based on the EDT decimal value.

@Evaldas: it doesn't help until you increase the number of decimals.

Thanks again.

/Kamal

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi Fabricio,

I saw a similar thread of yours, but did you use regional settings or EDT to solve the problem ?

Thanks

/Kamal

Was this reply helpful? Yes No
Fabricio Noriega 110 on at

Like (0)

Report

You need to change the EDT.

Was this reply helpful? Yes No
Denis Patrakov on at

Like (1)

Report

[quote user="casperkamal"]
One of our clients wanted higher precision on their quantity and pricing. Currently in Ax it is rounding off after two digits we wanted to move to 3 decimal places. This is important for the client because they deal with copper in tonnes, so an accuracy level of two digits could mean they will loose copper in Kg's.

Also similarly for the price a accuracy of 3 decimal places will give my client a better profit.
[/quote]

You should not change EDTs or something like that. Yes, AX uses two digits precision by default and you should get used to it. As to prices and amounts, there are just too many places in the AX application where an amount is rounded to two digits (especially in the financial module) that you just can't do anything with it. In case your customer wants to deal with copper in tonnes with a kg precision he sould use kg at least as a storage unit for copper. A storage unit for an inventory item should always be the least possible unit in which an item can be measured with at most a two digits precision. To set a price agreement for a tonne with a "three digits precision" you should use PriceUnit greater then 1, f.e. set a price of $50000,45 for a tonne with the PriceUnit of 10 - this will give you an actual price of $5000,045 for a tonne. See also Setting up item price to accept more than two decimal places.

Note also that you can't just go and change an inventory item storage unit. AX stores quantity in all inventory transactions in the storage unit and it does not store the unitId itself! So if you have a copper measured in tonnes and have a transaction with a qty of 10 (tonnes) then in case you change the copper's stoage unit to kgs the transaction will become interpreted as with a qty of 10 kgs. So in case you deside to change an item's storage unit you should create another item with the storage unit you need, block the first item and use the second item ever after. You can also setup the second item as an alternative item for the first one and you should use loss & profit and count journals to "pass" the stock from one item to another.

Once again: you just can't make AX to use a precision of more then two digits throughout the application, there are other means to accomplish your task.

Was this reply helpful? Yes No
DG 1,226 on at

Like (0)

Report

@gl00mie

Hi...this sounds like contradicting to base statement made by the ERP. The AX solution is NOT meant to preach how the business should be done. The ERP should be customized according to the way business is done.

Here the business is working with measuring copper in tonnes but AX will be preaching it to work with KGs instead because there is no way we can customize the package!

Was this reply helpful? Yes No
Suggested answer

DG 1,226 on at

Like (0)

Report

Hi Kamal...sry i came to the thread after a few days. I read the contents above and did some research.

AX documentation about the field property 'NumberOfDecimals' is correct, it is just the display property. But there is some rounding off feature which is written in AX UI kernel code. If the display property is set to 2 decimal places and the user enter 3.222, it automatically rounds off the value to 3.22 not only in UI but also in the value stored in DB.

Changing the property of base EDT or the quantity related EDT can also have far reaching effect (as told by gl00mie above). You can try the following work-around solution.

1. Create a new EDT which extends related quantity EDT. Set the 'number of decimals' property to 3.

2. Add this EDT as a field in the table OR create an edit method (using new EDT) in the table which can take three decimal value from UI and then store it in the actual quantity related field by code. This way database will be updated with correct precision value.

Was this reply helpful? Yes No
Denis Patrakov on at

Like (1)

Report

[quote user="DG"]The AX solution is NOT meant to preach how the business should be done. The ERP should be customized according to the way business is done.[/quote]Tell it to SAP consultants ;-)

[quote user="DG"]Here the business is working with measuring copper in tonnes but AX will be preaching it to work with KGs instead because there is no way we can customize the package![/quote]There are some AX implementation best practices (as well as for any other product or technology). «Best practices tend to be built on the proper use of the technology, taking into account what the technology does, what it does not do, and what it was intended to do.» You can buy copper in tonnes and you can sell it in tonnes, too, but when it comes to inventory there's a best practice to use a unit that is small enough to allow quantity to be measured with no more then two digits precision. You can setup purchase/sales order quantity multiplicity, you can setup price agreements with a price unit of 10 or 1000 and thus effectively set a price with 3 or 5 digits precision. Yet when it comes to AX internal calculations it's better to follow best practices and just... to use a unit that is small enough. AX is also not intended to deal with amounts with more then two digits precision although you can use a nonexisting currency code with a fixed exchange rate of a 10000 for USD - that will allow you to operate with amounts rounded to $0.0001 instead of $0.01 (in AX a currency exchange rate is set for 100 "units" of a currency).

[quote user="DG"]1. Create a new EDT which extends related quantity EDT. Set the 'number of decimals' property to 3.

2. Add this EDT as a field in the table OR create an edit method (using new EDT) in the table which can take three decimal value from UI[/quote]3. Modify hundreds of table fields, forms, report designs, classes that use other EDTs for quantity and are in one way or another related to sales orders, inventory journals/inquiries/reports, master planning, etc.

You can abuse AX and force it to do something it's not intended to but in case you succeed the TCO of your AX implementation will most likely skyrocket. On the other hand there are standard ways to solve tasks like this without any customizations.

Was this reply helpful? Yes No