Customer & Supplier Object Types

What is a Customer?

A customer is any individual or organization that purchases from a business. That said, any individual or organization could potentially interact with a business in another capacity (e.g., as a supplier or employee). Because of this, ‘Customer’ is defined as a role, an organization, or an individual that interacts with a business.

However, businesses do not typically manage information about individuals and organizations in a shared model across vastly different business processes, like procurement (supplier) and sales (customer), for simplicity’s sake. To account for this, ‘Customer’ is used as a catch-all entity type that owns all information about individuals and organizations. For more about customer types, refer to details about contact persons below.

Note: If you split your data model into multiple entity types (i.e., individual customers versus organization customers), you must configure a separate Clerical Review Task List for each entity type.

Individual customer

For an individual customer, the typical customer attributes are:

  • First Name

  • Last Name

  • Addresses

  • Date of Birth

  • Gender

  • Phone Numbers

  • Fax numbers

  • Emails

  • Social Media IDs

  • Loyalty Card Information

  • Government IDs (social security, passport, driver's license)

Organization Customer

For an organizational customer, the typical customer attributes are:

Legal Name of the Organization

Date of Formation

Address

Contact Information

Main Phone

Fax

Main Email

Website URL

GLN / ILN

DUNS Number

Tax Identification Number

Risk Category

Organization customers are often organized in hierarchies. Refer to section about organization hierarchies below:

What is a Household?

A household is a collection of individuals, which is typically a family, living in the same home. Each member of the household is considered an individual customer.

The household construct helps businesses target customers that share a household either as a family unit or as individual customers. This allows the company to limit extraneous mailing campaigns and aggregate buying patterns.

In the Customer MDM initial configuration, Households are discovered by matching and created via Link Golden Records.

Accurately identifying the correct members of a household comes with natural limitations, as the definition of household is quite vague and varies from case to case. The data available to determine if specific people are accurately identified as part of the same household is often sparse.

Address and last name are the two most common matching criteria used to determine households. For more information, refer to the Algorithm & Match Codes - Household section of this documentation here.

This approach is intended for situations where accuracy must aim to be good but both false positives and false negatives can be accepted, such as with the case of analytics and mailing campaigns.

What is a Contact Person?

A contact person is a point of contact between two parties who conveys information or representation. Contact persons are modeled as a stand-alone entity type and must reference a customer or supplier. Contacts may use roles, for example, to designate the primary invoice contact.

Some typical attributes associated with contact persons are:

  • First and last name

  • Address

  • Email

  • Phone number

  • Job title

What is a Supplier?

A supplier is a person, business, or entity from which an enterprise purchases raw material, finished goods, or services. Such commodities are procured for the purpose of driving an enterprise’s business forward.

The terms ‘supplier’ and ‘vendor’ are often used interchangeably.

Suppliers are modeled as a stand-alone entity type within MDM. This allows the flexibility of distinguishing business processes and validations from individual or organization customer entity types.

Some typical attributes associated with suppliers are:

  • Legal Name of the Organization

  • Date of Formation

  • Address

  • Contact Information

  • Main Phone

  • Fax

  • Main Email

  • Website URL

  • DUNS Number

  • Tax Identification Number

Composite information for suppliers such as addresses, emails, and other contact information should be managed like customer object types.

Supplier GLN

A Global Location Number (GLN) is a global identification key developed according to the GS1 system of standards. The purpose of a GLN is to uniquely identify legal entities and locations around the world and it is used in the exchange of information within an organization’s supply chain. Key business benefits of a GLN include the communication of accurate information between suppliers and their trading partners, and the streamlining of supply chain management with increased operational efficiency.

In a Supplier MDM solution, as each supplier entity represents a legal entity and location, the GLN is modeled as an attribute on the supplier entity type. To ensure uniqueness of the GLN, Stibo Systems recommends configuring the GLN attribute as a STEP key. For more information, refer to the Unique Keys topic in the System Setup documentation here.

Supplier Onboarding with Self-Service

In a Supplier with Self-Service solution for a manufacturer, suppliers are initially onboarded by internal procurement managers within STEP. Additionally, external supplier users and supplier admin users are invited to access STEP through Web UI to further onboard new supplier entities and maintain existing supplier entities.

For an overview of the general data flow of this process, refer to Data Flow for Supplier Self-Service topic here.

Supplier products

In a self-service solution, introducing supplier product management requires a similar setup to a classification structure and product privilege links. A product must also have the relevant reference to a specific supplier entity. For example, a supplier's organization may have many distribution centers, however not all products are available at each distribution center.

The following diagram includes:

  • A supplier classification with classification sub folders to manage their own supplier entities and products.

  • References from supplier entities to the corresponding classification sub folders

  • References from products to the corresponding classification sub folder

  • Entity references from a product to a supplier

With this setup, each supplier entity within the organization can manage their own unique product offerings by restricting a supplier to view or modify only their own entities and products.

Supplier classifications

The supplier entities classification is a classification (aka ‘yellow folder’) node type within the STEP Workbench. Each supplier contains a strict relationship to a supplier classification, which ensures suppliers can only interact with objects associated with their unique classification structure. This structure, combined with references to the supplier entity, allows for privilege control between supplier users and supplier entities.

Privileges are set once for all suppliers, ensuring that a given supplier user cannot access data from other suppliers, as defined below:

  • Supplier user groups are associated to supplier classifications

  • In workbench, go to System Setting > Users & Groups > Web UI Settings flipper > set the 'Enable all-view for users that are a member of multiple suppliers' to 'Y' (refer to the Web UI Settings topic in the System Setup documentation here)

  • Through privileges, access is granted to the user group (refer to the Action Sets topic in the System Setup documentation here)

A supplier user can only access products, assets, and entities that are:

  • Linked to a supplier group where the user is a member

  • Not linked to any supplier group

In the example below, Clean Goods Manufacturer has been created as a self-service supplier.

The Clean Goods Manufacturer user group includes an administrator user and a supplier link to their classification.

Each classification in the structure includes references from the Clean Goods entities.

This allows the Clean Goods admin user to only have access to objects referenced to any of the super type (entities, products, assets) sub folders within the Clean Goods Manufacturer classification.

Within self-service solutions, it is likely that not every supplier will want to self-service. In this scenario, a 'No Self Service' supplier classification structure and business rules in workflows are used to govern objects that are not unintentionally left visible to all suppliers.

Supplier Self-Service privileges

In working with supplier entities in MDM, the management of privilege controls is paramount in ensuring supplier-specific data is governed and managed by the intended supplier users. To accomplish this, the Supplier entity type in STEP must contain a supplier privileges reference to a supplier entities classification.

When configuring privilege rules to support self-service, consider the following:

  • When should data be editable?

  • Who should be allowed to contribute to onboarding or data maintenance?

  • Is there an approval process?

  • What data should be displayed to the external users?

With the answers to these questions, consider the following common configurations:

  • Manage supplier entity onboarding and data maintenance through a workflow. This allows oversight of data enrichment as well as the ability to restrict who can change data and when. To accomplish this, use specific workflow privileges. Making the 'Modify' privileges available only when users are interacting with an entity currently in onboarding or maintenance. To access traceability of user edits for maintenance, use revision history by displaying a read-only details screen with a button configured to initialize into a workflow.

  • Allow data enrichment privileges only as needed. Not all users in an external supplier organization need, nor should be allowed, to contribute equally. Apply limited baseline privileges to the parent supplier group so all supplier users have a shared set of privileges. As certain users require additional privileges, configure other user groups to contain the varying added privileges. Link users into the additional groups for the cumulative set of privileges. For example, under the Users & Groups node, an external user added to the supplier admin group and the supplier user group acquires privileges from both groups. In this case, a supplier admin has the required privileges to create new supplier users for their organization as well as all supplier user privileges.

  • Grant approval privileges to only certain user roles. Allow a specialist user to provide a final review before fully onboarding a new supplier instead of giving all users approval privileges. When required, restrict user roles to only allow view / modify access on certain attributes. For example, a finance user can be allowed to view and edit tax code information but is not allowed to edit address information.

Supplier Onboarding with Accelerator for Retail

As retail organizations continue to mature in their MDM journey, the need for a true multidomain MDM solution continues to grow as the coupling between supplier onboarding, product information management, and product data syndication becomes more relevant. 

To facilitate this need, you can deploy the Supplier Onboarding Self-Service initial configuration in parallel with Accelerator for Retail and then integrate both with PDX.

In a Supplier Onboarding Self-Service solution with Accelerator for Retail, suppliers are initially onboarded by internal category managers, such as supplier accounts. In STEP, supplier accounts are modeled in a similar fashion as supplier classifications. 

As supplier accounts and supplier entities are onboarded, GLN information is modeled both as an attribute on the entity as well as a supplier location classification. The purpose of the location classification structure is to facilitate the integration with PDX. This process is only exposed to admin users. Users will continue to provide and maintain GLN information on the supplier entity.

For more information on Product Onboarding and PDX Invitation Flow, refer to the Accelerator for Retail Enablement Documentation here.

Handling Contact Information

Handling composite records with data containers

A customer record comprises multiple objects. It may have multiple addresses, emails, and phone numbers, which are all considered part of the record by users, as well as surrounding systems.

This is not to be confused with hierarchical structures of separate entities with each containing their own data flow.

Examples of separate entities may include:

  • contact persons for organization customers

  • store branches

  • warehouse locations

Such records are complex structures in themselves that may even reference or be referenced by other entities.

For more information, refer to the Data Containers topic in the System Setup documentation here.

Addresses

An address comprises several attributes that define a location. STEP offers specialized functionality around addresses, such as address verification via the Address Component Model.

Modeling addresses using data containers makes it possible to manage more than one address on the same customer / contact person. Data containers simplify the data modeling by providing a reusable address definition across multiple object types. When displayed in Web UI, addresses modeled using data containers can appear as one formatted value, despite being made of several attributes.

Addresses have metadata associated with them via the Address Component Model, the CASS address component model, and potentially solution specific meta data.

Email addresses and phone numbers

Email addresses and phone numbers should be modeled as data containers, as it is typical to have multiple phone numbers and email addresses for the same customer or contact person. It is also common to have meta data associated to each phone number or email address. The initial configurations have PhoneType as a Data container key. This allows a customer to only have one of each type of phone (cell, home, etc.).

Handling Confidential Information

Credit card information

Credit Card information should not be stored in or passed through STEP due to compliance requirements. It is simpler to store 'Recurring Charge Subscription IDs' when integrating to third-party services.

Bank account information

Handling bank account information does not typically require more security than name and address information.

Privileges

STEP Privileges to control who has access to what attributes and/or attribute groups.

Security

This guide does not cover information security in STEP in a broader sense, like infrastructure recommendations, encryption strategies, etc.

Note: The sample data provided in the initial configuration provides only main addresses. There are no delivery addresses.