How do you model trade and internal relationships in #D365?

Picking up where we left off on the clean data entry post, I’d like to talk about how different companies model their customers and vendors in D365 Finance and Supply Chain Management. During the design phase you have to make a choice: what is the criteria you are going to use for setting up a record as a customer or vendor? There are a lot of different scenarios that come to mind. First, you have customers and vendors that have multiple locations or offices. Most of that can just be handled with different addresses, especially if they are only used for delivery purposes. This means we are already using two Party Ids from the Global address book, a customer or vendor Party, and an address Party. Addresses can even be assigned a Purpose if you want to segregate delivery addresses, remit-to addresses, home addresses, etc.

Sometimes you need to manage global suppliers and customers by individual accounts because they operate as independent businesses, except for the purpose of invoicing and payment. In those instances, you could model them as individual customer accounts for recording sales orders and quotations, and then have a single parent or global account that is setup and linked to each customer accounts as the Invoice account. This allows for a rollup at a single level for invoice purposes if that fits your business requirements. When the field is left blank on a customer or vendor, the invoice account that is used for transactions is the customer or vendor account captured on the transaction.

Taking it even further, many companies find that even this relationship is limited to how they need to report. And it takes them hours to manually consolidate which accounts they want to use just to report at certain hierarchies. You don’t cap your use of the system or hamper processes because D365 can only be filtered on certain data in “out of the box” reports or reports only accumulate at defined levels.  We can always get data into Power BI and slice, dice, intersect, sum, or do whatever you want with it. If you are not restricted by government or other regulatory controls and the reporting is for internal purposes, KPIs, and decision making, then look at other solutions for managing customer and vendor relationships and hierarchies. Remember, Party Ids are created for all major supply chain and customer related record hierarchies and internal groupings, and they have the following types:

Customers and vendors are organizations, contacts are Persons, Legal entities are your internal companies, and then you have your teams, and operating units. What this means is you may have a mix of customers and vendors, and the relationships may go vendor to vendor and customer to customer, but in different ways. If I’m in a government, education, or nonprofit company, I may need to model people, like parents and children, or beneficiaries. If I am in manufacturing, distribution, or retail, I may need to have customers and vendors as parent and children Organization parties. That may be the case if for example, I have customer account Ids for all of a particular fast food chain’s locations and they all report up to one global account. Relationships allow you to link Party Ids and build a hierarchy of relationships. There are several Relationship types defined out of the box that show what type of Parties are defined in the relationship and you can create your own Relationship types. For example, I will create a record called “3PL Warehouse” to link 3PL Warehouse companies to Vendor or Customer accounts who use them.

It is important to remember that relationships link parties for all roles, therefore it can add complexity or confusion if you have customers who are vendors and vendors who are customers, as those relationships are already handled by the Roles assigned to the Party Id. You do not want to create non-sensical circularity issues or overlaps to amplify your reporting struggles even further. From a configuration standpoint, it is like anything else, you need a good design and structure.

I am now going to link multiple vendor or customer records using my new relationship. You can assign relationships for existing parties via the Global address book by viewing the Party record.

Who in the Dynamics world is modeling their relationships this way and how are you reporting? I am starting to bring data into Power BI and build dashboards to slice/dice at this level, but have not spent enough time on it yet. However, I hope this shows the flexibility of options to meet multiple industry needs in managing trade and internal reporting hierarchies for companies investing in D365.