RSS

Numerisanje knjigovodstvenih dokumenata

15 Apr

Numerisanje knjigovodstvenih dokumenata

Dobar program za knjigovodstvo se od strane svog autora skoro obavezno opisuje ovako

“Korišćenjem programskih opcija program je moguće u potpunosti prilagoditi osobenostima poslovanja korisnika”.

Poenta je veoma jasna: naš program radi i može sve za svakog da odradi samo ga treba malo podesiti.

Ja se sa tim uglavnom ne slažem i mislim da od “viška glava boli” te je po odgovornost autora da odabere minimalni set funkcija koji odgovaraju potrebama većine korisnika i da namerno zaobiđe “uniju svih eventualnosti” – jednostavnost ispred moći.

Jedno od retkih aspekata knjigovodstvenih programa gde taj princip ne važi je aspekt numerisanja dokumenata koji se kreiraju u programu za knjigovodstvo. Razlog zašto je to tako leži u mom lošem ličnom iskustvu iz prošlosti kada mi je problem broj jedan za distribuciju programa bio baš to što potencijalni korisnici nisu hteli da pređu sa svog metoda označavanja dokumenata na moj “super-inovativno-pametni” način. Jednostavna lekcija naučena tada: ljudima je bitno kako označavaju dokumente jer im to omogućava jednostavnije snalaženje u moru papira kojim su zatrpani i koliko god da je loš ili dobar taj sistem numerisanja veoma je teško odvići se od iste.

Ono što je problem u ovom validnom zahtevu korisnika je da svako od njih ima neki svoj način (obično urezan u cortex dugogodišnjim korišćenjem nekog knjigovodstvenog programa) i svi su oni različiti te je moj tadašnji pokušaj da od slučaja do slučaja dodajem nove načine rezultovala papazjanijom u kodu i “morem opcija”.

S obzirom da se dekadu kasnije opet srećem sa istim tipom programa, rekoh da ovaj put prvo razmislim pre nego što krenem sa programiranjem, a kad već razmišljam što ne bih razmišljao na glas.

Super-inovativno-pametni način numerisanja dokumenata

U tom mom starom programu imao sam dva tipa numerisanja gde je numerisanje dokumenata na prvi način je bilo implementirano na sledećim principima:

svaki objekt ima svoju šifru koja je tipa “01”, “02”….
brojač dokumenta je zaseban za svaki objekt
broj dokumenta == šifra objekta x 10.000 + redni broj dokumenta

.
Na primer, recimo da imam dva maloprodajna objekta i da unosim po kalkulaciju za oba objekta: broj kalkulacije prvog – 10001, broj kalkulacije drugog – 20001.

Prednost ovog principa je da na osnovu broja dokumenta “10001” korisnik odmah zna da je to iz MP 01 objekta.

Mana ovog metoda ima više:

Šta ako su šifre objekta MPBGD, MPNIS itd?
Šta ako imam fakturu na kojoj su iskazane stavke iz više objekata?
Objekat 01 ima više dokumenata sa istim brojem (MP kalkulacija 10001, MP Faktura 10001 itd)

.
Drugi metod numerisanja u tom mom starom programu je bio korišćen u numerisanju naloga za knjiženje i izgledao je ovako: ŠIFRA TIPA DOKUMENTA + ŠIFRA OBJEKTA + DD + MM

Recimo da je tip dokumenta “MP kalkulacija” ima šifru 31 i da je spomenuta kalkulacija broj 10001 napravljena 15.04.2012 broj naloga za knjiženje bi bio 31011504.

Prednost ovog metoda je da se samo na osnovu broja naloga automatski zna njegov datum i šta je na njemu knjiženo. Prednost je takođe ta što nema brojača u nalogu tako da se knjiženja slažu “prirodno” bez obzira na to kojim redosledom su unošena i kojim danima.

Mana ovog metoda je očigledna: broj naloga ne sadrži broj dokumenta te se postavlja pitanje šta ako je 15.-og aprila u objektu 01 bilo više kalkulacija?

Odgovor (u slučaju tog starog programa) je: gde piše da knjižni nalog mora da sadrži podatke SAMO jednog dokumenta.

Ostali načini numerisanja

Ok, sada kada ste videli tip numerisanja koji sam ja podržavao, sasvim vam je jasno na koji način sam reagovao kada je tokom moje prezentacije programa nekoj knjigovodstvenoj agenciji X dobio odgovor da se njima to ne dopada i da oni numerišu dokumente sa TIP DOKUMENTA + BROJAČ, da koriste isti brojače neovisno o objektu, a da naloge numerišu sa GGGG MM DD 0001.

Koristeći primere od gore njihovi brojevi dokumenata su: K0001 (kalkulacija objekata 01), K0002 (kalkulacija objekta 02) i 201103310001, 201103310002, 201103310003 itd.

Šta ću, gde ću – odradim i to i dodam nekoliko check box opcijama u administraciji.

Sledeća agencija: “ne sviđa mi se šta vi radite, a ne sviđa mi se ni agencija X što radi”. Oni numerišu sve dokumente na način TIP DOKUMENTA + OBJEKT + MESEC + 01 brojač.

Koristeći primere od gore njihovi brojevi dokumenata su: MKAL 01 03 01 (kalkulacija objekata 01), MKAL010302 (kalkulacija objekta 02) i NAL010301, NAL010302 itd.

Ishod znate, posle n agencija broj opcija u administraciji je premašio broj dugmadi u NASA lansirnom centru, a moj kod postao papazjanija i uvek je sledeći korisnik imao “svoj super-inovativno-pametni način”

Rad, red i disciplina

Za mene lično, putanje numerisanja dokumenata je stara navika ostala iz prošlosti i proistekla iz korišćenja loših knjigovodstvenih programa jer jednostavno i brzo pronalaženje željenog dokumenta u svakom programu bi danas trebalo da bude potpuno trivijalan zadatak za korisnika bez obzira kako sa koji dokument numeriše.

Ipak ne mogu da ignoriše problem koji očigledno postoji:

korisnici ne žele ni da pomisle da pređu na program koji ne podržava njihov način numerisanja
programska podrška od slučaja do slučaja nije isplativa ni za mene ni za korisnike

U mojim analizama starog koda koji podržava sve lude načine numerisanja pronašao sam da većina njih sadrži jednu ili više varijabli sledećeg tipa:

tip dokumenta – skraćenica (VPFAK, F)
tip dokumenta – šifra (31)
šifra objekta – (01, MP01)
šifra partnera – (kupca ili dobavljača)
Godina – (12, 2012)
Mesec – (04,4, apr)
Dan – (15)
Brojač po tipu dokumenta
Brojač po objektu
Brojač po tipu dokumenta i objektu
Brojač po Godini i/ili Mesecu i/ili Danu

Tokom instalacije mog programa, korisnik će moći da odabere bilo koju kombinaciju gore navedenih delova koji grad broj dokumenta za sve dokumente ili po tipu dokumenta.

Ono što ja (za sada bar) planiram da ponudim kao podrazumevan način numerisanja dokumenata je sledeće:

TIP DOK + BROJAČ PO TIPU DOKUMENTA (MPK0001, MPK0002)

Razlog: deluje mi kao najprostiji moguć pristup

Slažete se?

2 Comments

Posted in Funkcionalne karakteristike

Ulaz

27 Mar

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. Smeško

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 10^x 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… Smeško

4 Comments

Posted in Funkcionalne karakteristike, PC-Shop

Proizvodnja računara

27 Feb

Knjigovodstveni programi za proizvodnju računara

U ovom postu (kao što sam i obećao ranije) predstaviću moja razmišljanja na treći krupni problem koji PC servisi imaju u svom radu i koji ja pokušavam da rešim svojim programom.

Proizvodnja računara

U periodu od 1998-2001 radio sam kao serviser računara – zanimanje u narodu poznatije kao “crnac”.

Pos’o ko posao sa dosta blesavih stvari poput pamćenja svih piratskih serijskih brojeva od silnih (re)instalacija i nepobitnih transcedentalnih bisera mudrosti kao na primer trajno urezana u cortex spoznaja da kada se instalira Zyxel modem nikako ne sme da se kompjuter restartujte kada se to traži nego obavezno na dugme da se ugasi inače se Windows toliko sredi da može samo da se okadi posle toga. O nebuloznim korisničkim pričama neću ni da pričam, ko je proveo mesec u servisu čuo je sve o ljudima koji finom šmirglom krešu podnožje PCI kartice “da bolje legne” i onda donese komp na servis i slične narodne umotvorine.

Prolazile godine, a ja posta očeličeni crnac-veteran sasvim siguran da ne postoji stvar na koju ne mogu da se sviknem, al ne lezi vraže - dobih zadatak da napravim /suprise, suprise/ program za PC servis.

U početku sve beše kabeza: prijemnica, kalkulacija, ponuda, račun i sl. – prsite lete sami. Konfigurator, lager liste, cenovnici – radim levom rukom ne gledajući, dok desnom mlatim Gothic.

“Odraditi modul za proizvodnju računara”

Huh? Kakvu bre proizvodnju računara? Uzmem 5 dela sa police ispred mene, pobodem ih u ploču koju sam ubacio u kućište i to je to. U 99% slučajeva samo šrafciger pipam, dok u ostalim radi čekić kao sredstvo pretnje kompjuteru kod koga neće da se primi drajver za grafičku.

Čvrsto ubeđen da je šala u pitanju, uzimam papir i idem kod svog šefa sa osmehom na licu:”Da li je ovo neka greška?”.

I naravno da sam kao i svaki put kad postavim pitanje u vezi nešto besmislenog dobio odgovor

“To tako mora zbog knjigovodstva.”

Knjigovodstvo

Evo otprilike objašnjenja koji mi je dato tad – Šef (Š), Ja (JA)

Šef:”Vidiš ovu policu odakle prodajemo grafičke kartice – to je prodajni objekt. E sad kad uzmeš karticu odatle da ugradiš u kompjuter, karticu ne uzimaš iz prodajnog objekta, nego iz skladišta sirovina – razumeš?“

Ja:”Ne, razumem. Kažeš mi da moram da uzmem karticu sa ove police i odnesem na policu u magacinu pa tek onda odatle da je uzmem?

Šef: “O Bože. Pa nisi valjda retardiran da to uradiš. Zašto bi je nosio u magacin kad ćeš da je odatle odmah uzmeš i ugradiš? To se samo tako kaže – to je zbog knjigovodstva”

Ja: “A, zbog knjigovodstva znači” (ne razumem ništa, ali sigurno ima smisla kad je zbog toga)

Šef: “Ok, sad kad si uzeo taj deo iz knjigovodstvenog magacina, treba ti radni nalog da bi pristupio proizvodnji računara”

Ja:“Je l’ taj nalog ono kad mi ti vikneš sa sprata da “sklopim trojku sa 98-com” ili je to neki poseban nalog?”

Šef:“Ne, ja ti to kažem i dalje. Ovo je samo kobajagi papir gde ti ja naložim da to uradiš – zbog knjigovodstva”

Ja: “A, zbog knjigovodstva znači” (ne razumem ništa, ali sigurno ima smisla kad je zbog toga)

Šef:”E uzmeš lepo papir i popišeš delove sa stikerima koje ugrađuješ u komp i zabeležiš vreme koje provedeš proizvodeći računar”

Ja:“Misliš sklapajući računar? Kako da merim kad ih radim četiri odjednom ili idem na teren?”

Šef:”Ma to nema veze, bitno da zabeležiš samo stikere negde da razdužimo stanje i zbog garancije. Stavi uvek da si radio 45 minuta – to je smo zbog knjigovodstva”

Ja: “A, zbog knjigovodstva znači” (ne razumem ništa, ali sigurno ima smisla kad je zbog toga)

Šef:”Sad kad si proizveo računar, moraš da ga prebaciš u magacin gotovih proizvoda pa odatle da prebaciš u maloprodajni objekt. Odatle uzimaš kompjuter i daješ ga kupcu.”

Ja:“Gde da čeka mušterija dok mu nosim kompjuter po radnji da ga osveštam?”

Šef:”’e l’ me ti to zajebavaš? Naravno da nećeš da zavitlavaš tako mušteriju koja čeka da završiš. Čim sklopiš komp odmah mu daš sa tog stola gde radiš čim vidi da radi kako treba. To je samo tako zbog knjigovodstva.”

Ja: “A, zbog knjigovodstva znači” (ne razumem ništa, ali sigurno ima smisla kad je zbog toga)”

Ja:”Ok, ukapirao sam sve uđu dva kompa u MP objekt jedan izađe, drugi izađe – sve po PS-u”

Šef:”E tu sam te čekao! Nema dva kompa, praviš samo unikate. Jedan te isti komp, od istih delova potpuno kad napraviš dvaput to su unikati “PC 0001” i “PC 0002”. Znači stanje na lageru ide 1 pa 0. Nema nikad dva. Znam sad ćeš da me pitaš a što tako – zato što nemam para da certifikujem brend i svakom odrežem drugačiju cenu pa bi morao da nivelišem i ko zna šta još. Nemoj mnogo da razmišljaš, to je zbog knjigovodstva”

Ja: “J…o to knjigovodstvo – ništa nema smisla, al dobro – kad je zbog knjigovodstva….”

I vuk sit i ovce na broju

Evo 10+ godina kasnije se još trudim da prisilim sebe da nađem smisao u gore navedenom razgovoru – te proizvodnja nameštaja i računara je proizvodnja, te mora da postoji neka forma, standard itd. Pokušavam i ne uspevam.

To što zakon prisiljava nekog da odradi 73 različita papira za radnju tipa “uzmi 5 dela sa police, sastavi komp i daj ih čoveku koji sedi pored tebe” je i dalje po meni besmisleno. Proizvodnja računara i proizvodnja nameštaja nisu iste. Ono što ima smisla u slučaju prave proizvodnje, po meni je besmisleno u slučaju PC servisa.
Na sreću pa se ja ništa ne pitam nego se pitaju zakoni koji propisuju to što propisuju te su su zahtevi za 73 papira realni i neminovni. Tačka.

Upravo zbog te zakonski propisane obaveze s programi za knjigovodstvo koji se koriste u PC servisima i zahtevaju da se odradi sva papirologija “zbog knjigovodstva”.

Po mom ličnom mišljenju, program za PC servise može da efikasno reši taj problem i ispoštuje zakonsku formu na način koji je zabavan i ne troši vreme korisnika programa.

Efikasno rešenje

Moje se rešenje zasniva na bazi toga što knjigovodstveni programi opšte namene ignorišu način na koji se dolazi do proizvodnje računara. U slučaju PC servisa proizvodnji računara prethodi proces sastavljanja ponude/računa za prodaju računara na bazi lokalnog lagera i ponude distributera računarske opreme. Dokument koji definiše ponudu kupcu sadrži spisak delova koje ulaze u konfiguraciju sa cenama i količinama.

Ako se to ima u vidu onda je sasvim jasno da je proces proizvodnje računara moguće automatizovati na sledeći grubo opisani način:

Za sve delove definisane u zadatoj ponudi X, kreiraj međumagacinske otpremnice koje prebace te iste artikle u magacin sirovina.
Za sve delove definisane u zadatoj ponudi X, kreiraj radni nalog 123 koji trebuje sirovine definisane u #1 i dodeljuje nalog serviseru X.
Serviser X nalazi u spisku radnih naloga dodeljenih njemu pronalazi radni nalog broj 123 i unosi koliko je vremena proveo radeći na računaru. Korak je opcioni i može biti “uvek 45 minuta” te se i ovaj unos izbegava.
Onog momenta kada serviser snimi #3, međumagacinska otpremnica iz proizvodnje u MP se kreira automatski. Nabavna cena definisana radnim nalogom, prodajna cena definisana ponudom datom korisniku.
MP račun / paragon se automatski kreira na bazi podataka definisanih u #4 .

Krajnji rezultat je da su svi papiri kreirani potpuno automatski na bazi ponude date korisniku uz apsolutno minimalno utrošeno vreme korisnika. Cilj koji gađam: odabere se ponuda, klikne OK, i automatski 73 papira izađu iz štampača u roku od 10 sekundi.

Kompletna papirologija odrađena i zakon ispoštovan, ali daleko od očiju korisnika koga ne zanima šta se dešava “ispod haube”.

Zaključak

Ovo gore navedeno je naravno samo suština rešenja kojim planiram da rešim problem metastazirane papirologije PC servisa i naravno da je stvarnost komplikovanija, ali da ne bi smarao Tihim Donom preskočiću deo o tome kako planiram da implementiram rešenje na način koji je podjednako fokusiran na zabavnost i efikasnost i koji čvrsto verujem će pokrivati i potrebe složene realnosti a da ne ruši jednostavnost korišćenja.

Do tada, evo nekoliko mojih pitanja i nedoumica:

Da li je ovo realan problem u radu PC servisa ili sam promašio temu?
Da li je izloženo rešenje (pod pretpostavkom da je realno izvodljivo) rešenje koje bi vratilo osmeh na lica zaposlenih u PC servisima?
.

7 Comments

Posted in Funkcionalne karakteristike, PC-Shop

Stranica 1 od 1712 3 4 5...10...»Poslednja »

Knjigovodstveni programi