VirtueMart almacena registros comerciales dentro de un entorno Joomla, pero no utiliza el mismo modelo de Article como Product que J2Store o J2Commerce. Products, Categories de Product, fabricantes, precios, stock, campos personalizados, grupos de compradores, reglas de cálculo, Orders, métodos de envío y métodos de pago pertenecen a VirtueMart. Joomla aporta la identidad de usuario, menús, módulos, plantillas, marco de idiomas, enrutamiento, reglas de acceso y ecosistema de extensiones que rodean esos registros.
Esta división de propiedad convierte la migración en un problema de traducción de relaciones. Una variante de origen puede convertirse en un Product hijo, un campo personalizado u otra relación estructurada. Un segmento de Customers puede convertirse en un grupo de compradores que influye en precios y disponibilidad de métodos. Un valor fiscal o de descuento puede ser evidencia dentro de un Order antiguo o una regla de cálculo activa para futuros carritos. El destino correcto depende de la función empresarial de los datos de origen.
Límites de propiedad entre Joomla y VirtueMart
Una tienda VirtueMart se construye a partir de dos modelos conectados. El componente de comercio posee el catálogo y los registros transaccionales; Joomla posee gran parte del contexto del sitio y de identidad que expone esos registros.
| Área empresarial | Propietario principal en destino | Relación que debe conservarse |
|---|---|---|
| Identidad de Product y campos de catálogo | VirtueMart | Product con Category, fabricante, recursos multimedia, precio, stock, campos personalizados y Products relacionados. |
| Inicio de sesión del usuario | Usuario de Joomla | Usuario con comprador VirtueMart y registros de dirección. |
| Segmentación de compradores | Grupo de compradores de VirtueMart, en ocasiones combinado con acceso de Joomla | Comprador con precio, visibilidad, impuestos, pago o comportamiento de envío. |
| Ruta de la tienda | Menú, router, alias e idioma de Joomla y vista de VirtueMart | Product o Category con el destino preferido para el comprador. |
| Presentación de Product | Diseños de VirtueMart junto con plantilla y módulos de Joomla | Identificadores de registros con la salida correcta de página. |
| Pago y envío | Métodos y plugins de VirtueMart | Reglas activas de métodos con evidencia de Orders y comportamiento de proceso de compra. |
Un Product puede estar presente en VirtueMart mientras faltan su ruta para compradores, la ubicación en módulos o el contexto de idioma. Un usuario de Joomla puede existir mientras el grupo de compradores, dirección o historial de Orders correspondiente está desconectado. Ambos lados de la relación necesitan un responsable explícito.
Products, Categories, fabricantes y recursos multimedia
Los Products de VirtueMart pueden conectarse con múltiples estructuras comerciales. Un Product de origen puede necesitar una o varias Categories, fabricante, imágenes y archivos, campos de stock, dimensiones, disponibilidad, precios, impuestos, grupos de compradores, campos personalizados, Products hijos, Products relacionados, reseñas y contenido traducido.
| Significado en origen | Pregunta de destino en VirtueMart | Relación necesaria |
|---|---|---|
| Clasificación de Product | ¿Qué Categories de VirtueMart deben contener el Product? | Asignaciones Product-Category y jerarquía prevista. |
| Identidad de marca | ¿Debe ser fabricante, Category, campo personalizado o clave externa? | Relación Product-fabricante y cualquier relación con páginas de marca. |
| Galería y archivos | ¿Qué recursos son imágenes, archivos descargables o activos de contenido? | Función del recurso respecto al Product, orden y visibilidad. |
| Product relacionado o accesorio | ¿La relación representa merchandising, compatibilidad, sustitución o lógica de paquete? | Relación Product-Product con finalidad definida. |
| Stock y dimensiones | ¿Los valores pertenecen al Product o al Product hijo? | Propiedad sensible al inventario y al envío. |
| Reseñas y valoraciones | ¿Son registros nativos de VirtueMart, contenido Joomla o datos de extensión? | Relación entre autor, Product, valoración, texto y estado de publicación. |
La traducción de Categories no debe confundirse con la navegación de Joomla. Las Categories de VirtueMart organizan el catálogo comercial; los elementos de menú de Joomla exponen determinadas vistas de Category o Product. Por tanto, una jerarquía de Categories puede migrarse correctamente mientras la navegación de destino utiliza una estructura de rutas diferente.
Los registros de fabricantes también necesitan revisión semántica. Una marca de origen puede utilizarse solo como texto visible o controlar filtros, páginas dedicadas, exportaciones de catálogos, reglas de precios e identificadores de integración externa. El destino debe conservar las funciones que sigan siendo necesarias en lugar de convertir automáticamente cada etiqueta de marca en un objeto de destino concreto.
Products hijos, campos personalizados y significado de las variantes
Los campos personalizados de VirtueMart pueden describir Products, recoger datos del comprador, relacionar registros, activar funcionamiento de plugins o participar en estructuras seleccionables de Product. Los Products hijos pueden tener su propio SKU, precio, stock, dimensiones, imágenes o disponibilidad. Como ambos mecanismos pueden aparecer como opciones en la tienda, las “variantes” de origen no pueden mapearse de manera uniforme.
| Comportamiento en origen | Posible representación en VirtueMart | Significado que debe conservarse |
|---|---|---|
| Talla o color tienen SKU y stock propios | Relación Product padre-hijo, a menudo expuesta mediante un campo seleccionable | Cada elección resuelve al inventario y a la identidad de línea de Order correctos. |
| La elección cambia el precio pero comparte stock | Campo personalizado de Product o relación de precio configurada | El ajuste de precio permanece vinculado a la selección. |
| El comprador introduce texto o carga información | Campo personalizado de entrada del comprador o registro de extensión | El valor introducido permanece vinculado al artículo correcto del Order. |
| Especificación técnica | Campo personalizado descriptivo | El valor sigue siendo legible y, cuando corresponda, filtrable. |
| Product o Category relacionado | Relación de campo personalizado a nivel del sistema | El vínculo sigue resolviendo al registro previsto. |
| Configurador basado en plugin | Campo personalizado y tablas de datos propiedad del plugin | El estado de configuración tiene un propietario compatible en destino. |
La decisión de mapeo debe responder cinco preguntas: ¿la elección cambia SKU, stock, precio, imagen o preparación de pedidos? Si no cambia ninguno, puede ser descriptiva en lugar de una variante. Si cambia varios, es más probable que necesite un Product hijo o una estructura controlada por plugin que un simple campo de texto.
Los campos personalizados son definiciones reutilizables que luego se asignan a Products. Su definición, tipo, orden, visibilidad, propiedad de plugin y valor específico del Product son relaciones diferentes. Copiar solo el valor visible puede perder la definición que lo convierte en seleccionable o funcional.
Grupos de compradores, precios y reglas de cálculo
Los grupos de compradores de VirtueMart pueden influir en visibilidad del catálogo, precios de Products, impuestos, métodos de pago, métodos de envío y otras reglas comerciales. Por ello, un grupo de Customers del origen no es necesariamente equivalente a una única etiqueta de grupo de compradores de VirtueMart.
Los precios también pueden depender del contexto. Un Product puede tener precios asociados a rangos de cantidad, grupos de compradores, monedas u otras condiciones. Las reglas de cálculo pueden aplicar impuestos, descuentos, márgenes o modificaciones de precio y restringirse por Category de Product, fabricante, grupo de compradores, país, estado, moneda o fecha.
| Regla en origen | Relación en VirtueMart | Consecuencia de traducción |
|---|---|---|
| Lista de precios mayorista | Grupo de compradores más registros de precio de Product | La pertenencia del Customer y la elegibilidad del precio deben permanecer conectadas. |
| Compradores exentos de impuestos | Grupo de compradores, ubicación de dirección y reglas de cálculo | Identidad, geografía y condiciones de regla deben alinearse. |
| Descuento por Category | Category de Product más regla de cálculo | La regla depende de la pertenencia a Category, no de un campo de descuento copiado. |
| Impuesto regional | Contexto de país/estado más regla de cálculo | La dirección del Customer o del Order aporta parte de la entrada de la regla. |
| Promoción limitada en el tiempo | Regla de cálculo o cupón con fechas | El periodo activo y la operación aritmética deben permanecer explícitos. |
| Precio específico por moneda | Relación entre precio y moneda | Importe, moneda y contexto de presentación no deben confundirse. |
Los importes históricos de Orders y la lógica de cálculo activa pertenecen a capas diferentes. Un Order antiguo debe conservar el impuesto, descuento, moneda y total realmente registrados. No necesita que el motor de cálculo actual vuelva a calcular ese historial. En cambio, el nuevo proceso de compra depende de reglas activas del destino.
Compradores, direcciones, campos y Orders
VirtueMart suele vincular un usuario de Joomla con un registro de comprador, grupos de compradores y datos de dirección. Los Orders de invitados pueden existir sin una cuenta Joomla reutilizable. Los campos de comprador pueden recoger información de registro, facturación, envío, fiscalidad, empresa o específica de la transacción.
El modelo de destino debe asignar cada campo según su ciclo de vida:
- la identidad permanente de acceso pertenece al usuario de Joomla;
- la segmentación reutilizable del comprador pertenece a las relaciones de grupos de compradores;
- la información reutilizable de facturación o envío pertenece a registros de comprador/dirección;
- los datos de invitado pertenecen a la instantánea del Order;
- las notas de entrega o instrucciones de compra de un solo uso pertenecen al Order;
- los valores de membresía o consentimiento propiedad de extensiones pertenecen al sistema que los consume.
Los Orders son evidencia histórica. Pueden incluir instantáneas de Products, campos personalizados seleccionados, identidad del Product hijo, cantidades, precios, impuestos, descuentos, cupones, contexto de grupo de compradores, direcciones, etiquetas de pago y envío, estados, moneda, notas y facturas.
| Evidencia del Order | Por qué importa la relación |
|---|---|
| Product y Product hijo | Identifica el artículo vendible exacto, no solo el Product padre. |
| Selección de campo personalizado | Explica configuración, personalización o significado de opciones del Product. |
| Instantánea de comprador y dirección | Conserva quién compró y dónde se facturó o envió el Order. |
| Precio, impuesto, descuento y moneda | Explica el resultado financiero histórico. |
| Método de pago y envío | Proporciona contexto de soporte y preparación. |
| Estado y marcas de tiempo | Muestran el historial operativo del Order. |
| Referencia externa | Conecta registros de contabilidad, ERP, transportista o canal de venta externo. |
Los plugins de pago y envío pueden crear metadatos adicionales. La etiqueta histórica y la referencia del proveedor pueden pertenecer al Order migrado, mientras la configuración actual del plugin pertenece al entorno de destino.
Tienda, idiomas, URLs y presentación de Joomla
Los registros de Products y Categories de VirtueMart no determinan por sí solos el sitio que ve el comprador. Menús, módulos, overrides de plantillas, aliases, asignaciones de idioma, niveles de acceso y enrutamiento de Joomla dan forma a la tienda final.
Una URL de origen puede basarse en slugs de Products, Categories anidadas, prefijos de idioma, aliases de menú o una extensión SEO. Las rutas de VirtueMart pueden depender tanto de aliases comerciales como del contexto de menú de Joomla. La migración debe identificar el destino canonical de cada Product y Category de alto valor y después relacionar las redirecciones con ese destino.
Los datos multilingües pueden abarcar registros traducidos de Products y Categories, texto de fabricantes, etiquetas de campos personalizados, menús Joomla, módulos y metadatos. Una relación de idioma solo está completa cuando los registros comerciales traducidos resuelven mediante el idioma y contexto de ruta correspondientes en Joomla.
| Capa de tienda | Responsabilidad del modelo de datos |
|---|---|
| Aliases de Product y Category de VirtueMart | Identidad del lado comercial utilizada por las rutas. |
| Elemento de menú de Joomla | Punto de entrada y contexto de ruta para una vista. |
| Módulo | Consulta y ubicación que muestra Products o Categories. |
| Override de plantilla | Lógica de presentación que espera determinados campos o identificadores. |
| Asociación de idioma | Conexión entre contenido traducido, menús y registros comerciales. |
| Metadatos y destino canonical | Propiedad de la página de cara a buscadores. |
La lógica de presentación no debe insertarse en campos de Product únicamente para reproducir una página. Debe permanecer en la capa de presentación Joomla/VirtueMart, consumiendo los registros traducidos mediante relaciones estables.
Datos de plugins, personalizaciones y sistemas externos
Las tiendas VirtueMart suelen utilizar extensiones de pago, envío, campos personalizados, suscripciones, configuradores de Products, búsqueda, fuentes de catálogo, facturación, canales de venta externos, contabilidad y preparación de pedidos. Estas extensiones pueden crear tablas y referencias que no forman parte del modelo ordinario de Products, compradores u Orders.
| Dependencia | Datos que pueden quedar fuera de registros principales | Pregunta de destino |
|---|---|---|
| Plugin de campos personalizados | Valores de configurador, archivos aportados por el comprador, relaciones de Products hijos, lógica de precios | ¿Existe un plugin equivalente o un registro estructurado en destino? |
| Extensión de suscripciones o recurrencia | Planes, ciclos, renovaciones, referencias de pasarela, derechos | ¿Qué sistema será responsable del estado recurrente después de la migración? |
| Configurador o extensión de paquetes | Products componentes, fórmulas, configuraciones guardadas | ¿Puede el destino representar la configuración sin aplanarla? |
| Plugin de pago o envío | IDs de transacción, etiquetas, tracking, metadatos del método | ¿Qué valores son evidencia histórica y cuáles son configuración activa? |
| Integración ERP o contable | Claves de Product, Customer, impuestos, factura y Order | ¿Qué identificadores son duraderos y autoritativos externamente? |
| Override de plantilla o módulo | Expectativas sobre campos y reglas de presentación | ¿Qué identificadores traducidos deben permanecer estables para la presentación? |
Las columnas personalizadas de base de datos no se explican por sí mismas. Sus nombres pueden indicar almacenamiento, pero no finalidad empresarial. Cada valor que se conserve necesita un consumidor identificado, un ciclo de vida y una relación de destino.
Cómo cambian las diferencias de VirtueMart el alcance de migración
El alcance de VirtueMart debe expresarse como tratamientos de relaciones:
| Tratamiento | Ejemplos habituales en VirtueMart | Consecuencia para el alcance |
|---|---|---|
| Traducción directa de registros | Products, Categories, fabricantes, compradores, Orders, recursos multimedia | Mapear campos estándar e identificadores. |
| Reconstrucción de relaciones | Products padre-hijo, asignaciones de campos personalizados, grupos de compradores, precios, condiciones de reglas de cálculo | Reconstruir vínculos y entradas de reglas. |
| Estructura de presentación Joomla | Menús, módulos, rutas, contexto de idioma, overrides de plantillas | Asignar a la implementación del sitio de destino. |
| Datos propiedad de plugins | Configuradores, suscripciones, campos especiales de proceso de compra, metadatos de métodos | Definir un destino compatible o un archivo separado. |
| Continuidad con sistemas externos | Identificadores ERP, contabilidad, preparación de pedidos, fuentes de datos o canales de venta externos | Conservar claves duraderas y propiedad. |
| Retirada intencional | Plugins obsoletos, campos personalizados sin uso, rutas duplicadas, reglas abandonadas | Excluir con un motivo registrado. |
El modelo de datos es coherente cuando un Product puede seguirse a través de sus Categories, Products hijos, campos personalizados, precios, stock, reglas de grupos de compradores, líneas de Orders, rutas Joomla e identificadores externos sin depender de supuestos técnicos no documentados.
Conclusión
Las diferencias del modelo de datos de VirtueMart surgen de la interacción entre registros comerciales de VirtueMart y estructuras del sitio Joomla. Los Products pueden depender de Categories, fabricantes, recursos multimedia, Products hijos, campos personalizados, grupos de compradores, precios, reglas de cálculo y plugins. Los Customers pueden abarcar usuarios Joomla, registros de compradores, direcciones y grupos. Los Orders conservan instantáneas que deben seguir siendo comprensibles incluso si las reglas y plugins actuales cambian.
Una migración fiable traduce esas relaciones de forma explícita. Separa la evidencia histórica de Orders del cálculo activo y el funcionamiento del proceso de compra, mantiene el enrutamiento de Joomla separado de los registros de Product y proporciona un destino claro para los datos propiedad de plugins o sistemas externos. Así se conserva el significado comercial en lugar de limitarse a reproducir filas de base de datos.
Preguntas frecuentes
¿Por qué no todas las variantes de VirtueMart pueden mapearse al mismo tipo de opción?
Algunas elecciones son Products hijos con su propio SKU, stock, precio, imagen o dimensiones. Otras son modificadores de precio, campos personalizados descriptivos, datos introducidos por el comprador o configuraciones propiedad de plugins. Su función empresarial determina la estructura de destino.
¿Cuál es la diferencia entre una definición de campo personalizado y un valor de Product?
La definición establece el tipo de campo, funcionamiento, visibilidad y posible lógica de plugin. La asignación al Product proporciona el valor o selección para un Product concreto. Ambas relaciones pueden ser necesarias para que el funcionamiento de la tienda se conserve.
¿Cómo afectan los grupos de compradores al modelo de datos?
Los grupos pueden influir en precios, visibilidad, impuestos, métodos de pago, métodos de envío y otras reglas. Conservar solo el nombre del grupo sin sus miembros ni las reglas que lo consumen no conserva su significado empresarial.
¿Deben recalcularse los Orders históricos con las reglas fiscales y de descuento del destino?
No. Los Orders históricos deben conservar los importes y etiquetas registrados en el momento de la compra. Las reglas activas del destino gobiernan los nuevos carritos y deben permanecer separadas de la instantánea histórica.
¿Por qué importan los menús de Joomla si los Products se almacenan en VirtueMart?
Los menús pueden establecer el contexto de rutas y los puntos de entrada de la tienda. Los aliases de Product y Category pueden ser correctos mientras la URL preferida para el comprador sigue dependiendo de relaciones entre menú e idioma de Joomla.
¿Cómo deben traducirse los datos propiedad de plugins?
Identifica los registros que crea el plugin, las relaciones de Product, comprador u Order que consume y el sistema de destino que será responsable de la misma función empresarial. Conserva únicamente valores con un uso futuro definido.