Introducción al modelo de Variantes Padre/Hijo

Algunos marketplaces muy populares permiten el intercambio de productos con software de terceros como lo es Sales Layer y algunos lo hacen mediante la importación de ficheros CSV o Excel. 

Muchos de estos marketplaces sugieren un formato de intercambio cuando entran en juego variantes de producto. Este intercambio, está basado en una estructuración Padre/Hijo que permitirá una mejor disposición de la información de producto y variantes en el resultado final.

1

En este documento vamos a hablar de la forma de obtener documentos de importación válidos, cuando los artículos están concebidos como variantes de producto, y que sigan el modelo de estructura Padre/Hijo, mediante el uso de conectores de Sales Layer PIM. Está principalmente enfocado a los conectores que lo incorporan por defecto. Su salida es formateada mediante Plantilla Excel y su salida se formatea mediante CSV estándar.

Es importante saber que no todos los marketplaces admiten una estructura Padre/hijo a la hora de incluir información de variantes. Por ejemplo, marketplaces como Google Shopping, o Google Manufacturer, indican NO incluir el artículo padre como un producto separado en el feed de intercambio. En lugar de ello, utilizan un campo de agrupación dónde cada variante perteneciente al mismo padre debe informar del SKU padre. 

Si las tablas de productos y variantes están ambas activadas, la expulsión será una combinación fusionada de los datos de producto y sus variantes asociadas. Esto refleja, en el modo de funcionamiento por defecto, que si un producto está asociado a tres variantes de un producto la salida del conector mostrará registros que combinen los datos de variantes conectados con los datos ya casados. Si el producto no contiene ninguna variante de producto asociada, también será expulsado como un producto independiente sin valores para los campos de variantes conectados.

Nota: la utilidad de Fórmulas de los conectores del PIM de Sales Layer permite realizar operaciones sobre los campos de productos, variantes, etc. Así sería sencillo con una fórmula de concatenación, obtener descripciones, por ejemplo, en el apartado de Modelo, que combinarán otros campos como la talla y el color. Ej: Zapatillas Sport Xtreme Talla 41 Negro.

 

Añadir padres de variantes fusionadas (como un registro independiente)

 

Sales layer tiene conectores, como el de Amazon Seller, en los que es posible indicar la capacidad de añadir el padre de Variantes fusionadas como un registro independiente. La necesidad de este tipo de marketplaces de utilizar esta técnica hace que sea posible su realización desde el conector cuando se pretende trabajar con variantes.

Nota: plataformas como Lengow o Amazon Seller también permiten feeds con información únicamente a nivel de producto sencillo. En estos casos se pueden exportar feeds sin seguir el modelo Padre/Hijo, que es el aconsejado a la hora de importar feeds que incluyan variantes.

Si activamos la opción de Añadir padres de variantes fusionadas, en los conectores que la incorporan, obtendremos una salida que incluirá el artículo padre cuando este contenga variantes asociadas.

a

Vamos a verlo con un ejemplo:

Disponemos de un producto P1 con tres variantes VP1, VP2 y VP3.

El conector, cuando se fusiona, produce solo 3 registros, tantos como la cantidad de variantes que contenga.Por lo que lo que devolverá será:

P1... VP1...

P1… VP2...

P1... VP3...

Sin embargo, algunos mercados, como Amazon Seller, requieren la asociación de productos y variantes a través de una topología conocida como Padre/Hijo, la forma en que detallan los datos del padre y las diferentes variantes.

Con esta funcionalidad el resultado sería:

P1…. Padre

P1... VP1... Hijo

P1... VP2... Hijo

P1… VP3... Hijo

De este modo, lo que hace es agregar un nuevo registro al resultado: el padre sin datos combinados.

 

Fórmulas específicas del modelado padre/hijo en conectores

 

Cuando activamos las tablas de Producto y Variantes en un conector, y activamos la opción de “Añadir Padres de Variantes Fusionadas” podemos utilizar dos fórmulas en los campos de los conectores. Estos nos van a permitir conocer la tipología del registro que se está exportando para combinar con otras fórmulas, que a la vez, nos permitirán una correcta especificación de los datos de salida.

IS_FUSION_VARIANT_PARENT()

Devuelve cierto si el registro devuelto es padre de variante. 

* Requiere que el parámetro Fusion Variant Parents Output (Añadir padres de variantes fusionadas) esté habilitado.

IS_FUSION_VARIANT_PARENT_FREE()

Devuelve cierto si el registro devuelto forma parte de una fusión entre productos y variantes, y además no tiene ninguna variante asociada. En cualquier otro caso devuelve falso. 

* Requiere que el parámetro Fusion Variant Parents Output (Añadir padres de variantes fusionadas) esté habilitado.

Ejemplo de uso:

IF(IS_FUSION_VARIANT_PARENT(), PRINT("Parent"), PRINT("Child"))

Las fórmulas pueden ser utilizadas tanto en la pestaña de Productos, como en la pestaña de Variantes. 

Nota: cuando conectamos un mismo campo de salida en la pestaña de Variantes y Productos con la fusión habilitada, los especificados en la pestaña de formatos tienen precedencia sobre los de producto como explicamos más adelante.

Ejemplo de uso:

IF(IS_FUSION_VARIANT_PARENT(), IF(IS_FUSION_VARIANT_PARENT_FREE(), PRINT("Single Parent"), PRINT("Parent")), PRINT("Child"))

Ejemplo de uso:

Elimina los productos sin variante asociada del feed de salida definitivo.

IF(IS_FUSION_VARIANT_PARENT_FREE(), REMOVE_FROM_LIST())

Ejemplo de uso:

Genera Nombre de Variante combinando valores de campos.

IF(IS_FUSION_VARIANT_PARENT(), 

         CONCAT({Familia} , “ “, {Modelo}) ,

         CONCAT({Familia} , “ “, {Modelo} , “ “, {Talla}, “/“, {Color}) )

 

Salida por combinación de campos en tablas fusionadas

 

Es recomendable mantener una estructura de datos coherente en el PIM (que permite una estructuración flexible), cuando se organizan productos padre y variantes. 

Nuestro consejo es definir campos comunes en los productos, y campos específicos en las variantes.

Como ejemplo de campos comunes de producto podríamos hablar de: marca, familia, imágenes de ambiente, características, etc.

Como ejemplo de campos específicos de variante podríamos utilizar campos como: talla, color, género, etc.                                                                                                                                      

Según el tipo de negocio y su estructuración pueden variar enormemente los campos a utilizar (producto, variante…). Por esta razón, a menudo se necesitará combinar campos específicos de producto y campos específicos de variantes en un mismo campo del feed de salida. Como ejemplo un campo común de productos y variantes podría ser el precio.

En aquellas ocasiones que deba conectar un campo de variante y un campo de producto sobre un mismo campo de salida, existen unas reglas de sobreescritura.

  • Un campo conectado de la tabla de variantes, siempre tendrá precedencia sobre el valor de un campo conectado de la tabla de productos. Bien sea, porque el valor conectado se obtiene directamente del valor del campo en tablas, o bien porque el valor se obtiene mediante un fórmula.
  • Si el campo conectado en la tabla de de variantes tiene un valor nulo (la cadena vacía o sin espacios se entiende como tal), el valor utilizado en la columna conectada del feed de salida será el que proporcione el producto asociado a esa variante.
  • Los productos Padre (sin variante asociada o fruto de activar el parámetro “Añadir padres de variantes fusionadas”), no tienen un valor por defecto para los campos exclusivos de la tabla de variantes, tan solo el valor en tablas de producto. Así que la salida para aquellos será nula.
  • Si se utiliza una fórmula para dotar de valor a una columna de salida del feed (desde la pestaña de productos o la de variantes), el valor de salida se aplicará a todas los registros de salida. Utilice las fórmulas IS_FUSION_VARIANT_PARENT y IS_FUSION_VARIANT_PARENT_FREE, para determinar la tipología del registro expulsado y determinar el valor final, tal y como se vio en los ejemplos anteriores.

Supongamos los siguientes datos en tablas del PIM conectados de la siguiente forma:

Campo de Tabla Productos

Campo en el Feed de Salida

SKU

SKU

Modelo

Modelo

Marca

Marca

Familia

Familia

euro_price

Tarifa EUR

Campo de Tabla Variantes

Campo en el Feed de Salida

SKU

SKU

Talla

Talla

Color

Color

euro_price

Tarifa EUR

 

Los campos/columnas de salida SKU y Tarifa EUR, están conectados con sendos campos de las tablas de producto y variantes.

  1. Salida de conector estándar sin utilizar fórmulas.
  2. Salida de conector utilizando una fórmula para eliminar el precio del producto Padre (se puede aplicar en cualquiera de los campos euro_price).

IF(IS_FUSION_VARIANT_PARENT() AND IS_FUSION_VARIANT_PARENT_FREE() = 0 , “ ”)

En este caso eliminamos el precio de los productos Padre que hemos añadido, pero solamente de aquellos que disponen de variantes asociadas.

Nota: la correcta conexión de campos de tablas con las columnas de salida, junto con la utilización de fórmulas, permite generar automáticamente feeds atendiendo a cualquier tipo de especificación y tipologías sugeridas de los modelos de variantes Padre/Hijo.