J2Commerce combina la propiedad del contenido de Joomla con una capa comercial específica. Un elemento vendible puede depender de un artículo de Joomla, la Category del artículo, un alias, el idioma, el nivel de acceso, los medios, la ruta de menú y el estado de publicación, y al mismo tiempo mantener relaciones comerciales específicas de Product, precio, inventario, impuestos, opciones, proceso de compra y Orders. La migración solo funciona correctamente cuando esas dos capas permanecen conectadas.
El linaje de versiones también importa. J2Commerce actual es el sucesor activo de J2Store, mientras que generaciones anteriores de J2Store y J2Commerce pueden conservar estructuras de tablas, extensiones y convenciones de implementación diferentes. Un modelo de datos fiable no trata todas las instalaciones de comercio sobre Joomla como si fueran intercambiables. Primero identifica qué familia de versiones es propietaria de cada registro y después traduce su significado comercial a la estructura actual del destino.
El modelo de propiedad de J2Commerce
La distinción central se encuentra entre la identidad de contenido y la identidad comercial. Joomla aporta el marco de contenido que permite publicar una página de Product, asignarle una ruta, hacerla localizable mediante búsqueda y mostrarla al público correcto. J2Commerce aporta los registros comerciales que convierten ese elemento en algo comprable.
| Significado comercial | Propiedad habitual en Joomla | Propiedad habitual en J2Commerce |
|---|---|---|
| Título de Product, contenido extenso, alias, estado de publicación, idioma, nivel de acceso | Artículo de Joomla y registros CMS relacionados | El registro comercial referencia el elemento vendible |
| Jerarquía de categorías y agrupación de contenido | Categories de Joomla y relaciones de menú | Los listados de Products o filtros comerciales pueden utilizar esa agrupación |
| SKU, precio, stock, impuestos, peso, posibilidad de compra | Normalmente no pertenece principalmente al CMS | Product de J2Commerce y registros comerciales relacionados |
| Opciones del comprador y funcionamiento del tipo de Product | Puede mostrarse mediante diseños de Joomla | Opciones, variantes, lógica de tipo de Product o extensiones de J2Commerce |
| Identidad del comprador | Usuario de Joomla cuando existe una cuenta | Contexto de Customer, dirección, proceso de compra y Order |
| Ruta de la tienda online | Alias de Joomla, elemento de menú, router, idioma y contexto de acceso | El estado del Product determina si el resultado comercial puede utilizarse |
Esta separación explica por qué los recuentos de registros constituyen una evidencia débil. Un Product puede existir en la capa comercial y apuntar al artículo, Category, idioma o estado de publicación incorrectos. Del mismo modo, un artículo puede mostrarse correctamente y carecer de la relación comercial que proporciona precio, stock o controles de compra.
Identidad de Product, tipos de Product y relaciones vendibles
J2Commerce utiliza artículos de Joomla como base de contenido para los Products, pero el artículo no representa por sí solo el objeto comercial completo. Los Products de origen deben descomponerse en las partes que describen el elemento y las partes que controlan el funcionamiento de la venta.
Un Product físico sencillo puede traducirse de forma directa cuando un artículo, un registro comercial, un SKU, un precio y una posición de stock describen el mismo elemento. La complejidad aumenta cuando el origen utiliza variantes, bundles, descargas, suscripciones, membresías, reservas, depósitos u otros modelos especializados de Product. Estos patrones no son equivalentes simplemente porque aparezcan como opciones seleccionables en una página de Product.
| Patrón de origen | Pregunta de traducción hacia J2Commerce | Relación que debe permanecer explícita |
|---|---|---|
| Un Product sin opciones | ¿Qué artículo y registro comercial representan el elemento vendible? | Identidad artículo-Product, SKU, precio, stock, Category y estado de publicación |
| Variantes de talla o color | ¿Cada opción tiene su propio SKU, precio, stock, imagen, peso o disponibilidad? | Estructura principal de opciones hacia el resultado vendible correcto |
| Product descargable | ¿Qué archivos, estados de Order y derechos del Customer controlan el acceso? | Relación Product-archivo y Order-acceso |
| Suscripción o membresía | ¿Qué plan, renovación, grupo de usuarios o relación de acceso define la oferta? | Compra de Product hacia registros recurrentes o de estado de acceso |
| Reserva | ¿Qué fecha, recurso, capacidad, depósito o registro de asistente conserva el significado? | Product hacia registros de programación y reserva |
| Bundle u oferta configurable | ¿El bundle es un registro vendible, una colección de Products componentes o lógica de una extensión? | Oferta principal hacia componentes, precio, stock y evidencia de líneas de Order |
Una opción de origen solo debe convertirse en una opción de J2Commerce cuando se conserva el significado de la elección del comprador. Las especificaciones descriptivas pertenecen al contenido o a campos estructurados; las selecciones que controlan stock necesitan una relación vendible con inventario; los valores de personalización deben seguir asociados a la línea de Order correcta. Aplanar todos estos casos en un único campo genérico elimina significado operativo aunque el texto visible sobreviva.
Categories, menús, acceso y descubrimiento de la tienda
El descubrimiento de Products en J2Commerce está condicionado por estructuras de Joomla. Las Categories de Joomla agrupan artículos dentro del componente de contenido, mientras que los elementos de menú establecen destinos navegables e influyen en el enrutamiento. Los módulos, niveles de acceso, asignaciones de idioma, etiquetas y diseños de plantilla también pueden controlar dónde aparece un Product.
Por tanto, una taxonomía de origen puede requerir algo más que una importación uno a uno de Categories. El modelo de destino debe separar estas funciones:
- Clasificación: cómo organiza el personal los Products;
- Navegación: cómo llegan los compradores a listados y páginas de destino;
- Acceso: qué usuarios pueden ver el contenido o los controles de compra;
- Enrutamiento: qué alias y contexto de menú definen la URL preferida;
- Presentación: qué módulo o diseño compone la tienda online visible.
| Estructura de origen | Posible relación en el destino | Significado que debe conservarse |
|---|---|---|
| Product Category | Category de artículo de Joomla, regla de listado comercial o ambas | Agrupación administrativa y descubrimiento por parte del comprador |
| Colección dinámica | Filtro, consulta de módulo, etiqueta, campo personalizado o regla controlada por una extensión | La regla que determina la pertenencia, no solo los miembros actuales |
| Marca o fabricante | Campo estructurado de Product, Category, etiqueta, página de contenido o registro de extensión | Presentación, filtrado, navegación o identidad en un sistema externo |
| Catálogo restringido | Nivel de acceso de Joomla, grupo de usuarios, regla comercial o extensión | Quién puede ver o comprar el Product |
| Página de campaña | Artículo de Joomla, elemento de menú, módulos y Products vinculados | Composición de contenido, ruta y merchandising |
Un mismo Product puede ser accesible mediante varias rutas de Joomla. La migración debe asignar un destino preferido y conservar alias útiles o relaciones de redirección cuando sea necesario, en lugar de asumir que cada ruta de origen pertenece al propio registro de Product.
Customers, usuarios de Joomla, campos del proceso de compra y Orders
El significado del Customer se distribuye entre Joomla y J2Commerce. Un comprador registrado puede tener una identidad de usuario de Joomla, una o varias relaciones con grupos de usuarios, detalles de Customer, direcciones, campos del proceso de compra y Orders. Un comprador invitado puede no tener una cuenta Joomla reutilizable y aun así aparecer en registros históricos de Order.
El modelo de destino debe distinguir la identidad permanente de la evidencia transaccional:
| Valor de origen | Propiedad probable en el destino | Principio de traducción |
|---|---|---|
| Identidad de inicio de sesión y estado de la cuenta | Usuario de Joomla | Conservar la identidad única y la relación de cuenta cuando sea compatible |
| Función de acceso o membresía | Grupo de usuarios de Joomla, nivel de acceso o extensión comercial | Conservar la regla que utiliza esa pertenencia |
| Dirección reutilizable de facturación o envío | Registros de Customer/dirección | Mantener separada la propiedad de la dirección reutilizable de la instantánea de un Order concreto |
| Datos de contacto de invitado | Contexto de Customer específico del Order | No crear una cuenta persistente solo porque exista una dirección de correo electrónico |
| Número fiscal, nombre de empresa, instrucción de entrega | Campo de Customer, campo del proceso de compra, campo de dirección o campo de Order | Asignar según si el valor es reutilizable o específico de la transacción |
| Datos de marketing o consentimiento | Perfil de Joomla, registro de extensión o sistema externo | Conservar solo con un propietario y propósito claros |
Los Orders conservan lo ocurrido en el momento de la compra. Los nombres de Product, SKUs, cantidades, opciones seleccionadas, precios, descuentos, impuestos, envíos, etiquetas de pago, direcciones, estados, notas y referencias externas deben seguir siendo interpretables aunque el catálogo o la configuración actual del proceso de compra haya cambiado.
Los estados de Order deben traducirse por su significado operativo y no copiarse únicamente por etiqueta. Un estado de origen “complete” puede significar pagado, procesado logísticamente, cerrado o simplemente procesado. El estado de destino debe conservar la interpretación histórica sin insinuar que un plugin o proceso automatizado actual está activo.
Contenido, idioma, URLs y medios
Como la página de Product se apoya en contenido de Joomla, la migración debe identificar qué valores del origen pertenecen al artículo y cuáles pertenecen a los registros comerciales. Descripciones extensas, tablas técnicas, medios incrustados, documentos descargables, metadatos, asociaciones de idioma y configuraciones de acceso pueden afectar a la página aunque no sean campos de precio o inventario.
Las tiendas multilingües requieren traducir relaciones, no solo valores. Un Product traducido puede implicar artículos de Joomla separados, asignaciones de Category, alias, menús, módulos y asociaciones de idioma, además de texto comercial traducido. Copiar un código de idioma en una sola fila de Product no reconstruye esas relaciones.
Los medios también necesitan una propiedad clara. Una imagen de origen puede ser:
- la imagen principal de Product;
- una imagen de galería de Product;
- una imagen específica de una opción;
- una imagen incrustada en el contenido del artículo;
- un archivo descargable;
- un recurso de un módulo o página de destino.
Cada función puede requerir un destino distinto. Tratar todos los medios como una única galería de Product puede eliminar el funcionamiento de opciones, romper el contenido del artículo o exponer archivos que deberían permanecer controlados.
La continuidad de URLs depende de alias de Joomla, contexto de menú, enrutamiento, idioma y, en algunos casos, extensiones. El modelo de datos debe identificar los destinos canónicos de Product y Category, las URLs de origen que todavía aportan valor y la relación entre las redirecciones y las nuevas rutas de Joomla. Se trata de una decisión sobre propiedad de rutas y no simplemente de copiar slugs.
Extensiones, tablas heredadas e identificadores externos
J2Commerce puede ampliarse mediante paquetes de pago, envío, aplicaciones, informes, módulos y plugins. Estas extensiones pueden crear sus propios registros, añadir campos a Products u Orders, utilizar grupos de usuarios de Joomla o depender de identificadores externos. J2Commerce actual también tiene un linaje técnico distinto al de instalaciones heredadas de J2Store, por lo que las tablas y extensiones específicas de cada versión no deben mezclarse sin interpretación.
| Tipo de dependencia | Pregunta sobre el modelo de datos | Resultado adecuado en el destino |
|---|---|---|
| Extensión de pago o envío | ¿Qué etiquetas o referencias históricas pertenecen a los Orders y qué configuración pertenece a la extensión activa? | Conservar la evidencia del Order; asignar la configuración actual a la extensión del destino |
| Extensión de suscripción, reserva o depósito | ¿Qué planes, instancias, calendarios, saldos o derechos existen fuera de los registros ordinarios de Product y Order? | Asignar a un equivalente compatible, un sistema externo o una estructura definida por separado |
| Campos personalizados del proceso de compra | ¿El valor es un dato reutilizable de Customer, un dato de dirección, metadatos de Order o una entrada de línea de pedido? | Almacenarlo con el registro que controla su ciclo de vida |
| Extensión de informes | ¿Qué identificadores y relaciones de origen son necesarios para reproducir el informe? | Conservar los datos autoritativos subyacentes en lugar de limitarse al resultado del informe |
| Conexión ERP, CRM, contable o de almacén | ¿Qué IDs son claves estables y cuáles son estados temporales de sincronización? | Conservar los identificadores duraderos junto con un propietario externo identificado |
| Tablas heredadas de J2Store/J2Commerce | ¿Qué registros siguen teniendo significado comercial en la tienda activa? | Traducir el significado actual; no reproducir automáticamente estructuras técnicas obsoletas |
El nombre de una extensión no constituye un modelo de datos. El alcance debe identificar los registros que crea, las relaciones que utiliza y el sistema que será propietario de esas relaciones después de la migración.
Identificadores, límites entre versiones y linaje de registros
Los identificadores son especialmente importantes cuando una tienda ha pasado por J2Store, J2Commerce 4 y la generación actual de J2Commerce. Un mismo objeto comercial puede tener un ID de artículo de Joomla, un ID comercial heredado, un ID comercial actual, un SKU, una clave externa de ERP y uno o varios alias de URL. Estos identificadores están relacionados, pero no son intercambiables.
Un registro de destino debería tener normalmente una identidad interna autoritativa y conservar únicamente las claves heredadas o externas que sigan cumpliendo una función. Conservar cada ID técnico en un campo personalizado visible genera ruido sin reconstruir las relaciones originales. Eliminar todas las claves de origen puede volver imposibles la conciliación, las integraciones y la interpretación del historial de Orders.
| Identificador | Función que continúa | Tratamiento en el destino |
|---|---|---|
| ID de artículo de Joomla | Conecta el contenido con el elemento vendible en el origen | Utilizar para conciliar el origen; reconstruir el vínculo artículo-Product en el destino |
| ID heredado de J2Store o J2Commerce | Conecta registros comerciales antiguos y tablas de extensiones | Conservar en un registro controlado de correspondencias cuando registros posteriores sigan haciendo referencia a él |
| SKU o código de Product | Identidad operativa utilizada por el personal y los sistemas externos | Conservar como clave comercial cuando sea única y autoritativa |
| Clave externa de ERP, CRM o almacén | Conecta el Product, Customer u Order con otro sistema | Conservar junto con el sistema consumidor identificado |
| Alias o URL de origen | Ayuda a mantener la continuidad de rutas y redirecciones | Asignar al destino canónico en lugar de tratarlo como ID de Product |
El linaje del registro también determina si dos filas de origen representan duplicados, versiones históricas o Products separados. Esta cuestión debe resolverse antes de crear las relaciones del destino. Un modelo limpio puede conservar trazabilidad sin heredar estructuras de tablas obsoletas.
Cómo cambian las diferencias de J2Commerce el alcance de la migración
El alcance de J2Commerce debe organizarse alrededor del tratamiento de las relaciones, no como una lista plana de entidades.
| Tratamiento | Ejemplos habituales | Consecuencia para el alcance |
|---|---|---|
| Traducción directa de registros | Products, Customers, Orders, Categories, medios y contenido estándar con propiedad clara | Asignar campos y conservar los identificadores y relaciones necesarios |
| Reconstrucción de relaciones | Vínculos artículo-Product, relaciones usuario-Customer, opciones de Product, asociaciones de idiomas, dependencias de Category y menú | Reconstruir las conexiones dentro de la estructura del destino, no solo los registros |
| Configuración del destino | Menús, módulos, plantillas, reglas de acceso, configuración de pagos y envíos, funcionamiento fiscal activo | Asignar al responsable de la implementación del destino |
| Datos controlados por extensiones | Planes de suscripción, reservas, registros personalizados del proceso de compra, metadatos de plugins, informes personalizados | Definir un destino o exclusión explícitos |
| Continuidad con sistemas externos | IDs de ERP, claves contables, referencias de procesamiento de pedidos, membresías de CRM | Conservar claves duraderas y documentar el sistema consumidor |
| Retirada intencionada | Soluciones temporales obsoletas de J2Store, rutas duplicadas, campos sin uso, extensiones abandonadas | Excluir con un motivo registrado en lugar de trasladar deuda técnica |
El alcance es coherente cuando cada valor importante del origen tiene un propietario en el destino, cada relación dispone de un método de reconstrucción definido y toda estructura no compatible u obsoleta cuenta con un tratamiento explícito. Esto evita que el contenido de Joomla, los registros comerciales de J2Commerce y los datos de extensiones se migren como inventarios desconectados.
Conclusión
Las diferencias del modelo de datos de J2Commerce surgen de la combinación entre contenido de Joomla y una capa comercial específica. Los Products no son únicamente filas con precio y stock: están conectados con artículos, Categories, alias, acceso, idioma, medios, opciones, Customers, Orders y extensiones. Además, J2Commerce actual debe distinguirse de J2Store heredado y de estructuras anteriores de J2Commerce.
Una migración fiable traduce la propiedad y el significado comercial en lugar de limitarse a nombres de campos. Mantiene alineadas las identidades de artículo y Product, conserva el significado de las elecciones del comprador y de las líneas de Order, separa el enrutamiento de Joomla de los registros comerciales y asigna los datos de extensiones o sistemas externos a un destino claro. Este enfoque produce una tienda de destino cuyos registros siguen siendo comprensibles y utilizables dentro del entorno Joomla actual.
Preguntas frecuentes
¿Por qué un Product de J2Commerce no puede tratarse como una única fila de Product convencional?
Porque el elemento vendible puede depender tanto de un artículo de Joomla como de registros comerciales de J2Commerce. El contenido, el alias, la Category, el idioma, el acceso y el estado de publicación pueden pertenecer a Joomla, mientras que SKU, precio, stock, opciones y posibilidad de compra pertenecen a J2Commerce.
¿J2Commerce utiliza el mismo modelo de datos que J2Store heredado?
No. J2Commerce es el sucesor activo, pero las generaciones actuales y heredadas pueden utilizar tablas comerciales, extensiones y convenciones de implementación distintas. Las relaciones existentes de J2Store deben interpretarse y traducirse, no darse por idénticas.
¿Cómo deben traducirse las variantes y las opciones de Product?
Primero debe clasificarse qué cambia cada elección. Un SKU con stock propio, un modificador que solo cambia el precio, una especificación descriptiva y un campo de personalización tienen propietarios diferentes y no deberían convertirse todos en el mismo tipo de opción.
¿Dónde deben almacenarse los datos de Customer cuando intervienen usuarios de Joomla?
La identidad permanente de inicio de sesión pertenece a la relación con el usuario de Joomla, mientras que las direcciones reutilizables y los detalles comerciales pertenecen a los registros de Customer. Los datos de invitado y los campos específicos de una transacción deben permanecer asociados al Order correspondiente en lugar de crear cuentas artificiales.
¿Los menús y módulos de Joomla forman parte de los datos de Product?
No. Son estructuras independientes de presentación y enrutamiento de Joomla que utilizan datos de Product y del artículo. Las relaciones necesarias deben definirse aparte de la transferencia del registro de Product.
¿Cómo deben tratarse los datos controlados por extensiones y sistemas externos?
Hay que identificar el registro, su propósito comercial y el sistema que será propietario de él después de la migración. Los identificadores duraderos y las relaciones compatibles pueden conservarse; el estado técnico obsoleto no debe copiarse si no existe un consumidor que lo necesite.