# Technical considerations

By
The Quable Team
●
Published 2023-09-10

API driven import: process overview
ERP Data Structure
Mapping

# API driven imports: process overview

Importing your ERP data into Quable PIM is a multistep process. Several factors impact the quality of your data, such as dependencies and hierarchy. This is why imports must be done in a specific order.

graph LR 
    A[Push prerequisite values] 
    A --> B[Push classifications]
    B --> C[Push documents]
    C --> D[Push variants]
    D --> E[Push links]
 
graph LR 
    A[Push prerequisite values] 
    A --> B[Push classifications]
    B --> C[Push assets]
    C --> D[Push links]

# Steps

Step 1
Push predefined values
Your Quable PIM objects may include attributes with predefined values. In order for these objects to make use of the predefined values, they must already exist within Quable PIM. This is why predefined values are a prerequisite to importing documents.

Step 2
Push classifications tree
Now you can start to import your data hierarchy. This begins with the highest level, which is your classifications.

Step 3,4 & 5
Push documents & Variants + Links
After your classifications have been imported, you can add the heart of your data, your documents.
Next, add any variants you may have.
The last step to complete your data model is to add links to connect your variants to your documents.

Step 1 (optional)
Push predefined values
Your Quable PIM objects may include attributes with predefined values. In order for these objects to make use of the predefined values, they must already exist within Quable PIM. This is why predefined values are a prerequisite to importing documents.

Step 2 (optional)
Push classifications
Now you can start to import your data hierarchy. This begins with the highest level, which is your classifications. If no classification is provided while importing an asset, it is put in a by-default classification (dam_sort).

Step 3
Push assets
After your classifications have been imported, you can add your assets.
There are no variant applicable for assets.

Step 4 (optional)
Push links
If the import aims at adding new assets to existing documents, links can be imported last.

# ERP Data Structure

It's essential to ensure that your ERP data corresponds to your Quable PIM data model.

Example:
Your ERP only manages variants (also known as SKUs) and all of the data is associated to each variant.
Your Quable PIM data model consists of at least one document type with variants associated to that document type.
--> In this case, you'll need to manipulate your ERP data before it can be imported into Quable PIM.

The following table demonstrates two potential data models:

Data model Description
Model A - reference & variant For this data model, your ERP variants need to be separated into two elements: Reference document and Variant associated to the Reference document.
Model B - reference, color reference & variant For this data model, your ERP variants need to be separated into three elements: reference document, colorReference document, and a Variant associated to the ColorReference document via a link

# Mapping

A key element when importing from your ERP into Quable PIM is ensuring that the data correctly aligns to the various elements and that the appropriate relationships are maintained.

When mapping your ERP data to Quable PIM, there are two subjects that necessitate particular attention:

  • Document and Variant Codes

In many cases, the code in your ERP matches the unique identifier (ID) of the variant in Quable PIM. However, this is not always the case.
Quable PIM requires that both variants and documents have their own unique identifier per type.

Example
You can have both a variant and a document with a code: "A0001", but you cannot have two documents or two variants with that code.

  • Document and Variant Attributes

It's your responsibility to ensure the proper mapping and any trans-typing of your data between the ERP and Quable PIM.