The term “validation” has many definitions in our industry. Determining what data is valid can be a tremendous challenge considering the many flavors of ACES and PIES currently being requested by resellers, along with the ever-evolving versions of ACES and PIES XML standards.
Our validation logic is kept up-to-date with the latest generally accepted versions of the standards for both product and application data, ensuring your data is as widely accepted as possible. In short, our catalog reviews go far deeper than the basic XSD formatting check that is often sold as “XML validation” elsewhere.
Your ACES fitment records are checked against the latest (usually monthly) releases of the VCdb, PCdb, and Qdb. Deviations between your fitment data and the accepted standards are flagged for your review. Issues are presented in easy to read dashboards that display the health of your application data and serve as a launching point for clear paths to resolve those issues:
- Invalid Vehicle Definitions – Using an attribute id that is not a valid value in the VCdb. Example: Sending an Aspiration ID of 8.
- Invalid Vehicle Configurations – Using a combination of attributes that are not valid according to the VCdb and not identified by the sender as being a known invalid record. Example: Defining a Honda Civic to have 8 Doors.
- Direct Conflicts – Having two or more fitment records that have identical fitment definitions, not counting the part number.
- Extended Conflicts – Two or more fitment records that have overlapping vehicle coverage when all possible configurations are considered. Example: Part A is defined to fit a 2010 Ford Mustang and Part B is defined to fit a 2010 Ford Mustang GT.
- Part Terminology/Position Errors – Part Terminologies/Positions whose allowed usage and combinations can change with the release of each new PCdb.
- Qdb Definitions – Fitment notes that leverage the Qdb can become invalid with the release of a new Qdb. Evokat Premier confirms that the targeted qualifier definition remains a valid target.
The spectrum of product information that can be sent in a PIES XML file is quite extensive and the way receivers leverage this data can vary greatly. This is where we see the most “enhancements to the standards” (aka custom data rules) by receivers, which makes defining a universal set of validation rules a challenge. The ability to author Brand/Reseller specific values helps to mitigate customization issues, while we ensure that all product elements, such as prices and packages, are fully defined and that any verifiable reference data is valid:
- (PIES) Part Terminology – Any part terminology used to define an item must be approved for PIES use.
- PAdb Associations – Any product attribute that is associated with a PAdb ID must conform to the parameters defined by that attribute.
- AAIA Brand ID – All brand ids referenced must be valid according to the current ACA Brand Table.
In the end, it is up to a fully engaged Catalog Manager to ensure that the proper PIES XML elements are being used to communicate their brand’s message effectively. While we cannot tell you what to communicate about your items, we do offer several coverage summaries to highlight items that are missing key PIES elements.