Upravljanje investicionim projektima

Zidar malo me obeshrabrilo; ali u svakom slučaju se slažem što si konstatirao.

Ja sam čitavu bazu zamislio da se sve bazira na PROJEKTU ( INVESTICIJI ) za koju se kasnije vežu i Javne nabave i Ugovori i Situacije. Tako sam i nazvao bazu: "Investicije i projekti Komunalca d.o.o. Delnice". Sama aplikacija na Glavnoj formi ima prikaze upravo projekata ( graf i tabelarni popis ) te se klikom na pojedini projekt ( hiperlink ) otvara forma Detalji projekta gdje sam mislio imati sve podatke prikazane za pojedini odabrani projekat kroz više tabova ( Osnovne detalje o projektu, Detalje o ugovorima, Detalje o situacijama ) a u podnožju forme izračunate vrijednosti trenutnih stanja za pojedine projekte. Pošto sam početnik u Accessu vjerojatno sam zabrljao sa relacijama i sa unosima podataka u tabele. Na upitu sam namjerno unjeo izvođača jer nisam znao povezati Projekat ( koja bi meni trebala biti, kako sam gore naveo, glavna tabela ) i Javnu nabavu koju sam naknadno unašao.
Dok se sve ne raspetlja ja i dalje koristim postojeću bazu u 2010 kako bi mogao puniti tablice sa podacima.
Apeliram da otvoriš reporte iz ove moje baze i na reportima Bilanca stanja, Javna nabava, Sklopljeni ugovori i Situirani radovi vidiš što bi želio u konačnici. Nadam se da se drugi forumaši neće ljutiti što forsiram da se sve bazira na PROJEKTU, ali mi u firmi na takav način pratimo određene investicije. Ponovno napominjem da su podaci u bazi realni i stvarni.
Pozdrav!

Davore ne brini. Sve ce se raspetljati kako treba. Dobro je sto smo dobili program koji pokazuje kako u stvari zelis da se cela stvar odvija. I dobro je da sad imamo podatke koje mozemo uneti u 'novu' shemu, za koju mislimo da ce vljati (nadamo se ). I dobro je da imas reporte koji u ovom momentu pokazuju sta se hoce i izgledaju kao da rade. Treba mi smao malo vremena da sve rasporedim gde treba, za koji dan bice sve gde treba, povezano u tabelama i kverijima. Onda mozes da krenes i da svoje forme nekako povezujes s tom novom strukturom.

Blizu smo, strpi se samo za trenutak i sve ce biti OK.

Houston, we have a problem. Izgleda da moj Acces ima problema sa YU slovima.Kad uklonim sa formi kontrole koje se zovu na primer "Datum početka ugovora" i "Datum završetka ugovora", "Izvođač" onda sve radi. (Za izvodjaca sam ja kriv, Davor lepo kaze "Izvoditelj" )

Sve dok imamo č, š,đ i slicno, dobijam ActiveX control gresku. Bez obzira so Microsoft prevodi Access na bivse jugoslovenske jezike, to nece moci da radi. Ja cu da pocistimnazive koliko mogu, ali molim te da na tvojoj strani pocistis sve nazive tabela, formi, kevrija koji u sebi sadrze:
1) bilo sta od jugoslovenskih slova
2) znakove razmaka
Access jednostavno odbija da radi ako su razmci i nasa slova prisutni u nazivima objekata. labele su verovatno OK, ali nazivi objekata (tabele, kveri, polja u tabelama) nisu izgleda prihvatljivi.

Osiam ako neko iam neki savet kako uklopiti Access sa YU znacima?

Kod mene sve radi, ali normalno sam prije toga instalirao 'Office 2010 Croatian Language Pack' koji sam downloado sa interneta. Međutim ja ću bez problema počistiti naša slova i nazive napisati bez razmaka.
Međutim ne razumijem zašto ste svi vjerni Accessu 2003 i 2007, kada 2010 bez problema sve radi i ima više mogućnosti a posebno kod pisanja formula ( IIf i dr.). Posebno što možeš podesiti da li želiš 2000-2003 ili 2007.
Pozdrav!

Evo malo sam prepravio relacije u poseldnjoj verziji koju je Davor zakacio. Sutra cu da objasnim sta nije valjalo, i sta je ostalo da ne valja jos uvek (ili je nejasno) u Davorovoj verziji. Moja verzija je .MDB, ali ako je otvorite u 2007 ili vise, trebalo bi da rade split forme i anchoring za kontrole, automatski. Prosao sam kroz sve tabele, uklonio YU znakove, uklonio razmake i u nekim slucajevima sinhronizovao nazive kolona (Ssad se zove projektID svuda). To su mehanicke stvari. Logicke stvari cemo da raspravimo sutra (razdvajanje izvodjackih ugovora od finansijskih ugovora, razjasnjavanje polja Vrijednostprojekta i UgovorenaVrijednost koje nalazimo svuda, u Projekti, Ugovori, javne NAbave i kojekuda jos).

Zidar, pokrenuo sam tvoju prerađenu bazu i to je to što sam bio zamislio.
Ali, u Formama i Reportu:Bilanca stanja ima dosta nelogičnosti - ne znam da li su to stvari koje si mislio kada si napisao:

Tako imamo slučaj da imaš polje 'Zbir svih ugovora potpisanih za projekat' koje je doslovno zbroj svih ugovora što nije u redu. Sa tom logikom za svaki projekat imat ćemo vjerojatno da je iznos ugovora prekoračen. Pravilo je ako je za neki ugovor ugovorena vrijednost npr. 100.000,00 onda se iz tih novaca plaća glavni izvođač svih 100.000,00 kn za završene radove, a taj izvođač za monterski dio radova plaća npr. 54.000,00 kn ( SVOJE KOOPERANTE ) - u tom slučaju ne možemo prikazati da je ugovorena zbirna vrijednost od 154.000,00 kn pošto to jednostavno nije tako i taj podatak nam nije uopće bitan. Vrijednost projekta je uvijek Ugovor sa izvođačem ( tj. vrijednost dobivena putem javne nabave ) i ugovor za nadzor.
IZNOS UGOVORA PREKORAČEN je samo u slučaju kada su situacije IZVOĐAČA + NADZORA veće od ubovorene vrijednosti. Uostalom kada riješimo stvari iz citata onda ću dati primjedbu jer se one odnose samo na izračunata polja.
Pozdrav!

Samo kratko, za trenutak, malo kasnije napisacu vise:

Odlicno, ovo je vazno, nisam o tome mislio. To cemo lako ispraviti, kad rascistimo one silne vrednosti posvuda.

Ono sto sam rekao da treba da raspravimo stoji i dalje, za koji sat cu to imati. Sad imam neku 'emergency' ovde na poslu, za jedno 5-6 sati od sada javisu se ponovo.

Pozdrav

Da vidimo sta sam razume, a sta ne. Gledajuci u podatke i shemu tabela, vidim da imamo polje UgovorenaVrijednost
u tabeli Projekti.UgovorenaVrijednost. SLicnio imamo u JavnaNabava.Vrijednost. U najvecem broju slucajeva je Projekti.UgovorenaVrijednost = JavnaNabava.Vrijednost, ali ne uvek. Ima slucajeva kada imamao vise od jedne Javne Nabave za isti projekat. Tada vazi Projekti.UgovorenaVrijednost >= SUM(JavnaNabava.Vrijednost).To cemo d aostavimo tako. Bilo bi lepo da se kontrolisu ovi uslovi, ali pretpostavljam da nije problem da se nekako 'garantuje' da je to OK.
Neka stoji kako stoji.

Pretpostavio sam da se za izvestaje uzima vrednost iz Projekti.UgovorenaVrijednost.Da li je ta pretpostavka tacna?

Za svaku Javnu Nabavu, trebalo bi da postoji i jedan rekord u tabeli Ugovori. Ovo je komplikovano da se postigne, ima u modelu koji smo postavili ranije, ali nije neophodno za sada. Mnogo je vzanije da SVAKA situacijaima ugovor. Vezivanje situacije na Projekat, bez ugovora, moze da prodje, ali je cistije mnogo ako se veze na ugovor.

Ja sam pokusao da povzem ugovore i situacije, i uspelo je za sve osim nekoliko. Situacije vezane za Projekte 17,14 i 10 nisam mogao da spojim s augovorima, jer u tabeli Ugovori nema ugovora za te projekte, ni jednog. Ako to dodas, mnogo tga ce biti lakse. Ovaj kveri radi na tvojoj bazi i pokazuje situacije za koje nemas ugovore:


Sto se tice izracunavanja na Bilanci, to se asniva na dve pretpostavke:
1) Vrednost projekta ce cita iz Projekti.UgovorenaVrijednost ili SUM(JavnaNabava.Vrijednost), sta je bolje?
2) Protiv toga se postavljaju samo ugovori koji su tipa "Izvodjenje" ili "Nadzor",
Znaci, Projekti.UgovorenaVrijednost >= SUM(Situacije WHERE TipUgovora IN ("Izvodjenje","Nadzor")

Tu ima jedna problem. Na tvojim izvestajima, ti oduzimas samo IZvodjenje, nadzor ne oduzimas. To je mozda namerno, a mozda je rezulat cinjenice da si sumu siturianih vrednosti stavio u HEADER sekcije TipSituacijeID, pa ti slucajno cita samo prvu TipSituaciejID, koji sasvim slucajno je "Izvodjenje"

Ovde imamo cudnu stvar, da se TipUgovora i TipSituacije uglavnom poklapaju(opisi se poklapaju, ne i kodovi), osim za tipove ugovora 1 i 7. To govori da ugovori tipa 1 i 7 i ne treba da budu u istoj tabeli sa ostalima, ali ako insistiras, neka ih i tamo. Time smo kverije napravili komplikovanijim, ali nema veze. Ugovori tipa 1 i 7 ne rezultiraju Situacijom, svi ostali rezultiraju situacijom - prema tome, to nisu isti ugovori, nisu iste vrste, i zgodno bi bilo orazdvojiti iha, ali neka stoji.

Moja verzija 04 sabira "Izvodjenje" i "Nadzor" pa taj zbir uporedjuje sa Projekti.UgovorenaVrijednost. Tako si tikazao, ali tako nisi uradio na bilanci. Malo sam prepravio relacije. Dodao sam kolony 'Vazi se' u tabelu TipUgovora, cekirano je za Izvodjenje i NAdzor, za sve ostalo nije.To ide u kverije qryZ_BilancaStanja i qryZ_ProjektiIUgovori od kojih s eposle sve gradi. Verovatno kveriji mogu da s enaprave tako da vaze i za druge tipove ugovora, pa da se pred upotrebu odbaci sto ne treba ali dnas nemam vise vremena.

Sve u svemu, mozes da zadrzis sto si napravio, ako moras. Ako imas vremena da ponovo pokusas, milsim da je bezbednija varijanta strujtura baze u mojoj verziji 04. Sve podatke sam prebacio iz tvoje posledne MDB verzije, pa brem podatke ne gubis. Budi oprezan sa MIcrosoft wizardima i template resenjima, cesto lepo izgledaju, ali ne rade bas kako treba.



Imas u
tabeli JavneNabave polaj za datume, koja se ti text tipa.

Što se tiče Javne nabave sve si dobro razumio. Za jedan projekat može biti više JN, npr. kada se sklapa anex.
DA.
Ovdje se javlja problem; Imam slučajeva kada se naknadno sklapa ugovor i situacije se ispostavljaju po par mjeseci ranije i ne mogu ih vezivati za ugovor. Sada ću ispasti neskroman, ali jedan zahtijev; kako si mogao vidjeti iz podataka ja sam zadužen za Projekat Stara Sušica i Brestova Draga te preko njih testiram bazu. Kod Projekta Stara Sušica imamo tri godišnja ugovora izvođača (br.29,4 i 3) kada na formi kliknem na + uz ugovor 29 prikažu se sve situacije izvođača za projekat, ali uz ubovor br. 3 i br. 4 nema rekorda. Da li je moguće vezati npr. situacije iz 2011. godine na ugovor br. 3, iz 2012. na ugovor br. 4 i iz 2013. na ugovor br. 29. Znam da kompliciram ali bilo bi točnije i bilo bi idealno.
Dalje, u subformi 'lstSituiranoPoVrstamaRadova' sada nema monterskih radova što nije dobro, ja sam mislio da se oni samo ne zbrajaju u čelijiji 'Ukupno situirano po svim vrstama radova:' a ne u subformi ( trebalo bi dva upita) jer sada nemam uvida na monterske situacije i nigdje ih ne pratim, a za njih imam ugovor. Ne vidim ih niti u Reportu: Bilanca stanja za projekat.
To je bilo namjerno, jer vrijednost investicije nije sadržavala i vrijednost nadzora, ali za to se ne brini jer na formi vidim vrijednosti. Doduše bilo bi bolje da umjesto polja 'Zbir svih ugovora potpisanih za Projekat:' na formi imamo polja : Ugovor za izvođenje ( Zbir ugovora 3 + 4 + 29) pa polje Ugovor za Montažu ( Zbir ugovora 9+28) i polja Ugovor za Nadzor ( broj 24 ) i tek onda Ukupno.
Nemam ništa protiv, meni jedino treba podatak da imam uvid u te ugovore. Ako je bolje da budu posebno nemam ništa protiv.
Pozdrav!

Evo mene opet; Zidar u bazi tabele 'RadoviZaIzvodjenje' i 'UobicajeniRadoviZaIzvodjenje' meni ne služe ničemu i one su ostale samo zato jer Zaposlenika nisam znao povezati sa Projektima ( takva veza je bila iz predloška i ako bi ih obrisao baza više nije radila ) tako da bi bilo dobro da se te dvije tabele izbace. Doduše vidim u relacijama da si tabelu 'UobicajeniRadoviZaIzvodjenje' već izbacio. Na koji način da ažuriram podatke iz moje baze a da ne poremetim relacije i nazive iz tabela koje si ti postavio.
Pozdrav!

Sad smo u situaciji koju sam opisao na samom pocetku - taman kad pomislimo da smo nesto uradili, shvatimo da to nije bas to. Dobro, nije bas to, ali je blizu :-)


Javne nabave za sada mozemo potpuno da zanemarimo. Ni jedan kveri ih ne uzima, kaod a nam ni ne trebaju. A ni ne trebaju nam, situacjie se vzu ili za ugovor ili za par (projekat,izvodjac), mozda i (Projekat, IZvodjac, Godina). Zato cemo ih zanemariti. Javne nabave postaju interesantne kad treba da se cuve text oglas, gde je sve oglaseno, ili kome je polsat zahtev za ponudu, ili ko je sve podneo ponudu, sta je radila komisija, ko je izabran i slicno. To je sve inteersantno, ali ne utice na pracenje situacija. Neka zato ostane za posle, kao nezavistan modul.



Ovo je malo nezgodno. Ugovor nama u bazi nije bitan sa pravne tacke gledista (kakao ces isplacivati nekom novac ako nemas na osnovu cega)
. Nama je bitno da vezemo situaciju za NESTO, a najlakse je za izvodjacki ugovor.Razmisljao sam o razlicitim opcijama, ali se bez ugovora ne moze. Zato predlazem da ako nemas ugovor jos uvek, uneses neku izmisljenu oznaku za Broj Ugovora, na primer "NEDOSTAJE UGOVOR 00027" gde bi ti brojcani deo cinio oznaku jedinstvenom. Onda lepo stavimo Foreign Key (relationship u Accesu) sa tabele Ugovori na tabelu Situacije i stavimo UPDATE CASCADE (nikako DELETE CASCADE). kad se otpise stvarni ugovor, onda u tabelu Ugovori ono "NEDOSTAJE UGOVOR 00027" zamenimo pravom oznakom, na primer "UG IZV 2012/56 ". Zbog CASCADE UPDATE ta ce se vrednost bezbolno preneti u tabelu SItuacije. Problem s ovim je da se ne promeni oznaka ugovora nenamerno, ali za sada neka bude ovako. Ne menjas stotine ugovora svakog dana, pa da se provuce nehoticna greska. Ovo bi radio nekoliko puta godisnje, i onda je moguce biti pazljiv. Znaci, za ugovore koji ti nedostaju, izmisli privremenu oznaku i ona neka stoji dok ne dobijes pravu. Time smo formalno zadovoljili pravilo baze podataka. Vazna pretpostavka ovde je da svaki ugovor iz koga slede situacije, vazi za tacno jednu godinu (fiskalnu ili kalendarsku, svejedno)

Ovo cu razmotriti u posebnom postu, moram da pogledam.

I na ovo cemo da odgovorimo u posebnom postu, treba da pogledam, ali nece biti komplikovano. A i zaposlenike verujem da mozemo vezati direktno na ugovor.

Upravo zbog toga, ja sam mislio da osnov bude projekat ili investicija, ali normalno onda situacije ne mogu vezati niti za ugovore niti za godine i opet se javlja problem. Ako otvoriš Report:Bilanca stanja za npr. Staru Sušicu kod Izvoditelja imaš 8 privremenih situacija i one su redom P-1,P-2 do P-8 (zadnje oznake) i ako nisu poslagane po redu javlja se problem jer ispada da je npr. P-1 500.903,51 kn a u stvarnosti je 216.733,00 kn i kumulativi ne prikazuju stvarne iznose; mada je u konačnici matematika u redu. To sam mislio kada sam mislio da se situacije vežu na godišnje ugovore (ili barem da se slažu po datumima od prve do zadnje). To ponovno napominjem da bi razumio da je to stvarno važno, a ne samo iz formalnosti, mada si rekao da ćeš to razmotriti naknadno
Moj prijedlog je da, kako si jednostavno predložio, napišemo BEZ UGOVORA 0001 i dalje rastući.

Ovvde su Situacije vezane na pogresne ugovore.

To sam verovatno ja pobrkao, kad sam vezivao situacije na ugovore. Klik na + pokazuje samo situacije koje pripadaju konkretnom ugovoru 29. , a to su u stvari SVE situacije - jer sam ih sve greskom dodelio ugovoru 29. Klik na ugovore 4 i 3 ne daje nista, sto je takodje pogresno, jer njima nisam ddoelio ni jednu situaciju. A ugovor 29, u stvari ne treba da ima ni jednu situaciju, jer je iz 2013 godine, a radovi jos nisu zapoceli u 2013.

Sad cemo to da ispravimo. U zakacenoj bazi imas kverije koji se zovy ZZZ_qry_SituacijeProj2 i ZZZ_qryUgovoriProj2, koji pokazujeu situacije i ugovore za Staru Susicu. Kad otvorimo ova dva kverija, videcemo kako treba da se povezu ugovori i situacije.

Sta sam uradio:
1. Promenio sam relaciju sa tabele Ugovori na tableu Situcije - dodao UPDATE CASCADE opciju.
2. Odradio sam tri puta update query ZZZ_qry_PoveziSituacijeNaUgovore_Proj2, sa razlicitim vrednostima i WHERE, ovako:
Situacije 2,4,12 su iz 2011 => UgovorID = 3 (Godisnji Ugovor za 2011)
Situacije 13,14,15,16,17 su iz 2012 => UgovorID = 4 (Godisnji Ugovor za 2012 godinu)
Ovi UPDATE sus se automatski preneli na tabelu Situacije, zbog Updae Cascade.

Nema ni jedne situacije iz 2013 (jos uvek je sve pod snegom, ne moze da se radi )

Ovako je izgledalo PRE nego sto sam radio UPDATE:


Ovako izgleda POSLE update:


Ovako izgleda UPDATE query. Pazi da promenis sva tri parametra WHERE (ProjectID, SituacijaID) i UPDATE TO: i UgovorID



Predlazem da pogledas sve ostale situacije, za ostale projekte, koje sam povezao sa ugovorima, verovatno bar neke imaju isti ovaj problem. Koristi gotove ZZZ kverije, samo promeni WHERE i moci ces da sve podesis.

Kao sto rekosmo, za situacije za koje nemas ugovore, izmisli ugovor, staiv Broj = 'NEMA UGOVORA xxxx' gde je xxxx neki jedinstveni broj. Kad se ugovor stvarno potpise, radices UPDATE na tabelu Ugovori:

i taj ce se update preneti i na tabelu SItuacije.

Posle pravilnog povezivanja situacija na ugovore, trebalo bi i kveriji da rade kako treba. Mozda reba malo raditi i na kverijima, tu i tamo, videcemo.

Mislim da smo razresili problem povezivanja (korektnog) izmedju situacija i ugovora.

Ovo je sada super: Ako primjetiš, sve situacije iz 2011. su u zbroju jednake godišnjem ugovoru za 2011. a situacije iz 2012. ugovoru iz 2012. godine. Međutim, ja i dalje nemam situacije za monterske radove u reportu:Bilanca Stanja. Kod njih je isti problem da nisu povezane sa godišnjim ugovorima (ugovori br.9 i br.28).
Kako mi na poslu svakodnevno unašamo podatke u "moju template" bazu dok ne sredimo ovu, zanima me kako da najlakše napravim update podataka, a da ne pobrkam relacije???

Podesio sam malo vecinu kverija, kao i report. Sad smo na verziji 05. pogledaj, ali i pogledaj kako je sta postignuto. Nema makroa, nema programiranja. Sve je kveriju koji je baza za report, grupisanje reporta je vazno, i nekoliko formula na samom reportu. Znam da izgleda ruzno, tu ne mogu nista. Dok sam radio inzenjeriju, imao sam briljantne tehnicare pa se nikad nisam naucio da radaim lepo i pedantno. Moji su bili proracuni i nebulozne ideje a momci i devojke iz tima su stvarno bili graficku obradu projekata podigli na nivo umetnosti.


Lepo, unecemo kao sto smo i ovo dosad. Sad znamo na sta treba da pazimo. Ti budi siguran da si uneo ugovore za SVE situacije, kako smo rekli. Ostalo ce biti lako kad to immamo. Pogledaj na reportu SVE projekte, ima ih nekoliko gde su izbrkane godine. probaj na jednoj kopiji da odradis kverije koje sam pomenuo jutros. to ce ti pomoci da razumes sustinu i pozadinu resenja.

Sam ne vjerujem da sam uspio; za Staru Sušicu sam napravio Update za monterske radove i onda malo za vježbu na projekat Brestove Drage. Sve ide OK.
Report je izvanredan i imam sve podatke koje sam želio, čak i više...Izvrsno.
Doduše, podatke u bazi smo malo pobrkali, ali to je najmanji problem; kada će biti gotovo sve ću provjeriti i u redu!
Pozdrav!

Imam jedan problem kod Reporta, ali samo na jednom projektu od njih 20. Kod prikaza situacija za monterske radove prikazuje prvi red prazan kao da je u tablici situacija - jedino kumulativ prikazuje 0,00 kn. Nije mi jasno zašto, kada kod svih ostalih 19 projekata sve prikazuje ispravno. Gledao sam u tablicu Situacije i nisam našao nikakav problem !!!!
Na slici zaokružen zapis.

Pogledacu. I ja sam primetio isto, samo na drugom mestu, pa sam nekim trikovima na reportu napravio da se ne vidi prazan red. Medjutim, ima jos. Problem je najverovatnije u kveriju koji daje podatke za report - tu s enegd pojavljuje prazan red u odredjenim situacijama. Pogledacu, to ne bi smelo da se desava. Moglo bi da ima veze sa jos uvek ponegd enekorektnim ili nekompletnim povezivanjem na Ugovore. Pogledau, pa cu ti javiti.

Na žalost vraćam nas na poćetak; kolegica Branka zajedno samnom testira bazu i ona je primjetila slijedeće:
kod Projekta br. 1 - Sunger za Nadzor su potpisana dva ugovora ( br. 14 i 15 ) na iznose od 62.800,00 kn i drugi na iznos od 51.700,00 kn. Oba ugovora ima isti Nadzor ili izvođač, i oba ugovora su potpisana u 2012. godini. Na riportu za stavku 'Vrijednost ugovora' prikazuje samo iznos od 62.800,00 kn ( ugovor br. 14 ) umjesto da ih zbroji ( ugovor br. 14 + 15 ) i prikaže iznos od 114.500,00 kn za 2012. godinu. Dakle stavke 'Vrijednost ugovora' moraju biti sumari iste vrste ugovora za istu godinu. Naknadnim pregledom sam vidio da je taj problem na više projekata. To isto pravilo mora zadovoljiti sve vrste radova, dakle, ako je ista godina, isti izvođač - vrijednost ugovora za navedenu godinu je zbroj svih ugovora za tu godinu, koji se potpisao za istu godinu sa istim izvođačem za istu vrstu radova... Prikopčat ću zadnju bazu koju testiram ( Zidar.accdb ) i koju sam već poćeo malo preuređivati, tako da vidiš problem. Ista situacija je kada se osnovni ugovor i anex ugovora potpišu u istoj godini ( projekat 4 i 6 - Hlevci i Manci i Brestova Draga ).
Pozdrav!!!

Šta nedostaje u bazi?

Potpis

Teško je biti direktor a još teže ne biti!?