Supplier Data Definition Tab

The Supplier Data Definition tab within the PDX Onboarding Channel Configurator offers multiple parameters that define data properties provided by suppliers through PDX. These properties relate to products, packaging products, and assets.

Within the General canvas of the tab, users can find the following parameters:

  • Product Object Type: This parameter enables users to configure the product object type utilized for exchanging product data between PDX and PMDM. Users can select the desired object type by clicking on the adjacent node picker icon.

  • Product Hierarchy Root: This parameter permits users to select the top root folder of the product hierarchy, which will subsequently become the PDX category root. Users can find and select the product root folder by clicking on the node picker icon located next to the parameter.

  • Attribute Groups: This parameter allows users to configure an attribute group that stores all vendor-facing product attributes. This attribute group can have multiple child attribute groups. Users can find and select the appropriate attribute group by clicking on the node picker icon located next to the parameter. Vendor users can view all the attributes in the group, grouped by sub-groups in PDX UI channel view, and can edit them unless attributes are defined otherwise. Users can add multiple attribute groups by clicking on the Add link provided below the parameter field.

  • Hidden Groups: This parameter enables users to configure an attribute group that contains the attributes to be excluded from vendors. This makes it possible to create vendor facing attribute groups (used in the Attribute Groups parameter), that have exception attributes that need to be hidden from vendors.

Note: Supplier facing attributes must have attribute IDs containing only alphanumeric characters and: '-', '_', '#', ':', ' ' and '/'. If the channel is configured with multiple languages, attributes that have Language set as dimension dependency can have values that vary by language in PDX. Similarly, if the channel is configured with multiple market, attributes that have the market dimension set as dimension dependency can have values that vary by market in PDX

Assets

The parameters available within this canvas are relevant if the PDX channel should support the submission of assets.

Once the asset functionality is activated, users can perform the following configurations in STEP:

  • Specify the asset attributes that will be available to vendors. This is achieved via a configuration on the asset references in STEP.

  • Determine the mandatory assets

  • Define the structure of Asset Object Types and Asset Reference Types that vendors will be able to create via the channel.

  • Control how assets are sent from PDX to STEP

The relevant parameters are:

  • Asset Import Configuration: This parameter allows users to configure the import configurations that will be used when importing assets. Click the node picker icon next to the parameter to find and select the import configuration. If the parameters 'Asset URL attribute' or 'Asset Content Hash' are used, then it is expected that some custom business rules are added to this import configuration.

  • Asset Import Folder Path: This field is to be configured with a file folder available on the STEP application server that is designated for the upload of Asset STEPXML files and optional binary assets submitted by PDX. The upload folder for product files is distinct and separate from this folder.

    Note: This folder needs to be the same as the configuration set in the 'The Standalone.JVMArgs' property of the Tagglo component, which is located in the 'sharedconfig.properties' file under the 'Tagglo.UploadDir.ASSET' section.

    The below business rule can be used to check the status of both the upload folders.

  • Supplier Assets Classification Object Type: This parameter is to be configured with an object type of the classification folder that is used to store assets for a supplier. To link assets to the Alternate Classification , the Reference Type must be configured in the 'Asset Reference Type Map' parameter as described below.

  • Asset Relevance: To determine which asset attributes are to be displayed on products in PDX, this parameter must be set with a metadata attribute that is valid for the asset reference. The attribute should be LOV-based and have the following values:

  • ‘Yes' (ValueID ‘Y') which directs the system to display assets of that type on the product.

  • ‘Primary', (ValueID ‘Primary') which directs the system to display an asset of that reference type as the primary image.

  • ‘No' (ValueID 'N') to indicate that the asset reference is not relevant for suppliers and will not be displayed in PDX.

  • Within the STEP system , the attribute value is maintained on the asset reference types.

If the attribute configured in this parameter is left blank, then the system assumes the value as ‘No'.

Note: To set up which image is displayed for products in the 'List' and 'Grid' views on the Product Summary page in PDX, it is essential to ensure that only one asset reference type has the 'Asset Relevance' attribute set to 'Primary'. This is because the asset reference with this setting will be used to provide the image asset that displays as the 'Primary Image' in PDX. If more than one asset reference type has the 'Asset Relevance' attribute set to 'Primary,' the system will randomly choose one to display as the Primary Image in PDX.

  • Maximum Number of References: This parameter is to be configured with a metadata attribute that can restrict the number of references allowed on a product for a given asset reference type by setting a maximum on the asset reference type.

    In the example below the ‘PDX: Maximum Number of References' attribute has been configured in the 'Maximum Number of References' parameter. The admin user has then set this maximum to ‘8' on a vendor facing asset reference in STEP. This pre-set maximum will then be enforced in PDX. In practice, this means that a retailer can decide, for instance, that they want the supplier to provide no more than eight Product Images per submitted product, and the system enforcement means suppliers must abide by this setting. Products that do not satisfy this rule cannot be submitted and the corresponding asset attribute will be marked with a red error.

  • Category Mandatory References Attribute: This parameter is to be configured with a attribute where the category-specific asset references that must be mandatory for users in PDX are controlled. This attribute is valid on the product category node itself. The attribute configured in this parameter should allow for multiple values and must contain the list of mandatory references on that category.

    The attribute should be LOV based with these valid values:

    • LOV Value = asset reference name

    • LOV Value ID = asset reference ID

    As an example, a retailer has chosen the 'PDX: Mandatory References' attribute as the Category Mandatory References Attribute. In addition, the retailer has decided that both 'Primary Product Image' and 'Product Images' asset references should be mandatory for suppliers in PDX in the 'Clothing' category. To implement this, the retailer has added both references to the 'PDX: Mandatory References' attribute on the 'Clothing' product category node, as depicted in the screenshot below.

  • Asset Reference Type Map: The ability to create a table within this parameter allows users to map Product To Asset Reference with the Asset Object Type. The parameter determines the Asset Object Type that PDX will use when a product with assets is submitted.

    The first row in the example below defines that if an asset is added to the ‘Primary Product Image' asset attribute on a product in PDX, the asset will be submitted to STEP as an asset of type 'Product Image.' Similarly with the next three rows.

    The last row defines that if an asset is added to an asset attribute on a product in PDX, and if that asset attribute is not one of ‘Primary Product Image', ‘Documents', ‘Product Video', or ‘Certificate', then the asset will be submitted to STEP as an asset of type 'Product Image.'

    As there can only be one default Asset Object Type, only one row with a blank Product To Asset Reference value is allowed.

  • Asset File Name: This mandatory field is to be defined with an attribute belonging to an asset. It is used to configure the attribute carrying the original file name of the asset.

  • Asset URL attribute: This optional field is to be defined with an attribute belonging to an asset. It is used to configure the attribute carrying the PDX URL of the asset. The attribute chosen for this field must be valid for all vendor-facing assets.

    If left empty, the assets will be uploaded to STEP as binary asset files. However, if populated with a valid attribute, PDX will upload an asset XML file containing the asset URL. Then STEP can download the asset file.

    The assets are hosted on the domain https://cdn.pdx.stibosystems.com/, which may have to be whitelisted for the download from STEP to be possible.

    To ensure the smooth functioning of this solution, it is recommended to download the asset as part of the asset import using a simple business action. The validity of asset URLs cannot be assumed indefinitely. PDX guarantees the URL validity for a minimum of 7 days, after which the URL may expire. Additionally, the URL may vary between submissions and over time.

  • Asset Content Hash: This optional field is to be defined with an attribute that is used to carry Asset Hash information and is intended to be used in combination with the Asset URL attribute. The attribute must be valid for all vendor-facing assets.

    When this field is populated, the PDX will add an image hash as the value in the configured attribute sent to STEP. On the STEP side, this can be used in a business rule run by the asset importer to decide if this asset is already present in STEP and therefore does not need to be downloaded and imported again.

Asset Reference Metadata

By default, assets are in PDX treated as regular product attributes with binary asset content.

Therefore, suppliers can onboard different asset types referenced by the corresponding products using different asset reference types as defined by the Asset Reference Type Map.

The following option makes it possible to also onboard asset reference metadata, i.e., to onboard different asset types referenced by the corresponding products using different asset reference types (including some asset reference metadata) as defined by the Asset Reference Type Map.

  • Asset Reference Metadata Group: This optional field can be configured with an attribute group that includes all vendor-facing asset reference metadata. When this field is populated, all assets in PDX expect the primary one (This is optional, see the Asset Relevance field above) will be considered composites. Each composite will contain an asset attribute, and the attributes from this attribute group will provide additional columns to the composite. If this field is not populated, vendor-facing assets will be considered regular standalone asset attributes in PDX. PDX does not support asset reference metadata that can vary by language or market.

Asset Validation Object

The parameters available within this canvas can be used to configure a range of asset validations. These are basically the rules that assets must satisfy before they can be submitted to STEP.

For retailers with specific requirements for supplier-delivered assets linked to submitted products, PMDM supports the ability to validate assets in the PDX Channel. For instance, if a retailer requires product-linked image assets to be .jpg files, a validation can be applied in the parameters available within this canvas which ensures that image asset files submitted via PDX will be .jpgs.

Note: The asset validations are tied to the Asset Type in STEP, not the Asset Reference Type.

Described below is a list of asset validations that may be applied in STEP and enforced in PDX.

  • MIME type – By applying a MIME type limitation, retailers can restrict submitted assets to only those with the desired MIME types. For instance, if a retailer wants all instruction manuals associated with the submitted product to be of the .pdf MIME type, the validation applied in the configured product data validation would be ‘application/pdf'. This validation is applied directly on the object type, found under ‘Object Types & Structures' on the ‘System Setup' tab in the workbench. In the example shown in the screenshot below, the object type is 'ProductImage'. In this case, the admin has determined that if images submitted for products are not of the MIME types listed in the 'MIME Types' field, the product cannot be submitted. If possible, PDX will automatically convert the file to one of the valid file formats.

    For more information on MIME types, refer to the MIME Types topic in the System Setup documentation.

In order to use the validations below a dedicated entity type ‘Asset Validation Object' with some special attributes, needs to be setup.

Asset validation objects are created to define specific asset validation rules on specific assets in PDX. The validations display like this on the asset validation object in STEP:

Each Asset validation object is tied to the asset object types that the validations should apply to via a dedicated attribute.

Listed below are the various validation settings that can be applied on the asset validation object, accompanied with a description of each:

  • Aspect Ratio – Allows retailers to specify the aspect ratio (the ratio of an image's width to its height) of the product-linked images submitted by suppliers via PDX. Select from the options available in the dropdown: 1:1, 2:33, 1:1, 2:3, 3:4, 16:9 and 16:10. If the submitted image does not conform to the specified aspect ratio, the product submission will be rejected, and an explanatory error message will display.

  • Maximum File Size (Bytes) -- A product-linked image submitted via PDX cannot have a larger file size than the number of bytes set for this parameter.

  • Asset dimension (in pixels) -- The size, in pixels, of product-linked image assets submitted by suppliers via PDX can be strictly controlled by setting a series of attributes on the asset reference type definition. Below is a list of these settings along with a description of the image aspect they control:

    • Maximum Pixel Height – The image height of submitted images can be no greater than the number (in pixels) set in this parameter.

    • Maximum Pixel Width – The image width of submitted images can be no greater than the number (in pixels) set in this parameter.

    • Minimum Pixel Height – The image height of submitted images can be no less than the number (in pixels) set in this parameter.

    • Minimum Pixels (Longest Side) -- The image width or height of submitted images, whichever is greater, can be no less than the number (in pixels) set in this parameter.

    • Minimum Pixel Width – The image width of submitted images can be no less than the number (in pixels) set in this parameter.

If an asset does not satisfy one of these configured rules, the corresponding product cannot be submitted and the asset will be marked with a red error, as shown in the screenshot below:

There are two exceptions for the asset not satisfying the configured rules:.

  1. Maximum Pixel Height and Maximum Pixel Width validation errors: Instead of blocking the submission, PDX will, if possible, automatically downscale supported image assets to an appropriate size.

  2. MIME type validation errors: If possible, PDX will automatically convert the file to one of the valid file formats defined by the MIME type limitations. PDX supports converting images from the any of the source formats: JPEG, PNG, WebP, GIF, AVIF, TIFF, or SVG to any of the valid target formats PNG, JPG, or GIF. If multiple valid file formats are configured, PDX will prioritize PNG over JPG and will prioritize JPG over GIF when selecting the output file format.

Additional information about the various settings that are needed on the asset validation object are described below:

  • Asset Validation Object Type: This parameter is to be configured with an entity object type. This object type must be the object type used to store asset validation object.

  • Asset Object Types: This parameter is to be configured with an attribute. The values of the selected attribute are the asset object types this asset validation object is relevant for. The attribute must be valid for the Asset Validation Object Type and should be a Multi-valued Lists of Values (LOV) of asset object types.

  • Valid Color Spaces: This parameter is to be configured with an attribute that contains the color spaces that a digital asset of this type must have. The attribute must be valid for the Asset Validation Object Type and should be a Multivalued LOV of color spaces. The valid options are:

  • Bitmap

  • CMYK color

  • Grayscale

  • Indexed color

  • RGB color

  • Minimum Pixel Width: This parameter is to be configured with an attribute where the values of the selected attribute contains the minimally required pixel width that a digital asset of this type must have. The attribute must be valid for the Asset Validation Object Type and should be of type integer.

  • Minimum Pixel Height: This parameter is to be configured with an attribute where the values of the selected attribute contains the minimally required pixel height that a digital asset of this type must have. The attribute must be valid for the Asset Validation Object Type and should be of type integer.

  • Minimum Pixels (Longest Side): This optional parameter is to be configured with an Entity attribute that defines the minimum pixel size of the longest side of the asset, i.e., the minimum pixel size of at least one of the asset edges.

  • Maximum Pixel Width: This parameter is to be configured with an attribute where the values of the selected attribute contains the maximum allowed pixel width that a digital asset of this type may have. The attribute must be valid for the Asset Validation Object Type and should be of type integer.

  • Maximum Pixel Height: This parameter is to be configured with an attribute where the values of the selected attribute contains the maximum allowed pixel height that a digital asset of this type may have. The attribute must be valid for the Asset Validation Object Type and should be of type integer.

  • Maximum File Size Bytes: This parameter is to be configured with an attribute where the values of the selected attribute contains the maximum allowed file size a digital asset of this type may have. The attribute must the valid for the Asset Validation Object Type and should be of type integer.

  • Aspect Ratio: This parameter is to be configured with an attribute where the values of the selected attribute contains the aspect ratios that a digital asset of this type must have. The attribute must the valid for the Asset Validation Object Type and should be a Multivalued LOV of aspect ratios.

Families

The parameters available within this canvas are mainly in relevance to the setup of family and variant related functionality.

Products in PDX can be grouped into product families that may include product variants. When those product variants are sent to STEP, they arrive tagged with a unique identifying attribute called a ‘Family ID'. The value for this attribute, which is assigned to each variant product, enables users to recognize that these variants belong to the same product family in STEP.

Family attributes: Family attributes in PDX enable a structure through which an attribute on a product on the family level, defined as one level above the sellable products, can have a specific value that filters down to the products nested beneath that product. This helps ensure data consistency throughout the products in that family. When an attribute is defined as being a "family" attribute, validations in PDX are automatically applied that prevents users from submitting products for which the family attribute values differ between other products in that family. When a user submits a single product contained inside of a family, the PDX system automatically submits all products in that family. In this way, all products in the family are validated and submitted to STEP at the same time. To configure an attribute as being a ‘family attribute', a Family Indicator Attribute must be set to 'Yes' on the attribute link between the product category and the desired attribute.

Variant Attributes: When product families are used, it is possible to define certain attributes as being variant attributes. When attributes are defined as variant attributes, validations in PDX are automatically applied that ensure that any combination of values assigned to a given variant product must be unique within the family. To define an attribute as a variant attribute for a specific section of the product hierarchy in PDX, the metadata attribute ‘Variant Indicator' must be given a value: An integer must be assigned for that metadata attribute.

The following parameters are available within this canvas:

  • Variant Indicator Attribute: This parameter is to be configured with an attribute. The content should be a meta data attribute on the attribute to products category link determining if an attribute is a Variant attribute. An attribute becomes a variant attribute if an integer has been assigned for that metadata attribute.

  • Family Indicator Attribute: This parameter is to be configured with an attribute. The content should be a meta data attribute on the attribute to products category link determining if an attribute is a Family attribute. An attribute becomes a family attribute if the value 'Yes' is assigned for that metadata attribute. The attribute should be LOV based with allowed values 'No' (Value ID=N) and 'Yes' (Value ID=Y).

  • Family ID Attribute: This parameter is to be configured with an attribute which will be used to store the PDX family identifier and can be used to group products into families in STEP.

  • Family Object Type: This optional field is to be configured with a product object type that defines the STEP Family object type. If configured, this product object type will be used to create a classical 2 level parent / family-child / variant structure whenever a family is submitted from PDX to STEP rather than a flat structure. However, if not used, it is expected that all vendor facing attributes (regular, family, and variant) are valid on the Product Object Type.

    If this option is used it is expected that all family attributes are valid for the STEP Family object type and regular and variant are valid on the Product Object Type

Packaging

The parameters available within this canvas are mainly relevant to the setup of packaging, which covers the ability to structure and manage packaging information in PDX.

Packaging objects (‘Pallet', ‘Case', ‘Pack') are created as separate objects directly below a dedicated ‘PackagingRoot' node in STEP.

References connect each packaging object to the next lower-level packaging object and from the lowest level to the sellable product (the Product Object Type).

The quantity in each packaging object is held in the 'Qty of Next Lower Package' metadata attribute found on the packaging reference.

The following parameters are available within this canvas:

  • Packaging Attribute Group: This parameter is to be configured with an attribute group that contains all Vendor Facing Packaging Attributes across all levels.

  • PackagingRoot: The field defines the root node in the Primary Product Hierarchy where all packaging objects are created when submitted from PDX.

  • Packaging References Attribute Group: This parameter contains an attribute group. This configuration controls which attribute group the packaging references in PDX are visualized below.

  • Packaging Type Attribute: This parameter contains an attribute that is used in PDX to identify the packaging type of the PDX product. The attribute should be a LOV with a value for each relevant packaging level. For example, ‘Pallet', ‘Case', ‘Pack', and ‘Each.' PDX supports up to 4 levels in a packaging hierarchy

  • Next Lower Package Quantity: This parameter contains an attribute and identities the 'Qty of Next Lower Package' metadata attribute. The metadata attribute must be valid for all packaging references.

Packaging Object Types

The parameters available within this canvas are relevant to the setup of the packaging hierarchy. This parameter contains up to 4 entries, one for each relevant packaging level. For each packaging level the following must be configured:

  • Packaging product object type

  • ValueID of the relevant entry in the LOV for the Packaging Type Attribute selected above

  • Packaging reference that point to the next lower level (not relevant for level 1)

Only the levels taken into use need to be filled out, i.e., one of the following:

  • Level 1 and level 2

  • Level 1 and level 2 and Level 3

  • Level 1 and level 2 and Level 3 and Level 4

Below is an example of the configuration of a 4 level packaging hierarchy:

In this example above it is assumed that the Packaging Type Attribute parameter is configured with an attribute with this packaging type LOV:

  • Value: 'Pallet', ValueID: PAL

  • Value: ‘Case', ValueID: CS

  • Value: ‘Pack', ValueID: PAK

  • Value: ‘Each', ValueID: EA

Data Containers

Data container types in STEP are available in PDX as single- or multi-valued 'composites,' which is the term used in PDX to describe data container-analogous objects. To display a composite in PDX, the data container type and the supplier-relevant attributes within the data container must be linked in STEP to one of the PDX-relevant attribute groups configured via the fields 'Attribute Groups' or 'Packaging Attribute Group.'

To illustrate the different ways data containers and composites display in their respective systems (STEP and PDX), this section will outline, via screenshots, how two sample data containers, 'Product Ratings' and 'Product Reviews,' will display. In the screenshot below are the two sample data containers.

If a data container is linked to any of the three PDX-relevant attribute groups and is valid for the PDX facing object types, the data container will display on a product in PDX as a composite, as shown in the screenshot below:

When a PDX user clicks on the ‘Product Reviews’ composite’s details, the data container attributes and their values display in PDX as shown in the screenshot below:

For reference, the same data containers, when linked to a product submitted to STEP, display as shown in the screenshot below:

To ensure proper display of data containers as composites in PDX, it is helpful to know some additional aspects of the functionality beyond what is described above. What follows is additional information relevant to admins working to configure data containers in STEP to achieve the desired results in PDX:

  • Only data containers and data container attributes linked to one of the PDX-facing attribute group fields will be available in PDX.

  • Data container types that need to be available in PDX must have an ID Pattern with the auto-generated data container ID defined.

  • Both single-valued and multi-valued data containers are supported.

  • PDX composites support the ability to embed a composite within a composite, creating a two-level composite. STEP's comparable data container functionality does not support (nor necessitate) a multi-level structure. Because of this difference, only one-level composites are supported by this solution.

  • Text added to the Help Text metadata attribute on the data container will display in PDX on the associated composite for suppliers (refer to the PDX Presentation Tab topic for more information).

Data containers and data container attributes linked to the 'Mandatory For Submit' attribute group will be mandatory in PDX.

Data containers linked to the 'Locked After Initiate' attribute group will not be editable in PDX after the initial submission, even if the product is in an editable state.

Refer to the PDX Rules Tab topic for more information on the 'Mandatory For Submit' and 'Locked After Initiate' attribute groups.

  • There is no support for category-specific data containers. Because PDX does not support STEP's 'Validity restricted to hierarchies' setting on the 'Restriction' attribute on the data container type, this setting must be set to 'None' to ensure data container information is properly displayed in PDX.

  • Data containers and data container attributes can be sorted in PDX using the 'Display Sequence' metadata attribute on data container types and attribute definitions. Refer to the PDX Presentation Tab topic for more information.

  • If a data container type does not have a data container key defined, all data container instances of that data container type (that are also included in one of the three PDX-facing attribute nodes) will be overwritten by the data container instances included in the submission. For example, if data container ‘Product Reviews' does not have a data container key configured, and ‘Product Reviews' was held in one of the three PDX-facing attribute nodes, all instances of the 'Product Reviews' data container on the product with the ID '1234' will be overwritten each time the '1234' product is submitted from PDX.

    For more information on data container keys, refer to the Data Container Keys topic in the System Setup documentation.

  • If a data container key is defined for a data container type, existing data container instances will be updated if composites with the same key are submitted from PDX. A validation rule in PDX ensures data container keys are unique within a multi-valued composite.

For example, shown in the screenshot below are two data containers of the type ‘Product Review.' They are linked to a product. One has a 'Data Container Key' of '001' and the other '002.'

If the product is re-submitted to STEP from PDX with a data container instance of '001' and another of '003,' the '001' data container will be updated in STEP with any changed values. The '002' data container will be deleted and a new data container with a new data container key will be created and populated with the values from '003.'

Data containers are supported in Maintenance. For additional information about the Maintenance process, review the Workflow And Status Tab topic.