Upravljanje investicionim projektima

Sve isto kao i prije...



_{[Ovu poruku je menjao Zidar dana 29.01.2013. u 18:53 GMT+1]}

Ma ne brini za program, ionako je vec zastareo

Muci me jos uvek shema baze. Ono sto imamo ne valja. Spremio sam novu verziju, cini mi se da je bliza realnosti. Zakacicu 3 slike:
1) cela baza = ShemaBAze_03.png
2) deo o okvirnim sporazumina i finsniranju
3) deo o izvodjackim ugovorima i situacijama

Shema je na nivou koncepta, ideje - logicki model. Nedostaju pomocne lookup-tabele i naravno nedostaju mnoge kolone (predmet radova, vrsta ugovora interni externi i ostal), u tabelama. One ce se pojaviti kad predjemo na fizicki model.

Ono sto se vidi iz sheme cele baze jeste da imamo dve oblasti koje su namerno ostavljene da budu nezavisne. Deo o finssijama (gore levo na shemi) i deo o izvodjenju (desno, odozgo na dole) jedinu vezu imaju preko liste projekata i plana kostanja projekata po godinama. To znaci da mozemo da radimo jedan pa drugi deo i da ti delovi rade jedan bez drugoga ako je potrebno. I zaista, da bi pravili ugovore s izvodjacima i pratili situacije, nije 100% neophodno da imamo podatke o okvirnim sporazumima. Isto tako, mozemo ceo posao u vezi sa finasiranjem da napravimo a da i ne znamo za situacije i izvodjacke ugovore. Kada cemo da povezemo finasiranje i izvodjenje? Onda kada budemo hteli da finasijerima prosledimo naloge za naplatu koji proizilaze iz podnesenih situacija. E to ce verovatno da popuni onu prazninu u donjem levom uglu nase sheme.

Za sada ne znamo dovoljno o mehanizmu same naplate, pa neka to saceka. Ne znamo da li prvo komunalac naplati od finasijera, pa onda komunalac plati izvodjacu minus motazni radovi, ili se trazi da finasijer direktno plati izvodjacu, pa onda izvodjac placa komunalcu za montazne radove, ili nesto trece, za sada nas ne zanima.

ShemaBaze_03 dozoljva:
1. da bude vise od jednog finsijera na jednom sporazumu
2. da se projekti izvode vise od jedne godine
3. da za svaku godinu projekta doidelimo jednog ili vise finsijera

1. Za svaki projeakat raspisujemo javni poziv
2. Imamo tacno jednog pobjednika na javnom pozivu
3. Taj pobednik sklapa ugovore za svaku godinu za projekt koji mi je dodeljen
4. za svaki ugovor podnose se situacije

Nije vidljivo sa shema ali vazi:
1. Komunalac ce se naci na lsiti finsijera
2. Komunalac ce se naci na lsiti potencijalnih izvodjaca (ugovaraca, kao u prethodnim verzijama)
3. komunalac ce biti neakd narucilac radova, a nekad izvrsilac
4. Kada je komunalac izvrsilac radova, narucilac je izvodjac sa postojecim ugovorom

Shema grantuje integritet podataka u smislu da neke stvari moraju postojati pre nekih drugih stvari. Na primer, da bi se nparavio ugovor o izvodjenju, mora da postoji a) pobednik javnog natjecaja i b) plan kostanja projekta za datu godinu. Drugi primer - da bi se dogovorilo finsiranje projekta kroz godine, mora da postoji a) okvirni sporazum b) lista finasijera sa dodgovorenim udelima u finsiranju c) plan kostanja projekta po godinama.

Nas problem je kako da obezbedimo integritet podataka i za uslove koje se nevide sa sheme:
1. jednom uneti podaci o ugovoru ili okvirnom sporazumu (datumi, iznosi) ne smeju se vise menjati (moze se napraviti anex ugovora, ali se ne sme menjati postojeci ugovor)
2. da se jednom unete situacije ne mogu vise menjati
To cemo kad budemo radili fizicki dizajn baze.

Sada slike:
A) Finasiranje projekata:

B) IZvodjenej Projekata

C) Sve zajedno

Najbolje je da se kompletna baza povezuje preko samog Projekta.

Ova ideja mi se sviđa i mislim da će i sami budući korisnici jednostavnije koristiti buduću bazu. Koliko sam te shvatio, neće biti problem povezati i izraditi podatke koje smo u prethodnoj shemi imali za ugovore. Pošto je ubačena tablica JavnaNabava da li to znači da se naknadno može u bazu uključiti i dio za pračenje kompletnog postupka javne nabave ( objava, eventualne žalbe i dr. vezano uz JN ).

Usput da navedem da je princip plaćanja direktno izvođačima cesijama.
Pozdrav!

U access verziji bice sva polja koja smo imali ranije (narucilac, izvrsilac, Predmet ugovora, zastupnici, vrsta ugovora). Menja se dosta deo o finansiranju i nacin na koji su povezane tabele.

Ugovore mozemo direktno vezati za projekte, ali mi se cini da je veza na PlanKostanjaProjekta (Projekt,Godina, Iznos) bolja jer se ugovori sklapaju za svaku godinu, sa ili bez okvirnog sporazuma. Ugovori vise nisu vezani za sporazume. Znaci, na strani ugovora belezis stvarne troskove (sto moras platiti izvodjacima), a n strani finansiranja belezis plan trosenja para, ko ce i koliko na kraju da plati. Baza podataka ti pomaze da uporedis sta su ti ispostavili izvodjaci sa onim sto su ti finasijeri obecali da ce platiti.

Verovatno ce za javne nabavke moci da se doda ono sto si pomenuo, posto smo javnu nabavu uveli u igru.

U Access verziji necemo pisati nikakav kod, prvo cemo upisvati podatke u tabele direktno, onim redom kako nam kaze flow-chart koji smo na pocetku napravili - ko sta radi. Mozda ce nam trebati i jedan flowchart da pokrije finansije, to nemamo u pocetnom dijagramu.

Najverovatnije nist sutra, ili vrlo malo, imam puno da radim, ali bice za cetvrtak i petak zasigurno.

Odlično, ja ću za vikend uzeti kući stvarne podatke iz firme ( ugovore, situacije i dr. ) tako da napunim tablice kako bi onda lakše pratio tok i relaciju podataka kroz npr dva primjera koji se međusobno razlikuju.

Prije svega, pohvaljujem temu i pratim je zdušno :)
Hvala pokretaču teme, i svima koji pomažu (da Vas sada ne nabrajam sve :) ) ovo izgurati do nekog nivoa.

Igrom slučaja radim u jednoj građevinskoj firmi pa imam iskustva sa situacijama, ugovorima, itd. Često se na neki ugovor dodaje aneks, pa bi i to trebali uzeti u obzir, npr. ubaciti entitet "aneks".

Također, u najviše slučajeva Situaciju ovjerava izvođač, nadzor i investitor (osim ako nisu neki manji poslovi kada investitor ne angažira nadzor), tako da smatram da bi trebali ubaciti i entitet "nadzor".

Imam još nekih ideja, ali za sada toliko, dok vidim kako će se prihvatiti ove, ali uglavnom radi se o vrstama usluga, odnosno radova koji bi bile stavke ugovorenog troškovnika, preko kojega bi se Situacija trebala automatski generirati.

Naravno, ovo sve govorim iz prakse na poslu, s programiranjem Vam baš ne mogu puno pomoći :)

Hvala thenoise Ono sa aneksima je dobra ideja, ubacicemo, 'leba ne jede.

Sto se tice nadzora i overavanja, dobro je i to, ali cemo sacekati malo sa povezivanjem. Za sada mozemo da evidentiramo ugovor koji Komunalac potpisuje sa nadzornim organom. Overavanje situacije i placanje je proces, koji cemo verovatno modelovati nesto kasnije. Za sada nam je dovoljno da evidentiramo ugovore i situacije koje dolaze na overu na osnovu tih ugovora. Overa situacija je sledeci korak, u ovom momentu to jos nemamo.

U ovom momentu nema planova da se cuvaju u bazi stavke troskovnika (troskovnik = predmer i predracun ?), niti stavke ugovora, iako je i to moguce. To ima smisla jedino kad se ovaj sistem poveze sa projektovanjem, pa projektanti direktno u bazu unose stavke troskovnika. Ako nije tako, onda mora neko da prekucava ceo predmer u bazu, sto nije prijatno i na kraju zbog toga nikad i ne proradi cela stvar.

Naravno, ne znaci da ne moze da se skine baza sa foruma i da svako sebi dodaje sta mu treba. Samo treba biti pazljiv da se negde ne zabrlja.

Drago mi je da nam se thenoise pridružio;
Što se tiče ideje o unosu troškovnika i automatskog generiranja situacija, mislim da bi to strahovito zagušilo bazu; mada nebi bilo loše, međutim za višegodišnje radove (npr. izgradnja vodospreme cca 4000 m3) imam izvođačku situaciju od 50-100 listova svih vrsta radova i dovoljna je greška u jednoj stavci, opisu stavke i sl. da kompletan trud padne u vodu. Kada sam dobio ideju za ovu bazu želja mi je bila u konačnici pratiti stvarne troškove realizacije nekog projekta; ugovaranje, izvođenje i troškovi realizacije projekta da bi znao da li je investicija pozitivna ili negativna. Taj dio možemo eventualno na kraju...
Pozdrav!

Upravo zbog toga nisam ni detaljno pojašnjavao cijelu ideju, dok ne čujem vas kako ćete reagirati.

Mada, ukoliko želiš pratiti i troškove, i fakturirane, odnosno situirane radove, trebaš ih pratiti prema nekom ugovorenom troškovniku da bi znao da li si na nekom projektu u plusu ili minusu.

Ne znam kako misliš postaviti relaciju ugovoreno/utrošeno, ako ćeš upisivati samo cifre u access bazu, negdje opet trebaš sa strane (čitaj excel) računati troškove.

Ali u pravu ste, idemo dovršiti ovu super ideju, pa se onda može nastaviti ukoliko bude znanja i volje :)

Vjerojatno si mogao zaključiti da radim u komunalnoj firmi i kao tehnički rukovodioc moj je posao upravo što želim rješiti kroz ovu bazu. Kolegica koja vodi računovodstvo i financije ionako prati troškove za pojedine projekte (plaće, materijali, prijevoz i ostali troškovi) a ja mislim njezin izračun upisati u bazu...
U budućnosti tko zna?

Polako se ukljucujem u temu, malo sam zapostavio i cini mi se da na osnovu ovog Vaseg poslednjeg posta ipak sve vodi da je granica sistema na nizem nivou od Preduzeca ili kako ste rekli "moj je posao upravo što želim rješiti kroz ovu bazu". Mozemo li onda smatrati da je Vas posao upravljanje investicionim projektima? Ako je to tako onda bih pokusao da definisem prvo funkcionalni model, a onda model podataka.

---

Zorane, već je bilo i vrijeme da se uključite!

Na žalost, moj posao nije samo upravljanje investicionim projektima, ali je i to. Jednostavno smatrao sam da sa rješavanjem baze za vođenje investicionih projekata rješavam si ogroman posao, a puštam mogućnost naknadne dogradnje sistema za "viši" nivo. Sama baza za upravljanje investicionim projektima je za mene ionako prevelik "zalogaj" i da kolega Zidar nije uskočio i preuzeo voditi realizaciju ove baze vjerojatno bi i odustao. Ovako uz vas iskusnije ako uspijem realizirati ovaj projekat biti će super, a ima šanse dogurati do kraja, što za nivo Poduzeća ne mogu garantirati.



Kako se u subformu ubaci ovakav zadnji red sa slike???

_{[Ovu poruku je menjao dzaga29 dana 31.01.2013. u 07:51 GMT+1]}

Uspeo sam da nekako prevedem opstu shemu u Access. Jos nisam potpuno zadovoljan, ali evo bar nesto.

Popunio sam tabele na finsnijskoj strani, i nesto malo na strani ugovora. Sa izvodjackim ugovorima imamproblem - da li se ugovor potpisuje samo na osnovu javne nabavke, ili moze i bez toga?

Baz je u MDB formi, za Access 2003. AKo ne prolazi u 2007 i 2010, uradite konverziju. Ne mogu da se javim do ponedeljka najverovatnije.

Ugovor sa izvođačem u pravilu se potpisuje ne temelju odabira putem javne nabave. U rijetkim slučajevima ide putem direktne pogodbe. Dakle Javna nabava mora biti.
Moramo unjeti i tablicu djelatnika koji će biti zaduženi za pojedine investicije i pratiti samo stanje investicije ( pod stanjem mislim nešto nalik; ugovoreno, u izgradnji, završeno ili sl. ) kako bi kroz upite mogao na kraju npr. izlistati dovršene investicije ili investicije u izgradnji i sl.
Pozdrav!

_{[Ovu poruku je menjao dzaga29 dana 02.02.2013. u 00:27 GMT+1]}

Smatrao sam za prikladno da promenim naziv teme iako je počela trivijalnim pitanjem.

---

Hvala Getsbi, to je bila prava stvar. Opet ja sa drugim UserID, password koji mi radi na poslu, ne radi kod kuce.

Evo sta imamo sada:
1) iz poslednje (04) verzije izbacio sam nepotrebne kolone, uglavnom iz finnsijskih tabela
2) dodao sam pracenje statusa investicije, na najprostiji moguci nacin, ali neka za sada
3) preradio tabelu IzvodjackiUgovori
4) preradio malo veze izmedju ugovora, pobjednika na javnoj nabavi, javne nabave

Sledi tekst:
- objasnjenje tabele IzvodjackiUgovori i nekih pravila za unos podataka
- pravila za popunjavanje tabele Situacije
- kako radi pracenje statusa

Ugovori:

Za inevsticiju (projekat) broj [InvID], za godinu [ugovornaGodina], na dan [datumUgovora], potpisan je ugovor broj [BrojUgovora] tipa [TipUgovora], sa izvodjacem [Izvrsilac] koji je na javnoj nabavci [JavnaNabava] pobedio; predmet ugovora je [PredmetUgovora], vrednost ugovora je [UkupniIznosUgovora]; sam dokument smo skenirali i sacuvali u poljeu [Datoteka].

Uslovi:
Tip ugovora moze biti EXT, INT, ANX i NDZ. Zavisno od tipa ugovora, polja [Izvrsilac],[Podizvodjac],[BrojUgovora] i [VezaNaUgovorGod] moraju biti popunajen ana odredjen nacin. Ovako:

'EXT = ugovor koji Komunalac sklapa sa izvodjacem, [Podizvodjac] = [Izvrsilac], [BrojUgovora] = [VezaNaUgovorGod]

'ANX', = anex na postojeci 'EXT' ugovora, [Podizvodjac] = [Izvrsilac], [VezaNaUgovorGod] = postojeci EXT ugovor

'INT'= ugovor o izvodjenju montaznih radova, koje EXT izvodjac sklapa sa komunalcem, [Podizvodjac] = 'Komunalac', [VezaNaUgovorGod] = postojeci EXT ugovor

'NDZ' = ugovor sklopljen sa nadzornim organom, da nadzire projekat koji je ugovoren nekim postojecim EXT ugovorom. Izvodjac = 'Nadzodni organ', [VezaNaUgovorGod] = postojeci EXT ugovor



Situacije:
Situacija je racun (invoice) koji izvodjac radova podnosi komunalcu. Obicno s epodnosi jednom mesecno, poslednjeg daa u mesecu, za radove izvresene u datom mesecu. U mesecu u kome se zavrsavaju radovi podnosi se 'Zavrsna situacija'. Sve ostale situacije su 'Privremene'. Za jako kratke projekte, podnosi se amo jedna situacija - zavrsna. Posle zavrsne situacuje nema vise podnosenja situacija. Podnete situacije en mogu se menjati, Situacije se moraju unositi u prirodnom redosledu, po datumima na koje se odnose. Ne dozvoljava se da se posmatrani projekat unese prvo situacija za MArt, pa onda za Januar ili februar. Mora ici redom - Januar, februar, mart. Izmene iznosa su dozvoljene za poslednju unetu situaciju, dok s ene unese nova situacija. Posle toga izmene unazad nisu dozvoljene. Tabela Situacije napravljena je tako da se iskazana pravila moraju postovati.

Pravila unosa u tabelu Situacije:
Sva polja su obavezna.
BrojUgovora - prenosi se iz tabele IzvodjackiUgovori
RB = 1 za prvu situaciju, raste za 1 za svaku sledecu
DatumSituacije = sloboda nunos, mora biti veci od datuma prethodne situacije
VrstaSituacije = 'privremena' il 'zavrsna'
UkupnoDoSada = zbir zinosa svih prethodnih situacija plus iznos ove situacije.
Za prvi unos, UkupnoDOSada = IznosSituacije
IznosSituacije = iznos na situaciji
RbPre = Vrednost RB u prethodnom rekordu, RbPre = Rb-1. Za prvi unos, RbPre = Rb = 1
DatumPre = datum iz prethodnog unosa, za prvi unos DatumPre = DatumSituacije
UkupnoPre = vrednost UkupnoDoSada iz prethodnog unosa. Za prvi rekord UkupnoDoSada = IznosSituacije
VrstaSituacijePre = vrsta situacije u prethodnom unosu. Za prviu unos, VrstaSituacije = VrstaSituacijePre, i moze biti Privremena = privremena ili Zavrsna = Zavrsna.
Ne moze postojati ni jedan rekord gde je VrstaSituacijePre = 'Zavrsna' i VrstaSituacije = 'Pocetna'

Rekapitulacija pravila unosa za pocetnu situaciju za posmatrani projekat:
BrojUgovora = ugovor za koji upisujemo situaciju
Rb = 1
DatumSituacije = slobdan unos
IznosSituacije = slobodan unos
UkupnoDoSada = IznosSituacije
VrstaSituacije = 'privremena' il 'zavrsna' (Zavrsna je kad je prva situacija i jedina situacija, desava se za male projekte)
RbPre = 1 (= Rb)
DatumPre = DatumSituacije
UkupnoPre = IznosSituacije
VrstaSituacijePre = VrstaSituacije

Za svaki sledeci unos (situaciju) za posmatrani projekta:
BrojUgovora = ugovor za koji upisujemo situaciju
Rb = 1+RbPre (1+iz prethodnog rekorda (1,2,3,4...))
DatumSituacije = slobdan unos, veci od DatumPre
IznosSituacije = slobodan unos
UkupnoDoSada = IznosSituacije + UkupnoPre
VrstaSituacije = 'privremena' ili 'zavrsna'
RbPre = Rb-1 (= Rb iz prethodnog rekorda)
DatumPre = DatumSituacije iz prethodnog rekorda
UkupnoPre = UkupnoDoSada iz prethodne situacije
VrstaSituacijePre = VrstaSituacije iz prethodne situacije

Ova kompleksnost se veoma lako sakriva kodom, pa korisnik aplikacije samo unosi nove vrednosti, on ..Pre i ne vidi. Imam kod u verziji sa 2007, pa cu ga u sledecoj iteraciji ubaciti.

Kako radi precenje statusa
Statuse ima smisla pratiti samo u toku pripreme i izgradnje, i to one aktivnosti koje nismo pokrili tabelama u bazi.
Nema svrhe unositi statuse "Investicija usla u okvirni sporazum", "Ugovoreno", "naplaceno" jer za sve to postoje tabele sa podacima.
Ako postoji rekord u tabeli ProjektiUSporazumu za odredjeni projekta, onda smo dostigli stanje "usao u sporazum".
Ako postoji rekord u tabeli JavneNabave, onda smo dostigli status "Raspisana javna nabava"
Ako imamo rekord u tabeli "PobkednicNatjecanja", onda smo dostigli tu fazu.
Ako imamo rekord u tabeli Ugovor, onda smo dostigli i tu fazu.

Statuse ima smisla pratiti kad pocne izvodjenje, da mozemo reci na primer ovo:

Priprema:
InvId = 1, DatumStatusa = 1 Feb 2011, Status ="Zpoceta Priprema", Opis = "Narucena projektna dokumentacija, Teh projekt Rijeka"
InvId = 1, DatumStatusa = 25 Maj 2011, Status ="Priprema u toku", Opis = "Dokumentacija prosla reviziju"
InvId = 1, DatumStatusa = 30 Juni2011, Status ="Priprema u toku", Opis = "Dobijene saglasnosti od Elektro distribucije"
InvId = 1, DatumStatusa = 1 Feb 2012, Status ="Zavresne Priprema", Opis = "Dobijena gradjevinska dozvola"

U medjuvremenu smo raspisali javni natjecaj i odabrali izvodjaca. Onda sledi izvodjenje:
InvId = 1, DatumStatusa = 1 April 2012, Status ="Zapoceti radovi"
InvID = 1, DatumStatusa = 30 Juni 2012, Status = "Radovi u toku", Opis = "Postavljene cevi do stacionaze 1500"
InvID = 1, DatumStatusa = 30 Juli 2012, Status = "Radovi u toku", Opis = "Postavljene cevi do stacionaze 3500"
InvID = 1, DatumStatusa = 6 Aug 2012, Status = "Zastoj", Opis = "Kliziste na stacionzis 3700"
InvID = 1, DatumStatusa = 16 Aug 2012, Status = "Radovi u toku", Opis = "Sanirano kliziste, ponovo radimo"
InvID = 1, DatumStatusa = 30 Aug 2012, Status = "Radovi u toku", Opis = "Zavresna proba na pritisak"
InvID = 1, DatumStatusa = 30 Sep 2012, Status = "Radovi u toku", Opis = "Zavrsen prikljucak na glavni dovod"
InvID = 1, DatumStatusa = 30 Sep 2012, Status = "Radovi zavrseni", Opis = "Izvrsena primopredaja cevovoda"

Uneo sam koliko sam mogao podataka u tabela, i gd eje bilo zgodno stavio sam lookup na kolone za laksi unos. Kolone sa lookupima i dalje pokazuju stvarne vrednosti (sto nije uobicajeno), tako da to nece smetati kverijima.

Imate materijala za nekoliko dana. prethodne verzije su bile prilicno nemoguce za rad i unos test podataka. Verzija 05 je malo laksa. U 06 cu dodati kod za olaksani unos situacija. Mislim d aima dovoljno materijala za celu sedmicu.

Srecno

Šta reći na ovo, osim pohvaliti?

Ako mogu primijetiti ovo: u tablici Uposlenici, ima vanjski ključ RadnoMjestoID koji bi trebao biti iz tablice Radna mjesta, a te tablice nema, tako da nemamo ni radna mjesta za pojedinog uposlenika. Nije toliko ni bitna u ovoj fazi, ali eto samo da pokažem da pratim materiju :)

Htio bih pitati za tablicu Pravila i dbo_Calendar.

Pravila - gdje se mogu pronaći primjeri kreiranja pravila za noobove, kako bismo mogli ovo upotrebljavati ubuduće, jer mi se čini jednostavnije postaviti neka pravila u tablicama, nego kasnije prtljati po kodu.

dbo_Calendar - kako uopće kreirati ovakvu neku tablicu, i kako najlakše editirati npr. da je svaka subota osim praznika radna, odnosno kako neke datume koji su neradni u klasičnom smislu npr. 01.01. najjednostavnije staviti na neradne. Da li to raditi preko Update query, odraditi jednom i to je to (znam kako npr. za svako 1.5. staviti NO, ali za subote ne znam), ili se može pri kreiranju ovakve tablice na početku nešto odraditi.
Također, za šta će nam ova tablica služiti kasnije konkretno? Pretpostavljam da će biti vezano uz datume situacija i slično ali me zanima razlika upotrebe od klasičnog tipa podatka date/time i ovoga.

Ovo sa Statusima mi se jako sviđa, gdje se može pratiti izvođenje radova, i tražiti izvješća od odgovorne osobe u pojedinim fazama, pa onda to uspoređivati sa dinamičkim planom.

Htio bih reći i ovo, na pojedine tendere se zajednički često prijavljuje nekoliko firmi kao konzorcij. Jedna firma je uvijek nositelj projekta i ona ispostavlja situacije prema investitoru, dok ostali članovi konzorcija ispostavljaju svoje situacije prema nositelju projekta. Investitor novac prebacije samo na nositelja projekta, dok nositelj prebacuje na ostale članice konzorcija.
Često se događa da zbog financijskih problema kojih smo svi svjesni, situirate jedan iznos, a investitor ili nositelj projekta vam prebaci manji iznos, jer para nema, more bit bidne, ali sada nema.
Možda ne bi bilo loše postaviti tablicu uplate, da se u nju unosi koliko je kada leglo na račun, tako da se vidi da je situirano milion nečega, u godinu dana, na to plaćen porez, a prebačeno vam 50 000 nečega te da možete reagirati. Pretpostavljam da je to sada priča vezana za porširenje cijele aplikacije, ali ako se već ima podatak o odrađenom poslu, ne bi bilo loše u istoj bazi imati podatak i o naplaćenim iznosima.


_{[Ovu poruku je menjao thenoise dana 05.02.2013. u 23:50 GMT+1]}

@thenoise hvala za pohvae :-), i mnogo je dobrih zapazanja u tvojoj poruci. Da odgovorimo na zapazanja:
Interesantno kakao inzenjer uvek ima dobro zapazanje :-) Naravno da je lakse postaviti pravila na tabelama nego petlajti po kodu. Problem je sto 90% programera to razume i ne vide u cemu je problem jer njima programiranje nije problem - pa to je ono za sta su palceni, ne? Pravi nacin razmisljanja je 'treba programirati korisne stvari, a ne gubiti vreme na ono sto s emoze postici bez programiranja'. Naravno, ne mogu bas sva pravila da se postave na tabelama, mora nekad i kod da se pise. To ne znaci d atreba UVEK pistai kod i potpuno zanemariti pravila na tabelama.

Elem, tabela sa pravilima nazalost nije doe sistema za uspostavljanje pravila. Tu sam mislio da drzim pravila prevedana na jezik koji ljudi mogu d a razumeju. Pravila su zapisana u table properties, u vidu logickih izkaza koji povezuju kolone (polja) u tabeli. Na primer, kad hocu da kazem "Ako je tip ugovora = 'EXT' onda mora biti BrojUgovora = PozivNaUgovor" to zapisujem kao Tabela tblPravila sadrzla bi tekst pravila iskazan prirodnim ljudskim jezikom (srpski, hrvatskim, bosanski, federacisjkim, slovenackim, makedonskim, i ostalim jezicima bivse Jugoslavije) . U table properties za tabelu Ugovori upisan bi bio ovaj NOT.. OR matematicki iskaz.

Dobro zapazanje. tabela Uposlenici je tu samo kao primer, mnogo toga treba da se doda, zavisno od lokalne situacije. To ostavljamo svakom ponaosob ko bude razvijao sistem na osnovu ponudjene okvirne sheme.

Tablicu Kalendar mozes kreirati u Excelu, pa prebaciti u Access. Onda koristis UPDATE ili direktan unos da podesis sta ti treba. Posto to sve radis samo jednom, svejedno je kako ces to da uradis. Izmene su moguce i kasnije. Do sada nismo koristili ovu tabelu, ali posto je opste korisna, stavio sam je bazu.

tacno, to je to. Steta je sto se ne mozemo direktno povezati sa naprimer MS project. Medjutim, ako je dinamicki plan iole stabilan (ne dodaje nove aktivnosti) mozda bi mogao da uvezes dinamicki plan kao tabelu. ili skup tabela, pa je to dostupno bazi. Problem je kad se promeni dinamicki plan, da se te promene odrade i u Access bazi. Ali, to nije tema ovog projekta.

Pazi, ova baza se radi da pokrije potreba Komunalca. Komunalac placa konzorcijumu i bas ga briga kako ce konzorcijum da podeli pare. Komunalac ne prati situacije koje clanovi konzorcijuma podnose nosiocu posla. Ako se i to zeli - moze. Ubacis sve clanove u tabelu izvodjaca i tretiras ih kao INT ugovore (na isti nacin kao sto tretiras situacije koje Komunalac podnosi izvodjacu)


Ovo je moguce dodati, to je onaj donji levi cosak sheme, koji tek treba da se razvije. medjutim, ponovo imamo problem duplikacije podataka. Podaci o uplatama postoje negde u firmi, valjda su svi knjigovodstveni sistemi vec automatizovani. Ovo znaci da nas referent koji prati investiciju, mora nekako od knjigovodstvene sluzbe da dobije podatke o uplatama i sam da ih unosi i ovu nasu bazu. To znaci da ti podaci nece biti ni tacni ni azurni. posto s ene garantuje ni tacnost ni azurnost, mozda je Excel bolje resenje?

Hvala na zapazanjima i pohvalama :-)

Ja ću krenuti od kraja prema gore.

Dupliranje podataka - cilj svake baze podataka i aplikacije koja njome upravlja i koristi podatke iz nje je integriranost, odnosno unošenje određenog podatka samo jednom, i u daljoj upotrebi samo iskorištavanje tog podatka. Tako i kod ovog "lijevog ćoška šeme", za koji smatram da ukoliko će se ova ideja od dzaga29 razvijati i dalje treba odmah pretpostaviti i pokušati to razviti kao samostalnu aplikaciju na koju se može "zalijepiti" neka od rješenja za financijsko knjigovodstvo koje se mogu naći na ovom podforumu.

To govorim iz razloga, što je ranije građevinska situacija bila dovoljna po zakonodavcu za knjiženje. Pojavom fiskalizacije kod nas u BiH, uz svaku situaciju je potrebno uspostaviti i fiskalni račun. Zbog ograničenja fiskalnih kasa, i printera na broj znakova po svakom artiklu, bilo je potrebno nabaviti i aplikaciju za fiskalni uređaj, gdje se može napraviti da izbaci cijeli račun u jednoj stavci, a uz fiskalni račun se prilaže i faktura, na kojoj su stavke pojedinačno. I evo ga, već smo kod dupliranja unosa.
Isto tako, kada mi vrijednost situacije unesemo jednom u ovu bazu koju sada razvijamo, isti podatak se mora unijeti još minimalno jednom u aplikaciju za financijsko poslovanje. Opet se duplira unos. Tako da dok firma nije u stanju kupiti ili napraviti neko custom rješenje za svoje potrebe, dupliranje unosa postoji.

Konzorcij sam spomenuo iz istog razloga i mišljenja da bi trebalo staviti tablicu uplate, odnosno "lijevog ćoška". Evo jedan od primjera: imamo ugovor sa nekim da kao izvođač izvedemo radove u vrijednosti 100. Za tog investitora smo do sada izveli 99 ali nam on ne plaća ništa već pola godine. I imamo drugog investitora za kojeg isto imamo ugovor 100, izveli smo 90 i platio nam je 85. Treba odlučiti koji prije završiti.

Kod situacija, odnosno kod dijela kada se potpiše Ugovor, u ovisnosti o Ugovoru, postoje i stavke o avansu, te vrijednosti zadržanog novca za garanciju izvođenja radova. Avans je najčešće 10%, a zadržani novac za garanciju je, barem kod mene 3-5%. Avans i zadržani novac se od situacija odbija u istom postotku kolika mu je vrijednost. Ne bih Vas htio previše gnjaviti sa ovim, ali možda bi trebalo i ovo uzeti u razmatranje.

Ovo sa statusima se može koristiti u praćenju dinamičkog plana koji je zadan i npr. je već kod šefa građenja na zidu negdje. Ukoliko se prilagodi baza višekorisničkom sučelju, šef se logira, vidi statuse pored pojedinih projekata, usporedi ih sa dinamičkim planom na svome stolu ili zidu, i onda poziva odgovornu osobu za gradilište na raport.

dbo_Calendar - mislim da je zgodno ovako uspoređivati datume, a kako će se konkretno primijeniti još trebam vidjeti :)

Pravila nad tabelama se pišu koristeći klasične logičke operatore, ili Access ima svoja neka pravila? Pitao sam za link na neke primjere ako imaš iz rukava, samo da vidim koja se sintaksa smije koristiti.

I da završim sa svojim pametovanjem... :)

Pošto si odradio ogroman dio posla i hvala ti na tome još jednom, a ima nas sigurno i više zainteresiranih za ovakvu temu, interesira me šta ti očekuješ od nas da napravimo i da li ćeš ti biti ljubazan skupa sa nama odrađivati forme, reporte, odnosno upeglavanje ovoga do nekog mogućeg kraja?

Zasto smo stali? Nema vise pitanja ili se vredno radi na pravljenju programskih modula koji ce da opsluzuju ovakvu bazu? Ili je tema postala neinteresantna?