Wix combina creación de sitios web, comercio, CRM, CMS, marketing y datos de aplicaciones dentro de un mismo sitio. Esa amplitud hace que el significado de las relaciones sea más importante que la similitud entre campos durante una migración. Un Product del origen puede convertirse en un Product de Wix Stores con opciones, elecciones, variantes, contenido multimedia, Categories, relaciones con marcas e inventario. Una persona puede existir como Contact, Member del sitio, Customer relacionado con Orders o participante en otra aplicación empresarial de Wix. Un registro CMS del origen puede corresponder a una colección de Wix CMS, mientras que un Product, Blog Post, reserva, evento o registro de aplicación pertenece a un propietario de datos distinto dentro de Wix.
Wix también presenta un límite activo de versión de catálogo. Un sitio Wix puede utilizar Catalog V1 o Catalog V3, pero no ambos simultáneamente. Catalog V3 introduce variantes universales, Customizations reutilizables, Inventory Items separados por variante y ubicación, Categories jerárquicas, marcas, secciones de información reutilizables y otras entidades de catálogo. Por ello, la versión de catálogo del sitio de destino forma parte del modelo de datos y no debe tratarse como un detalle técnico menor.
La principal tarea de representación consiste en conservar las relaciones padre-hijo y entre sistemas que dan significado a los datos. La identidad de un Product debe seguir conectada con la variante, Category, registro de inventario, ubicación, contenido multimedia e identificador externo correctos. La identidad de Contact debe mantenerse separada del acceso de Member y del consentimiento de marketing. Los Orders deben conservar evidencia de las transacciones sin convertirse en configuración del futuro checkout. Las colecciones CMS y los datos de aplicaciones necesitan propietarios explícitos en lugar de convertirse en contenido de página genérico.
La versión del catálogo de Wix define un límite de propiedad de datos
Catalog V1 y Catalog V3 no exponen exactamente la misma estructura de registros. Un sitio utiliza una sola versión del catálogo en cada momento, por lo que la representación de los datos debe seguir la versión activa en el sitio de destino. Catalog V3 está diseñado alrededor de servicios más explícitos para Products, variantes, Inventory Items, ubicaciones, Categories, marcas, ribbons, secciones de información y Customizations reutilizables.
Catalog V3 también utiliza variantes universales: cada Product tiene al menos una variante, incluida una variante predeterminada para Products sin opciones visibles. En este modelo, precio, SKU, inventario y otros detalles del elemento vendible pueden entenderse a nivel de variante aunque el comprador vea un Product sencillo.
| Supuesto de la tienda de origen | Significado en el catálogo de Wix | Consecuencia para la representación |
|---|---|---|
| Un Product sin opciones no tiene variante. | Catalog V3 sigue representando una variante predeterminada. | La identidad del Product y la identidad vendible permanecen relacionadas aunque no exista una elección visible. |
| Toda opción es un dato descriptivo de Product. | Las opciones crean variantes; los modificadores recogen personalización sin crear variantes. | Separe las elecciones que afectan stock de los datos introducidos por el comprador y de la personalización opcional. |
| Una única cantidad de inventario pertenece al Product. | En Catalog V3, los Inventory Items relacionan una variante con una ubicación. | Conserve tanto la variante vendible como el contexto de ubicación detrás de cada cantidad. |
| Una colección equivale a un árbol de Categories. | La versión del catálogo y el modelo de Categories de Wix determinan la organización de Products. | Represente la jerarquía del origen mediante las relaciones de Categories compatibles con el sitio de destino. |
| Los datos de Wix Stores y los datos de Wix CMS son intercambiables. | Las entidades del catálogo de Wix Stores y los elementos de colecciones de Wix CMS tienen propietarios distintos. | Use CMS únicamente para registros que pertenezcan realmente a colecciones CMS o estructuras de datos externas. |
Por ello, una migración no debe asumir que una representación entre campos creada para una versión del catálogo de Wix se aplica sin cambios a otra. Las integraciones externas también necesitan los IDs de entidad y el nivel de detalle correctos. Un ERP que reconoce variantes no puede conectarse de forma fiable utilizando únicamente el ID del Product padre cuando Catalog V3 administra el inventario por variante y ubicación.
Products, variantes universales, opciones, elecciones y modificadores
Un Product de Wix es el registro padre del catálogo. En Catalog V3, cada Product tiene al menos una variante. Los Products con opciones pueden generar variantes a partir de combinaciones de elecciones. Cada variante puede incorporar un SKU, precio, contenido multimedia y significado de inventario distintos. Las Customizations distinguen las opciones que generan variantes de los modificadores que recogen información adicional del comprador sin cambiar la identidad de la variante ni del inventario.
Esta diferencia es esencial al migrar Products configurables. Una talla o color del origen que cambia el SKU o el stock suele corresponder a datos de opción y variante. Un campo de grabado, una nota de regalo o una personalización opcional se parece más a un modificador. Una aplicación del origen puede combinar ambos comportamientos en un mismo configurador, por lo que la migración debe separar la identidad vendible resultante de las instrucciones proporcionadas por el comprador.
| Configuración de origen | Propietario en Wix | Significado que debe conservarse |
|---|---|---|
| Product simple con un SKU | Product más variante predeterminada | Contenido del Product a nivel padre; SKU vendible, precio e identidad de inventario a nivel de variante. |
| Combinaciones de talla/color | Opciones, elecciones y variantes | Cada combinación comprable permanece vinculada con las elecciones, SKU, precio, contenido multimedia y stock correctos. |
| Texto de grabado o mensaje de regalo | Modificador o resultado de personalización propiedad de una aplicación | La información introducida por el comprador permanece vinculada con la línea adquirida sin crear variantes falsas de inventario. |
| Mejora opcional | Modificador, Product independiente o variante según el significado de stock y precio | El propietario de destino depende de si la mejora crea un elemento vendible distinto. |
| Paquete o kit | Relación de Products, paquete propiedad de una aplicación o estructura externa de inventario | Componentes, autoridad sobre stock, formación del precio y datos resultantes en la línea del Order siguen siendo explicables. |
| Suscripción, reserva, evento u oferta de servicio | Product de Wix Stores u otra aplicación empresarial de Wix según su funcionamiento | La identidad de catálogo permanece separada de facturación recurrente, programación, asistencia o derechos de acceso. |
Las Customizations de Catalog V3 pueden reutilizarse entre varios Products. Esto crea otro límite relacional: la definición de personalización puede ser compartida, mientras que su asignación al Product y el funcionamiento resultante de variante o modificador siguen siendo específicos de cada Product. Eliminar o modificar una definición compartida puede afectar a varios Products, por lo que las plantillas de opciones del origen solo deben representarse como entidades reutilizables cuando realmente compartan el mismo significado para el negocio.
El contenido multimedia de Products también requiere disciplina de propiedad. Los recursos del Product padre pueden describir la oferta general, mientras que una imagen asociada a una elección o variante puede identificar una combinación específica. Trasladar todas las imágenes a una única galería indiferenciada puede conservar los archivos, pero perder la relación que ayuda al comprador a reconocer la variante seleccionada.
Categories, marcas, Info Sections, Ribbons y descubrimiento
La organización del catálogo de Wix puede implicar Categories jerárquicas, asignaciones de Products, marcas, ribbons, secciones de información reutilizables, búsqueda, navegación del sitio y presentación de páginas. Estos registros cumplen funciones diferentes.
Las Categories de Catalog V3 pueden formar árboles padre-hijo y permitir que un Product se asigne a varias Categories, incluida una relación con una Category principal. Las marcas representan la identidad del fabricante o marca. Las Info Sections proporcionan información enriquecida y reutilizable de Products, como especificaciones, guías de tallas, instrucciones de cuidado o detalles de garantía. Los Ribbons actúan como etiquetas promocionales. Las páginas y menús del sitio determinan la navegación pública y la presentación.
| Concepto de origen | Propietario de destino en Wix | Consecuencia para la representación |
|---|---|---|
| Jerarquía permanente de departamentos | Árbol de Categories y relaciones entre Products y Categories | Conserve el significado duradero de exploración y clasificación. |
| Fabricante o marca | Entidad Brand y asociación con Product | Mantenga la identidad de marca separada de Categories y especificaciones descriptivas. |
| Especificaciones técnicas | Campos de Product, Info Sections, datos CMS o PIM externo según reutilización y propiedad | No convierta atributos descriptivos en variantes salvo que creen combinaciones vendibles. |
| Guía de tallas o instrucciones de cuidado compartidas por varios Products | Info Section reutilizable | Conserve un único propietario compartido del contenido y las referencias desde Products. |
| Etiqueta de oferta, novedad o destacado | Ribbon o presentación promocional | Mantenga el estado promocional separado de la clasificación permanente de Products. |
| Colección estacional | Category, página de destino, ribbon, campaña o presentación seleccionada según el propósito | Conserve el significado de la campaña sin convertirlo en un tipo permanente de Product. |
| Elemento de menú | Relación de navegación del sitio hacia una Category, página de Product, CMS Page o URL externa | La navegación no se convierte en propietaria de la clasificación de Products. |
Un mismo valor del origen puede necesitar propietarios distintos según su uso. “Organic” podría ser una especificación consultable, una etiqueta de Product, una Category o un campo de certificación procedente de un PIM externo. La representación debe seguir el flujo de trabajo que consume el valor y no solo la etiqueta utilizada en el sistema de origen.
Las relaciones entre variante y ubicación determinan el significado del inventario
Los Inventory Items de Catalog V3 representan una variante específica en una ubicación específica. El registro de inventario puede almacenar cantidad, disponibilidad, comportamiento de preorder y otros significados de stock para esa combinación variante-ubicación. Cada tienda dispone además de una ubicación predeterminada, mientras que ubicaciones adicionales pueden representar almacenes, sucursales o puntos de procesamiento de pedidos.
Una plataforma de origen puede almacenar una cantidad por Product, una cantidad por variante o cantidades separadas por almacén y canal. Estos modelos no son equivalentes.
| Patrón de inventario del origen | Relación de destino en Wix |
|---|---|
| Una cantidad de Product sin opciones visibles | Variante predeterminada → ubicación de inventario prevista → Inventory Item. |
| Stock a nivel de variante | Cada combinación vendible del origen → variante de Wix → Inventory Item por ubicación. |
| Stock por almacén | Almacén/sucursal de origen → ubicación de Wix o sistema externo propietario del almacén → cantidad por variante y ubicación. |
| Disponibilidad ilimitada o producción bajo pedido | Disponibilidad de la variante y significado del seguimiento de inventario, no una cantidad artificialmente grande. |
| Stock para preorder | Inventory Item por variante y ubicación más reglas de preorder cuando el destino admita ese funcionamiento. |
| Autoridad externa sobre stock | IDs de variante/ubicación de Wix más clave de ERP o almacén utilizada para la sincronización continua. |
| Asignación a mercado en línea | Variante → relación con canal/listado externo → propietario del stock, en lugar de cantidades duplicadas sin control. |
En Catalog V3, la creación del Product y la creación del Inventory Item son operaciones separadas salvo que se utilice un flujo de creación combinado. Esa separación refuerza el modelo de propiedad: un Product puede existir sin un registro de inventario completo, y el inventario no puede interpretarse sin conocer la variante y la ubicación que lo poseen.
Cuando un ERP o almacén sigue siendo la autoridad, la cantidad inicial de stock es menos duradera que los identificadores que mantienen alineadas las futuras actualizaciones. Un ID externo a nivel de Product no es suficiente si el sistema externo almacena cada combinación de variante y ubicación por separado.
Contacts, Members, Customers y relaciones de marketing
Wix CRM Contacts y los Members del sitio representan relaciones diferentes. Un Contact es un registro de persona u organización utilizado en CRM, comunicaciones, Orders y aplicaciones empresariales. Un Member es un usuario del sitio con autenticación y, potencialmente, relaciones de perfil, rol, permisos o acceso restringido. Un Customer comercial puede estar relacionado con un Contact y con Orders sin reproducir todo el funcionamiento de una cuenta del origen.
Una cuenta de Customer del origen puede incluir direcciones, historial de Orders, contraseñas, funciones dentro de una empresa, grupos de clientes, exenciones fiscales, puntos de fidelización, membresías, suscripciones, consentimiento y atributos específicos de aplicaciones. Estos valores deben asignarse a la entidad de Wix o sistema externo que sea responsable de su uso continuo.
| Patrón de identidad del origen | Decisión de relación en Wix |
|---|---|
| Comprador minorista registrado | Identidad Contact/Customer conectada con direcciones y Orders; relación Member solo cuando se pretende acceso al sitio. |
| Comprador invitado | Contexto Contact relacionado con el Order sin inventar una cuenta Member. |
| Suscriptor solo de newsletter | Contact más relación de consentimiento/suscripción de comunicación, sin convertirlo automáticamente en Customer o Member. |
| Usuario de comunidad o contenido restringido | Member más relación Contact y cualquier propietario relevante de rol, permiso o acceso. |
| Contacto de empresa B2B | Contact más relación de empresa/CRM/cuenta externa; no implica automáticamente una jerarquía organizativa completa. |
| Participante en programa de fidelización | Contact/Customer más el registro de fidelización de Wix o externo que sea propietario de puntos y estado. |
| Cuentas duplicadas del origen | Solo se consolidan cuando email, teléfono, IDs externos, direcciones, consentimiento y propiedad de Orders respaldan una única identidad. |
Las contraseñas y el estado de autenticación no deben tratarse como campos de perfil ordinarios. Aunque un Customer del origen se convierta en un Member de Wix, credenciales de acceso, estado de invitación, roles y permisos tienen significado independiente de seguridad y ciclo de vida.
El consentimiento de marketing también permanece independiente del historial de compra. Un Contact que compró una vez no se convierte automáticamente en suscriptor, y un suscriptor puede no haber comprado nunca. Conservar el consentimiento exige mantener separada la relación de comunicación del propio registro Contact.
Los Orders conservan historial comercial y contexto de aplicaciones
Los eCommerce Orders de Wix administran el ciclo posterior a la compra. Un Order puede contener artículos adquiridos, datos de pago, información de facturación y envío, descuentos, impuestos, datos de entrega o recogida, estado de procesamiento, reembolsos, facturas y referencias externas. Draft Orders, registros de facturación, transacciones, facturas y procesamientos relacionados tienen propietarios vinculados pero distintos.
La línea de Product o variante dentro de un Order histórico es una instantánea de la transacción. Debe conservar aquello que se compró, incluidas opciones o personalizaciones seleccionadas, aunque el catálogo actual cambie más adelante. La configuración actual de pagos, impuestos, envío, notificaciones, facturación e inventario sigue siendo configuración para Orders futuros.
| Valor histórico | Significado dentro de Wix Orders |
|---|---|
| Número de Order del origen | Referencia externa para atención a Customers y conciliación. |
| Línea de Product/variante | Título adquirido, variante, SKU, cantidad, precio y elecciones seleccionadas. |
| Resultado de modificador o personalización | Valor proporcionado por el comprador o generado por una aplicación, conectado con la línea de Order correcta. |
| Descuento, impuesto y cargo de entrega | Explicación del total histórico, no configuración de reglas actuales. |
| Datos de pago y reembolso | Historial financiero vinculado con el Order y el propietario de la transacción. |
| Envío, entrega, recogida o procesamiento de servicio | Estado histórico de procesamiento y contexto de seguimiento. |
| Referencia de factura o contabilidad | Relación Order/factura más identificador contable externo. |
| Referencia de canal de venta o aplicación | Origen del Order y propiedad de la aplicación externa. |
Los Wix Orders pueden ser creados por varias soluciones empresariales e integraciones de Wix, no solo por Wix Stores. Por ello, un registro migrado debe conservar qué aplicación o canal originó la transacción cuando esa diferencia afecte elaboración de informes, procesamiento de pedidos o atención a Customers.
Los Orders históricos tampoco deben crear Products actuales artificiales. Una línea de Order correspondiente a un Product retirado, un servicio puntual o un cargo generado por una aplicación puede seguir siendo comprensible como instantánea sin añadir un Product nuevo al catálogo activo.
Colecciones de Wix CMS, elementos de datos, referencias y datos externos
Wix CMS almacena elementos de datos dentro de colecciones. Estos elementos pueden contener campos tipados y referencias a otros elementos. Wix también admite conexiones con bases de datos externas que exponen colecciones externas mediante las interfaces de datos de Wix. Estas capacidades hacen que CMS sea útil para contenido estructurado, directorios, catálogos personalizados, bibliotecas de recursos y datos de aplicaciones, pero CMS no sustituye Wix Stores, Contacts, Orders, Blog, Bookings, Events ni otros propietarios especializados.
Una tabla personalizada del origen solo debe convertirse en una colección de Wix CMS cuando el registro empresarial pertenezca realmente a un modelo de contenido o de datos personalizados. Un Product que debe participar en el checkout de Wix Stores, variantes, inventario y Orders debe seguir siendo un Product de Wix Stores. Un Blog Post debe continuar como contenido Blog cuando el funcionamiento de publicación sea importante. Una reserva debe seguir conectada con el sistema de reservas que sea propietario de disponibilidad y asistencia.
| Registro de origen | Propietario de destino en Wix |
|---|---|
| Biblioteca de especificaciones de Products | Info Sections, campos de Product, colección CMS o PIM externo según reutilización y autoridad. |
| Recurso editorial o directorio | Colección CMS y elementos de datos con referencias explícitas y relaciones con páginas dinámicas. |
| Artículo de blog | Wix Blog Post con significado de publicación, autor, Category/etiqueta, contenido multimedia y URL. |
| Catálogo personalizado de Products que no se vende directamente | CMS o colección de base de datos externa; Wix Stores solo cuando se requiera funcionamiento comercial. |
| Registro de evento, reserva, curso o membresía | Aplicación empresarial de Wix correspondiente más relaciones Contact/Member y de transacción. |
| Fila de base de datos externa | Relación con colección externa mediante IDs estables y campos de referencia. |
| Contenido creado con un constructor de páginas | Presentación de página/sección conectada a registros CMS o comerciales, no propietario autorizado de los datos. |
Los campos de referencia de CMS conservan relaciones entre registros, por ejemplo un recurso vinculado con autor, Category, Product o ubicación. Convertir esas relaciones en texto copiado elimina la capacidad de actualizar y consultar los registros de manera independiente.
Páginas del sitio, URLs, contenido multimedia, datos multilingües y SEO
El contenido de un sitio Wix puede incluir páginas, páginas dinámicas, Blog Posts, contenido alimentado por CMS, material multimedia, menús, páginas de Products, páginas de Categories, redirecciones, campos SEO, dominios y variantes multilingües. Estos registros determinan cómo se presentan y descubren los datos de catálogo y contenido, pero no sustituyen el Product, elemento CMS, Contact u Order subyacente.
Un layout creado con un constructor de páginas del origen puede combinar referencias a Products, texto, imágenes, formularios y widgets de aplicaciones. El modelo de destino debe separar el contenido reutilizable y los registros empresariales de la sección visual que los presenta.
| Recurso web de origen | Relación de propiedad en Wix |
|---|---|
| Título, descripción, contenido multimedia, URL y datos SEO de Product | Product de Wix Stores y presentación de la página de Product. |
| Página de destino de Category | Category más relación de página/navegación y cualquier contenido complementario. |
| CMS Page o página de contenido dinámico | Página/página dinámica del sitio más colección CMS y referencias a elementos de datos. |
| Blog Post | Registro Wix Blog con significado de autor, publicación, Category/etiqueta, contenido multimedia y ruta. |
| Elemento de menú | Relación de navegación hacia una página, Category, Product, página dinámica, ancla o URL externa. |
| Contenido multilingüe | Campos y referencias específicos de idioma para sitio/contenido/Products, no registros independientes duplicados salvo que sea intencionado. |
| URL de origen | Ruta de destino más relación de redirección cuando cambia la ruta. |
| Tema o componente del Editor | Configuración de presentación que hace referencia a entidades autorizadas de contenido o comercio. |
La URL anterior debe apuntar a un registro de destino conocido. Una redirección es una relación entre rutas, no un sustituto para definir qué Product, Category, página, Blog Post o elemento dinámico de Wix reemplaza el recurso del origen. Los enlaces internos y referencias de contenido multimedia también deben conservar el destino previsto en lugar de mantener rutas obsoletas del origen.
Aplicaciones, Velo, plugins de servicios y propiedad de sistemas externos
Las aplicaciones de Wix, código Velo, plugins de servicios, automatizaciones, webhooks, bases de datos externas y sistemas de terceros pueden ser propietarios de datos que no pertenecen al catálogo nativo de Wix Stores. Reviews, suscripciones, fidelización, mercados en línea, contabilidad, procesamiento de pedidos, búsqueda avanzada, feeds de Products, CRM y configuradores personalizados pueden introducir registros e identificadores adicionales.
Que una aplicación de destino realice una función similar no demuestra que los datos de la aplicación de origen puedan representarse directamente. Deben comprenderse la entidad propietaria, el esquema de datos, las claves relacionales y el ciclo de vida.
| Señal personalizada o externa | Propietario de destino |
|---|---|
| ID de Product o variante en ERP | Product/variante más relación con ERP al nivel de detalle del catálogo reconocido externamente. |
| Clave de inventario de almacén | Inventory Item por variante y ubicación más sistema de almacén. |
| ID de Contact o empresa en CRM | Contact más relación con CRM/empresa externa. |
| ID de publicación en mercado en línea | Relación Product/variante/canal, no un campo genérico de Product. |
| Registro de Review, fidelización o suscripción | Aplicación Wix o sistema externo más referencias a Product, Contact, Member u Order. |
| Estado de configurador personalizado | Propietario aplicación/Velo/CMS más Product/variante y resultado correspondiente en la línea de Order. |
| Registro de base de datos externa | Colección externa más campos de referencia de Wix y clave duradera del sistema externo. |
| Configuración de webhook o plugin de servicio | Configuración de destino que conecta sistemas, no un registro Customer o Product. |
Este modelo de propiedad evita conservar datos personalizados inutilizables. Un valor solo es duradero cuando el equipo conoce su registro padre, sistema autorizado, ciclo de vida y sistema o proceso que lo utiliza. Los campos personalizados genéricos no sustituyen una relación definida Product-aplicación, Contact-CRM, Order-mercado en línea o CMS-base de datos externa.
Cadenas representativas de relaciones en Wix
Las cadenas de relaciones hacen explícito el significado del destino al mostrar el registro padre, los registros dependientes y el propietario externo cuando corresponda. Son especialmente útiles en Wix porque comercio, CRM, Members, CMS y aplicaciones pueden contener datos sobre el mismo evento empresarial. Una cadena completa muestra qué entidad de Wix es autorizada y qué registros solo hacen referencia o presentan esos datos.
| Patrón del origen | Relación de destino en Wix |
|---|---|
| Product de ropa con stock por talla/color | Versión del catálogo → Product → opciones/elecciones → variantes → contenido multimedia/SKU de variante → Inventory Items por ubicación. |
| Regalo personalizado | Product/variante → modificador o dato propiedad de aplicación → personalización en la línea de Order → referencia de procesamiento. |
| Inventario en varias ubicaciones | Variante → ubicación Wix → Inventory Item → clave externa de almacén cuando otro sistema sigue siendo la autoridad. |
| Customer que también utiliza contenido restringido | Contact/Customer → Orders y direcciones; Member → autenticación/rol/acceso; el consentimiento permanece como relación de comunicación separada. |
| Recurso administrado por CMS vinculado con Products | Colección CMS → elementos de datos/campos de referencia → IDs de Products de Wix Stores → página dinámica/navegación. |
| Venta en mercado en línea | Order → referencia de origen/canal → instantánea de Product/variante en detalle de artículo → historial de transacción/procesamiento → ID externo de mercado en línea. |
| Category sensible para SEO | Árbol de Categories/pertenencia de Products → página del sitio o ruta de Category → navegación → URL de destino → redirección desde el origen. |
Estas cadenas conservan la propiedad específica de Wix y, al mismo tiempo, reconocen que una plataforma de origen puede haber combinado comercio, contenido, identidad y datos de aplicaciones dentro de un mismo registro o tabla.
Conclusión
La representación del modelo de datos de Wix comienza con la versión de catálogo del sitio de destino y se extiende por Wix Stores, ubicaciones de inventario, CRM Contacts, Members del sitio, eCommerce Orders, colecciones CMS, páginas, contenido Blog, aplicaciones, Velo y sistemas externos. Estas familias de registros están relacionadas, pero no son intercambiables.
Un modelo de destino sólido en Wix asigna cada valor del origen al Product, variante, customization, Category, ubicación, Inventory Item, Contact, Member, Order, elemento CMS, registro de contenido, aplicación o sistema externo que sea propietario de su significado continuo. Esta estructura conserva las relaciones comerciales y de contenido sin confundir datos históricos con configuración futura ni reducir datos especializados de aplicaciones a campos genéricos.
Preguntas frecuentes
¿Por qué importa la versión del catálogo de Wix durante una migración?
Un sitio Wix utiliza Catalog V1 o Catalog V3, y las relaciones entre entidades son diferentes. Catalog V3 utiliza variantes universales y servicios separados para inventario por variante y ubicación, Categories, marcas, Customizations, secciones de información y otros registros del catálogo.
¿Las opciones y los modificadores de Products en Wix son lo mismo?
No. Las opciones y elecciones crean variantes que pueden contener significado de SKU, precio, contenido multimedia e inventario. Los modificadores recogen personalización o información opcional sin crear una variante o identidad de inventario separada.
¿Puede todo Wix Contact convertirse en Member del sitio?
No. Un Contact es un registro de CRM y relación empresarial. Un Member tiene autenticación y puede incorporar significado de perfil, rol, permisos o acceso restringido. Un comprador puede seguir siendo Contact/Customer sin recibir una cuenta Member.
¿Los Orders migrados a Wix configuran el futuro comportamiento del checkout?
No. Los Orders conservan artículos adquiridos, elecciones, historial de pagos/reembolsos, direcciones, procesamiento, facturas y referencias externas. El funcionamiento actual de pagos, impuestos, envío, notificaciones e inventario sigue siendo configuración independiente.
¿Cuándo deben convertirse los datos personalizados del origen en una colección de Wix CMS?
Utilice CMS cuando los datos pertenezcan a un modelo de contenido estructurado o de registros personalizados que se beneficie de campos, referencias, consultas y páginas dinámicas. Products, Orders, Contacts, Blog Posts, reservas, eventos y otros registros especializados deben permanecer con sus propietarios nativos en Wix cuando ese funcionamiento sea necesario.
¿Cómo deben representarse los datos de aplicaciones de Wix y sistemas externos?
Mantenga cada valor con su Product, variante, Contact, Member, Order, elemento CMS u otro registro empresarial padre y conserve el identificador externo utilizado por la aplicación propietaria. Una nota genérica o un campo sin estructura no conserva la relación necesaria para futuras sincronizaciones.