osCommerce abarca hoy dos etapas de datos sustancialmente distintas. osCommerce v4 ofrece varios front ends o canales de venta, Products configurables, grupos de Customers, atributos y propiedades de Products, marcas, control CMS, temas, Apps y precios avanzados. Sin embargo, muchas tiendas de origen siguen funcionando sobre bases de datos derivadas de 2.x o sobre instalaciones muy modificadas cuyas extensiones y estructuras de tablas no coinciden con v4.
Ese linaje constituye la primera decisión del modelo de datos. Un registro products_attributes de una tienda antigua no equivale automáticamente a un atributo, una propiedad o una relación de Product configurable actual en v4. Una tabla de extensión heredada puede contener stock, proveedores, vales, SEO o datos de Orders que v4 representa en otro lugar. Un Product actual de v4 también puede asignarse a canales de venta y grupos de Customers, relaciones que no existen de la misma forma en instalaciones antiguas.
Por ello, la planificación debe identificar qué generación de osCommerce es propietaria de cada registro, qué significa comercialmente y qué elementos relacionados deben seguir conectados en la tienda de destino.
El linaje de versiones es una frontera del modelo de datos de osCommerce
Las tiendas osCommerce v4 modernas y las tiendas heredadas no deben tratarse como si compartieran un único esquema uniforme. v4 es una plataforma Open-Source actual con varios front ends, control CMS, Products configurables, temas, Apps y un modelo administrativo más reciente. Las tiendas 2.x antiguas suelen utilizar extensiones directas de tablas, módulos instalados manualmente, archivos PHP modificados y contribuciones de la comunidad.
La tienda de origen también puede haber pasado por actualizaciones o forks. Sus nombres de tablas pueden resultar familiares aunque las definiciones de campos y las relaciones hayan cambiado. Por tanto, el linaje de versiones determina si una opción de Product, un grupo de Customers, un canal de venta, una página de contenido o un registro de extensión tiene un equivalente nativo actual.
| Evidencia del origen | Interpretación en osCommerce | Consecuencia para la migración |
|---|---|---|
| Registros actuales de Products y asignaciones de v4 | Modelo moderno de catálogo de osCommerce | Conservar Products, Categories, marcas, atributos, propiedades, canales y relaciones con grupos de Customers. |
| Tablas principales heredadas de 2.x | Modelo de registros anterior de osCommerce | Interpretar mediante las relaciones heredadas en lugar de aplicar etiquetas actuales de v4. |
| Tablas o columnas de extensiones comunitarias | Datos propiedad de una extensión | Identificar la extensión y el registro principal que modifica. |
| PHP y SQL modificados | Lógica comercial o esquema personalizado | Trasladar el significado comercial en vez de copiar el mecanismo antiguo. |
| Tienda derivada de un fork | Linaje de plataforma relacionado pero no idéntico | Confirmar las definiciones y los IDs de las entidades en la instalación real. |
| Clave de un sistema externo | Identificador de ERP, PIM, WMS, marketplace, contabilidad o preparación y envío | Conservar la identidad duradera entre sistemas. |
Esta distinción evita diseñar un modelo moderno de destino alrededor de supuestos que solo eran válidos para una instalación heredada.
Products, Categories, marcas y canales de venta están relacionados, pero son entidades distintas
En osCommerce v4 actual, un Product puede contener identidad principal, descripciones, identificadores, precio y coste, impuestos, modo de stock, imágenes, vídeo, configuración física, virtual o descargable, datos SEO, proveedores, notas y relaciones de marketing. Los Products pueden asignarse o restringirse por canales de venta y grupos de Customers. Las Categories también pueden asignarse a front ends y grupos de Customers concretos.
Esto va más allá de una jerarquía simple entre Product y Category. Un mismo Product puede compartirse entre varios front ends con distinta visibilidad, contenido, precios o contexto comercial. Una instalación multitienda de origen que duplica Products puede representarse mejor mediante una única identidad de Product con asignaciones por canal; otro origen puede necesitar Products separados porque la identidad comercial realmente difiere.
| Estructura del origen | Propietario en osCommerce v4 | Relación que debe conservarse |
|---|---|---|
| Artículo vendible canónico | Product | Identidad, identificadores, precio, stock, medios, impuestos y descripciones. |
| Jerarquía de navegación | Category y asignación de Product | Árbol de Categories y colocación muchos-a-muchos de Products. |
| Marca o fabricante | Relación de marca o proveedor | La identidad de marca sigue separada de la clasificación por Category. |
| Tienda regional o de marca | Front end o canal de venta | Disponibilidad de Product y Category por canal. |
| Catálogo específico para determinados compradores | Asignación de Product/Category a grupo de Customers | La visibilidad y disponibilidad permanecen vinculadas al grupo previsto. |
| Merchandising relacionado | XSell, UPSell, grupos de Products o relación de marketing | Los vínculos de merchandising permanecen separados de la pertenencia a Categories. |
El número de Products migrados dice poco sobre si el front end, la Category, el grupo de Customers o la marca correctos conservan la relación adecuada con cada Product.
Atributos, propiedades, Products configurables y grupos de Products cumplen funciones diferentes
osCommerce v4 actual distingue los atributos de las propiedades. Los atributos pueden definir valores seleccionables, usar plantillas, afectar precio o peso, admitir archivos virtuales o descargables y participar en el inventario de Products. Las propiedades describen características de Product y pueden utilizarse para presentación, filtros, búsqueda, comparación, grupos de Products, iconos, muestras, rangos y valores estructurados.
Por tanto, una opción del origen debe clasificarse según su función. Si el comprador selecciona un valor que cambia el artículo comprado, pertenece a la capa de atributos o Products configurables. Si el valor describe el artículo para buscarlo o compararlo, encaja en la capa de propiedades. Si agrupa Products para merchandising o por características compartidas, puede ser más adecuada una relación de grupo de Products.
| Significado en el origen | Estructura de osCommerce a considerar | Límite de la relación |
|---|---|---|
| Elección de talla o color | Atributo y valor asignado | Product, opción, efecto en precio/peso y valor seleccionado en la línea de Order. |
| Combinación con stock independiente | Product configurable o relación de inventario por atributo | Identidad del elemento hijo o combinación, cantidad, SKU y disponibilidad. |
| Especificación técnica | Categoría de propiedad, propiedad y valor | El dato estructurado permanece separado de una opción de compra. |
| Rango filtrable | Propiedad con presentación para filtro o búsqueda | Tipo, unidades, rango y valores de Product permanecen normalizados. |
| Conjunto reutilizable de opciones | Plantilla de atributos | Las definiciones siguen siendo reutilizables para los Products previstos. |
| Familia de Products o conjunto de comparación | Grupo de Products o relación entre Products | El significado del grupo permanece separado de la jerarquía de Categories. |
| Archivo digital | Product virtual/descargable y relación de atributo/archivo | Archivo, caducidad, límite de descarga, Product y contexto de Order. |
Los atributos heredados de osCommerce pueden necesitar reinterpretarse dentro de estas funciones modernas. Conservar el nombre antiguo del campo sin clasificar su comportamiento puede convertir una combinación vendible en un valor de filtro o una especificación en una opción que gestione inventario.
Stock, precios, proveedores, canales y grupos de Customers forman un grafo comercial
Los registros actuales de Products en v4 pueden incluir stock real u otros modos de stock, coste del proveedor, descuentos por cantidad, precio recomendado, clase fiscal, disponibilidad por canal, asignaciones a grupos de Customers y restricciones específicas por grupo. Otras Apps pueden ampliar funciones mayoristas, de marketplace, retail o empresariales.
Estas relaciones deberían modelarse como un grafo en vez de aplanarse dentro de columnas de Product. Un precio del origen puede pertenecer a un grupo de Customers, un umbral de cantidad, una regla de coste del proveedor, un canal, una moneda o una promoción. Un valor de stock puede pertenecer a un Product, una combinación de atributos, una ubicación o un almacén externo. Un código de proveedor puede ser un campo interno del Product o la clave de un registro externo de aprovisionamiento.
| Valor comercial | Propietario y relación | Significado que debe mantenerse |
|---|---|---|
| Precio minorista base | Product y moneda | Valor comercial predeterminado. |
| Visibilidad por grupo de Customers | Asignación de Product/Category al grupo | Acceso del comprador al objeto del catálogo. |
| Precio por grupo o mayorista | Product, grupo de Customers y regla de precios | Alcance de compradores previsto e importe. |
| Descuento por cantidad | Product y relación de umbrales | Cantidades de corte y efecto sobre el precio. |
| Coste del proveedor | Relación entre Product y proveedor | Propietario del aprovisionamiento, coste, moneda y clave del proveedor. |
| Disponibilidad por canal | Relación de Product/Category con front end | Dónde se ofrece el artículo. |
| Cantidad de inventario | Product o combinación configurable y propietario del stock | Identidad vendible y cantidad autoritativa. |
Los precios históricos de Orders deben permanecer como instantáneas históricas. No deberían recalcularse a partir del grupo actual del Customer, del canal o del precio actual del Product después de la migración.
Customers, grupos de Customers, direcciones y permisos tienen significados diferentes
Los grupos de Customers en osCommerce v4 pueden controlar la visibilidad de Products y Categories, la aplicación de impuestos, descuentos acumulativos y el tratamiento predeterminado de compradores invitados o recién registrados. Los registros de Customers también se conectan con direcciones, Orders, datos de comunicación y, potencialmente, Apps que aportan estructuras mayoristas, crédito, fidelización, marketplaces o B2B.
Un segmento del origen debe interpretarse por su función. Una exención fiscal, un segmento de marketing, una cuenta mayorista, una relación empresarial y un nivel de fidelización no constituyen necesariamente un único grupo de Customers. Algunos pertenecen a configuraciones principales de grupos, otros a una App y otros a un CRM o ERP externo.
| Concepto de cuenta en el origen | Propietario de osCommerce a considerar | Relación que debe conservarse |
|---|---|---|
| Comprador individual | Cuenta de Customer y libreta de direcciones | Identidad, acceso, direcciones y Orders. |
| Comprador invitado | Instantánea de Customer dentro del Order | Identidad histórica sin inventar una cuenta persistente. |
| Nivel mayorista o minorista | Grupo de Customers y reglas relacionadas de catálogo/precios | Pertenencia junto con visibilidad, descuentos y efectos fiscales. |
| Estado de exención fiscal | Configuración del grupo o campo específico del Customer/App | El significado legal o comercial permanece explícito. |
| Cuenta empresarial o profesional | App mayorista/B2B o entidad de cuenta externa | Varios usuarios y reglas comerciales permanecen conectados. |
| Administrador o usuario interno | Usuario de backend y permisos | El acceso del personal permanece separado de la segmentación de Customers. |
| ID de CRM/ERP | Identificador externo | Clave estable para volver a conectar sistemas. |
La etiqueta del grupo por sí sola no basta cuando dependen de ella distintos precios, Products, Categories, impuestos o condiciones de pago.
Orders conserva instantáneas de transacciones distribuidas entre varios registros relacionados
Los Orders de osCommerce pueden incluir la identidad del Customer o invitado, direcciones de facturación y entrega, instantáneas de Products y atributos, cantidades, precios, descuentos, impuestos, envío, información de pago, estados de Order, comentarios, transacciones, envíos, reembolsos, devoluciones, facturas y registros propiedad de extensiones. La administración actual de v4 también puede gestionar Orders manuales y el historial relacionado de Customers.
La migración de Orders debe conservar la transacción histórica, no intentar reconstruirla a partir de la configuración actual de Products o Customers. Un Product puede haber cambiado de nombre o precio. Un Customer puede haber cambiado de grupo. El módulo de pago puede haberse sustituido. El Order sigue siendo válido cuando sus propias líneas, totales, direcciones, estados y referencias explican lo ocurrido.
| Elemento del Order | Propietario histórico | Significado que debe mantenerse |
|---|---|---|
| Línea de Product | Instantánea de Product dentro del Order | Nombre/SKU del Product, cantidad, atributos seleccionados y precio en el momento de la compra. |
| Dirección de facturación/entrega | Instantánea del Order | Dirección histórica independiente de la libreta actual del Customer. |
| Importe de descuento/impuesto/envío | Registro de total o ajuste del Order | Etiqueta, importe, secuencia y aportación al total final. |
| Referencia de pago | Registro de transacción o módulo de pago | Evidencia histórica para conciliación. |
| Estado y comentarios del Order | Historial del Order | Secuencia de estados, fecha, visibilidad y contexto narrativo. |
| Envío/seguimiento | Registro de envío o preparación | Transportista, método, seguimiento y artículos enviados cuando estén representados. |
| Reembolso/devolución | Registro posventa relacionado | Importe, líneas afectadas, motivo y estado. |
La tienda de destino puede usar una nueva configuración activa de pagos y envíos y, al mismo tiempo, conservar las etiquetas y referencias vinculadas a Orders antiguos.
CMS, front ends, temas, URLs y contenido del catálogo tienen propietarios distintos
osCommerce v4 moderno incluye control CMS, varios front ends, temas, un diseñador visual de temas, contenido de Products y Categories, configuración SEO, imágenes, vídeos y valores específicos por idioma. Las instalaciones heredadas pueden utilizar extensiones de páginas informativas, páginas PHP estáticas, cajas de plantilla, archivos de idioma o contribuciones SEO.
Estos elementos visibles deben separarse entre los dominios de contenido, ruta, canal y presentación. La descripción de un Product pertenece al Product. Una página CMS tiene identidad y ruta independientes. La descripción de una Category pertenece a la Category. Un elemento de menú o una colocación en front end controla la navegación. Un tema y una plantilla definen la presentación. Una redirección conecta una ruta antigua con un nuevo destino.
| Recurso del origen | Propietario en destino | Implicación del modelo de datos |
|---|---|---|
| Descripción de Product/Category | Entidad del catálogo | Mantener el contenido con la entidad y el idioma correctos. |
| Página informativa o de políticas | Página CMS | Conservar identidad, ruta, jerarquía y visibilidad de la página. |
| Contenido específico de front end | Registro CMS/contenido más asignación de canal | Mantener conectados el contenido y su alcance por canal. |
| Nodo de menú o navegación | Configuración de navegación | La presencia del contenido no recrea automáticamente su colocación. |
| Bloque de tema o caja de plantilla | Capa de presentación | Reconstruir el diseño por separado del contenido subyacente. |
| Imagen/vídeo de Product | Relación de medios del Product | Conservar identidad del recurso, orden, idioma y vínculo con el Product. |
| URL heredada | Ruta de la entidad y redirección | Mantener relaciones entre rutas de origen y destino. |
Esta separación resulta especialmente importante al migrar desde una tienda 2.x antigua cuyo contenido está integrado en plantillas o extensiones hacia las estructuras actuales de CMS y front ends de v4.
Apps, extensiones heredadas, tablas personalizadas y sistemas externos amplían osCommerce
osCommerce v4 actual utiliza App Shop y admite Apps para pagos, envíos, marketing, comercio mayorista, marketplaces, contabilidad y otras funciones. Las tiendas heredadas suelen usar extensiones instaladas manualmente que modifican archivos principales y tablas de la base de datos. Ambos modelos pueden ser propietarios de registros situados fuera del esquema nativo de catálogo y Orders.
| Propietario de los datos | Ejemplos de registros | Decisión de traducción |
|---|---|---|
| Núcleo de osCommerce | Products, Categories, marcas, atributos, propiedades, Customers, Orders, CMS | Mapear mediante las relaciones nativas de datos. |
| App de v4 | Campos de App, entidades, transacciones, ofertas de marketplace, reglas mayoristas | Conservar con la App u otro propietario explícito en destino. |
| Extensión heredada | Columnas añadidas, tablas, estados, vales, SEO, stock, informes | Identificar la extensión y los registros principales que modifica. |
| Código personalizado | Tablas, procesos o cálculos a medida | Trasladar el significado comercial en lugar de la estructura antigua del código. |
| Servicio externo | Impuestos, pagos, envíos, búsqueda, marketplace, analítica | Conservar referencias históricas y claves activas de conexión. |
| ERP/PIM/WMS/CRM | IDs maestros de Product, Customer, stock, proveedor y Order | Conservar identificadores duraderos y la fuente autoritativa. |
Un campo de una extensión heredada no se convierte automáticamente en un campo de App de v4. Del mismo modo, que exista una App actual con un nombre parecido no garantiza que los datos de la extensión antigua tengan el mismo esquema o significado comercial. La frontera de migración debe definirse registro por registro.
Decisiones de traducción de osCommerce según el significado comercial
| Patrón del origen | Pregunta correcta de traducción | Consecuencia de una suposición incorrecta |
|---|---|---|
| Matriz heredada de opciones | ¿Es un atributo principal, una relación de Product configurable o una combinación de stock propiedad de una extensión? | Se pierden SKU secundarios, stock, precio o valores seleccionados. |
| Campo descriptivo de Product | ¿Pertenece a una propiedad de v4, al contenido, a una marca, a un proveedor o a un PIM externo? | La estructura de búsqueda y comparación queda incoherente. |
| Product duplicado entre tiendas | ¿Existe un único Product con asignaciones por canal o varias identidades comerciales realmente distintas? | El stock y el SEO se separan innecesariamente o se sobrescriben diferencias regionales. |
| Grupo de Customers | ¿Qué relaciones de visibilidad, descuento, impuestos o precios dependen de él? | La etiqueta del segmento sobrevive, pero se pierde su efecto comercial. |
| Total de Order procedente de un módulo antiguo | ¿Qué importe y etiqueta históricos deben mantenerse en el Order? | Los totales pasados dejan de poder explicarse. |
| Página estática heredada | ¿Es contenido CMS, código de plantilla, una ruta o un registro de extensión? | El contenido llega sin su propietario o navegación correctos. |
| ID externo | ¿Qué sistema y qué entidad identifica la clave? | Fallan la conciliación y la sincronización. |
Una migración hacia osCommerce tiene éxito cuando el modelo de destino refleja la generación correcta de la plataforma y conserva las relaciones entre los dominios de catálogo, canal, Customer, Order, contenido, App y sistemas externos.
Conclusión
La traducción del modelo de datos de osCommerce comienza separando las estructuras modernas de v4 de las instalaciones heredadas. v4 actual admite Products asignados a canales de venta y grupos de Customers, atributos, propiedades, relaciones de catálogo configurables, control CMS, varios front ends, temas, Apps y precios avanzados. Las tiendas antiguas pueden depender de tablas, extensiones y archivos modificados muy distintos.
La tienda de destino debe conservar la identidad de Products y Categories, los atributos seleccionables, las propiedades descriptivas, las relaciones con canales y grupos de Customers, las instantáneas históricas de Orders, la propiedad de CMS y rutas, y los identificadores externos duraderos. No debe asumir que un registro de una extensión heredada se vuelve nativo simplemente porque v4 actual ofrece una función con un nombre parecido.
Preguntas frecuentes
¿Por qué importa tanto la versión de osCommerce de origen?
Las tiendas v4 modernas y las tiendas 2.x heredadas utilizan arquitecturas y modelos de extensiones sustancialmente distintos. Una misma etiqueta puede referirse a tablas, relaciones o comportamientos diferentes, por lo que el linaje del origen determina cómo debe traducirse el registro.
¿Cuál es la diferencia entre atributos y propiedades en osCommerce?
Los atributos pueden representar valores seleccionables de Product y afectar al precio, el peso, el inventario o los archivos descargables. Las propiedades describen características estructuradas utilizadas para presentación, filtros, búsqueda, comparación o agrupación de Products.
¿Puede un mismo Product de osCommerce asignarse a varios front ends o grupos de Customers?
v4 actual admite asignar o restringir Products y Categories por front end, canal de venta y grupo de Customers. La migración debe conservar esas relaciones en lugar de duplicar Products sin necesidad.
¿Todas las opciones heredadas de Product deberían convertirse en relaciones modernas de Product configurable?
No. Algunas opciones solo ajustan el precio o capturan una selección del comprador, mientras que otras identifican combinaciones con stock independiente. El destino correcto depende del SKU, stock, precio, medios y comportamiento en las líneas de Order.
¿Cómo deberían tratarse los Orders históricos si cambian los módulos de pago o envío?
Deben conservarse las líneas de Products del momento de la compra, direcciones, totales, etiquetas de métodos, referencias de transacción, estados, envíos y registros posventa. La configuración activa del destino puede cambiar sin reescribir la transacción histórica.
¿Qué debería ocurrir con los datos de extensiones antiguas de osCommerce o Apps actuales de v4?
Hay que identificar la extensión o App, la entidad principal que amplía y cualquier sistema externo del que dependa. Los registros activos necesitan un propietario explícito en destino; los datos técnicos obsoletos pueden archivarse o excluirse en lugar de forzarse dentro de campos nativos.