Refund workflow u web shopu treba posmatrati kao kontrolisani tok podataka, a ne kao jednu akciju u administratorskom panelu. Porudžbina može biti poslata u celini, vraćen samo jedan artikal, odobren povraćaj bez prijema robe ili neuspešno izvršen povraćaj novca. Ako se sve te situacije svode na jedan status, sistem brzo postaje nejasan i sklon greškama.
Praktičan model razdvaja najmanje četiri stvari: status porudžbine, status isporuke, status zahteva za povraćaj i status refundacije. Tako korisnička podrška može da vidi šta se dešava sa robom, magacin zna šta treba da primi, a finansije imaju precizan zapis o tome da li je novac zaista vraćen. Ovaj nivo modelovanja je deo šire odluke o arhitekturi kada se planira izrada web shopa.
Zašto jedan status porudžbine nije dovoljan
Statusi poput „u obradi“, „poslato“ i „završeno“ korisni su za osnovni prikaz, ali ne opisuju dovoljno dobro povraćaje. Na primer, porudžbina može istovremeno biti:
- plaćena i delimično isporučena,
- u procesu povraćaja za jedan od tri artikla,
- sa refundacijom koja čeka potvrdu payment provajdera,
- zatvorena za prodaju, ali i dalje otvorena za računovodstvenu obradu.
Zato je korisno razlikovati poslovno stanje od tehničkog događaja. „Kupac je poslao zahtev za povraćaj“ nije isto što i „refundacija je uspešno izvršena“. Prvo je događaj koji pokreće workflow, a drugo je potvrđeni rezultat finansijske operacije.
Minimalni model podataka za refund workflow
Pre definisanja statusa, treba odlučiti koji objekti postoje u sistemu. U jednostavnijem web shopu mogu biti dovoljni sledeći entiteti:
| Entitet | Šta opisuje | Primer podataka |
|---|---|---|
| Porudžbina | Celinu kupovine | broj, kupac, valuta, ukupna vrednost |
| Stavka porudžbine | Pojedinačni proizvod ili količinu | SKU, količina, cena, popust |
| Isporuka | Šta je fizički poslato | paket, tracking broj, datum slanja |
| Zahtev za povraćaj | Razlog i obim povraćaja | stavke, količina, razlog, prilozi |
| Prijem povrata | Šta je stvarno vraćeno u magacin | primljena količina, stanje proizvoda |
| Refundacija | Finansijsku transakciju povraćaja | iznos, valuta, payment ID, status |
Ovaj model omogućava da se jedan zahtev odnosi na deo porudžbine i da jedna porudžbina ima više finansijskih operacija. Važno je sačuvati vezu između refundacije i originalne naplate, umesto da se samo umanji ukupna vrednost u tabeli porudžbine.
Kako organizovati statuse bez previše izuzetaka
1. Status porudžbine
Status porudžbine treba da opisuje njen životni ciklus u prodaji. Tipičan niz može biti:
- kreirana, ali nije plaćena,
- plaćanje potvrđeno,
- u pripremi,
- delimično poslata ili poslata,
- isporučena,
- otkazana,
- zatvorena.
Nije neophodno da svaka implementacija koristi baš ove nazive. Bitno je da svaki status ima jednu jasnu definiciju i dozvoljene prelaze. „Završena“ ne bi trebalo automatski da znači i „novac je vraćen“, jer refundacija može nastupiti nakon isporuke.
2. Status zahteva za povraćaj
Zahtev za povraćaj predstavlja poslovni proces i može imati zaseban tok:
- započet – kupac je otvorio zahtev, ali ga još nije poslao;
- podnet – zahtev je kompletiran i čeka proveru;
- odobren – povraćaj je prihvaćen prema pravilima prodavca;
- odbijen – zahtev nije prihvaćen, uz zabeležen razlog;
- čeka prijem – kupac treba da pošalje robu ili je roba u transportu;
- primljen – magacin je evidentirao povrat;
- zatvoren – sve povezane radnje su završene.
„Odobren“ i „primljen“ treba da ostanu odvojeni. U suprotnom, sistem može da pokrene refundaciju pre nego što je roba proverena, iako poslovna pravila zahtevaju kontrolu artikla.
3. Status refundacije
Refundacija treba da ima svoj tehnički status, na primer:
- nije pokrenuta,
- zahtev poslat payment provajderu,
- u obradi,
- uspešna,
- neuspešna,
- poništena ili ručno rešena.
Payment provajderi obično imaju sopstveni identifikator refundacije i sopstveni životni ciklus. Na primer, API poziv može biti prihvaćen, ali konačni status stići naknadno kroz webhook. Zato aplikacija ne bi trebalo da označi refundaciju kao uspešnu samo zato što je zahtev poslat bez greške.
Primer refund workflow-a od zahteva do zatvaranja
Jedan kontrolisan tok može izgledati ovako:
- Kupac podnosi zahtev. Sistem proverava da li porudžbina postoji, da li pripada korisniku i koje stavke i količine mogu biti predmet zahteva.
- Sistem izračunava očekivani iznos. U obzir se uzimaju cena stavke, proporcionalni popust, dostava i eventualni drugi troškovi prema poslovnim pravilima.
- Operater odobrava ili odbija zahtev. Odluka dobija razlog, autora i vreme izmene.
- Generiše se instrukcija za povraćaj. Kupac dobija informacije o pakovanju, adresi ili načinu predaje, ako je to primenljivo.
- Magacin evidentira prijem. Količina koja je stvarno vraćena može se razlikovati od prvobitno odobrene količine.
- Pokreće se refundacija. Sistem šalje precizan iznos payment provajderu i čuva njegov referentni ID.
- Čeka se potvrda. Webhook, periodična provera ili ručna kontrola ažuriraju status refundacije.
- Workflow se zatvara. Kupac dobija obaveštenje, finansijski zapis je kompletan, a stanje zaliha se ažurira prema nalazu magacina.
U nekim modelima refundacija može biti pokrenuta odmah nakon odobrenja, bez čekanja fizičkog prijema. To je poslovna odluka koja smanjuje trenje za kupca, ali povećava rizik ako roba ne stigne ili nije u očekivanom stanju. Sistem treba da podrži izabrano pravilo, a ne da ga slučajno nametne tehničkim redosledom.
Delimični povraćaj i više refundacija
Najviše problema nastaje kada porudžbina sadrži više artikala ili količina istog artikla. Zbog toga refundaciju treba vezati za konkretne stavke i količine, ne samo za broj porudžbine.
Primer: kupac je naručio tri proizvoda, ali vraća jedan. Porudžbina ostaje isporučena, dok jedna stavka dobija status „u povraćaju“. Ako se kasnije vraća još jedan proizvod, sistem treba da kreira novi zahtev ili novu stavku postojećeg zahteva, u skladu sa pravilima. U oba slučaja mora postojati zaštita od toga da zbir refundacija pređe iznos koji je stvarno naplaćen za tu stavku.
Posebno treba definisati kako se obračunavaju:
- proporcionalni popusti na paket ili korpu,
- trošak dostave kod delimičnog povraćaja,
- poklon proizvodi i promotivni kodovi,
- različite valute i zaokruživanja,
- naknadne izmene cene ili ručne korekcije.
Pravila ne treba skrivati u neproverljivim ručnim kalkulacijama. Prikažite operateru kako je sistem došao do iznosa i omogućite obaveznu napomenu za svaku ručnu korekciju.
Greške koje treba sprečiti u implementaciji
Duplo pokretanje refundacije
Dugme za refundaciju treba da bude zaštićeno od dvostrukog klika, ponovljenog zahteva ili ponovljene obrade webhook-a. Korisni su idempotency ključ, jedinstvena interna referenca i provera prethodno uspešno refundiranog iznosa.
Mešanje statusa sa slobodnim tekstom
Napomena operatera može objasniti situaciju, ali ne treba da bude jedini dokaz da je refundacija urađena. Status, iznos, korisnik koji je izvršio akciju, vreme i payment referenca treba da budu strukturirani podaci.
Nedovoljna istorija promena
Audit trail treba da pokaže ko je promenio status, sa koje vrednosti na koju, kada i zbog čega. To je korisno za podršku, interne kontrole i rešavanje sporova. Istorija ne mora da bude vidljiva kupcu u celosti, ali mora biti dostupna ovlašćenim korisnicima.
Neusaglašeni sistemi
Web shop, payment provajder, magacin, računovodstvo i email obaveštenja mogu imati različite statuse. Definišite koji sistem je izvor istine za koju informaciju. Payment provajder potvrđuje finansijski ishod, dok web shop vodi poslovni zahtev, a magacin potvrđuje fizički prijem robe.
Korisnički interfejs: šta treba da vidi kupac, a šta operater
Kupcu je potreban jednostavan pregled: koja porudžbina je u pitanju, koje stavke se vraćaju, šta je sledeći korak i da li je refundacija pokrenuta ili završena. Interni kodovi payment provajdera i detalji webhook-a nisu korisni u korisničkom interfejsu.
Operateru je potreban detaljniji prikaz:
- originalno naplaćenog i preostalog iznosa,
- zahteva i odobrenih količina,
- statusa prijema robe,
- istorije promena,
- payment ID-ja i greške ako je refundacija neuspešna,
- veze sa skladištem, računovodstvom i komunikacijom prema kupcu.
Za složenije kataloge, više valuta ili različita tržišta, refund workflow treba uskladiti sa načinom prikaza valuta, poreza i lokalnih pravila. U tom slučaju korisno je povezati ga sa vodičem o multi-currency i lokalizaciji web shopa za više tržišta.
Kako testirati workflow pre puštanja
Testiranje ne treba ograničiti na uspešnu kupovinu. Napravite matricu scenarija koja pokriva makar sledeće slučajeve:
- otkazivanje pre slanja i nakon slanja,
- potpuni povraćaj jedne porudžbine,
- delimični povraćaj više stavki,
- povrat manje količine od odobrene,
- neuspešan poziv payment provajderu,
- ponovljeni webhook ili prekid veze tokom obrade,
- refundacija u drugoj valuti, ako je podržana,
- ručna refundacija van standardnog toka,
- povrat robe koja nije u stanju za ponovnu prodaju.
Za svaki scenario zapišite očekivane statuse na nivou porudžbine, stavke, povrata i refundacije. Ako rezultat zavisi od ručnog dogovora, to je signal da pravilo treba precizirati pre razvoja.
Veza sa ostatkom ecommerce arhitekture
Refund workflow ne treba projektovati izolovano. Promene payment provajdera, migracija kataloga, guest checkout i faceted navigacija mogu uticati na identitet kupca, istoriju porudžbina i način na koji se stavke pronalaze.
Ako se menja platforma, posebnu pažnju posvetite očuvanju ID-ja porudžbine, stavki, refundacija i audit zapisa. Širi plan je opisan u tekstu o migraciji web shopa i prenosu kataloga, kupaca i porudžbina. Kod kupovine bez naloga proverite kako će kupac dokazati vezu sa porudžbinom i kako će dobiti status povrata; relevantan je i vodič o guest checkout-u i tehničkom rešavanju kupovine bez registracije.
Ako je potreban širi redizajn informacione arhitekture i korisničkih tokova, može biti korisno sagledati i izrada sajta kao deo ukupnog digitalnog sistema, ali refund workflow ostaje specifičan ecommerce proces sa sopstvenim pravilima.
Praktična odluka pre razvoja
Pre nego što se statusi implementiraju, napišite jednu tabelu sa četiri kolone: događaj, prethodni status, novi status i dozvoljena akcija. Dodajte vlasnika odluke i podatke koji moraju biti sačuvani. Na primer, događaj „payment provajder potvrđuje refundaciju“ može promeniti refundaciju u „uspešna“, poslati obaveštenje kupcu i kreirati računovodstveni zapis, ali ne mora promeniti celu porudžbinu u „vraćena“ ako su vraćene samo pojedinačne stavke.
Dobro modelovan sistem ne pokušava da sakrije složenost. On je razdvaja na razumljive objekte, ograničava dozvoljene prelaze i ostavlja trag svake važne odluke. Sledeći korak je da pravila povraćaja, payment integraciju, skladište i korisničku podršku prođete kao jedan proces, pre nego što se izabere konačan set statusa i ekrana.
