Amazon-returvarer og refunds i Business Central: Når salget går den anden vej
Integrationer bliver ofte designet omkring den glade sti:
Ordre → lager → levering → betaling.
Men e-commerce stopper ikke ved leveringen.
Nogle varer kommer retur. Nogle kunder får refunds. Nogle varer kan sælges igen. Andre kan ikke.
Derfor bør Amazon-returvarer og refunds i Business Central være en del af integrationsdesignet fra starten.
Amazons Reports API kan blandt andet bruges til rapportdata om returns, lager og ordrer, mens Amazon også har separate processer for seller-fulfilled returns. Amazon Developer Docs
Returneret og refunderet er ikke det samme
Det er vigtigt at skelne mellem to hændelser.
Refund: Den økonomiske hændelse.
Return: Den fysiske varebevægelse.
De kan hænge sammen, men de bør ikke behandles som den samme datatype.
En kunde kan eksempelvis få en refund, før den fysiske vare er modtaget.
Derfor bør økonomi og lager ikke blindt opdateres efter samme event.
Ved FBA håndterer Amazon meget af den fysiske proces
Ved FBA overtager Amazon en stor del af fulfillment- og returhåndteringen.
Det betyder ikke, at virksomheden kan ignorere returdata.
Business Central kan stadig have behov for at vide:
- hvilken oprindelig ordre returneringen vedrører
- hvilken SKU der er involveret
- hvilket beløb der er refunderet
- hvordan lagerstatus påvirkes
- om varen igen kan indgå i beholdningen
- hvordan den finansielle hændelse skal håndteres
Læs mere om [Amazon FBA integration til Business Central](/amazon-fba-integration-business-central/).
Ved FBM bliver virksomhedens eget lager en del af processen
Ved FBM modtager virksomheden eller dens 3PL ofte varen fysisk.
Så opstår der et nyt spørgsmål:
Hvad er varens tilstand?
En returneret vare kan være:
- salgbar
- beskadiget
- mangelfuld
- til inspektion
- til kassation
Det er ikke nødvendigvis korrekt straks at lægge den tilbage i disponibelt lager.
Læs også [Amazon FBM integration til Business Central](/amazon-fbm-integration-business-central/).
Returårsager er værdifulde data
Hvis en bestemt SKU har markant flere returneringer end andre, er det ikke kun et kundeserviceproblem.
Det kan pege på:
- produktkvalitet
- forkert produktbeskrivelse
- størrelsesproblemer
- emballage
- transportskader
Når returdata bliver struktureret og koblet til produkt- og salgsdata, kan virksomheden bruge dem aktivt.
Returflowet bør defineres
Et eksempel på et FBM-flow:
Amazon return request → Business Central → lager/3PL → fysisk kontrol → lagerstatus → refund/kredit → rapportering
Et FBA-flow kan have en anden fysisk proces, men Business Central har stadig brug for de relevante ERP- og økonomidata.
Undgå at bygge returns som en eftertanke
Det er meget nemmere at designe returhåndtering sammen med ordreflowet end at tilføje den efterfølgende.
Fra starten bør I definere:
Hvilken nøgle forbinder returneringen med den oprindelige ordre?
Hvornår ændres lagerstatus?
Hvornår sker økonomisk postering?
Hvordan håndteres delvise refunds?
Hvordan håndteres varer, der ikke kan sælges igen?
Det vigtigste at tage med
Et godt Amazon-flow går ikke kun fra Business Central til kunden.
Det skal også kunne håndtere data, der bevæger sig tilbage.
Når returns og refunds er en integreret del af systemarkitekturen, slipper lager, kundeservice og økonomi for hver især at opfinde deres egen manuelle proces.