Data Validation

Data validation in MDM is generally governed by data type definitions, workflows, business rules, and the Web UI. This provides a tight coupling of operational processes and data governance within the business.

The data validation in the Web UI functionality may be used to conduct data validations for specific business partner roles in the user interface. Complexities associated with multiple roles must be accommodated and the proper validations must be applied to the proper roles and to the proper users as the taxonomy presented is dictated by roles.

By using data validation in the Web UI, it is possible to enforce data validity constraints such as mandating contact persons to be referenced for each customer or supplier, or conditionally display, hide, or make mandatory attributes and references based on the role.

For example, while onboarding a new customer or supplier, data validation in the Web UI may conditionally hide the VAT Number attribute until the user inputs a main address that is in Europe or Australia. Once the Europe or Australia address is added, the Web UI displays the VAT Number attribute and makes it mandatory. This ensures regulatory compliance before users may navigate away from the screen

For more information on data validation in the Web UI, refer to the Data Validation in the Web UI topic in the Web User Interfaces documentation here.

Data Validation for Business Partner Roles

In the legal entity-based model, business partner roles must be validated, and the appropriate data types must be displayed to the end-user. 

The following fields are relevant for the business partner role entity:

  • ID – The STEP ID of the business partner role object. The ID should reflect the type of business partner role. There is only one business partner role entity for each role in the system.

  • Name – The STEP name of the business partner role.

  • Optional Data Types Attribute Group ID – STEP ID of the attribute group which contains all attributes, references, and data containers that are optional for the business partner role. This is for data validation and Web UI display purposes.

  • Mandatory Data Types Attribute Group ID – STEP ID of the attribute group which contains all attributes, references, and data containers that are mandatory for the business partner role. This is for data validation and Web UI display purposes.

A business rule should evaluate the type of business partner role and its corresponding optional and mandatory data types, and then conditionally display these attributes in a Web UI screen.

Alternatively, the Web UI screen tabs with role-specific attribution may also be conditionally displayed based on this logic.

Since different user personas are responsible for different states of a workflow, these patterns need to be replicated for each workflow state.

Data Validation for Interaction Roles

To provide the ability to enforce data validations for interaction roles, some metadata attributes are included to facilitate data validations.

The following fields are relevant for the interaction role entity:

  • ID – The STEP ID of the interaction role object. The ID should reflect the type of interaction role. There is only one interaction role entity of each type in the system.

  • Name – The STEP name of the interaction role.

  • Optional Data Types Attribute Group ID – STEP ID of the attribute group which contains all attributes, references, and data containers that are optional for the interaction role. This is for data validation purposes and Web UI display.

  • Mandatory Data Types Attribute Group ID – STEP ID of the attribute group which contains all attributes, references, and data containers that are mandatory for the interaction role. This is for data validation purposes and Web UI display.

  • Reference Type ID – STEP ID of the reference type that represents of this role. The source object of this reference type is the entity which assumes ownership of the interaction role. The target object of this reference type is the entity which receives the interaction role.

The above illustration shows:

  • The relationship between two interaction role entities which dictates  ‘Ship-to’ requirements, i.e., a ‘Payer.’

  • The interaction roles that entities A and B take on.

  • The relation between Entity A (the ‘Ship-to’) and Entity B (the ‘Payer’) as indicated by the ‘Payer’ reference type.

When assigning an interaction role to a business partner entity, the legality of the relationships must be enforced by business rules, as follows.

  • An entity requires a definition of what interaction roles are allowed and what interaction roles are required. All interaction role references for this entity must be validated against this definition.

    For example, the ‘Ship-to’ role entity requires a ‘Payer’ role entity. Therefore, since Entity A is a ‘Ship-to’ role it must contain a ‘Payer’ role reference as indicated on the ‘Payer’ role entity.

  • Validation that the target of an entity’s interaction role reference contains the interaction role that is required by the referencing entity.

    For example, the interaction role ‘Payer’ contains a Reference Type ID=Payer. Therefore, since Entity A is a ‘Ship-to’ with a Payer reference to Entity B, then Entity B must be a ‘Payer’ role.

For information on the data model recommendation for interaction roles, refer to the Interaction Role Data Model topic here.