Dynamics 365 Business Central – Making sense of the Currency Exchange Rates Page when setting Exchange Rates

Introduction

Coming from a Dynamics GP background I initially found the exchange rate setup in Dynamics 365 Business Central a little confusing. In Dynamics GP you set an exchange rate, and then configure whether you wish the system to divide or multiple the foreign currency amount by that rate, to get the local currency amount, and that’s it.

However, in Dynamics 365 Business Central things are a little different. In this post I’ll walk through the key fields in the Currency Exchange Rates page to explain how you can set Exchange Rates in Dynamics 365 Business Central.

** This post only goes through setting Exchange Rates for Documents. It doesn’t touch on the Exchange Adjustment side of things.

Currency Setup

To access the “Currency Exchange Rate” page you must first go to the “Currencies” page, highlight the currency in question, and then drill down on the “Exchange Rate”. Alternatively from the “Currencies” page you can highlight the currency and click “Process > Exch. Rates” as per below.

This should then open the “Currency Exchange Rates” window which is shown below:

As I mentioned previously this window looks a little confusing to me? It appears there’s more than one place to enter a rate for the same currency? There’s also no option to specify if you wish to divide or multiply the currency at a given rate? (which is something I’m used to). So where do you enter the rate exactly?

Making sense of it all

I’ve found the key fields in this window are the “Exchange Rate Amount” and the “Relational Exch. Rate Amount”.

The “Exchange Rate Amount” is the rate to use for the “Currency Code” selected on the line, and the “Relational Exch. Rate Amount” relates to the rate to use for the “Relational Currency Code”. (generally its left blank so its the local currency – see further below for an example where this isn’t the case)

This can be further explained in the image below

Therefore using the Currency Exchange Rates window shown above, as we have 1.0 in the Relational Exch. Rate Amount (GBP) and 1.3 in the Exchange Rate Amount (EUR) this means 1.3 Euros is equal to 1 GBP. (The “Exchange Rate Amount” is acting as the exchange rate)

Hence entering a transaction for €200.00 would equate to £153.85 (i.e. 200 / 1.3 = 153.85)

I could also flip this by entering 1.0 in the “Exchange Rate Amount” and 0.76923 in the “Relational Exch. Rate Amount” as per below:

This now means the “Relational Exch. Rate Amount” is acting as the Exchange Rate.

In this example €1 (Exchange Rate Amount) is equal to £0.76923 (Relational Exch. Rate Amount). Therefore entering a transaction for €200.00 would also equate to £153.85 (i.e. 200 * 0.76923)

Both would work exactly the same its just a slightly different configuration.

** I would tend to use the divide method as the rates make more sense in this scenario.

Bonus – Adding a Relational Currency Code

I’ve never come across a situation where the “Relational Currency Code” is anything other than blank (i.e. the local currency) however now we know how the relationships work let’s test this out.

I’ve therefore changed the Currency Exchange Rates page for EUR to include USD as the Relational Currency Code as per below

And the USD rate is below:

Therefore if I were to raise a €200 Invoice the GBP will be calculated as follows:

Step 1 Euros to USD :- €200 / 1.3 = $153.8462

Step 2 USD to GBP :- $153.8462 / 1.39 = £110.68

To confirm I added an Invoice in Business Central and below is the statistics page confirming our calculations

Conclusion

Although confusing at first (at least to me) understanding how the Exchange Rates are picked up and used is fairly straight forward. Its also flexible offering various options for how to calculate exchange rates.

Thanks for reading!

Dynamics GP – 10 tips when running a General Ledger Year End on a large SQL Database

Introduction

A few weeks ago I assisted with a General Ledger year end for a GP user with a very large number of journals and consequently a very large SQL database.

Usually a year end is a fairly straight forward routine, however as this user has such a large database, along with additional SQL bits and pieces for disaster recovery and bespoke reporting, it required a little more thought to ensure things went as smoothly as possible.

In this post I thought I’d share the steps I took to hopefully assist anyone else facing a similar situation in the future.

Here goes…..

1) Do the basics first.

By basics I mean following Microsoft’s general Year End prerequisites which can be found here.

I find the most important steps are ensuring you have a good backup and also ensuring the general ledger codes have the correct posting type as this can be a pain to correct post year end.

2) Ensure you have enough disk space for the SQL Data and SQL Log files.

This usually isn’t a consideration when running the Year End however given the size of the data its something that needs planning when dealing with GL tables in the 100’s of GBs.

Microsoft’s official guidance on disk space is included in the Year End documentation that I’ve linked to above however I’ve copied the section on disk space below:

During the year-end closing routine, all the records that will be moved are put in a temporary table before they are moved to the GL30000 table. You must have free disk space that is equal to the size of the GL20000 table to perform the routine.

To find the current size of the GL20000 you can use the sp_spaceused system stored procedure i.e.

However I’d also add that when dealing with large data volumes you also need to plan for extraordinary SQL transaction log growth as well.

For example the SQL transaction log grew to 240GB when I did this particular year end. This is because various statements including the INSERT statements into GL30000 are completed in one SQL transaction. Therefore no matter what the SQL recovery model is of your database, the log file is going to grow while the process completes. This is standard behaviour so SQL can roll the whole transaction back should any issue occur.

3) Remove any Database Mirroring or Availability Groups.

In my scenario the user has database mirroring for disaster recovery. I could have left this on however this would result in a lot of transaction log being sent over the wire while the Year End ran potentially doubling the length time it takes. I always see the amount of time something takes, as the size of the window of opportunity for something to go wrong. The quicker I could get the Year End process to go, the less chance I had of something going wrong. On the down side it does mean I had additional configuration to complete post year end, but I was fine with this.

4) Remove any custom indexes

If you have any additional custom indexes on GL20000 and GL30000 its best to remove them. Again its not a problem if you don’t remove them, however it can slow things down and also increase the amount of transaction log that SQL will produce. This is because if you are DELETEing and INSERTing data into tables the indexes also have to be updated. Therefore the less indexes you have the better. This requires additional space and also additional log to record the operations.

**Don’t remove any of the standard indexes though.

5) Stop the SQL Agent.

Maintenance tasks like reindex routines sometimes use the SQL agent to run. As I suspected the Year End will run for a very long time, I stopped the SQL agent to prevent this from happening. Its always best to check that critical operations won’t be affected by this though. If so just disable any SQL jobs that run maintenance on the Dynamics databases.

6) Temporarily revoke permissions for any Reporting Logins.

Ideally I’d like to set the database to single user mode while the Year End ran however as I wanted to monitor the process I didn’t want to restrict this too much. I therefore disable logins that I knew were used for reporting in case anyone sets off a large report in the middle of the year end.

7) Ensure SQL log growth on the database is set sensibly.

As I mentioned above the SQL transaction log is going to grow during this operation regardless of the recovery model. Therefore go to the properties of the SQL database and ensure the growth is set correctly, and its set in MB’s rather than a percent. I set it to grow 10GB increments for this particular year end process.

8) Use SQL monitoring scripts

I like to nosy under the hood when running most things but I especially want a sneak peak on the General Ledger Year End. My tool of choice for this is Adam Machanic’s awesome free monitoring tool sp_whoisative. This is a free script you can use to monitor activity in SQL. Using this I can pretty much see at what point the Year End was up to. i.e. INSERTing the data to GL30000 etc.

**If you didn’t know about this free script, and this is all you take away from this blog I’d be happy :). Its a really cool free tool you can use when troubleshooting all sorts of things in SQL i.e. blocking etc.

I also want to monitor my database and log growth as the process is running. If I monitor this I can predict when the log will run out of space and need to grow. I then check the disk space to ensure the growth will happen smoothly. To do this I use this script

SELECT DB_NAME() AS DbName, 
name AS FileName, 
size/128.0 AS CurrentSizeMB, 
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS FreeSpaceMB 
FROM sys.database_files; 

9) Be patient 🙂

One of the most important things is to be patient as this routine can last hours on a large data set. Its also important to never cancel the operation by manually closing GP down even if it says “Not Responding”. If it doubt you can run the sp_whoisactive stored procedure and check what’s happening on the server.

10) Once complete

After a huge sigh of relief I performed an additional backup and then started recreating the indexes, setting up the mirroring and restarting the SQL agent. I also shrank the SQL transaction log back down to a reasonable size.

Conclusion

I hope you find the information in this post useful. Although you may not need to follow all the points I outlined, I think the most important are disk space for the SQL transaction log, monitoring and lots of patience 🙂

Thanks for reading!

Dynamics 365 Business Central – A closer look at Journals and Documents

Introduction

Ever wondered why you have options to post to Vendors in a Sales Journal and Customers in a Purchase Journal? What do Documents and Journals have in common? How are Ledger entries and GL register created?

In this post I’ll explain more about Financial Journals and Documents and hopefully unlock some of their secrets along the way.

**Please note there are other journals such as Item Journals for inventory management which I wont cover in this post)

Journals

Journals are scattered throughout Dynamics 365 Business Central and can be used to record a whole manner of transactions. The most commonly used financial journals would be General Journals, Sales Journals, Purchase Journals, Cash Receipt Journals and Payment Journals.

Interestingly, under the hood all the journals are pretty much the same. All the journal pages are based on the Gen. Journal Line (81) table and all journals use the same Gen. Journal posting routine (codeunit) to create the relevant Ledger Entries and G/L Register.

As you can see from the image below although the General Journal and Sales Journal use different pages they are based on the same table.

The difference between the journals only really exists on their Pages and the actions and options available on those Pages.

For example the Payment Journal page has an action to run the “Suggested Payment Routine”, which is relevant to paying suppliers, and the other journals also have different actions. However, as they are all technically the same, nothing stops me creating a Payables Payment transaction in a Sales Journal and getting the correct Ledger Entries.

For instance, as you can see below although I’m in a Sales Journal I can still choose an Account Type of “Vendor”.

When you post the journal the relevant Ledger Entries and G/L Register are created and the journal lines are removed. (some exceptions exist like for recurring journals).

Therefore, taking all this into consideration, we could technically just use the “General Journal” page to record all of our financial transactions in Business Central, whether they be Sales or Purchase entries. We can also use one journal to record a whole host of different types of transaction. (as I show in this post)

Documents – Overview

When we refer to documents in Dynamics 365 Business Central we are referring to things like Sales Invoices and Purchase Invoices. (there are of course others such as Sales Orders, Sales Shipments, Purchase Orders, and Purchase Receipts)

They will have a Header and Lines, with the Header typically containing information on the Customer or Supplier and various dates, and the lines containing information or what you are selling or buying, for example items or GL codes.

When you post an Invoice, postings routines are ran to create the Ledger Entries and G/L Registers and new Posted Documents are created and the unposted document is removed. (you can archive Sales Orders using the archiving options in Setup)

For example if I were to Post a Sales Order via the “Ship and Invoice” option a Posted Sales Shipment and Posted Sales Invoice would be created along with financial Ledger Entries such as General Ledger and Customer Ledger Entries.

Documents – Posting

So what do Documents and Journals have in common? What makes them technically the same when it comes to the creation of the Ledger Entries and GL Registers?

As mentioned above when you post a Document the system runs posting routines to create the relevant ledger entries and it turns out these are the exact same posting routines that run when you are posting a journal (whether that be a General Journal, Payment Journal etc).

The posting routine responsible for this is “Codeunit 12, Gen. Jnl.-Post Line”. This is responsible for creating all the Financial Ledger Entries and G/L Register regardless of whether you are posting a journal or a document.

Therefore when you post a document its converted into journal lines, the lines then validated, and finally its posted in the same way as a journal.

Conclusion

The Gen. Journal Line table and Gen. Jnl.-Post Line codeunit do feel like the heart of Dynamics 365 Business Central. (certainly the financial heart)

I hope this article helped explain some of the concepts around journals that I found confusing when I started out with Business Central.

Thanks for reading!