EShop es una extensión de comercio electrónico para Joomla con sus propios registros de catálogo, Customers, Orders, precios, descuentos, impuestos, envíos, pagos y proceso de compra. Joomla aporta el contexto de identidad, rutas, módulos, idiomas, plantillas y sitio web que rodea esos registros. Una traducción de datos coherente debe preservar la frontera entre ambas capas y, al mismo tiempo, distinguir los registros comerciales históricos de la configuración activa.
Cuando EShop es la Plataforma de destino, campos de origen con nombres parecidos pueden necesitar representaciones diferentes. Un “atributo” del origen puede ser una opción de Product elegida por el comprador, un atributo informativo, un campo personalizado de Product, una pestaña de Product, un campo del proceso de compra o un identificador externo. Un grupo de Customer del origen puede controlar precios en lugar de permisos. Una ruta de página del origen puede depender de Menu Items de Joomla en vez de pertenecer directamente al Product. Por eso, las decisiones sobre el modelo de datos deben comenzar por el significado y la propiedad, no por las etiquetas.
EShop combina registros comerciales con la estructura del sitio Joomla
EShop es propietario de los principales registros de la tienda. Joomla es propietario de la identidad general del sitio, la navegación, los módulos, las plantillas, los idiomas, el acceso y la infraestructura de extensiones. Los plugins de pago, envío, importación, informes e integración pueden introducir datos o referencias adicionales.
| Capa de propiedad | Registros habituales | Consecuencia para la traducción de datos |
|---|---|---|
| Catálogo de EShop | Products, Categories, Manufacturers, opciones, atributos, campos personalizados, adjuntos, precios y stock | Conservar las relaciones de Product y distinguir las elecciones vendibles de la información descriptiva. |
| Historial comercial de EShop | Customers, grupos, direcciones, Orders, líneas de Order, cupones, vales, impuestos, envíos, pagos y estados | Mantener las instantáneas históricas y las relaciones que explican cada transacción. |
| Núcleo de Joomla | Usuarios, Menu Items, módulos, idiomas, alias, plantillas y acceso | Mantener el contexto de rutas, identidad y presentación sin tratarlo como datos del catálogo de EShop. |
| Plugins de EShop y Joomla | Pagos, envíos, importaciones, módulos, campos especializados e integraciones | Identificar al propietario del plugin y determinar si el registro es histórico, operativo o externo. |
| Sistemas externos | ERP, CRM, POS, procesamiento de pedidos, contabilidad e información de Products | Mantener identificadores estables en la entidad de EShop reconocida por el sistema externo. |
Este mapa de propiedad mantiene un registro de Product separado de la página de Joomla que lo expone y mantiene la referencia de pago de un Order separada de la configuración del plugin de pago utilizado para transacciones futuras.
Products, Categories, Manufacturers y relaciones de catálogo
Un Product de EShop puede participar en varias relaciones del catálogo: ubicación en Categories, identidad de Manufacturer, archivos multimedia, precios, stock, clase fiscal, medidas, opciones, atributos, campos personalizados, pestañas, adjuntos, Products relacionados, metadatos, alias y valores específicos por idioma. Una Plataforma de origen puede combinar o separar estos conceptos de manera diferente.
Las Categories pueden formar una jerarquía y recibir asignaciones de Products. Manufacturers ofrece una entidad de tipo marca independiente. Products relacionados, datos de comparación, listas de deseos, filtros, módulos y búsqueda pueden depender de la identidad del Product sin convertirse en campos del Product.
| Concepto del origen | Posible representación en EShop | Relación que debe conservarse |
|---|---|---|
| Familia de Product con SKU secundarios separados | Product principal con opciones, o Products separados conectados mediante relaciones de comercialización | Identidad vendible, stock, precio, archivos multimedia e identificadores externos en el nivel correcto |
| Marca o proveedor | Manufacturer | Relación entre Product y Manufacturer sin integrar Manufacturer dentro de la taxonomía de Categories |
| Árbol de departamentos | Jerarquía de Categories de EShop | Estructura padre-hijo, asignación de Products, alias, metadatos y contexto de idioma |
| Artículo relacionado o complementario | Relación con Product relacionado | Dirección y finalidad de la asociación Product a Product |
| Descarga, manual o ficha técnica | Adjunto o pestaña de Product | Propiedad del archivo, relación con Product, título, idioma y visibilidad |
| Datos técnicos del Product | Atributo, campo personalizado o pestaña de Product | Significado descriptivo sin crear selecciones innecesarias para el comprador |
La representación en el destino debe conservar la lógica administrativa del catálogo de origen. Dos Products con SKU e identidades de almacén diferentes no deben fusionarse únicamente porque compartan un título. En sentido contrario, un sistema de origen que crea un registro por talla puede representarse mejor mediante opciones de Product de EShop cuando esas combinaciones pertenecen a un mismo Product comercial principal.
Las opciones, los atributos, los campos personalizados y las pestañas de Product no son intercambiables
EShop distingue las elecciones del comprador de la información descriptiva de Product. Las opciones representan selecciones que un Customer realiza antes de añadir un Product al carrito, como talla o color. Los atributos describen información utilizada para detalle o comparación. Los campos personalizados pueden almacenar información adicional específica del Product. Las pestañas y los adjuntos pueden aportar contenido ampliado, vídeos, documentación o archivos.
| Estructura de EShop | Significado principal | Ejemplos del origen |
|---|---|---|
| Opción de Product | Elección del comprador que puede afectar la línea comprada | Talla, color, embalaje, acabado, nivel de servicio |
| Valor de opción | Selección permitida dentro de una opción | Pequeño, mediano, azul, caja para regalo |
| Atributo de Product | Característica informativa utilizada para descripción o comparación | Material, procesador, capacidad, compatibilidad |
| Campo personalizado de Product | Valor estructurado adicional no cubierto por los campos ordinarios | Código regulatorio, clasificación interna, referencia externa |
| Pestaña de Product | Sección de contenido ampliado en la página de Product | Especificaciones, garantía, vídeo, instrucciones de cuidado |
| Adjunto | Relación entre un archivo y un Product | Manual, certificado, ficha técnica, documento descargable |
Una opción de origen debe convertirse en opción de EShop únicamente cuando la selección del Customer forme parte de la línea de Product comprada. Una especificación técnica que no altere la elección vendible pertenece a un atributo, campo personalizado o sección de contenido. Aplanar estas estructuras puede generar combinaciones imposibles, páginas duplicadas o líneas de Order que ya no muestran lo que eligió el comprador.
También debe preservarse el significado comercial a nivel de opción. Cuando una selección del origen afecta precio, SKU, peso, imagen, stock o disponibilidad, la representación en el destino debe mantener juntas esas relaciones. Una etiqueta sin el funcionamiento comercial asociado no constituye un modelo de datos equivalente.
Customers, usuarios de Joomla, Customer Groups y direcciones tienen significados distintos
Los Customers de EShop pueden conectarse con identidades de usuario de Joomla, pero los datos de Customer incluyen relaciones comerciales específicas, como direcciones, Orders, listas de deseos, contexto de recompensas y asignación a grupos. La compra como invitado puede crear datos históricos de comprador y dirección sin que exista una cuenta registrada permanente.
Customer Groups es especialmente importante porque EShop puede utilizarlos para precios diferenciados de Products. En cambio, un grupo de usuarios de Joomla suele representar permisos o acceso. Por tanto, un “grupo” del origen debe clasificarse antes de trasladarlo.
| Registro del origen | Significado de destino en EShop o Joomla |
|---|---|
| Inicio de sesión registrado | Identidad de usuario de Joomla vinculada al Customer de EShop apropiado cuando sea compatible |
| Customer comercial | Perfil de comprador de EShop, direcciones, relaciones con Orders y contexto de grupo comercial |
| Comprador invitado | Identidad histórica y dirección almacenadas con Orders sin inventar una cuenta permanente |
| Nivel mayorista o nivel de precios | Customer Group de EShop cuando controla precios comerciales o elegibilidad |
| Administrador o función de contenido | Grupo de usuarios y estructura de permisos de Joomla, no Customer Group de EShop |
| Organización y contactos | Diseño separado de organización/contactos cuando un simple registro de Customer no puede conservar la relación |
La traducción de direcciones también debe distinguir las direcciones reutilizables de Customer de las instantáneas de Order. Un Customer puede actualizar una dirección después de una compra, pero el Order histórico sigue necesitando los datos de facturación y envío registrados en el momento de la transacción.
Orders conserva las elecciones de Product, los datos del proceso de compra y el historial comercial
Un Order de EShop puede conservar identidad de Customer o invitado, direcciones de facturación y envío, líneas de Product, valores de opciones seleccionadas, cantidades, precios, descuentos, cupones, vales, impuestos, envío, referencias de pago, moneda, estados, campos personalizados del proceso de compra, notas y marcas de tiempo. Estos registros explican qué ocurrió; no son instrucciones para calcular futuras transacciones en el destino.
| Elemento de Order | Significado histórico |
|---|---|
| Línea de Product | Identidad y descripción del Product comprado en el momento de la venta |
| Valores de opciones seleccionadas | Configuración real del Product elegida por el comprador |
| Campo personalizado del proceso de compra | NIF/IVA, instrucción de entrega, información de recogida, referencia empresarial u otro valor recopilado |
| Precio, descuento, cupón, vale e impuesto | Instantánea monetaria que no debe recalcularse con reglas nuevas |
| Método e importe de envío | Elección de entrega y cargo registrados para el Order |
| Método de pago y referencia de transacción | Contexto histórico del pago, no configuración activa de una pasarela |
| Moneda | Moneda utilizada para la transacción y sus totales registrados |
| Historial de estados | Evidencia del ciclo operativo utilizada para atención e informes |
Los campos personalizados del proceso de compra requieren una asignación propia. Algunos valores describen al Customer, otros una dirección, otros se aplican a un solo Order y otros identifican una empresa externa o un flujo de entrega. Colocar todos los valores del proceso de compra en el perfil de Customer puede crear datos obsoletos o incorrectos; conservarlos todos únicamente como texto en un Order puede volver inaccesibles identificadores empresariales reutilizables.
Precios, descuentos, impuestos, envíos y pagos tienen una vertiente histórica y otra de configuración
EShop admite precios de Product, precios por Customer Group, descuentos por cantidad, cupones, vales, tasas fiscales, zonas geográficas, monedas, plugins de envío y plugins de pago. Estos conceptos cumplen dos funciones diferentes en el modelo de datos.
Primero, los Orders históricos contienen el resultado comercial: precios cobrados, descuentos aplicados, impuestos registrados, envío elegido, referencias de pago y totales por moneda. Segundo, la tienda de destino contiene reglas activas y configuración de plugins que determinan el funcionamiento futuro.
| Área comercial | Registro histórico | Estructura operativa activa |
|---|---|---|
| Precio por Customer Group | Precio o descuento reflejado en líneas históricas de Order | Relación actual entre Product y grupo de precios |
| Cupón o vale | Código y efecto del descuento registrado en un Order | Definición, elegibilidad, fechas y uso restante del cupón o vale |
| Impuesto | Importe y etiqueta fiscal del Order histórico | Clase fiscal, tasa, zona geográfica y reglas actuales de cálculo |
| Envío | Etiqueta de método, cargo, dirección y contexto de seguimiento | Plugin de envío habilitado y condiciones actuales de tarifa |
| Pago | Etiqueta del método, referencia de transacción y estado | Plugin de pago habilitado, credenciales y configuración actual de procesamiento |
| Moneda | Moneda e importes registrados en el Order | Monedas publicadas y funcionamiento actual del cambio |
Separar ambas vertientes evita que los datos históricos sean sustituidos por reglas actuales y evita confundir un Order antiguo con una configuración operativa completa.
Los datos comerciales multilingües y las rutas de Joomla forman un modelo combinado
EShop admite datos de tienda multilingües, mientras Joomla aporta relaciones más amplias de idioma de contenido, Menu Items, módulos y rutas. Products, Categories, Manufacturers, opciones, atributos, campos personalizados, etiquetas y textos de la tienda pueden tener valores específicos por idioma. Menu Items y módulos de Joomla pueden exponer rutas o contenido de apoyo distintos para cada idioma.
Una Plataforma de origen que almacena todas las traducciones en un Product puede necesitar valores de EShop específicos por idioma. Un origen que utiliza registros de Product separados puede necesitar lógica de asociación o identificadores para conservar equivalencias. Las traducciones de interfaz y las sobreescrituras de idioma deben seguir separadas del contenido empresarial traducido.
| Registro de idioma o ruta | Significado en el destino |
|---|---|
| Campo traducido de Product o Category | Contenido comercial visible para el comprador en un idioma concreto |
| Idioma de contenido de Joomla | Asignación de idioma utilizada por registros del sitio y componentes |
| Menu Item específico por idioma | Punto de entrada público, alias y contexto de navegación para un idioma |
| Módulo específico por idioma | Bloque de apoyo de la tienda mostrado en contextos de idioma seleccionados |
| Cadena de idioma de interfaz | Texto de extensión o plantilla, no contenido de Product o Category |
| Alias y metadatos de Product | Valores relacionados con SEO y rutas vinculados al registro comercial correspondiente |
El registro de Product y la ruta que lo expone deben permanecer diferenciados. Un Menu Item de Joomla puede apuntar a una vista de EShop e influir en alias, jerarquía, idioma, acceso y contexto de plantilla, mientras que el alias del Product y el enrutador de EShop aportan su propio significado a la ruta. Traducir únicamente el título del Product no conserva esta estructura combinada.
Módulos, plantillas, temas y sobreescrituras de diseño son relaciones de presentación
EShop puede mostrar Products mediante páginas del componente, módulos de Joomla, artículos de Joomla, búsqueda, filtros y diseños personalizados. Las plantillas y sobreescrituras pueden cambiar la salida de Product, Category, carrito, proceso de compra y cuenta sin modificar los registros comerciales subyacentes.
| Objeto de presentación | Interpretación en el modelo de datos |
|---|---|
| Módulo de Product o Category | Presentación reutilizable que consulta registros de EShop |
| Artículo de Joomla que incorpora salida de Product | Registro de contenido que contiene o invoca una relación con EShop |
| Sobreescritura de plantilla | Lógica de presentación, no campo portátil de Product |
| Ajuste de tema o diseño | Configuración de presentación separada de la propiedad del catálogo |
| Módulo de filtro o búsqueda | Interfaz de descubrimiento que utiliza atributos de Product, Categories, Manufacturers u otros datos indexados |
| Página de destino personalizada | Contenido de Joomla o de un constructor que hace referencia a Products y Categories de EShop |
Esta separación permite que los datos de catálogo sigan siendo la fuente autorizada incluso cuando el destino utiliza otro constructor de páginas, plantilla o diseño de tienda.
Plugins, importaciones, tablas personalizadas y sistemas externos amplían el modelo principal
EShop admite plugins de pago y envío, importaciones y exportaciones, módulos, integraciones, campos personalizados y diseños personalizados. Las tiendas con muchos años de funcionamiento también pueden contener tablas modificadas, integraciones SQL directas, sincronizaciones programadas, informes personalizados o identificadores procedentes de ERP, CRM, POS, contabilidad y sistemas de procesamiento de pedidos.
| Señal de propiedad externa | Interpretación necesaria |
|---|---|
| Referencia de transacción de pago | Relación histórica entre Order y pago que puede ser necesaria para soporte o conciliación |
| Identificador de transportista o procesamiento de pedidos | Relación con Shipment u Order utilizada por un sistema externo |
| Clave de importación de Product | Identificador estable de Product u opción utilizado para sincronización repetida |
| Tabla personalizada del proceso de compra | Valores a nivel de Order, Customer, dirección u organización que necesitan propiedad explícita |
| ID externo de Product o Customer | Identificador que debe permanecer vinculado a la entidad de destino reconocida por el sistema conectado |
| Estado o metadatos creados por plugin | Significado definido por el plugin, no por un campo ordinario de EShop |
El destino no necesita copiar cada tabla del origen. Sí necesita un responsable explícito para cada valor crítico para el negocio y una decisión deliberada sobre si ese valor se convierte en un campo nativo de EShop, un registro perteneciente a un plugin, una relación de Joomla o una referencia de un sistema externo.
Conclusión
Una migración hacia EShop es una traducción entre capas de catálogo, transacción, Joomla, presentación, plugins y sistemas externos. Products, opciones, atributos, campos personalizados, Customers, grupos, direcciones, Orders, campos del proceso de compra, precios, impuestos, envíos, pagos, idiomas, rutas de Menu y módulos tienen distintos significados de propiedad y relación.
Un modelo de destino coherente conserva estas distinciones antes de transformar registros. Así se mantienen las elecciones del comprador vinculadas a las líneas de Product, los totales históricos vinculados a Orders, los grupos comerciales separados de los permisos de Joomla, las traducciones conectadas con los registros comerciales correctos y los identificadores externos asociados con las entidades utilizadas por los sistemas conectados.
Preguntas frecuentes
¿Las opciones y los atributos de Product de EShop son lo mismo?
No. Las opciones representan elecciones del comprador que pueden aparecer en la línea comprada. Los atributos describen información de Product utilizada para detalle o comparación. Los campos personalizados, pestañas y adjuntos cumplen funciones descriptivas adicionales.
¿Cada variación de Product del origen debe convertirse en una opción de EShop?
Solo cuando los registros del origen representan elecciones dentro de un mismo Product comercial. SKU separados con URL, ciclo de vida, inventario, archivos multimedia o identidades externas independientes pueden necesitar permanecer como Products separados o requerir un diseño padre-hijo más deliberado.
¿Los grupos de usuarios de Joomla equivalen a los Customer Groups de EShop?
No. Los grupos de usuarios de Joomla suelen controlar permisos y acceso. Los Customer Groups de EShop pueden representar segmentación comercial, como precios diferenciados. Un grupo del origen debe asignarse según aquello que realmente gobierna.
¿Dónde deben almacenarse los campos personalizados del proceso de compra?
El destino depende de su significado. Los valores de identidad reutilizables pueden pertenecer a un Customer u organización, los valores de dirección a una dirección, y las instrucciones o referencias específicas de una transacción al Order.
¿Los Orders históricos definen el funcionamiento futuro de impuestos, envíos y pagos?
No. Los Orders conservan importes, etiquetas, referencias y elecciones registradas en el momento de la compra. Los cálculos y el procesamiento futuros dependen de las reglas actuales del destino y de los plugins habilitados.
¿Cómo deben tratarse los Menu Items de Joomla alrededor de Products y Categories de EShop?
Los Menu Items deben seguir siendo registros de rutas y navegación que apuntan a vistas de EShop. Pueden influir en alias, jerarquía, idioma, acceso y contexto de plantilla, pero no sustituyen al Product o Category subyacente de EShop.