Upravljanje dokumentima preko WEB

Započeo Siniša Ranđić, 26.01.2017, 21:17

prethodna tema - sledeća tema

Siniša Ranđić

Često sam u prilici da popunjavam čitav niz formulara, koji se zatim prosleđuju nadležnim licima na obradu. Da bi jedan takav dokument postao izvršan tj. da bi se moglo postupiti po njemu neophodno je da prođe, kako se to kaže, nekoliko ruku. Konkretan slučaj je postupak otvaranja putnog naloga za putovanje u zemlji i inostranstvu. 
  • Onaj ko treba da putuje popunjava odgovarajući zahtev;
  • Zahtev predaje u administraciju;
  • Odluku o otvaranju putnog naloga donosi rukovodilac (dekan) uz saglasnost nekog od svojih pomoćnika (prodekana);
  • Na osnovu pozitivne odluke nadležni administrativni službenik popunjava putni nalog i zavodi ga u delovodnik;
  • Po izvršenom putovanju izvršilac popunjava putni nalog i predaje ga u finansijsku službu zajedno sa pratećom dokumentacijom (računi).
U vreme informacionih tehnologija ovaj posao bi mogao da se automatizuje. A jedan ovakav pristup bi bio dobra prilika da studenti učestvuju i realizaciji jedne relativno složene aplikacije, koja bi zahtevala demonstraciju stečenog znanja na jednom konkretnom poslu. A istovremeno bi se utvrdila korelacija u pogledu načina i obima znanja koja se stiču tokom nastave sa zehtevima rešavanja konkretnog problema.

durma93

Dobra stvar I cini mi se ne tako teska za implementaciju. Ali kao sto uvek biva lakse je reci nego uraditi.

Miloš

Ovo je oblast kancelarijskog poslovanja koja je zakonski i pravilnicima uredjena u nasoj zemlji.

Samo kancelarijsko poslovanje se razlikuje od ustanove u kojoj se sprovodi, ali najcesce podele su na opstinsko kancelarijsko poslovanje, sudsko, vojno i privredno. Najvece razlike se vide u delovodniku.

U opstinama "zivotni ciklus" predmeta izgleda ovako:
Podnosenje zahteva (gradjanin predaje zahtev) > Zavodjenje predmeta ili spisa akata u pisarnici (predmet dobija IDK broj) > resavanje predmeta (referenti resavaju predmet) > arhiviranje ili slanje u drugi stepen

U privredi je to obicno malo drugacije, ali sustinski isto. Osnovna razlika je u delovodniku, tj nacinu vodjenja predmeta.

U sustini dosta interesantna tema, postoji nekoliko domacih firmi koje nude svoja resenja, ne bih da ih ovde reklamiram, ali ono sto je interesantno jeste da su vecina resenja desktop app i mislim da ni jednu web app nisam nasao. Nekako je logicno da ovaj vid app bude desktop varijanta, ali mislim da ce uskoro prevagnuti i tu potreba za kvalitetnim web softverom, posebno u opstinama.

Ukoliko ima zainteresovanih rado bih podelio svoje znanje o ovoj temi. Za one koje interesuje konkurencija najbolje je da guglaju pojmove: episarnica, elektronska pisarnica, elektronsko kancelarijsko poslovanje i sl.

Imajte u vidu da Vam je najveci konkurent microsoft-ov Share Point, ali nije bas realno da on jos dugo godina zazivi u nasoj zemlji, mada znam neke kompanije koje ga uspesno koriste. Sistem je veoma robustan tako da ga zbog toga ljudi izbegavaju.
Dip. Inž. elektrotehnike i računarskog inženjerstva (Moduo RI).
Zaposlen u firmi Infolab d.o.o. na poziciji DevOps Inženjer (odnosno system administrator i release manager).

Siniša Ranđić

Ja sam o ovome razmišljao kao pokaznoj vežbi za studente, a usput bi se i poslovanje Fakulteta osavremenilo. Znam ja koliko smo mi konzervativni, najčešće bez razloga. Npr. ja sam valjda jedini nastavnik koji Zapisnike sa ispita popunjava elektronski. Istina kao Word dokument, ali ipak nije ručno. U principu u prvo vreme sve može da se vodi dvostruko, tj. da postoji elektronska verzija i papirna. Ali bi ipak izgradila jedna nova informaciona infrastruktura, a studenti bi bili u prilici da realizuju realan sistem, koji ima cilj da živi, a ne da zadovolji nastavnika.

Miloš

Naravno, sto se tice vezbe bilo kakav rad je dobar rad.

Pokazna vezba ili ne, uvek postoji mogucnost da se prica prosiri, a ako se neko dobro potrudi moze kasnije i da zaradi.


Dao sam jednu pogresnu informaciju, zakoni o kancelarjskom poslovanju su definisani samo za drzavne ustanove, dok privatnici nisu u obavezi da implementiraju ove odredbe, tj mogu samostalno da se organizuju kako ce da vode svoje delovodnike.


Iz iskustva ljudi koji se ovim bave vec vise od 10 godina, vecini firmi vodi skraceni delovodnik, gde se predmeti zavode kao br/tekuca_godina i pored toga arhiva, kako bi se lako nasli arhivirani predmeti.

U sustini ovo bi bilo kreiranje nekog DMS-a (Document management studio).
Dip. Inž. elektrotehnike i računarskog inženjerstva (Moduo RI).
Zaposlen u firmi Infolab d.o.o. na poziciji DevOps Inženjer (odnosno system administrator i release manager).

Siniša Ranđić

Ja ću u toku dana završiti opis projektnog zadatka i pregled svih operacija koje se izvršavaju. Mislim da će biti interesantno razmišljati o ovom problemu, ne toliko da se nekome olakša posao, koliko sa aspekta izrade aplikacije. Čak mislim da će se pokazati da je u pitanju komplikovanija stvar nego da se radi ručno. međutim, ne treba se ad hoc predavati.

Siniša Ranđić

Po obećanju pripremio sam predlog Projektnog zadatka za razmatranu aplikaciju. Na bazi njega potrebno je izvršiti detaljnu analizu problema i definisati sve informacije i aktivnosti koje treba softverski podržati. U okviru zadatka pokušao sam kratko da ukažem na strukturu tiha ktivnosti i informacija koje treba obrađivati. Međutim, ostao je određeni broj finesa koje nisu razmatrane, a može se pokazati da su značajne za realizaciju aplikacije. Ono što se često zaboravlja tiče se izuzetaka, tj. situacija koje nisu deo normalnog izvršavanja obrade, već se radi o situacijama koje mogu da dovedu do neželjenih posledica i koje pri realizaciji aplikacije treba identifikovati i ponuditi odgovarajuću reakciju koja će date posledice da predupredi. 
Što se tiče same realizacije aplikacije treba pokušati da se ka krajnjem cilju ide parcijalno. Tj. možda treba poći od pretpostavke da nije potrebno odobravanje putnog naloga već da se na bazi zahteva i njegovog zavođenja "štampa" putni nalog. U narednim koracima može se ći na varijante popunjavanja putnog naloga i izrade obračuna. Tek na kraju može da se umetnu koraci koji podrazumevaju odobravanje putnog naloga. Kad je u pitanju autentifikacija treba voditi računa da pri registrovanju korisnika treba voditi računa da se oni mogu "regrutovati" samo iz spiska zaposlenih, jer bi u suprotnom slučaju putni nalog mogao da zahteva bilo ko ko pristupi odgovarajućoj WEB stranici.
Očekujem predloge za rešavanje ovog problema, kao i doprinose u specifikaciji pristupa upravljanju dokumentima poput ovog.

Marko Аcović

Koliko sam video, putni nalogi izgleda kao na ovom linku: http://media.preduzetnik.rs/2015/06/slput.pdf

U skladu sa tim, ja bih najpre krenuo od definisanja baze podataka u koju ce biti smesteni sve relevatni podaci.
Najpre, potrebna je tabela sa korisnicima (nastavnicima i saradnicima).

Tabela korisnici (nastavnici) bi trebalo da ima sledeca polja:

== users ==
* ID (integer) // PK
* first_name (varchar(20))
* last_name (varchar(20))
* username (varchar(20))
* fk_workplace_name_id (integer) // FK
* email (varchar(20))
* password (varchar(50)) (md5 ili neka druga enkripcija)
* phone1 (varchar(20))
* phone2 (varchar(20))
* account_activated (boolean)
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

Druga pomocna tabela koja je potrebna je tabela sa zanimanjima (saradnik, docent, vanredni prof, redovni prof,...):

== workplaces ==
* ID (integer) PK
* workplace_name (varchar(50))
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

Jos jedna pomocna tabela za tipove prevoznih sredstava
== vehicles ==
* ID (integer) // PK
* name (varchar(20))
* category (smallint)
* description (varchar(200))
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

Tabela sa putnim nalozima bi mogla da izgleda ovako:

== travel_warrants ==
* ID (integer) // PK
* warrant_id (integer) // UNIQUE (Ako sam dobro razumeo, ovo je delovodni broj)
* fk_user_id (integer) // FK
* country (varchar(20))
* city (varchar(20))
* fk_vehicle_id (integer) // FK
* approved_by_dean (boolean)
* approved_by_vicedean (boolean)
* expenses_approved (boolean)
* travel_description (varchar(300))
* fk_wages_id (integer) // FK
* start_date (DATE) // pocetak putovanja
* end_date (DATE) // kraj putovanja
* travel_report (TEXT ili BLOB) // izvestaj, popunjava se po zavrsetku putovanja                       
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

 Trebace nam i tabela sa dnevnicama za slucaj da postoje cenovni rangovi (u zavisnosti od rastojanja)
== wages ==
* ID (integer)
* range_type (VARCHAR(50))
* price (DECIMAL(p,s)) // Dnevnica
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

Tabela sa strukturom troskova
== travel_expenses ==
* ID (integer) // PK
* fk_expense_type_id (INTEGER) // FK
* price (DECIMAL(p,s))
* fk_vehicle_id (integer) // FK
* travel_warrant_id (INTEGER) // FK
* description (VARHCAR(200))
* start_date (DATE) // za slucaj da se menja prevoz
* end_date (DATE)
* created_on (timestamp)
* created_by (integer)
* updated_on (timestamp)
* updated_by (integer)

Naravno potrebna je i tabela sa vrstama troskova
== expenses ==
* ID (INTEGER) // PK
* expense_name (VARCHAR(20))
* description (VARCHAR(200))

Kad se gorepomenuto uzme u obzir, dijagram tabela bi trebalo da izgleda kao na slici putni_troskovi_db_shema.jpg.

Predlazem sledeci nacin koriscenja aplikacije za upravljanje putnim nalozima.

1. Korisnik klikne na link FTNC sevisi
2. Otvara se ekran prikazan na slici 2a
3. Ako je registrovan, korisnik unosi svoje korisnicko ime i lozinku
4. Ako su ulazni parametri ispravni, otvara se ekran prikazan na slici 2b
5. Odavde korisnik moze da pregleda sve postojece putne naloge, da ih pretrazuje, stampa, kao i da kreira nove

Ukoliko ne postoji kreiran nalog, klikom na link na ekranu za logovanje, trebalo bi da se otvori novi ekran (nisam ga nacrtao) gde bi korisnik (nastavnik) trebalo da unese svoje podatke. Moglo bi da se napravi aktivacija naloga putem SMS poruke. Na primer, korisnik unese i prosledi sve podatke a onda mu na telefon stize SMS poruka sa kodom koji je validan u narednih 15 minuta i koji mora da unese u dodatno polje kako bi nalog postao aktivan. Ovo se naravno radi samo jednom.

Klikom na link Kreiraj nalog trebalo bi da se otvori nova forma gde bi korisnik trebalo da unese podatke o putovanju i taj nalog sacuva. Ako sam dobro razumeo, nakon toga, SMS/mejl bi trebalo da stignu dekanu i prodekanu cime ih obavestava o pristiglom nalogu za odobrenje. Nakon odobrenja, korisnik unosi troskove putovanja i dalje ide proces opisan u profesorovom pdf dokumentu.

Bilo bi dobro napraviti i Android verziju aplikacije gde bi korisnik mogao da ubacuje troskove za odredjeno putovanje.

Izvinjavam se sto sam ovako nabacao informacije. Pisao sam kako mi je dolazilo na pamet. Trebalo bi svakako dobro porazmisliti i postaviti dobre osnove kako kasnije ne bi bilo problema u implementaciji i eksploataciji.

Ako ima pitanja ili nesto nije jasno, mozemo da diskutujemo.


Siniša Ranđić

Želim da se zahvalim Marku na trudu koji je učini da osmisli rešenje probleme i da svoje komentare na sam problem.

Marko Аcović

Razmisljam od jutros, kako god da se usaglasimo za strukturu tabela, dobro bi bilo da se za svaku tabelu napise po jedna klasa u kojoj bi bile sadrzane metode za dodavanje, izmenu, brisanje, pretragu unosa iz te tabele. Tako bismo za tabelu users imali klasu:

class Users {
    int id;
    string firstName;
    string lastName;
    ...
    ...
    public string getUser() { ... }
    public boolean updateUser() { ... }
    public boolean validateEmail(string email) { ... }
    ...
}

Na slican nacin se odradi i za ostale tabele. Na ovaj nacin imamo modele svake tabele i interfejs za komunikaciju sa bazom. Nakon toga, trebalo bi izmodelovati i kontroler i view i onda imamo finu MVC aplikaciju.

Siniša Ranđić

Slično bi bilo i za pitanje autentifikacije.
  • Treba da postoji spisak onih koji uopšte mogu da pristupaju WEB stranicama;
  • Prava pristupa i operacijam nad tabelama i stranicama
  • Sam proces dodeljivanja pristupnih parametara
  • Proces autentifikacije

Marko Аcović

To bi moglo da se resi tako sto se kreira posebna tabela koja ce da sadrzi definicije svih privilegija i nivoe. Zatim se ta tabela uveze sa tabelom korisnika u relaciji vise prema vise (nova tabela izmedju koja bi definisala koji korisnik ima koji skup privilegija).

Marko Аcović

A proces autentifikacije bi mogao da ide na sledeci nacin:

1. korisnik klikne na link FTNC servisi.
2. otvara se ekran gde se korisniku nudi da se uloguje preko korisnickog imena/sifre. takodje mu se nudi registracije
3. klikom na registraciju, otvara se novi ekran sa formom za popunjavanje.
4. Korisnik unese sve podatke i klikne na Submit
5. Aplikacija generise jedinstveni alfanumericki kod koji salje korisniku na mejl. ovaj kod bi imao rok vazenja od 15 minuta
6. Korisnik otvara mejl, kopira kod i unosi u formu cime se zavrsava proces registracije. Ukoliko ne unese u roku od 15 minuta, proces registracije se ponistava i svi podaci moraju da se unose iz pocetka.
7. Nakon toga, administrator aplikacije definise privilegije za novoregistrovanog korisnika (opisano u prethodnom postu)