Evidencija reklamiranih isporuka treba voditi svaku prijavu od konkretne stavke isporuke do potvrđenog ishoda. Minimalni zapis povezuje stavku, razlog, priloge, vlasnika postupanja i dogovoreni ishod. Predmet se ne završava samom odlukom: završetak traži dokaz rješenja reklamacije. Financijski dokument, ako je potreban, nastaje u službenom sustavu prema dodijeljenoj ovlasti.
Reklamacija često počinje izvan ERP-a: porukom kupca, pozivom skladištu, fotografijom oštećenja ili internom nalazom. Bez zajedničkog zapisa lako se izgubi veza između prijave, stvarne isporuke, dogovora s kupcem i naknadne financijske radnje.
Mini evidencija ne mora zamijeniti ERP. Njezina je uloga zadržati operativni kontekst reklamacije na jednom mjestu i jasno pokazati tko treba napraviti sljedeći korak.
Dobar minimalni proces odgovara na pet pitanja:
Takav zapis nije isto što i odobrenje knjiženja, odobrenje povrata ili izdavanje dokumenta. Te radnje pripadaju službenom sustavu i korisniku s odgovarajućom ovlasti.
Za svaki predmet korisno je otvoriti jedinstveni identifikator i vezati ga uz isporuku. Ako isporuka ima više redaka, potrebno je evidentirati i konkretnu stavku, količinu ili drugi raspoloživi identifikator stavke. Sam broj otpremnice bez stavke može ostaviti nejasnoću kad reklamacija obuhvaća samo dio isporuke.
Preporučeni ulazi uključuju:
Kontrolirani popis razloga može olakšati kasniji pregled, ali ne bi smio sakriti važan opis slučaja. Primjerice, oznaka "oštećenje" sama po sebi ne govori je li šteta vidljiva pri primitku, utvrđena tijekom uporabe ili dokumentirana naknadno. Slobodni opis i prilog često nose bitan kontekst.
Vlasnik unosa, primjerice služba za korisnike ili osoba koja prima prijavu, otvara predmet i povezuje ga s isporukom i stavkom. Ako veza nije dostupna, predmet može dobiti status iznimke "čeka identifikaciju isporuke". Takav status sprječava privid da je predmet spreman za odluku.
Vlasnik obrade provjerava jesu li razlog, opis, traženi prilog i veza s isporukom dovoljni za procjenu. Nedostajući dokaz nije nužno razlog za odbijanje reklamacije, ali mora biti vidljiv kao otvoreno pitanje. Potpunost ulaza i opravdanost reklamacije dvije su odvojene odluke.
Operativni vlasnik prikuplja nalaz relevantne funkcije, primjerice skladišta, kvalitete, prodaje ili proizvodnje. Ovlaštena osoba ili uloga zatim evidentira odluku. Uloga koja unosi nalaz ne mora biti ista kao uloga koja odobrava ishod.
Korisno je razlikovati barem sljedeće ishode:
Dogovoreni ishod treba biti operativno razumljiv. Umjesto općenite oznake "riješeno", zapis može navesti primjerice zamjensku isporuku, povrat robe, korekciju usluge, odbijanje s obrazloženjem ili drugi dogovoreni postupak.
Hipotetski scenarij: kupac prijavi oštećenje jedne stavke s otpremnice i priloži fotografiju. Vlasnik predmeta povezuje prijavu s tom stavkom, skladište unosi nalaz, ovlaštena uloga odobrava zamjensku isporuku, a predmet ostaje otvoren dok odgovorna osoba ne potvrdi izvršenje dogovorenog postupka. Ako ishod zahtijeva financijski dokument, referenca na dokument upisuje se nakon njegove izrade u službenom sustavu.
Odluka nije dokaz izvršenja. Predmet je spreman za zatvaranje tek nakon potvrde da je dogovoreno postupanje provedeno ili da je evidentirano zašto se ne provodi. Potvrda može sadržavati izvršitelja, datum, kratku napomenu i vezu na relevantnu službenu evidenciju.
Ovdje nastaje dokaz rješenja reklamacije: sljediv niz od prijave i priloga, preko odluke, do potvrđenog postupanja. Dokaz ne mora biti jedan dokument, ali mora omogućiti provjeru slijeda bez oslanjanja na usmeno sjećanje.
Mini aplikacija može raditi samostalno, bez ERP-a ili Orkaste. To je prijedlog procesa, a ne najava gotovog proizvoda. Ipak, granice sustava treba odrediti prije implementacije.
Operativna evidencija može voditi prijavu, komunikacijski kontekst, priloge, odgovornosti i status. ERP ostaje mjesto službenih transakcija, poput financijskog dokumenta, ako ga ovlašteni korisnik treba izraditi. Evidencija može pohraniti referencu na taj dokument, ali ne bi trebala prikazivati nastanak dokumenta kao automatsku posljedicu same reklamacije bez definiranog odobrenja i ovlasti.
U ORKA pristupu Orkasta može nositi svakodnevnu suradnju, ERP službene transakcije, a Trueforce specijalizirani inženjerski rad. Raspodjela je smislenija od preklapanja odgovornosti: treba unaprijed odrediti koji sustav drži koji podatak, tko ga mijenja i što je službeni trag za pojedinu radnju.
Podatkovna ograničenja mogu pomoći pri osnovnoj kvaliteti zapisa. Primjerice, mogu provjeravati jedinstvenost identifikatora, obvezna polja i veze među zapisima. Dokumentacija za PostgreSQL Constraints opisuje takve kategorije ograničenja.
No ograničenje podataka ne zamjenjuje poslovno pravilo. Pravilo poput "za oštećenje je potrebna fotografija" ili "određeni ishod zahtijeva dodatno odobrenje" treba definirati zasebno: tko odlučuje, kada pravilo vrijedi, postoje li iznimke i gdje se iznimka obrazlaže.
Važno je i izbjeći previše krut obrazac. Obvezan prilog može zaustaviti legitimnu prijavu bez fotografije. S druge strane, potpuno slobodan unos otežava radni red i naknadnu provjeru. Praktičan kompromis je vidljivo označiti nedostajući ulaz, dodijeliti vlasnika dopune i propisati tko smije prihvatiti iznimku.
Prije izrade obrasca ili integracije dogovorite sljedeće.
Ulazi i njihovi vlasnici
Odluke koje treba zapisati
Iznimke koje ne smiju ostati skrivene
Proces je prihvaćen za rad kada se za svaki zatvoreni predmet može provjeriti veza s isporukom ili evidentirana iznimka, razlog, raspoloživi prilozi, vlasnik obrade, ovlaštena odluka, dogovoreni ishod i potvrda postupanja. Ako je nastao financijski dokument, treba biti dostupna njegova službena referenca. Ovaj kriterij je provjerljiv bez pretpostavljanja početne ili ciljne vrijednosti.
Ako postoje nejasnoće oko vlasništva podataka, granice ERP-a i operativne evidencije ili pravila iznimaka, Screening poslovnog procesa može poslužiti kao strukturiran sljedeći korak prije izrade rješenja.