Today I attended day 4 of the Dynamics 365 Financials training class organized by Liberty Grove.
Here are links to my summaries of the prior days of the class:
Day 1 - Navigation, Company Setup, and Posting Groups
Day 2 - Dimensions, more Setup, and Financial Reporting
Day 3 - Payables and Inventory
Day 4 covered a lot of content and I found several items that I think are important to note, so this will be a long one.
And on a side note, I think I'm going to organize a contest to come up with some good abbreviations for the D365 products, since constantly typing out Dynamics 365 Financials gets old. And I'm obviously not the only one with this issue:
I may use D365Fin or D3Fin or maybe even D3F eventually, but for now I've setup a keyboard shortcut in my FastKeys app that will automatically replace "d3" with "D365 Financials" as I type it.
And with that, let's get started.
1. UI Updates.
As we worked through more exercises and were exposed to more windows and record types, I sensed the navigation in D365 Financials can sometimes get long, a little winding, and even circular. This is noticeable for me probably 90% due to the fact that the user interface and functionality is all new, making it seem more complex than it is. But I do think there are some valid navigation paths where you may want a compass and breadcrumbs to keep from getting lost.
I suspect that there are a few places in GP where drilling into inquiry windows and GoTo windows can have a similar result, but in GP, you usually hit a dead end after 3-4 windows.
Here is a small example of what I would consider a 'longer' D365 Financials navigation. There may be a more direct way to do this, but I believe this example actually came up during the class.
Let's say I'm currently logged in under the Accountant role. Notice the word "Accountant" above the company name.
Notice that the home page for this role doesn't list anything related to Inventory or Items. So I need to search for Items. Easy enough.
Once you open an Inventory Item, click on the Navigate "ribbon group" -> Entries -> Ledger Entries.
You can then select an Item Ledger Entry and click Navigate.
You are then presented with a list of "Related Entries".
You can then click on the G/L Entry row and click on Show Related Entries in the ribbon, which takes you to GL Entries for account 50100 Cost of Materials.
From the GP user perspective, this is quite a bit of drilling around to see a GL entry. As always, there are likely one or two completely different paths that may be shorter, but I think this is an interesting demonstration of the different terms used by D365 Financials navigation and how it may seem more complex to a GP user who first encounters the software.
But wait! If you want to entertain yourself, you can click on the Navigate button again. Which brings you to right back to Document PS-CR104001. Where you can click on G/L Entry again! Then click on Show Related Entries again! Which takes you to the GL Entries yet again! It's an interesting user interface where it seems you can go in an infinite loop of Navigation and Related Entities.
Seriously though, it's great to have the ability to drill into and through records and activity, but from a GP user perspective, the amount of information available through the navigation will likely be a bit confusing and overwhelming at first.
And if you were to throw in a really tight security policy, I suppose that could complicate things. Suppose my role let me navigate half way through this process, but then prevented me from seeing some windows. I might call IT or my D365 Financials partner and ask "Why can't I see X?" That scenario might be tedious to figure out.
2. Cool Lookups. I officially dub this feature: "Cool Lookups"
I think this is a great feature of D365 Financials. It will take some initial setup to populate the lookup tables, but hopefully it is possible to create lists of valid data (USPS zip code lists?) that can be imported.
Let's say that you're entering a customer. Instead of having to type in the city, state, and zip, what if you skipped entering the city and state, and were to just type the first 2 or 3 numbers of the zip code? Like, say, "606".
A window appears showing you a list of valid zip codes for Chicago IL. And when you select the zip code, the City, State, and Zip code fields are populated.
Boom. Mic drop.
Those in the GP world should be familiar with Rockton SmartFill. This is kinda-sorta similar, but D365 Financials kicks it up a notch by making both City and Zip code lookup fields, and then having the user selection populate all three fields: City, State, and Zip.
You can do the same with the City field, where you are presented with a list of Zip codes in that city.
I think this is a great feature--it makes address data entry faster and more accurate.
3. Master records and Contact records. The concept of D365 Financials master records and related contact records makes sense in theory, but in practice, setting up contact records correctly is confusing at first, and somewhat tedious and cumbersome. I, and a few other students, got tripped up on this feature, so it's worth spending some time making sure you understand how D365 Financials behaves when you assign a Contact to a master record.
Let's start by discussing how Dynamics GP stores master records and contact records. In GP, you have a Customer record, and then you have a 'main' Address IDs associated with the customer record. The address ID consists of an alpha ID, such as the word PRIMARY, and contact info, such as contact name, address, phone, etc. The main address ID, or different address Customer Address IDs can be designated as the Primary Ship To, Bill To, and Statement addresses.
The object model would look something like this.
D365 Financials has a different model.
A Customer record has an address, but it does not appear to be a separate object or record--the address is just the main customer address--fields for the Customer record.
You then create a Company Contact record type that is associated with the Customer. Once you have a Company Contact setup for the Customer, you then create Person Contact records that are children of the Company Contact record. I believe the object model looks something like this.
While I think I understand this object model, I don't have enough experience with D365 Financials to know how it works or is really used in practice. For example, what is the value of having separate Company and Person contact types associated with a customer? Are those contact types used in different ways throughout the system? Are there specific benefits of separate Person contacts, instead of just having a "Contact" name field on an address ID?
I could see the potential benefit if D365 Financials eventually gets a Common Data Model with D365 CRM--this model might be a better fit for sharing data between those two systems. But I don't know how CRM stores such records, so I don't know if such a benefit exists.
For now, I'll just note that the D365 Financials design is different than GP, and that you'll want to be aware of that difference.
In terms of creating the Contact records, that is a bit confusing for new users. When you create a new customer in D365 Financials, you'll get to the Primary Contact Code. You'll want to be careful at this point.
You'll click on the ellipsis button and a Contact List lookup window will appear.
Note that a new Contact number will be displayed in this lookup window, and that the Contact Number is in bold text. This is a key distinction.
When you create a new Customer record and click on the Primary Contact Code lookup button, D365 Financials automatically creates a Company Contact record, and Company Contacts will show up in bold text. But, by default, the Company Contact record is completely empty. Even though you just entered the company address on the Customer window, this new Company Contact record is blank. Nothing is copied to the Company Contact. Hopefully a future version will let you copy or default the values from the Customer record.
Because the Company Contact record is blank, you'll want to first edit it to enter the customer address information. So you will click on the Edit button in the ribbon. This is where I got confused.
It assigns a Contact Card number to the record, and you see that value in both the "No." field and the "Company No." field.
Wait a minute, didn't we already have a Customer Number of C00070 assigned to our customer? Why is this Contact Card saying the Company Number is CT000044?
Well, look back at my diagram of the D365 Financials Customer object model. Note that a Customer is different than a Company Contact. Those are two different objects.
So I now have to re-enter the Customer address & contact information on the Company Contact card. A Copy button on this window would be nice.
Now that I have my CT000044 Company Contact record setup, I can close the contact card and return to the Contact List lookup window.
Notice that the bold Company Contact record now displays the customer information. You can now click on OK to assign that Company Contact record to the Customer.
But notice that right below Primary Contact Code, there is a Contact Name field. That Contact Name field is a link to a Person Contact record. If I click on the lookup button next to the Contact Name field, I get the same Contact List window.
Since I only have one record listed, and it's a bold Company Contact, I now have to create a Person Contact record. So I make sure that the Company Contact record is selected, then click on the New button.
Wait, that's not right. Hmmm, that just creates a new Company Contact record. Let me pull up my notes from class. Ah, yes, I see that there is a 7 step process for creating a Person Contact that is associated with a Company Contact that is associated with a Customer. Hey, only 7 steps! I don't think it's just me--I think this process could be simplified.
So, getting back on track, to create a Person Contact, you actually have to edit the existing Company Contact. So from the Contact List lookup window, you highlight the Company Contact record and click on Edit.
Once I'm editing the Company Contact record, I need to click on Navigate, then click on Related Contacts. Pretty obvious, right?
Now I get a Contact List window that looks pretty much exactly the same as the Contact List window I just came from. But apparently it's different. Somehow. I can't tell how, but just trust me.
Now that you are in this Contact List window, NOW you can click on the New button. Yes, I promise. When the new Contact window opens and you tab past the No field, a new Contact Number will be populated, and the Company No field will be filled with the "parent" Company Contact number value. If this is a bit confusing, you are not alone. It took me at least 3 tries to understand this process, and even then, I just got it wrong and had to review my notes.
The key fields to watch here are No, Type, and Company No. The Company No field value must automatically populate with the Company Contact number value, and the Type here should be person. If the values are different, you've done something wrong.
And notice that finally, an address is populated automatically for the Person Contact record. Small victories. Once you are done with the Person Contact, you can close that window and you'll see the new Person Contact under the Company Contact.
That's great, but remember you are still a few windows deep in the UI and need to crawl back to your Customer record so that you can actually assign your Person Contact record to your Customer.
So you then close the Related Contacts list, which takes you back to the Company Contact window, which you then close. This takes you back to an identical looking Contact List, which will now show your Person Contact, which you can then select, and click OK.
You'll know you're getting close when you see the Customer record and Contact Name field behind your Contact List.
So after all of that work, you have finally populated the second Contact field with a name.
This seems a bit overwrought just for a Contact Name, so I'm hoping that there is some simpler process for this.
I'm okay with the concept of the D365 Financials customer / contact object model, but unless I'm missing something, I am not a fan of how a Customer and the associated Contact records are entered. It seems too cumbersome, and I would guess that a majority of the Contact records could simply be copied based on the data on the Customer record. In the GP world, I don't see too many customers really utilizing the separate Company Contact and multiple Person Contacts for a customer, so I'm interested in learning more about how these records are used elsewhere in D365 Financials.
Lots of Other Items to Discuss
There are several other things I'd like to cover, but since this post is so long, I'm going to end Day 4 here and will write separate posts for the other D365 Financials topics I'd like to cover.
I hope you found this post interesting, educational, or useful.