Migrar a ShopWired no consiste únicamente en trasladar Products, Customers, Orders, Categories, Reviews, Coupons y registros de CMS a una nueva área administrativa. ShopWired organiza el comercio mediante una estructura propia que abarca Products, Categories, marcas, variaciones, opciones, extras, inventario, identidad de Customer, funciones B2B, configuración del proceso de compra, ajustes de IVA e impuestos sobre ventas, reglas de entrega, aplicaciones, funcionamiento de la API y presentación de la tienda mediante el tema. Una buena planificación debe traducir los datos de origen a esta estructura sin perder el significado empresarial que existe detrás de los registros.
La pregunta central es sencilla: cuando un registro de origen llega a ShopWired, ¿el negocio seguirá entendiendo qué significa y la tienda seguirá utilizándolo correctamente? Una opción de Product que antes era una simple etiqueta puede necesitar convertirse en una variación, opción, extra, paquete, campo de personalización o comportamiento gestionado por una aplicación. Un segmento de clientes puede transformarse en un registro de Customer, un suscriptor del boletín, un Customer B2B, un grupo de precios o un campo personalizado. Un Order histórico puede seguir siendo legible para atención al cliente, pero no configurará automáticamente el proceso de compra, la entrega, los pagos, el IVA, los impuestos sobre ventas ni el funcionamiento B2B para las transacciones futuras.
El significado de los datos en ShopWired se entiende mejor cuando la transferencia de registros se separa de la reconstrucción operativa. Cada valor debe interpretarse según la función comercial u operativa que debe seguir cumpliendo: facilitar la navegación del catálogo, controlar combinaciones comprables, conservar el historial de Customers, respaldar cuentas B2B, explicar Orders históricos, mantener visibilidad en buscadores, conectar sistemas externos o sostener el merchandising continuo.
Prioridades para traducir el modelo de datos hacia ShopWired
La planificación del modelo de datos de ShopWired debe empezar por las áreas que pueden cambiar con mayor facilidad el significado empresarial: configuración de Products, identidad de Customer, funcionamiento B2B, interpretación de Orders, descubrimiento en la tienda y dependencias de sistemas externos. Estas áreas determinan si la tienda migrada solo contiene registros o si realmente puede utilizarse.
| Área de la tienda de origen | Interpretación en ShopWired | Pregunta de planificación |
|---|---|---|
| Variantes y opciones de Product | Variaciones, opciones, extras, paquetes, entradas de texto/archivo o comportamiento de una aplicación | ¿La opción de origen afecta a SKU, precio, inventario, entrega, impuestos o solo a la presentación? |
| Estructura de Categories y marcas | Descubrimiento de Products, navegación, filtros, SEO y lógica de merchandising | ¿Los Customers podrán seguir encontrando los Products prioritarios mediante las rutas esperadas? |
| Registros de Customer | Identidad basada en correo electrónico, estado de cuenta, historial de Orders, notas, campos personalizados y separación B2B | ¿Los registros duplicados, de invitados, B2B y registrados mantienen el significado correcto? |
| Grupos de Customers y cuentas B2B | Visibilidad B2B, precios, funcionamiento de la cuenta y reglas operativas | ¿Qué reglas son datos, cuáles son configuración de ShopWired y cuáles requieren revisión personalizada? |
| Orders históricos | Historial del Customer, etiquetas de pago y entrega, valores fiscales, notas de Order, contexto logístico y referencias externas | ¿Los Orders históricos siguen siendo útiles para atención al cliente e informes después de la migración? |
| Recursos de contenido y SEO | Páginas, páginas de destino, Blog Posts, menús, redirecciones, metadatos y presentación controlada por el tema | ¿Qué contenido afecta a búsqueda, confianza, conversión o incorporación de clientes B2B? |
| Aplicaciones e integraciones | Propiedad externa de datos, funcionamiento de API/webhooks, fuentes de inventario, contabilidad, procesamiento logístico, correo, canales de venta externos o CRM | ¿Qué sistemas conectados deben reconfigurarse, mapearse, reconstruirse o excluirse? |
Esta perspectiva evita un error habitual: asumir que basta con encontrar campos de nombre parecido. La similitud entre campos no garantiza similitud operativa. En ShopWired, el significado depende de cómo participa el registro en la selección de Products, reconocimiento de Customers, venta B2B, proceso de compra, procesamiento logístico, cálculo de impuestos y presentación de la tienda. Un mapa de propiedad útil conecta cada valor con su Product principal, variación, Customer, cuenta B2B, Quote, Order, registro de contenido, aplicación o sistema externo antes de definir correspondencias a nivel de campo.
Products, Categories, marcas y datos de descubrimiento
Los Products de ShopWired se relacionan con Categories, marcas, variaciones, opciones, extras, inventario, precios, imágenes, palabras clave de búsqueda, filtros, URLs y relaciones de merchandising. Un catálogo de origen puede almacenar estos conceptos mediante Products, colecciones, etiquetas, atributos, fabricantes, bloques de un constructor de páginas o registros de aplicaciones. En el destino, cada significado debe asignarse a la estructura de ShopWired que realmente sea responsable de él.
Las Categories proporcionan organización jerárquica de Products, mientras las marcas representan identidad de fabricante o marca. Los filtros de Product pueden exponer valores estructurados para comparación. Las palabras clave de búsqueda influyen en el descubrimiento sin convertirse en Categories visibles. El tema puede mostrar estos registros, pero la presentación no pasa a ser la fuente autorizada del catálogo.
| Concepto del catálogo de origen | Responsable en ShopWired | Consecuencia de la traducción |
|---|---|---|
| Departamento o jerarquía duradera | Category y estructura padre-hijo | Conservar pertenencia de Product y significado estable para navegación. |
| Fabricante o marca | Relación de marca | Mantener la identidad de marca separada de una Category genérica o una especificación. |
| Atributo técnico utilizado para filtrar | Filtro de Product o campo estructurado | Conservar el valor de comparación sin crear variantes artificiales. |
| Sinónimo interno de búsqueda | Palabra clave de búsqueda de Product | Mejorar el descubrimiento sin mostrar el término como contenido del catálogo. |
| Colección de campaña | Category, página de destino, oferta o relación de presentación seleccionada | Seguir el propósito comercial en lugar de la etiqueta del origen. |
| Imagen principal y galería | Relación multimedia de Product/variación | Conservar la función de cada imagen y el contenido específico de una variación cuando cambia la combinación comprable. |
La identidad de Product solo sigue siendo comercialmente útil cuando los equipos pueden determinar qué se vende, dónde aparece, qué marca o Category lo organiza, cómo se encuentra y qué registro de inventario y precio controla la unidad vendible.
Variaciones, opciones, extras y significado de la configuración de Product
ShopWired distingue variaciones, opciones, extras, texto personalizado, carga de archivos, paquetes, pedidos anticipados, suscripciones y otros comportamientos de Product. Las plataformas de origen suelen llamar a todo ello “opciones”, aunque las relaciones sean distintas.
Una variación representa una combinación vendible y puede contener SKU, precio, inventario, imagen, peso, GTIN, MPN y significado relacionado con el IVA. Una opción o un extra puede añadir una selección o un cargo opcional sin crear la misma identidad asociada a inventario. Las entradas de texto y archivos conservan información proporcionada por el Customer. Un paquete conecta una oferta con otros registros de Product. Los pedidos anticipados y las suscripciones añaden relaciones temporales y transaccionales que van más allá del catálogo estático.
| Comportamiento en el origen | Responsable en ShopWired | Significado que debe conservarse |
|---|---|---|
| Combinación de talla/color con SKU o inventario propio | Variación | Identidad vendible, precio, inventario, imagen, peso e identificadores externos a nivel de combinación |
| Mejora opcional o envoltorio de regalo | Opción o extra | Selección opcional y efecto en el precio sin crear inventario de variante ficticio |
| Texto para grabado | Entrada de texto personalizada de Product y captura en la línea del Order | Valor introducido por el Customer conectado con la línea comprada |
| Diseño o documento aportado por el Customer | Relación de carga de archivo y captura en la línea del Order | Propiedad del archivo del Customer, seguridad y visibilidad para el procesamiento logístico |
| Kit o multipack | Paquete o relación Product-a-Product | Identidad de componentes, cantidad, autoridad sobre inventario y significado en Orders históricos |
| Product de pedido anticipado o suscripción | Product más relación temporal/transaccional | Contexto de lanzamiento, facturación, renovación o cuenta que no reside únicamente en los campos de Product |
| Configurador condicional | Lógica propiedad de una aplicación | Las selecciones del origen y los datos resultantes del Order deben separarse de la aplicación que los generó |
Esta distinción evita dos errores opuestos: crear variantes para datos descriptivos u opcionales y convertir combinaciones con inventario propio en texto estático. Los identificadores externos deben permanecer asociados al nivel de Product o variación que reconocen los sistemas de almacén, contabilidad, fuentes de datos y canales de venta externos.
Datos de Customer, cuenta y marketing
ShopWired separa perfiles de Customer, suscriptores de boletines, Customers B2B, puntos de recompensa, relaciones de recomendación, fuentes de Customer y datos de Customer creados por aplicaciones. El correo electrónico es una clave de identidad importante, pero los correos duplicados, Orders de invitados, cuentas antiguas y relaciones B2B pueden hacer insegura una correspondencia uno a uno.
Un registro de Customer puede ser responsable de datos de contacto, direcciones, estado de cuenta, historial de Orders, notas y campos personalizados. El estado del boletín representa una relación de comunicación, no una identidad de Customer sustituta. El estado B2B añade significado sobre precios y acceso. Los puntos de recompensa forman un registro vinculado al Customer. Las etiquetas de aplicaciones o los identificadores CRM pueden seguir siendo propiedad de sistemas externos.
| Patrón de identidad en el origen | Decisión de relación en ShopWired |
|---|---|
| Comprador minorista registrado | Perfil de Customer vinculado con direcciones y Orders históricos |
| Comprador invitado | Identidad y direcciones a nivel de Order sin inventar una cuenta permanente |
| Contacto únicamente suscrito al boletín | Relación de suscriptor separada de una cuenta de comprador salvo que los registros representen realmente a la misma persona |
| Comprador B2B aprobado | Customer B2B más las relaciones de precio, visibilidad, impuestos y cuenta que dan significado a la aprobación |
| Cuentas de origen duplicadas | Consolidar solo cuando identidad, consentimiento, direcciones y propiedad de Orders justifican la decisión |
| Saldo de recompensas o recomendaciones | Registro de programa vinculado al Customer, no una nota genérica de Customer |
| ID de CRM o marketing | Identificador externo asociado al registro de Customer o suscriptor reconocido por el sistema conectado |
El modelo de destino no debe inferir consentimiento, aprobación B2B ni propiedad de cuenta a partir de un nombre compartido. Debe conservar la relación que hacía útil operativamente el registro de origen.
Datos B2B, de comercio, Quotes y precios
Las estructuras B2B de ShopWired incluyen Customers B2B, Categories y Products exclusivos para B2B, precios comerciales, bandas de precios, precios individuales, descuentos globales, Quotes y funcionamiento relacionado de la cuenta. Son registros conectados, no atributos de una sola fila de Customer.
La identidad del comprador pertenece al Customer o Customer B2B. La regla comercial puede pertenecer a una banda de precios, un precio B2B específico de Product, una excepción individual, un descuento global, una relación de visibilidad o un Quote. Los Quotes y Orders históricos conservan resultados negociados; la configuración B2B actual define el comportamiento de compra futuro.
| Elemento B2B del origen | Responsable en ShopWired | Significado de la relación |
|---|---|---|
| Cuenta empresarial aprobada | Customer B2B | Identidad del comprador y estado B2B aprobado |
| Nivel mayorista | Banda de precios B2B o descuento global | Tratamiento comercial compartido para una clase de Customers B2B |
| Precio contractual | Precio individual de Customer B2B u otra relación Product-Customer | Excepción específica de cuenta en el nivel correcto de Product o variación |
| Catálogo exclusivo B2B | Relación de visibilidad de Product/Category | Qué compradores aprobados pueden descubrir y adquirir el artículo |
| Quote | Registro de Quote vinculado con Customer, Products, precios, notas, estado y, cuando corresponda, Order posterior | Captura comercial negociada, no un carrito ordinario |
| Condiciones de orden de compra | Contexto Customer/Quote/Order más configuración de pago del destino | Conservar condiciones y referencias históricas separadas del funcionamiento activo del proceso de compra |
| Estado de IVA | Customer B2B y relación fiscal | La evidencia del comprador y el tratamiento comercial no deben reducirse a una etiqueta |
Por tanto, un Customer Group de origen no es suficiente por sí solo. Su significado dentro del modelo de datos es la red de precios, Products, reglas de visibilidad, historial de Quotes, condiciones y tratamiento fiscal conectados con ese grupo.
Orders, estados de Order, Quotes y contexto transaccional
Un Order de ShopWired registra lo que ocurrió en una transacción. Sus relaciones pueden incluir identidad de Customer o invitado, líneas de Product y variación, opciones, extras, datos de personalización, precios, cupones, entrega, etiquetas de pago, IVA o impuestos sobre ventas, estados, notas, reembolsos, devoluciones, suscripciones, Quotes y referencias de sistemas externos.
Los valores históricos de Order son capturas del momento. No deben recalcularse con los precios actuales de Product ni con la configuración fiscal actual. Una etiqueta de pago o entrega explica el Order pasado, pero no configura la pasarela ni la zona de entrega del destino. Un campo personalizado de Order pertenece a la transacción salvo que el mismo valor se promueva deliberadamente a un dato persistente de Customer o Product.
| Relación del Order | Significado histórico que debe conservarse |
|---|---|
| Asignación a Customer o invitado | Quién realizó el Order y qué direcciones se utilizaron |
| Línea de Product/variación | Identidad comprada, SKU, opciones o extras seleccionados, cantidad y descripción de línea |
| Texto/archivo aportado por el Customer | Instrucción para procesamiento logístico vinculada con la línea comprada o el Order |
| Precio, descuento, cupón, IVA/impuesto y total | Captura financiera registrada en el momento de la compra |
| Etiqueta de pago y entrega | Contexto del método para atención y reconciliación sin implicar configuración activa |
| Estado, reembolso, devolución y cronología | Evidencia del ciclo de vida y cambios sobre la transacción original |
| Referencia de Quote o suscripción | Relación con el proceso comercial que precedió o siguió al Order |
| ID externo | Clave de reconciliación para ERP, contabilidad, procesamiento logístico, canal de venta externo o CRM |
Los Orders siguen siendo útiles cuando el personal puede interpretar la transacción aunque hayan cambiado el catálogo actual, el tema, las aplicaciones o la configuración del proceso de compra.
Datos del proceso de compra, entrega, pagos, IVA e impuestos sobre ventas
ShopWired separa los datos históricos de transacciones de la configuración que crea Orders futuros. Los Orders antiguos pueden contener nombres de métodos de entrega, cargos, etiquetas de pago, valores de IVA o impuestos sobre ventas, exenciones y respuestas personalizadas del proceso de compra. El proceso de compra actual de ShopWired, las zonas y tarifas de entrega, métodos de recogida, pasarelas de pago, zonas de IVA, tasas fiscales personalizadas, reglas B2B y aplicaciones del proceso de compra son registros de configuración independientes.
| Valor histórico del origen | Responsable del dato | Relación separada en el destino |
|---|---|---|
| Etiqueta del método de pago y referencia de transacción | Order | Configuración de pasarela y credenciales para futuras transacciones |
| Método y cargo de entrega | Order | Zona, tarifa, restricción, recogida y configuración del transportista |
| Importe de IVA o impuesto sobre ventas | Captura financiera del Order | Zonas de IVA, tipos fiscales, exenciones y reglas de cálculo actuales |
| Evidencia de exención del Customer | Customer/Customer B2B o registro externo de cumplimiento | Regla del destino que aplica el tratamiento a futuros Orders |
| Respuesta a una pregunta del proceso de compra | Campo de Order o Customer según su propósito | Definición del campo y regla de visibilidad en el proceso de compra |
| Condiciones fuera de línea o referencia de orden de compra | Customer B2B, Quote u Order | Configuración actual de condiciones de pago y aprobación |
| Salida de una aplicación del proceso de compra | Datos de Order propiedad de la aplicación | Configuración de la aplicación en el destino y relación de datos compatible |
Esta separación mantiene los datos históricos y la configuración futura en sus funciones correctas: los registros migrados explican transacciones pasadas, mientras los registros de configuración describen cómo ShopWired creará nuevas transacciones. Están relacionados, pero ninguno sustituye al otro. La misma distinción se aplica a las exenciones de Customer y las condiciones B2B: el Order histórico conserva lo ocurrido, mientras la relación de Customer o B2B registra por qué un tratamiento similar puede volver a aplicarse en el futuro.
Contenido, SEO, menús y datos dependientes del tema
El contenido de ShopWired puede incluir páginas web, páginas de destino, Blog Posts, metadatos de Product y Category, redirecciones 301, menús y listas de enlaces, información de empresa, imágenes, archivos, Products destacados, preguntas y respuestas de Product y otros registros de la tienda. Los temas representan estos registros, pero no se convierten en su propietario autorizado.
Un bloque de un constructor de páginas del origen puede combinar texto, imágenes, referencias de Product, formularios y widgets de aplicaciones dentro de un único objeto visual. El modelo de destino debe separar el contenido duradero de la configuración de presentación y de las referencias comerciales dinámicas.
| Recurso del origen | Responsable en ShopWired | Consecuencia de la traducción |
|---|---|---|
| Página de política, servicio o información B2B | Página web | Conservar cuerpo, metadatos, enlaces, recursos multimedia y significado duradero de URL. |
| Landing page de campaña o editorial | Landing page más referencias de Product/contenido | Separar contenido reutilizable del diseño específico del tema. |
| Entrada de blog | Blog Post | Conservar título, cuerpo, recursos, contexto de fecha/autor cuando sea relevante, metadatos y enlaces internos. |
| Datos SEO de Product o Category | Product/Category más campos SEO | Mantener la identidad canónica del registro separada de redirecciones y ubicación en menús. |
| Elemento de menú | Relación de menú/lista de enlaces | La navegación pública puede apuntar a un Product, Category, página, Blog Post, URL externa o campaña. |
| Redirección | Relación de redirección 301 | Conservar el significado de ruta origen-destino sin tratar la URL antigua como contenido de página. |
| Sección o widget del tema | Presentación del tema/aplicación | Recrear la presentación por separado de los datos de contenido o Product que muestra. |
La propiedad del contenido importa tanto en experiencias B2B como minoristas. Una página de incorporación B2B, una biblioteca de especificaciones de Products, una página de políticas o una página de destino de alto valor puede conservar significado empresarial aunque cambie por completo su diseño visual.
Aplicaciones, API, webhooks y datos de sistemas externos
ShopWired ofrece aplicaciones, credenciales API y webhooks, y su ecosistema incluye conexiones con contabilidad, procesamiento logístico, inventario, canales de venta externos, marketing, impuestos, búsqueda, suscripciones y B2B. Los datos de una aplicación del origen no pasan a ser datos nativos de ShopWired solo porque exista una aplicación de destino con una función parecida.
El modelo de destino debe identificar el sistema autorizado para cada valor operativo. Los IDs de Product y variación pueden ser reconocidos por un ERP. Los IDs de Customer pueden pertenecer a un CRM. Las referencias de Order y envío pueden pertenecer a sistemas logísticos o contables. El consentimiento de suscriptores puede ser propiedad de una plataforma de marketing. Un webhook es configuración; el identificador externo transportado por su payload es un dato.
| Dependencia | Relación autorizada |
|---|---|
| ID de Product de ERP o contabilidad | Product o variación reconocida por el sistema externo |
| Clave de fuente de datos de inventario | Product/variación con inventario más el sistema que controla el stock disponible |
| Referencia logística | Relación de Order, envío o paquete reconocida por el transportista o almacén |
| ID de Customer/empresa en CRM | Relación de Customer o Customer B2B en el nivel de cuenta correcto |
| ID de publicación de canal de venta externo | Relación Product/variación/canal, no una descripción genérica del Product |
| Consentimiento y etiquetas de marketing | Suscriptor/Customer más el sistema externo que controla el estado |
| Campo personalizado de aplicación | Valor propiedad de una aplicación con un Product, Customer, Order o Quote principal explícito |
| Credencial API o suscripción a webhook | Configuración segura del destino, no datos de publicación ni de Customer |
La paginación de API, autenticación y gestión de errores afectan a cómo los sistemas intercambian registros, pero no cambian quién es propietario de los datos subyacentes. Por ello, el mapa de propiedad debe seguir siendo estable aunque se reconstruya la implementación de la integración.
Límites de propiedad de datos personalizados y externos
Los datos personalizados y externos relacionados con ShopWired deben organizarse mediante límites de propiedad, no mediante etiquetas genéricas de escalamiento. La decisión fundamental consiste en determinar si el valor pertenece a una entidad nativa de ShopWired, una aplicación de ShopWired, la configuración de presentación o un sistema externo.
| Señal de datos | Responsable en el destino | Definición de relación necesaria |
|---|---|---|
| Especificación de Product utilizada para filtros | Estructura Product/filtro | Nombre del atributo, valor, pertenencia de Product y función de presentación en la tienda |
| ID de almacén a nivel de variación | Variación más ERP/almacén | Combinación vendible y registro externo que la reconoce |
| Referencia contractual de Customer B2B | Customer B2B más CRM/contabilidad | Organización, contacto, cuenta comercial y clave del sistema externo |
| Campo personalizado exclusivo de Quote | Quote | Contexto de negociación o aprobación sin convertirlo en atributo permanente de Customer |
| Registro de suscripción o paquete creado por una aplicación | Aplicación más Product/Order | Product principal, relaciones de facturación o componentes y referencias de transacciones históricas |
| Ajuste de tema que selecciona Products | Presentación del tema | Las referencias de Product siguen siendo autoritativas en el catálogo; el ajuste solo controla la presentación |
| Tabla personalizada del origen no compatible | Entidad principal definida o sistema externo | Deben quedar explícitos el propósito empresarial, clave principal, ciclo de vida y responsable en el destino |
Este modelo evita dos fallos: forzar cada valor de origen al campo nativo más parecido y conservar datos personalizados sin comprender su relación principal. Un valor solo es utilizable cuando los equipos saben qué registro lo posee, qué sistema lo reconoce y si describe historia, comercio actual o presentación. La propiedad también debe mantenerse estable entre exportaciones e integraciones. Cuando un valor personalizado se duplica en varios sistemas, debe identificarse una única fuente autorizada y una clave de reconciliación duradera para que las actualizaciones posteriores no creen versiones contradictorias del mismo hecho comercial.
Conclusión
La planificación del modelo de datos de ShopWired debe centrarse en significado, no en coincidencia de campos. Las diferencias más importantes suelen aparecer en configuración de Products, funcionamiento B2B, identidad de Customer, historial de Orders, contexto del proceso de compra, recursos de contenido y SEO, aplicaciones, flujos API, IDs externos y campos personalizados. Cada área debe interpretarse según su uso empresarial continuado, no únicamente según si un registro puede importarse.
Un modelo de destino sólido asigna cada valor del origen a un Product, variación, Customer, relación B2B, Quote, Order, registro de contenido, aplicación, capa de presentación o sistema externo. Ese mapa de propiedad conserva el significado comercial sin confundir datos históricos con configuración futura.
Preguntas frecuentes
¿Por qué las opciones de Product de ShopWired necesitan una revisión especial durante la migración?
Porque las opciones de Product del origen pueden representar comportamientos distintos en ShopWired. Algunas se convierten en variaciones con SKU, precio, inventario, imagen, peso o significado fiscal. Otras corresponden a opciones, extras, campos de personalización, paquetes o estructuras propiedad de aplicaciones.
¿Los registros de Customer se corresponden solo por nombre en ShopWired?
No. La identidad de Customer está fuertemente vinculada al correo electrónico. Los correos duplicados, Orders de invitados, cuentas registradas, cuentas B2B y campos personalizados de Customer deben revisarse cuidadosamente para que el historial de Orders y el significado de la cuenta sigan siendo utilizables.
¿Los Orders migrados configuran el proceso de compra en ShopWired?
No. Los Orders migrados pueden conservar contexto histórico de pagos, entrega, descuentos, impuestos y procesamiento logístico cuando sea compatible. El proceso de compra activo sigue dependiendo de la configuración de pagos, entrega, IVA o impuestos sobre ventas, grupos de Customers, comercio B2B y aplicaciones de ShopWired.
¿Pueden migrarse los precios B2B y las reglas comerciales como datos normales de Customer?
No siempre. Las cuentas B2B, bandas de precios, precios individuales, relaciones de Quote, visibilidad de Products, condiciones de cuenta y tratamiento fiscal son registros comerciales conectados, no campos ordinarios dentro de un perfil de Customer.
¿Cuándo necesitan los datos personalizados de ShopWired un responsable independiente?
Cuando un valor pertenece a una aplicación, un sistema externo, una tabla personalizada del origen, una capa de presentación o una relación que no encaja en un Product, Customer, Quote, Order o registro de contenido ordinario.
¿Cómo deben traducirse las reglas B2B hacia ShopWired?
Separa la identidad subyacente del comprador y los datos de Product de la regla que cambia precio, visibilidad, tratamiento fiscal, cotización o funcionamiento del proceso de compra. Conserva los registros que contienen significado duradero y documenta qué configuración del destino o sistema conectado aplicará la regla comercial.