Producto, variante y SKU no son lo mismo: el problema de sincronizar un catálogo con variantes
Producto, variante y SKU no significan lo mismo en un ERP y un ecommerce. Aprende a sincronizar catálogos, tallas, colores, Precios y Stock sin perder su estructura.
Una camiseta.
Tres colores.
Cinco tallas.
¿Cuántos productos son?
La respuesta puede ser uno.
O quince.
Depende de a qué sistema se lo preguntes.
Para el equipo comercial puede ser un único modelo. Para el ERP pueden ser quince referencias. Para el ecommerce, un producto con quince variantes. Para el almacén son quince unidades de inventario diferentes.
Todos están hablando de la misma camiseta.
Pero no están hablando de la misma entidad.
Ahí empieza uno de los problemas más habituales al sincronizar catálogos entre ERP y ecommerce.
Una camiseta puede ser un producto, 15 variantes o 15 referencias. Descubre por qué sincronizar un Catálogo ERP–ecommerce exige entender primero su modelo.
Tabla de contenidos
Un producto puede convertirse en muchas cosas
Imaginemos:
Camiseta Essential
Colores:
Negro
Blanco
Verde
Tallas:
S
M
L
XL
XXL
Comercialmente tenemos un producto.
Pero necesitamos controlar stock de:
Negro / S
Negro / M
Negro / L
…
hasta obtener quince combinaciones.
Cada combinación puede tener:
- referencia;
- EAN;
- stock;
- precio;
- peso;
- imagen;
- estado.
El ecommerce suele resolverlo mediante una estructura parecida a:
Producto
→ Variante 1
→ Variante 2
→ Variante 3
Pero un ERP no tiene por qué hacerlo así.
Puede representar modelo, talla y color mediante artículos independientes, tablas relacionadas, dimensiones o estructuras específicas del propio ERP.
Por eso encontrar dos campos llamados SKU no resuelve necesariamente la integración.
El problema de variante y SKU no está en los campos
Supongamos que alguien prepara un Excel:
| ERP | Ecommerce |
|---|---|
| Referencia | SKU |
| Descripción | Title |
| Color | Option |
| Talla | Option |
Parece que hemos resuelto el problema.
Todavía no.
La pregunta importante es:
¿Qué representa una fila en cada sistema?
En el ERP una fila podría representar una combinación concreta:
ESS-NEG-M
En ecommerce esa misma referencia podría existir dentro de:
Camiseta Essential
como una variante:
Negro / M
Antes de mapear campos necesitamos entender la cardinalidad y las relaciones entre las entidades.
No estamos transformando simplemente:
Referencia → SKU
Estamos transformando:
modelo + dimensiones + referencias
en:
producto + variantes.
Una variante no es solo una opción visual
Esta separación no es solo conceptual. En modelos ecommerce como el de Shopify, una variante puede tener su propio SKU, código de barras, precio, inventario e incluso medios asociados.
En ecommerce es fácil pensar en talla y color como selectores:
Color: Negro
Talla: M
Pero detrás de esa selección existe normalmente una unidad vendible concreta.
Puede tener 12 unidades mientras Negro / L tiene cero.
Puede tener otro EAN.
Puede pesar diferente.
Puede incluso tener un precio diferente.
Por tanto hay dos niveles que no debemos confundir:
Información compartida
Nombre
Marca
Descripción
Colección
y:
Información de la variante
SKU
EAN
Talla
Color
Stock
Precio específico
Decidir dónde vive cada dato es parte del modelo de integración.
El stock obliga a resolver correctamente el modelo
Este es el punto donde un mal modelado deja de ser un problema estético.
Imaginemos:
Camiseta Essential
Stock total: 84.
Ese número sirve de poco al ecommerce.
El cliente no compra “Camiseta Essential”.
Compra:
Camiseta Essential / Negro / M
Si esa combinación tiene stock cero, el producto está agotado para ese cliente aunque queden otras 83 unidades.
La disponibilidad debe existir en el mismo nivel en el que se produce la compra.
Por eso:
la granularidad del stock debe corresponder con la granularidad de la unidad vendible.
Esto es especialmente importante en moda y calzado, pero aparece también en deporte, mobiliario configurable, merchandising y muchos otros catálogos.
Las imágenes tampoco siempre pertenecen al mismo nivel
Otra camiseta.
Negro.
Verde.
La fotografía principal puede pertenecer al modelo.
Pero quizá las fotografías de producto dependan del color.
Tenemos entonces:
Producto → imagen principal
pero:
Color Negro → imágenes negras
Color Verde → imágenes verdes
El ecommerce puede soportar perfectamente esa estructura.
La pregunta es si el sistema origen la representa igual.
Y, si no lo hace, dónde vive realmente esa relación.
ERP, PIM, DAM y ecommerce pueden tener responsabilidades diferentes sobre el mismo catálogo.
¿Y las categorías?
También suelen mezclarse dos conceptos.
Una familia del ERP puede existir para organizar internamente artículos.
Una categoría ecommerce existe para ayudar al cliente a navegar.
No necesariamente deberían ser iguales.
El ERP puede tener:
TEXTIL > CAMISETAS > MANGA CORTA
mientras el ecommerce quiere:
Mujer > Básicos
y:
Nueva colección
simultáneamente.
Copiar automáticamente la jerarquía del ERP puede ser técnicamente fácil y comercialmente incorrecto.
¿Quién crea el producto?
Esta pregunta es más importante de lo que parece.
Podemos decidir que:
ERP
crea referencia, variante, EAN, precio y stock.
Mientras:
Ecommerce/PIM
mantiene copy, SEO, imágenes y merchandising.
Eso significa que la sincronización del catálogo no tiene por qué ser completamente unidireccional ni completamente bidireccional.
Puede haber autoridades distintas dentro de una misma entidad.
Producto no significa una única fuente de verdad para todos sus atributos.
Entonces, ¿qué debemos modelar?
Antes de sincronizar un catálogo con variantes necesitamos responder:
¿Qué es el producto?
¿Qué información comparten todas sus variantes?
¿Qué es una variante?
¿Qué combinación representa una unidad vendible?
¿Qué identifica esa variante?
SKU, referencia, EAN u otro identificador.
¿Qué dimensiones existen?
Talla, color, acabado, capacidad…
¿Dónde vive cada dato?
ERP, ecommerce, PIM, DAM…
Y solo después:
¿cómo representa cada aplicación esas relaciones?
Este orden evita intentar resolver un problema semántico mediante un Excel de campos.
Moda es un buen ejemplo, no una excepción
Talla y color hacen que el problema sea especialmente visible.
Pero el mismo patrón aparece en:
Calzado
modelo × color × talla.
Mobiliario
modelo × material × acabado.
Deporte
producto × talla × configuración.
Merchandising
producto × color × formato.
Incluso en algunos productos industriales.
La pregunta siempre es parecida:
¿Dónde termina el producto y empieza la unidad que realmente podemos vender?
Integrar consiste en conservar significado
Un ERP puede llamarlo artículo.
Otro puede separar talla y color.
Shopify puede llamarlo Product y Variant.
PrestaShop puede representarlo mediante producto y combinaciones.
Las palabras cambian.
La relación empresarial permanece.
Por eso en Distillsync trabajamos con conceptos intermedios como PRODUCTO y VARIANTE antes de traducirlos al modelo específico de cada aplicación.
No para imponer a todos los sistemas la misma estructura.
Precisamente para lo contrario:
para permitir que sigan siendo diferentes sin perder el significado cuando los datos pasan de uno a otro.
