This is the second in a two part series looking at what your Dynamics GP data looks like when its migrated into Business Central.
In the first part we explored how opening balances are migrated and how they appear in Dynamics GP. We also looked at some of the options you have when migrating the opening balances, like preventing them auto posting so you can make changes if you were thinking of modifying the Chart of Accounts or adding dimensions. You can read the full post here.
In this post I want to look at how the Historical data migrates and where you can find the historical transactions in Dynamics GP. We’ll specifically look at Sales and Financial transactions.
Please note the migrated historical Purchasing data can be found in the same place as the Sales data you just select the Vendor List rather than Sales List
In my opinion this is one of the main reasons you might consider using the Microsoft tools to migrate your Dynamics GP data to Business Central. The migration of the Historical transactions is one of the first questions you I’m asked on almost every Business Central project, regardless of whether the client is moving from Dynamics GP. Normally the answer is no, or you can but it will involved lots of work and expense. This isn’t the case when moving from Dynamics GP to Business Central. The migration tooling does all the hard work for us and we can reap all the benefits.
Just like the previous post I’ll be using a migrated copy of the Dynamics GP “Fabrikam” text company I’ve migrated into my demo Business Central environment.
Options for Migrating Historical Data
Before we look at the migrated data let’s have a quick look at the options available when migrating the data.
In the “GP Company Migration Configuration” page we are offered the option to migrate the following modules:
We can also specify how many years of history you can migrate using the setting below:
I tend to select all modules and set the history to around 6 years.
Now we know what we can migrate, let’s take a look at where we can find the historical transactions in Business Central, and what they look like 😊.
What do my Historical Sales and Receivables Transactions look like and where can I find them?
Let’s first take a look at some Sales Transactions.
The historical data doesn’t create Customer Ledger Entries, as they have already been fully paid. The historical transactions are migrated into special tables, which can be accessed in various areas of Business Central.
There are a few places you can see your migrated Sales historical transactions however my favourite place is via the “Factbox” on the Customer List Page.
Here I’ve opened the Customer List page and you can see the tiles on the Factbox I can use to see my Dynamics GP transactions
If I click on the “GP Sales Transactions” tile I can see a full list of the “Sales Order Processing” transactions that have migrated from Dynamics GP:
From here I can drill down onto them and see “Distributions” and the Sales Lines
Here’s the same transaction in Dynamics GP. You can see all the detail has migrated
This information being available in Business Central is incredibly useful.
For example I can view the detail on previous Sales Orders and Sales Invoices I’ve sent to my customers. I no longer have to keep referencing my legacy Dynamics GP system for this type of information. Its seamlessly at my finger tips right in Business Central.
But wait it gets better!! Let’s now have a look at the information in the “GP Receivables Transactions” tile.
Note that when you post a Sales Invoice in Dynamics GP, as well as the Posted Sales Invoice, you also get a RM (Receivables Management) type transaction which is a little like the “Customer Ledger Entry” in Business Central. By drilling down on the “GP Receivables Transactions” we are looking at this RM transaction. This is what you apply cash receipts to and what Debtors reports are based off.
After selecting the “GP Receivables Transactions” tile we can see a list of all the fully paid migrated historical transactions:
If I drill down on our invoice from the earlier example, STDINV2057, we can now see the Payment that was applied to it.
Amazing! We can see the exact payment that paid the invoice.
This gives me lots of advantages. For example, if I have credit control queries from my customers, I can answer them from right inside Business Central. No need to switch between systems, its right here at my finger tips.
What do my historical Financial Journals look like and where can I find them?
Now let’s take a look at the historical financial data that is migrated.
To find the historical Financial data you first go to the “Chart of Accounts” page and from here I can select “Account > GP Detail Snaphot” to get the various options as per below:
I’ll first click “All Detail Transactions” and this takes us to a full list of all the journals that have migrated.
If you are missing you’re old segmented GL structure you can see it here 😊.
What’s absolutely fantastic is you can highlight a journal and click “View Details” to view the originating transaction. For example if I highlight the payment above and click “View Details” it shows me the payment.
I can even see the Invoice that the payment paid 😊.
If I now click the “Detail by Account” option I can see my whole GL account structure and I’m able to drill down and view the journals per account:
Again this is amazing information that I no longer have to go into Dynamics GP to view.
Now if I have queries on balances or I make regular journal adjustments I can view the historical entries right inside of Business Central.
Conclusion
In this post, we’ve explored how historical data from Dynamics GP is migrated into Business Central using Microsoft’s Cloud Migration tools, and how that data can be accessed for day-to-day reference.
Being able to view historical sales transactions, applied payments, and detailed financial journals directly inside Business Central provides massive value when migrating from Dynamics GP to Business Central.
I would even argue that even if you decide not to go live using a migrated GP company, there can still be significant benefit in migrating your historical data into Business Central as a separate reference company. This allows users to access GP history in a familiar Business Central interface, without impacting the live transactional company. This could strike a nice balance between keeping historical information accessible and starting fresh.
Ultimately, having historical GP data available inside Business Central helps make the new system a true single point of reference.
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.
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.
thedynamicsexplorer.com 