Kobl returdata mellem webshop, ERP og betalingssystem
En gennemarbejdet datakontrakt forbinder ordrelinje, ERP-varemodtagelse og tilbagebetaling. Separate statusser forebygger forkerte lager- og betalingsvisninger.

Når du forbinder webshop, ERP og betalingsudbyder, kræver en retur mere end et fælles felt «færdig». Integrationen skal kunne se, hvilken linje der kommer tilbage, hvad der sker med lageret, og hvilken status den tilhørende tilbagebetaling har. Fastlæg relationerne, før du bygger grænsefladerne.
Knyt et helt forløb sammen
En fiktiv webshop med boligtilbehør har leveret to vaser med ordre O-86 og modtaget betaling. En vase kommer tilbage med et skår i kanten. I eksemplet er en tilbagebetaling på 24 EUR aftalt for denne vase. Teamet planlægger følgende kobling:
System | Reference og fakta | Forventet status |
|---|---|---|
Webshop |
| Den anden vase bliver hos kunden; den oprindelige leverede mængde skal kunne spores. |
ERP |
| Tilgang til salgbar beholdning: 0 styk. |
Betalingsudbyder |
| Anmodet og bekræftet gennemført er separate statusser. |
Koblingen bruger linje- og transaktionsreferencer. Samme produktnavn eller varenummer er ikke nok, når samme vare findes i flere ordrer.
Fastlæg en intern integrationsmodel
Følgende datapost er et eget design til dette fiktive forløb, ikke et API-kald til en udbyder. Mængderne gælder returen; beløbet er angivet i EUR-cent.
{
"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"
}
}Referencerne forbinder webshoppens ordrelinje, dens leveringslinje og den oprindelige ERP-leveringslinje med betalingen. Gem også udbyderens tilbagebetalingsreference på sagen. Hvis linjen ikke kan kobles entydigt, skal posten afvente afklaring i stedet for at blive bogført automatisk gennem navnesammenligning.
Brug den rigtige kilde til hver ændring
I eksemplet leverer webshoppen relationen til den købte linje. ERP bekræfter modtagelse, kontrolresultat og frigivelse af beholdning. Betalingsudbyderen leverer tilbagebetalingsstatus. Ansvarsfordelingen står i datakontrakten; en anden systemfordeling kan kræve andre tildelinger.
Shopifys ReturnLineItem peger på en Shopify-leveringslinje; integrationen skal oprette forbindelsen til ERP-linjen. Refund-dokumentationen påpeger udtrykkeligt, at en datapost alene ikke bekræfter en gennemført pengebevægelse. Stripe beskriver også separate hændelser for oprettelse, ændring og fejl. Integrationen skal koble den valgte udbyders faktiske statusser til sin interne model.
En gennemført tilbagebetaling må derfor kun ændre betalingsstatus i eksemplet. Den gør ikke den beskadigede vase salgbar. Varemodtagelse gør heller ikke automatisk tilbagebetalingen gennemført.
Kontrollér det forventede resultat
Kontrollér forløbet i et egnet testmiljø: delreturen tilhører den rigtige linje, lagerændringen bliver ved 0, og 2400 cent tilhører den rigtige betaling. Når tilbagebetalingen er bekræftet gennemført, skifter dens status, mens varen forbliver spærret. Et uklart betalingssvar skal være synligt som uafklaret. En gentaget statusbesked skal opdatere samme sag. Teknisk behandling af gentagne forsøg kræver også en passende idempotensstrategi.
Kilder
Læs videre
Alle artikler






E-handel med ASES
Webshops, markedspladser og B2B-portaler


