Mover datos hacia Jumpseller exige algo más que relacionar columnas de origen con campos de destino. Jumpseller separa el Product principal, sus variantes comprables, la personalización introducida por el Customer, los campos personalizados descriptivos, la pertenencia a Categories, la navegación, el inventario, la identidad del Customer, los Orders históricos, el contenido de la tienda online y los registros de integración mediante relaciones distintas. Una plataforma de origen puede almacenar varios de esos significados dentro de un único sistema de atributos o de una sola tabla perteneciente a una extensión.
Por eso, la cuestión central al representar los datos no es si un valor de origen puede copiarse. Es qué objeto de Jumpseller debe ser su propietario y qué relación debe mantenerse. La talla y el color pueden definir variantes con stock propio; un texto de grabado puede seguir siendo un dato introducido para una línea de Order; la marca puede ser un campo personalizado utilizado para filtrar; una Category puede organizar Products sin reproducir el menú anterior; y un identificador externo puede seguir siendo esencial aunque los Customers nunca lo vean.
Los Products son registros principales del catálogo, no unidades de venta completas
Un Product de Jumpseller aporta la identidad de catálogo compartida de una oferta comercializable. Puede contener nombre, descripciones, imágenes, relaciones con Categories, estado, precios predeterminados, ajustes de stock, campos SEO, opciones, campos personalizados y otra información de merchandising. Sin embargo, cuando las opciones generan variantes, el Product principal deja de ser el propietario único de todos los valores comerciales.
Las plataformas de origen suelen combinar de forma diferente los datos del Product principal y los de cada unidad vendible. Una puede guardar cada talla y color como un Product independiente. Otra puede almacenar un Product con SKU hijos. Una tercera puede conservar el Product principal pero guardar imágenes, coste, stock y ajustes de precio en una matriz controlada por una aplicación. El destino en Jumpseller debe conservar la diferencia entre Product principal y variantes, en lugar de aplanar todos los registros en el mismo nivel.
| Patrón del catálogo de origen | Interpretación en Jumpseller | Consecuencia para las relaciones |
|---|---|---|
| Un registro para cada talla y color | Product principal con variantes generadas por opciones cuando los registros representan una misma familia comercial | Las descripciones y Categories compartidas pueden permanecer en el Product principal, mientras que SKU, stock, precio, peso e imágenes pueden pertenecer a las variantes. |
| Product principal con SKU hijos | Product más combinaciones de variantes | Los identificadores existentes de los hijos deben seguir vinculados a la combinación de opciones correspondiente. |
| Product sencillo sin elecciones seleccionables | Product con sus propios valores comerciales | No hace falta crear artificialmente una capa de variantes solo porque el origen exponga una tabla de atributos. |
| Elemento digital o que no se envía | Product cuyo procesamiento e inventario tienen un significado diferente al de un artículo físico | Las referencias de entrega, archivos y expectativas de envío deben permanecer separadas de los datos ordinarios de stock. |
| Familia de Products generada por una aplicación | Registros de Product más relaciones controladas por la aplicación | Los valores descriptivos pueden encajar en campos estándar, mientras que las reglas generadas o los registros vinculados siguen perteneciendo a la aplicación de origen o a otro sistema de destino. |
El estado de un Product también tiene significado. Un estado de origen como activo, oculto, borrador, archivado, descatalogado o disponible bajo pedido puede no corresponder a un único estado de Jumpseller. La representación de destino debe distinguir visibilidad pública, posibilidad de compra, disponibilidad de stock y conservación estacional, en lugar de reducir todos los estados a activado o desactivado.
Opciones, variantes, datos introducidos por el Customer y campos personalizados son estructuras diferentes
Las Product Options de Jumpseller pueden generar variantes reales, pero no todo valor de origen parecido a una opción pertenece a una cuadrícula de variantes. Opciones como talla o color pueden producir combinaciones con su propio SKU, precio, stock, peso, coste y relación con imágenes. Otras entradas de Product recogen texto, mensajes más largos, archivos o selecciones opcionales sin crear una combinación con inventario independiente.
Los Custom Product Fields tienen otra función. Describen el Product y pueden facilitar el descubrimiento cuando se representan mediante valores seleccionables adecuados. Marca, material, familia olfativa, tipo de compatibilidad, temporada o especificación técnica pueden pertenecer a esta capa cuando no crean unidades vendibles independientes.
| Significado comercial | Estructura adecuada de Jumpseller | Qué no debe perderse |
|---|---|---|
| Talla o color con stock independiente | Product Option que genera variantes | Identidad de la combinación, SKU, inventario, precio, peso y relación con imágenes |
| Grabado, dedicatoria o mensaje breve | Entrada de texto introducida por el Customer | El valor elegido debe seguir asociado a la línea de Order comprada, no a la definición del Product principal. |
| Instrucciones detalladas de personalización | Entrada de área de texto | El texto libre del comprador no debe convertirse en metadatos reutilizables del catálogo. |
| Diseño o documento aportado por el comprador | Entrada de archivo | La referencia del archivo pertenece al contexto de la compra, no al inventario. |
| Embalaje opcional o extra de pago | Entrada seleccionable sin variante cuando corresponda | La influencia sobre el precio y el valor elegido para la línea de Order deben permanecer diferenciados de una variante con stock. |
| Marca, material, aroma, clase de compatibilidad o especificación | Custom Product Field | El descriptor puede respaldar información o filtrado del Product sin multiplicar variantes. |
| Regla de configurador condicional | Relación con una aplicación o sistema externo | Las dependencias, fórmulas y visibilidad condicional no equivalen a valores ordinarios de opción. |
Esta separación evita multiplicar variantes artificialmente. Un catálogo de origen que guarda color, talla, texto de monograma, elección de garantía y especificaciones técnicas en una única tabla de atributos puede necesitar cuatro representaciones distintas en Jumpseller. Tratar los cinco valores como dimensiones de variante crea combinaciones que no son unidades reales de inventario; tratar los cinco como campos personalizados elimina la capacidad de seleccionar y controlar stock para variantes auténticas.
Categories, navegación y filtros forman relaciones de descubrimiento distintas
Las Categories de Jumpseller organizan Products y pueden formar jerarquías entre elementos principales y secundarios. También pueden contener nombres, descripciones, imágenes, orden, información SEO y pertenencia de Products. Por eso los registros de Category son importantes para la estructura del catálogo, pero no reproducen por sí solos todo el recorrido de navegación de la tienda online.
La navegación puede colocar Categories en el menú principal, en un menú de Categories o en el pie de página, y puede anidar esas entradas de forma independiente de la relación Product-Category. Una taxonomía de origen también puede contener grupos internos de merchandising, colecciones de campañas, marcas, facetas de búsqueda o etiquetas operativas ocultas. Cada agrupación necesita un significado explícito en el destino.
| Agrupación de origen | Posible propietario en Jumpseller | Decisión de representación |
|---|---|---|
| Familia permanente de Products | Category y pertenencia de Products | Conservar la jerarquía y la pertenencia como estructura de catálogo. |
| Rama de navegación principal | Entrada de navegación que dirige a una Category u otra página | Mantener la ruta y la ubicación en el menú separadas de la existencia de la Category. |
| Faceta de marca o material | Custom Product Field y relación con filtros | Utilizar un descriptor cuando el valor agrupa Products sin definir una elección comprable. |
| Faceta de talla o color | Product Option y relación con filtros | Mantener un vocabulario coherente de opciones para que las elecciones equivalentes puedan servir como filtro. |
| Campaña estacional | Category, contenido de destino, contexto promocional o enlace del tema | Elegir el objeto que realmente controla la campaña en lugar de crear por defecto una taxonomía permanente. |
| Etiqueta interna para informes | Campo administrativo o clasificación de un sistema externo | No mostrar un código interno como navegación de la tienda solo porque proceda de una tabla de Category. |
Los filtros de Jumpseller pueden utilizar Product Options que generan variantes y campos personalizados seleccionables. Esto convierte la coherencia de nombres en parte del modelo de datos. «Color», «Colour» y «Finish» pueden representar el mismo concepto comercial en el origen, pero convertirse en filtros separados si se tratan como campos distintos. En sentido contrario, valores con nombres parecidos pueden necesitar mantenerse separados cuando uno define una variante y otro es solamente descriptivo.
Precios e inventario pueden pertenecer al Product, la variante, el contexto del Customer o una ubicación
Los valores de precio y stock carecen de significado sin saber quién los controla. Un Product sencillo puede tener un precio y una cantidad de stock. En un Product con variantes, cada combinación puede ser propietaria de SKU, precio, coste, peso, imágenes e inventario. Los precios específicos para Customers pueden crear una relación independiente entre una Customer Category y una lista de precios. Los precios por volumen pueden añadir umbrales de cantidad sin cambiar la identidad básica del Product.
El inventario también puede depender de la ubicación. Cuando existe stock por ubicación, el modelo de destino debe conservar la relación entre Product o variante, ubicación de inventario, cantidad y estado de stock. Una cantidad total única no indica qué ubicación puede procesar el artículo ni qué integración es la fuente autorizada.
| Valor comercial | Posible propietario | Por qué importa la propiedad |
|---|---|---|
| Precio base de venta | Product o variante | Un precio del Product principal no puede sustituir precios diferentes de combinaciones reales. |
| Precio de referencia o comparación | Product o variante | El valor de referencia debe permanecer unido a la misma unidad vendible que el precio activo. |
| Coste | Product o variante | Los datos de margen resultan engañosos si el coste de una variante se mueve al Product principal. |
| Tramo por cantidad | Product o relación de precios | El umbral y el precio unitario pertenecen juntos. |
| Precio específico para un Customer | Customer Category y relación con lista de precios | El precio depende de la clasificación del comprador, no de un campo universal del Product. |
| Stock | Product o variante en una ubicación | La cantidad debe permanecer vinculada a la unidad vendible y la ubicación de inventario correctas. |
| Estado de stock ilimitado | Regla de disponibilidad del Product o variante | Una cantidad vacía o cero no equivale necesariamente a inventario ilimitado. |
Los movimientos históricos de stock también son distintos del stock actual. Los Orders pueden modificar el inventario cuando cambia su estado, pero un Order importado es evidencia histórica, no una instrucción para repetir el movimiento de stock original. El destino necesita, como registros separados, el estado final previsto del inventario y el contexto histórico del Order.
Customers, Customer Categories, direcciones y relaciones de marketing necesitan significados separados
Un registro de Customer de Jumpseller representa identidad de cuenta y contacto, pero un perfil de Customer de origen puede incluir mucho más que nombre y correo electrónico. Direcciones, identificadores fiscales, datos de empresa, consentimiento de marketing, estado de cuenta, notas, segmentación, identificadores externos de CRM y pertenencia a Customer Categories pueden tener propietarios distintos.
| Elemento de cuenta de origen | Significado en el destino Jumpseller | Límite de la relación |
|---|---|---|
| Nombre y correo electrónico | Identidad y datos de contacto del Customer | La identidad no debe duplicarse solo porque la persona tenga varios Orders. |
| Direcciones de facturación y envío | Contexto de dirección relacionado con el Customer o con un Order histórico | Las direcciones actuales de la cuenta y las capturas históricas de Orders pueden ser legítimamente diferentes. |
| Datos de empresa o fiscales | Campo de Customer, campo de dirección o registro empresarial externo | El valor pertenece al objeto que lo utiliza para el contexto de cuenta o transacción. |
| Grupo de Customers o nivel mayorista | Customer Category y contexto relacionado de precios o acceso cuando se represente | Un segmento comercial no es solo una etiqueta cuando cambia precios o condiciones de acceso. |
| Consentimiento para boletines | Relación de marketing o plataforma externa de marketing | El significado y origen del consentimiento deben mantenerse separados de la mera existencia de la cuenta. |
| Saldo de fidelización o estado de membresía | Registro de aplicación o sistema externo | Un registro de Customer por sí solo no reproduce la relación del programa. |
| Identificador CRM o ERP | Identificador externo estable | La clave debe permanecer vinculada a la misma persona o empresa utilizada por el sistema externo. |
Los datos de contraseña requieren una interpretación independiente. Un hash de contraseña de origen puede utilizar un esquema que Jumpseller no pueda reutilizar. En ese caso, la identidad del Customer puede seguir teniendo significado aunque las credenciales de autenticación requieran otro proceso de acceso a la cuenta. El modelo de datos no debe considerar un correo electrónico migrado como prueba de que las credenciales de inicio de sesión originales sean portátiles.
Los Orders conservan el contexto comercial histórico, no la configuración actual de la tienda
Un Order de Jumpseller reúne la identidad del Customer o comprador sin cuenta, las líneas de Order, variantes seleccionadas, valores de opciones introducidos por el Customer, direcciones, precios, descuentos, impuestos, gastos de envío, estado de pago, estado de procesamiento, notas, marcas de tiempo y referencias externas. Estos valores forman una captura histórica de lo ocurrido en el momento de la compra.
Esa captura debe mantenerse separada de los registros actuales de Products y configuración. Una línea antigua de Order puede conservar el título del Product, SKU, opciones elegidas y precio aunque el Product activo se haya renombrado, cambiado de precio, desactivado o eliminado. Un coste histórico de envío puede mostrar lo pagado sin definir el método de envío actual. Una referencia de pago puede servir para conciliación sin configurar la pasarela activa.
| Componente del Order | Significado histórico | Relación en el destino |
|---|---|---|
| Identidad del Product en la línea de Order | Qué se compró en ese momento | Conservar cuando sea posible la referencia al Product o variante, manteniendo al mismo tiempo el texto de la captura histórica. |
| Opciones seleccionadas y entradas personalizadas | Elecciones del comprador para esa línea | Mantenerlas con la línea de Order aunque cambie después la definición actual del Product. |
| Precio, descuento e impuesto | Captura comercial | No recalcular el historial a partir de los Products o reglas fiscales actuales. |
| Dirección de facturación y envío | Dirección utilizada en la transacción | Mantenerla separada de posteriores cambios en el perfil del Customer. |
| Estado y referencia de pago | Contexto histórico del pago | El registro no controla la configuración de la pasarela actual. |
| Estado de procesamiento y seguimiento | Contexto histórico de entrega | El registro no define las reglas actuales del transportista o almacén. |
| Canal de origen o identificador externo | Clave de conciliación e integración | Conservar la clave cuando otro sistema la utilice para identificar el Order. |
Los Orders de compradores sin cuenta, cancelados, parcialmente procesados, reembolsados y con entradas personalizadas muestran relaciones que un Order pagado sencillo no expone. El modelo de destino debe contemplar estos estados sin convertir registros históricos en configuración activa de procesos.
CMS Pages, Blog Posts, URL y contenido del tema tienen propietarios diferentes
El contenido de la tienda online de Jumpseller puede incluir CMS Pages, Blog Posts, descripciones de Products y Categories, entradas de navegación, banners, secciones del tema, imágenes, contenido de políticas y campos SEO. Una plataforma de origen puede guardar todo esto en un único creador de páginas o tabla de contenido, pero Jumpseller lo asigna a objetos distintos.
| Contenido de origen | Interpretación en Jumpseller | Diferencia de propiedad |
|---|---|---|
| Contenido de presentación, contacto, políticas o guías | CMS Page | El contenido estable de la página y su ruta permanecen separados de su ubicación en menús y del diseño del tema. |
| Artículo editorial o anuncio | Blog Post | Fecha de publicación, contexto de autoría, Categories o etiquetas, contenido multimedia y enlace permanente pueden diferir de una CMS Page. |
| Texto de Product o Category | Descripción controlada por el catálogo | El contenido pertenece al objeto del catálogo, no a una página genérica independiente. |
| Cabecera, pie de página, banner o sección de la página de inicio | Contenido del tema o navegación | La ubicación de presentación no equivale al registro comercial subyacente. |
| Meta título, meta descripción o enlace permanente | Relación SEO y de ruta del objeto propietario | Los metadatos deben permanecer conectados al Product, Category, CMS Page o Blog Post que describen. |
| Redirección o ruta antigua | Relación de enrutamiento | La URL antigua sigue siendo útil aunque el objeto de destino reciba un enlace permanente diferente. |
El código del tema puede leer campos de Product, campos personalizados, Categories, menús y resultados de aplicaciones, pero no es propietario de esos registros. Reproducir el marcado antiguo no sustituye la representación correcta de los datos subyacentes. Del mismo modo, copiar el cuerpo de contenido sin sus enlaces, medios, ruta y propietario puede crear una página existente que ya no cumple su función dentro de la tienda online.
Aplicaciones, API, webhooks e identificadores externos forman una capa de datos alrededor de la tienda
Jumpseller puede intercambiar datos con sistemas externos mediante aplicaciones, API y webhooks. Una tienda de origen puede depender de un ERP para inventario, un CRM para clasificar Customers, un servicio de procesamiento de pedidos para estados de envíos, un marketplace para publicaciones o una aplicación para suscripciones, reservas, Reviews, fidelización, paquetes o configuración de Products.
Estos registros deben clasificarse por propiedad, no por visibilidad. Un valor mostrado en una página de Product puede estar controlado por un PIM externo. Una cantidad de stock visible en Jumpseller puede sincronizarse desde un ERP. Una etiqueta de Customer puede derivarse de un CRM. Un identificador de publicación de marketplace puede representar una oferta del canal y no el Product principal.
| Registro de integración | Propietario probable | Requisito de representación |
|---|---|---|
| Identificador ERP de Product o variante | Relación entre ERP y catálogo | Conservar la clave en el Product o variante correspondiente usado para sincronización. |
| Identificador de almacén o ubicación | Sistema de inventario o procesamiento de pedidos | Mantener la identidad de ubicación separada de una simple cantidad de stock. |
| Identificador CRM de Customer | Relación entre CRM y Customer | Evitar crear una nueva clave no relacionada para la misma persona o empresa. |
| Identificador de publicación de marketplace | Publicación en un canal de venta | No confundir una publicación con el Product o variante canónicos. |
| Registro de suscripción, reserva o fidelización creado por una aplicación | Dominio de la aplicación | Mantener explícitas las referencias al Product, Customer y Order principales. |
| Estado de sincronización por webhook | Proceso de integración | Tratar marcas de tiempo, identificadores de eventos y cursores como datos operativos de integración, no como contenido de la tienda online. |
Un destino coherente no necesita reproducir cada tabla de origen. Sí necesita un propietario definido para cada identificador y relación que permita administrar el catálogo, mantener la continuidad de Customers, conciliar el historial o sincronizar sistemas externos.
Un mapa de representación de Jumpseller debe resolver el significado antes que el almacenamiento
El modelo de datos de Jumpseller puede resumirse como un conjunto de decisiones de propiedad. Los Products principales controlan la información comercial compartida. Las variantes controlan las combinaciones vendibles. Los datos introducidos por Customers pertenecen a una interacción con el Product y más tarde a una línea de Order. Los campos personalizados describen Products. Las Categories organizan la pertenencia al catálogo. La navegación controla la ubicación en menús. Los Customers controlan identidad y contexto de cuenta. Los Orders conservan capturas históricas de transacciones. Las aplicaciones y sistemas externos controlan sus registros e identificadores especializados.
| Pregunta sobre el origen | Decisión de representación |
|---|---|
| ¿El valor crea un artículo con precio o stock independiente? | Representarlo a nivel de variante y no como campo personalizado descriptivo. |
| ¿El comprador introduce el valor para una compra concreta? | Mantenerlo como dato del Customer y conservarlo con la línea de Order. |
| ¿El valor describe muchos Products sin crear variantes? | Utilizar un campo personalizado adecuado o una relación de clasificación. |
| ¿La agrupación organiza Products o controla la navegación? | Separar la pertenencia a Category de la ubicación en menús. |
| ¿El valor es configuración actual o evidencia histórica? | Mantener el catálogo y la configuración operativa actuales separados de las capturas de Orders. |
| ¿Otro sistema utiliza el identificador como clave? | Conservarlo en el objeto de destino que representa la misma entidad comercial. |
| ¿El registro pertenece a una aplicación en lugar del núcleo de Jumpseller? | Mantener la relación con la aplicación en lugar de forzar los datos dentro de un campo estándar no relacionado. |
Resolver estas preguntas produce una tienda capaz de administrar coherentemente los datos migrados. El destino refleja qué significa cada registro, qué objeto lo controla y cómo se relaciona con el resto del entorno Jumpseller.
Conclusión
Jumpseller cambia el significado de los datos al separar Products principales, variantes, entradas del Customer, campos personalizados, Categories, filtros, navegación, inventario, Customers, Orders, contenido e integraciones mediante relaciones distintas. Por eso, una tabla de atributos, una tabla de Customers o un registro de creador de páginas del origen puede necesitar varios objetos de destino en lugar de una correspondencia directa entre campos.
Una migración coherente conserva la propiedad que existe detrás de cada valor. Los Products siguen conectados con variantes realmente vendibles, los campos descriptivos permanecen separados de las elecciones del comprador, las Categories permanecen separadas de la navegación, la identidad del Customer se mantiene distinta de los programas de aplicaciones, los Orders siguen siendo capturas históricas y los identificadores externos permanecen vinculados a los sistemas y objetos que dependen de ellos.
Preguntas frecuentes
¿Las Product Options y los campos personalizados de Jumpseller son lo mismo?
No. Las Product Options pueden crear variantes o recoger entradas del comprador según el tipo de opción. Los campos personalizados describen el Product y pueden servir para filtrar cuando se representan correctamente. Cada valor debe asignarse según cree una combinación vendible, recoja una elección puntual del comprador o describa el Product.
¿Cuándo debería un atributo de origen convertirse en una variante de Jumpseller?
Debe formar parte de una variante cuando la elección identifica una unidad vendible real con significado comercial o de inventario propio, como SKU, precio, cantidad de stock, peso, coste o relación con imágenes distintos. Los valores descriptivos y la personalización de texto libre deben quedar fuera de la cuadrícula de variantes.
¿Las Categories migradas reproducen automáticamente el menú anterior?
No. Las Categories controlan la agrupación y jerarquía de Products, mientras que la navegación controla la ubicación en menús y la presentación de rutas. Una Category puede existir sin aparecer en el menú principal, y un menú puede incluir enlaces a CMS Pages, Blog Posts, páginas de campañas u otros destinos.
¿Cómo deben relacionarse los Orders históricos con los Products actuales?
Los Orders históricos deben conservar sus capturas de línea, opciones seleccionadas, precios, direcciones, estados y referencias externas. Cuando exista una relación fiable con un Product o variante, puede mantenerse el vínculo, pero los cambios posteriores del catálogo no deben reescribir lo que registró el Order en el momento de la compra.
¿Qué ocurre con los datos de aplicaciones de origen que no tienen un campo nativo en Jumpseller?
El registro debe seguir clasificado bajo su propietario real, ya sea una aplicación o un sistema externo. Las referencias principales y los identificadores estables importantes pueden conservarse en una estructura de destino adecuada, mientras que el funcionamiento especializado permanece diferenciado de los campos ordinarios de Product, Customer u Order.
¿Un mismo campo de origen puede tener destinos distintos en Jumpseller según el Product?
Sí. Un campo llamado «Size», «Type» o «Status» puede tener significados comerciales diferentes entre familias de Products. El destino depende de si el valor crea una variante, describe el Product, controla disponibilidad, recoge una entrada del Customer, permite filtrar o pertenece a un proceso externo.