Collegare i resi tra negozio, ERP e sistema di pagamento

Quando si collegano negozio, ERP e fornitore di pagamenti, un reso richiede più di un campo comune «completato». L’integrazione deve distinguere quale riga rientra, cosa accade alle scorte e lo stato del rimborso associato. Definisca queste relazioni prima di realizzare le interfacce.

Collegare un caso completo

Un negozio fittizio di accessori per la casa ha consegnato due vasi con l’ordine O-86 e ricevuto il pagamento. Un vaso torna con il bordo scheggiato. Nell’esempio è stato concordato un rimborso di 24 EUR per quel vaso. Il gruppo prevede questa corrispondenza:

Il collegamento usa riferimenti di righe e operazioni. Lo stesso nome o codice articolo non basta quando l’articolo compare in più ordini.

Definire un modello interno d’integrazione

Il record seguente è un modello progettato per questo caso fittizio, non una chiamata API di un fornitore. Le quantità riguardano il reso; l’importo è espresso in centesimi di 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"
  }
}

I riferimenti collegano la riga d’ordine del negozio, la sua riga di consegna e la riga di consegna ERP originale al pagamento. Registri sul caso anche il riferimento di rimborso restituito dal fornitore. Se la riga non è identificabile senza ambiguità, il record deve attendere un chiarimento invece di essere contabilizzato automaticamente confrontando i nomi.

Usare la fonte corretta per ogni modifica

Nell’esempio il negozio fornisce il legame con la riga acquistata. L’ERP conferma ricevimento, esito del controllo e rilascio delle scorte. Il fornitore di pagamenti fornisce lo stato del rimborso. Il contratto dati specifica queste responsabilità; una diversa ripartizione tra sistemi può richiedere assegnazioni diverse.

ReturnLineItem di Shopify rimanda a una riga di consegna Shopify; l’integrazione deve creare il collegamento con la riga ERP. La documentazione di Refund precisa che un record da solo non conferma un movimento di denaro riuscito. Anche Stripe descrive eventi distinti per creazione, aggiornamento e fallimento. L’integrazione deve associare gli stati effettivi del fornitore scelto al proprio modello interno.

Un rimborso riuscito deve quindi cambiare solo lo stato del pagamento nell’esempio. Non rende vendibile il vaso danneggiato. Allo stesso modo, ricevere la merce non rende automaticamente riuscito il rimborso.

Verificare il risultato atteso

Verifichi il caso in un ambiente di prova adeguato: il reso parziale appartiene alla riga corretta, la variazione di scorta resta 0 e i 2400 centesimi sono legati al pagamento corretto. Quando il rimborso riuscito è confermato, il suo stato cambia mentre la merce resta bloccata. Una risposta di pagamento ambigua deve rimanere visibile come irrisolta. Una notifica ripetuta deve aggiornare lo stesso caso. La gestione tecnica dei nuovi tentativi richiede anche una strategia di idempotenza adeguata.

Fonti

• Shopify — ReturnLineItem, GraphQL Admin API

• Shopify — Refund, GraphQL Admin API

• Stripe — Refund and cancel payments