Kupčev zahtjev za povrat nije dokaz primitka robe niti automatska osnova za financijsko zatvaranje. Operativna obrada webshop povrata treba povezati četiri odvojena koraka: evidentiranje zahtjeva, fizički primitak, kontrolu vraćene robe i odluku o povratu sredstava. Financijska transakcija slijedi tek nakon evidentiranog primitka i odluke ovlaštene osobe prema unaprijed definiranim pravilima poslovanja.
Ovakvo razdvajanje smanjuje rizik zatvaranja povrata prije nego što skladište potvrdi što je stvarno stiglo, u kojem stanju i u kojoj količini. Istodobno financije dobivaju jasan signal za rad, umjesto zaključivanja na temelju poruke kupca, najave dostave ili statusa prijevoznika.
Webshop može zaprimiti zahtjev kupca prije slanja paketa, tijekom prijevoza ili nakon što roba stigne u skladište. Svaki od tih trenutaka nosi različitu poslovnu informaciju.
Ako sustav preskoči razliku između tih koraka, isti status može prikrivati više različitih stanja. Primjerice, oznaka "povrat u tijeku" ne govori je li kupac samo otvorio zahtjev, je li paket stigao ili je roba pregledana. Takav status otežava skladištu planiranje rada, financijama kontrolu obveza i korisničkoj službi preciznu komunikaciju.
Proces ne mora biti složen, ali svaka prijelazna točka treba imati vlasnika, ulaz i vidljiv zapis.
Korisnička služba, webshop ili integracija otvara zapis povrata i povezuje ga s izvornom narudžbom. Vlasnik ulaza je kanal koji je zaprimio zahtjev, uz odgovornost poslovne uloge za provjeru osnovnih podataka.
Minimalni ulazi mogu uključivati:
U ovoj fazi zapis dobiva status zahtjeva. Ne treba ga tretirati kao potvrđen primitak niti kao nalog financijama za povrat sredstava.
Ako proces koristi povratnu naljepnicu, prijevoznika ili drugi način povratne dostave, zapis može sadržavati očekivani paket. Vlasnik dopune podataka može biti webshop integracija, korisnička služba ili logistika, ovisno o organizaciji.
Najava služi operativnom planiranju. Ona nije zamjena za skeniranje, prebrojavanje ili identifikaciju robe pri primitku.
Skladište evidentira datum i vrijeme primitka, lokaciju, identifikator paketa kada je dostupan te osobu ili radnu ulogu koja je zaprimila robu. Ako paket nije moguće povezati s postojećim zahtjevom, skladište treba otvoriti iznimku, a ne zatvoriti povrat pretpostavkom.
Fizički primitak odgovara na ograničeno, ali važno pitanje: je li paket ili roba stigla pod kontrolu organizacije? Ne odgovara još na pitanje ispunjava li roba uvjete internog postupanja.
Kontrola vraćene robe uspoređuje stvarno primljeno s očekivanim zapisom. Vlasnik ove aktivnosti obično je skladište, kvaliteta ili druga imenovana operativna uloga.
Kontrola može obuhvatiti:
Rezultat kontrole treba ostati odvojen od financijske odluke. Operativni tim utvrđuje činjenice o primitku i stanju. Ovlaštena poslovna uloga primjenjuje poslovna pravila na te činjenice.
Odluka može biti odobrenje povrata sredstava, djelomični povrat, zamjena, daljnja provjera ili odbijanje prema internim pravilima. Vlasnik odluke mora biti imenovana uloga, primjerice financije, korisnička služba, voditelj procesa ili kombinacija uloga kroz odobravanje.
Pravila za odluku treba dokumentirati zasebno. Ne treba ih prikazivati kao zakonske uvjete bez nove provjere službenog izvora. Organizacija treba provjeriti koje uvjete, rokove i komunikaciju primjenjuje na svoje tržište, proizvode i prodajne kanale.
Financije provode službenu ERP transakciju nakon vidljivog zapisa o primitku, rezultata kontrole i odluke. Vlasnik financijskog knjiženja je financijska funkcija ili ovlaštena ERP uloga.
Sustav treba zadržati vezu između izvornog dokumenta, zahtjeva za povrat, zapisa o primitku, rezultata kontrole, odluke i financijske transakcije. Ta veza olakšava provjeru pojedinačnog slučaja bez ručnog prikupljanja podataka iz e-pošte, webshopa i skladišnih bilješki.
Slijedi hipotetski scenarij, ne opis stvarnog klijenta ni stvarne isporuke ORKA.
Kupac otvara zahtjev za povrat za dvije jedinice artikla. Webshop zapis povezuje s narudžbom, ali skladište pri primitku nalazi jednu jedinicu. Skladištar evidentira stvarnu količinu, dodaje status kontrole i otvara iznimku za nepodudarnost količine. Financije ne zatvaraju povrat na temelju izvornog zahtjeva za dvije jedinice. Ovlaštena osoba pregledava zapis, primjenjuje interna pravila i unosi odluku. Tek tada financije provode odgovarajuću ERP transakciju.
Vrijednost ovog obrasca nije u broju statusa, nego u jasnoj odgovornosti. Nitko ne mora nagađati je li druga jedinica zaprimljena, izgubljena u procesu ili predmet dodatne provjere.
Ograničenja u bazi podataka pomažu zaštititi osnovnu kvalitetu zapisa. Primjerice, mogu provjeravati jedinstvenost identifikatora, obvezna polja i veze među zapisima. PostgreSQL dokumentacija opisuje ograničenja poput jedinstvenosti, obveznih vrijednosti i stranih ključeva u poglavlju Constraints .
Ta ograničenja korisna su za sprječavanje očitih pogrešaka, poput zapisa povrata bez povezane narudžbe kada proces takvu vezu zahtijeva. Ipak, ne određuju sama poslovnu odluku. Baza ne može sama zaključiti je li stanje proizvoda prihvatljivo, tko smije odobriti iznimku ili koji financijski ishod slijedi nakon pregleda.
Poslovna pravila treba definirati zasebno, zajedno s vlasnikom procesa. Pravilo može propisati obvezan pregled za određenu vrstu artikla, drugo odobrenje za odstupanje količine ili posebnu obradu robe koja ne može natrag u prodaju. Tek nakon definicije pravila treba odlučiti hoće li se ono provoditi radnim uputama, ERP konfiguracijom, integracijom, izvještajem ili kombinacijom tih elemenata.
Dobro osmišljen proces ne pretpostavlja potpunu podudarnost u svakom slučaju. Treba predvidjeti barem sljedeće iznimke:
Za svaku iznimku odredite vlasnika, rok za internu obradu prema vlastitim pravilima, dopuštene odluke i način evidentiranja. Nejasna iznimka često stvara više ručnog rada od samog redovnog povrata.
Prije promjene workflowa, konfiguracije ili integracije provjerite sljedeće.
Proces je prihvatljiv za rad kada svaki obrađeni povrat ima jedinstvenu referencu, vezu s izvornom narudžbom ili evidentiranu iznimku, zapis fizičkog primitka, rezultat kontrole ili otvorenu iznimku, imenovanog vlasnika odluke te vezu s financijskom transakcijom nakon provedene odluke. Provjerljiva mjera je udio pregledanih zapisa u odabranom razdoblju koji sadrže sve obvezne tragove ili dokumentiranu iznimku. Organizacija može pratiti i broj slučajeva u kojima je financijska transakcija otvorena prije potvrde primitka.
Ako postojeći proces miješa statuse ili odgovornosti, početna korisna aktivnost nije automatski nova integracija. Najprije mapirajte stvarni tok rada, vlasnike i iznimke kroz Screening poslovnog procesa . U ORKA pristupu Orkasta preuzima svakodnevnu suradnju i službene ERP transakcije, dok Trueforce donosi specijaliziranu inženjersku ponudu kada proces zahtijeva tehničku izvedbu. Sljedeći korak je odabrati jedan tok povrata, provjeriti njegove zapise od zahtjeva do knjiženja i ukloniti prijelaze bez jasnog vlasnika.