As I learn and familiarise myself with Dynamics 365 Business Central I often post something in Dynamics GP and then wonder how this same task could be achieved in Dynamics 365 Business Central.
Today’s pondering was looking for the equivalent to the “Payables Transaction Entry” window that we have in Dynamics GP.
I know you can post to G/L accounts via the “Purchase Invoice” page in Dynamics 365 Business Central but to me this is primarily a “Purchase Order Processing” type window. I wanted to post a sundry payables invoice, onto a vendor, to multiple GL codes, without the need to touch the “Purchase Invoice” window.
As usual there is more than one way to do this however I focus on the “Purchase Journal” page. I also elude to why I think you can achieve the same using other “journal” pages, although you might not necessarily want to use those anyway 🙂
Dynamics GP – Payables Transaction Entry
In Dynamics GP you can post a sundry payables invoice in a very straight forward and easy to understand window called “Payables Transaction Entry”.
This window has no link to Purchase Order Processing. We tend to advise users to use this window for posting invoices for sundry items and things you wouldn’t necessarily have a Purchase Order for. You can click “Distributions” and record multiple GL codes for this one invoice. Its also handy to import transactions into very quickly and users seem to prefer this window for speed of entry.
Dynamics 365 Business Central – Purchase Journal
There are various “journal” pages in Dynamics 365 Business Central so I turned to the “Purchase Journal” page to achieve my goal.
The first thing I found I had to select was the option “Show more columns” as per below.
Crucially this adds the “Account Type” option which gives the user the ability to add “G/L Account” when keying in the Payables document:
Now I had the “Account Type” field available for entry I found as long as you keep the Document Number, External Document No and Posting Date the same you are able to add a payables document with multiple lines.
First you add the “Account Type” of “Vendor” and key in the first line with the total amount of the document. On the subsequent lines you can choose “G/L Account” as the account type and enter the G/L distribution breakdown. Also, if you wish to analyse tax to any of the distributions you must populate the “Gen. Posting Type” with “Purchases” and then populate the “VAT Prod. Posting Group”.
In the end you should have something like this and the document will post successfully
As with any investigation you usually find some interesting things along the way.
The major takeaway I found is that you can post the same purchase invoice using the “General Journal” page. After looking more closely it seems this is possible as both pages are based on the “Gen. Journal Line” table. Therefore all the fields (and business logic) you need are available on the “General Journal” page as well.
See below. The “Purchase Journal” and “General Journal” pages are based on the same table:
However, as a word of caution, if you were to post the same purchase invoice from the “General Journal” page the transaction is given a “Source Document” of “GENJNL” in the “G/L Register” rather than “PURCHJNL”.
See below. The top G/L Register was posted using the “General Journal” page and the other using the “Purchase Journal” page.
Therefore I’d suspect its best to use the specific “Purchase Journal” for these postings.
You receive the message “The Posting Date is not within your range of allowed posting dates” when trying to post a Purchase Invoice in Business Central.
According to the user setup the “Posting Date” of the document I’m posting is within the allowed posting range so why won’t the system allow me to post it?
Background – Value Entries
To provide a little more detail I’m trying to post a Purchase Invoice that I’ve matched to a Posted Purchase Receipt and I’ve increased the Unit Cost on the Purchase Invoice as the price has changed since the goods were received. I’ve also sold the items on a Sales Invoice before I’ve tried posting the Purchase Invoice.
Therefore, if we look at the value entries of this item prior to attempting to post the Purchase Invoice they are as follows
We have a value entry for the Posted Purchase Receipt showing a date of 12/05/2017 and a “Cost Amount (Expected)” of £10.00 (this the amount I used when posting the Purchase Receipt)
We also have a value entry for the Sales Invoice showing a Posting date of 25/05/2017 and a “Cost Amount (Expected)” of £10.00.
Details of the Purchase Invoice
The Purchase Invoice I’m posting is dated 01/06/2017 and I’ve amended the Unit Cost from the original £10.00 that pulled through from the Posted Purchase Receipt to £12.00
Now when I try and post this transaction, I receive the message
Therefore, just to confirm the Posting Date of the Purchase Invoice is within my allowed posting dates below is a screen shot of the User Setup window showing my Allow Posting Dates
The dates are also within the General Ledger allowed posting dates as shown below
Therefore, at first glance its not apparent why the system isn’t allowing me to post this document? The Purchase Invoice posting date is 01/06/17 and this is within my range of allowed posting dates?
The Issue – Automatic Cost Adjustment and Adjust Cost Item Entries
When posting the Purchase Invoice, the system has detected that the cost has changed from the Posted Purchase Receipt, and as this has been sold on a Sales Invoice, the cost of goods sold need adjusting.
The system therefore tries to post an adjustment using the Posting Date of the entry its adjusting (in this case the Sale Entry on the 25/05/17), which is in May, and as this falls outside of my posting range I receive the error “The Posting Date is not within your range of allowed Posting Dates”.
** Its also worth noting I’m getting this message when posting the Purchase Invoice because the option “Automatic Cost Adjustment” is set to “Always” in Inventory Setup. This means the system checks for cost adjustments when you post the transaction. If this wasn’t set to “Always”, then depending on its setting its possible the document would post however when the “Adjust Cost Item Entries” batch job was subsequently run the error would occur.
See below for my Inventory Setup
There are two possible solutions to my issue here. The first is to change my “Allowed Posting Dates” in the “User Setup” to 25/05/2017 through to 30/06/2017. This will then include the posting date of the entry that will be adjusted.
Alternatively, I could change the “Allowed Posting Dates” in the General Ledger Setup to 01/06/2017 through to 30/06/2017. Then, as per the article I linked to, the system would use the date of 01/06/2017 for the adjustment entries, (i.e. the first open date in the General Ledger Setup) which does fall in my allowed periods to post to.
Therefore I’ll change my “Allowed Posting Dates” in the User Setup as per below
And now when I post the Purchase Invoice this is succecssful
If I now view the Value Entries you can see the adjustment entry created with a Posting Date of 25/05/17.
Although this is a simple example it shows why you may encounter this error when it seems the postings date configuration on the User Setup should allow a document to post.
Within Dynamics NAV \ Business Central you can switch Expected Cost Posting to G/L both ON and OFF via the option below in Inventory Setup.
In this post I’ve been playing with this feature to see how things work and how the various postings differ to Dynamics GP. I also take a look at how the Value Entries in Inventory play a pivotal role in this. I end by taking a closer look at the SQL tables involved and how things fit together.
Expected Costs in Dynamics GP
When you receive goods via a Shipment transaction in Dynamics GP a Purchase Accrual is automatically created to a General Ledger accrual account to record the expected cost in the General Ledger. This account is generally taken from the Creditor Card as per below:
opposite debit entry is taken from the Inventory Item card as per below:
Let’s add a Purchase Order Shipment transaction in Dynamics GP and see this in action:
As you can
see from the screen shot above, I’m receiving one Inventory item, and this has
created an accrual distribution crediting the 000-2111-00 accrued purchases
account I specified on the creditor card. The balancing debit side is to the
Inventory code that we specified on the Inventory Item card.
see what happens when we invoice the Shipment:
Just as expected the accrual is reversed via a Debit entry to the 000-2111-00 accrued purchases account and the accounts payable is credited. Therefore, the balance in the accrual account is now nil.
There’s no way to disable this behaviour in Dynamics GP. When you post a “Shipment” for some Inventory Items General Ledger entries are always created. (however you can prevent the entries posting through to the General Ledger via the Posting Setup)
Expected Costs in Dynamics NAV \ Business Central
Before we look at Expected Costing in Dynamics NAV \ Business Central we first have to take a step back and look at the various inventory entries that are created when you post inventory transactions.
When you post an inventory transaction in Dynamics NAV \ Business Central the system creates a minimum of two inventory entries: an Item Ledger Entry and a Value Entry. The Item Ledger Entry records the change in quantity and the Value Entry records the change in inventory values. For the purposes of this post we just need to know that when posting Purchase receipts Value Entries are created for Expected Costs, and when you post Purchase Invoices, Value Entries are created for Actual Costs, and Expected Costs are reversed.
Expected Cost Posting to G/L – Switched ON
Unlike Dynamics GP you can switch ON and OFF accrual postings in Dynamics NAV \ Business Central via the Expected Cost Posting to G/L option in Inventory Setup. When you switch Expected Cost Posting to G/L ON interim accounts are used to post the accrual and inventory entries for Purchase receipt transactions.
The equivalent Dynamics GP accrued purchases account is called Invt. Accrual Acc. (Interim) and is specified in the General Posting Setup window and is selected based on the Posting Groups used on the Item and Creditor. (see my previous post for more details on the posting groups). I’ve highlighted this below
The Inventory code for the debit side of the transaction is taken from the Inventory Posting Group and again is based on the combination of posting groups used. I’ve highlighted this below
The key difference here is Dynamics GP doesn’t use an interim Inventory account whereas Dynamics NAV \ Business Central does.
In my Cronus demo data, the option Expected Cost Posting to G/L is currently switched ON so let’s see how this works when I create a Purchase Order for an Inventory item and receive it.
Here’s my Purchase Order and after clicking Post I’m going to choose receive so I receive the items into the Inventory:
When I view the item I can see this has created the following Value Entry (Number 454) which shows the Cost Amount (Expected) and Expected Cost Posted to G/L both populated.
If I highlight the Value Entry and click Navigate > General Ledger I can see the G/L Entries associated with the Value Entry
we can see the 5510 Accrual account is being credited and the debit entry is
posting to the 2111 “Interim” Inventory code.
Now let’s invoice the purchase order and take a look at the G/L entries. First I click Post and select Invoice on the Purchase Order. (Incidentally if I were to select Receive and Invoice the system recognises I’ve already received the items. It doesn’t receive them again)
This has created the a new Value Entry (Number 455) . There’s a few things to note here. Firstly the Cost Amount (Expected) and the Expected Cost to G/L have been reversed. Secondly the Cost Amount (Actual) and Cost Posted to G/L have been populated.
Again if I highlight the Value Entry and choose Navigate > General Ledger we can the G/L Entries associated with this Value Entry.
As you can see the original entries created via the Purchase Receipt have been reversed by posting a debit to the 5510 Inventory accrual account and a credit to the 2111 Interim Inventory account. The system has then posted new entries to the 2210 Resale items inventory account (debit) and the direct cost applied account (credit). (for more info on the direct cost applied account see my previous post).
So that’s it. Although there are a few extra distributions to Dynamics GP everything makes sense. Its also apparent that the Value Entries have a direct relation to the G/L entries that are created.
Expected Costing to G/L – Switched OFF
Now let’s see what happens when we post a Purchase Receipt with the Expected Cost Posting to G/L switched OFF. First I switch the option OFF and then create and post the Purchase Receipt
This has created the following Value Entries (Number 456)
The key thing to note here is that although the Cost Amount (Expected) is populated the Expected Cost Posted to G/L isn’t. This means no G/L Entries have been created. To prove this click Navigate > General Ledger to view any G/L Entries
Let’s now invoice the Purchase Order and see what happens:
This has created the following Value Entry
This Value Entry records the Cost Amount (Expected) being reversed and the Cost Amount (Actual) and Cost Posted to G/L are also populated. Therefore we get the following G/L Entries
As expected no expected cost postings have been created or reversed for this transaction.
Bonus – G/L Item Ledger Relation and Post Value to G/L SQL tables
An unexpected bonus of writing this post was the chance to geek out on some of the Dynamics NAV tables. Unlike Dynamics GP, I don’t have much of a grasp of the SQL tables in Dynamics NAV however while going through the various scenario’s I was curious about how a couple of things worked which encouraged me to dig a little deeper.
The first thing was how I was able to drill down on the G/L Entries from the Value Entries screen? This meant there must be a direct or indirect relationship between the tables.
After some digging I found the link was via the G_L – Item Ledger Relation table. Therefore writing the SQL query below enabled me to join the G/L Entries and Value Entries table to see all the details for Value Entry Number 455
The next thing I was curious about was what would happen if the Expected Cost Posting to G/L was switched from OFF to ON when there were lots of Purchase Receipts that hadn’t yet been invoiced?
I found the answer to this question lay in the two prompts you receive when you switch Expected Cost Posting to G/L from OFF to ON (or ON to OFF). Below are the two messages you get when toggling the setting
As per the first message it seems when you switch the option Expected Cost Posting to G/L ON the system determines if the Actual Costs for the Purchase Receipt have been posted and if not a record is written for that Value Entry to the Post Value Entry to G_L SQL table. This has a link back to the Value Entry so the system knows to create the Expected Cost interim postings for this Value Entry.
To show this in action, I switched the Expected Cost Posting to G/L option OFF and queried the SQL table:
As per the image above the SQL table is currently blank.
I then created
a Purchase Order and received it as per below:
After posting this I queried the Post Value Entry to G/L SQL table again to see if any new rows had been added and the table was still blank
I then checked the Value Entry for my receipt and as per the screen shot below the Cost Amount (Expected) is populated but the Expected Cost Posted to G/L is blank. As this is only the Purchase Receipt the Cost Posted to G/L is also zero.
I then went back to Inventory Setup and switched Expected Cost Posting to G/L back ON and clicked YES to the prompt and now when I check the Post Value Entry to G/L table its populated as per below
After toggling the Expected Cost Posting to G/L option to ON the system has determined that this Value Entry has no G/L Entries for the Expected Costs and has inserted a record into the Post Value Entry to G_L table with a direct link back to the Value Entry that was created when I posted my receipt.
Now if I run the Post Inventory Cost to G/L batch job as instructed in the second message G/L entries are created for the purchase receipt, the SQL table is cleared, and the Value Entry is updated. See below:
The report output
of the “Post Inventory Cost to G/L” shows entries have been created:
Below are the expected cost General Ledger entries created to the interim accounts. (in my previous example these were created immediately because I had Post Expected Costs to G/L switched ON)
And finally the Expected Cost Posted to G/L field on the Value Entry has been updated to show the General Ledger entries have been created and posted.
If I now check the Post Value Entry to G_L table in SQL I can see its been cleared.
Incidentally if I were to switch OFF Expected Cost Posting to G/L before running the Post Inventory Cost to G/L batch job the SQL row is removed from the Post Value Entry to G_L table.
In conclusion I find the way Dynamics GP deals with expected costs to be a much more conventional and simple approach however there’s no doubting that Dynamics NAV \ Business Central gives more flexibility.
Although I don’t know much about the inner workings of Dynamics NAV \ Business Central it also seems to me that G/L Entries are created based on the Value Entries.
In another post I hope to look at how Expected Costs work with Sales Shipments and Sales Invoices.
One thing I’ve noticed when posting Purchase Invoices with Inventory items in Dynamics NAV \ Business Central are the additional distributions to the Direct Cost Applied and Purchases accounts?
I’ve never been quite sure what the Direct Cost Applied account is, and when I’ve looked into it, I can’t find much information out there either. While researching for a previous post (here) a theory struck me for why the system might be posting to this account. Therefore, in this post I’ll detail my thoughts as to why Dynamics NAV \ Business Central posts to the Direct Costs Applied and Purchases accounts when posting Purchase Invoices using Inventory Transactions.
Purchase Invoicing in Dynamics GP
Firstly, I’ll go back to my roots – let’s see what distributions Dynamics GP creates when posting a Purchase Invoice with an Inventory Item. In this example we are receiving the Item and posting the invoice at the same time. Dynamics GP calls this a Shipment \ Invoice.
As you can see the distributions created are as follows:
Credit: Accounts Payables
This would also create one General Ledger Journal in Dynamics GP (G/L Register is the NAV\BC equivalent) with one Source Document (Source Code is the NAV\BC equivalent).
I’m not an accountant but this makes sense to me. We bought something for £6 so we have a Credit postings to Accounts Payables. We have increased our Inventory so we have a £5 Debit to Inventory, and finally a Debit to VAT.
As this is not an expense invoice there are no P&L implications at this point. We will have Cost of Goods Sold postings when we sell the item.
Purchase Invoicing in Dynamics NAV \ Business Central
When I post a Purchase Invoice for an Inventory Item in Dynamics NAV \ Business Central the distributions created are below. (*Please note I have Automatic Cost Posting switched ON in Inventory Setup)
There’s a couple of things to note here. Firstly, there are two more distributions when compared to Dynamics GP. We have distributions to the Direct Cost Applied account (7191) and the Purchases account (7110). Secondly, some GL Entries have a Source Code of PURCHASES and others have a Source Code of INVTPCOST.
Why the extra distributions?
If we dig deeper and go to the G/L Registers for this Purchase Invoice we can see the system has created two separate G/L Registers.
This G/L Register for the PURCHASES portion of the transaction:
And this G/L Register for the INVPTCOST portion of the transaction
The system has created two G/L registers because in Dynamics NAV \ Business Central you can defer the INVPTCOST portion of the GL postings via the “Automatic Cost Posting” option in the Inventory Setup.
Because of this each of these separate G/L Registers needs a balancing entry in order for the debits and credits to balance and the posting to work. In the case of the PURCHASES G/L Register of the transaction the 7110 Purch, Retail account is used and for the INVPTCOST G/L Register the 7191 Direct Cost Applied account is used.
One Possible Conclusion
Based on these findings one theory I have for the postings to the Purchases and Direct Costs Applied accounts when dealing with Inventory Items is to accommodate the Automatic Cost Posting option in the Inventory Setup. (the ability to defer the posting of the Inventory portion of the transaction). It could also be because for other aspects of the costing engine that I haven’t delved into yet.
If this option didn’t exist, and Inventory postings were always posted in real time, I can’t see why there would be a need to post to these additional accounts.
This is just an observation. I have no clear evidence to back this up. I’m just a Dynamics NAV \ Business Central newbie wondering why this works differently to Dynamics GP.
Above all I’m here to learn so if there are other reasons for the additional distributions I’d love to hear them.
All ERP systems aim to make data entry simple, fast and accurate. One way to achieve this is to default as much data as possible when the user is entering transactions, including the General Ledger distributions. In this post I aim to show how Dynamics NAV \ Business Central defaults the General Ledger codes when entering a Sales Invoice using inventory Items. Also, as I come from a Dynamics GP background, I’ll start off by providing a quick overview of how Dynamics GP achieves this, to offer a comparison between the two Dynamics systems.
The Dynamics GP way
GP you enter default General Ledger codes on entities like customers, vendors,
items, fixed assets and then the “catch all” which is the Posting Accounts Setup window.
Once this has been configured the General Ledger codes default automatically onto the transaction. For example, when creating a Sales Invoice for an inventory item usually the control account would default from the customer card and the revenue code would default from the inventory item (you can change this but usually it would be setup this way). At this point the user can potentially edit and change the General Ledger codes on the transaction prior to posting thus overriding the system defaults. Being able to edit the General Ledger codes inside the transaction gives the user more flexibility however it can also introduce mistakes or errors. An example would be someone changing the control account, which would likely cause a reconciliation issue at month end.
The Dynamics NAV \ Business Central way
From a Dynamics GP perspective things change quite dramatically when you look at how Dynamics NAV \ Business Central defaults the General Ledger codes. Instead of assigning specific General Ledger codes on customers, vendors, items, fixed assets, you assign Posting Groups to each of these entities. It’s the posting groups that have the General Ledger codes assigned and based on the combination of the posting groups used, general ledger postings are automatically performed when the transaction is posted. This means unlike Dynamics GP you can’t edit or change the default General Ledger codes prior to posting which gives less flexibility but there’s also less chance of mistakes being made.
So how do Dynamics NAV \ Business Central posting groups work?
There are two main types of posting groups – Specific and General.
Specific posting groups are used to default the control accounts. For example, I’ve assigned the specific Customer Posting Group “DOMESTIC” to the customer below:
If we open the Customer Posting Group window and look at the setup, we can see when I post a transaction for this customer the General Ledger code 40400 will be used for the receivables control account.
to the General Posting Groups things
become a little more complex.
posting groups can be split into two further groups – Business and Product. You
assign “Business” posting groups to customers and vendors and “Product”
postings groups to Items.
combination of the General Business
Posting group from the customer and the General
Product Posting Group from the item determines the General Ledger codes
that will be used. This is something that is best explained via an image, so
I’ve included a screen shot below of the General
Posting Setup window from my demo version of Business Central.
As you can see the posting groups form a matrix and the combination of “Business” (labelled Gen. Bus. Posting Group in the window) and “Product” (labelled Gen. Prod. Posting Group in the window) determines the General Ledger codes used when you post a transaction.
based on the General Posting Setup
above, if a customer has been assigned a Gen.
Bus Posting Group of DOMESTIC as per below:
item they are buying has been assigned a Gen.
Prod Posting Group of RETAIL as per below:
Then based on the General Posting Setup matrix defined in the General Posting Setup window the General Ledger sales account that will be used when the transaction is posted is 10200.
Defaulting the VAT Codes – VAT Posting Groups
A similar concept
is used when Business Central is determining the VAT percentage and VAT General
Ledger codes to be used. The matrix is defined in the VAT Posting Setup window as per below:
So, in this
example if the VAT Bus. Posting Group
on the customer was “DOMESTIC” and the VAT
Prod. Posting Group used on the Item is “STANDARD” the VAT percentage used
would be 20 and the General Ledger code used would be 56100.
So there you have it. A very quick overview of how Dynamics NAV \ Business Central uses Posting Groups to create the General Ledger distributions when posting a Sales Invoice with inventory items.
Its month end and when you come to reconcile the General Ledger control accounts to Receivables or Payables there’s a difference! You check all the usual things like unposted General Ledger batches or manual journals that may have been inadvertently posted to a control account, but this proves fruitless. So where do you start to track down the difference? There’s quite a lot of information out there on this however one technique I’ve found that gives me the most success is to narrow down the difference to a single day using the Historical Aged Trial Balance and the General Ledger Trial Balance and then use smartlists to focus on the transactions on that day. So without further ado here’s the full process.
Step 1: Find
the date the ledgers last balanced.
This is very important. For this to work you need a point in time when the Receivables (or Payables) Historical Aged Trial Balance matches the control account. In reality the ledgers should be reconciled at least monthly so this shouldn’t be a problem
Step 2: Run
the Historical Aged Trial Balance periodically and compare this to the General
Ledger Trial Balance of the control account.
have a starting point when the ledgers balance run the historical aged trial balance
report periodically using the “Print/Age as of” field and compare this to the General
Ledger trial balance for the same date range until you find the difference.
For example, let’s say the General Ledger and Receivables last balanced at the end of February but don’t balance at the end of March 2019. In this scenario you’d run the historical aged trial balance with a “Print/Age as of” date of the 7th of February as per below:
run the General Ledger Trial Balance for the control account up to the 7th
of February as per below:
If the Historical Aged Trial Balance matches the General Ledger Trial Balance you can safely assume the difference occurred later in the month and therefore you repeat the process running the same reports but advance the date. For example, you’d run the Historical Aged Trial Balance report with a “Print/Age as of” of the 14th of February and the General Ledger Trial Balance report with a date of 14th of February. Once you find a point where the reports no longer match you alter the date working backwards until ultimately you have one day when the reports match and the following day when the reports don’t match. You have now found the date the ledger goes out of balance!
Step 3: Run a smartlist of the General Ledger and Receivables transactions for the day the ledgers went out of balance
Now you have the exact date the ledgers went out of balance you can run a smartlist of the General Ledger and Receivables transactions and compare them looking for differences.
To do this
use the “Account Transactions” smartlist for the General Ledger using the date the
ledgers go out of balance.
Therefore, assuming the date we have identified when the ledgers went out of balance is the 10th of February, you’d run the smartlist using the following search criteria:
Next run the “Receivables Transactions” smartlist for the Sales Ledger using the same date as per below:
If you output both smartlists to Excel you can compare the two datasets and hopefully this will highlight the transaction(s) causing the difference. However if you still can’t find the difference Step 4 may help.
Step 4: Check
the Apply records
Normally by Step 3 I’ve identified the difference and can take corrective action. However, on the rare occasion this doesn’t help I’ve had to examine the apply tables in SQL as I’ve found a journal hasn’t posted for a multi-currency exchange gain or loss.
To explain in more detail when one or more foreign currency transactions are applied with difference exchange rates a journal is created in the General Ledger to adjust the control account. This is also recorded on the RZGANLOS field in the Receivables apply tables namely RM20201\RM30201.
To see if
this is causing an issue you need to have access to SQL to run a query. The
query I use is below assuming the date the ledgers went out of balance is the 10th
set dateformat dmy select * from RM20201 where DATE1 = ’10 Feb 2019′ AND RLGANLOS<>0 select * from RM30201 where DATE1 = ’10 Feb 2019′ AND RLGANLOS<>0
In my experience you should have at least one journal for each record produced by the query. In the General Ledger smartlist they would have a source document of “RMAPY”. (apply journal). If not a manual journal may have to be posted for any missing journals.
following these steps I can usually find the difference.