Retailers can configure their Accelerator for Retail system so that when PDX users who are onboarding products select a specific value for one List of Values (LOV) attribute, the options available to them in a different LOV attribute will be pre-filtered, presenting the user with a retailer-configured subset of LOV values from which to select. This can be done by configuring a product data validation with an LOV cross-validation condition.
As an example, an LOV attribute named ‘Country’ is a product attribute a supplier can enrich in PDX. From the LOV dropdown, the user has selected the value ‘Germany’, as shown in the screenshot below.
Because the LOV cross-validation has been implemented, when the PDX user selects ‘Germany’, the LOV options available in the LOV attribute ‘Region’ will display only German regions.
This pre-filtering is controlled via the ‘PDX: LOV Filter Attribute’ metadata attribute, which is found on the attribute definition.
The ‘PDX: LOV Filter Attribute’ metadata attribute is used to enable the connection between the two relevant LOV-based attributes. For the dependent attribute, which is the LOV-based attribute whose values will be filtered, the value assigned to ‘PDX: LOV Filter Attribute’ should be the ID of the defining attribute, which is the LOV-based attribute that determines the valid values. To continue the example described above, the dependent attribute ‘Region’ would have ‘PDX: LOV Filter Attribute’ populated with the value ‘Country’.
Additional capabilities and considerations for LOV Cross Validation
The ValueIDs for the two LOVs configured for LOV Cross-Validation must also satisfy additional requirements for the cross-validation to work.
-
The ValueIDs of the dependent LOV values, the values being filtered, must be prepended with the value ID of the defining LOV for the cross-validation to work properly.
To illustrate using the example described previously, the LOV attribute ‘Country’ includes an LOV value 'Germany' with the ValueID 'germany’. To restrict the region options available in the LOV attribute ‘Regions' to only German regions when ‘Germany’ is selected, the ValueID for the German region ‘Mosel' must begin with the ValueID for 'Germany’, which is ‘germany’'. Using this logic, a possible ValueID for ‘Mosel’ could be ‘germany_mosel'.
-
The LOV cross-validation allows for multiple layers of dependent attributes, not just two.
To expand upon the previous example, let us say the retailer wants to include a second dependent LOV attribute, in this case ‘City’, to the cross-validation. In this scenario, the ‘PDX: LOV Filter Attribute’ for ‘City’ must be set to ‘Region’. A supplier would first select ‘Germany’ for ‘Country’, then ‘Mosel’ for ‘Region, and then, for the ‘City’ LOV attribute, only retailer-relevant German cities in the selected region should be available for the supplier to select. So, if an LOV value from the LOV ‘City’ is to be a selectable value when the user selects ‘Mosel', the ValueID for the valid city, in this case 'Koblenz’, will need to have both of its defining LOV values prepended to its ValueID. Using this logic, a possible ValueID for 'Koblenz' could be 'germany_mosel_koblenz'.