Računovodstveni softverski paket

Naziv: KOMUNALNO KOTOR DOO

PIB: 02013274

E-mail: direktor@jkpkotor.com

Telefon: 032/325-677

Fax: 032/322-080

Internet adresa: https://www.jkpkotor.com

Adresa: Škaljari bb

Grad: Kotor

Poštanski broj: 85330

-------------------------------------------------------------

OSNOVNI PODACI

Opis predmeta javne nabavke

Računovodstveni softverski paket

TEHNIČKA SPECIFIKACIJA PREDMETA NABAVKE

1. Upravljanje ljudskim resursima (hr) Ovaj modul treba da obuhvata sve radnje vezane za zaposlenog, od unošenja sistematizacije, preko kreiranja rješenja o zaposlenju i praćenje kretanja zaposlenog do okončanja rada kod pravnog lica.

Pored evidencije zaposlenih na redovnom radu, bilo da je na određeno ili neodređeno vrijeme, potrebno je da sistem ima mogućnost unosa, evidencije i obračuna zarada za angažovana lica putem ugovora o djelu. | o Parametri za rad sa programom i mogućnost kreiranja parametara u skladu sa potrebama korisnika -organizaciona struktura (neograničen broj hijerarhijskih nivoa),

-šifarnik radnih mjesta,

-šifarnik zanimanja

-šifarnik stručne spreme

-šifarnik vjeroispovijesti

-šifarnik neradnih dana

-šifarnik tipova rješenja

-šifarnik vrste isplata

o Unos sistematizacije radnih mjesta pravnog lica po organizacionim jedinicama,

- Sistematizacijom se definišu radna mjesta sa stručnom spremom, godinama iskustva i zanimanjem koje se zahtijeva.

o Formiranje početnog stanja zaposlenih (unos biografskih podataka zaposlenih i važećih ugovora o radu),

-biografski podaci,

-Opšti podaci,

-Socijalna podaci o zaposlenom (broj djece, broj članova domaćinstva, riješeno stambeno pitanje, broj članova domaćinstva koji ostvaruju prihode i sl.)

-Kontakt podaci (telefon, email, facebook profil, linked in profil)

-Služba, odjeljenje u kojem je zaposleni raspoređen, u skladu sa aktom o sistematizaciji

-Upload skeniranog ugovora o radu, licence, sertifikata ili nekog drugog dokumenta

o Zasnivanje radnog odnosa u skladu sa zakonskim propisima -Evidencija ugovora o radu (trajanje od-do, broj radnih sati, kojeficijent za obračun zarade-može se preuzeti iz sistematizacije i sl. )

-Vrsta zaposlenja (na određeno, na neodređeno vrijeme, pripravnik, ugovor o djelu)

o Kretanje u službi zaposlenog,

-Potrebno je da sistem ima mogućnost evidentiranja promjene radnog mjesta unutar preduzeća. (raspored na drugo radno mjesto, promjene organizacione jedinice, promjene koeficijenta koji služi za osnov zarade zaposlenog, izdavanja rješena u svim slučajevima izmjene podataka)

-Na osnovu ovih evidencija potrebno je obezbijediti izvještaj sa podacima o zaposlenom sa prikazom njegovog kretanja u službi (od datuma 1 do datuma 2 – računovođa; od datuma 3 do datuma 4 – rukovodilac službe računovodstva ...)

-Štampa ugovora o radu ili ugovora o djelu direktno iz sistema sa usvojenim šablonima

o Praćenje odsustva zaposlenog (datumi od-do, razlog odsustva),

-Plaćeno -Neplaćeno

o Pregled obustava,

o Praćenje godišnjih odmora (datumi od-do),

-Potrebno je da sistem sam obračunava broj slobodnih dana za godišnji odmor na osnovu parametara koji se unesu sa kolektivnog ugovora.

-Kreiranje i štampanje rješenja za godišnji odmor na osnovu usvojenog šablona,

-Kontrola koja sprečava kreiranje rješenja za veći broj dana nego što zaposleni ima na raspolaganju u tekućoj poslovnoj godini.

-Sistem mora imati mogućnost da zanemari dane vikenda, državne, vjerske praznike i porodične praznike (na osnovu Zakona o radu) prilikom kalkulacije slobodnih dana za godišnji odmor.

o Sistem mora posjedovati karakteristične izvještaje kao na primjer:

-Kvalifikaciona struktura zaposlenih

-Starosna struktura zaposlenih

- Polna struktura

-Zaposleni po vrsti zaposlenja

-Zaposleni sa podacima o koeficijentima

-Podaci o ukupnom broju zaposlenih, broju zaposlenih određene stručne spreme, starosti, pola

-Izvještaji moraju biti parametrizovani u zavisnosti od izvještaja (na dan, u periodu, za organizacionu jedinicu i sl.)

-Izvještaji moraju biti dostupni u PDF, Excel i Word formatu | 1 Paket

2. Upravljanje finansijama i računovodstvo Aplikacija za upravljanje finansijama mora da funkcioniše u skladu sa važećom zakonskom regulativom i računovodstvenim standardima. Aplikacija mora da prevenira mogućnost izmjene na obrađenim i proknjiženim dokumentima, to jest da omogući ispravke grešaka putem storniranja dokumenta kada ostaje vidljiv trag o postojanju i poništenju dokumenta. Storniranje dokumenta podrazumijeva dodavanje istog dokumenta sa negativnim predznakom čime se stanje dovodi na nulu po tom osnovu. Storniranje dokumenta mora da prati komentar korisnika sistema koji je izvršio storniranje. Storniranje dokumenta mora da bude kontrolisano dodjeljivanjem korisničkog prava za ovu poslovnu funkciju, to jest, nemaju svi korisnici pravo da storniraju dokument.

Aplikacija mora da omogući paralelan rad stare i nove poslovne godine bez potrebe izlaska iz jedne godine i ulaska u drugu godinu. Na primjer, potrebno je omogućiti jedinstvenu karticu komitenta za nekoliko godina, to jest period koji preklapa više od jedne kalendarske godine. Na isti način je potrebno omogućiti pregled bilo koje analitičke ili sintetičke kartice konta.

S obzirom na organizacionu šemu preduzeća Komunalno Kotor DOO, to jest postojanje područnih jedinica potrebno je omogućiti da se pojedine funkcije ovog modula koriste u samim područnim jedinicama, a pojedine funkcije samo u centrali što se definiše samo pravima pristupa. | o Kontni okvir -Konto (ne smije biti ograničenja u broju karaktera konta)

-Naziv

-karakter konta (bilansno, profitno, vanbilansno i devizno)

-vrsta konta (dugovno-potražno, aktivno-izvještajno, analitičko-sintetičko). o Finansijsko knjigovodstvo (glavna knjiga),

-Obrada ulaznih faktura i KUF (unos u knjigu ulaznih faktura, likvidatura, kontiranje). Veoma je važno omogućiti knjiženje po profitnim centrima, mjestima troška i nosiocima troška, kao i razdvajanje jednog ulaznog računa troška na više mjesta troška ili više profitnih centara (struja, telefon, gorivo i sl.)

-Sistem mora posjedovati brzo i jednostavno učitavanje ulaznih faktura preko parsiranja podataka sa QR koda fakture prilikom elektronske fiskalizacije te fakture. Skeniranjem QR koda sa fakture dobijaju se podaci sa SEP portala Uprave prihoda i carina i automatski prosljeđuju korisnicima koji imaju rolu (profil korisnika) za obradu KUF-a.

-Obrada izlaznih faktura i KIF (unos u knjigu izlaznih faktura, likvidatura, kontiranje) -Obrada ulaznih i izlaznih odobrenja

-Formiranje i štampa naloga za knjiženje o Finansijska operativa

-Pregled potraživanja

-Pregled knjiženja po kontima - dokumentima, kartica konta

-Pregled kontnog plana

-Pregled naloga za knjiženje

-Pregled prometa po poslovnom partneru – kartica partnera

-Pregled ukupnih i dospjelih potraživanja

- Pregled izvoda

-Pregled stanja na tekućim računima

- Pregled plaćanja u određenom periodu

- Pregled obaveza sa mogućnošću označavanja obaveza za plaćanje (kreiranje naloga za plaćanje) sa mogućnošću eksporta naloga za plaćanje u fajl pogodan za import u eBanking sistem (xml, txt ili sl.)

-Mogućnost importovanja izvoda iz XML formata ili drugih formata za razmjenu podataka

-Automatsko povezivanje stavki analitike (gdje god se poklapaju računi sa naplatama i plaćanjima na osnovu poziva na broj)

-Ručno povezivanje stavki analitike (gdje nije unešen poziv na broj ili gdje se ne poklapa sa brojem računa) - Izrada naloga za izmjenu ulaznog i izlaznog PDV-a i PDV prijava

-Knjižna odobrenja

-Automatsko povezivanje stavki analitike po starosti

-Štampa i automatsko slanje na email komitenta izvoda otvorenih stavki za komintenta/e -Štampa i automatsko slanje na email opomena pred utuženje

oSve poslovne promjene se mogu pratiti po:

-profitnim-poslovnim centrima

-mjestima troška -nosiocima troška ili funkcijama.

oupravljačko računovodstvo koje podrazumijeva praćenje prihoda i troškova, u zadatom vremenskom intervalu, po:

-organizacionim jedinicama,

-mjestima nastanka,

-nosiocima,

-funkcijama.

oanalitika poslovnih partnera:

-dobavljača, -kupca, -kreditora,

-zaposlenih, itd.,

ofinansijska operativa: -praćenje naplate od poslovnih partnera po valuti plaćanja,

-praćenje očekivane naplate i naplate koja kasni u periodima od 15,30,60,90 i preko dana (neophodno je da konfigurator broja dana bude promjenljiv)

-plaćanja – pregled obaveza uz formiranje naloga za plaćanje kao dokumenta u sistemu koji može da se izveze u format fajla koji odgovara uvozu u eBanking sistem (xml, txt),

-Automatske notifikacije u sistemu i email notifikacije finansijskom direktoru o isticanju valuta za plaćanje faktura dobavljačima

-kompenzacije i predlozi za kompenzacije (štampa izjave o kompenzaciji na odgovarajućem obrascu),

-obrada žiro, tekućih i deviznih računa,

oBlagajničko poslovanje,

-Blagajničko poslovanje obuhvata sve radnje koje se odnose na primanje i izdavanje novca.

-neograničen broj blagajni

-unos i obrada blagajničkog dnevnika

-dnevna rekapitulacija

-automatsko kontiranje i prenos u glavnu knjigu

-poslovne promjene (uplatnice i isplatnice)

-nalog blagajni da primi (prenos gotovine sa žiro računa u blagajnu)

-nalog blagajni da izda

-automatsko formiranje blagajničkog dnevnika na kraju dana na osnovu evidentiranih poslovnih promjena

-Prijem uplata i izdavanje priznanica iz sistema na šalteru za direktan prijem uplata u gotovini.

o Bilans stanja, bilans uspjeha, bilans tokova gotovine, (mogućnost štampanja bilansa za određeni period ili po određenom profitnom centru)

o Bruto bilans (zaključni list) sa mogućnošću filtriranja po profitnom centru ili mjestu troška

o Standardni i namjenski izvještaji za tekuću godinu kao i odgovarajući izvještaji iz prethodnih godina (arhiva).

-Bilans stanja i bilans uspjeha

-Stanje na računu po organizacionim jedinicama

-Kartica računa

-Kartica komintenta po više konta kupaca (kupci u zemlji za usluge i utuženi kupci)

-Sve kartice komitenta

-Izvještaj o prihodima i rashodima u određenom periodu i po organizacionim jedinicama

-Dnevni promet po organizacionim jedinicama

-Dnevni promet po kontima

-Izvještaji propisani Zakonom i računovodstvenim standardima

-Profitabilnost

- Ostali izvještaji koji se specificiraju na početku projekta

-Mogućnost dobijanja svih izvještaja za sve godine poslovanja bez potrebe da se izađe iz jedne godine i uđe u drugu godinu, kao i uz mogućnost da se neki izvještaji gledaju za određeni period koji obuhvata više kalendarskih godina (na primjer zimska sezona od 01.10. jedne godine do 01.05. naredne godine) | 1 Paket

3. Obračun zarada Ova aplikacija informacionog sistema ne smije biti nezavisna već mora biti integrisana sa aplikacijama za upravljanje kadrovima i finansijama. Za svaki obračun aplikacija treba da crpi aktuelne podatke o zaposlenima iz aplikacije za upravljanje kadrovima (godine radnog staža, kojeficjent, stepen stručne spreme i sl.) koji utiču na visinu zarade.

Potrebno je da aplikacija bude u velikoj mjeri parametrizovana to jest da postoji mogućnost konfiguracije obračuna prema kolektivnom ugovoru i internim pravilnicima unutar preduzeća.

Obračun zarada mora biti integrisan prije svega sa sistemom koji propisuje Poreska Uprava kojoj se šalju zaključeni obrađeni podaci o zaradama zaposlenih putem automatski pripremljenog XML fajla.

Obračun zarada mora da ima sve konfiguracije za obračun po aktuelnom programu Evropa sad kao i da omogući bilo kakve rekonfiguracije u skladu za izmjenama zakonskih propisa. | o Parametri koji mogu da se usklađuju sa izmjenama u regulativi:

-Porezi, (definisanje svih vrsta poreza i/ili opštinskih prireza naspram zakonske regulative)

-Doprinosi (ujedno i povezivanje sa komintentima kome se plaćaju doprinosi poput Poreske uprave, Fond PIO i sl.)

-vrste plaćanja (potrebno je da sistem ima mogućnost definisanja neograničenog broja vrsta plaćanja za koje se posebno definišu parametri. Vrste plaćanja su zarade, topli obrok, prevoz, putni nalog, regres i sl.). Moraju biti podržane konfiguracije za sve vrste plaćanja koje propisuje Uprava prihoda i carina Crne Gore.

-Vrste obustava (potrebno je da sistem ima mogućnost definisanja neograničenog broja vrsta obustava). Obustave mogu biti jednokratne ili stalne u procentu u odnosu na zaradu

§ Obustava dnevnice

§ Naplata štete od radnika

§ Zakonske obustave

§ Članstva u komorama i sindikatima

§ Krediti

oObustave zaposlenihih, oEvidencija prisustva (to jest odsustva) – šihtna lista

oParametri za obračun zarada (period na koji se odnosi obračun, fond sati, vrijednost boda, minuli rad). Na osnovu tipa obračuna, obračun može biti:

-startni dio zarade čija vrijednost se mijenja shodno Odluci Društva,

-redovan rad, -rad na praznik,

-noćni rad,

-prekovremeni sati,

-topli obrok,

- prevoz,

-naknada zarade zbog privremene spriječenosti za rad – do 60 dana, preko 60 dana, porodiljsko odsustvo, 100% plaćeno bolovanje. Ovaj obračun se mora automatski obračunati kao 12 mjesečnih zarada, koje prethode mjesecu u kojem je nastala privremena spriječenost za rad, uz mogućnost ručnog unošenja procenta umanjenja,

- zimnica, regres itd.

oObračun se radi automatski u odnosu na unešene parametre. Potrebno je da sistem ima mogućnost korekcije pojedinačne plate ili kompletnog obračuna sve do ovjere obračuna. Nakon ovjere obračuna moguće je jedino storniranje i ponovni obračun.

oMogućnost obračuna svih aktivnosti zaposlenih koje utiču na visinu zarade, tj. mogućnost evidencije svega što ulazi u obračun.

oObračun otpremnina i jubilarnih nagrada.

oRefundacije i stimulacije.

oSistem mora imati mogućnost pregleda neto i bruto zarada kao i prosječne zarade na mjesečnom i godišnjem nivou, zbirno kao i po profitnim centrima, i sl.

oMogućnost eksporta u XML format obračuna radi importa u eBanking sistem kako bi se automatizovao proces plaćanja.

oAutomatski prenos naloga u finansije (knjiženje). Za potrebe automatskog knjiženja zarada potrebno je da sistem ima mogućnost kontiranja svih vrsta plaćanja.

oPored obračuna zarada za zaposlene potrebno je da sistem ima mogućnost obračuna i evidencije lica angažovanih na osnovu ugovora o djelu, članova revizorskog i izvršnog odbora. Potrebno je da sistem ima omogućenu direktnu štampu zakonski propisanih obrazaca IOPPD, Rekapitulacija po vrstama plaćanja, Zbirna rekapitulacija, Spisak obustava, Spisak obustava po komitentima, Platne liste, spisak plata, Specifikacija zarada po profitnim centrima, RAD1, M4, M12, OPD2, OPD3 i sl.

oSistem mora posjedovati uobičajene računovodstvene izvještaje (platne liste i obustave za zaposlene), kao i zakonski obavezne izvještaje i obrasce koji će se štampati iz sistema. Kako bi sistem pružio adekvatnu mogućnost analize potrebni su minimum sljedeći parametri za izvještaje: organizacione jedinice, vrste plaćanja, stručne spreme, zanimanja, karakter zaposlenja, određeno, neodređeno vrijeme, pripravnici itd.

oSistem mora imati mogućnost slanja platnih lista na email zaposlenima.

Sistem mora da posjeduje export obračuna u XML format prema tehničkoj specifikaciji Uprave prihoda i carina CG kako bi se importovao na njihov portal | 1 Paket

4. Upravljanje osnovnim sredstvima Aplikacija mora da omogući korisniku da prati stanje, kretanja, zaduženja i raspored osnovnih sredstava po organizacionim jedinicama, računopolagačima, lokacijama, obračun amortizacije i revalorizacije, rashodovanje ili prodaju sredstava tj. brisanje iz evidencije.

Aplikacija mora da osigura povezanost sa aplikacijom za upravljanje finansijama i drugim neophodnim aplikacijama u smislu korištenja podataka i automatskog knjiženja.

Opšti parametri koji se preklapaju sa parametrima drugih aplikacija unutar sistema moraju biti centralizovani, to jest da se definišu na jednom mjestu. Na primjer: organizacione jedinice preduzeća, kontni okvir, računopolagači (iz evidencije zaposlenih) i sl. | oMogućnost kreiranja parametara u skladu sa potrebama korisnika

-Amortizacione grupe i stope u odnosu na zakonske propise

-Šifarnik lokacija unutar organizacije gdje je sredstvo fizički smješteno. Uz pomoć ovog parametra olakšava se popis OS.

oPočetno stanje osnovnih sredstava i unos nabavki

-Unose se sva sredstva u trenutku implementacije sistema

-Evidencija za svako sredstvo treba da sadrži detaljne podatke o sredstvu kao što su: naziv, datum nabavke, datum aktivacije, dobavljač, datum fakture, broj fakture, dobavljač, fabrički broj, serijski broj, inventarni broj, datum garancije, organizaciona jedinica, lokacija gdje je sredstvo smješteno, računopolagač, poreska i računovodstvena amortizaciona grupa, konto, konto ispravke, rezidualna vrijednost, i sl.

oManipulacija-unos promjena stanja i rasporeda osnovnih sredstava -Dogradnja osnovnih sredstava,

§ odabir inventarnog broja sredstva na kojem se vrši dogradnja

§ unos naziva tj opisa dogradnje

§ unos ukupnog iznosa dogradnje

§ aktiviranje dogradnje tj. ovjera sredstva

-Rastavljanje osnovnih sredstava (dodjeljuje se novi inventarni broj za sva novodobijena sredstva koja se kasnije ponašaju nezavisno i moguće su sve operacije nad njima)

-sastavljanje osnovnih sredstava (moguće je iz više sredstava formirati jedno sredstvo),

-Premještaj (preraspored) osnovnih sredstava § Promjena lokacije sredstva

§ Promjena poslovne jedinice

oDeaktiviranje osnovnih sredstava gdje se kao razlog može javiti rashod, prodaja ili manjak. Deaktiviranjem sredstva istorijat postojanja sredstva sa svim podacima mora biti omogućen

oObračun amortizacije

-Predračun amortizacije (planski pokazatelj koji podrazumijeva obračun amortizacije za godinu dana za sva sredstva koja se nalaze u funkciji, po unesenim stopama.),

-Periodični obračun (služi za periodično obračunavanje amortizacije pri čemu se obračuni pamte u bazi podataka),

-Godišnji obračun (Na osnovu godišnjeg obračuna se vrši pripis ispravke vrijednosti u bazi OS i karticama osnovnih sredstava).

oKnjiženje novonabavljenih sredstava, dogradnje, deaktiviranih sredstava, kao i amortizacije mora biti automatizovano kroz integraciju sa aplikacijom za upravljanje finansijama. Na nalogu za knjiženje moraju biti prikazani iznosi obračunate amortizacije po kontima i mjestima troška

oObračun revalorizacije koji može biti:

-Periodični i

-Godišnji. oInventarisanje – propis osnovnih sredstava,

-Propisom se vrijednosno stanje osnovnih sredstava ažurira prema stvarnom stanju.

-Izrađuje se propisna lista u kojoj propisna komisija upisuje stvarno stanje po organizacionim jedinicama unutar pravnog lica. -Na propisnoj listi sredstva su složena po lokacijama. -Unos propisane količine je podloga za listu viškova ili manjkova. -Knjiženjem propisa se na kartice osnovnih sredstava zapisuje promjene viška i manjka.

oRashod osnovnih sredstava i prodaja osnovnih sredstava.

oMogućnost atačovanja fotografija osnovnih sredstava

oVeliki broj standardnih i namjenskih izvještaja:

-Knjiga osnovnih sredstava

-Knjiga rashoda

-Kniga novih nabavki

-Kartica popisa robe

-Obračuni amortizacije po organizacionim jedinicama, kontima, amortizacionim grupama,

-Pojedinačna kartica osnovnog sredstva

-Sumarno stanje - kartica svih osnovnih sredstava,

-Lista za propis | 1 Paket

5. Materijalno računovodstvo, prodaja roba i usluga (veleprodaja, maloprodaja) Aplikacija je namijenjena za podršku upravljanja poslovnim procesima koji se tiču trgovine robom ili uslugama. Aplikacija ne smije da funkcioniše samostalno već mora biti integrisana sa ostalim aplikacijama Poslovnog Informacionog Sistema preduzeća D.O.O. KOMUNALNO KOTOR. Integracija se podrazumijeva sa aplikacijama Upravljanje finansijama (šifarnici kupaca i dobavljača, država, opština, valuta, poreza i sl.), Upravljanja ljudskim resursima (zaposleni će biti računopolagači u magacinima ili komercijalisti po kojima će se pratiti učinak i sl.), i drugo.

Osnovne grupe procesa koje moraju biti pokrivene ovom aplikacijom su: parematrizovanje procesa, nabavka robe, veleprodaja i maloprodaja. | oMogućnost kreiranja parametara u skladu sa potrebama korisnika

-Grupisanje artikala i usluga (u daljem tekstu artikli) u minimum 4 hijerarhijska nivoa. Grupe artikala se koriste za grupnu manipulaciju ili za izvještavanje

-Kategorije za knjiženje usluga i artikala (dodjeljivanje konta za automatska knjiženja). Kategorizaciju artikala definišu sami korisnici u odnosu na zahtjeve analitike i izvještavanja iz modula za upralvjanje finansijama.

-Definisanje skladišta

§ Neograničen broj skladišta

§ Definisanje skladištara, to jest računopolagača za skladište

§ Tip skladišta

§ Organizaciona jedinica kojoj pripada skladište

§ Lokacije u skladištu (omogućavaju lakšu fizičku organizaciju prostora u skladištu i lakše pronalaženje atrikla u skladištu)

§ Mogućnost finansijskog vođenja skladišta po prosječnim nabavnim cijenama ili po prodajnim cijenama

§ Mogućnost definisanja načina izdavanja robe iz skladišta po metodi FIFO (First In First Out)

§ carinsko skladište i posebna pravila u radu carinskog skladišta

-Jedinice mjere

-Artikli (definišu se detaljni podaci o artiklima kao što su: automatska šifra, naziv, grupisanje, kategorija, barkod, neograničen broj fotografija, narativni opis, porijeklo, poreska stopa, cijena, porez, tehnički podaci, garantni period, procenat kaliranja, dimenzije, standardna količina na lageru, minimalna količina na lageru, rok trajanja, porijeklo, marža, rabat, tarifni broj i carinska stopa, zemlja porijekla, proizvođač, neograničen broj EAN-a za jedan artikal, osnovna jedinica mjere i neograničen broj alternativnih jedinica mjere, uputstvo za upotrebu za deklaracije, kataloški broj, fabrički broj, mogućnost definisanja vođenja serija/šarži i rokova trajanja, informacija o važenju i roku garancije, i sl.)

-Mogućnost pregleda zaliha po vrstama artikala, vrijednosti i svim ostalim definisanim karakteristikama.

-Mogućnost štampe etiketa za artikle za obilježavanje artikala na policama (naziv, cijena, barkod, uputstvo za upotrebu, stara/nova cijena nakon nivelacije i sl.)

-Mogućnost štampe carinskih deklaracija na samoljepljivim papirima na osnovu unešenih atributa za artikle.

-Artikal može biti i usluga. Za artikle kojima je dodijeljen tip usluga nikada se ne radi prijem i stoga je potrebno drugačije knjižiti njihovu prodaju u odnosu na prodaju roba. Sistem ne smije usluge voditi kao minusne količine!!!

-Na artiklima se mogu definisati i alternativne jedinice mjere koje predstavljaju neki procenat u odnosu na definisanu osnovnu jedinicu mjere. Na primjer (1 paleta=100 kutija). Ulazni i izlazni dokumenti moraju imati mogućnost definisanja alternativne jedinice mjere na osnovu čega će sistem sam preračunati vrijednosti i voditi zalihe u osnovnoj jedinici mjere.

-Sistem ne smije dozvoljavati mogućnost da količina artikala ima vrijednost manju od 1 (navedeno ne važi za ikebane u magacinu cvjećare)

-Vrste dokumenta (potrebno je da aplikacija ostavlja mogućnost korisnicima da sami definišu vrste dokumenta i njihove osobine – ulazni ili izlazni, knjiži se ili ne i sl.)

-Definisanje popusta prema kategorijama kupaca, kategorijama artikala, proizvođaču, dobavljaču.

-Mogućnost definisanja smjena i razdvajanje pazara po smjenama

oNabavka robe

-Trebovanje robe iz centralnog magacina ili trebovanje robe direktno od dobavljača

-Narudžba, služi za naručivanje i praćenje isporuke,

§ Predstavlja narudžbenicu koju sačinjavaju odgovorni zaposleni

§ Na osnovu narudžbenice, nabavna služba vrši nabavku materijala

§ Narudžbenica se kreira prepisom iz trebovanja ili direktno

-Prijem robe u skladište - kalkulacija

§ Prijem artikala se radi isključivo na nivou magacina

§ Radi se u dva koraka: prijem količinski i prijem finansijski, to jest kalkulacija

§ Količinski prijem radi skladištar. Ovim dokumentom skladišta potvrđuje artikle i količine koje su primljene u magacin

§ Potrebno je da sistem ima mogućnost prepisa stavki iz određenog dokumenta narudžbenice u dokument prijema gdje će skladištar da napravi korekcije u slučaju potrebe

-Kalkulacija nabavne cijene,

§ Obrada dokumenta prijema predstavlja drugi korak. Obradu rade zaposleni zaduženi za nabavke. Prilikom obrade prijema vrši se i kalkulacija nabavne cijene u kojoj treba da budu uključeni i neograničen broj zavisnih troškova nabavke (transport, osiguranje, carina i sl.) § Ovjerom prijema radi se količinsko zaduživanje skladišta, a ovjerom kalkulacije radi se finansijsko zaduživanje skladišta i to po prosječnim nabavnim cijenama koje su rezultat kalkulacije

-Povrat artikala prema dobavljaču

§ Povrat artikala se radi isključivo na nivou magacina

§ Dokument povrata artikala može da se odnosi na eksternog dobavljača ili na interni prenos iz skladišta u skladište (međuskadišnica)

§Povrat se radi po određenom dokumentu prijema ili je moguće raditi slobodni povrat bez veze sa dokumentom prijema

§Stavke na dokumentu povrata mogu biti samo iz prethodno odabranog dokumenta prijema sa količinom koja je jednaka ili manja od količine na dokumentu prijema

§Ovjerom povrata umanjuju se zalihe u magacinu i količinski i finansijski.

-Manipulacija artiklima (međuskladišnica)

§Služi za prenos artikala iz skladišta u skladište

§Međuskladišnica podrazumijeva automatsko ažuriranje količinskog i finansijskog stanja u oba skladišta, izlaznom i ulaznom

§Aplikacija mora imati mogućnost posebne ovjere izlaza i ulaza (kada su obije ovjere odrađene sprovodi se korekcija stanja u oba magacina) i mogućnost korekcije stanja samo jednom ovjerom (automatski za oba dokumenta)

§ Aplikacija mora omogućiti formiranje i knjiženje međuskladišnice u dva koraka (formiranje vrše skladištari a knjiženje komercijala)

-Vođenje serija i rokova

§Na dokumentu nabavke mora postojati mogućnost unosa serija i rokova trajanja. Za jedan artikal na ulaznom dokumentu može da se definiše više serija i rokova.

oMaloprodaja

-Prijem od dobavljača

§Dokument omogućava direktan prijem robe od spoljnog dobavljača u maloprodajni objekat

§ Moguće je pozivanje na dokument narudžbenice robe za dobavljača čime će se automatski prepisati podaci na dokument prijemne kalkulacije.

§ Dokument sadrži sljedeće atribute: komintent (dobavljač) i datum prijema,

§ Dokument mora da ima mogućnost unosa neograničenog broja zavisnih troškova koji će biti iskorišćeni u kalkulacij nabavne cijene, to jest maloprodajne cijene

-Interni prijem iz centralnog skladišta

§Prijem iz centralnog skladišta mora biti složeni dokument koji se sastoji od dva dokumenta: izlaz iz centralnog skladišta i ulaz u MP objekat. Svaki magacioner zadužen za svoj objekat ovjerava svoj dokument. Ulaz u MP ne smije postojati bez izlaza iz centralnog magacina

-Povrat robe dobavljaču

§Dokument povrata artikala može da se odnosi na eksternog dobavljača ili na interni prenos iz veleprodaje u maloprodaju (otpremnica u maloprodaju)

§Povrat se radi po određenom dokumentu prijema ili je moguće raditi slobodni povrat bez veze sa dokumentom prijema

§Stavke na dokumentu povrata mogu biti samo iz prethodno odabranog dokumenta prijema sa količinom koja je jednaka ili manja od količine na dokumentu prijema

§Ovjerom povrata umanjuju se zalihe u magacinu i količinski i finansijski.

-Prenos između maloprodajnih objekata

§Dokument omogućava prenos artikala između maloprodajnih objekata

§Nije dozvoljena promjena cijene na ovom dokumentu

§Ovo mora biti složeni dokument koji se sastoji od dva dokumenta: izlaz iz jednog MP objekta i ulaz u MP drugi objekat. Svaki magacioner zadužen za svoj objekat ovjerava svoj dokument. Ulaz u MP ne smije postojati bez izlaza iz drugog MP objekta

-Razduženje maloprodaje po specifikaciji iz POS aplikacije

§ Dokument služi za unos svih prodatih artikala, to jest izlaza robe iz maloprodajnog skladišta.

§ Dokumetom se razdužuje maloprodajni objekat i količinski i finansijski

§ Dokument se knjiži u finansijama

-Nivelacija prodajne cijene

§ S obzirom da se zalihe u maloprodajnom objektu vode po prodajnim cijenama svaka promjena cijene koja nije inicirana prijemnicom radi se preko dokumenta za nivelaciju.

§ Nivelacija prodajne cijene se vrši za sve preostale zalihe za artikle koji se nalaze na ovom dokumentu

-POS aplikacija

§ služi za prodaju roba i usluga

§ artikli se dodaju preko šifre, barkoda ili preko pretrage po nazivu artikla

§ hijerarhijski pregled artikala po kategorijama i brzo dodavanje artikla na stavke računa klikom na artikal iz odgovarajuće kategorije

§ mogućnost određivanja popusta na jedan artikal ili na više artikala odjednom

§ za artikle koji se vode po seriji/šarži i roku trajanja POS aplikacija mora da ponudi izbor šarže i roka trajanja sa zaliha nakon skeniranja barkoda artikla

§ Ako se račun pravi za poznatog kupca, kupac se bira iz liste vrijednosti. Ukoliko kupac ne postoji mora postojati mogućnost da se kupac doda u POS aplikaciji. Pravna lica moraju da se dodaju automatskim povlačenjem podataka sa crps.me putem unešenog PIB-a kako bi se izbjegle greške prilikom dodavanja kupaca i izbjeglo unošenje duplih kupaca

§ Na računu se evidentira kupac, datum računa, mjesto isporuke i mogućnost biranja artikala koji se dostavljaju kupcu/koje on ne preuzima u MP objektu, datum valute plaćanja za poznate kupce

§ Prodaja na rate – definiše se na koliko rata se prodaje predmetni račun i program mora da iskalkuliše plan otplate. Na A4 verziji računa mora da se vidi specifikacija rata. Prilikom knjiženja predmetni račun se knjiži analitički po ratama i valutama dospijeća rata

§ Ovjerom računa vrši se automatsko razduženje maloprodajnog objekta

§ Račun / razduženja MP se automatizovano prenose u KUF i na nalog za knjiženje na osnovu definisanih šema knjiženja

§ Na većim prodajnim mjestima potrebno je da aplikacija radi na Windows računarima sa ekranima osjetljivim na dodir ili putem prečica na tastaturi, dok se na tržnicama i vagi očekuje android POS uređaj sa aplikacijom i štampačem na istom uređaju. | 1 Paket

6. Servis vozila – održavanje voznog parka Predmetni aplikativni softver predstavlja jednu od komponenti PIS-a i u potpunosti je integrisan sa ostatkom sistema kako bi se izbjeglo duplo unošenje podataka. Aplikativnim modul pokrije određene procese koji se tiču servisiranja voznog parka čime će se obezbijediti knjiženje utroška rezervnih dijelova, ulja i maziva po vozilima koja će biti deklarisana kao MT – mjesta troška. | -Veza sa šifarnikom artikala iz komercijale (rezervni dijelovi, ulja, maziva)

-Veza sa magacinima

-Formiranje radnog naloga za vozilo

-Štampa radnog naloga

-Evidencija usluga i rezervnih djelova na radnom nalogu

-Izdavanje mehaničarakih artikala sa srevisnog naloga. Formirati nalog za izdavanje iz magacina.

-Razdvajanje usluga i dijelova na vulkanizerske, električarske i mehaničarske u tabove

-Planer termina za servis po majstorima ili boxovima

-Šeme knjiženja za knjiženje internih servisnih naloga na trošak

-Prepisivanje podataka na knjiženje u glavnu knjigu -izvještaji | 1 Paket

7. Radni nalozi – zelenilo, održavanje čistoće, rad po pozivu Predmetni aplikativni softver predstavlja jednu od komponenti PIS-a i u potpunosti je integrisan sa ostatkom sistema kako bi se izbjeglo duplo unošenje podataka. Aplikativni modul pokriva poslovne procese koji se tiču evidencije različitih radnih naloga na kojima mogu da se definišu pružene usluge i utrošeni materijali i koji mogu da se fakturišu krajnjim kupcima ili knjiže interno na trošak poslovanja. | ·Kreiranje radnog naloga za održavanje nekog sredstva ili objekta ili javne površine definisane u katalogu predmeta održavanja

·Kreiranje radnog naloza po pozivu

·Evidencija pruženih usluga na radnom nalogu

·Evidencija utrošenih materijala na radnom nalogu

·Mogućnost direktnog fakturisanja radnog naloga za bezgotovinska plaćanja

·Mogućnost knjiženja radnog naloga interno na troškove poslovanja putem šeme knjiženja | 1 Paket

8. Praćenje ugovora za usluge i automatsko fakturisanje – biling sistem | Aplikacija mora da omogući jedinstveno praćenja svih ugovora u preduzeću u različitim poslovnim jedinicama. U sistemu se definišu različiti ugovori između preduzeća i krajnjeg korisnika koji može biti fizičko ili pravno lice. Ugovori mogu biti za odvoz smeća, zakupe tezgi na pijacama, zakupe poslovnih prostora, prodaja i održavanje grobnih mjesta i razne druge komunalne usluge bez ograničenja. Moguće je odvojeno voditi ugovore na nivou organizacioni jedinica ili direktno na nivou cijelog preduzeća. Svaka organizaciona jedinica evidentira i prati realizaciju svojih ugovora (te može da vidi samo ugovore koje se odnose na njegov organizacioni dio). Pojedini korisnici mogu da vide ugovore u cijelom sistemu. Stavke ugovora predstavljaju usluge koje su prethodno kategorisane. Usluge na ugovoru mogu biti jednostavne sa jednostavnim cjenovnikom (cijena zakupa tezge, cijena godišnjeg održavanja grobnog mjesta, i sl.) ili cijene mogu biti definisane kao jedinične cijene po metru kvadratnom stambenog ili poslovnog prostora (odvoz smeća) i uz to mora postojati evidencija stambenih i poslovnih prostora. Neophodno je da aplikacija ima mogućnost uvoza stambenih i poslovnih prostora iz excel šablona za import podataka. Neophodno je da postoji mogućnost izmjene vlasnika stambenog ili poslovnog prostora. Osnovni atributi ugovora koja se mogu pratiti su:

oBroj ugovora oDatum ugovora

oVrsta ugovora (ugovor sa cijenom usluge ili ugovor sa kalkulacijom cijene u odnosu na kvadraturu stambenog ili poslovnog prostora)

oTrajanje ugovora – važenje ugovora

oDatum posljednje fakture (u odnosu na ovaj datum neophod)

oPeriodičnost fakturisanja u mjesecima (1 – mjesečno, 3 – kvartalno, 6 – polugodišnje, 12 - godišnje)

oRok plaćanja po izdatoj fakturi

oPredmet Ugovora (moguće više usluga) sa cijenom i eventualnim popustom

oPartner sa kojim je potpisan ugovor (komitent)

oPripadajući organizacioni dio

oUslovi plaćanja

oNačin dostavljanja računa (štampano dostavom, emailom)

oNapomene Fakturisanje

Na osnovu definisanih ugovora i uslova fakturisanja neophodno je da sistem posjeduje mogućnost automatskog kreiranja mjesečnih i godišnjih faktura, to jest po periodičnosti fakturisanja definisanog u ugovoru.

Pregled korisnika usluge upravljanja komunalnim otpadom mora sadržati sledeće podatke: površina stambenog odnosno poslovnog objekta, spratnost, adresa, reon, poštanski reon, djelatnost (za pravna lica), katastarska parcela, JMB / PIB, i sl.

Sistem mora omogućiti pregled svih korisnika sumarno, kao i po gore navedenim karakteristikama. Mora omogućiti izvještaje u ukupnom broju korisnika, ukupnoj površini nepokretnosti fizičkih i pravnih lica.

Fakture na sebi prikazuju zaduženje za tekući period, prethodni dug, dug po tužbi odnosno dug po sporazumu i ukupan iznos za fakturisanje, iznos fiksnog i varijabilnog dijela cijene prema unaprijed definisanom procentu u odnosu na važeću jediničnu cijenu pomnoženu sa površinom nepokretnosti i troškovnik sa procentualnim učešćem u ukupnu cijenu, shodno zakonu o Komunalnim djelatnostima.

Prethodni dug i dug po tužbi se automatski povlači iz glavne knjige.

Kreira se zbirna faktura ukoliko isti komitent ima više objekata ili usluga na ugovorima u okviru iste organizacione jedinice DOO KOMUNALNO KOTOR” Kotor.

Fakture se automatski fiskalizuju po pravilima elektronske fiskalizacije u CG. Sistem sam vodi računa o uspješnosti fiskalizacije. Očekivano je preko 30000 mjesčenih fakrtura.

Sistem mora posjedovati mogućnost automatskog slanja računa na email svim komitentima koji su se registrovali za taj vid isporuke računa. Sistem mora biti integrisan i sa platformom https://www.edostava.me/ čime se pojeftinjuje isporuka računa za korisnike koji prihvate ovaj način dostave. Putem API integracije sistem će nakon fakturisanja poslati sistemu eDostava informaciju o računu na osnovu čega će isti biti isporučen elektronskim putem.

Sistem mora da omogući naplatu računa preko sistema eComerc platforme koju je dužan izvođač isporučiti zajedno sa sistemom. eCommerce platforma mora biti uskon integrisana sa sistemom u cilju preuzimanja stanja kupaca u svakom trenutku. eCommerce portal za naplatu dugovanja se treba realizovati kao nezavisna stranica koja će biti registrovana na podomenu https://naplata.jkpkotor.com I kao takva fizički linkovana na odgovarajućoj stranici na javnom portalu preduzeća.

Fakture se štampaju na laserskom štampaču na A4 šablonima sa jednom fakturom na jednoj stranici i šablonima sa 3 fakture na jednoj A4 stranici. Neophodno je da sistem omogući nesmetano štampanje velikog broja faktura (i preko 30000 faktura mjesečno) u jednom ciklusu. Štampaju se samo fakture koje se ne šalju putem emaila ili eDostave. Fakture se štampaju po reonima.

Osim izrade mjesečnih faktura sistem mora imati mogućnost izrade faktura i profaktura kao i avansnih faktura za druge usluge koje Društvo pruža.

Sistem mora imati mogućnost obračuna kamata, shodno odluci i modelu Društva.

Automatske notifikacije

Sistem mora posjedovati mogućnost automatskog slanja email notifikacija kao opomene za neplaćeni račun u dogovorenim mjesečnim terminima za sve klijente kojima je poznata email adresa. Za predmetnu funkcionalnost koristiće se poseban nalog na mailgun.com za masovno slanje mailova koji će registrovati Komunalno Kotor (nije obaveza isporučioca da preuzima troškove slanja email-a).

Sistem mora posjedovati mogućnost automatskog upozorenja na zastarijevanje potraživanja i generisanja predloga za izvršenje.

Opomene pred utuženje

Sistem mora posjedovati mogućnost masovne štampe opomena pred utuženje, po šablonu koje obezbijedi DOO Komunalno Kotor” Kotor kako bi se iste distribuirale poštom.

Aplikacija mora da poseduje i izveštaje kao što su:

- Pregled svih ugovora po organizacionim jedinicama u izabranom periodu, sa podacima o ugovorenom, fakturisanom, plaćenom iznosu i preostalom iznosu za plaćanje

- Kartica pojedinog pretplatnika – komitenta | 1 Paket

9. Uslužno vaganje | Aplikacija mora da omogući vezu sa vagom na Pretovarnoj stanici i Kamenolomu.

Na osnovu izmjerene količine, vrši se fakturisanje, po usvojenom cjenovniku. Aplikacija mora imati mogućnost otvaranja novih poslovnih partnera i mogućnost unosa težine osnovnog sredstva (kamiona). Na izdatom računu mora biti prikazana bruto i neto količina koja je izvagana. | 1 Paket

10. Parking | Aplikacija mora da omogući vezu postojećeg parking softvera sa glavnom knjigom na osnovu exporta podataka iz aplikacije za parking. | 1 Paket

11. Web stranica za komunikaciju sa korisnicima | Sistem mora posjedovati web stranicu namijenjenu korisnicima koja će imati sljedeće funkcionalnosti:

• Registracija korisnika - kreiranje korisničkog naloga na osnovu validnog emaila i unešene šifre korisnika koja se vidi na računu. Sistem mora da validira unešeni email uz slanje linka za potvrdu posjedovanja emaila koji je korisnik unio.

• Čekiranje da li klijent želi da prima račun putem email-a

• Pregled kartice komitenta za registrovane korisnike

• Plaćanje računa preko web stranice (opisano u tački 2.8 - fakturisanje)

Web stranica će biti linkovana na postojeći web sajt preduzeća. | 1 Komada

12. Izvještavanje iz sistema | Informacioni sistem mora posjedovati minimum standardne računovodstvene i komercijalne izvještaje koji su načelno opisani u zahtjevima za svaki modul. Izvještaji moraju biti dostupni u PDF formatu, kao i u formatima pogodnim za dodatnu obradu kao što su .xlsx i .docx za izvještaje koji sadrže informacije koje se mogu koristiti u daljoj analizi.

Informacioni sistem mora posjedovati mogućnost kreiranja PIVOT tabela u oblasti izvještavanja iz fakturisanja i prodaje | 1 Paket

13. Administracija sistema | Osnovna poslovna funkcija za koju se vezuje pojam administriranja sistema je Kontrola pristupa aplikacijama, tj. autentikacija i autorizacija korisnika sistema. Autentikacija podrazumijeva identifikovanje korisnika na osnovu korisničkog naloga. Korisnički nalog definiše se minimum korisničkim imenom i lozinkom. Neophodno je da sistem upisuje u bazu kriptovanu lozinku, to jest da ni administrator sistema ne može da vidi lozinku koju je korisnik sam sebi postavio. Korisnički nalog je moguće deaktivirati kada se onemogućava pristup sistemu predmetnom korisniku. Potrebno je da postoji i funkcionalnost otvaranja korisničkog naloga koji je vremenski ograničen. Nakon isteka roka trajanja naloga sistem automatski blokira pristup predmetnom korisniku.

Autorizacija korisnika podrazumijeva evaluaciju prava pristupa korisnika određenom traženom resursu (cijeloj aplikaciji ili pojedinoj formi ili izvještaju unutar aplikacije).

Kontrola pristupa treba u najvišem hierarhijskom nivou da bude povezana sa organizacionom šemom preduzeća, to jest korisnicima se određuje pravo rada sa podacima za određenu organizacionu jedinicu. Takođe, mora biti obezbjeđen pristup podacima samo ovlašćenim licima u mjeri kako je to definisao administrator sistema. Ovom aplikacijom upravlja samo Administrator informacionog sistema. Neophodno je da pristup IS-u bude apsolutno dozvoljen jedino uz konsultovanje prava pristupa dodijeljenih kroz ovu aplikaciju.

Aplikacija mora da ima podršku za formiranje rola (profila korisnika). Potrebno je sistematizovano i precizno definisati i prepoznati srodne skupove poslova. Rola predstavlja skup poslovnih funkcija i ona grupiše korisnike koji obavljaju slične poslove. Na primjer u aplikaciji Upravljanje finansijama možemo imati role šef računovodstva, knjigovođa, operater blagajne i sl. U okviru role na uključenim poslovnim funkcijama moguće je postaviti više parametara za kontrolu pristupa: dozvoljeno čitanje, dozvoljen upis podatka, dozvoljena izmjena, dozvoljeno brisanje, dozvoljena ovjera dokumenta.

Svaki zapis ili izmjena podatka u Informacionom sistemu mora biti praćen sa upisom korisničkog naloga koji je kreirao slog i kada je slog kreiran, kao i korisnika koji je posljednji ažurirao slog i tačno vrijeme kada je odrađena ta akcija. Na formama unutar IS-a moraju jasno biti vidljivi ovi podaci i po njima je moguće filtriranje (na primjer selektovati samo fakture koje je kreirao neki korisnik sistema u određenom vremenskom periodu). | 1 Paket

14. Nefukcionalni zahtjevi u radu sistema | a)Jednostavnost korišćenja sistema – ogleda se u tome da se ciljanim grupama korisnika omugući jednostavno ostvarivanje poslovnih ciljeva kroz realizaciju poslovnih procesa odnosno procedura. Jednostavnost i lakoća u učenju rada na sistemu, efikasnot u radu i zadovoljstvo korisnika sistemom. -Preduslov 1: Usklađenost sa poslovnim procesima i procedurama – sistem prirodno slijedi korake poslovnog procesa i prati korisnika u običajenom toku aktivnosti koje obavlja.

-Preduslov 2: Dizajn korisničkog okruženja (interface) – Ekranske forme moraju biti dizajnirane u skladu sa pravilima i primjermia dobre prakse. To se prije svega odnosi na garfički dizajn, centričnosti i konzistentnost u pogledu prezentacije informacija, način obrade grešaka i funkcije pomoći korisnicima u radu.

b)Pouzdanost sistema je svojstvo sistema da obavlja svoju funkciju neprekidno korz određeno vrijeme u okviru zadanih uslova.

c)Sigurnost sistema – sposobnost sistema da spriječi pristup, pregled i izmjene podataka neautorizovanim licima. -Preduslov 3: Implementiran modul za autentifikaciju i autorizaciju korisnika,

-Preduslov 4: Razrađen model uloga i prava korisnika i sistemu,

-Preduslov 5: Vođenje dnevnika aktivnosti (log file) – praćenje i zapisivanje svih aktivnosti u sistemu (ko je, kad je i nad čime je izvršena aktivnost)

d)Backup – sigurnosne kopije podataka – omogućava pohranjivanje svih podataka u obliku sigurnosnih kopija na više različitih lokacija. Time se omogućava povrat izgubljenih podataka, odnosno, kontrola štete ukoliko je gubitak podataka neizbježan. e)Dostupnost sistema – neophodno je da sistem bude dostupan korisnicima sistema u toku regularnog radnog vremena preduzeća koje će ga koristiti. Iz tog razloga, sve nadogradnje sistema ili izmjene na sistemu koje zahtijevaju off-line” režim rada moraju se raditi izvan definisanog radnog vremena (od 07:00 do 19:00h). f)Skalabilnost – je sposobnost sistema da opsluži naglo povećanje broja korisnika, obima posla, proširenja sistema u funkcionalnom (dodatne usluge-funkcionalnosti) ili organizacijskom (dodatne jedinice ili organizacije) smislu.

g)Podrška u radu sistema – obuhvata različite elemente podrške i održavanja koje treba pružiti za vrijeme eksploatacije sistema.

-Prenos podataka i probni rad

-Obuka korisnika

-Podrška korisnicima u radu sa sistemom

-Help-desk usluge – online pomoć, upustva, podrška putem telefona, e-pošte itd. | 1 Paket

15. Zahtjevi za arhitekturu sistema

Sistem mora biti baziran na savremenim web tehnologijama i arhitekturi orijentisanoj ka servisima (SOA – Service Orijented Achitecture). Ovakva arhitektura omogućava povezivanje različitih servisa sa različitim vrstama klijenata i omogućava jednostavnu, a prije svega bezbjednu integraciju sa eksternim sistemima kroz precizno definisane zahtjeve za eksterne Web servise. Aplikativna rješenja treba da koristite tanke klijente (web browseri), kojima se isporučuje standardni HTML/XML/Javascript sadržaj. Komunikacija između klijenta i srednjeg sloja treba da bude putem standardnog https protokola, koji može biti ostvaren kroz različite tipove Internet konekcija. Sistem mora da ima mogućnost da se jednostavno pokrene putem web pretraživača na računarima, laptop računarima, tablet računarima i telefonima. Dijelovi sistema koji će se koristiti na terenu moraju biti prilagođeni ekranima tablet računara od 10.

Tehnološka platforma sistema mora da bude skalabilna, proširiva i fleksibilna. | IS će se sastojati od jedne centralne lokacije. Centralna lokacija sadrži sljedeće komponente sistema:

-Skladište podataka (centralno) – baza podataka

-Aplikativna logika

-Sistem za distribuciju i upravljanje autentifikacionim i autorizacionim podacima

-Sistem za pravljenje rezervnih kopija podataka (backup)

Postulati na kojima treba da bude bazirana arhitektura IS-a:

-Platformski nezavistan na klijentskoj strani – nezavisnost u odnosu na na operativni sistem

-Upotreba otvorenih standarda

-Horizontalno skalabilan (tj uvećavanje performansi se vrši dodavanjem novih procesnih jedinica) Na centralnoj lokaciji se nalazi cijela infrastruktura sistema (misli se na računarsku) bazom podataka. Svi podaci se čuvaju u njoj. U organizacionim jedinicama nalaze se samo radne stanice, to jest nema lokalnih servera koji bi se koristili za upravljanje parcijalnim podacima. Shodno tome nije potrebno ni postojanje sistema za asinhroni prenos podataka. Sa stanovišta komunikacija, ovaj sistem se oslanja na bilo koju širokopojasnu (broadband) internet vezu, u opsegu od jednostavne broadbend veze, preko iznajmljene bakarne parice do optičkog linka. Za komunikaciju će se koristiti kriptovani https protokol (tunelovanje). Ova arhitektura omogućava:

-Jednostavno i efikasno održavanje sistema.

-Efikasnu administracija bezbjednosti sistema.

-Upravljanje sigurnosnim kopijama podataka.

Ponuđač mora da ponudi zakup CLOUD platforme za predmetnu centralnu lokaciju sistema. Dakle, nije predviđena nabavka servera i drugih data centar” komponenti koje bi bila instalirane u prostorijama D.O.O. KOMUNALNO KOTOR Kotor. CLOUD platforma će omogućiti jednostavno povezivanje udaljenih organizacionih jedinica i omogućiti nesmetan, jednostavan, pristup sistemu direktno sa bilo koje lokacije (iz kancelarije, od kuće, sa telefona i sl.) što će pokriti i potrebu za poboljšanjem kontinuiteta poslovanja u situacijama lock down”-a kakav je bio u periodu pandemije Covid-19.

Sa CLOUD platformom ponuđač će biti obavezan da obezbijedi i adekvatne dnevne backup procedure za kreiranje rezervnih kopija podataka kao i da obezbijedi oporavak sistema.

CLOUD platforma mora posjedovati i desister recovery” podsistem za brzi oporavak sistema u slučaju havarije na primarnoj lokaciji. Svaka transakcija u bazi podataka mora biti automatski prenešena na desister recovery” platformu u roku od max 1s zakašnjenja (active-passive cluster princip). | 1 Paket

16. Implementacija i obuka korisnika | Na kraju instalacije i testiranja svih komponenti IS-a tim koji upravlja projektom će usvojiti plan implementacije i plan obuke korisnika na predlog Izvođača. Izvođač je dužan da sprovede obuku korisnika, instalira i implementira IS. Prije početka implementacije Izvođač je dužan da isporuči korisničku dokumentaciju podijeljenu po aplikativnim modulima IS-a, kao i materijale za obuku, koji uključuju:

-korisnička uputstva koja moraju biti prilagođena korisnicima IS-a sa različitim nivoima iskustva u radu sa informacionim sistemima

-korisnička uputstva moraju biti dostupna unutar sistema svakom korisniku sistema

-uputstva za administraicju sistema

Izvođač je dužan da sprovede obuku za korišćenje svih softverskih modula za sve zaposlene koji će koristiti IS 50 korisnika IS-a i 2 administratora). Obuka će se organizovati u upravnoj zgradi preduzeća kao i u prostorijama organizacionih jedinica prema planu implementacije koji će biti usvojen. Odmah nakon obuke korisnika startuje se sa produkcionim korišćenjem PIS-a. | 1 Paket

17. Sistemska platforma | Sistemska platforma za IS mora biti zasnovana na Open Source tehnologijama, to jest bez potrebe dodatnog licenciranja platformskih proizvoda. Ukoliko ponuđač ponudi rješenje koje posjeduje komponente koje se dodatno licenciraju, sve cijene licenci moraju biti uključene u cijenu IS-a uz prateće godišnje obnove za 5 godina. Svi eventualni skriveni troškovi padaju na teret Isporučioca.

Nabavka računarskog hardvera i sistemskih softvera (operativni sistemi i drugo) nije predmet ovog dokumenta. | 1 Paket

18. Migracija podataka | Predviđa se migracija podataka iz postojećih informacionih sistema u vidu migracije šifarnika komitenata, artikala i usluga, početnih stanja u magacinima, početnih stanja finansija po kontima i sl. Naručilac će obezbijediti podatke za migraciju u vidu excel fajlova. Implementacija novog sistema podrazumijeva import početnog stanja u svim modulima IS-a:

-U finansijama po kontima

-U finansijama kompletna migracija Glavne knjige kako bi se obezbijedile kartice komitenata i za prethodni period

-U kadrovima početno stanje zaposlenih i ugovora

-U materijalnom i trgovini, početno stanje magacina

-U ugovorima, početno stanje svih ugovora na osnovu kojih će se vršiti obračun kao i evidencija stambenih i poslovnih prostora

-U osnovnim sredstvima – importovati popis osnovnih sredstava kao početno stanje | 1 Paket

19. Dokumentacija | Korisnička dokumentacija za aplikativne softvere koja mora biti isporučena uključuje, ali se ne ograničava samo na:

- Korisnička uputstva za aplikativne softvere u sklopu samog softvera i u formi pogodnoj za štampu (opis sistemskih funkcija, uputstva za sve komponente sistema i sve korisničke uloge, uputstva za administrativne module)

- On-line sistem za pomoć korisnicima (ticketing sistem) – svaki korisnik sistema treba da dobije prava pristupa sistemu za prijavljivanje problema gdje će imati uvid u status prijavljenih problema i gdje će se pratiti i mjeriti odziv izvođača prilikom otklanjanja problema

- Uputstva za instalaciju i deinstalaciju sistema

Korisnička dokumentacija ne smije samo objasniti način korišćenja softvera, već mora objasniti i značenje: na primjer, nije dovoljno samo reći da je neko polje obavezno za unos nego se mora objasniti i razlog zbog čega je to tako, šta je značenje određenog atributa, i sl. | 1 Paket

Vrsta predmeta: Robe

Vrsta postupka: Otvoreni postupak

Službenik za javne nabavke: Aleksandar Popović

Kontakt: 032322080

Datum objave: 2022-05-27 14:00:00

Napomena

-------------------------------------------------------------

Procijenjena vrijednost nabavke: 41320 EUR

-------------------------------------------------------------

ROKOVI

Početak podnošenja: 27.05.2022 14:00

Kraj podnošenja: 29.06.2022 12:00

Datum otvaranja: 29.06.2022 12:00

Rok za donošenje odluke: 29.07.2022 12:00