This is the third post in a series comparing Dynamics 365 Business Central and Dynamics GP, and follows on the post Dynamics 365 Business Central vs. Dynamics GP: Customer Navigation.
In this post, I am going to compare the Customer records of both Business Central and Dynamics GP.
There are hundreds of details of Customer records that can be analyzed, but I'm going to discuss a handful of the things I happened to observe as a long time user of Dynamics GP, but a brand new user of Business Central.
Dynamics GP
I've spent so much time in the Dynamics GP Customer Maintenance window that I no longer notice the details. As a result, I'm going to have to review it more carefully to try and point out some details that make it unique, along with a few quirks.
 |
| Dynamics GP Customer Maintenance Window |
Customer ID: Let's start with the Customer ID field. This is a 15 character text field used to store a unique identifier for a customer. One of the quirks of Dynamics GP is that it does not generate any default ID values for master records. As a result, customers typically come up with an arbitrary convention for assigning Customer IDs, like "first 8 letters of the customer name, followed by a 3 digit sequential numeric suffix". For example, "AMCETOOL001".
I think I've only encountered one Dynamics GP customer that needed more than 15 characters for this field, due to an elaborate customer ID scheme, so the customer ID field length seems sufficient for most customers.
Honestly, I think it's silly that GP has no means to automatically generate master record IDs. While most customers seem content to manually generate the IDs, many customers, consultants, and ISVs have developed scripts and customizations to automatically generate and assign the IDs. But it's one of those things where customers and partners are reinventing the same low-value solution thousands of times over.
I can come up with hypothetical pros and cons to having the flexibility to assign the customer ID, but I think it's typically unnecessary, and I think GP users would get along just fine if system generated IDs were assigned automatically. If Dynamics GP had better search features, it would decrease the dependency on customer ID numbering schemes, but given the poor search capabilities of GP, most customers are highly dependent on their ID systems to lookup master records, which is unfortunate.
Class ID: The Dynamics GP Class ID is a very handy feature that allows you to default a whole bunch of settings from a "Class" template. Payment terms, credit limit, discounts, tax schedules, you name it. In addition to defaulting values, many customers use the Class ID as a means to categorize customers. So perhaps customers are grouped into West / Central / East classes to identify their region. Or perhaps Wholesale vs Retail customers. It's a great dual-purpose field that is widely used.
 |
| Customer Class Setup |
 |
| National Accounts Maintenance |
Multiple Customer Addresses: Dynamics GP allows each customer record to have an (practically) unlimited number of child address records. Each Address ID record contains contact information, plus a few additional fields like shipping method, taxes, salesperson, etc. While this does offer Dynamics GP users flexibility for storing multiple customer addresses, in my experience, most customers don't utilize this feature much, with the vast majority of customer records having only one address ID. And when integrating Dynamics GP with other systems that do not support multiple customer addresses, this design often causes some complexity, as multiple Dynamics GP Address IDs must be mapped to separate customer records in the external system. But in cases where customers have separate Bill To and Ship To addresses, or multiple Ship To addresses, this is a pretty handy feature.
 |
| Customer Address Record |
Phone Numbers: One design flaw / annoyance in Dynamics GP is the phone number field format. It defaults to the North American phone number format, which is a complete mess for companies that need to specify international phone numbers. Technically, it is possible to modify the default format, but it's a hassle. The phone number values are stored in the database as numbers-only, in a fixed length format, with trailing zeroes. This data storage 'method' results in hassles when retrieving and formatting the numbers. Quirky, and not ideal.
 |
| Phone Number Storage in SQL |
Address Fields: While the Dynamics GP address fields are labeled for North American addresses, the number of fields and field lengths seems sufficient for international addresses. I worked with one customer who sold services in dozens of countries around the world, and the Dynamics GP address fields worked fine for their customer address records.
Accounts: In Dynamics GP, a customer record can have default GL posting accounts assigned. This is a different design than Business Central, as Gavin Whittaker explains in his post on Business Central Posting Groups.
 |
| Dynamics GP Customer GL Account Defaults |
Email Addresses: Dynamics GP (Great Plains) was developed well before "The Internet" was popular. As a result, the main customer record does not have any fields for email, web site, etc. An "Internet Information" window was added at some point, and provides a confusing mess of Internet related fields that are attached to a Customer + Address ID combination. This window / record does provide several additional fields at the Customer Address level, but the data is stored in a separate table, adding a bit of complexity to integrations and queries.
 |
| Internet Information Window |
Field Availability and Field Lengths: One of the most important aspects of any ERP system is its ability to store the data you need. Does the system have enough fields to store additional information related to a customer, and are the fields long enough to store the values you need? In my experience, the Dynamics GP customer record has plenty of fields, and the field lengths have been more than adequate. In addition to the standard fields, there are two User Defined fields, two Comment fields, a Note field, several other fields that can be co-opted, and the ability to attach files to the customer record.
There are cases where GP customers want to store lots of additional information about a customer--perhaps contract information, additional billing info, etc. Those customers often use the Extender product to add custom fields, or they customize GP using Modifier & VBA, .NET, or Dexterity to add additional fields.
Business Central
Before I get started, here is a link to the Business Central documentation that describes and names the design elements of a Card page. I find it helpful to know the formal names of each element or section of a page to help facilitate discussion.
 |
| Business Central Customer Card with Wide Layout view and FactBox Pane on the right |
In Business Central, the "Customer Card" page is used to edit a customer record. The Customer Card has at least 3 different "views". There is a standard or compact view, a "wide layout" view, and also a "FactBox pane" that can optionally be displayed on the right side of the page.
 |
| Standard or Compact view and Show More links on each FastTab |
Critical Update: I have discovered that Dynamics 365 Business Central supports emoji characters. This is my new favorite feature.
 |
| Emoji support is essential for any modern ERP system |
FastTabs: The Customer Card has several "FastTab" sections: General, Address & Contact, Invoicing, etc. Each FastTab can be collapsed by clicking on it, or you can click on the Show More link in the upper right of each FastTab to show additional fields.
 |
| Customer Card "General" FastTab with Show More selected |
The FastTab design, and the Show More option, both seem like nice design elements, allowing a user to hide sections or fields that they don't need to work with.
 |
| Example of collapsed / hidden FastTabs |
And if a user chooses to have Show More for the General FastTab, and collapse the Address & Contact FastTab, those preferences appear to be retained. So when the user returns to the Customer Card, it displays the window with the same layout preferences the user selected the last time they used the page.
Read Only Mode: Interestingly, there is a Pencil button at the top of the Customer Card that allows a user to enter "read-only mode" on the customer record.
 |
| Read Only Mode |
At first glance, I was puzzled by this feature. In the Dynamics GP world, you typically use security to either allow a user to create and edit records through the Customer Maintenance window, or only allow read-only access through the Customer Inquiry window. The user either has edit permissions, or they don't. I can't think of a use case where a user would freely switch between read-only and edit mode.
When and how would this feature be useful?
I posted this question on Twitter and the Business Central Forum, and after reviewing the responses, I've come up with my own guess about the Pencil button at the top of the Customer record.
The initial responses I received claimed that the Pencil button read-only mode is a handy feature that allows users to avoid accidentally changing a record. Because Business Central does not have a Save button or an Undo button, and because Business Central immediately saves changes to fields, a user could accidentally change a field value on a record, and it would be saved immediately. The Pencil button, the responses claimed, allow users to switch to Read Only mode to avoid accidentally changing the record.
While the button can be used this way, I do not believe that is the reason the Pencil button is displayed at the top of the Customer Card page. It's unrealistic to expect a typical end user to open a record, then have them pause, reflect, and perform the extra step of clicking a button to prevent themselves from accidentally making a mistake. I don't consider this a viable explanation for the button.
After poking around further, I found that by default, clicking on a Customer or Vendor record opens it in Edit mode in Business Central. However, if you click on the "More options" ellipsis button next to a Customer or Vendor record, you can choose "View" to open the record directly in Read Only mode.
This is a clue that I think points to a much better explanation for the Pencil button at the top of the Customer Card.
After I questioned the initial responses claiming that the Pencil button is intended to help users avoid accidental edits each time they opened a record, I received what I think is a better explanation from Marton Sagi.
 |
| A better explanation for the Pencil button |
For those of us that aren't yet familiar with BC development, this is insightful.
My current assessment is that the Pencil button is not a feature that is necessarily intended to be used on a Customer Card or Vendor Card page by the user when a record is viewed. It is simply exposing a feature of the Business Central architecture and development tools.
An AL developer can apparently choose to open records in either Edit mode or Read Only mode. Customer Card records just happen to open in Edit mode by default, and the Pencil button is displayed because the Edit / Read Only feature is fundamental to Business Central Card pages.
On a different page that opens a record in Read Only mode by default, I presume that if the page was designed to allow edits, a user could click on the Pencil button to switch from Read Only to Edit mode.
This makes much more sense to me. I don't believe there is an equivalent feature in Dynamics GP. In GP, if a user has permissions open the Customer Maintenance window or a Transaction window, the windows always opens in "Edit" mode and the user can change or delete the record. (While other users with read only access would open a GP Inquiry window, which is always read only.) But unlike Business Central, in Dynamics GP, the user must explicitly Save, Discard, or Delete the record after making changes.
 |
| GP requires that you choose to Save or Discard changes to a Customer record |
But this reminds me of one annoying quirk in Dynamics GP that is not related to the Customer record, but is related to editing transactions. In GP, if you edit an existing transaction, but don't want to save your changes, you are sometimes greeted with this frustrating dialog.
 |
| Accept any changes or delete the entire record |
In this case, GP does not allow you discard your changes to the existing transaction. There is no cancel or undo. You either have to save any and all changes, and potentially try to undo them later, or you have to delete the entire transaction and start over. So in this respect, Dynamics GP transaction edits don't seem to be any different than Business Central edits that are saved immediately.
Customer Number: A Dynamics GP user will immediately notice that the Customer "No." field is automatically populated with a sequential, incrementing number.
 |
| Business Central can auto-number master records |
This is a great feature.
The customer number is generated based on a "Number Series" that can be customized.
 |
| The CUST Number Series automatically assigns numbers to new customer records |
To view all of the Number Series records, click on the magnifying glass Search button in the upper right corner of any Business Central page and type "number series".
 |
| Search for Number Series |
 |
| Centralized listing of all Number Series records |
The centralized management of all Number Series records is great. While Dynamics GP does not auto number master records, it does automatically number most transactions. And GP users will know that the "next number" values for GP transactions are scattered throughout the application, buried in at least a dozen different windows.
And notice that Business Central has a "Manual Nos." checkbox for each number series.
 |
| Option to allow manual entry / override of the number series |
This checkbox indicates whether a user should be allowed to override the value provided by the number series.
When creating a new customer, I can modify the default number series value.
 |
| Modifying the default number series value |
And even more interesting, I see that Business Central allows me to change the Number for an existing Customer record!
If I modify the existing Number value and press Tab, this dialog appears.
 |
| Business Central allows the Customer number to be changed |
If I click on Yes, the new Customer Number is saved.
 |
| New Customer Number |
This is very different from Dynamics GP, which does not allow changing record IDs through the user interface. In the GP world, if customers need to change customer IDs or vendor IDs, they often need to change many of them, and would use a separate tool or third party product to perform the bulk Customer ID updates through the SQL Server database.
On the one hand, this seems like an interesting feature in Business Central. But on the other hand, I can't think of a situation where this feature would be used or how often it would be used.
Do you know of any use cases where changing an individual record number in Business Central is valuable? If so, I'd love to hear about them. Post a comment below, or email me at steveendow (at) gmail !
Customer Templates: When creating a new customer, Business Central seems to require that you select a Customer Template.
 |
| Business Central Customer Templates |
The Business Central Customer Template appears to be similar in concept to a Dynamics GP Class ID. The Customer Template provides default values for 23 customer fields or settings that are automatically applied to a new customer record.
 |
| Business Central Customer Template |
One difference that I noticed between the Business Central Customer Template and Dynamics GP Customer Class ID is that it appears the BC Customer Template can only be applied once, when a new customer is created. I wasn't able to find a way to apply a different template to an existing Customer record, unlike Dynamics GP, which allows you to apply a different Customer Class to an existing Customer.
Parent / Child Customers: I was unable to find any type of Parent / Child relationship in the Business Central Customer record. If there is a way to associate Customer records in this way, please let me know.
Contacts: Business Central has a Contact object that appears to be similar to a Dynamics GP Address ID on the surface, but seem to serve a different role in Business Central.
I recall being confused by the Contacts during the training class that I attended (back when the product was called "Project Madeira" and "Business Essentials"). The concept seems like it should be straightforward, but the way that Business Central automatically creates Contact records is a bit confusing to me as a new user.
When I created the C00010 Customer, a Contact Code CT000024 value was automatically created.
 |
| Business Central automatically creates a Contact Code and Contact record |
If I click on the ellipsis button on the Contact Code field...
 |
| Contact Lookup |
A list of Contacts is displayed.
 |
| Contact List |
This is where I get puzzled. Notice that there is a Contact CT000023 shown in bold, above the Customer Contact CT000024.
It seems like CT000023 is the "main" Customer Contact record, but for some reason a second Contact record is created automatically.
If you edit each of the Contact records, you should notice that the Type field has two different values: Company and Person.
 |
| Company Contact record |
 |
| Person Contact record |
I think I understand the concept of the Contact record, but I am still not clear on why there is a separate Company Contact and Person Contact. I assume they each serve a purpose, but looking only at the Customer record, it isn't obvious to me what that purpose is. Perhaps it is to support the Relationship Management features of Business Central?
One thing that confuses me about the two Contact record types is what happens when I edit one of them. In this example, I modified 3 fields on the Person Contact.
 |
| Modifying 3 fields on the Person Contact record |
After I made those changes, the Email field on the Company Contact record changed.
 |
| Email value is modified on the Company Contact record? |
Why? Is this the intended behavior? Or a bug?
It seems odd that a change to the Person Contact record would update the Company Contact record, but even stranger that in this small test, only the Email field is updated.
It seems that changing the Country Code on the Person Contact record also changes the Country Code on the Company Contact record. So it isn't just the Email field that is updated between the records.
Is that intentional?
I suspect I need to have someone explain how the Contact records are used and why some fields seem to update in both Contact records, while others do not.
Update: After testing this again, and changing all of the fields in the Person Contact record, none of the fields in the Company Contact record were updated. So I am not sure what happened in my first test and why changing the Email and Country Code values on my Person Contact updated those fields on my Company Contact. Puzzling.
Ship To Code: In an additional twist on Customer addresses, Business Central allows you to create a Ship To Code.
 |
| Customer Ship-to Code |
 |
| Customer Ship-to Code & Address |
This seems similar to the Dynamics GP Ship To field, which allows you to specify a different Address ID.
 |
| Dynamics GP Customer Ship To Address ID |
But a fundamental difference is that Business Central has separate Contact record and Ship To address record types, whereas Dynamics GP has a single Address ID record type that can be used interchangeably in any address ID field on the Customer record.
Phone Number: The almost-free-text Business Central phone number field is a nice improvement over the rigidly formatted Dynamics GP phone number field. However, there is one oddity.
 |
| Letters are verboten, but symbols are okie dokie |
The Business Central phone number field allows numbers and symbols, but does not allow any letters. From a database perspective, this seems odd--if you're able to enter and store any symbol, you should be able to technically store letters as well. But...
Eric Hougaard explained that this restriction is due to the ExtendedDataType property on the phone number field.
Erik provided a link to this page:
https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/properties/devenv-extendeddatatype-property
Which describes the "Phone No." Extended Data Type property with this sentence:
"When the field type is interpreted as a phone number, the client will show dial actions."
Given this, my guess is that letters are excluded in order to support VoIP dialing, which would make sense.
Interestingly, the Phone No field does support emojis!
 |
| Emoji away! |
This post has become extremely long, so although there are probably a hundred other details that can be covered, I'm going to wrap it up here. As I discover more features and quirks related to the Business Central Customer record, I'll likely create smaller posts to cover individual features, rather than this type of epic post.
Steve Endow is a Microsoft MVP in
Los Angeles. He works with Dynamics GP, Dynamics 365 Business Central, SQL
Server, .NET, Microsoft Flow, and PowerApps.
Steve,
ReplyDeleteI don't know of anywhere on the Customer Card to set Parent/Child relationships, but this can be accomplished in a way on the actual transaction in the Shipping and Billing FastTab by toggling the "Bill-to" drop down to "Another Customer" and then selecting the "Parent" customer that should be invoiced for the "Child" invoice.
Very cool, thanks for the tip! I will check that out!
Delete