Dynamics F/SCM Customer Experience (CRM) Dynamics GP Dynamics Business Central (NAV) Dynamics SL Power Platform Fabric Copilot

[Anne Kaese]

Hi there,
Has anyone used this extension from MS about increasing decimal places for prices, costs and/or units?

Extending decimal point precision for selected data types – Finance & Operations | Dynamics 365

Issues?  problems?  concerns?

thanks.

——————————
Anne Kaese

——————————

[Steve Latta]

We have. We needed to have decimal precision out to 4 decimal places for both quantity and costing/pricing. It works fine, but it is a pain in the butt visually, especially for our accounting users.

First, extending costing and pricing to 4 decimal places (at least the way our partner implemented it) extends to all financial numbers throughout the system. That means you are looking at 4 decimal places on your financial data as well. General ledger, trial balance, inventory value reports, invoice totals, etc. This pissed our CFO off to the point we are currently having specific reports modified so the financial columns only display 2 decimal places – extra cost for unintended customizations – even after knowing it was going to be throughout the system and signing off on it. At least with the Financial Reports, you can control the displayed decimal places, so our financial statements were unaffected.

Second, there’s no default way to force D365 to round GL postings to 2 decimal places across the board. So, when you go to 4 decimal places for pricing and costing, by default it will want to post GL transactions associated with inventory, sales and purchases to 4 decimal places. We definitely didn’t want that. The solution we found was to set the rounding on the USD currency to 2 decimal places for everything but prices. See screenshot from the currency setup:

That has worked and kept all of our GL postings properly rounded to 2 decimal places. The setup has to be done for each legal entity and currency you deal with, but once it’s done, you should be good to go.

My personal opinion is that looking at 4 decimal places everywhere is something you get used to doing fairly quickly. However, we found our older accountants generally refused to adapt and thus we’re having to do extra modifications to reports and screens they use most often to suit them. The obvious downside to this is that we’ll have a mix of 2 and 4 decimal places visible depending on where in the system the user is looking. 

The biggest issue is a human one. We had to increase decimal precision because people refused to do pricing and quantities per 100 or per 1000 instead of the per 1 they were used to, which would have allowed the system to use out-of-the-box conversions. Once we implemented the 4 decimal places, it was again people who refused to adapt to looking at 4 decimal places where they had been used to seeing 2, despite the fact all the financial transactions were rounding to whole cents.

——————————
Steve Latta
Accountant
Ortec, Inc.
Easley SC
——————————
——————————————-

[Kaare Boraas]

Hello Anne.  Just wanted to make you aware that there is a native solution for handling unit prices with >2 decimals.  See my blog post below.  It has it’s own challenges.  First it takes a while for users to understand and adopt.  In general they don’t like it and find it confusing. Also native reports don’t always look right and need modification to accommodate.

https://www.axug.com/blogs/kaare-boraas/2019/10/24/d365fo-how-to-manage-unit-prices-with-2-decimals?CommunityKey=af0dadbe-c222-4660-9d1e-a9e3416c837a

——————————
Kaare Boraas
Relationship Manager
PCL Constructors Inc.
Edmonton AB
——————————
——————————————-

[Zvika Rimalt]

just to mention that I tried to push back on that customization pretty hard, and suggested Kaare’s approach, but unfortunately our purchasing staff were not swayed.
They argued it would be too confusing to people recording purchase orders or comparing vendors’ invoices to the purchase orders in D365.

——————————
Zvika Rimalt
Functional Consultant
Vancouver BC
——————————
——————————————-

[Zvika Rimalt]

We have done that on my current project.

So far no issues, but we have not gone live yet.

We needed item pricing and item STD cost to be 4 decimal points, but nothing else.

Unlike what Steve describes here were managed to do it without having to change ALL accounting numbers everywhere to 4 decimal points.
Kind of probably telling you that not all Microsoft partners are created equally… hopefully it’s allowed to say that here.

Main challenge was to find the minimally intrusive way to do it.
We ended up modifying an extended data type, and it trickled to all the places we needed 4 decimal pricing
It also modified areas we did not necessarily want to change, but since we were not using those other functionalities it was not an issue for us – so when making a change to EDT it’s important to review all the places where it is being used.

** sorry, I sent you the same response as a personal message by mistake **

——————————
Zvika Rimalt
Functional Consultant
Vancouver BC
——————————

——————————
Zvika Rimalt
Functional Consultant
Vancouver BC
——————————
——————————————-