EasyStore combina un componente comercial dedicado con capas de identidad, acceso, enrutamiento, módulos y creación de páginas de Joomla. Sus Products, variantes, Categories, tags, marcas, colecciones, Customers, Orders, Coupons, Reviews y registros comerciales pertenecen a EasyStore, mientras Joomla y SP Page Builder pueden determinar cómo se accede a ellos y cómo se presentan.
Cuando EasyStore es la plataforma de destino, la cuestión central del modelo de datos no es si un registro de origen puede copiarse a un campo de nombre similar. La cuestión es qué objeto de EasyStore debe ser propietario del significado y qué relación de Joomla o de presentación debe permanecer separada. Un catálogo de origen puede contener Products, opciones, especificaciones, colecciones, navegación, landing pages, identidades de compradores e historial de transacciones dentro de un único modelo; EasyStore distribuye esas responsabilidades entre registros comerciales y registros de composición del sitio.
EasyStore utiliza capas de propiedad distintas para comercio y Joomla
EasyStore almacena el modelo principal de venta, mientras Joomla aporta el entorno del sitio. SP Page Builder puede consumir datos de EasyStore y organizar su salida pública sin convertirse en propietario de inventario de Product, identidad de Customer o historial de Orders.
| Capa | Registros habituales | Consecuencia para la traducción del modelo |
|---|---|---|
| Comercio EasyStore | Products, variantes, precios, inventario, Categories, tags, marcas, colecciones, Customers, Orders, Coupons y Reviews | Estos registros forman el grafo comercial y deben conservar sus relaciones internas. |
| Núcleo Joomla | Usuarios, niveles de acceso, menús, módulos, idiomas, medios y alias | Pueden controlar identidad, accesibilidad, visibilidad y contexto del sitio sin sustituir entidades de EasyStore. |
| SP Page Builder | Diseños de página y bloques de contenido EasyStore | La presentación referencia registros EasyStore, pero no se convierte en sistema de registro de Product u Order. |
| Integraciones de pago y envío | Referencias de gateway, carrier y transacción | Las referencias históricas pertenecen a Orders; el funcionamiento futuro pertenece a la integración del destino. |
| Extensiones e integraciones personalizadas | Campos adicionales, webhooks, IDs externos y flujos especializados | Debe identificarse la propiedad antes de asignar valores a objetos de destino. |
Esta división evita dos errores frecuentes: tratar contenido de Joomla como si fuera dato comercial y tratar la salida visual de Page Builder como si contuviera el modelo autoritativo de Product.
Products, variaciones y variantes necesitan traducción a nivel de relaciones
Un Product de EasyStore puede contener título, alias, descripción, medios, precios, tratamiento fiscal, medidas de envío, identificadores, lógica de inventario, Category, tags, acceso y valores SEO. Cuando se añaden variaciones, EasyStore crea significado comercial a nivel de variante. Precios e inventario pasan del contexto del Product principal a Product Variants, donde cada combinación puede tener precio, descuento, peso, SKU, identificador estandarizado, cantidad, disponibilidad y visibilidad propios.
Una plataforma de origen puede representar la misma mercancía como Products separados, un Product con opciones, una matriz de combinaciones, registros secundarios configurables o campos personalizados. El destino debe decidir qué registros forman el Product principal de EasyStore y cuáles se convierten en variantes.
| Patrón de catálogo de origen | Pregunta de representación en EasyStore | Significado en riesgo |
|---|---|---|
| Un Product por talla o color | ¿Deben consolidarse bajo un único Product con variantes? | URL, Reviews, medios, inventario e IDs externos pueden duplicarse o fusionarse incorrectamente. |
| Product principal con SKU secundarios | ¿Qué atributos de los secundarios definen valores de variación de EasyStore? | Las combinaciones vendibles pueden perder SKU, precio, stock o visibilidad. |
| Opción de texto libre en Order | ¿Es una variación vendible o metadato histórico de línea? | Elecciones del comprador pueden forzarse a una estructura de variantes que no corresponde al origen. |
| Campos de especificaciones de Product | ¿Deben convertirse en Additional Data en lugar de variaciones? | Atributos informativos pueden confundirse con elecciones comprables. |
| Stock a nivel de Product y también de opción | ¿Qué nivel de inventario es autoritativo? | El destino puede duplicar cantidades o mostrar combinaciones no disponibles. |
Las variaciones de EasyStore no son simples etiquetas visuales. Una vez creadas, cada variante puede llevar sus propios atributos comerciales. Por ello, los identificadores de origen deben permanecer unidos al nivel vendible que reconocen sistemas externos, almacenes y Orders históricos.
Additional Data, tags, marcas, colecciones y Products relacionados cumplen funciones distintas
EasyStore ofrece varias formas de describir y agrupar Products. Additional Data puede contener especificaciones estructuradas. Los tags apoyan descubrimiento y clasificación flexible. Las marcas identifican fabricante o identidad de marca. Categories organizan la jerarquía principal. Collections pueden seleccionar Products con fines de merchandising. Las relaciones de upselling y venta cruzada conectan un Product con otros Products.
Estas estructuras no deben aplanarse en una taxonomía genérica.
| Estructura de EasyStore | Función principal | Datos de origen que pueden corresponder |
|---|---|---|
| Category | Organización principal del catálogo y asignación de Products | Categories o departamentos con significado duradero de navegación |
| Tag | Etiqueta flexible de descubrimiento | Palabras clave, temas, casos de uso o clasificaciones no jerárquicas |
| Brand | Identidad de marca o fabricante | Registros de marca, proveedor o fabricante cuando el significado coincida |
| Collection | Agrupación curada de Products | Grupos de campaña, surtidos estacionales, gamas destacadas o colecciones editoriales |
| Additional Data | Especificaciones informativas de Product | Atributos técnicos, materiales, dimensiones, compatibilidad o datos descriptivos |
| Relación upsell/cross-sell | Vínculo comercial Product→Product | Referencias relacionadas, complementarias, sustitutas o de mayor valor |
Una “collection” de origen puede ser Category, grupo dinámico, landing page o campaña. La representación debe seguir su propósito empresarial y no la etiqueta. Lo mismo ocurre con atributos: una talla seleccionable pertenece a variaciones; una especificación técnica no seleccionable pertenece a Additional Data u otra estructura descriptiva.
Las Categories de EasyStore no son menús de Joomla ni diseños de Page Builder
Las Categories de EasyStore organizan Products dentro del modelo comercial. Los Menu Items de Joomla hacen accesibles páginas y pueden definir alias, rutas, acceso, idioma y contexto de plantilla. Los diseños de SP Page Builder organizan componentes y bloques EasyStore en páginas. Una landing page puede depender de las tres capas.
| Concepto público | Propietario EasyStore | Relación Joomla/presentación |
|---|---|---|
| Jerarquía de listado de Products | Árbol de Categories de EasyStore | Un Menu Item puede exponer una ruta de Category o una página curada. |
| URL de Product | Alias de Product y enrutamiento del componente EasyStore | El contexto de menú de Joomla puede influir en la ruta pública. |
| Landing page de campaña | Products o referencias a colecciones de EasyStore | Un diseño SP Page Builder puede organizar el contenido de campaña. |
| Etiqueta de navegación | Menu Item de Joomla | Puede apuntar a Category, Collection, Product o página personalizada. |
| Bloque de Product | Fuente de datos EasyStore | Un bloque SP Page Builder controla colocación y presentación. |
Esta separación importa cuando la plataforma de origen almacena navegación y agrupación de catálogo como un solo objeto. Recrear solo el árbol de Categories puede no recrear la navegación pública, y copiar solo diseños puede dejar Products desconectados de sus relaciones autoritativas de Category y Collection.
Customers y usuarios de Joomla pueden vincularse sin ser el mismo registro
EasyStore puede mantener registros de Customer y convertir un usuario Joomla existente en Customer. Esa relación no convierte ambos conceptos en idénticos. Joomla controla identidad de login, estado de cuenta, grupos de usuarios y acceso. EasyStore controla el perfil de comprador y las relaciones comerciales necesarias para la tienda.
Una plataforma de origen puede contener Customers registrados, compradores invitados, administradores que nunca compraron y Customers cuyo historial utiliza un email distinto al actual. Estos patrones no deben normalizarse en una sola forma de cuenta perdiendo significado histórico.
| Patrón de identidad de origen | Decisión de relación en EasyStore |
|---|---|
| Comprador registrado con login equivalente a Joomla | Vincular el Customer con el usuario Joomla correcto cuando el destino admita esa identidad. |
| Comprador invitado | Conservar datos del comprador y direcciones con Orders históricos sin inventar una cuenta permanente. |
| Varias cuentas de origen con el mismo email | Decidir si permanecen separadas, se consolidan o necesitan clave externa. |
| Cuenta de personal/administrador | Mantener identidad de permisos separada de estado de Customer salvo que también sea comprador. |
| Contacto B2B ligado a una organización | No colapsar organización, contacto, precios y permisos en un registro básico de Customer. |
Los grupos de usuarios de Joomla también deben permanecer separados de segmentos comerciales. Un grupo utilizado para permisos administrativos o contenido restringido no equivale automáticamente a Customer Group, audiencia de descuento o nivel mayorista.
Orders conservan instantáneas comerciales, no configuración activa
Un Order de EasyStore representa una transacción histórica. Su significado puede incluir identidad de Customer o invitado, direcciones, selecciones de Product/variante, cantidades, precios, descuentos, impuestos, envío, referencias de pago, estado, reembolsos/cancelaciones, notas y marcas de tiempo. Estos valores son instantáneas de lo ocurrido en la compra.
Los datos históricos de Order no deben sustituir configuración actual de Product, impuestos, envíos, pagos o proceso de compra. Una etiqueta de envío en un Order antiguo registra el método usado entonces; no define la configuración actual del transportista. Una referencia de pago conserva contexto de transacción; no configura una pasarela.
| Relación de Order | Significado histórico que debe conservarse |
|---|---|
| Referencia a Product o variante | Qué unidad vendible se compró, incluido el identificador de origen cuando sea necesario |
| Descripción de línea y valores seleccionados | El artículo y selección visibles para el comprador en el momento de compra |
| Relación con Customer o invitado | Quién realizó el Order y qué direcciones se utilizaron |
| Precio, descuento, impuesto y total | La instantánea comercial, no un recálculo bajo reglas actuales |
| Referencia de envío y pago | Método y contexto de transacción registrados para ese Order |
| Estado y cronología | Evidencia de ciclo de vida necesaria para soporte y generación de informes |
| Información de reembolso/cancelación | El cambio histórico respecto a la transacción original |
Cuando el origen almacena líneas independientemente de los Products actuales, esas instantáneas deben seguir siendo legibles incluso si el catálogo cambió, un SKU se retiró o una variante se reorganizó.
Coupons, Reviews y otras relaciones necesitan propietarios propios
Coupons y Reviews están relacionados con catálogo y Customers, pero no son campos de Product. Un Coupon puede contener elegibilidad, tipo de descuento, fechas, uso y relaciones con Product, Category o Customer. Una Review puede conectar identidad Customer/invitado con Product, puntuación, texto, estado y fecha.
Tratarlos como contenido decorativo pierde su significado relacional. Una Review sin vínculo al Product correcto queda huérfana. Un Coupon copiado solo como código puede representar una regla comercial diferente. Una wishlist, evento de analítica o carrito abandonado puede pertenecer a otra área de EasyStore o a un servicio externo y no debe inferirse a partir de datos principales de Customer u Order.
La integración con SP Page Builder representa referencias de presentación
EasyStore puede suministrar Products y elementos comerciales a diseños de SP Page Builder. Los bloques pueden renderizar listas de Products, búsqueda, Categories, filtros, precios, puntuaciones, títulos, controles de carrito, listas de deseos, contenido de Reviews y otros elementos. Estos bloques referencian datos comerciales; no controlan inventario de Product ni historial de Orders.
Un constructor visual de origen puede incrustar referencias de catálogo directamente en JSON o registros de diseño. El modelo de destino debe separar contenido editorial reutilizable, configuración estática de diseño y referencias dinámicas a EasyStore.
| Elemento de Page Builder | Interpretación de datos |
|---|---|
| Bloque de lista de Products | Consulta o referencia de presentación a Products de EasyStore |
| Bloque de Category | Relación de visualización con una Category de EasyStore |
| Bloque de precio, rating, título o miniatura | Campos renderizados desde el contexto de Product |
| Control de carrito o wishlist | Elemento interactivo público, no datos históricos de carrito |
| Bloque estático de texto o imagen | Contenido de página que puede necesitar migración independiente |
| Override de diseño personalizado | Implementación de presentación, no entidad comercial estándar |
Esta separación permite que Products y Categories sigan siendo autoritativos mientras los diseños se recrean o traducen según el modelo de presentación del destino.
Configuración, integraciones y datos personalizados deben clasificarse por propiedad
La configuración de EasyStore puede definir impuestos, proceso de compra, pagos, envíos, notificaciones por email, inventario y reglas de visualización. Estas configuraciones influyen en funcionamiento activo, pero no equivalen a Products, Customers u Orders. Los registros históricos pueden referirse a sus resultados sin contener la configuración futura.
Transportistas personalizados, integraciones de pago, extensiones de desarrollo, campos de base de datos personalizados, webhooks e identificadores externos añaden otras capas. El modelo de destino debe identificar si cada valor es un registro principal de EasyStore, identidad/ruta Joomla, referencia SP Page Builder, registro de integración o clave de sistema externo.
| Señal de datos personalizados | Requisito de traducción del modelo |
|---|---|
| ID de ERP/almacén a nivel de variante | Conservar en la variante vendible correcta, no solo en el Product principal. |
| Campo personalizado de Customer | Determinar si pertenece a EasyStore, datos de usuario Joomla o perfil externo. |
| Referencia de transacción de pasarela | Mantener con el Order histórico y su contexto de pago. |
| Identificador de envío específico del carrier | Mantener con el Order o relación de procesamiento que lo utiliza. |
| Fuente personalizada de datos de Page Builder | Identificar la entidad EasyStore referenciada y la configuración de presentación separada. |
| Tabla perteneciente a extensión | Definir entidad principal, propósito empresarial y responsable de destino antes de traducirla. |
Un modelo limpio de EasyStore es, por tanto, un mapa de propiedad: las entidades comerciales permanecen en EasyStore; login y acceso permanecen en Joomla; la composición visual permanece en SP Page Builder o capa de presentación; y los IDs externos permanecen vinculados a los registros que reconocen los sistemas conectados.
Conclusión
Migrar datos a EasyStore exige más que crear Products y Customers. Los Products pueden contener registros comerciales a nivel de variante; Categories, tags, marcas, Collections y especificaciones cumplen funciones diferentes de descubrimiento; usuarios Joomla y Customers pueden vincularse sin convertirse en la misma entidad; Orders conservan instantáneas históricas; y los diseños SP Page Builder referencian datos comerciales en lugar de controlarlos.
Mantener estos límites explícitos produce un modelo de destino capaz de sostener gestión de catálogo, identidad de Customer, servicio histórico, presentación pública y continuidad de sistemas conectados sin aplanar las capas Joomla y EasyStore en un conjunto de registros ambiguo.
Preguntas frecuentes
¿Las variaciones de EasyStore son solo opciones de visualización?
No. Una vez creadas, las variantes pueden tener precio, descuento, tratamiento fiscal, datos de envío, SKU, identificadores estandarizados, inventario, disponibilidad y visibilidad propios. Deben traducirse como registros vendibles cuando el origen utiliza combinaciones equivalentes.
¿Las especificaciones de Product deben convertirse en variaciones?
Solo cuando el valor define una combinación vendible seleccionable por el comprador. Las especificaciones informativas se representan mejor mediante Additional Data u otra estructura descriptiva para no crear variantes artificiales.
¿Las Categories de EasyStore son lo mismo que Menu Items de Joomla?
No. Las Categories organizan Products. Los Menu Items crean navegación y contexto de ruta y pueden apuntar a Category, Product, Collection o página de Page Builder.
¿Puede vincularse un usuario Joomla con un Customer de EasyStore?
Sí. EasyStore admite convertir un usuario Joomla en Customer, pero el usuario Joomla sigue siendo la identidad de login mientras EasyStore controla el perfil comercial y sus relaciones.
¿Los Orders migrados configuran pagos, envíos o impuestos?
No. Los Orders conservan contexto histórico de transacción. El funcionamiento futuro de pagos, envíos, impuestos y proceso de compra pertenece a la configuración de EasyStore y a las integraciones activadas en destino.
¿Cómo deben tratarse los diseños públicos de SP Page Builder?
Deben separarse en contenido estático, configuración de presentación y referencias a entidades EasyStore. Los datos de Product y Order deben seguir siendo autoritativos en EasyStore aunque Page Builder controle cómo aparecen los elementos públicos.