Dynamics 365 Business Central – Why do you need to specify posting groups on G/L codes?

Introduction

Since I’ve been working with Dynamics 365 Business Central I’ve loved the concept of posting groups. As a way of a very brief background, posting groups are used by Dynamics 365 Business Central to gather the required G/L codes when you post a transaction. Therefore you add posting groups to entities like Customers, Vendors, Bank Accounts, Item and also more interestingly G/L codes.

Coming from a Dynamics GP background I could understand why posting groups where needed on all entities, with the exception of G/L codes? Surely if I specify a G/L code on a transaction or journal, this is the G/L code I want to post to?

In this post I hope to shed some light on why the system still requires posting groups on G/L Codes.

A Sales Transaction using a G/L Code

As way of an example lets imagine we are adding the Sales Invoice using a G/L code as per below:

This transaction looks fairly straight forward. We are posting a Sales Invoice with a revenue code of 10100 therefore we expect G/L entries of Debit Debtors and Credit this Revenue code. With this in mind why would we need posting groups defined on the G/L code?

Ok, that’s a fair point, so let’s change the transaction ever so slightly and add some line discounts.

So now we have added line discounts we need a posting to the “Sales Discount” G/L code. However how is the system going to select the correct G/L code?

You guessed it, the answer is using Posting Groups.

So, if we look at the G/L card for G/L code 10100 we can find the product posting groups:

As this is SERVICES the system will use this, in combination with the “General Business Posting Group” from the Customer card, to select the relevant discount code using the “General Posting Setup” window, in this case 10300.

Without this information the transaction would fail to post. This is why the system is requiring you to enter posting groups onto G/L codes. They are needed so the system has a method of gathering other G/L codes that might be needed on the transaction.

Conclusion

This is likely obvious to seasoned Dynamics NAV and BC users however its something that took me a little while to fully grasp so I thought it worth sharing.

Hopefully anyone new to Dynamics 365 Business Central found this useful. (you can also read more about posting groups in this post)

Thanks for reading!

Dynamics 365 Business Central – How to change the Due Date on a posted transaction

Introduction

Due dates are automatically calculated using payment terms however sometimes you may wish to change them after posting the transaction.

You can do this on both the Sales and Purchase side using the relevant “Ledger Entry” page. Below I’ll demonstrate how this is done on a Payables Invoice using “Vendor Ledger Entries”.

Demo

First open the Vendor Ledger Entry page and click “Edit List” off the action pane

You will now see that the Due Date, along with other editable fields, can be changed. Here I’ve changed the due date on the top transaction from 01/07/2020 to 01/08/2020

As you can see I can also change the payment discount and tolerance dates.

Conclusion

Very quick post today but hopefully useful nonetheless.

Thanks for reading!

Dynamics 365 Business Central – Detailed Ledger Entries – The Unsung Hero

Introduction

When I talk to users about Dynamics 365 Business Central we often discuss the ledger entries, such as Customer and Vendor Ledger Entries, but never really touch on Detailed Ledger Entries.

They kind of go under the radar, however in reality they perform a crucial function, and underpin lots of information shown on the Ledger Entries screen.

In this post I aim to give them some well deserved limelight as I go through just how important a role they play in business central.

Ledger Entries

If we first take a look at the “Customer Ledger Entries” page we can see this is showing all the various documents we have posted against our customers.

In fact, this is the main page that’s used when you want to see a full history of all the documents we have posted to our customers. Using this page we can quickly see outstanding invoices, payments and much more.

It also displays things like Posting Date, Document Type, Document Number, Customer No and then a variety of Amount columns.

What’s interesting to note is that all the amount columns are hyperlinks, which we can click to view more information on that amount. However before we do this let’s take a deep dive into the “Customer Ledger Entries” table to gather more information on those columns.

Lets get technical

To figure out why those amount columns have hyperlink drilldowns let’s first check what table the “Customer Ledger Entry” page is based on. We can do this by clicking “CTRL + ALT + F1” to view the Page Inspection. In here we can see its based on the “Cust. Ledger Entry (21)” table

Now let’s open that table in “VS Code” and take a look at a couple of those amount columns. Specifically we’ll look at the “Amount” and “Remaining Amount” columns

Here we can see that the “Amount” and “Remaining Amount” columns aren’t physically stored in the “Cust. Ledger Entry” table. They are in fact calculated fields (flowfields) based on data in the “Detailed Ledger Entry” table.

So, when we see those amounts on the “Customer Ledger Entry” page we are in fact seeing totals based on data in the “Detailed Ledger Entry” table. This is why they are showing as hyperlinks. Very cool!

** What’s even more cool is that to maintain high performance they are implemented using SQL indexed views on the Detailed Ledger Entry table (I explain more on how this works in this article)

Wrapping up

Armed with this information we can see why whenever we post a sales transaction we get “Detailed Ledger Entries”, as well as the more commonly known “Customer Ledger Entries”. The “Detailed Ledger Entries” are maintaining the “Amount” fields on the “Customer Ledger Entries” table and (therefore) page.

Therefore its now apparent just how much of a crucial role they are playing in maintaining the amounts and outstanding amounts on the “Customer Ledger Entry” page we use so often.

Its worth noting “Detailed Ledger Entries” are created for a whole manner of things that affect balances on transactions. The most obvious would be when we apply one transaction to another. For example if I apply the invoice to the cash receipt from my earlier screen shot I’ll get “Detailed Ledger Entries” to reflect this.

** The system will create two detailed ledger entries. One for the invoice and once for the payment and both will have a type of “Application”

If when I drill down on the “Remaining Amount” on the Invoice it takes me to the related “Detailed Ledger Entries” and if we sum the “Amount” column it comes back to 0.00 which is reflected on the “Customer Ledger Entry”

** Incidentally we can get a list of all the different types by looking at the “Entry Type” on the “Detailed Ledger Entries” table in VS code

Conclusion

In summary the “Detailed Ledger Entries” are there to keep track of changes to the amounts of the “Customer Ledger Entries”. This way the system doesn’t have to maintain summary running totals on the “Customer Ledger Entries”.

Thanks for reading!