Let’s Compare: GP to BC Master Records
I remember very well trying to get a handle on the key differences between GP and BC as soon as it was released.
For me, I needed 2 things to get started: the list of SQL tables, and the window in the BC application so I could ‘see’ the overlay of the data. We can do that easily in GP, but I struggled greatly to really understand these with BC, not having access to SQL and being a web based application was a whole new world.
Here is a key functional translation that may be helpful to know up-front: “Pages” in BC are the same as “Forms” in GP. The various pages behave as a form overlay on the data. Some are cards, some are entry, some are inquiry type pages.
So, remember, BC is not GP in the cloud.
For someone migrating from GP to BC, understanding the differences in how BC structures its core Master Records is critical, and the next most important thing to consider after the General Ledger Accounts and Dimensions. For this new post, I’ll be covering a lot of information, but I do hope it gets you in The Dynamics Mindset, and is helpful on journey to BC in the cloud. But first:
The singular most important concept to understand before scrubbing your vendor, customer, and item lists lies in the concept of the ‘No. Series’. BC has one, GP does not, but BC does not have a numbering series for everything (yet), such as shipping address IDs.
The second most important thing to grasp is the malleability of the master record pages in BC due to various factors including Role Center selection and Personalization.
The third concept to grasp is the method which BC posts to the various ledgers. This is quite different than GP, but pretty cool to see it work, and I think it is quite helpful to have these layers for subledger reporting, especially with Power BI. I am not covering that here, but at this point, just be aware there are subledgers available in BC just like in GP.
The fourth idea to understand is there is no direct correlation from GP to BC for the “Class ID.” This is accomplished by combining Templates and Posting Groups.
Please check out my new GP-to-BC Migration Station page for a deep dive, full-emersion journey into the tables and fields of your choice. This is my personal set of master record table comparison and reference pages. I also discuss key BC migration considerations for your GP data preparation, and provide links to the official BC table guides there.
I wanted to create and share in this post a high-level table comparison and summary of the individual master record cards, with links to the individual parts of the Migration Station analysis. I hope you enjoy!
Vendors, Addresses, EFT/Banking
The basis of an efficient setup within the purchasing functional area in Business Central lies with the Vendor, Vendor Address, and Vendor EFT/Banking information. The comparison screenshot below shows the table IDs and the total number of columns in their respective ERP systems.
I found an exact or a close match for 22 of the 109 fields on the Vendor card in GP (20%)
There are 11 of 28 fields that match on the Vendor Address card in GP (35%)
For the Vendor EFT/Banking card there are 13 of 37 overlapping fields (39%)
The Vendor No. in BC does not necessarily need to be the Vendor ID you used in GP, but it could be, if you configure BC to allow manual numbers in the vendor numbering series. I definitely recommend converting to the auto-numbering option that BC offers for creating new vendors at some point. The very fact that BC does this is quite nice.
Like GP, there is a vendor Merge utility, but it only handles one record at a time instead of having an import option to change in bulk. GraVoc has developed customization for BC that does this however so we can service our customer needs.
There are a lot of GP users that have customizations or ISV products that will NOT need them after moving to BC.
Consider integrations with other systems when setting up your BC vendors.
Customers, Addresses, Salespeople
The typical setup for Sales within Business Central starts with Customers, Customer Addresses, and Salespeople. The comparison screenshot below shows the table IDs and the total number of columns in their respective ERP systems.
I found an exact or a close match for 28 of the 103 fields on the Customer card in GP (27%)
There are 15 of 33 fields that match on the Customer Address card in GP (45%)
For the Salesperson card there are 5 of 39 overlapping fields (13%)
The Customer No. in BC does not necessarily need to be the Customer ID you used in GP, but it could be, if you configure BC to allow manual numbers in the customer numbering series.
Like GP, there is a customer Merge utility, but it only handles one record at a time instead of having an import option to change in bulk. GraVoc has developed customization for BC that does this however so we can service our customer needs.
There are a lot of GP users that have customizations or ISV products that will NOT need them after moving to BC.
Consider integrations with other systems when setting up your BC customers.
Items, Locations
Products and Services and the sites they reside in, are considered Items and Locations in Business Central. Just like in GP, items in BC can be real-deal inventory items, that have quantities on shelves, or service items that merely print on sales invoices and book revenue. There are many intricacies to the proper setup of the entire inventory module, and more so for manufacturing, however for the purposes of this analysis I am sticking to the Item and Location cards. The comparison screenshot below shows the table IDs and the total number of columns in their respective ERP systems.
I found an exact or a close match for 14 of the 90 fields on the Item card in GP (16%)
There are 11 of 33 fields that match on the Location card in GP (33%)
The Item No. in Business Central does not necessarily need to be the Item ID you used in GP, but it could be, if you configure BC to allow manual numbers in the item numbering series.
One key difference to note is in the field length of the Item Code. It is a whopping 33% shorter in BC than in GP (20 character max vs 30 char max in GP) so check your item IDs because you may be forced to shorten some of them. Out of all the field differences between systems, this could be the most frustrating of them all for migrating from BC.
There are a lot of GP users that have customizations or ISV products that will NOT need them after moving to BC.
Consider integrations with other systems when setting up your BC items and locations.
Checkbooks/Banking
Maintaining proper cash controls and reporting is critical for every business, and the Bank Reconciliation module is where it all gets tracked in the ERP. The online / SAAS nature of Business Central lends itself to more and better API connectivity with your bank, which is a big help in todays world. BC has an auto-matching feature, and Copilot as well, for performing bank recons. Keep in mind multicurrency is different between GP and BC, and that applies to banking too.
Business Central stores a lot on the Bank Account card. When comparing to Dynamics GP, it took me three different tables to map the most important setups for the one Bank Account table in BC. What a difference! The comparison screenshot below shows the table IDs and the total number of columns in their respective ERP systems.
I found an exact or a close match for only 17 of the 126 COMBINED fields on the Checkbook Master, Bank Master, and Checkbook EFT master cards in GP (13%).
One major update and difference from GP is that BC uses the concept of Data Exchange Definitions for importing and exporting bank information. The sheer flexibility of this tool, in addition to the connectivity offerings many banks have off-the-shelf as an extension for BC, enable a better bank rec experience with deeper and more modern file types and international capabilities as well.
There are a lot of GP users that have customizations or ISV products that will NOT need them after moving to BC.
Consider integrations with other systems when setting up your BC Bank Accounts.
Author’s note and Disclaimer:
Mapping ERP systems is a complex and subjective task for any one person.
Significant differences between GP and BC will require you to learn more deeply about the product to perform a successful implementation.
There is more than one way to map particular fields, but I think you’ll get a lot out of the references provided.
I am not infallible, so let me know if you spot an issue I need to update. I don’t want to present anything factually incorrect here, however how you map your data in real life is up to you.
I needed to know the differences that really matter between the master records in both Dynamics GP and Business Central. I hope you gain value from my analysis and notes.
As I do more BC implementations, and if / when BC changes, I’ll keep this up to date, and make adjustments and add additional notes where needed. I’ll also work on filling in any holes to make this complete because these are MY personal reference pages too.
Some of the tables on the individual pages probably won’t render very well on some mobile devices, but try tipping it horizontally instead!
Please feel free to bookmark the Migration Station page, and use it as a reference guide, or a learning tool, to help with your migration.
I’m grateful should this experience or these insights be helpful to you on your journey…until next post!