Productos variables en WooCommerce: cómo sincronizar variantes y SKU con el ERP
Con los productos variables en WooCommerce, tu cliente encuentra una camisa, elige azul y talla M y añade una unidad. El almacén necesita una referencia concreta para preparar esa combinación.
La ficha comercial reúne opciones; la operación de venta debe reconocer cuál se eligió. A partir de ahí cambian el precio, la disponibilidad y los datos que vuelven al ERP.
Vamos a mantener una camisa con tres variaciones para entender cómo se construye esa relación y qué sucede al incorporar una opción nueva.
Productos variables en WooCommerce: la unidad que se vende
La camisa del ejemplo se ofrece en azul y blanco, con las tallas que el negocio ha preparado para cada color.
WooCommerce presenta el modelo y permite elegir opciones. Al confirmar, el comprador ha seleccionado una combinación concreta.
El almacén necesita saber cuál es.
Por eso conviene separar información compartida y datos propios de la unidad vendible. La descripción del modelo puede ser común, mientras referencia, código de barras, precio o disponibilidad pueden cambiar por combinación.
WooCommerce documenta los productos variables y las variaciones con datos propios. La configuración real de la tienda determina cómo se utiliza cada nivel.
En el ERP debemos averiguar qué representa una referencia y cómo se agrupan sus opciones. Después podemos preparar la correspondencia.
El SKU ayuda a identificar, pero necesita contexto
Dos aplicaciones pueden utilizar un código parecido y representar niveles distintos del Catálogo.
Una referencia puede identificar el modelo general en un sistema y una combinación concreta en otro. Antes de mapear necesitamos entender esa diferencia.
También puede haber códigos comerciales, códigos del fabricante o referencias alternativas. Conviene elegir qué identificador mantiene la relación estable y qué función tienen los demás.
Cambiar el texto visible de un producto no debería obligar a adivinar qué referencia lo originó. La integración necesita conservar los identificadores que relacionan las entidades.
En Distillsync puedes configurar búsquedas, correspondencias y transformaciones dentro de tareas. La revisión debe comprobar qué nivel del modelo identifica cada dato.
Tres variaciones tienen correspondencias distintas
WooCommerce documenta los productos variables como una ficha con opciones y variaciones. En nuestro escenario la camisa tiene atributos de color y talla, pero solo se comercializan tres combinaciones.
| Artículo vendible ERP del ejemplo | Opciones WooCommerce | Identidad de variación ficticia | SKU |
|---|---|---|---|
| CAM-AZ-M | Azul, M | 901 | CAM-AZ-M |
| CAM-AZ-L | Azul, L | 902 | CAM-AZ-L |
| CAM-BL-M | Blanco, M | 903 | CAM-BL-M |
La ficha padre reúne las tres. La posibilidad de elegir blanco y L no debe generar una cuarta combinación comercial por el mero hecho de combinar todos los valores de atributos. El catálogo del negocio determina qué opciones existen.
Los atributos utilizados para la variación deben estar definidos con coherencia en la ficha y relacionados con las opciones de cada variación. «Azul» y otro valor escrito de una forma distinta pueden acabar representando opciones separadas si la configuración no los normaliza.
El SKU mantiene la referencia de negocio. El identificador interno permite dirigirse a una variación ya creada. El artículo producto, variante y SKU explica las diferencias; aquí seguimos su representación dentro de WooCommerce.
El nivel de stock decide qué cantidad se actualiza
En esta camisa cada combinación tiene inventario propio: ocho unidades azules M, dos azules L y cinco blancas M. La configuración del ejemplo controla existencias por variación.
Al vender una azul M, esperamos siete para CAM-AZ-M. Las otras dos cantidades permanecen. Publicar quince en el padre y tratar esa suma como Stock independiente de cada opción podría permitir vender tallas que no están disponibles.
Existe también el caso de opciones que consumen una disponibilidad común. El nivel de control debe responder a la unidad física que prepara el negocio. No se elige por la comodidad de enviar un único número.
La documentación de la API WooCommerce distingue campos de gestión de stock y cantidad. Esa interfaz describe cómo representar el dato; el negocio decide si corresponde al padre o a cada variación, y la integración debe respetar la configuración elegida.
Para comprobar el ejemplo actualizamos CAM-AZ-L de dos a cuatro. La ficha sigue reuniendo las mismas tres variaciones, azul M conserva ocho si todavía no hubo compra y blanco M conserva cinco. El resultado muestra que la identidad y el alcance de la actualización se mantienen.
Las imágenes y el precio pueden cambiar a otro ritmo
Una fotografía puede describir el color, mientras el precio depende de la referencia o de las condiciones del comprador.
Cada dato necesita una responsabilidad clara. Puede que el ERP mantenga determinados importes y que ecommerce gestione las imágenes. Una actualización de stock debería modificar la parte que le corresponde sin sustituir contenido ajeno a su función.
Esto evita que una tarea frecuente termine sobrescribiendo cambios editoriales o reconstruyendo toda la ficha innecesariamente.
La integración necesita distinguir creación, actualización y mantenimiento de relaciones. Actualizar una cantidad no exige necesariamente revisar todos los contenidos del producto, pero sí identificar correctamente su destino.
Un atributo informativo no siempre crea otra variación
La composición de la camisa es algodón. Ese dato puede ayudar a elegir sin generar una unidad vendible distinta. Color y talla, en cambio, participan en las tres combinaciones que el negocio prepara como artículos del ejemplo.
Si cada atributo técnico se convierte automáticamente en una dimensión de variación, el catálogo puede producir combinaciones que no existen. La estructura debe conservar qué opciones cambian la referencia y cuáles describen el producto o una variante ya reconocida.
Después el equipo decide mostrar un color con otra denominación comercial. La referencia CAM-AZ-M sigue identificando la misma camisa, pero cambia su presentación. La actualización necesita reconocer la variación existente y mantener su correspondencia, en lugar de crear otra opción únicamente porque ha cambiado el texto visible.
El mismo criterio se utiliza al modificar imágenes. Una fotografía compartida del modelo puede mantenerse en la ficha, mientras una imagen de un color pertenece a determinadas variaciones. El cambio se aplica en el nivel acordado y conserva los demás recursos.
Para comprobarlo elegimos CAM-AZ-M y CAM-BL-M. Ambas comparten talla, pero mantienen color y referencia distintos. Actualizar la imagen azul no debe sustituir la blanca ni modificar el inventario.
Distillsync permite preparar la selección y las transformaciones de los datos mediante tareas. La correspondencia debe mantener las identidades a través de esos cambios de presentación. Así el catálogo puede mejorar su contenido sin reconstruir el trabajo de relaciones que permite comprar y servir cada opción.
Una variante nueva necesita completar el recorrido
El catálogo evoluciona. Se incorpora una talla, se sustituye una referencia o deja de venderse una combinación.
Debemos decidir cómo reconocer esos cambios.
Una referencia nueva puede necesitar atributos, identificadores y relación con el modelo antes de publicarse. Una retirada puede tener Pedidos pendientes o histórico que convenga conservar.
Por eso borrar y dejar de ofrecer son operaciones diferentes. La política de la empresa debe determinar qué permanece y cómo se presenta el cambio al comprador.
Para una agencia, disponer de ejemplos de alta, actualización y retirada permite revisar la configuración con el responsable del catálogo. Las diferencias se entienden desde el producto, antes de bajar a campos técnicos.
Puedes consultar también el módulo de Catálogo.
Una talla nueva recorre catálogo, stock y pedido
El negocio incorpora azul XL con referencia CAM-AZ-XL. Primero aparece la nueva opción válida en la ficha. Después se reconoce la variación creada y se relaciona con aquel artículo del ERP.
La cantidad inicial del ejemplo es tres. El precio y la imagen se asignan según las responsabilidades acordadas; si la imagen azul pertenece a WooCommerce, una actualización de stock no la sustituye.
Hacemos una compra de una azul XL. La línea vuelve con CAM-AZ-XL y cantidad uno; su disponibilidad queda en dos según la política del caso. Las opciones anteriores siguen apuntando a sus referencias.
Si la compra llega con la referencia general de la camisa, el fallo se encuentra en la relación de la variación con la línea. Si el catálogo crea otra ficha al actualizar XL, se ha perdido la identidad del padre o de la variación existente.
Distillsync permite preparar estas relaciones en tareas configurables. Este mantenimiento complementa la guía de WooCommerce y ERP: aquí el resultado es que cada opción conserve su unidad vendible al nacer, actualizarse y comprarse.
Cada opción conserva una identidad comercial
La ficha ayuda al cliente a elegir. La variación define lo que compra. El ERP necesita reconocer la referencia que permite continuar la operación.
Distillsync utiliza un modelo semántico común y tareas configurables para trabajar con entidades y relaciones entre aplicaciones. Puedes empezar por un producto conocido y revisar cómo se transforma sin perder sus opciones.
La integración debe permitir que la elección del cliente llegue al almacén con el mismo significado.
Descubre Distillsync para WooCommerce o crea tu cuenta y empieza a probarlo.