Multilevel omnichannel inventory es la configuración de VTEX que permite que una cuenta principal ofrezca el stock de sellers white label y de cuentas franquicia para la venta en los marketplaces. Esta función solo está disponible para los mercados y vendedores de VTEX.

Este artículo incluye la siguiente información sobre la funcionalidad:

• Arquitectura de cuentas
• Beneficios
• Restricciones
• Cómo configurar

Para obtener más información sobre la arquitectura de los pedidos de tipo Multilevel Omnichannel Inventory y aprender a realizar la configuración a través de la API REST, consulta nuestro artículo en el Developer Portal.

El marketplace es el entorno donde se vende el producto, también llamado vitrina, y el seller es el propietario del envío del producto.

Cuando una tienda vende sus productos en un marketplace, tenemos una relación de dos niveles. Sin embargo, la arquitectura de VTEX permite que las tiendas actúen tanto como marketplaces como sellers, ampliando el número de combinaciones posibles.

Es posible que un seller de una cuenta principal actúe como marketplace para sellers white label. Este es el caso de las redes de tiendas configuradas como cuentas franquicia y de las tiendas físicas, que son por definición sellers en otra tienda VTEX.

También es posible que este seller principal venda sus productos en un marketplace.

Cuando esto ocurre, tenemos una arquitectura de tres niveles entre el marketplace, el seller principal y sus sellers white label, como se ilustra en la imagen de abajo.

De forma predeterminada, los productos de las tiendas físicas, o sellers white label (nivel 3 en la imagen), no están disponibles para ser vendidos por el marketplace de nivel 1, pero con la funcionalidad Multilevel Omnichannel Inventory puedes disponibilizarlos.

De este modo, es posible que un marketplace venda los productos de sus sellers directos, así como de las tiendas físicas y de los sellers white label vinculados a estos sellers.

Esto significa que cuando el seller de la cuenta principal configura una integración con un marketplace, las cuentas franquicia también se integran automáticamente con él, por lo que no es necesario gestionar cada franquicia individualmente para configurar su integración con el marketplace.

Actualmente, solo se permite un nivel de recursión. En otras palabras, el marketplace puede vender productos de sellers white label integrados con un seller directo.

Esta funcionalidad aporta ventajas competitivas al marketplace, como:

• Mayor diversidad de productos ofrecidos al cliente final.
• Menos problemas de stock insuficiente al incluir más tiendas que ofrecen productos.
• La opción de ofrecer todo el stock de una operación omnichannel a otros marketplaces, aumentando la oferta de puntos de recogida, por ejemplo.
• La posibilidad de trabajar con nuevos modelos de negocio y conectar diferentes marcas con relaciones de colaboración entre el marketplace y el seller.
• Acceso a nuevos mercados y nichos de consumidores.
• Orquestar los pedidos de múltiples canales con visibilidad sobre toda la cadena.

Para más información sobre la arquitectura de pedidos aplicada en Multilevel omnichannel inventory, consulta nuestro artículo para desarrolladores.

Algunas de las funcionalidades que forman parte del modelo tradicional de marketplace no están disponibles para un escenario de Multilevel omnichannel inventory. Es importante conocer estas restricciones antes de habilitar la configuración.

La funcionalidad Multilevel Omnichannel Inventory está disponible únicamente para marketplaces VTEX. Para utilizar la funcionalidad, el marketplace (nivel 1) debe realizar la configuración para cada seller directo (nivel 2) deseado. Puedes hacerlo al registrar nuevos sellers o al editar la configuración de sellers existentes en tu tienda. Consulta más información accediendo a Configurar y al Developer portal.

No es posible distribuir las cuentas por cobrar en toda la cadena (marketplace, seller directo y sellers white label). Los pagos de los pedidos de Multilevel Omnichannel Inventory solo pueden realizarse en el marketplace. La conciliación y la transferencia de valores a los sellers de nivel 3 deben realizarse fuera de VTEX, ya que no hay soporte nativo para esta etapa.

Puedes utilizar la solución de split de pagos solo para dividir las cuentas por cobrar entre los niveles marketplace y seller directo (nivel 2). En este caso, se recomienda utilizar el split de cobros.

En estos casos, el seller directo se convierte en receptor de los ítems de sus sellers white label y de sus propios ítems, eliminando las comisiones establecidas en la relación con el marketplace.

La solución puede ser suficiente en los casos en que el seller directo forma parte del mismo grupo económico que sus sellers white label, lo que permite concentrar todas las cuentas por cobrar en una sola cuenta bancaria.

Es importante destacar que cuando el seller directo no es responsable de las cuentas por cobrar de los sellers white label, la solución de split de cobros estará limitada al no permitir la distribución a los sellers white label.

Una vez realizada la configuración, solo los medios de pago del marketplace aparecerán como opción en el checkout. Los medios de pago de los sellers directos (nivel 2) y de los sellers white label (nivel 3) no se importan a la arquitectura de las cuentas. Por lo tanto, el checkout solo muestra los medios de pago del marketplace, incluso si el afiliado del seller directo está configurado para utilizar sus medios de pago.

El afiliado de la cuenta franquicia debe tener siempre desmarcada la opción de usar los medios de pago.

Si un seller white label (nivel 3) recibe un pedido y lo rechaza, este pedido no se asigna a otro seller white label. En consecuencia, el comprador deberá crear un nuevo pedido en el storefront del marketplace. Obtén más información en Change seller.

La tienda no puede modificar los pedidos finalizados en un escenario de Multilevel Omnichannel Inventory. Por lo tanto, debe cancelar el pedido y crear uno nuevo. Consulta más información en Change chain orders in external marketplaces.

El cliente no puede modificar los pedidos en la sección Mis pedidos del storefront del marketplace. Cualquier cambio en los pedidos debe realizarse a través del servicio de soporte al cliente o vía API.

La funcionalidad Manual price no se aplica al Multilevel omnichannel inventory. Por lo tanto, no es posible modificar manualmente los precios en el carrito. Es necesario actualizar el precio a través de:

• Integración con el ERP
• Pricing API REST
• Página de precios en el Admin VTEX

Cuando un nuevo usuario realiza una compra, sus datos no se registran en el Profile system del seller directo, que es la tienda que realizó la venta (nivel 2 en el diagrama anterior). Es decir, el seller no tiene visibilidad de este usuario. Los datos del perfil del usuario solo se guardarán en el marketplace, que es responsable de toda la comunicación con él. Obtén más información en Información compartida entre el marketplace y el seller en VTEX.

Un marketplace no puede configurar la exhibición de los precios y la disponibilidad de los productos para los sellers white label (nivel 3) con la funcionalidad Region.

La aplicación de cupones,tarjetas de regalo (vales) y beneficios vinculados a los UTM está restringido a marketplaces nivel 1. No se aplicarán los configurados en sellers directos (nivel 2) ni en cuentas franquicia o sellers white label (nivel 3).

No es posible crear tablas de precios mediante la funcionalidad Tablas de precios. Los precios deben registrarse vía integración con ERP o a través de plantillas.

La configuración de la funcionalidad Multilevel omnichannel inventory debe ser realizada por el marketplace en tu Admin VTEX o a través de la API Rest. Esta configuración puede realizarse tanto para los sellers ya integrados como para los sellers agregados por primera vez.

Ten en cuenta que la configuración debe realizarse para cada seller directo (nivel 2) al que quieras aplicar la funcionalidad, pero no para cada cuenta de seller white label o cuenta franquicia (nivel 3).

Para configurarla en los sellers que se han integrado previamente, el marketplace debe seguir los pasos a continuación.

1. En el Admin VTEX, ve a Marketplace > Gestión.

2. En la fila correspondiente al seller cuyos sellers white label deseas acceder, haz clic en .

3. Haz clic en Datos del seller.

4. Rellena el campo Fulfillment endpoint siguiendo el ejemplo: https://{{sellerAccount}}.vtexcommercestable.com.br/api/checkout?affiliateid={{affiliateId}}&sc={{tradePolicyId}}

5. Sustituye los campos que están entre llaves por los valores que se describen a continuación, eliminando las llaves:

   • sellerAccount: el nombre de la cuenta del seller en VTEX.
   • affiliateId: el código de tres dígitos correspondiente al afiliado creado por el seller. El seller debe informar este valor al marketplace.
   • tradePolicyId: ID de la política comercial creada por el seller en su propio entorno VTEX para vender en su marketplace. El seller debe informar este valor al marketplace.

6. Haz clic en Guardar.

Si el marketplace desea agregar un nuevo seller con Multilevel omnichannel inventory configurado desde cero, debe seguir las instrucciones en Agregar seller y rellenar el campo Fulfillment endpoint siguiendo los paso 4 y 5 del tutorial en Sellers ya integrados.

Supongamos que tu marketplace ya está integrado con el seller "Tienda ABC" y quieres vender productos de sellers white label integrados con ese seller.

Actualmente, el valor del campo Fulfillment endpoint del seller tiene el siguiente formato y se puede identificar accediendo a Marketplace > Sellers > Gestión de sellers:

https://storeabc.vtexcommercestable.com.br/api/fulfillment?affiliateId=mkp&sc=2

Para habilitar la funcionalidad Multilevel omnichannel inventory, el nuevo valor del campo debe contener el endpoint de **checkout, **en lugar del endpoint de fulfillment:

https://storeabc.vtexcommercestable.com.br/api/checkout?affiliateid=mkp&sc=2

Ten en cuenta que los valores introducidos en los campos sellerAccount, affiliateId y tradePolicyId que ya estaban rellenados en el endpoint de fulfillment permanecen los mismos en el endpoint de checkout. Lo que cambia es el fragmento /checkout.