CS-Cart representa el comercio mediante relaciones que pueden aplanarse con facilidad de forma incorrecta. Los Products pueden incluir Features, filtros, Options, excepciones de Options y Product Variations. Categories y Products pueden pertenecer a distintos alcances de escaparate. Las ediciones Multi-Vendor añaden vendedores, administradores de vendedor, Products propiedad de vendedores, Orders de marketplace, comisiones y contexto de pagos a vendedores. Los grupos de Customer pueden afectar precios, acceso y promociones. Las extensiones de plataforma pueden introducir registros que ni siquiera pertenecen al catálogo principal.
Estas diferencias importan porque etiquetas similares en el origen no garantizan el mismo funcionamiento. Un campo “color” puede ser un Feature descriptivo, un valor de filtrado, una Option que modifica el precio o un Feature utilizado para generar Product Variations separadas. Una tienda de origen puede traducirse a un escaparate independiente de CS-Cart, una rama regional de marketplace o simplemente una presentación localizada. Un proveedor puede ser una referencia interna en un sistema y un vendedor de marketplace con propiedad sobre Products y Orders en otro.
Por tanto, una migración hacia CS-Cart exige traducir la propiedad de las entidades y sus relaciones. El objetivo es conservar qué significa cada registro para el catálogo, escaparate, vendedor, Customer, Order y sistemas conectados, no solo reproducir nombres de campos.
CS-Cart separa hechos de catálogo, elecciones del comprador y Variations vendibles
CS-Cart utiliza estructuras distintas para hechos de Product y elecciones de Product. Features son propiedades inseparables como marca, material, ISBN o especificación técnica. Pueden agruparse y usarse para comparación, filtrado u organización del catálogo. Options son elecciones separables del comprador, como grabado, envoltorio de regalo o garantía; no tienen stock independiente, pero pueden afectar precio o peso. Product Variations son Products agrupados por valores seleccionados de Features, y cada Variation sigue siendo un Product con identidad comercial propia.
| Valor de origen | Responsable en CS-Cart | Significado que debe mantenerse distinto |
|---|---|---|
| Especificación técnica | Product Feature o grupo de Features | Describe el Product y puede apoyar filtrado o comparación. |
| Configuración de Product elegida por el comprador | Product Option y variante de Option | Cambia la configuración comprada sin convertirse en stock independiente. |
| SKU hijo por color/talla | Product Variation dentro de un grupo de Variations | Sigue siendo un Product y puede conservar SKU, precio, stock, imagen y visibilidad propios. |
| Combinación prohibida | Excepción de Option o regla de disponibilidad de Variation | Impide configuraciones no válidas en lugar de crear otro valor de atributo. |
| Elección reutilizable de merchandising | Option global o estructura tipo plantilla | Una definición puede asignarse a varios Products. |
| Faceta de búsqueda | Filtro basado en Features u otros valores compatibles | Requiere valores normalizados y relaciones correctas con Categories. |
La diferencia entre Variations y artículos de catálogo es especialmente importante. Cada Variation es un Product, pero puede o no ocupar un lugar visible propio en listados. Un catálogo de origen que muestra cada SKU hijo como Product separado puede necesitar varios artículos visibles; otro puede presentar un único padre y mantener la mayoría de las elecciones dentro de la página de Product.
Una migración que convierte todas las Options de origen en Features pierde comportamiento de compra. Convertir todas las especificaciones en Options crea elecciones innecesarias. Combinar todos los SKU hijos en un único Product puede eliminar inventario e identidad independientes. La estructura correcta sigue aquello que controla el valor de origen.
Products, Categories, Features y filtros forman el modelo de descubrimiento
Un Product de CS-Cart incluye campos comerciales principales, imágenes, precio, cantidad, estado, información de envío e impuestos, descripciones, Categories, Features, Options, archivos y valores propiedad de extensiones. Las Categories aportan jerarquía y alcance por escaparate; Features aportan hechos estructurados; filtros exponen valores seleccionados para el descubrimiento.
Una Category de origen puede representar navegación, una página de destino SEO, una marca, una clasificación técnica o una agrupación interna. Estos significados no deberían permanecer automáticamente como Categories. Una marca almacenada como Category puede encajar mejor como Product Feature. Un árbol de especificaciones usado para navegación facetada puede requerir grupos de Features y filtros. Una página de merchandising puede necesitar contenido y bloques además de asignaciones de Products.
| Estructura de descubrimiento en origen | Pregunta de traducción a CS-Cart | Consecuencia de la relación |
|---|---|---|
| Jerarquía de Categories | ¿Qué Categories siguen siendo visibles para compradores y cuáles son internas? | La asignación de Products y la propiedad por escaparate dependen de la respuesta. |
| Categories de marca | ¿Debe la marca convertirse en Product Feature? | La marca puede apoyar filtrado y comparación sin duplicar navegación. |
| Valores de facetas | ¿Son Features normalizados, Options o campos personalizados de una extensión? | Solo el responsable correcto puede producir filtros coherentes. |
| Products en varias Categories | ¿Qué Categories y escaparates deben exponer cada Product? | Un Product puede existir y aun así faltar en un recorrido importante. |
| Archivos de Product | ¿Son descargas, adjuntos, manuales o registros de extensión? | La propiedad del archivo determina acceso y significado en líneas de Order. |
Los códigos de Product de CS-Cart son identificadores, pero la plataforma no garantiza por sí sola que sean únicos en todo contexto. Cuando la tienda de origen depende de la unicidad de SKU para ERP, almacén o marketplace, la relación con identificadores externos debe ser explícita.
Los escaparates cambian el alcance de Products, Categories, Customers y configuración
El funcionamiento de escaparates de CS-Cart depende de la edición. En Store Builder Ultimate, los escaparates pueden operar como tiendas independientes con Products, Categories, configuraciones, bases de usuarios y mecanismos de proceso de compra propios. En Multi-Vendor Ultimate, pueden representar ramas regionales de marketplace con vendedores seleccionados, monedas, idiomas, métodos de pago y envío, temas, layouts y bloques.
Esto significa que “tienda” no es una unidad universal de origen a destino. Un mismo Product puede pertenecer a un escaparate, aparecer en varios mediante asignaciones de Category o seguir la visibilidad del vendedor entre ramas de marketplace. Las Categories pueden pertenecer a un escaparate o, en contextos de marketplace, tener un alcance más amplio. Cuentas de Customer y administradores también pueden ser globales o específicos según configuración.
| Contexto de origen | Interpretación en Store Builder | Interpretación en Multi-Vendor |
|---|---|---|
| Tienda de marca o regional | Escaparate independiente con catálogo y configuración propios | Rama de marketplace con vendedores seleccionados y configuración regional |
| Propiedad de Product | Product propiedad del escaparate que puede aparecer por Categories asignadas | Product propiedad de vendedor visible donde participa el vendedor |
| Precio de Product | Puede variar por escaparate | Normalmente sigue al Product del vendedor entre ramas salvo otra estructura de precios |
| Category | Pertenece a un escaparate específico | Puede ser global o asociarse a un escaparate específico |
| Base de Customers | Puede separarse por escaparate | Puede compartirse o acotarse según el diseño del marketplace |
| Administrador | Relación administrativa específica por escaparate | Administradores de marketplace y de vendedor tienen propiedades distintas |
El alcance de migración debe identificar si las diferencias del origen pertenecen a datos, configuración u operaciones independientes. Locale, moneda, pagos, envíos, tema y proceso de compra no sustituyen la propiedad de Product y Category. Un registro puede migrarse correctamente y aparecer en el escaparate equivocado si falta su relación de alcance.
Vendedores y Common Products añaden propiedad de marketplace
CS-Cart Multi-Vendor introduce al vendedor como propietario comercial, no como simple etiqueta de fabricante. Los vendedores pueden tener administradores, Products, participación en escaparates, líneas de Orders, métodos de envío, planes, comisiones, saldos, pagos y datos de perfil. Un campo de proveedor de origen solo debería convertirse en vendedor cuando la organización realmente posee actividad de marketplace.
Algunas implementaciones también usan Common Products o conceptos de catálogo compartido. Un Common Product puede aportar identidad compartida mientras las ofertas de vendedores conservan información comercial específica del vendedor. Esto es distinto de copiar el mismo Product en varios catálogos de vendedores y también de un Product propiedad de la tienda con metadatos de proveedor.
| Relación de origen | Destino en marketplace CS-Cart | Significado que debe conservarse |
|---|---|---|
| Fabricante o marca | Product Feature, valor similar a fabricante o datos de marca | Origen descriptivo sin propiedad del vendedor |
| Referencia de proveedor | Campo interno o identificador externo | Abastecimiento operativo sin comportamiento de cuenta de marketplace |
| Vendedor de marketplace | Registro de vendedor | Propiedad de Products, líneas de Order, comisiones y pagos |
| Administrador de vendedor | Usuario de vendedor o relación administrativa | El acceso pertenece al vendedor correcto |
| Artículo compartido con ofertas de vendedores | Common Product más datos de oferta específicos por vendedor cuando se utilice | La identidad compartida se mantiene separada de precio y stock del vendedor |
| Order de marketplace | Order padre y contexto relacionado con vendedor o líneas | Responsabilidad del vendedor y liquidación siguen siendo interpretables |
La migración de vendedores está incompleta si llegan sus Products sin propiedad de vendedor o si llegan cuentas de vendedor sin Products, administradores, contexto de Orders e identificadores externos. A la inversa, convertir cada proveedor de origen en vendedor crea relaciones de marketplace que nunca existieron.
Customers, User Groups y segmentación comercial
Los usuarios de CS-Cart pueden representar Customers, administradores y, en Multi-Vendor, usuarios de vendedores. User Groups pueden controlar precios, acceso, métodos de pago, métodos de envío y otras reglas. Un Customer también puede tener campos de perfil, direcciones, historial de Orders e identificadores externos.
Una etiqueta de Customer en origen debe interpretarse por función. Mayorista, VIP, distribuidor, personal, exento de impuestos, reseller o suscripción solo deberían mapearse a un User Group si ese grupo es el responsable correcto de ese comportamiento. Una cuenta de empresa con varios compradores puede requerir otra estructura o una extensión. Un segmento CRM usado solo para marketing no debería convertirse automáticamente en grupo de precios.
| Relación de Customer de origen | Posible destino en CS-Cart | Significado a conservar |
|---|---|---|
| Comprador individual | Usuario Customer y direcciones | Identidad, inicio de sesión, direcciones y Orders permanecen conectados. |
| Grupo de precios o acceso | User Group | El grupo controla una regla comercial real. |
| Etiqueta de marketing | Campo de perfil o CRM externo | Segmentación sin crear comportamiento comercial incorrecto. |
| Administrador de vendedor | Usuario de vendedor | El usuario pertenece al vendedor correcto, no a la población de Customers. |
| Cuenta empresarial externa | Datos personalizados de perfil, extensión o identificador externo | Los compradores siguen vinculados a la organización autoritativa cuando sea necesario. |
El historial de Orders y la segmentación de Customers deben permanecer separados. Un Order histórico puede registrar el precio e impuesto aplicados en el momento de compra; no debe recalcularse a partir del grupo actual del Customer después de migrar.
Los Orders conservan instantáneas comerciales y de marketplace
Un Order de CS-Cart puede incluir identidad de Customer o invitado, direcciones, referencias de Product y Variation, Options elegidas, cantidades, precios, descuentos, impuestos, envíos, etiquetas de pago, estados, notas, archivos, promociones y propiedad de marketplace. En Multi-Vendor, las estructuras relacionadas con vendedores y comisiones añaden otra capa.
Las líneas de Order son instantáneas históricas. El nombre, precio, stock, valores de Features o vendedor actuales de una Variation pueden cambiar posteriormente. El Order debe seguir explicando qué compró el Customer. Del mismo modo, las etiquetas históricas de pago y envío deben seguir siendo legibles aunque los métodos actuales sean configuración de la tienda de destino.
| Elemento de Order | Relación histórica que debe conservarse |
|---|---|
| Línea de Product | Identidad de Product o Variation, código, cantidad, precio y Options elegidas |
| Promoción | Importe de descuento y contexto de regla o Coupon cuando esté disponible |
| Impuesto | Importe y etiqueta aplicados al comprar |
| Envío | Transportista, método, seguimiento, cantidad procesada y contexto de vendedor cuando esté disponible |
| Pago | Etiqueta histórica del método y referencia de transacción cuando esté disponible |
| Contexto de vendedor | Propiedad del vendedor, comisión, pago o relación con Order de vendedor |
| Estado | Significado del ciclo de vida utilizado por soporte, procesamiento de pedidos e informes |
La tienda de destino no necesita reproducir todos los procesos obsoletos para conservar el historial, pero el Order importado debe seguir siendo inteligible. Un registro que muestra un total sin configuración de Product, vendedor, descuento, impuestos y contexto de estado no equivale al historial comercial de origen.
Contenido, idiomas, URL y presentación del escaparate
El contenido de escaparates CS-Cart puede incluir Pages, registros de Blog donde esté instalado, descripciones de Product y Category, banners, menús, bloques, layouts, temas, metadatos, nombres SEO y valores específicos por idioma. Estos activos tienen responsables distintos y no deben comprimirse en una única entidad genérica de contenido.
Las descripciones de Product y Category pertenecen al catálogo. Pages y navegación tienen jerarquía y alcance propios. Bloques y layouts describen presentación. Los nombres SEO y redirecciones gobiernan rutas. Los valores de idioma pueden almacenarse como traducciones asociadas con una entidad compartida en lugar de Products o Categories independientes.
| Activo de origen | Capa de destino en CS-Cart | Límite que debe conservarse |
|---|---|---|
| Traducción de Product o Category | Valor de catálogo específico por idioma | Una entidad permanece conectada con varios valores localizados |
| Página informativa | Jerarquía de Pages y asignación a escaparates | Contenido, relación padre, acceso y ruta siguen separados |
| Menú o elemento de navegación | Estructura de menú o bloque de escaparate | La navegación no se infiere únicamente de la existencia de Category |
| Banner o bloque promocional | Registro de presentación o marketing | La ubicación visual se separa de datos de Product subyacentes |
| URL heredada | Nombre SEO y relación de redirección | Ruta de origen y destino permanecen explícitos |
| Layout de tema | Configuración de presentación del destino | La estructura de tema no se confunde con contenido portable |
Esta separación es especialmente importante en entornos multitienda y marketplace, donde un mismo contenido puede ser global, específico por escaparate, específico por vendedor o específico por idioma.
Extensiones de CS-Cart, tablas personalizadas e integraciones poseen datos adicionales
Las extensiones de plataforma de CS-Cart pueden añadir campos de Product, funcionamiento de marketplace, registros de fidelización, suscripciones, reservas, Reviews, puntos de recompensa, datos de pago o envío, feeds externos y procesos personalizados. Sus registros pueden vivir en tablas específicas de extensión y depender de hooks, configuración, tareas programadas o servicios externos.
En CS-Cart, un Add-on es una extensión de plataforma y no una etiqueta genérica para campos ordinarios de Product. El alcance debe identificar la extensión, sus entidades y los registros principales que amplía.
| Responsable de datos | Registros típicos | Requisito de traducción |
|---|---|---|
| Núcleo de CS-Cart | Products, Categories, Features, Options, Variations, usuarios, Orders, escaparates | Conservar semántica de entidad y relaciones nativas |
| Capa Multi-Vendor | Vendedores, usuarios de vendedor, Products de vendedores, comisiones, pagos | Mantener propiedad del vendedor conectada entre catálogo y Orders |
| Extensión de plataforma CS-Cart | Reviews, recompensas, suscripciones, reservas, campos especiales de Product | Inspeccionar por separado el esquema de extensión y la capacidad de destino |
| Desarrollo personalizado | Tablas, campos, estados o registros de procesos a medida | Definir un destino explícito para cada relación comercial activa |
| Sistema externo | Artículo ERP, cuenta CRM, almacén, listado de marketplace, referencia contable | Conservar identificadores necesarios para conciliación y reconexión |
Los formatos de importación y exportación no definen todo el modelo de datos. Un campo puede exportarse sin incluir configuración o proceso relacionado de la extensión. A la inversa, un identificador externo puede ser pequeño en tamaño y esencial para conectar el registro migrado con ERP, PIM, WMS, CRM o datos de marketplace.
Decisiones de traducción de CS-Cart según la relación
Un mapeo fiable resuelve el responsable de cada valor de origen antes de elegir el campo de destino.
| Patrón de origen | Pregunta de traducción | Consecuencia de elegir el responsable equivocado |
|---|---|---|
| Color y talla con SKU hijos | ¿Es un grupo de Variations basado en Features? | Se pierde identidad independiente de Product, stock o visibilidad de catálogo |
| Grabado o envoltorio | ¿Es una Option sin stock independiente? | Una elección de servicio se representa erróneamente como Variation vendible |
| Especificación técnica | ¿Es un Feature y quizá un filtro? | Descubrimiento y comparación se vuelven incoherentes |
| Varias tiendas regionales | ¿Son escaparates independientes o ramas de marketplace? | Se mezcla el alcance de Products, Categories, Customers y configuración |
| Proveedor o vendedor | ¿Es abastecimiento descriptivo o propiedad de vendedor? | Products, usuarios, Orders, comisiones y pagos de vendedor se pierden o inventan |
| Nivel de Customer | ¿Es User Group, segmento CRM externo o relación empresarial? | Precio y acceso se vinculan a la estructura incorrecta de Customer |
| Campo de extensión | ¿Qué módulo de CS-Cart lo posee y qué registro amplía? | Los datos se copian sin la capacidad que los interpreta |
Una migración hacia CS-Cart conserva significado cuando hechos de catálogo, elecciones de compra, Variations, alcance de escaparate, propiedad de vendedores, segmentación de Customers, historial de Orders, contenido y registros de extensiones permanecen distintos pero conectados.
Conclusión
CS-Cart no es un esquema plano de Products y Orders. Features describen Products; Options representan elecciones separables; Variations siguen siendo Products agrupados por Features seleccionados. Los escaparates pueden poseer catálogo y alcance de Customers de forma distinta entre Store Builder y Multi-Vendor. Vendedores introducen propiedad de marketplace, mientras User Groups influyen en el trato comercial. Orders dependen del contexto histórico de líneas, promociones, impuestos, pagos, envíos, estados y vendedores. Extensiones y sistemas externos pueden poseer registros fuera de los tipos de datos principales.
El alcance más sólido asigna cada valor de origen a la estructura de CS-Cart que controla el mismo significado comercial. Así se protegen descubrimiento de Products, elecciones de compra, responsabilidad de vendedores, trato de Customers, Orders históricos, escaparates localizados y continuidad de integraciones sin forzar registros distintos dentro de campos superficialmente similares.
Preguntas frecuentes
¿Cuál es la diferencia entre un Feature y una Option de CS-Cart?
Un Feature es una propiedad inseparable del Product, como marca, material o ISBN, y puede apoyar filtrado o comparación. Una Option es una elección separable del comprador, como grabado, envoltorio o garantía; puede afectar precio o peso, pero no tiene stock independiente.
¿Cuándo deberían los SKU hijos del origen convertirse en Product Variations de CS-Cart?
Cuando cada hijo sigue siendo un Product y el grupo difiere mediante valores seleccionados de Features. El mapeo debe conservar SKU hijo, stock, precio, imagen y relaciones de visibilidad en lugar de combinar los hijos en una lista plana de Options.
¿Una tienda de origen siempre puede convertirse en un único escaparate de CS-Cart?
No. En Store Builder, un escaparate puede ser una tienda independiente con catálogo y Customers propios. En Multi-Vendor puede ser una rama regional de marketplace con vendedores seleccionados y configuración regional. El límite operativo del origen determina el modelo correcto.
¿Debe cada proveedor de origen convertirse en vendedor de CS-Cart?
No. Un vendedor posee Products de marketplace y registros comerciales relacionados con vendedores. Un fabricante, marca, código de proveedor o fuente de compra puede seguir siendo dato descriptivo o de sistema externo cuando no representa una cuenta de vendedor.
¿Por qué deben separarse los datos de extensiones de plataforma de los datos principales?
Una extensión puede poseer sus propias tablas, estados, configuración y relaciones. Copiar sus campos a un Product o Customer principal no conserva el proceso que interpreta esos campos.
¿Cómo deben traducirse los registros de catálogo compartido de un marketplace?
Separe la identidad compartida del Product de ofertas específicas de vendedores, precio, stock, propiedad y responsabilidad sobre Orders. Tanto si el destino usa Common Products como otra estructura, esas capas no deberían colapsarse en Products duplicados y sin relación.