Gambio combina un catálogo comercial amplio con precios por grupo de Customers, gestión de contenido, campos multilingües, módulos y dos modelos operativos: Gambio Cloud y Gambio autohospedado. Los registros visibles pueden parecer familiares, pero sus relaciones son propias de la plataforma. Un artículo puede vincularse con varias Categories, utilizar diferentes tipos de Product, contener campos y pestañas adicionales, restringir visibilidad por grupo de Customers y recibir precios por grupo o cantidad. Las elecciones del comprador también pueden proceder de distintas generaciones de lógica de catálogo, incluidos atributos de artículo, propiedades, opciones actuales, Product Options y Product Variants.
Estas diferencias hacen poco fiable una transferencia campo por campo. Un valor de color puede ser información descriptiva, un atributo heredado, un valor de opción o parte de una variante con identidad propia. Un nivel de Customer puede controlar visibilidad, precio, tratamiento fiscal, cantidad mínima o varias de esas relaciones. Un registro de contenido puede pertenecer al Content Manager, a una pestaña de Product, a una Category, a un bloque del tema o a un módulo. El modelo de migración debe identificar quién es el propietario en Gambio de cada valor y preservar los registros relacionados que le dan significado comercial.
El significado de los registros depende de la generación del catálogo y del entorno
Gambio mantiene una línea de plataforma actual, pero las tiendas con muchos años pueden contener datos creados bajo estructuras de catálogo anteriores, módulos de terceros o cambios personalizados de base de datos. La versión de origen y los componentes instalados influyen en si una elección se almacena como atributo o propiedad heredada, opción actual, Product Option, Product Variant o registro de un módulo personalizado.
Cloud y autohospedado utilizan Gambio, pero establecen límites de responsabilidad distintos alrededor de los registros técnicos. Las tiendas Cloud dependen más del hosting y las actualizaciones gestionadas por la plataforma. Las instalaciones autohospedadas pueden contener archivos locales, GXModules, temas, ampliaciones de base de datos o modificaciones directas sin equivalente en una instalación limpia de destino. Esta diferencia no cambia el significado de Products, Customers u Orders nativos, pero sí cambia la confianza con la que un campo propiedad de una extensión puede clasificarse como dato portátil de Gambio.
| Evidencia de origen | Interpretación en Gambio | Consecuencia para las relaciones |
|---|---|---|
| Registros actuales de Product Option y Product Variant | Modelo actual de elecciones del comprador y combinaciones vendibles | Conservar juntas definiciones de opción, valores seleccionados, identidad de variante y valores comerciales. |
| Atributos o propiedades heredados del artículo | Estructura de una generación anterior del catálogo | Interpretar según la versión de origen en lugar de forzar terminología actual. |
| Tabla de GXModule o tercero | Entidad propiedad del módulo o ampliación de un registro principal | Identificar el módulo y el Product, Customer, Order o contenido que amplía. |
| Registro de una tienda Cloud | Dato nativo de Gambio dentro de un entorno gestionado por la plataforma | Separar datos comerciales de configuración técnica gestionada. |
| Campo o tabla personalizada en autohospedado | Extensión local, esquema modificado o registro de integración | Asignar destino solo después de conocer propietario y proceso que consume el dato. |
| Identificador externo | Clave ERP, PIM, WMS, marketplace, contabilidad o procesamiento de pedidos | Conservar la clave estable necesaria para reconectar la tienda de destino. |
La versión y el entorno son datos de linaje. Explican por qué dos tiendas Gambio pueden mostrar la misma etiqueta y, sin embargo, almacenar o utilizar el valor de forma distinta.
Products, tipos de artículo, Categories y campos del catálogo son entidades distintas
Gambio suele utilizar el término artículo para un Product vendible. Un Product puede contener número de artículo, stock, peso, Manufacturer, clase fiscal, estado de entrega, código de barras o EAN, unidad de embalaje, unidad de cantidad, cantidad mínima, incrementos de cantidad, imágenes, descripciones multilingües, metadatos y enlaces con Categories. El tipo de Product también puede distinguir un artículo estándar, descargable o un servicio.
Las Categories son registros separados y un Product puede vincularse con más de una Category. Esta relación importa cuando la tienda de origen duplica Products para colocarlos en varias ramas, o cuando las Categories también funcionan como estructuras de merchandising, SEO o navegación. La representación correcta puede ser un Product con varias asignaciones de Category y no varios Products con contenido duplicado.
Gambio también admite campos adicionales de Product, pestañas, filtros, asignaciones a taxonomías de Google, Manufacturers, contenido relacionado y marcadores de merchandising. Estos valores no deben comprimirse en la descripción solo porque sean visibles en la página de Product.
| Patrón de origen | Propietario en Gambio que conviene considerar | Significado que debe conservarse |
|---|---|---|
| Artículo físico vendible | Registro estándar de Product | Identidad, precio, impuestos, stock, peso, imágenes y asignaciones de Category. |
| Archivo digital | Product descargable y relación de acceso con el Order | Identidad del archivo, condiciones de acceso e historial de compra. |
| Servicio o artículo sin envío | Tipo de Product de servicio | Identidad vendible sin inventar datos de procesamiento físico. |
| Product visible en varias ramas | Un Product vinculado con varias Categories | Identidad compartida con varias rutas de descubrimiento. |
| Especificación técnica | Campo adicional, valor de filtro o contenido estructurado | Mantener el significado descriptivo separado de una elección del comprador. |
| Explicación ampliada del Product | Pestaña o relación de contenido del Product | Mantener el contenido asociado al Product y al idioma correctos. |
| Identidad de proveedor o marca | Manufacturer o relación de datos maestros externos | Conservar significado de marca y clave externa. |
La regla principal es preservar la identidad del Product una sola vez y reconstruir sus relaciones. Duplicarlo para reproducir cada ruta de navegación del origen crea incoherencias en stock, SEO e historial de Orders.
Opciones, Product Options, variantes, atributos y propiedades no deben mezclarse
El modelo de elecciones del comprador ha evolucionado. Los recursos actuales distinguen opciones, Product Options y Product Variants, mientras tiendas antiguas pueden seguir usando atributos o propiedades de artículo. Estas estructuras pueden parecer similares en la tienda, pero no son intercambiables a nivel de datos.
Una opción define un dominio de elección como talla o color. Un Product Option conecta la opción con un Product. Un Product Variant representa una combinación concreta derivada de Product Options y puede contener datos comerciales propios de esa combinación. Los atributos o propiedades anteriores pueden guardar valores parecidos mediante otras tablas y reglas. Los datos de origen deben clasificarse por funcionamiento y linaje, no por etiqueta.
| Funcionamiento de origen | Pregunta de interpretación en Gambio | Relación que debe sobrevivir |
|---|---|---|
| La elección solo cambia la selección mostrada | Opción o Product Option sin identidad comercial independiente | Enlace Product-opción y valor seleccionado. |
| La combinación tiene SKU, stock, precio, peso, imagen o disponibilidad propios | Product Variant | Product padre, valores seleccionados, identidad de variante y valores comerciales. |
| El comprador introduce texto o personalización | GX-Customizer o entrada propiedad de un módulo | El valor introducido permanece conectado con la línea del Order. |
| El valor describe el Product | Campo adicional, filtro, propiedad o contenido | El valor descriptivo permanece separado de la combinación comprada. |
| Una tienda antigua utiliza atributos de artículo | Estructura heredada de atributos | Nombre, valor, efecto de precio, funcionamiento de stock y linaje de origen. |
| Una tienda antigua utiliza propiedades de artículo | Estructura heredada de propiedades o combinaciones | Grupos de propiedades, valores, combinaciones y relación con Product. |
Un selector sencillo de talla puede asignarse directamente. Una matriz de combinaciones con stock e imágenes separados requiere identidad a nivel de variante. Un campo de personalización pertenece a la línea comprada del Order, no a una variante reutilizable. Tratar los tres como simples opciones puede hacer que el catálogo parezca correcto mientras se pierde significado operativo e histórico.
Stock, precios, grupos de Customers y reglas de cantidad forman una capa comercial
Los datos de Product pueden conectarse con control de stock, cantidades mínimas, incrementos, visibilidad por grupos de Customers, precios por grupo, precios escalonados, descuentos, clases fiscales, ofertas especiales y otras reglas comerciales. Estas relaciones determinan quién puede ver un artículo, qué precio recibe y qué cantidad puede comprar.
Un grupo de Customers no es solo una etiqueta de segmento. Gambio puede utilizarlo para controlar visibilidad y precios de Product. Un nivel mayorista de origen puede requerir una relación con el grupo, mientras un segmento de marketing puede pertenecer a otra estructura. Los Orders históricos deben conservar el precio, descuento, impuesto y cantidad reales registrados al comprar, no reinterpretarse a partir del grupo actual del Customer.
| Significado de origen | Relación en Gambio | Límite de traducción |
|---|---|---|
| Product disponible solo para compradores aprobados | Visibilidad Product-grupo de Customers | Conservar la relación de acceso, no solo el nombre del grupo. |
| Precio mayorista o de distribuidor | Precio de Product para grupo de Customers | Mantener conectados Product, grupo, moneda y precio. |
| Tramo por cantidad | Precio escalonado o regla dependiente de cantidad | Preservar umbrales y el alcance de Customers que lo recibe. |
| Cantidad mínima de compra | Valor de pedido mínimo del Product | Mantener la regla comercial separada de la cantidad de inventario. |
| Stock por combinación vendible | Stock a nivel de variante cuando corresponda | No adjuntar toda la cantidad al Product padre. |
| Precio promocional actual | Relación de precio activa | Mantenerlo separado del precio histórico guardado en Orders antiguos. |
Aquí campos aparentemente pequeños se vuelven operativamente relevantes. Un precio copiado sin su relación de grupo no es el mismo precio. Un valor de stock sin identidad de variante no es el mismo registro de inventario.
Customers, direcciones, grupos y Orders contienen tipos de evidencia distintos
Los datos de Customer pueden incluir identidad de cuenta, direcciones, pertenencia a grupos, contexto de comercio o distribuidor, notas, preferencias de comunicación, Reviews y relaciones administrativas. Deben separarse por finalidad. Una dirección guardada no es lo mismo que una instantánea de dirección dentro de un Order. Una pertenencia a grupo no es un descuento histórico. Una cuenta de administrador no es una cuenta de Customer.
Los Orders contienen evidencia comercial histórica: identidad de Customer o invitado, direcciones de facturación y envío, referencias a Products y variantes, elecciones realizadas, cantidades, precios, descuentos, impuestos, envíos, etiquetas de pago, estados, comentarios, facturas, documentos de entrega, retiradas y otros registros relacionados. Un Order migrado debe seguir siendo comprensible aunque la tienda de destino use otra configuración activa de pago, envío, impuestos o estados.
| Elemento histórico | Propietario en Gambio | Significado que debe conservarse |
|---|---|---|
| Comprador registrado | Cuenta de Customer | Identidad y relación con Orders y direcciones. |
| Comprador invitado | Instantánea de identidad del Order | Contexto histórico sin inventar una cuenta. |
| Dirección guardada | Libreta de direcciones del Customer | Relación reutilizable de dirección. |
| Dirección de facturación o envío de un Order | Instantánea en el momento de la transacción | Evidencia de cómo se realizó la operación. |
| Elección de Product en una línea | Etiqueta de Product/variante y valores elegidos | Artículo exacto comprado aunque el catálogo cambie después. |
| Etiquetas de pago y envío | Historial del Order | Evidencia histórica, no configuración actual del método. |
| Historial de reembolso, retirada o estado | Registros relacionados del Order | Mantener trazable el contexto de posventa. |
El modelo más sólido mantiene separados los datos maestros del Customer y las instantáneas del Order. Actualizar una dirección tras la migración no debe reescribir la dirección registrada en un Order antiguo.
Content Manager, contenido de Product, URLs y temas tienen propietarios diferentes
El contenido de Gambio puede vivir en Content Manager, descripciones y pestañas de Product, descripciones de Category, banners, sliders, menús, páginas legales, páginas de error, bloques de tema, archivos de idioma o módulos. Cada estructura tiene un propietario y una relación de ruta diferentes.
Las CMS Pages deben conservar identidad, idioma, contenido, visibilidad, ubicación en menú y relación de URL. Las pestañas permanecen conectadas con Products. Las descripciones de Category se mantienen con sus Categories. Un bloque de tema o configuración de StyleEdit controla presentación y no debe confundirse con una CMS Page portátil. El contenido legal puede necesitar revisión empresarial actual, pero su identidad y ubicación como registro pueden preservarse.
Products y Categories también pueden contener palabras clave de URL, reescrituras, metadatos, términos de búsqueda y valores multilingües. Estas relaciones influyen en el descubrimiento, pero no convierten navegación, contenido y SEO en el mismo objeto.
| Elemento visible en tienda | Propietario probable en Gambio | Implicación del modelo de datos |
|---|---|---|
| Página informativa o de políticas | Entrada de Content Manager | Conservar contenido, idioma, ruta y ubicación. |
| Explicación adicional de Product | Pestaña o contenido del Product | Mantenerla conectada con el Product en lugar de crear una página genérica. |
| Texto de landing de Category | Registro de Category | Mantenerlo con identidad y ruta de la Category. |
| Banner o teaser de inicio | Configuración de banner/teaser | El activo de contenido y su colocación son distintos. |
| Elemento de menú | Configuración de navegación | Una página o Category migrada no recrea automáticamente su posición en menú. |
| Bloque de tema u override | Presentación del tema o módulo | Reconstruir presentación sin clasificar código como contenido. |
| URL antigua de Product o Category | URL de entidad y relación de redirección | Conservar la relación entre ruta de origen y destino. |
Una migración limpia puede conservar contenido aunque cambie la presentación. Lo crítico es que cada registro llegue al propietario correcto y permanezca conectado con su ruta e idioma.
Módulos, GXModules, APIs y sistemas externos amplían el modelo nativo
Gambio admite módulos, GXModules, temas, REST APIs, importación/exportación e integraciones con marketplaces, contabilidad, procesamiento de pedidos, búsqueda y otros sistemas. Pueden crear campos, tablas, estados, identificadores y registros de procesos que no pertenecen al modelo nativo de Product, Customer u Order.
Que un valor exista en base de datos no lo convierte en campo principal de Gambio. Un módulo puede guardar ID de publicación de marketplace, código de proveedor, referencia de transacción de pago, estado del canal de datos, propiedad personalizada de Customer o indicador de procesamiento de Order. Su significado depende del módulo o sistema externo que lo consume.
| Propietario del dato | Ejemplos | Decisión de traducción |
|---|---|---|
| Núcleo de Gambio | Products, Categories, Customers, Orders, contenido, opciones y variantes | Asignar mediante relaciones nativas. |
| Módulo o GXModule | Campos, tablas, estados y registros vinculados a configuración | Conservar solo con propietario de destino y clave principal relacionada identificados. |
| Tema o StyleEdit | Diseño, bloques, plantillas y ajustes visuales | Tratar como presentación de destino, no datos maestros comerciales. |
| ERP/PIM/WMS externo | Identificadores maestros, stock, proveedor, precios o procesamiento | Conservar claves duraderas entre sistemas y su autoridad. |
| Marketplace o canal | IDs de publicación, estados de oferta, Categories del canal y metadatos de sincronización | Mantenerlos separados del Product canónico salvo que el proceso de destino siga utilizándolos. |
| Código personalizado | Tablas a medida o campos principales modificados | Definir propiedad explícita en lugar de asumir soporte nativo. |
Cloud y autohospedado pueden exponer evidencia técnica distinta, pero la regla es la misma: los datos activos propiedad de extensiones necesitan un propietario futuro. Los artefactos técnicos obsoletos no adquieren valor solo porque existan en la base de datos de origen.
Decisiones de traducción según el significado empresarial
| Patrón de origen | Pregunta correcta en Gambio | Consecuencia de una suposición incorrecta |
|---|---|---|
| Product padre con combinaciones hijas | ¿Es una opción, Product Option, variante actual o combinación de atributo/propiedad heredada? | Se pierden o duplican SKU, stock, precio, imagen o valores elegidos. |
| Product visible solo para mayoristas | ¿La visibilidad por grupo de Customers controla la restricción? | El Product queda público o inaccesible para compradores previstos. |
| Precio por nivel o cantidad | ¿Qué Product, grupo, umbral y moneda definen el precio? | El comprador recibe un precio incorrecto aunque el número exista. |
| Contenido mostrado en página de Product | ¿Es pestaña, campo adicional, bloque de módulo o CMS Page? | El contenido llega sin la relación que lo muestra. |
| Estado histórico de Order | ¿Qué historial, pago, procesamiento o retirada explica el estado? | El personal no puede interpretar la transacción pasada. |
| Campo creado por módulo | ¿Qué módulo o sistema externo posee y actualiza el valor? | Se copia un dato huérfano a un campo que ningún proceso mantiene. |
| URL heredada | ¿Qué Product, Category o contenido debe recibir la redirección? | Se rompe continuidad de búsqueda y enlaces internos pese a transferir los registros. |
La migración preserva significado cuando linaje de Products, elecciones del comprador, comercio por grupos, evidencia histórica de Orders, propiedad del contenido y registros de extensiones se tratan como dominios conectados pero separados.
Conclusión
La traducción del modelo de datos de Gambio está determinada por la generación del catálogo, tipos de Product, enlaces con Categories, estructuras actuales y heredadas de opciones, precios y visibilidad por grupo, Orders históricos, Content Manager, módulos, APIs y el entorno Cloud o autohospedado. Un campo de origen solo es útil cuando la tienda de destino conserva la entidad propietaria y los registros relacionados que le dan significado.
El modelo de destino más sólido distingue Products de variantes, campos descriptivos de elecciones del comprador, datos maestros de Customer de instantáneas de Order, contenido de presentación y registros principales de Gambio de datos pertenecientes a módulos o sistemas externos. Esa disciplina de propiedad produce un catálogo e historial comercial comprensibles, no simplemente poblados.
Preguntas frecuentes
¿Cuál es la diferencia entre las opciones de Gambio y Product Variants?
Las opciones definen dominios de elección y Product Options conectan esas opciones con un Product. Product Variants representan combinaciones concretas y pueden contener valores comerciales propios. Tiendas antiguas pueden utilizar atributos o propiedades, por lo que importan la versión y las relaciones entre tablas.
¿Toda combinación de Product de origen debe convertirse en Product Variant?
No. Una combinación encaja como variante cuando tiene identidad o valores comerciales propios, como SKU, stock, precio, peso, imagen o disponibilidad. Personalización y especificaciones descriptivas suelen pertenecer a otras estructuras.
¿Cómo afectan los grupos de Customers a la migración?
Pueden controlar visibilidad de Products, precios por grupo, precios escalonados, tratamiento fiscal u otras reglas comerciales. Conservar solo el nombre del grupo no conserva esas relaciones.
¿Puede un Product de Gambio pertenecer a varias Categories?
Sí. Gambio puede vincular un Product con varias Categories. Una tienda de origen que duplica Products para navegación puede representarse mejor con una identidad única y varias asignaciones.
¿Las entradas de Content Manager son lo mismo que pestañas de Product o bloques del tema?
No. Content Manager contiene registros independientes. Las pestañas pertenecen a Products y los bloques de tema y ajustes de StyleEdit pertenecen a presentación. Cada uno necesita un propietario distinto en destino.
¿Qué debe hacerse con datos creados por módulos o integraciones externas?
Identificar el módulo o sistema externo, el registro principal que amplía y el identificador estable que los conecta. Las relaciones activas necesitan un destino explícito; los registros técnicos obsoletos pueden excluirse o archivarse sin tratarlos como datos nativos de Gambio.