Vincular devoluciones entre tienda, ERP y sistema de pago

Al conectar tienda, ERP y proveedor de pagos, una devolución necesita más que un campo común «terminado». La integración debe identificar qué línea vuelve, qué ocurre con las existencias y el estado del reembolso asociado. Defina estas relaciones antes de implementar las interfaces.

Vincular un caso completo

Una tienda ficticia de accesorios para el hogar entregó dos jarrones en el pedido O-86 y recibió el pago. Un jarrón vuelve con el borde astillado. En este ejemplo se ha acordado un reembolso de 24 EUR para ese jarrón. El equipo prevé la siguiente relación:

El vínculo utiliza referencias de líneas y operaciones. Coincidir en nombre o código de artículo no basta cuando el mismo artículo aparece en varios pedidos.

Definir un modelo interno de integración

El registro siguiente es un diseño propio para este caso ficticio, no una llamada a la API de un proveedor. Las cantidades se refieren a la devolución; el importe se expresa en céntimos de EUR.

{
  "returnId": "R-86",
  "orderReference": "O-86",
  "shopOrderLine": "OL-86-A",
  "shopFulfillmentLine": "FL-86-A",
  "erpDeliveryLine": "DL-86-A",
  "receivedQuantity": 1,
  "saleableStockDelta": 0,
  "refund": {
    "paymentReference": "PAY-86",
    "amountMinor": 2400,
    "currency": "EUR",
    "state": "requested"
  }
}

Las referencias vinculan la línea del pedido de tienda, su línea de entrega y la línea original de entrega en ERP con el pago. Guarde también en el caso la referencia de reembolso devuelta por el proveedor. Si la línea no puede identificarse de forma inequívoca, el registro debe quedar pendiente de aclaración, en vez de contabilizarse automáticamente mediante coincidencia de nombres.

Usar la fuente correcta para cada cambio

En el ejemplo, la tienda aporta el vínculo con la línea comprada. El ERP confirma recepción, resultado de inspección y liberación del stock. El proveedor de pagos aporta el estado del reembolso. El contrato de datos recoge estas responsabilidades; otra distribución de sistemas puede requerir otras asignaciones.

ReturnLineItem de Shopify apunta a una línea de entrega de Shopify; la integración debe establecer el vínculo con la línea del ERP. La documentación de Refund aclara que un registro por sí solo no confirma un movimiento de dinero exitoso. Stripe también describe eventos separados para creación, actualización y fallo. La integración debe vincular los estados reales del proveedor elegido con su modelo interno.

Por tanto, un reembolso exitoso solo debe cambiar el estado del pago en este ejemplo. No convierte el jarrón dañado en vendible. Recibir la mercancía tampoco hace que el reembolso tenga éxito automáticamente.

Comprobar el resultado esperado

Compruebe el caso en un entorno de prueba adecuado: la devolución parcial pertenece a la línea correcta, el cambio de stock sigue en 0 y los 2400 céntimos corresponden al pago correcto. Al confirmarse el reembolso exitoso cambia su estado, mientras la mercancía sigue bloqueada. Una respuesta de pago ambigua debe seguir visible como no resuelta. Una notificación repetida debe actualizar el mismo caso. La gestión técnica de los reintentos también requiere una estrategia de idempotencia adecuada.

Fuentes

• Shopify — ReturnLineItem, GraphQL Admin API

• Shopify — Refund, GraphQL Admin API

• Stripe — Refund and cancel payments