Dynamics 365 Business Central – Method and explanation to assist troubleshooting the message “The Posting Date is not within your range of allowed posting dates”

Introduction

When posting Purchase Invoices you can sometimes encounter the error “The Posting Date is not within your range of allowed posting dates” even though the Posting Date on the Invoice is within your allowed range.

In this post I’ll briefly explain a method you can use to find out which Posting Date the system is trying to post into and also why you are getting this message.

** Please note I’ve also written about this here but cover more things in this post 🙂

The Error

A common scenario is you are happily posting a Purchase Invoice that is matched to a Posted Purchase Receipt when you receive the error below:

The first thing to do is check if the Posting Date of the Purchase Invoice does indeed fall within your allowed posting range. You can check your allow posting date range via “User Setup” and compare this to the Posting Date on the document.

As you can see the Posting Date of the document (05/03/21) falls within my allowed posting dates (01/03/21 – 31/03/21) so what’s the issue? Why is the system saying this posting falls outside my allowed range?

The Troubleshooting Method

Before we try and understand why this is happening its a good idea to figure out which date the system is trying to post into. I do this by following the method below:

1) Blank out your posting range in the “User Setup”.

2) Rather than posting the document select to “Preview” the postings as per below. (if you did choose to post the document it would work so be sure to only Preview)

3) If you then drill down on the G/L Entries this will show you the Posting Date the system is trying to use which is outside of your range:

So, now we know the system is trying to post a portion of the GL entries to the date 20/02/21, which falls outside my range of Posting Dates, and this is why I’m receiving the error message. However, before we go changing our allowed posting dates and posting the document, let’s look into why the system is posting back to this date.

A Little background

Before we get into why this happens its useful to have some background on this example. In this example the Sales and Purchasing process followed the following steps:

1) The Item was purchase receipted at a cost of ÂŁ15.00 on the 10/02/21.

2) The Item was sold on a Sales Invoice on the 20/02/21.

3) The Purchase Receipt is being Purchase Invoiced on the 05/03/21 but the cost changed from ÂŁ15.00 to ÂŁ17.00 on the Item.

The key point here is point 3. The costs of the Item have changed from when they were purchase receipted (point 1) and subsequently sold (point 2). When this happens a key piece of functionality called “Adjust Costs – Item Entries” makes adjustment postings but more on that later.

Digging deeper

In Business Central when posting a Purchase Invoice that involves Items you are essentially creating two separate postings (registers). This is standard behaviour to support the “Automatic Cost Posting” feature. (more on that here)

One posting is for the purchases side of the transaction, which includes the Account Payable G/L code, and the other is for the Inventory. If you take a look at the G/L entries window you can see these defined in groups by the “Source Code”. The PURCHASES source code is the entries related to purchases such as the Account Payables G/L code and the INVPTCOST is for the Inventory postings.

In our example one of the INVPTCOST set of postings is causing an issue. For some reason this has been back dated to the 20/02/21. So why have these entries been created?

Adjust Costs – Item Entries

These entries have been created by the “Adjust Cost – Item Entries” batch job that runs when you post the Purchase Invoice (assuming you have “Automatic Cost Adjustment” set to Always).

As the costs have changed from ÂŁ15.00 on the Purchase Receipt (point 1) to ÂŁ17.00 on the Purchase Invoice (point 3) adjustments need to be made as the Item was sold at a cost of ÂŁ15.00 (point 2). Therefore the Cost of Goods Sold and Inventory postings need adjusting to the new Cost.

Choosing the Posting Date for the Adjustment

So why has the system selected the date of 20/02/21 for these postings?

The system determines the earliest date for Inventory adjustments based on the Allowed Posting Dates in the General Ledger Setup. (and also Inventory Periods if they are in use. You can read more about how the Posting Date is selected when Inventory Periods are involved via this Microsoft article.)

Therefore if we check our General Ledger Setup the Allowed Posting Dates are as follows:

In this configuration the earliest date we can post an adjustment is the 01/02/21.

In our scenario the Inventory we need to adjust on the Sales Invoice has a posting date of 20/02/21. Looking at our General Ledger Posting Setup we allow postings to this date so system creates adjustments with a posting date of 20/02/21 and as a consequence of this we receive the error “The Posting Date is not within your range of allowed posting dates” as our User Setup only allows postings between 01/03/12 and 31/03/21.

The Fix

Now we know why this is happening, and how the date is selected, we can choose to fix this by either adjusting our User Setup to allow posting in February or change the General Ledger Setup.

In my scenario I’ve changed the General Ledger Setup to only allow postings from 01/03/21 through to 31/03/21 which matches my User Setup. So now the earliest posting date that can be used for the Inventory Adjustment is 01/03/21.

If I now preview postings you can see the system will make the adjustment on the 01/03/21.

I will now be able to post this transaction as the Posting Dates on all entries are within my Allowed Posting Dates.

Conclusion

This error crops up a lot when people sell items prior to Purchase Invoicing them and costs change. Hopefully this article will help explain why this is happening and how you can troubleshoot it.

Thanks for reading!

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 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!