With complex data models, it is important to enforce data validity to ensure high data accuracy, and to consider the differences between a data model and a process model. STEP offers various ways to build out a data model to support many business processes. This includes features surrounding business conditions to enforce certain data standards by setting desired attributes and references as either hidden, mandatory, or read only.
For more information, refer to the Data Validation in Web UI topic in the Web User Interfaces documentation here.
Business Conditions Use Cases
As demonstrated in the following use cases, while onboarding new supplier and customer data, procurement and sales managers may need to provide certain mandatory attributes and references, as well as adhere to certain regulatory conditions to maintain high data quality and compliance standards.
Onboarding Contacts with Mandatory Attributes and References
Otto, a procurement manager, is responsible for onboarding new contacts for suppliers. It is critical to ensure data quality surrounding this contact information to allow a quick point of contact, should issues arise. Currently, no safeguards exist, so Otto has fallen into the pattern of onboarding placeholder contacts and returning later to populate additional information. This leads to contacts being onboarded with poor data quality where critical contact info (e.g., first name and last name) may be incomplete or inaccurate.
To improve data quality and ensure critical information is available, certain stewardship conditions may be built into the Web UI. Making the address, email, and phone attributes mandatory ensures that contacts are onboarded with the required information and without filler data.
Additionally, Data Validation in the Web UI also encompasses mandating certain references to be enriched within a workflow.
Before Otto can submit the new contact for approval, he must also reference the new contact to a supplier entity. This ensures all contacts are associated with one or more suppliers and eliminates ‘orphaned’ contacts in the system.
In the configuration example below, the Mandatory JavaScript bind is used designate which attributes and references are mandatory.
The JavaScript in this business condition is:
mandatory.setMandatory(node, manager.getReferenceTypeHome().getReferenceTypeByID(contactRef));
mandatory.setMandatory(node, manager.getAttributeHome().getAttributeByID("FirstName"));
mandatory.setMandatory(node, manager.getAttributeHome().getAttributeByID("LastName")); In the Web UI, the first and last name attributes and the supplier reference are now required as indicated by the red asterisks.
Onboarding Customers with Conditional Hidden-Mandatory Attributes
Brianna is a sales manager for Acme Company and is responsible for managing relationships with new and existing B2B customers. A central part of Acme’s sales strategy is to conduct industry segmentation analysis. To do so, Acme requires that all customers with a revenue threshold of over one million dollars must provide industry classification codes (NAICS and SIC) as part of their onboarding with Acme Company.
Brianna requires that the onboarding workflow and Web UI is able to conditionally mandate that NAICS and SIC codes are provided before the user is able to submit the new supplier forward in the onboarding process. To accommodate this, Data Validation in the Web UI may be configured to enforce this conditional mandatory validity in an onboarding Web UI screen.
For suppliers, the Revenue Size attribute value determines the requirement for the NAICS Code and SIC Code attributes. This can be configured with the Hidden and Mandatory JavaScript binds.
The JavaScript in this business condition is:
var attrHome = manager.getAttributeHome();
//hidden
if (revenueSize < 1000000){
hidden.setHidden(node, attrHome.getAttributeByID("NAICSCode"));
hidden.setHidden(node, attrHome.getAttributeByID("SICCode"));
} else{
mandatory.setMandatory(node, attrHome.getAttributeByID("NAICSCode"));
mandatory.setMandatory(node, attrHome.getAttributeByID("SICCode"));
}
return(true); In the Web UI, when Revenue Size is greater than 1,000,000, the NAICS Code and SIC Code attributes are displayed and marked as mandatory. When Revenue Size is less than 1,000,000, the NAICS Code and SIC Code attributes are hidden.
Prevent Workflow State Submission if Potential Duplicates Exists
One of the initial steps in onboarding a new supplier or customer is to check if the new supplier or customer already exists in the MDM system. The standard recommendation for this check is the ‘Find Similar’ functionality which either provides an absolute match based on predetermined criteria or provides a list of potential duplicates. A ‘Not’ business condition may be used to prevent the submission of the onboarding task to the next workflow state if potential duplicates exist. This means that Otto (or another procurement user) must adjudicate the potential duplicates before the onboarding process can proceed, which ensures a high degree of data quality at entry into the system.
To prevent submission of tasks with potential duplicates, a ’Not’ condition plug-in is used. By specifying an algorithm for this condition, the rule prevents Otto from submitting the task if the specified algorithm indicates that potential duplicates exist.
The following prompt informs Otto if potential duplicates do exist.
For more information on this business condition, refer to the Business Condition: 'NOT' Condition topic in the Business Rules documentation here.
Enforcing Value Validity of Payment Terms and Invoice Schedule
Onboarding new customers involves not only providing important master data which identifies the customer uniquely, but also providing certain operational attributes which drive downstream business processes. For example, providing invoicing information allows the Finance team to properly invoice and set the appropriate commercial payment terms agreed upon with the new customer.
Since the list of payment term values can be lengthy, it is important to ensure that Brianna (or other sales users) can easily find and select the proper payment term for their onboarding task. In STEP, LOV Cross Validation may be used to validate the relevant list of values for payment terms against the invoice schedule attribute for the customer. For more information on LOV cross validation, refer to the Business Condition: LOV Cross-Validation topic in the Business Rules documentation here.
For example, if the invoice schedule for a new customer is monthly, only the payment terms related to monthly or 30 days should be displayed to Brianna for selection. The Payment Terms LOV includes more than 100 values for different invoice schedules.
The LOV Cross Validation business conditions reduces the values available for selection based on the Invoice Schedule value.
In the Web UI, when 'Monthly' is selected for the Invoice Schedule attribute, the Terms Of Payment values are filtered to only display monthly options.
Data Validity Considerations
When enforcing data validity, it is important to consider where and how it will be enforced. STEP offers various options to control data in the Web UI, including the use of workflows, privilege setups, and business condition validation. Workflows can be used to incorporate and manage complex business processes, such as supplier onboarding. Privilege setups can be used to govern role-based access, such as category managers and logistics specialists. Data validity can be enforced via business conditions in the Web UI to guide the user through the interface while managing the master data.
For more information on data validation in the Web UI, refer to the Data Validation in Web UI topic in the Web User Interfaces documentation here.