Bagisto no trata un catálogo de comercio electrónico como una colección plana de Products y campos personalizados. Su arquitectura basada en Laravel separa tipos de producto, atributos, familias de atributos, Categories, canales, idiomas, monedas, fuentes de inventario, grupos de Customers, Orders, CMS Pages, registros de marketing, paquetes, API y capas comerciales opcionales como marketplace o B2B. Un campo de origen solo resulta útil en Bagisto cuando llega a la estructura que realmente posee su significado comercial.
Esta diferencia cambia el alcance de la migración. Un valor de talla puede ser contenido descriptivo, un atributo utilizado para filtrar o parte de una relación de Product configurable. Una cantidad puede pertenecer a una fuente de inventario concreta en lugar de al Product de forma global. Una Store de origen puede corresponder a un canal de Bagisto con su propia Category raíz, idioma, moneda, tema y asignación de inventario. Una cuenta de empresa o un vendedor puede depender de un paquete instalado y no del modelo Customer principal.
Por tanto, la cuestión central no es si Bagisto tiene un campo con un nombre parecido. Lo importante es si la tienda de destino representa la misma relación: a qué registro pertenece el dato, qué controla y qué otras entidades deben seguir conectadas para conservar su significado empresarial.
Bagisto representa los registros mediante distintas capas comerciales
Bagisto combina entidades comerciales principales con configuración y estructuras pertenecientes a extensiones. Dos valores que aparecen uno al lado del otro en una exportación pueden corresponder a capas de destino diferentes. La identidad de Product pertenece al catálogo. Los campos disponibles para ese Product dependen de su familia de atributos. El alcance de la Store corresponde a canales. La propiedad del stock pertenece a fuentes de inventario. La segmentación de Customers corresponde a grupos o a una capa B2B/marketplace instalada. La presentación puede pertenecer a CMS Pages, temas o una tienda headless.
| Significado en origen | Propietario probable en Bagisto | Consecuencia para la representación |
|---|---|---|
| Artículo vendible | Product con un tipo definido | El tipo determina registros secundarios, elecciones de compra, procesamiento y comportamiento de precios. |
| Especificación del Product | Atributo asignado mediante una familia | Un texto visible no es automáticamente filtrable, comparable ni reutilizable. |
| Store, mercado o dominio | Canal con idioma, moneda, Category raíz, tema y relaciones de inventario | El contexto de Store debe seguir vinculado al catálogo y localización correctos. |
| Cantidad de almacén | Asignación y cantidad de una fuente de inventario | Un único número global puede perder la propiedad por ubicación. |
| Segmento de Customer | Grupo de clientes o estructura de cuenta perteneciente a un paquete | El significado de precio o acceso puede no caber en un único campo de Customer. |
| Venta histórica | Order con líneas, totales, direcciones, facturas, envíos, reembolsos y transacciones | El recuento de Orders por sí solo no conserva el historial comercial. |
| Funcionamiento comercial personalizado | Paquete de Bagisto, módulo a medida, registro controlado por API o sistema externo | El mapeo de campos principales no basta si otra capa posee la relación. |
Esta propiedad por capas explica por qué un mapeo campo a campo es poco fiable. El mismo valor de origen puede necesitar un destino distinto según afecte selección de Products, gestión del catálogo, localización, inventario, tratamiento de cuentas, informes o continuidad de integraciones.
Los tipos de Product definen las relaciones de venta
Bagisto admite varios tipos de Product, incluidos simple, configurable, virtual, bundle, grouped, downloadable y orientados a reservas. El tipo no es solo una etiqueta administrativa. Define qué se vende, si existen Products secundarios o vinculados, qué campos son relevantes, cómo se interpretan precio y stock y qué elige el comprador.
Un Product principal con variantes de color y talla puede convertirse en un Product configurable cuyas variaciones tengan SKU, precio, cantidad, imagen o visibilidad propios. Un kit solo corresponde a un bundle cuando sus componentes y reglas de selección encajan con esa relación. Un Product agrupado representa una colección de Products vendibles vinculados, no un único SKU con inventario. Un Product descargable necesita relaciones con archivos y acceso. Un Product de reserva añade disponibilidad y calendario que no existen en una fila de Product convencional.
| Patrón de origen | Relación de Bagisto que debe distinguirse | Implicación de alcance |
|---|---|---|
| Product principal con SKUs secundarios | Product configurable y variaciones | El contenido del principal y los valores comerciales de los secundarios no deben fusionarse. |
| Kit con componentes opcionales | Product bundle y selecciones del bundle | Elección de componentes, cantidades y precios pueden exigir una traducción estructural. |
| Conjunto comercial de artículos independientes | Product grouped y Products vinculados | Cada Product vinculado sigue siendo vendible y con inventario propio. |
| Servicio no físico | Product virtual o estructura de servicio perteneciente a un paquete | El significado de envío y procesamiento difiere del de Products físicos. |
| Artículo digital | Product downloadable, archivos, enlaces y reglas de acceso | La relación con el archivo es independiente del texto del Product. |
| Servicio o alquiler programado | Product booking o estructura personalizada | Disponibilidad y recursos no pueden representarse como simples opciones. |
La decisión sobre tipo de Product también afecta los Orders históricos. Una línea de Order debe seguir siendo comprensible aunque el destino represente el Product de otra forma. Conservar solo el nombre del Product sin la variación elegida, el componente del bundle, la descarga o el contexto de reserva deja un historial técnicamente presente pero semánticamente incompleto.
Los atributos y familias gobiernan el significado del catálogo
Los atributos de Bagisto estructuran información de Product. Las familias agrupan los atributos disponibles para una clase concreta. Esto significa que los campos personalizados del catálogo de origen no deben copiarse indiscriminadamente a una única forma universal de Product.
Un campo utilizado para filtrado requiere un tratamiento diferente de otro usado solo como referencia interna. Un valor que crea una elección configurable debe distinguirse de una especificación descriptiva. Un título localizado, un precio, un SKU único, una marca booleana de Store y una especificación técnica multiselección no comparten el mismo tipo de entrada, validación, indexación ni comportamiento por canal o idioma.
El diseño de familias convierte, por tanto, las convenciones del catálogo de origen en un esquema controlado de la tienda de destino. Un comercio que vende ropa, maquinaria, manuales descargables y servicios reservables puede necesitar familias distintas porque cada grupo requiere atributos y relaciones comerciales diferentes.
| Funcionamiento del campo de origen | Interpretación en Bagisto | Qué debe seguir siendo cierto |
|---|---|---|
| El comprador elige el valor | Atributo configurable o elección propia del tipo de Product | El valor elegido identifica la variación o resultado vendible correcto. |
| El comprador filtra por ese valor | Atributo de Product filtrable | Los valores están suficientemente normalizados para filtrar con sentido. |
| El personal compara Products por ese dato | Atributo comparable o estructurado | Los hechos equivalentes no quedan enterrados en descripciones. |
| El campo solo existe para una clase de Product | Atributo asignado a una familia específica | Products no relacionados no reciben un esquema universal sobredimensionado. |
| El valor cambia según idioma o canal | Dato localizable o específico de canal cuando sea compatible | El contexto correcto recibe el valor correcto. |
| El valor es metadato interno de integración | Atributo personalizado, registro de paquete o identificador externo | Los identificadores operativos no se exponen ni reutilizan como contenido de Store. |
Esta separación evita una distorsión frecuente: tratar todas las opciones, especificaciones, etiquetas, campos creados por aplicaciones y códigos internos como el mismo tipo de atributo. Bagisto puede contener información de Product muy rica, pero esa flexibilidad solo aporta valor si cada dato se asigna a la familia y función correctas.
Categories, canales, idiomas y fuentes de inventario forman el alcance de Store
Las Categories de Bagisto organizan Products, pero las relaciones de canal determinan qué catálogo y contexto de localización utiliza cada Store. Un canal puede incluir dominio, Category raíz, idiomas, monedas, tema y asignaciones de fuentes de inventario. Por ello, una Store de origen, un catálogo regional, un sitio por idioma o una Store de una unidad de negocio pueden requerir algo más que un árbol de Categories.
Las Categories pueden servir para navegación, páginas de merchandising, clasificación interna o estructura heredada. Bagisto debe recibir las relaciones que siguen siendo útiles, no cada etiqueta histórica. La Category raíz asignada a un canal es especialmente importante porque define el inicio de la jerarquía de catálogo de ese contexto.
Las fuentes de inventario añaden otra dimensión de propiedad. Un Product puede tener stock distribuido entre ubicaciones. La cantidad de origen debe interpretarse junto con el almacén, sucursal, proveedor, punto de recogida o contexto de procesamiento. Sumar todas las ubicaciones puede conservar el total y destruir la disponibilidad por ubicación.
| Capa de alcance | Relación que mantiene Bagisto | Ambigüedad típica en origen |
|---|---|---|
| Category | Jerarquía padre-hijo, asignaciones de Products, contenido localizado y significado de URL | Las Categories de origen pueden mezclar navegación, SEO y clasificación interna. |
| Canal | Dominio, Category raíz, idioma, moneda, tema y contexto de inventario | Una “Store” puede representar en realidad un mercado, idioma, marca o unidad de negocio. |
| Idioma | Valores traducidos de Products, Categories y contenido | Los idiomas pueden existir como registros duplicados o campos en lugar de relaciones. |
| Moneda | Presentación y contexto comercial de la Store | La moneda histórica del Order debe mantenerse separada de la configuración actual del canal. |
| Fuente de inventario | Stock perteneciente a una ubicación | Una sola cantidad de Product puede ocultar varios almacenes o pools de stock. |
Un Product puede existir correctamente en Bagisto y seguir siendo invisible o comercialmente incorrecto si está vinculado a la Category raíz equivocada, no está disponible en el canal previsto, carece de valores localizados o utiliza una fuente de inventario incorrecta. Son fallos de relación aunque todos los registros estén presentes.
Customers, grupos, vendedores marketplace y cuentas B2B representan identidades diferentes
Los Customers principales de Bagisto incluyen identidad, contacto, direcciones y relación con grupos. Los grupos pueden influir en el tratamiento comercial, incluidos precios o elegibilidad para reglas. Sin embargo, vendedores marketplace, empresas B2B, usuarios de empresa, funciones de aprobación, listas de solicitud, presupuestos y órdenes de compra pueden pertenecer a paquetes opcionales y no al Customer principal.
Una etiqueta de origen como wholesale, dealer, distributor, employee, tax-exempt, approved buyer o vendedor del marketplace debe interpretarse por finalidad. Algunos valores corresponden a un grupo de Customers. Otros representan una empresa, una organización vendedora, un rol de permisos, una relación de crédito o una clasificación externa de CRM. Aplanarlos en un campo de texto conserva la etiqueta y elimina la relación que la hacía operativa.
| Identidad de origen | Pregunta sobre el destino en Bagisto | Relación que debe conservarse |
|---|---|---|
| Comprador individual | Customer principal y direcciones | Identidad, contacto, asociación de cuenta e historial de Orders. |
| Segmento comercial | Grupo de Customers o relación de precios | El segmento sigue separado de etiquetas arbitrarias. |
| Comprador de empresa | Empresa B2B y estructura de usuarios cuando exista | Los usuarios siguen vinculados a empresa, rol y contexto comercial correctos. |
| Vendedor marketplace | Registro de vendedor/proveedor perteneciente al paquete marketplace | Products, Orders, comisiones, pagos y usuarios del vendedor siguen vinculados. |
| Cuenta externa de CRM o ERP | Customer más identificador externo | La tienda de destino puede reconciliar el Customer con la cuenta que gobierna el sistema externo. |
El destino correcto depende de la instalación real. Bagisto principal, Multi Vendor Marketplace, B2B Marketplace, B2B eCommerce y los paquetes multi-tenant no comparten un único esquema universal de Customers. Sus registros deben tratarse como dominios de propiedad distintos, no como estructuras intercambiables.
Los Orders conservan el contexto comercial histórico
Un Order de Bagisto se relaciona con identidad de Customer o invitado, direcciones, líneas de Order, configuraciones de Product elegidas, precios, descuentos, impuestos, envío, etiquetas de pago, estados, facturas, envíos, reembolsos y transacciones. Estas relaciones explican lo ocurrido; la cabecera del Order por sí sola no basta.
Los Orders históricos también contienen instantáneas. Nombres de Product, precios, impuestos, direcciones y selecciones de opciones reflejan el momento de compra aunque el Product o Customer actual cambie después. Sustituir esas instantáneas por valores actuales altera el historial. Importar solo totales sin líneas ni contexto de estado reduce la fiabilidad para atención al cliente e informes.
| Relación del Order | Significado histórico |
|---|---|
| Línea de Order | Identidad de Product, SKU, cantidad, precio, configuración elegida e instantánea descriptiva. |
| Dirección | Datos de facturación y envío en el momento de la compra. |
| Factura | Importe reconocido o facturado, que puede diferir del estado del ciclo de vida del Order. |
| Envío | Registro de procesamiento y cantidades enviadas. |
| Reembolso | Valor revertido y líneas o importes afectados. |
| Transacción | Referencia del sistema de pago y estado cuando esté disponible. |
| Estado de Order | Significado del ciclo de vida de origen que puede requerir un equivalente deliberado en destino. |
El alcance debe conservar el nivel de detalle necesario para atención al cliente, historial de cuenta, informes y reconciliación con sistemas externos. El funcionamiento actual de pagos, envíos, impuestos y notificaciones pertenece a la configuración del destino; las etiquetas e importes históricos pertenecen al contexto del Order migrado.
CMS, URL, registros de marketing y búsqueda tienen propietarios distintos
Bagisto incluye CMS Pages, reescrituras de URL, sitemaps, términos y sinónimos de búsqueda, suscripciones a newsletters, Reviews, reglas de carrito y reglas de catálogo. No deben agruparse bajo una categoría genérica de “contenido” porque cumplen funciones diferentes.
Las CMS Pages llevan contenido e identidad de URL. Los metadatos de Products y Categories pertenecen a sus registros de catálogo. Las reescrituras conservan relaciones de rutas. Los términos y sinónimos influyen en descubrimiento. Las Reviews relacionan Customers y Products. Las suscripciones representan consentimiento y audiencia. Las reglas de carrito y catálogo codifican condiciones y acciones, no simples valores de descuento.
| Recurso de origen | Propietario en Bagisto | Límite de representación |
|---|---|---|
| Página informativa | CMS Page | Contenido, ruta, metadatos y navegación son aspectos separados. |
| Metadatos de Product o Category | Registro de catálogo | Los campos SEO deben permanecer vinculados a la entidad e idioma correctos. |
| URL heredada o redirección | Reescritura de URL o estructura de redirección | La relación entre ruta antigua y destino debe permanecer explícita. |
| Sinónimo de búsqueda | Registro de sinónimos | Un par de términos no es contenido de página. |
| Review de Product | Relación Product-Customer | Importan valoración, autor, estado y asociación con el Product. |
| Regla promocional | Regla de carrito o catálogo | Condiciones, acciones, fechas, canales y grupos forman una estructura única. |
Los registros de marketing son especialmente sensibles a la compresión semántica. Un código de Coupon sin condiciones de elegibilidad, fechas, alcance de Customers, historial de uso o acción de descuento no representa la misma promoción. Cuando no exista una estructura equivalente, debe conservarse como evidencia histórica o rediseñarse como configuración del destino, no forzarse a un mapeo engañoso.
Paquetes, API, tiendas headless y tablas personalizadas amplían el modelo
Bagisto está diseñado para ampliarse mediante paquetes Laravel, tipos de Product personalizados, módulos, API REST o GraphQL, webhooks, código de integración y tiendas headless. Estas capacidades crean datos que pueden no aparecer en las tablas principales de Product, Customer u Order.
Un paquete puede introducir entidades, relaciones pivot, configuración, estados, permisos e identificadores externos propios. Una Store headless puede consumir datos principales de Bagisto y mantener composición de páginas o índices de búsqueda en otro lugar. ERP, PIM, WMS, CRM, conectores marketplace o aplicaciones móviles pueden tratar Bagisto como un participante más de un sistema de datos mayor.
| Propietario de datos | Ejemplos | Implicación de migración |
|---|---|---|
| Núcleo de Bagisto | Products, Categories, Customers, Orders, atributos, canales, fuentes de inventario | Mapear según la semántica nativa de entidades y relaciones. |
| Paquete instalado | Vendedores marketplace, empresas B2B, recursos de reserva, suscripciones, tipos de Product personalizados | Revisar el esquema del paquete y conservar vínculos con registros principales. |
| Módulo Laravel personalizado | Tablas, campos, registros de procesos o historial de eventos específicos | Definir destino o archivo explícito para cada relación activa. |
| Capa de presentación headless | Composición de páginas, índice de búsqueda, contenido solo de frontend, identificadores en caché | No asumir que la presentación de la Store reside en el núcleo de Bagisto. |
| Sistema externo | ID de artículo ERP, ID de cuenta CRM, código de almacén, ID de listing marketplace | Conservar identificadores necesarios para reconectar la tienda de destino con el sistema que gobierna esos datos. |
La pregunta decisiva es quién posee el dato. Que un valor esté almacenado cerca de un Product no significa que pertenezca al Product. Puede pertenecer a un paquete, sistema externo o capa de presentación. El alcance solo está completo cuando estas relaciones se identifican y se define un destino para los registros que siguen siendo necesarios.
Decisiones de representación en Bagisto según significado comercial
La decisión final debe relacionar cada patrón de origen con su propietario en Bagisto y con la consecuencia de elegir el propietario equivocado.
| Patrón de origen | Pregunta correcta | Consecuencia de una suposición incorrecta |
|---|---|---|
| Opciones con SKUs secundarios y stock | ¿Representan una relación de Product configurable? | Identidad de variante, inventario o precio quedan incorrectos. |
| Especificaciones reutilizadas en una clase | ¿Pertenecen a atributos y una familia? | Filtrado y gobierno del catálogo permanecen inconsistentes. |
| Stores regionales separadas | ¿Son canales, idiomas, monedas o instalaciones independientes? | Products y contenido aparecen en el contexto equivocado. |
| Cantidades por almacén | ¿Qué fuente de inventario posee cada cantidad? | El stock total puede ser correcto y la disponibilidad por ubicación incorrecta. |
| Customers mayoristas o de empresa | ¿Representan grupo, empresa B2B, usuario de empresa o cuenta externa? | Precios, acceso y relaciones se aplanan. |
| Products y Orders pertenecientes a vendedores | ¿El paquete marketplace posee la relación con el vendedor? | Desaparecen propiedad, comisiones y contexto de pagos. |
| Campos personalizados de un paquete | ¿Qué entidad del paquete se relaciona con qué registro principal? | Los datos se copian sin el proceso que los consume. |
Una migración hacia Bagisto resulta coherente cuando Products, atributos, canales, inventarios, Customers, Orders, contenido, paquetes e identificadores externos se representan como estructuras conectadas. Así se conserva algo más importante que la presencia de datos: el significado comercial que permite operar la tienda de destino.
Conclusión
Migrar a Bagisto exige traducir relaciones entre catálogo, Store, inventario, Customers, Orders, contenido, extensiones e integraciones. Los tipos de Product determinan estructuras vendibles. Las familias gobiernan la información del Product. Los canales conectan catálogo, localización e inventario. Los grupos de Customers y paquetes B2B o marketplace opcionales definen distintas relaciones de cuenta. Los Orders dependen de líneas, instantáneas, facturas, envíos, reembolsos y transacciones. Los paquetes y sistemas externos pueden poseer datos que el núcleo de Bagisto no controla.
Las mejores decisiones de alcance identifican al propietario de cada valor comercialmente importante y conservan los vínculos entre registros. Si el mapeo se basa solo en nombres de campos, la flexibilidad de Bagisto puede ocultar pérdida de significado. Cuando se basa en finalidad y relación, la tienda de destino recibe un catálogo y un historial comercial que siguen siendo comprensibles y utilizables.
Preguntas frecuentes
¿En qué se diferencian los Products configurables de Bagisto de las opciones normales?
Un Product configurable conecta un Product principal con variaciones vendibles creadas a partir de atributos elegidos. Las variaciones pueden tener SKU, precio, cantidad, imagen o visibilidad propios. Una opción de texto que no identifica una variación gestionada de forma independiente no debe convertirse automáticamente en la misma estructura.
¿Por qué importan las familias de atributos durante la migración?
Determinan qué atributos pertenecen a cada clase de Product. Evitan que todos reciban un conjunto de campos sobredimensionado y ayudan a conservar la diferencia entre especificaciones de ropa, datos de equipos, contenido descargable, detalles de reservas y otros tipos de información.
¿Una Store de origen siempre puede convertirse en un canal de Bagisto?
No. Una Store puede representar dominio, idioma, moneda, marca, región, catálogo o unidad de negocio independiente. El modelo correcto puede ser un canal con varios idiomas, varios canales o instalaciones separadas según qué relaciones deban permanecer independientes.
¿Cómo debe representarse el stock por almacén?
Cuando la ubicación importa, el stock debe conservar su propiedad por fuente de inventario. Combinar todas las cantidades en un total de Product puede eliminar contexto de almacén, recogida, proveedor o procesamiento aunque la suma global sea correcta.
¿Los vendedores marketplace y empresas B2B son Customers normales de Bagisto?
No necesariamente. Las relaciones de vendedor y empresa pueden pertenecer a paquetes marketplace o B2B instalados. Esas estructuras pueden incluir usuarios de organización, roles, catálogos, comisiones, pagos, crédito, presupuestos o órdenes de compra que no caben en el Customer principal.
¿Qué debe hacerse con los datos pertenecientes a paquetes o módulos personalizados?
Identifique el paquete o módulo, los registros principales que amplía y el proceso de negocio que consume sus datos. Las relaciones activas necesitan un destino explícito y conservar identificadores; los registros obsoletos pueden archivarse o excluirse sin fingir que son campos nativos de Product o Customer.