Aprobación de pedidos B2B en Shopify: funciones nativas, apps o portal a medida

La aprobación de pedidos B2B en Shopify puede referirse a tres necesidades distintas. El comerciante puede aprobar el alta de una empresa, revisar un pedido entrante o permitir que un empleado del cliente solicite autorización a su propio responsable de compras. Solo el tercer caso es una aprobación de compra del lado del cliente. La solución depende de quién aprueba, qué aprueba y qué debe permanecer bloqueado hasta entonces.

Una consulta de un comerciante en Shopify Community plantea exactamente ese recorrido: solicitud del empleado, aprobación de su responsable y visibilidad para el proveedor únicamente después. Un botón que diga «Enviar para aprobación» no garantiza que decida la organización correcta.

Revisado el 29 de septiembre de 2026. Los datos de plataforma proceden de Shopify. Las funciones de las aplicaciones son afirmaciones documentadas por sus proveedores, no certificaciones mediante pruebas propias. La arquitectura y los criterios de aceptación son recomendaciones de Wavect.

¿Qué flujo de aprobación de Shopify necesita realmente?

Empiece por las funciones nativas para la revisión del vendedor; pruebe una aplicación de equipos compradores para la autorización empleado-responsable; encargue desarrollo a medida solo para requisitos que la aplicación no pueda hacer cumplir con fiabilidad. Varios aprobadores o una conexión ERP exigen pruebas más cuidadosas, no necesariamente una tienda nueva.

Escriba una condición concreta: «Un empleado de la sucursal A puede solicitar productos, pero solo el responsable asignado a A puede liberar esa solicitud exacta, y antes no puede existir un pedido de Shopify ni un pedido de venta en el ERP». Adáptela a su política. Que ya pueda existir un borrador en Shopify es una decisión distinta y esencial.

¿Qué permite Shopify de forma nativa, también en Grow?

La matriz de funciones B2B por plan de Shopify incluye empresas, permisos por sucursal, checkout convertido en borrador y números de orden de compra en Basic, Grow, Advanced y Plus. Afirmar que todo B2B nativo o toda revisión de borradores requiere Plus está desactualizado. Siguen existiendo restricciones de funciones específicas.

Aprobar una cuenta permite entrar, no autoriza cada compra

Las solicitudes de cuenta de empresa mediante Shopify Forms permiten al comerciante conceder acceso B2B. Es un proceso de alta. Una aplicación que aprueba registros no tiene por qué enviar cada carrito de un empleado a su responsable de compras.

La revisión de borradores pertenece al comerciante

En la interfaz administrativa en inglés, siga Customers → Companies → company → location → Checkout → Order submission y seleccione Submit all orders as drafts for review. Shopify lo explica en sus ajustes de checkout. La solicitud llega a la cola de borradores del vendedor sin pago durante ese checkout.

Encaja cuando su propio equipo comprueba existencias, transporte, precios negociados o crédito antes de aceptar la venta. No demuestra, por sí solo, que el responsable del cliente haya autorizado el gasto. Tampoco cumple «el vendedor no debe ver nada antes de la aprobación del cliente»: el vendedor ya dispone del borrador.

Administrador de sucursal no equivale a aprobador de compras

Shopify documenta dos permisos de clientes para sucursales de empresa: Ordering only, con el historial propio, y Location admin, con todos los pedidos de la sucursal y edición de direcciones. Esas descripciones no establecen una cadena de aprobación del responsable. No confunda permisos del cliente con acceso del personal al panel del comerciante.

Separe también precio y autorización. Shopify indica que los borradores enviados desde el checkout B2B mantienen los precios bloqueados por defecto. Ese bloqueo no acredita consentimiento, no reserva presupuesto departamental ni decide si cambiar una dirección de entrega exige otra aprobación. Son reglas distintas.

Un número de orden de compra es una referencia, no una prueba de que el titular del presupuesto aprobó su contenido. «Todavía no pagado» y «todavía no autorizado» tampoco significan lo mismo. El diseño debe definir ambos estados sin convertir un aplazamiento del pago en un control de compras.

¿Pueden Shopify Flow o Functions gestionar aprobaciones del comprador?

Utilice Flow para coordinar acciones, no como sustituto de una política de compras que se haga cumplir. Shopify Flow está disponible en Basic, Grow, Advanced y Plus. La acción Send HTTP Request requiere Grow, Advanced o Plus y puede conectar el proceso con un servicio externo.

Existe una limitación importante: Send internal email no admite una dirección de destinatario variable. Para avisar a un responsable distinto en cada empresa necesita una integración adecuada de notificaciones transaccionales. Una dirección fija del personal no constituye enrutamiento dinámico a compradores externos.

Defina el punto de bloqueo antes de automatizar mensajes. Un flujo que actúa después de crear el pedido no puede impedir su creación hasta la aprobación del responsable. Además, un enlace de autorización necesita una comprobación en el servidor: la persona autenticada debe poder aprobar la versión actual de esa solicitud, para esa empresa y sucursal.

La documentación de disponibilidad de Shopify Functions distingue las aplicaciones públicas con Functions, disponibles entre planes con las restricciones de cada API, de las aplicaciones personalizadas que contienen Functions, que requieren Plus. No presuponga que una agencia puede desplegar cualquier Function propia de checkout en Grow.

La restricción de la operación concreta es todavía más precisa: la Payment Customization Function API, revisada en su versión 2026-07, limita orderReviewAdd a B2B en Plus y describe revisión por el comerciante. Esto no contradice el checkout como borrador configurado por sucursal en todos los planes. Son controles distintos y ninguno aporta por sí solo un portal completo de aprobación del comprador.

Confirme el plan, el modelo de distribución de la aplicación, la operación exacta y la ruta de checkout admitida. «Utiliza Shopify Functions» no es una respuesta suficiente sobre compatibilidad.

¿Funciones nativas, aplicación de aprobación o portal a medida?

Elija la solución fiable más pequeña. Una aplicación y un conector ERP limitado pueden resultar mejores que una cadena frágil de automatizaciones o una plataforma de compras totalmente propia. Varias aplicaciones baratas tampoco son económicas si ninguna controla de forma definitiva la decisión.

¿Qué aplicaciones de aprobación conviene evaluar?

SparkLayer: un proceso documentado del lado comprador

La documentación Company Users de SparkLayer describe un rol Limited cuyas solicitudes pasan al titular de la cuenta de empresa. Las solicitudes pendientes permanecen ocultas para el comerciante. El titular puede completarlas o cancelarlas. Esto sí aborda autorización del cliente y no solamente revisión del proveedor.

Considérelo un candidato para probar, no una garantía de encaje universal. Pida una demostración con su configuración de cuentas, precios, métodos de pago y rutas alternativas de checkout. Compruebe aprobadores por sucursal, umbrales, presupuestos acumulados y cambios posteriores al envío. La aprobación de un titular no equivale, sin más pruebas, a un motor arbitrario de políticas multinivel.

Approovly: verificar quién aprueba y el funcionamiento actual

La ficha de Approovly en Shopify App Store anuncia solicitudes de aprobación internas y externas. La ficha no demuestra su jerarquía empresarial ni un bloqueo previo a la creación del pedido. Compruebe mantenimiento actual, respuesta del soporte y una demostración completa antes de seleccionarla.

Para ambas aplicaciones, solicite ver la misma operación como empleado, aprobador y comerciante al mismo tiempo. Observe cuándo aparecen el borrador, pedido, solicitud de pago y mensaje al ERP. Después cambie el importe, acceda desde otra empresa y reutilice un enlace antiguo. Estas pruebas aportan más que una larga lista comercial de funciones.

Incluya exportación de datos, conservación del historial, comportamiento al desinstalar, permisos solicitados y responsabilidad por fallos de integración. Pida confirmación escrita del plan compatible y de si la aplicación sustituye, complementa o evita el modelo B2B existente. La comparación se basa en documentación, no en una prueba de instalación de ninguno de los productos.

¿Cuándo se justifica un portal de compradores a medida?

El desarrollo a medida se justifica cuando una regla comercialmente importante no puede aplicarse o demostrarse con la configuración disponible. El alcance debe ser la capa de aprobación que falta, no reconstruir Shopify.

No siempre necesita otra tienda. Shopify permite extensiones de página completa en cuentas de cliente, incluidas páginas no vinculadas a un pedido existente. Evalúe una página integrada de solicitudes y aprobaciones antes de crear otra experiencia de compra. Confirme la compatibilidad de las cuentas y las capacidades necesarias de la extensión.

Mantenga en el servidor el registro autorizado de cada solicitud: empresa y sucursal, solicitante, aprobadores admisibles, versión de la política, moneda y base del cálculo. Vincule la decisión a una instantánea versionada de referencias, cantidades, precios, tratamiento fiscal, transporte y dirección. No confíe en un atributo editable del carrito ni en una etiqueta «approved» enviada por el cliente.

Si el comerciante no debe ver la compra antes de la aprobación, conserve la requisición en el almacenamiento de la aplicación y cree el borrador o pedido de Shopify solo después de liberarla. Si se admiten borradores visibles para el vendedor, pueden formar parte del proceso, pero deben protegerse la finalización y los enlaces de factura contra posibles vías alternativas. Inventario y caducidad de la oferta también necesitan reglas explícitas.

Separe estados de solicitud como pending_approval, approved, rejected y expired de la creación en Shopify, el pago y la entrega al ERP. Una solicitud puede estar aprobada mientras falla su transmisión. Llamar «completo» a ambos acontecimientos oculta la excepción que operaciones debe resolver.

Límites de gasto y varios aprobadores requieren reglas precisas

Un umbral por pedido no es un presupuesto mensual. Defina si incluye impuestos y transporte, qué moneda manda, si las solicitudes pendientes reservan fondos y cuándo una denegación o cancelación los libera. En presupuestos compartidos, compruebe y reserve capacidad de forma atómica para que dos solicitudes simultáneas no consuman el mismo saldo.

Política ilustrativa, no configuración nativa de Shopify: una empresa de ocho sucursales permite autoliberar compras de hasta €500 si queda presupuesto mensual suficiente. Por encima de €500 aprueba el responsable de sucursal; por encima de €5.000 también finanzas. El responsable de otra sucursal carece de autoridad. Los cambios sustanciales crean otra versión e invalidan la aprobación anterior.

Especifique si las aprobaciones son secuenciales, paralelas con unanimidad o basadas en un cuórum. La delegación debe tener caducidad y trazabilidad. Las vacaciones de un responsable no deben provocar aprobación automática silenciosa; un enlace antiguo no debe conservar permisos revocados. Son criterios para una aplicación comprada y para una solución propia.

¿Cómo llegan los pedidos aprobados a Shopify y al ERP?

Defina la transferencia antes de programarla. ¿Shopify es el sistema principal de pedidos o debe el ERP validar primero crédito, existencias y correspondencias de clientes? ¿Quién libera la preparación y envío? La aprobación del comprador permite continuar; no demuestra que las comprobaciones posteriores hayan terminado correctamente.

La mutación draftOrderComplete de Shopify convierte un borrador en pedido y ofrece opciones relacionadas con el pago. Ejecutarla no equivale por sí mismo a haber cobrado. Nunca marque un pedido como pagado únicamente porque lo autorizó un responsable; respete el proceso de facturación o las condiciones de pago acordadas.

En una integración propia, mantenga una correspondencia duradera entre ID y versión de la requisición, ID del borrador o pedido de Shopify y referencia ERP. Guarde una tarea de liberación junto con la decisión y procésela mediante una cola con reintentos. Evite duplicados con idempotencia de aplicación y una referencia o restricción de unicidad apropiada en el ERP.

Si una creación termina en timeout, su resultado es desconocido, no necesariamente fallido. Reconcilie los registros existentes antes de reintentar. Shopify advierte que no garantiza el orden ni la entrega de webhooks. Verifique autenticidad, elimine entregas duplicadas y ejecute conciliación en vez de depender de una sola notificación.

Si el ERP no está disponible, muestre «aprobado, pendiente de ERP» y mantenga bloqueada la expedición cuando lo exija la política. No oculte el problema con un correo de éxito. Operaciones necesita un reintento que conserve la misma referencia comercial, no un botón que cree involuntariamente otro pedido.

Para un backend Odoo, consulte nuestra guía de límites de integración de la API de Odoo. El flujo de aprobación determina cuándo se autoriza la compra; el conector determina cómo se entrega con fiabilidad al ERP.

¿Qué debe probar antes de comprar o publicar?

Pida al proveedor o al equipo de implementación que ejecute estos casos con roles reales y pedidos representativos en un entorno no productivo. «Llegó el correo de aprobación» solo supera la prueba de notificación.

Conserve versiones, decisiones, identidades y referencias posteriores como evidencia. Demuestre una compra correcta y la recuperación ante fallos. El sistema debe responder quién autorizó qué contenido, con qué política y qué registros de Shopify y ERP resultaron.

¿Qué debe incluir una evaluación del flujo y una propuesta?

Prepare el plan de Shopify, la configuración de cuentas, un recorrido de pedido actual, roles de empresa y sucursal, límites, reglas de pago, datos del ERP y un caso fallido o gestionado manualmente. Oculte datos personales y comerciales sensibles antes de compartir ejemplos.

Una evaluación útil entrega un mapa del proceso actual y deseado, una recomendación nativo/app/a medida, un modelo de permisos y estados, el límite de la integración y las pruebas de aceptación. La propuesta debe especificar supuestos, configuración frente a programación, licencias de terceros, migración, responsabilidad operativa y exclusiones expresas.

Compare coste operativo total, no únicamente suscripción y presupuesto de desarrollo. Incluya configuración, integración, soporte, cambios de política, pruebas de regresión y gestión de excepciones. Calcule la situación inicial con su tiempo por solicitud y volumen mensual. Añada el retrabajo medido por separado; no dé por hecho un aumento genérico de velocidad o ingresos.

El caso MyMerch de Wavect describe automatización selectiva de procesos Shopify, no una reconstrucción de plataforma. Es experiencia de entrega relacionada, no una afirmación de que MyMerch utilizara la arquitectura de aprobación descrita aquí.

Para la decisión general, consulte software a medida frente a software estándar. Para una carencia de implementación, nuestro servicio de desarrollo de software a medida es el siguiente paso comercial. Consulte una evaluación de su flujo de aprobación B2B en Shopify con Wavect y solicite una propuesta acotada basada en los controles que realmente necesita.