Papiri koji prate ulaz robe
Nakon što sam sam u prethodnom članku podelio svoja iskustva iz prošlosti u vezi proizvodnje računara, da pređemo na sledeću temu: “ulaz robe”. Uobičajene ograde su kao i uvek na snazi: sve što ovde opisujem je na bazi mog ličnog iskustva za koje ne tvrdim da je sveobuhvatno i tačno, već samo da je iskreno podeljeno sa vama. I danas se koristim primerom malog servisa računara u kome sam radio nekada davno, ali je tematika verujem univerzalno primenljiva i na druge slične primere neovisno čime se firma bavi i trguje.
Kritike i sugestije kao i uvek jako cenjene i dobrodošle.
Nabavna lista
Kontrolisanjem stanja na lageru (biće članak samo o tome) ustanovi se da određeni broj artikala nedostaje ili ga ima u količini koja ne garantuje nesmetani rad prodavnice računara te se isti moraju nadomestiti nabavkom od distributera. Sa stanovišta lagera ta lista za nabavku je jedinstvena, ali s obzirom da se kod jednog distributera ima dobra valuta za Samsung monitore, kod drugog cena je dobra za “Asus ploče”, onda se ta lagerska nabavna lista razbije na više zasebnih nabavnih lista gde svaka od njih sadrži listu artikala za nabavku od određenog prodavca/distributera.
Nabavna lista sadrži količine i okvirne nabavne cene. Nabavne cene se upisuju ili na bazi informacija sa B2B portala prodavaca ili se uzima zadnja nabavna cena od datog dobavljača. Suštinski je nabavna lista u mom svetu forma izveštaja magacinskog stanja uz dodatne ad hoc modifikacije koje reflektuju trenutne tržišne okolnosti.
Prijemnica
Što bi rekao Ujak Albert iz Mućki “negde s kraja 90-tih” robu distributeri nisu razvozili nego se išlo po nju. Obično po robu ujutru kreće vlasnik servisa računara, provede ceo dan po Beogradu obilazeći 73 različita distributera da prikupi sve sto je na listi za nabavku i “10 minuta pre kraja radnog vremena” se vrati nazad u servis. Usled tog limitiranog vremena roba se samo istovaruje iz vozila i popisuje količinski da se proveri da je sve naručeno po planu, a cene – “ujutru”. Znači roba se iznosi i slaže u prijemnom odeljenju (u mom slučaju to je bilo “desno iza vrata da se ne vidi sa ulice”) i samo se brzinski štikliraju stavke sa nabavnih lista.
Danas se naravno ne ide po robu nego je dovoze, ali je problem isti jer po Marfijevom zakonu “broj mušterija u servisu doživljava maksimum u momenat kada roba stigne” pa je potrebno brzo prekontrolisati okvirno i količinski robu koju distributer isporučuje.
Prijemnica robe ne iskazuje nikakve informacije o ceni iz dva razloga: a) nema potrebe za komplikovanjem života onog koji prima robu količinski, b) nema potrebe da svako zna nabavne cene po kojima se roba nabavlja.
Drugim rečima, na ekranu stoji ime artikla, bar kod i količina koja se očekuje – to je sve.
Sasvim je očigledno da je ovo što ja zovem prijemnica robe u stvari otpremnica dobavljača, ali se ja ipak držim termina prijemnice u opisanom kontekstu iz sledećih razloga:
-
otpremnica dobavljača je samo analogni papirni dokument koji opisuje primljenu robu
-
otpremnica je često otpremnica/račun u kom slučaju može da sadrži podatke koji su poverljivi u poslovnom smislu
-
U mom internom svetu prijemnica se kreira na bazi nabavnih lista koje već imam u elektronskom formatu te njihova izrada ne oduzima dragoceno vreme.
Sve u svemu, prijemnica u kontekstu koji je ja koristim je više interni dokument preduzeća, koji možda može da se tretira i kao “polovično formirana kalkulacija” dok je otpremnica posebni dokument.
Kalkulacija
Ujutru vlasnik radnje dolazi na posao, uključuje računar i kreće sa drugom fazom prijema robe – formiranjem maloprodajnih cena.
Kod kreiranja kalkulacije odabira opciju da se učita prijemnica koju su prethodno verifikovali kod prijema magacioneri. Pošto on ima pristup celokupnom setu informacija, ažurira nabavne cene sa nabavne liste sa onima koje su mu iskazane na fakturi. U slučaju mog programa za servise računara gde postoji snažna integracija sa B2B portalima, količina rada potrebnog za ažuriranje nabavnih cena je minimalna.
Kada su tako sređene nabavne cene i količine na kalkulaciji, pristupa se određivanju prodajne cene. Program ponudi razumne opcije da uštedi vreme, a ipak je na kraju sve na korisniku da odluči tačno šta želi.
Osnovni princip kod unosa kalkulacije je da se za svaku stavku kalkulacije automatski ponudi “razumna maloprodajna cena” te da se konceptualno govoreći “unos cena” zameni “dorađivanjem ponuđenih cena”. To dorađivanje se naravno može odraditi ukucavanjem same cene ili procenta “marže” za svaku od stavki.
Prvi ulaz artikla
Ako je ovo prvi ulaz artikla u radnju, program uzima definisanu podrazumevanu maržu i dodaje je je na “nabavnu cenu” (detalji računice su nebitni za ovaj članak) i tako se dolazi do podrazumevane prodajne cene koju program upisuje u kolonu prodajna cena. Ova se cena boji nekom drečavom bojom da privuče pažnju korisnika jer se prvi put definiše i korisnik mora da je promeni i/ili potvrdi pritiskom “na enter”. Postavlja se pitanje ako već mora da se ukuca i/ili potvrdi, čemu onda nuditi cenu sa podrazumevanom maržom? Odgovor je prost: lakše je meni kao korisniku da zaokružim cenu koja uglavnom ide na “x%” nego da sam ručno računam za svaku novu stavku to isto digitronom.
prodajna cena = nabavna cena + podrazumevana marža
Ponovljeni ulaz – pristup sa fiksnom prodajnom cenom
Ako ovo nije prvi ulaz artikla, program pronađe poslednju maloprodajnu cenu dati artikl ima u firmi i upiše tu cenu u polje maloprodajna cena, a onda izračuna maržu na bazi razlike te prodajne i ostvarene nabavne cene. U slučaju da je artikl nabavljen po istoj nabavnoj ceni, prodajna cena i procenat marže ostaju isti i nikakve dodatne dekoracije prikaza podataka se u tom redu ne vrše. U slučaju da je roba nabavljena skuplje, marža će biti niža te se boji crvenom bojom da privuče korisniku pažnju da ako zadrži prodajnu cenu profit će biti manji za taj artikl. U slučaju da je artikl nabavljen jeftinije, procenat marže će biti viši, te se boji zelenom bojom. Ideja je da se takođe privuče pažnja korisnika, ali pošto je korisnik na dobitku, to informacija nije toliko bitna da zaslužuje drečavu boju.
podrazumevana marža = istorijska prodajna cena – nabavna cena
Ponovljeni ulaz – pristup sa fiksnom maržom
Druga moguća varijanta rezonovanja u slučaju ulaza robe za koju postoje prethodni prodajni podaci je da se iz zadnje kalkulacije očita profitna stopa i izračuna na bazi toga podrazumevana prodajna cena. Logika ovog pristupa se sastoji u tome da je korisnik već jednom odlučivao o marži koju želi da ostvari za zadati artikl pa ne treba mnogo filozofirati nego mu tu njegovu prethodnu odluku treba ponuditi kao podrazumevanu vrednost.
Cena koja se nudi ovako se obično zakružuje “na dole” ili “na gore” na 10x dinara,
podrazumevana prodajna cena = nabavna cena + istorijska marža
Ponovljeni ulaz – hibridno rešenje
Treća metoda određivanja podrazumevane prodajne cene sa kojom sam se ja sretao u prošlosti je pristup koji je kombinacija prethodna dva. Naime, programu se kaže da se drži prvog pristupa (fiksirane prodajne cene) sve dok usled porasta nabavne cene marža ne opadne relativno za x% u kom slučaju se prelazi na drugi obračun (fiksirana marža) i prodajna cena obračunava na bazi te marže bez obzira koliko je viša u odnosu na zadnju prodajnu cenu. Zahtev za ovako nečim korisnik formuliše na sledeći način
“Želim da zadržim staru cenu sve dok mi zarada
ne opadne za više od 10% po tom artiklu”
Primer hibridne logike
Evo primera kako bi to moglo da izgleda u stvarnosti – sledeća situacija
Juče sam prodao zadnji primerak procesora E8400 koji smo nabavio po ceni od 100 evra a prodao ga po ceni od 120 evra što (vulgarizovano za potrebe ovog posta) vodi ka procentu marže od 20% i recimo da se ja držim gore navedene logike o zadržavanju stare cene maksimalno do 10% umanjenja marže.
Sumirano:
-
nabavna cena 100 evra (NC)
-
prodajna cena: 120 evra (MPC)
-
zarada: 20 evra
-
% marže 20% ((MPC / NC) – 1)*100
Ako ukrstim ove podatke sa gore navedenu formulacijom moje poslovne logike dobijam ovo:
”Cena procesora ostaje 120 evra bez obzira na nabavnu cenu
sve dok je marža bar 18% sa tom prodajnom cenom”
Recimo prvo da prvo kupim novi E8400 procesor po ceni od 101.5 evra.
((120 /101.5) – 1)*100 = 18.2%
Marža od 18.2% je smanjena za 1.8% sa novom nabavnom cenom što je u okviru dozvoljenog smanjenja (10% od 20% je 2%) te podrazumevana cena ostaje 120
Recimo da onda kupim još jedan E8400 procesor, ali ovaj put po po ceni od 105 evra.
((120 /105) – 1) * 100 = 14.3%
Marža od 14.3% je smanjena za 5,6% sa novom nabavnom cenom što je u van okvira tolerancije od 2% tako da program mora da preračuna novu prodajnu cenu na bazi nove nabavne cene i minimalne tolerisane marže (18%) pa je tako nova podrazumevana prodajna cena 124 evra (105 * 1,18)
Naravno da ova logika može da se implementira na različite načine, ali je koncept nadam se jasan šta podrazumevam kad kažem “hibridno rešenje”.
Pauza
Pre nego što priča o papirima u preduzeću produži dalje i dublje želim da zastanem ovde i čujem koji su još dodatni atributi koji savršena kalkulacija u programu treba da ima jer je kalkulacija jedna od najvažnijih dokumenata u poslovanju preduzeća pa zaslužuje da se malo bolje zagleda.
Vaš red…
Kao i obično Vašim se tekstovima malo toga može dodati, a još manje oduzeti (ali ostaje ono pitanje „kad će izaći Papiri v0.1“).
Dali ste predvideli mogućnost da se kroz realizaciju ulazne kalkulacije omogući definisanje buduće podrazumevane marže uz artikal (promena stare) u odgovarajućem magacinu, a ne da se za to mora ići u neki drugi prozor programa. Ovde se odma nameće pitanje dali bi u nekim slučajevima trebalo opciono omogućiti da se ta marža primenjuje samo na dotični magacin, za koji se radi ulazna kalkulacija, na sve magacine (cenovnike) ili samo odabrane. Tu se sada pojavljuje i problem prava pristupa pojedinim opcijama, ali to je neko drugo pitanje.
Ovde bi unapred trebalo predvideti neke situacije koje mogu da komplikuju život u budućnosti ako se ne predvide na vreme. To je problem kada se primenjuje različita marža u različitim maloprodajnim objektima, ili organizacionim jedinicama (maloprodaja, servis, veleprodaja, repromaterijal-proizvodnja itd).
Druga stvar je kada se nešto kupuje kao set, a prodaje i maržira kao komad.
Bitno je i koji će podaci da stoje na prijemnici kako bi se prijem robe mogao obaviti na adekvatan naćin, kao što su naša šifra, šifra dobavljača, šifra proizvođača, bar kod, eventualni opis artikla, a možda i mogućnost da se doda slika kako bi se artikal mogao i vizuelno prepoznati. Ovo zadnje samo kao opcija, iako se u mnogim delatnostima i malim firmama i danas najviše primenjuje ta odokativna metoda.
Ovo su neke stvari koje su mi na blic pale na pamet, bez dubokog uživljavanja u problem.
Napoleon je rekao da nema tog plana koji može da izdrži prvi susret sa neprijateljem i bas to se i desilo mom planu da izbacim marta tu prvu javnu verziju, izgubio sam 2 meseca neplanirano na stvari van Papira, tako da sad radim svaki dostupan minut da sto pre to odradim. Znam da odgovor nije sjajan, ali to je šta je – neću da lažem 🙂
Ovo izlganje ideja za kalkulaciju je namerno ogoljeno i uprošćeno da ne komplikuje primere. Jedna od dimenzija iz stvarnosti koju sam namerno tako izostavio je to da predužeće može da ima više prodajnih objekata i zasebnu cenovnu politiku za svaki od njih – naravno da se slažem da je apsolutno neophodno celu priču omogućiti po potrebi da bude definisana „po objektu“.
Što se tiče potreba za odlsaskom u drugi deo programa, to je možda stvar broj jedan koju pokušavam da iskorenim svojim programom (stvar broj 2 je neophodnost rada mišem).
Na ovom primeru logika mog programa bi mogla možda da se opiše ovako:
„Ako imam artikl X u kalkulaciji sa cenom 90, a nova cena je 100, ne ćelim da da odem na ekran Y i nadjem artikl X pa da mu tamo promenim mu cenu/maržu na 100. Ono što želim je da je prekucam u kalkulaciji, a ti cenjena šklopocijo zvana računar ukapiraj sama na osnovu mojih podešavanja da li treba da promeniš maržu u svim objektima ili samo za objekt za koji unosim kalkulaciju“.
Drugim rečima, šta god računar može sam da odradi, treba sam i da odradi to, a da se korisnik fokusira na bitne stvari kao što je npr. odluka sa kojom maržom prodavati artill X.
Sto se tice atributa artikala bice svi navedeni naravno dostupni, sa tim da kada korisnik prvi put startuje program vidi minimalni set kolona, a onda po sopstvenoj zelji odabere iz liste kolona kolone koje zeli da doda prikazu kalkulacije. Razlog za ovo je sto je vecini malih firmica verujem bitan „samo bar kod i naziv“ tako da osnovno korisnicko iskustvo treba organizovati oko toga uz mogucnost podesavanja naorednih korisnika.
Hvala za (kao i uvek) izuzetno korisne sugestije!
Pozdrav za vas sajt, veoma je dobra ideja, narocito kada se ovako javno diskutuje na njemu.
Mene buni jedna stvar, a to je sledece. Iako nisam strucnjak za knjigovodstvo, znam ponesto, pa imam sledece pitanje.
Kada vam jedna firma posalje fakturu, da li postoji mogucnost da se podaci iz te fakture automatski prebace u program za izradu maloprodajnih ili veleprodajnih kalkulacija, gde bismo mi samo u kalkulaciji dodali maloprodajnu cenu, a svi ostali podaci bi se automatski preuzeli iz racuna dobavljaca, pa bi smo mi na taj nacin imali sve podatke u finansijskom i robnom knjigovodstvu (izradjenu kalkulaciju i kepu knjigu)?
Ne znam da li to ima reseno na ovaj nacin, i da li postoji uopste neka standardizacija u komunikaciji izmedju razlicitih informacionih sistema, pa verujem da je ovako neka tema dobra za diskusiju, i da tu moze puno da se uradi. Cak mozda i pravljenje nekog softverskog resenja koje bi sluzilo iskljucivo za uskladjivanja svih informacionih sistema na trzistu.
Na taj nacin bi se ustede bile jako velike.
Pre svega,
hvala na veoma zanimljivom komentaru.
Naravno da ima logike i da bi bilo sjajno i iako sam ja tip čoveka koji uvek kaže „a što ne bi moglo“ po onome što sam čuo do sad to je teško ostvarivo kako stvari stoje sad.
Mi smo na blogu na tu temu imali intenzivnu diskusiju na Knjigovodstveni programi i standardi koja bi mogla da se sažme grubo:
– programa je mnogo i svi su potpuno različiti (tehnološki, implementaciono itd itd)
– država nije zainteresovana ili nema sredstava/načina da definiše standard i propiše određene norme
– proizvođači programa su nekoliko puta pokušali da se dogovore sami oko toga bezuspešno.
Dejan je u komentarima A sad adios spomenuo neki xml format dogovoren za razmenu još na osnivačkoj skupštini Udruženja Proizvođača softvera Srbije pre više godina
tako da je to verovatno najdalje što se odmaklo u ovom smeru.
Sve u svemu, dok država ne zamahne svojom batinom sve se svodi na usamljene poduhvate dostojne Don Kihota (ja sam jedan od tih što uludo troši energiju u ovom pravcu da podrži scenario koji ste naveli importa fakture drugog programa) koje nisam optimista da će dovesti do željene opšte integracije između programa u dogledno vreme.
Teško naravno ne znači i nemoguće 🙂