This is another post in my #TipTuesday series. Today’s topic is a commentary on currency IDs as well as a tip on currency symbols.
I doubt everyone will agree with my thoughts on the items below as there are different approaches to configuring Dynamics GP. I think this also has elements of an “it depends” situation whether it makes sense for your organization or not. In any case, here is my take on currency setup & symbols and a couple of my tips I follow when configuring currencies.
When Dynamics GP is installed, if Fabrikam (aka the Sample Company) is created, there are default currencies in the system, with IDs prefixed with Z-. If Fabrikam isn’t installed, these currencies will not appear.
Here’s the list in GP 2018 in my environment (I have Fabrikam but no other additional “real” companies created):
These Currency IDs, in my humble opinion, are intended for the sample company only and were never intended for companies to use for real in day-to-day business in a production company. If a company is just implementing Dynamics GP for the first time, new currencies should be created, even if you aren’t using multicurrency and have no plans to.
Over the years I’ve seen some environments where the reseller or customer didn’t create new currency IDs and they use the Z- currencies in production companies and it’s just plain weird in my opinion. Fortunately, most of my implementation experience I would say this wasn’t the case.
When the ISO field was introduced to the currency setup window, the sample data was updated to include the ISO codes. I believe I remember an issue (possibly eConnect?) that required ISO codes be unique, one per currency. If I have no choice, and the Z- currencies already exist, I would change the ISO codes on those to be “not real” if I also have new currency IDs set up for some of those. That way, in a production environment, the “real” ISO codes are also real currency IDs in use in the companies I have configured. While there may be multiple currencies configured in Dynamics GP, only the specific currencies assigned to a given company can be used for transactions in that company.
Where I was really intending to go with this post is to recommend the use of an alpha identifier with the symbol on currencies where they share the same symbol, like a dollar sign.
In my last post, I gave an example of why changing the view on transaction entry to Originating was a good idea. One of the things I pointed out when I flipped the view to Originating was that my Canadian dollar transaction visually was obvious because the symbol was C$, not just a dollar sign. I knew instantly I was entering in the correct currency. If the USD currency had a symbol of U$, it would have also been obvious that I was entering in the wrong currency in that example.
In Currency Setup, the symbol can be more than just 1 character and I encourage customers to take advantage of that. If the company does a lot of transactions in multiple currencies, it would be useful to have a visual identifier on every transaction to identify the currency. If the company rarely transacts in other currencies, I am less inclined to configure it this way, for some of the reasons identified below.
There are cons to this approach, most notably that every single report has oddball currency symbols on them and at times the windows or reports get cluttered looking. Long term, I think if you deal with enough currencies, the pros outweigh this and the savings in fewer mistakes will compensate for the “ugly” reports. (Plus, reports can be modified to handle it better if needed).