Product data
Product variants from your ERP: one product with every color and size, none lost on the way
Your ERP holds a T-shirt in 4 colors and 6 sizes as a matrix, as item variants or as 24 separate items. We build the integration that turns each of those shapes into one product where the buyer picks color and size, with stock, price and barcode per variant, and that keeps every variant ID stable from run to run.
Three shapes of the same T-shirt
A crew-neck T-shirt, style 20731, in 4 colors and 6 sizes is 24 sellable units. ERPs store those 24 in three different shapes, and the store needs a fourth.
| ERP shape | Example | What the integration has to find |
|---|---|---|
| Matrix parent with children | NetSuite: parent 20731, child 20731-BLK-048 with parent set |
little: the parent is the product, the matrix options are the options |
| Item with item variants | Business Central: item 20731, variant code BLK-048 |
the options: one code holds two values |
| Flat items | 24 items 20731-BLK-044 to 20731-WHT-054, no parent |
the product and the options, from a field or the item number |
The store shape is one product with two options and 24 variants. How the three layers of product data fit together is on the product data page. This page covers the step from each ERP shape to that product.
With 20 styles someone fixes the variants by hand. With 1,500 styles, a new season twice a year and colors that are dropped mid-season, the integration has to know which items belong together and keep them together on every run.
How it works
Finding the product
Matrix. In NetSuite the parent item and its children are linked through parent and typed by matrixtype. The child's name is built from the parent's matrixitemnametemplate, which combines item attributes and matrix options with a separator. A parent holds at most 2,000 combinations. The integration reads the parent as the product and each child as a variant.
Item variants. Business Central's API v2.0 has an itemVariant resource with itemNumber, code and description. The code is one string. There are no option axes: a T-shirt variant is BLK-048, a pair of pants might be NVY-32-34. The integration splits the code on a rule that is set per item group.
{
"value": [
{ "itemNumber": "20731", "code": "BLK-048", "description": "CREW TEE BLACK 48" },
{ "itemNumber": "20731", "code": "BLK-050", "description": "CREW TEE BLACK 50" },
{ "itemNumber": "20731", "code": "OLV048", "description": "CREW TEE OLIVE 48" }
]
}
The third line does not fit the rule. It is held and listed with the item number and the code, and it does not become a one-variant product next to the real one.
Flat items. The grouping key is a style field or a fixed part of the item number. 20731-BLK-048 splits into style, color and size when every item number in the group has exactly three parts. A style number that itself contains a hyphen, such as KB-200-BLK-048, breaks the pattern, so the check runs per item on every run.
Option values and their order
The codes go through a translation table: BLK is Black, 048 is 48. The order of the values comes from the same table, not from the alphabet.
| Sizes as stored | Sorted A to Z | Sorted by the size table |
|---|---|---|
| S, M, L, XL, 2XL | 2XL, L, M, S, XL | S, M, L, XL, 2XL |
| 044, 046, 048 | 044, 046, 048 | 044, 046, 048 |
| 30, 32, 34, 36 | 30, 32, 34, 36 | 30, 32, 34, 36 |
Zero-padded codes sort correctly by accident. Letter sizes never do. In productSet the order is written explicitly: each variant gets a position, starting at 1, and each option a position of its own.
What sits on the variant
| Data | Level | Shopify field |
|---|---|---|
| SKU | variant | sku, case-sensitive |
| Barcode | variant | barcodes, up to 20 |
| Price and compare-at price | variant | price, compareAtPrice |
| Stock | variant per location | inventory item, written by the stock flow |
| Weight | variant | inventoryItem.measurement.weight |
| Image | per color | file on each variant of that color |
| Title and description | product | written by the PIM or the store, not the ERP |
Keeping variant IDs stable
Every store variant has its own ID, and orders, reviews, ads and saved carts point to it. The integration stores the pair of ERP SKU and Shopify variant ID. productSet finds the product by identifier, here a customId holding the style number, so a second run updates the same product instead of creating a copy. Because productSet deletes variants that are missing from its input, every run sends the full set of a product's variants, including those that are inactive in the ERP. An inactive item stays a variant at stock 0 with inventoryPolicy set to DENY. Removing it is a decision you approve in a dry run.
Throughput
A catalog of 1,500 styles with 36,000 variants. Business Central returns up to 20,000 entities per page, so all item variants are 2 requests. Writing to Shopify is one productSet per style: 1,500 calls. At the minimum of 10 points per mutation and 100 points restored per second on a standard plan, that is 10 calls a second and 150 seconds at best. WooCommerce takes up to 100 variations per batch call per product, so a style with 24 variants is 1 call. BigCommerce batches 50 variants per call: a style with 72 variants is 72 divided by 50, which is 1.44, so 2 calls. After the first load only styles with a changed item are sent.
What goes wrong quietly
| What happens | Example | Result |
|---|---|---|
| A code that does not split | OLV048 next to BLK-048 |
a separate product with one variant, unless held |
| An untranslated value | NVY with no entry in the table |
the store shows NVY as a color name |
| Letter sizes sorted A to Z | 2XL, L, M, S, XL | the size picker in the wrong order |
| An inactive item left out | 23 of 24 variants sent to productSet |
Shopify deletes the 24th variant and its ID |
| A SKU that differs only in case | 20731-blk-048 in the store, 20731-BLK-048 in the ERP |
no match; a duplicate variant on the first run |
| More values than the platform takes | 12 colors x 9 waists x 20 lengths is 2,160 | rejected above 2,048 in Shopify and 600 SKUs in BigCommerce |
The last row needs a split before anything is written: by fit, by color group, or by merging two options into one value. The product data page works through the 2,160 case.
What it covers
- Grouping. From a matrix parent, an item variant code or a pattern in the item number, with a check per item on every run.
- Option values. Codes translated to names, sizes in the order of your size table.
- Data per variant. SKU, barcodes, price, weight and stock per variant; images per color.
- Stable IDs. The full set of variants on every run, so no variant is deleted by omission.
- Limits. Styles above a platform's option or variant ceiling are split by a rule you set.
A kit made of several items is a different thing from a variant: see kits and bundles. Contract prices per variant are on customer-specific pricing.
Which systems
| System | Model | Limit or caveat |
|---|---|---|
| NetSuite | matrix parent with child items, matrix options | 2,000 combinations per parent; child names from matrixitemnametemplate |
| Business Central | item with itemVariant records |
one code per variant, no option axes |
| Shopify | product with options and variants | 3 options, 2,048 variants; productSet replaces the full variant list |
| Adobe Commerce | configurable product built from simple products | each variation is a simple product with its own SKU; the attribute needs global scope and a dropdown or swatch input |
| WooCommerce | variable product with variations | attribute with variation set to true; up to 100 variations per batch call |
| BigCommerce | product with variant options | 600 SKUs per product, 250 values per option; 50 variants per batch call |
Checked on October 3, 2026 in the Business Central API reference for itemVariant, the NetSuite Records Browser, Shopify's productSet reference and the Adobe Commerce, WooCommerce and BigCommerce documentation. Per system: NetSuite, Business Central, Shopify, Magento, WooCommerce and BigCommerce.
Where standard connectors stop
Standard connectors move one ERP item to one store product. An ERP without a matrix then produces 24 products for one T-shirt. Where an ERP vendor ships its own Shopify connector, the documentation of one of them is explicit: the variant code is used as the only option, the connector cannot create a variant for a Shopify product that combines two or more options, and an option matrix cannot be defined in that ERP. A T-shirt with color and size is exactly that product.
In an integration built for your items, the product comes from wherever the grouping lives in your ERP, each code is split and translated by a rule you can read, and every variant stays until you remove it. For apparel and footwear catalogs, see apparel and footwear. Send us the item list of one style with all its colors and sizes.
Frequently asked questions
Our ERP has variants. Why do they not arrive as options in the store?
Because the ERP variant is usually one code, and the store wants one value per option. Business Central stores BLK-048 as a single variant code; Shopify needs Color Black and Size 48. The integration splits the code by a rule that is set per item group, translates each part, and holds the item when a code does not fit the rule.
Does each variant keep its own stock and price?
Yes. A variant is its own record with its own SKU in every platform. Stock and price go from the ERP item or item variant to the store variant with the same SKU. Size 54 can be at zero while sizes 44 to 52 stay orderable, and a 2XL can carry a higher price than the M on the same product.
What happens when a color is added?
The ERP gets 6 new items or variant codes and the store product gets 6 new variants: 4 colors become 5, and 24 variants become 30. When the new color code has no translation yet, for example OLV with no entry for Olive, the product is held and listed in the run report, so the store never shows OLV as a color name.
Can variants have their own images?
Yes, per color. Each Shopify variant has a file field for its image. The integration gives every variant with the same color code the same image, so a buyer who picks Navy sees the navy shirt. Images usually come from the PIM or the store itself, not from the ERP, as described on the product data page.
What happens to variants that already exist in the store?
On the first run each store variant is matched to an ERP item by SKU, and the pair is stored with the Shopify variant ID. Shopify treats a SKU as case-sensitive, so 20731-blk-048 and 20731-BLK-048 are two different values; the first run lists every store variant without a match, and nothing is deleted until that list is resolved.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase