Gå til indholdet

Kobl returdata mellem webshop, ERP og betalingssystem

En gennemarbejdet datakontrakt forbinder ordrelinje, ERP-varemodtagelse og tilbagebetaling. Separate statusser forebygger forkerte lager- og betalingsvisninger.

Lena Fischer2 min. læsetid
Lukket kasse med rød returpil, rød tape og et stregkodemærke.

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

OL-86-A: 2 leveret, 1 returneret.

Den anden vase bliver hos kunden; den oprindelige leverede mængde skal kunne spores.

ERP

DL-86-A: 1 modtaget, skade bekræftet ved kontrol.

Tilgang til salgbar beholdning: 0 styk.

Betalingsudbyder

PAY-86: aftalt tilbagebetalingsbeløb.

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

Skrevet af

  • Lena FischerRedaktør for e-handelLena Fischer står for ASES' artikler om e-handel. Hun skriver om webshopsystemer og deres integration med andre applikationer og forklarer de tekniske processer bag onlinehandel.

Følg ASES

Læs videre

Alle artikler

E-handel med ASES

Webshops, markedspladser og B2B-portaler