osCMax se entiende mejor como una instalación de comercio electrónico derivada de osCommerce cuyo modelo de datos real viene determinado por el paquete instalado, las contribuciones, las plantillas, los archivos modificados y las estructuras de base de datos personalizadas. Dos tiendas osCMax pueden compartir tablas conocidas para Products, Categories, Customers y Orders y, aun así, funcionar de forma distinta porque una utiliza una contribución incluida en el paquete, otra acumula años de cambios directos en el código y una tercera depende de exportaciones personalizadas o sistemas externos.
Por eso, el linaje y la propiedad de los datos son más importantes que el nombre de los registros. Un campo de Product puede formar parte del núcleo derivado de osCommerce, ser una columna añadida por una contribución, un valor de presentación de la plantilla o una clave de una integración externa. Un total de Order puede ser un subtotal o un registro de impuestos estándar, o puede proceder de una contribución de descuentos, recargos, vales regalo, envíos o pagos. Un bloque visible en la tienda puede contener contenido de negocio y, aun así, estar controlado por el código de la plantilla y de los módulos, no por una entidad CMS.
Por tanto, el modelo de migración debe separar los hechos comerciales básicos del funcionamiento controlado por contribuciones y de los elementos de presentación. El objetivo no es reproducir todos los mecanismos heredados, sino conservar las relaciones entre Products, Customers, Orders, contenido e identificadores que siguen teniendo significado para el negocio.
El significado de los datos de osCMax empieza por el linaje y las contribuciones instaladas
osCMax se originó en la familia osCommerce, pero se distribuía con funcionalidad adicional y se ampliaba habitualmente mediante contribuciones. Las tiendas con muchos años de funcionamiento pueden contener varias generaciones de archivos del núcleo, parches de base de datos, plantillas, archivos de idioma, módulos de pago, módulos de envío, módulos de totales de Order y modificaciones específicas del comercio.
La versión de origen, por sí sola, no describe completamente el esquema. El código instalado y la base de datos deben interpretarse conjuntamente. Una tabla puede parecer estándar y contener columnas adicionales. Un campo conocido puede ser leído por código personalizado. Una contribución puede añadir sus propias tablas y relacionarlas con Products, Customers u Orders mediante identificadores internos. Por ello, el linaje de los datos debe analizarse en cada entidad, no solo como parte de un inventario técnico.
| Capa de origen | Evidencia habitual | Consecuencia para el modelo de datos |
|---|---|---|
| Núcleo derivado de osCommerce | Products, Categories, Customers, direcciones, Orders, fabricantes, reseñas | Normalmente se traduce mediante relaciones comerciales conocidas. |
| Capa del paquete osCMax | Mejoras incluidas, convenciones de plantillas, campos de administración | Confirmar si el valor es dato, configuración o presentación. |
| Contribución instalada | Tablas, campos, estados, informes, descuentos, vales o lógica de envío y pago añadidos | Identificar la contribución y sus relaciones con los registros principales. |
| Modificación del comercio | PHP editado, cambios SQL, archivos de idioma personalizados, exportaciones a medida | Tratarla como un límite de propiedad personalizado, no como comportamiento nativo de la plataforma. |
| Sistema externo | ERP, contabilidad, almacén, marketplace, CRM, fuente de datos del proveedor | Conservar los identificadores externos estables y la autoridad del sistema. |
| Elemento técnico obsoleto | Tablas de módulos abandonados, campos sin uso, archivos de plantillas antiguos | No convertir residuos técnicos sin uso en datos permanentes de la plataforma de destino. |
Esta lectura por capas evita un error frecuente: asumir que todos los registros de una tabla reconocible con estilo osCommerce tienen el mismo significado en todas las instalaciones osCMax.
Products, Categories, fabricantes y atributos forman el núcleo del catálogo
El catálogo base de osCMax suele girar en torno a Products, Categories, fabricantes, descripciones de Product, imágenes, stock, precios, ofertas especiales, reseñas y atributos de Product. Los Products pueden asignarse a Categories y, en instalaciones multilingües, los nombres y las descripciones pueden almacenarse por separado para cada idioma. Los atributos conectan nombres y valores de opciones con Products y pueden afectar al precio, el peso, el modelo, el stock u otros comportamientos según el conjunto de contribuciones instalado.
La relación entre Products, Categories y atributos es más importante que cada fila individual. Una tienda de origen puede utilizar un Product con varios atributos, registros Product independientes para cada SKU o tablas de stock por atributo controladas por una contribución. El modelo de destino no debe inferir variantes independientes solo porque existan valores de opciones, ni asignar todo el stock al Product principal si la tienda de origen vende combinaciones de forma independiente.
| Patrón de origen | Interpretación en osCMax | Relación que debe conservarse |
|---|---|---|
| Product estándar | Registro Product del núcleo | Identidad, descripción, precio, impuesto, stock, imágenes y vínculos con Categories. |
| Product asignado a varias Categories | Relación Product-Categoría | Una identidad comercial con varias rutas de descubrimiento. |
| Fabricante o marca | Registro de fabricante y vínculo con Product | La identidad de marca permanece separada de la ubicación en Categories. |
| Atributo de talla o color | Relación de atributo de Product | Nombre de la opción, valor, Product, efecto sobre precio/peso y etiqueta en la línea de Order. |
| Stock específico de una combinación | Registro de stock por atributos controlado por una contribución | Product, combinación de opciones, cantidad, SKU y clave externa. |
| Precio especial | Relación de oferta especial del Product | El precio activo y su contexto temporal permanecen separados del precio base. |
| Reseña | Reseña vinculada a Product y, cuando existe, a Customer | Puntuación, texto, fecha, estado e identidad de Product. |
Una descripción de Product puede mostrar casi cualquier información, pero no puede sustituir las relaciones estructuradas de Categories, fabricantes, atributos, stock o reseñas.
Las combinaciones de atributos, el stock, las imágenes y los precios suelen depender de extensiones
Las tiendas osCMax heredadas utilizan con frecuencia contribuciones para ampliar el modelo básico de atributos de Product. Estas extensiones pueden introducir stock por atributo, SKU independientes para combinaciones, imágenes adicionales, campos extra de Product, descuentos por cantidad, precios por grupo de clientes, vales regalo o constructores personalizados de Products. La tienda visible puede hacer que estas funciones parezcan nativas aunque sus registros se encuentren fuera de las tablas principales.
Cada elección debe clasificarse según su funcionamiento comercial. Una opción descriptiva no necesita inventario independiente. Una combinación vendible con SKU y stock propios sí. Un campo de texto introducido por el comprador pertenece a la línea de Order. Un precio por cantidad pertenece a una relación entre Product y umbral. Una imagen adicional puede pertenecer a un Product, un valor de opción o una contribución de galería de la plantilla.
| Funcionamiento | Propietario probable | Límite de traducción |
|---|---|---|
| La opción solo cambia el precio o el peso | Relación de atributos del Product principal | Conservar nombre de opción, valor, vínculo con Product y ajuste. |
| La combinación tiene stock o SKU independientes | Contribución de stock por atributos o de variantes | Conservar por separado la identidad de la combinación y su cantidad respecto del Product principal. |
| El comprador introduce un grabado o mensaje | Contribución de entrada de texto | Conservar el valor introducido en la línea del Order comprado. |
| El Product tiene varias imágenes de galería | Contribución de imágenes o convención de plantilla | Conservar la identidad del contenido multimedia y su relación con Product/opción. |
| Precio por cantidad o por cliente | Contribución de precios | Mantener conectados Product, umbral o grupo, moneda e importe. |
| Certificado o vale regalo | Contribución de vales y registros de Order relacionados | Conservar código, saldo, destinatario, canje e historial de Orders cuando sigan activos. |
La interpretación debe regirse por las relaciones reales entre tablas y código de la tienda de origen. Las exportaciones genéricas de atributos no son suficientes cuando una extensión mantiene la combinación vendible en otra estructura.
Customers, libretas de direcciones, grupos y extensiones de cuenta son elementos distintos
El modelo de Customer derivado de osCommerce suele incluir una cuenta de Customer, una libreta de direcciones, referencias a la dirección predeterminada, datos de acceso y preferencias de comunicación. Las contribuciones de osCMax pueden añadir grupos de clientes, estado de mayorista, identificadores fiscales, campos adicionales de perfil, datos de referidos, puntos de recompensa, crédito de cuenta o flujos de aprobación.
Estos registros deben separarse según su finalidad. Una dirección guardada es dato maestro reutilizable del Customer. Las direcciones de facturación y envío registradas en un Order son instantáneas de la transacción. Un grupo mayorista puede controlar precios o acceso. Una fuente de marketing o código de referido puede ser metadato para informes. Un identificador externo de CRM puede ser la clave que permita volver a conectar al Customer después de la migración.
| Elemento de cuenta de origen | Propietario | Significado que debe conservarse |
|---|---|---|
| Cuenta de Customer | Registro Customer principal | Identidad y vínculo con direcciones y Orders. |
| Entrada de la libreta de direcciones | Registro de dirección del Customer | Relación de dirección reutilizable. |
| Dirección de facturación/envío del Order | Instantánea del Order | Evidencia histórica de la transacción. |
| Grupo mayorista o distribuidor | Clasificación de Customer controlada por una contribución | Pertenencia al grupo y reglas relacionadas de precio/acceso. |
| Campo adicional de perfil | Campo de contribución o tabla personalizada | Finalidad del campo, privacidad y clave del Customer. |
| Puntos de recompensa o crédito | Contribución de fidelización/crédito | Saldo, historial de movimientos y proceso que lo gobierna. |
| Clave de ERP o CRM | Identificador externo | Identidad persistente entre sistemas. |
Una exportación plana de Customers puede conservar datos de contacto y, al mismo tiempo, perder la relación comercial que convertía al Customer en distribuidor, comprador exento de impuestos o titular de una cuenta de crédito.
Orders, totales, estados, pagos y envíos conservan evidencia histórica
Los Orders de osCMax pueden contener la identidad del Customer o invitado, instantáneas de facturación y envío, líneas de Product, etiquetas de atributos, cantidades, precios, impuestos, descuentos, envío, etiquetas de pago, estados de Order, comentarios y registros controlados por contribuciones. La capa de totales de Order es especialmente importante porque muchos módulos heredados crean líneas separadas para subtotal, impuestos, envío, cupones, vales regalo, recargos, cargos por pedido pequeño, descuentos o créditos.
Estas líneas no son intercambiables con la configuración actual del proceso de compra. Los Orders históricos deben conservar qué se cobró y por qué, aunque la tienda de destino utilice reglas diferentes de impuestos, envío, pago o promociones. Un identificador de transacción de un módulo de pago puede ser una evidencia histórica importante, pero las credenciales o el código del módulo antiguo no forman parte del registro de Order.
| Elemento del Order | Propietario histórico | Significado que debe conservarse |
|---|---|---|
| Línea de Product | Instantánea de Product en el Order | Nombre, modelo/SKU, cantidad, precio y atributos seleccionados en el momento de la compra. |
| Dirección | Instantánea de facturación/envío del Order | Dirección histórica independiente de los datos actuales del Customer. |
| Línea de total del Order | Módulo de totales de Order o registro de total principal | Etiqueta, importe, orden de presentación y efecto sobre el total final. |
| Referencia de pago | Registro de transacción del módulo de pago | Clave histórica de conciliación sin tratarla como configuración activa. |
| Método de envío y seguimiento | Módulo de envío y contexto del envío | Etiqueta de transportista/método, coste, seguimiento y evidencia del procesamiento logístico. |
| Estado y comentarios del Order | Historial del Order | Secuencia, fecha, visibilidad y contexto de personal/cliente. |
| Registro de devolución, vale o crédito | Registro posventa controlado por una contribución | Vínculo con el Order, importe afectado y saldo restante cuando corresponda. |
El modelo de Order es útil cuando el personal puede comprender la transacción original sin tener que reconstruir el módulo retirado que la generó.
El contenido, los bloques, las plantillas, los archivos de idioma y las imágenes tienen propietarios distintos
Las tiendas osCMax suelen utilizar plantillas, bloques, archivos de idioma, banners, páginas informativas, descripciones de Products, descripciones de Categories, imágenes, botones y bloques generados por contribuciones. Todos estos recursos afectan a lo que ve el comprador, pero no forman una única entidad de contenido.
Las descripciones de Products y Categories pertenecen a los registros del catálogo. Las páginas informativas pueden almacenarse en una contribución de contenido o en archivos estáticos. Los encabezados de bloques y el texto de la interfaz pueden vivir en archivos de idioma. La ubicación de un bloque pertenece a la plantilla. Los botones e iconos son recursos del tema. Un bloque promocional puede generarse desde la configuración en lugar de almacenarse como una página.
| Recurso de la tienda | Propietario de datos o presentación | Interpretación para la migración |
|---|---|---|
| Descripción de Product/Category | Registro del catálogo | Conservar el contenido con su entidad e idioma. |
| Página informativa o de políticas | Contribución de contenido o contenido estático | Conservar identidad de página, ruta y relación de navegación cuando siga activa. |
| Encabezado de bloque o etiqueta de interfaz | Archivo de idioma | Tratarlo como texto de interfaz, no como contenido CMS. |
| Ubicación del bloque | Configuración de plantilla | Reconstruir por separado la ubicación en la plataforma de destino. |
| Imagen de galería de Product | Product o contribución de imágenes | Conservar la relación multimedia y el alcance de opción/variante. |
| Botón, icono o fondo | Recurso del tema | Mantenerlo solo si sigue teniendo valor de diseño. |
| URL heredada | Product, Category, contenido o ruta personalizada | Mantener las relaciones de redirección entre origen y destino. |
Esta separación permite trasladar contenido y recursos multimedia valiosos sin arrastrar a la tienda de destino la maquinaria obsoleta de las plantillas.
Las contribuciones y las tablas personalizadas pueden ser propietarias de registros críticos para el negocio
El principal reto de osCMax es determinar la propiedad de las contribuciones. Una contribución puede añadir un campo a una tabla principal, crear una entidad independiente, modificar el cálculo de un Order, introducir un nuevo estado o mantener una relación mediante una clave personalizada. La decisión para el destino depende de la finalidad empresarial, no de lo fácil que sea exportar la fila de la base de datos.
| Patrón de contribución | Ejemplo de significado | Decisión necesaria sobre la propiedad |
|---|---|---|
| Columnas añadidas a Product | Código de proveedor, distintivo, garantía, restricción, estado de la fuente de datos | Asignarlas a un campo nativo, atributo estructurado, clave externa o archivo. |
| Tabla personalizada de Product | Compatibilidad, componente de paquete, suscripción, precios por niveles | Conservar la entidad y sus relaciones con Product cuando sigan activas. |
| Extensión de Customer | Aprobación, fidelización, referido, impuestos, estado de distribuidor | Mantener la clasificación y las reglas o el historial que le dan significado. |
| Extensión de Order | Indicador de fraude, estado de exportación, referencia de pago, lote de procesamiento logístico | Conservarla como metadatos históricos o reconectarla con el proceso de destino. |
| Tabla de informes/exportación | Estado de extracto contable u operativo | Conservarla solo si sigue siendo el registro empresarial que gobierna ese dato. |
| Lógica principal modificada | Cambios en impuestos, envío, precio o permisos | Representar la regla empresarial en el modelo de destino, no el antiguo mecanismo PHP. |
Cuando ningún proceso actual consume un registro de una contribución, archivarlo puede ser más preciso que forzarlo dentro de un campo personalizado genérico. Los registros activos necesitan un propietario explícito en el destino y vínculos estables con Products, Customers u Orders principales.
Decisiones de traducción de osCMax según el significado empresarial
| Patrón de origen | Pregunta correcta para traducirlo | Consecuencia de una suposición incorrecta |
|---|---|---|
| Tabla principal conocida con columnas adicionales | ¿Qué campos son del núcleo, del paquete, de una contribución o personalizados? | Los datos de una extensión se confunden con un campo nativo del destino. |
| Atributos de Product y tabla de stock independiente | ¿Qué combinación es propietaria del SKU y de la cantidad? | El stock del Product principal sustituye al stock de la combinación vendible. |
| Grupo de Customer o indicador de distribuidor | ¿Qué precios, reglas de acceso, impuestos o condiciones de pago dependen de él? | El nombre del grupo se conserva, pero desaparece su significado comercial. |
| Varias líneas de totales de Order | ¿Qué módulo creó cada importe y cómo afecta al total final? | Los totales históricos quedan incompletos o resultan engañosos. |
| Bloque de la tienda | ¿El valor es contenido, configuración, texto de idioma o ubicación en la plantilla? | El texto visible llega sin su ruta o ubicación, o se conserva código obsoleto como si fueran datos. |
| ID de exportación personalizado | ¿Qué sistema externo es propietario de la clave? | Products, Customers u Orders no pueden conciliarse después de la migración. |
| Tabla de una contribución abandonada | ¿Algún proceso actual sigue dependiendo de ella? | Los residuos técnicos se trasladan como desorden permanente al destino. |
Los datos de osCMax siguen siendo útiles cuando los hechos comerciales básicos se separan de los mecanismos de contribuciones o plantillas que antes los mostraban o procesaban.
Conclusión
La traducción del modelo de datos de osCMax empieza por el linaje. Products, Categories, Customers, direcciones, Orders, fabricantes, reseñas y atributos pueden seguir el núcleo derivado de osCommerce, pero las extensiones pueden añadir stock independiente, precios, vales, clasificaciones de Customer, totales de Order, estructuras de contenido, exportaciones y tablas personalizadas. Las plantillas y los archivos de idioma también determinan la presentación de la tienda sin convertirse por ello en entidades comerciales ordinarias.
Una plataforma de destino bien planteada conserva los hechos empresariales y las relaciones activas: identidad de Product, opciones vendibles, contexto del Customer, totales históricos de Orders, contenido útil e identificadores externos. No presupone que cada contribución, archivo modificado o elemento de una plantilla antigua necesite un equivalente directo en el destino.
Preguntas frecuentes
¿Por qué dos tiendas osCMax pueden tener modelos de datos diferentes?
Porque pueden diferir las versiones de los paquetes instalados, las contribuciones, las plantillas, los parches de base de datos y las modificaciones realizadas por el comercio. Por eso, tablas principales conocidas pueden contener campos distintos o ser interpretadas por código diferente.
¿Los atributos de Product de osCMax equivalen a variantes independientes?
No siempre. Los atributos principales pueden modificar un Product, mientras que una contribución puede añadir SKU, stock, precio o imágenes a nivel de combinación. La identidad vendible independiente debe inferirse de toda la relación, no solo de las etiquetas de opciones.
¿Cómo deben interpretarse los grupos de clientes o los campos de distribuidor?
Hay que identificar el funcionamiento que controlan, como precios, acceso, tratamiento fiscal, condiciones de pago o aprobación. La etiqueta de clasificación está incompleta sin las reglas comerciales relacionadas.
¿Por qué son importantes los registros de totales de Order de osCMax?
Porque pueden explicar subtotal, impuestos, envío, cupones, vales regalo, descuentos, cargos o créditos. Conservar solo el total final elimina la estructura que explica cómo se calculó históricamente el importe.
¿Deben migrarse como contenido las plantillas, los bloques, los botones y los archivos de idioma?
Solo cuando contengan contenido empresarial que deba seguir utilizándose. La ubicación, las etiquetas de interfaz y los recursos visuales pertenecen a la presentación. Su significado debe separarse de los registros de Products, Categories y contenido.
¿Qué debe hacerse con los datos controlados por contribuciones o tablas personalizadas?
Hay que identificar la contribución, los registros principales que amplía y el proceso que aún consume esos datos. Las relaciones activas necesitan un propietario explícito en el destino; los registros obsoletos pueden archivarse o excluirse en lugar de forzarse dentro de campos genéricos.