Author: Gavin Whittaker

Dynamics GP to Business Central Migration Post – Part 1: What do my migrated Opening Balances look like in Business Central

Gavin WhittakerLeave a comment

Introduction

If you are thinking of moving from Dynamics GP to Business Central, Microsoft provide an absolutely amazing tool that can migrate your Dynamics GP data to Business Central 😊

This tool will not only migrate your master data, but also some opening balances, and crucially your historical data.

In this two part blog series, we’ll take a closer look at what gets migrated and how it appears in Business Central.

In Part 1 (this post) we’ll focus on opening balances, in particular your Customer and Vendor transactions and your General Ledger opening balance.

In Part 2 will take a look at how the historical data is migrated, and what it looks like once it’s in Business Central.

What do my Sales and Purchasing Opening Balances look like in Business Central?

The migration will transfer Customer and Vendor unapplied transactions currently in the OPEN tables in Dynamics GP.

Customer and Vendor opening balances are posted in separate batches during the migration. After the migration has finished, The first place I usually review them is on the G/L Register page, which provides a complete view of all the opening balance G/L Registers.

You can learn more about Registers and how they function in Business Central in my blog post here

From here I can I highlight one of the batches and click the “General Ledger Entries” button which will show me the General Ledger Entries for the highlighted batch.

As you can see the General Ledger Entries post in and out of the Debtors Control account. This is because the balance for the Debtors and Creditors is migrated as part of the General Ledger Opening Balance.

I can follow the same steps to view the General Ledger entries related to the Vendors by simply highlighting the G/L Register from the Vendors

You can then click “Customer Ledger Entries” to view a list of the OPEN unapplied Sales transactions. The sum of this should match your outstanding Sales transactions in Dynamics GP.

If I want to see the “Customer Ledger Entries” on the actual Customer, I can simply go to the Customer List and drill down on the Balance as per below

If I then drill down on the balance for “Adam Park Resort” I can see how the OPEN transactions in Dynamics GP have created Customer Ledger Entries in Business Central

When you go live with Business Central these entries will show on the “Aged Accounts Receivable” report that you should reconcile back to the “Historical Aged Trial Balance” in Dynamics GP.

If can follow the same process to view my migrated purchasing transactions. In this case the General Ledger Entries will have posted in and out of the Creditors control account and I can view and total my Vendor Ledger Entries as well.

Please note you can also migrate paid transactions however this is performed as part of the historical data migration which we’ll cover in Part 2

What do my General Ledger Opening Balances look like in Business Central?

Now we have seen the Customer and Vendor opening balances, let’s have a look at the General Ledger opening balances.

The first thing to note is that you can specify how many years of General Ledger opening balances you wish to migrate via the “GP Company Migration Configuration”. A screen shot of this is below:

Please note that every single year will then be migrated as an Open Year. So you’ll have to run the “Close Income Statement”, which is Business Central General Ledger Year End process, for those years that have been closed. This will close the Income Statement General Ledger balances to the retained earnings account.

Now we know we can migrate multiple years, lets have a look at how this appears in Business Central 😊.

Before we look at the opening balances its important to understand how the Chart of Accounts differ between Dynamics GP and Business Central.

Dynamics GP uses a segmented General Ledger account, whereas Business Central uses a single General Ledger account and Dimensions for extra analysis. Therefore the migration splits the Dynamics GP General Ledger code and uses the “Main Segment” for the General Ledger code and the other segments as dimensions. You can read more about this in my blog post here and here.

Therefore my migrated Fabrikam Chart of Accounts appears as per below in Business Central.

Again, I find the best place to start to look at how the balances have transferred, is the G/L Register page.

Here we can see that we have a register per Year-Period.

If I drill down on the “General Ledger Entries” for GP2025-1, you can see that we get a summarised total for each Dynamics GP General Ledger Code, rather than the individual detailed entries for the period.

Furthermore, we can match this back to Dynamics GP. So taking the highlighted row below for GL Code 5170 and Division Code 200 and Department Code 00, which is 200-5170-00 in Dynamics GP, we can see we have a balance that has migrated of £3,803.77.

If we have a look in Dynamics GP at code 200-5170-00 we can see the same monthly balance for period 1 of 2025

Taking this a step further, if I go straight to the “General Ledger Entries” page to see all migrated entries, and then filter to the GL code 5170, Division of 200 and Department 00, I can match every single period amount to that Dynamics GP summary shown above:

This proves that my migration has worked. All balances have been migrated on a month by month basis.

Whats also great, is now my GL code is seperate from my Division and Department, I can easily get a sum total at GL Code level and dimension level 😊

Conclusion

As we have seen, your opening balances from Dynamics GP migrate cleanly into Business Central, with Customer and Vendor OPEN transactions and summarised General Ledger balances brought across in a clear and reconcilable way.

In Part 2, we’ll take a closer look at historical data and how it appears in Business Central after migration.

Thanks for reading!

Dynamics 365 Business Central – Error Message “You have one or more documents that must be posted before you post document no….” when posting a Journal

Gavin WhittakerLeave a comment

Introduction

When posting a Journal in Business Central you receive the message “You have one or more documents that must be posted before you post document no..<docno>..according to your company’s No. Series setup”.

In this post we’ll look at why this error occurs and how it can be resolved.

First, let’s recreate the error

Here I have a journal batch for Depreciation. Everything looks fine, I’ve entered a Document Number and the journal balances.

The system will allow me to “Preview Post” however when I try and post the batch I’m presented with the error below:

I’m unable to post the batch?

Before we discuss the solution, let’s take a closer look at the configuration.

Journal Batch Configuration

The error is giving me some clues to the issue. Part of the error is saying “according to your company’s No. series setup”. I know that a No. Series in a Journal comes from the batch itself, so let’s have a look at that.

Below is a screen shot of my “DEPRECIATO” batch when contains my journal.

Here we can see that the batch has been assigned the No. Series “GJNL-GEN” so let’s go to the “No. Series” page and take a closer look at its configuration.

Straight away I’m seeing that “Manual No’s” has been switched OFF on the batch. This means that as this Number Series is assigned to my batch, I can’t enter my own number in journals in this batch.

Going back to my batch, I’ve explicitly given the journal my own Document Number of “NOVDEPREC”. However, as we have seen, the Number Series assigned to my batch doesn’t allow Manual No’s.

Therefore, this must be my issue 😊.

The Solutions

Now we know the issue, let’s think of some potential solutions.

Switch ON Manual Numbers on the Number Series

The most obvious solution is to go to my Number Series and switch ON manual numbers. This would enable me to use my own document number of NOVDEPREC and the journal should post.

However this means that if the number series is assigned to any other batches, users would now be able to enter their own document numbers, and this might not be a good idea.

Remove the Number Series from the Batch

I could also remove the “Number Series” from my batch. I could then use any document number I like on the journal lines.

This would be fine is this is my personal batch, and the controller is happy for manual numbers to be used on journals.

Click “Renumber Document Numbers” on the menu

Finally, I could click “Renumber Document Numbers” from the function menu on the journal page as per below:

This will automatically fetch the next number from the Number Series and the batch should now post

Conclusion

This post has shown why the error “you have one or more documents that must be posted before you post document no..<docno>..according to your company’s No. Series setup” occurs, and gives a number of solutions.

I tend to use the last option when fixing this, as I assume the user what’s a sequential number for their journals. Having that configuration also ensures you always have a sequential journal number which most users want.

Thanks for reading!

Dynamics 365 Business Central – How to post a Sales Credit for an Item without affecting Inventory using an Item Charge

Gavin WhittakerLeave a comment

Introduction

A client recently had a situation where they wanted to give a customer a discount as a goodwill gesture for an Item they had previously shipped and invoiced, as the customer wasn’t entirely satisfied with the Item.

However, when raising the Sales Credit Memo, they selected the inventory item and noticed the system had generated Item Ledger Entries to return the item to inventory. This was incorrect because the customer was keeping the item, they were just issuing their customer with a credit note due to an issue with the item and delivery.

In this post, we’ll explore two methods we can use to issue a credit note for an item without returning it to Inventory, and show how using an Item Charge proves to be the most effective.

Scenario

The scenario we have is a client has received delivery of an Item, in this case an Athens Desk, however it arrived late and they have complained and requested a discount for their inconvenience.

As a gesture of goodwill we are going to give them a 10% discount in the form of a Sales Credit Note.

There are a couple of ways we can deal with this. We could create a credit note and post directly to a GL account, or alternatively we could create a credit note and use an Item Charge.

We’ll first work through a scenario using a G/L Account and see why this might not be the best choice for this particular situation.

Credit Memo using G/L Account

First, we will create a Sales Credit Memo using a G/L account.

Below is the Sales Invoice for the Athens Chair that is to be credited.

Importantly, when we posted this Sales Invoice it created the following “Item Ledger Entry” to record the reduction in Inventory. This also shows the “Sales Amount (Actual)” as £649.40 which is retrieved via the Value Entry.

Please note the “Sales Amount (Actual)” shown on the Item Ledger Entry is actually a Flowfield that links (flows) back to the Value Entry. The Item Ledger Entry records the Inventory quantity movement for the transaction, whereas the Value Entry records the Inventory Values for that movement.

Please note the Sales Shipment number associated with the Sales Invoice is recorded on the Item Ledger Entry.

The Sales Invoice has also created the following “Value Entry”, which records the “Sales Amount (Actual)” which is linked to the above Item Ledger Entry

To raise the Credit Note, I’ll go to “Sale Credit Memo” and select the relevant Customer and enter the line as per below.

Here I’m picking up “G./L Account” as the Type and then selecting the relevant GL code and entering the amount.

This will generate the following entries:

As you can see there are no Item Ledger Entries being created, which is great, as we don’t want to adjust Inventory quantities, however there is also no Value Entry.

Therefore although the ledgers are correct, as the GL Entries have hit the relevant accounts, and the Customer Ledger Entry was created, if we look at the original Item Ledger Entry the “Sales Amount (Actual)” is unaffected.

Therefore if we are to use Inventory tables like Value Entries or Item Ledger Entries in reports the values for Sales Amount for this Sales Shipment / Invoice are incorrect.

Credit Memo using Item Charges

Another method we could use to raise the Credit Note is by using an Item Charge rather than a G/L Account.

When using an Item Charge in the Sales Credit Note we can then link (assign) the charge back to the posted transaction(in this case the Sales Shipment associated with the Sales Invoice we need to Credit). This will create a Value Entry and therefore be reflected on the Item Ledger Entry unlike the previous example when using a G/L Account.

Let’s walk through this example below.

First I’ll post another Sales Invoice for an Athens Chair as per below:

This has created a new “Item Ledger Entry” and “Value Entry” however they are the same as the previous Sales Invoice so I wont show these here.

I now want to credit this Sales Invoice, but this time using an Item Charge.

In order to do this I’ll create an Item Charge as per below:

I’ll now create a new Sales Credit Note and pickup the Item Charge and enter the amount.

Finally I’ll link, or assign, the charge to the posted transaction. (in this case the Sales Shipment associated with the Posted Sales Invoice)

This involves selecting the line, clicking “Item Charge Assignment”, finding the relevant Sales Shipment associated with my Sales Invoice, and then assigning the charge to the Sales Shipment.

This clip shows how I do this below:

Now when I post this transaction I get similar entries however I now have a Value Entry

On closer inspection the Value Entry is for £-64.94 and crucially its linked to the Item Ledger Entry

So now when we go look at the Item Ledger Entry for this Sales Shipment the Sales Amount has been reduced.

And if we drill down on the “Sales Amount (Actual)” to the Value Entries we can see the two value entries. One is the original Sales Invoice and the other the Item Charge we just posted:

We now have an accurate “Sales Amount (Actual)” being recorded in Business Central.

Therefore any reports based on the Inventory tables will reflect the accurate values.

Conclusion

In this post, we’ve walked through two methods to issue a Sales Credit for an item in Business Central without returning it to inventory.

We first looked at using a G/L Account, which is straightforward but doesn’t update the Item Ledger Entry’s “Sales Amount (Actual),” which can cause issues with inventory related reports.

We then looked at using an Item Charge, which we linked to the original Sales Shipment. This ensures the Sales Credit is reflected in the Value Entries and accurately adjusts the “Sales Amount (Actual).”

In my opinion this makes the Item Charge approach the better choice for maintaining precise inventory records and reliable reporting.

Thanks for reading!