Devoluciones omnicanal: cómo conectar tienda online, tienda física y ERP

Las devoluciones omnicanal se ponen a prueba cuando alguien llega a una tienda con una prenda comprada online y el personal no encuentra el pedido. Aceptar la bolsa es fácil; identificar la venta, recuperar el stock, emitir la factura rectificativa y devolver el dinero sin duplicidades exige conectar sistemas y responsabilidades.

Para un retailer de moda, el objetivo no es añadir un botón de «devolver». Es conseguir que tienda, ecommerce, pasarela de pago y ERP compartan una operación trazable. Este es el flujo que conviene definir y convertir en requisitos antes de contratar la integración.

Devoluciones omnicanal: una operación, varios sistemas

El comercio unificado necesita una visión compartida de pedidos, clientes, pagos e inventario, aunque cada dato tenga un sistema responsable diferente. No implica que todo deba vivir en una única aplicación.

• Ecommerce: conserva el contexto de compra, las promociones y la relación con el cliente.
• TPV: permite al personal identificar la operación, inspeccionar el artículo y registrar su recepción.
• ERP: gestiona los movimientos de inventario, la documentación fiscal y la contabilidad según la arquitectura acordada.
• Pasarela: ejecuta el reembolso sobre el pago original y comunica su resultado.
• Capa de integración: transporta eventos, controla duplicidades y facilita resolver incidencias.

Antes de desarrollar, asigna un sistema maestro a cada dato. Si TPV y ecommerce calculan por separado el importe reembolsable, pueden aplicar reglas distintas a una misma promoción.

Diseña el flujo completo, desde el pedido hasta la conciliación

1. Identificar el pedido y comprobar qué puede devolverse

El cliente debería poder presentar un QR, un número de pedido o una referencia verificable. La búsqueda debe mostrar únicamente la información necesaria, con permisos por rol y sin exponer datos de otros compradores.

El TPV consulta las líneas originales: SKU, talla, color, unidades entregadas, precio pagado, impuestos, descuentos y devoluciones anteriores. La elegibilidad se calcula sobre unidades disponibles para devolver, no sobre las inicialmente compradas.

También debe comprobar vendedor y sociedad: una tienda franquiciada o de otra entidad jurídica no puede tratarse automáticamente como un punto de devolución de la misma empresa. Ese circuito requiere acuerdos y tratamiento contable específicos.

2. Validar la política y fijar el importe

Separa la obligación legal de la política comercial. En España, el desistimiento de compras a distancia dispone, con carácter general y salvo excepciones, de 14 días naturales. Poder devolver una compra online en tienda física debe estar previsto en el procedimiento comunicado; no se deduce automáticamente del derecho de desistimiento.

El reembolso por desistimiento se realiza mediante el mismo medio de pago, salvo acuerdo expreso distinto sin costes para el consumidor. La norma también regula plazos y la posible retención hasta recibir los bienes o una prueba de devolución (fuente: Real Decreto Legislativo 1/2007, artículos 102 a 108).

El motor de cálculo debe recuperar los descuentos asignados a cada línea, el IVA y los gastos que corresponda devolver según el supuesto. Una devolución parcial, un lote promocional y un desistimiento completo no comparten necesariamente el mismo cálculo.

3. Registrar la recepción y decidir el destino del artículo

El personal confirma unidades, estado y motivo. «Recibido» no equivale a «disponible para vender»: una prenda puede requerir revisión, reacondicionamiento o traslado.

• Apto: entra en el stock vendible de la ubicación correspondiente.
• Pendiente de revisión: queda bloqueado en una ubicación de cuarentena.
• Dañado: sigue el circuito de incidencia, reparación o merma.

Registra cada movimiento con referencia a la devolución. Así evitas incrementar el inventario al recibir la prenda y volver a incrementarlo cuando el ERP procese el mismo evento. Esta separación complementa una buena gestión de inventario para evitar roturas de stock.

4. Generar la documentación fiscal correcta

El ERP debe recibir la referencia de venta, las líneas afectadas, bases, cuotas e importes. Cuando corresponda, emitirá la factura rectificativa vinculada a la factura original, respetando series y reglas fiscales. Si el documento original es una factura simplificada, hay que definir su circuito de rectificación, no inventar una factura ordinaria para facilitar la integración.

Un abono interno no sustituye por sí solo al documento fiscal exigible. El diseño debe validarse con administración o asesoría, conforme al Reglamento de facturación, Real Decreto 1619/2012, artículo 15.

5. Ejecutar el reembolso y confirmar su resultado

Para los reembolsos ecommerce, conserva el identificador de la transacción original. La solicitud a la pasarela debe llevar una clave de idempotencia: si hay un corte y se reintenta, no puede devolver el dinero dos veces.

Distingue «solicitado», «pendiente», «confirmado» y «fallido». Un tiempo de espera agotado no demuestra un fallo: antes de repetir la operación, consulta su estado. El justificante entregado al cliente debe reflejar la situación real, sin prometer un abono inmediato en su cuenta.

6. Conciliar y cerrar la devolución

El cierre debe relacionar pedido, devolución, recepción, documento rectificativo, identificador del reembolso y registro contable. Después se concilia el movimiento con la liquidación de la pasarela o el extracto correspondiente.

Una devolución puede estar recibida y documentada, pero seguir pendiente de reembolso. Por eso conviene mantener estados separados para mercancía, fiscalidad y pago, además de una cola de excepciones con responsable y fecha de resolución.

Un ejemplo: una chaqueta devuelta en tienda

Una clienta compra una chaqueta y un pantalón por 150 euros tras aplicar un descuento. El pedido guarda 90 euros asignados a la chaqueta y 60 al pantalón. Devuelve únicamente la chaqueta en una tienda de la misma sociedad.

1. El TPV localiza el pedido y confirma que esa unidad no se ha devuelto.
2. La regla comercial validada recupera los 90 euros de la línea, sin recalcular arbitrariamente el precio de catálogo.
3. La tienda recibe la prenda y la registra en cuarentena porque falta revisar una etiqueta.
4. El ERP emite el documento rectificativo correspondiente con el desglose fiscal original.
5. La pasarela procesa un reembolso parcial de 90 euros contra el pago inicial.
6. La conciliación comprueba ese movimiento; la prenda solo pasa a vendible tras aprobar la revisión.

Si la promoción exigía conservar ambos artículos, la regla aplicable debe haberse definido y comunicado previamente. No debería decidirla el cajero ni improvisarla el conector.

Matriz de responsabilidades para contratar la integración

La integración ecommerce TPV ERP necesita responsables de negocio, no solo endpoints. Esta matriz es un punto de partida: adapta los nombres a tu organización y designa una persona que apruebe cada bloque.

Casos de prueba que deben figurar en el contrato

No aceptes «las devoluciones funcionan» como criterio de entrega. Exige pruebas en un entorno representativo, con datos anonimizados o sintéticos y evidencias en todos los sistemas afectados.

• Devolución parcial con descuento: importe e impuestos coinciden con la asignación original.
• Doble intento simultáneo: dos tiendas intentan devolver la misma unidad; solo una operación se acepta.
• Reintento y webhook duplicado: se generan un único reembolso, un único movimiento de stock y una única rectificación.
• ERP no disponible: la operación sigue el circuito acordado, queda visible como pendiente y se recupera sin duplicados.
• Respuesta de pago incierta: el sistema consulta el estado antes de reenviar la solicitud.
• Pago mixto o tarjeta regalo: se respeta el reparto definido por medio de pago.
• Artículo dañado: se registra la recepción sin aumentar el stock vendible.
• Venta de otra sociedad: se bloquea o deriva al procedimiento autorizado.
• Cambio de talla: devolución y nueva venta quedan vinculadas, sin ocultar sus movimientos fiscales y económicos.
• Conciliación con diferencias: una comisión o liquidación agrupada no modifica el importe reconocido al cliente.

Añade tiempos máximos de sincronización, alertas, permisos, conservación de registros y procedimiento ante caída del TPV. El contrato debe incluir documentación de APIs, acceso a registros, política de reintentos y soporte para resolver operaciones incompletas.

Preguntas frecuentes

¿Se puede devolver una compra online en cualquier tienda física?

Depende de la política y del circuito habilitado por el vendedor. Comprueba establecimientos admitidos, entidad vendedora, documentación y condiciones, sin confundir esa facilidad comercial con los derechos legales del consumidor.

¿La devolución debe pagarse desde el datáfono de la tienda?

No necesariamente. Si el pago original fue online, el TPV puede iniciar una solicitud para que la pasarela original ejecute el reembolso. Deben respetarse las reglas legales y las capacidades del proveedor.

¿Cuándo vuelve la prenda al stock disponible?

Cuando se confirma que puede venderse y se registra en la ubicación adecuada. La recepción física puede producirse antes, manteniendo el artículo bloqueado mientras se revisa.

¿Qué ocurre si falla el ERP durante la devolución?

Debe aplicarse el procedimiento acordado: bloqueo controlado o recepción pendiente, según el diseño. La incidencia tiene que quedar registrada y recuperarse sin duplicar documentos, stock ni pagos.

Conclusiones: contratar un circuito, no un conector

Una devolución omnicanal está resuelta cuando mercancía, fiscalidad y dinero cuadran. Identificar responsables, separar estados y probar fallos reales es más importante que añadir otra pantalla al TPV.

En Konex abordamos estos proyectos definiendo el proceso y conectando ecommerce, TPV, ERP y pagos mediante APIs. KonexCommerce puede actuar como plataforma de venta dentro de esa arquitectura; la elección depende de los sistemas existentes y de las reglas operativas, no al revés.

Si necesitas ordenar este circuito, consulta los servicios de Konex y plantea una revisión del flujo, sus responsabilidades y los criterios de aceptación antes de empezar el desarrollo.