Hermetis
Technology · Podgorica
Looks solidNo risk signals
- Revenue 2025
- 216,066€
- Profit 2025
- 57,673€
- Employees
- 1
- Public contracts won
- 385,650€
11 public contracts from 1 buyer since 29 Nov 2022 · 11 with this buyer (385,650€)
Small procurement · Services
Contract awarded
To Hermetis
Technology · Podgorica
11 public contracts from 1 buyer since 29 Nov 2022 · 11 with this buyer (385,650€)
PREDMET NABAVKE 1. MINISTARSTVO UNUTRAŠNJIH POSLOVA - Izrada softvera za proširenje Case Management Systema CPV: 72212100 Procijenjena vrijednost: 15975 EUR USLOVI UČEŠĆA 1. Ponuđač je dužan da uz ponudu dostavi izjavu o ispunjenosti uslova utvrđenih zahtjevom i nepostojanju sukoba interesa, potpisana od strane ovlašćenog lica ponuđača, koja se sačinjava na Obrascu 2. 2. Kvantitativnu i kvalitativnu kontrolu kvaliteta će sprovoditi službenici Sektora za finansijsko-obavještajne poslove. 3. Virmanski. 4. Rok izvršenja Ugovora je četiri mjeseca od dana obostranog potpisivanja Ugovora. 5. Razvoj sofvera mora da se vrši isključivo u prostorijama Sektora za finansijko obavještajne poslove, u Podgorici, i na razvojnom okruženju koje je instalirano na opremi koja je vlasništvo Sektora za finansijko obavještajne poslove. 6. Detalji realizovanog CMS-a ne mogu biti dio zahtjeva za podnošenje ponuda i o njima će biti upoznat izabrani dobavljač u skladu sa propisima Sektora za finansijko obavještajne poslove. CMS je realizovan u .net tehnologiji. 7. Ponuđač mora ispunjavati uslove propisanim internim aktom Sektora za finansijsko obavještajne poslove u skladu sa članom 88. stav 3. Zakona o sprečavanju pranja novca i finansiranja terorizma. Na zahtjev ponuđači se mogu upoznati sa aktom u prostorijama Sektora za finansijsko obavještajne poslove uz potpisivanje izjave o pristupu tajnim podacima, a u skladu sa propisima kojima se reguliše zaštita tajnih podataka. 8. Ponuđač mora dostaviti najmanje tri reference realizovane u sektoru bezbjednosti, u poslednje tri godine, koje se odnose na realizaciju sličnih softverskih rješenja koja su realizovana u .net tehnologiji i MSSQL Database. 9. Ponuda mora da sadrži sledeće klauzule: 1. Dobavljač preuzima obavezu da izvrši sve svoje obaveze i zaduženja navedena u daljem tekstu uz svu pažnju i u skladu sa zakonima i drugim aktima, kao i etičkim normama i dobrom praksom posla o kojem je riječ. 2. Dobavljač je odgovoran da osigura da osoblje angažovano od strane Dobavljača, koji izvršava posao i isporuku obuhvaćenu Ponudom, svo vrijeme imaju potrebna ekspertska znanja, obrazovanje i iskustvo kako bi se sve obaveze Dobavljača navedene u okviru Ponude izvršile. Dobavljač treba da zamijeni, u roku koji Sektor za finansijko obavještajne poslove (SFOP) odredi pisanim obavještenjem, bilo kog člana osoblja za koga SFOP smatra da nema potrebna ekspertska znanja, obrazovanje ili iskustvo, ili one sa kojima SFOP ima poteškoća u saradnji. 3. Dobavljač je obavezan da, na opremi SFOP-a, formira razvojno i testno okruženje u roku od 30 (trideset) dana od dana prihvatanja Ponude. 4. Dobavljač će razvoj sofvera vršiti isključivo u prostorijama SFOP-a i na razvojnom okruženju koje je instalirano na opremi koja je vlasništvo SFOP-a. 5. Obaveza Dobavljača je da izradi dokument (u daljem tekstu: Funkcionalni zahtjevi) koji predstavlja Specifikaciju funkcionalnosti produkta i koji treba da sadrži najmanje: aktivnosti koje se planiraju izvesti kao zahtjevi, izvore, aktere, ulazne podatke/dokumente, izlazne dokumente, model podataka, preliminarni user interface, validacije i poslovna pravila (workflow). Funkcionalne zahtjeve treba da odobri ili da primjedbe, SFOP u roku od pet dana od njihovog dobijanja od strane Dobavljača. Ako je SFOP dao primjedbe na Funkcionalne zahtjeve Dobavljač je dužan da ih ispravi u roku od pet dana i dostavi SFOP na odobrenje. 6. Ako Dobavljač i SFOP ne usaglase Funkcionalne zahtjeve, odnosno ako SFOP ne potpiše saglasnost na funkcionalne zahtjeve, u roku od 25 dana od dana prihvatanja Ponude SFOP će prekinuti ovaj posao bez ostavljanja dodatnog roka i bilo kakve naknade Dobavljaču. 7. Obaveza Dobavljača je da za svaku fazu definisanu u Projektnom planu navedenog u Ponudi SFOP-u dostavi predlog testova operativne primopredaje. Testove operativne primopredaje treba da odobri ili da da primjedbe SFOP u roku od pet dana od njihovog dobijanja od strane Dobavljača. Ako je SFOP dao primjedbe na Testove operativne primopredaje Dobavljač je dužan da ih ispravi u roku od pet dana i dostavi SFOP-u na odobrenje. Ako po dobijanju predloga Testova operativne primopredaje SFOP ne da primjedbe u roku od pet dana smatra se da je iste odobrio. 8. Format testova operativne primopredaje treba da bude: • Broj testa: • Naziv testa: • Veza sa: Funkcionalni zahtjevi za fazu : • Koraci u sprovođenju testa: • Očekivani rezultati: 9. Uslovi sadržani u tačkama od 12 do 17 će se primjenjivati za razvoj i prihvatljivost Softvera, kao i na, bez izuzetka, sva naknadna release/izdanja, naknadno nadograđivanje, poboljšanje i naknadne verzije. 10. Dobavljač će razviti Softver na način što će isti odgovarati zahtjevima navedenim u Projektnom zadatku i na taj način primijeniće standarde i procedure i zadovoljiti vremenske okvire i faze navedene u Projektnom planu. 11. Dobavljač se slaže da iscrpno testira Softver, uključujući (bez ograničenja) i bez izuzetaka sva njegova naknadna release/izdanja, naknadno nadograđivanje, poboljšanje i naknadne verzije, na odgovarajući način u okolnostima, u svim odgovarajućim fazama razvoja, i dokumentovaće njegovo testiranje u testovima u pisanoj formi koje dostavlja SFOP-u. Dobavljač će dostaviti svoje planove za testiranje SFOP-u na pregled, kako bi osigurao da se održavaju SFOP-ovi standardi o kvalitetu. Dobavljač se takođe slaže da naknadno modifikuje planove za testiranje kako bi prilagodio zahtjeve SFOP-a ako on smatra da je neka promjena potrebna ili odgovarajuća. Takvi testni dokumenti će sadržati detaljni opis testova kako se sprovode, i testnih rezultata, uključujući (bez ograničenja) listu nastalih programskih grešaka i listu važnih pitanja. 12. Odmah nakon završetka svake razvojne faze navedene u vremenskom rasporedu u Ponudi, Dobavljač će postaviti Softver i dostaviti dokumentaciju i ostali materijal, koji je potreban da se obezbijedi, u skladu sa rasporedom. SFOP će imati pet (5) radnih dana od postavljanja Softvera da izvrši inspekciju, testiranje i procjenu Softvera kako bi utvrdio da li Softver zadovoljava kriterijume prihvatljivosti u skladu sa procedurama u Projektnom zadatku, ili koje je utvrdio Dobavljač, a odobrio SFOP prije testiranja. 13. Ako Softver ne zadovoljava kriterijume prihvatljivosti, SFOP-u će Dobavljaču dostaviti obavještenje u pisanoj formi navodeći zašto je Softver neprihvatljiv. Dobavljač će imati pet (5) radnih dana od dana prijema obavještenja da ispravi nedostatke. SFOP će zatim imati pet (5) radnih dana da izvrši inspekciju, testiranje i ponovnu procjenu Softvera. Ako Softver i dalje ne zadovoljava kriterijume prihvatljivosti, SFOP-u će imati sledeće opcije: i) ponavljanje procedure koja je gore navedena, ili ii) da prekine ovaj posao bez ostavljanja dodatnog roka. Ako SFOP ne dostavi obavještenje u pismenoj formi Dobavljač u toku početnog petodnevnog perioda za vršenje inspekcije, testiranja i procjene ili u toku bilo kojeg produžetka toga perioda, da Softver ne zadovoljava kriterijume prihvatljivosti, za SFOP će se smatrati da je prihvatio Softver nakon isteka toga perioda. 14. Nakon završetka finalne razvojne faze navedene u vremenskom rasporedu u Ponudi, testiranje prihvatljivosti će biti izvršeno na Softveru u njegovoj cjelosti kako bi se utvrdilo da li Softver zadovoljava kriterijume prihvatljivosti i da li radi na način koji suštinski odgovara Specifikacijama u Projektnom zadatku. SFOP će imati maksimum deset (10) radnih dana da izvrši takvo testiranje. Ako završeni Softver ne zadovoljava kriterijume prihvatljivosti, stranke će pratiti procedure o prihvatljivosti navedene u prethodnim tačkama. 15. Ako i kada se na testovima prihvatljivosti utvrdi da je razvijeni Softver nakon završetka bilo koje razvojne faze u skladu sa kriterijumima prihvatljivosti, SFOP će odmah obavijestiti Dobavljača da je razvijeni Softver prihvatljiv. 16. Dobavljač prenosi SFOP-u njegovo cjelokupno pravo, naziv i interes u bilo čemu što je kreirao ili razvio Dobavljač za SFOP-u u okviru ove Ponude (u daljem tekstu: Radni proizvod) uključujući patente, autorsko pravo, poslovnu tajnu i druga vlasnička prava. 17. Dobavljač će pratiti i pomagati u pripremi bilo koje dokumentacije potrebne da se osigura bilo koje autorsko pravo, patent, ili druga prava u vezi intelektualne svojine u Radnom proizvodu besplatno za SFOP. 18. Source code je vlasništvo SFOP-a. Za svaku fazu realizacije obaveza Dobavljača je da SFOP-u na optičkom medijumu preda source code. 19. Dobavljač garantuje da će za jednu (1) godinu (u daljem tekstu: Održavanje aplikacije) nakon uspješno završenih testova operativne primopredaje Softver biti oslobođen od materijala koji reprodukuje programske greške i kvarove/neispravnosti u stručnosti i materijalu, i biće adekvatan Specifikacijama iz Projektnog zadatka ako bude radio u skladu sa instrukcijama Dobavljača. Ako materijal koji reprodukuje programske greške bude otkriven tokom Održavanje aplikacije, Dobavljač će ih odmah popraviti. Ova garancija će biti nevažeća ako do nesaglasnosti dođe iz jednog ili više sledećih razloga: i. Nedostaci u Hardveru zbog kvarova, problema sa strujom, problema životne sredine ili bilo kojeg drugog uzorka osim samog Softvera; ii. Modifikacija Softvera operativnog sistema ili kompjuterskog Hardvera bez konsultacije sa Dobavljačem; iii. Zloupotreba i greške u radu sa Softverom od strane zaposlenih SFOP-a, 20. Dobavljač nije obavezan da popravlja bilo koji nedostatak osim ako SFOP obavijesti Dobavljača o postojanju i prirodi nedostatka nakon što je nedostatak ustanovljen. 21. Dobavljač garantuje da nijedan dio Softvera ili dokumentacije, obuhvaćeni ovom Ponudom, neće sadržati osobinu zaštite (protection feature) koja je dizajnirana da spriječi korišćenje Softvera. Ovo, uključuje, bez ograničenja, bilo koji kompjuterski virus, worm, software lock, drop dead uređaj, Trojan-horse program, trap door, time bomb ili bilo koji drugi kod ili instrukcije koje se mogu iskoristiti za procjenjivanje, modifikovanje, brisanje, oštećenje ili onesposobljavanje Korisničkog Softvera ili kompjuterskog sistema. 22. Dobavljač mora nadoknaditi i omogućiti nepovredivost SFOP-u od i protiv žalbi ili akcija od strane bilo koje ili svih trećih stranaka, uključujući gubitke, troškove, odgovornosti, realne naknade za advokata i druge troškove koji nastaju usled takvih tužbi ili akcija, navodeći razlog da Softver povrjeđuje ili krši autorsko pravo, marku, patent ili poslovnu tajnu treće strane, pod uslovom da: i. SFOP odmah pisano obaviještava o bilo kojoj tužbi Dobavljača; ii. Dobavljač ima isključivu ulogu odbrane od takve tužbe i svih pregovora za postizanje pogodbe ili kompromisa; iii. SFOP obezbjeđuje razumnu saradnju sa Dobavljačem. 23. U bilo kojoj akciji koja se bazira na žalbi o povredi, Dobavljač mora na svoj trošak (i) dobiti za SFOP pravo da nastavi sa korišćenjem Softvera, ili (ii) zamijeni ili modifikuje Softver sa Softverom koji ne uzrokuje povrede obezbjeđujući istu funkcionalnost. 24. Tokom trajanja ovog Posla (rok za realizaciju ponude dat u ponudi odabranog dobavljača) i deset godina nakon njegovog isteka, stranke (Dobavljač i SFOP) će biti razumno pažljive u spriječavanju neovlašćenog korišćenja ili distribucije povjerljivih informacija druge stranke. Razumna pažnja podrazumijeva najmanje isti stepen pažnje koji stranke koriste za zaštitu svojih sopstvenih povjerljivih informacija od neovlašćenog objavljivanja. KRITERIJUMI ZA IZBOR Partija 1: cijena 100 bodova; kvalitet 0 bodova. 1. Cijena TEHNIČKA SPECIFIKACIJA 1. proširenje Case Management Systema 1. Dorada Portala FOJ-a Potrebno je prošiti Portal FOJ-a u skladu sa implementacijom novog Zakona o sprečavanju pranja novca i finansiranja terorizma 2. Prosirenje poziva eksternim servisima a. poziv servisu Centralnog registra stanovništva Potrebno prosiriti poziv servisu Građanska Stanja za sledeće parametre: imena roditelja, rođeno prezime, pol. Rezultat pretrage treba da prikazuje navedene podatke. Kod poziva servisa GS iz forme “Pretrage entiteta lica”, ukuliko je rezultat pretrage više lica za svako lice treba prikazati sve raspoložive podatke koje vraćaju servisi MUPa. b. poziv servisu CROO i FIN Potrebno je proširiti poziv srervisu Uprave carina i prihoda za pravna lica na osnovu specifikacije web servisa. c. poziv servisu UP Redizajnirati poziv servisa u pogledu učitavanja nomenklatura na način da se isto izvršava prilikom poziva tačno određenog servisa. d. monitoring rada servisa externih servisa Potrebno je dodati „job“ za provjeru dostupnosti servisa koje koristi CMS. Job treba da prilikom pokretanja aplikacije, kao i u toku rada sa istom povremeno provjeri dostupnost svih servisa i o istom prikaže notifikaciju službeniku. Period za provjeru dostupnosti servisa treba da bude konfigurabilan. 3. Monitoring rada servisa a) za rad servisa FOJ-a Potrebno je napraviti monitoring rada servisa FOJ-a. Kroz monitorinog treba da se prikazuje rad servisa: koliko puta se pristupalo servisu u zadatom periodu, broj dostavljenih odgovora od strane servisa u zadatom periodu. 4. Promjena stepena tajnosti predmeta Potrebno je doraditi modul za promjenu stepena tajnosti sa veceg na manji, tj ukidanja stepena tajnosti na osnovu rješenja, odnosno istekom rješenja. Kod kreiranje predmeta, ukoliko je predmet klasifikovan donosi se rješenje o stepenu tajnosti. Istekom ovog rješenja, predmet po automatizmu treba da postane nekalsifikovan, a notifikaciju o istom treba poslati rukovodicu odsjeka I nosiocu predmeta. Ukoliko se donese rješenje o ukidanju ili smanjenju stepena tajnosti, isto je potrebno kreirati kroz modul za rješenja u CMS, a zatim na osnovu njega promjeniti stepen klasifikacije predmetu. Ukoliko je rješenje o ukidanju / promjeni donošeno od strane drugog organa, isto je potrebno prvo skenirati kroz modul za rješenja o stepenu tajnosti pa tek onda promjeniti stepen predmetu. 5. Modul za storniranje dostavljenih izvještaja Za administratore CMS-a je potrebno dodati modul kojim se vrši stortniranje pogrešno unijetih izvještaja od strane obveznika i Carina. Navedeni modul je potrebno da omogući pregled svih dostavljenih / unijetih izvještaja za određeni vremenski period, gdje je pored datuma kriterijum pretrage bira obveznik, broj komunikacije i osnovni podaci o komunikaciji (podaci koji se koriste u listi pregleda). Nakon pronalaska odgovarajuće komunikcije, omogućiti storniranje iste uz obavezan unos razloga storniranja. Storniranje u CMS treba da obrise i tx na portalu. 6. Pregled komunikacija i priloga u predmetu U CMS, u predmetu, u listi pristiglih komunikacija, potrebno je označiti komunikacije koje su od strane obveznika označene statusom „lice nije umatičeno“ kao i omogućiti službeniku da komunikacije sa ovim statusom može da sakrije iz liste, odnosno ponovo prikaže. Listu pristiglih / poslatih komunikacija je potrebno reorganizovati u odnosu na postojeće, zbog velikog broja odgovora koji stiže. Odgovore koji stižu od istog obveznika, za isti entitet, potrebno je spojiti u jedan odgovor s obzirom da obveznici imaju mogućnost parcijalnog odgovaranja na zahtjev vezan za jedno lice. U tab-u prilozi iz komunikacija, radi boljeg pregleda priloga potrebno je napraviti „stablo“ po obvezniku koji je poslao prilog, kao i za priloge koji su vezani direktno za entitete. 7. Aplikacija za publikaciju aplikacija Potrebno je napraviti aplikativno rješenje za publikovanje aplikacija koje koristi FOJ. Aplikacija se pokreće nakon logovanja službenika na računar, i prikazuju se aplikacije na koje službenik ima pravo pristupa. Prilikom pokretanja dostupne aplikacija, ista vrši provjeru da li postoji nova verzija aplikacije. Ukoliko postoji, vrši preuzimanje uz poruku „preuzimanje nove verzije“ koja se prikazuje službeniku. Nakon uspješnog preuzimanja, aplikacija se pokreće. Ukoliko nema novih verzija aplikacija, aplikacija se odmah pokreće. Publikaciju aplikacija treba da vrši administrator, na centralnom serveru (FS). Takođe, na istom serveru se postavljaju i nove verzije aplikacija. Pojašnjenje razvojnog okruženja Opis sistema Case Managament - Korištene tehnologije • CM o Database layer – Microsoft SQL server 2019 verzija. Stored porcedure, UDF funkcije, JOB-ovi o Srednji sloj : C#, dot.net 4.7, servisi na WCF (windows communication foundation), o Klijentske bioblioteke za eksterne servise (MUP, UP, SUD, MIN Pravde itd...) C#, dot.net 4.7, SOAP klijenti , REST servisi klijent, WCF servise klijent, CSLA.NET framework o Aplikacija CM: desktop win forms aplikacija, dot.net 4.7 , C#, DevExpress v21.1, kontrole, CSLA.NET framework • Portal o Database layer – Microsoft SQL server 2019 verzija, Stored porcedure, UDF funkcije. o Srednji sloj i web aplikacija: C#, dot.net 4.7, ASP.MVC 5, CSLA.NET framework o UI na veb stranama: javascript, KnockoutJS i JQuery javascript biblioteke, HTML i CSS o Servis za preuzimanje podataka sa portala : C#, dot.net 4.7, ASP WEB API Količina: 1 količina DOKUMENTI 1. Obavještenje.PDF https://cejn.gov.me/api/common/downloadFile/1992926 2. Izrada softvera za proširenje Case Management Systema.PDF https://cejn.gov.me/api/common/downloadFile/2005651
| Supplier | Contract status | Awarded | VAT | Contract date |
|---|---|---|---|---|
| hermetisPIB 02947021 | Published | €15,150 | €3,181.50 | 8 Oct 2024 |
0 matched payments
No treasury payments matched yet.
Matching is heuristic, using entity-name normalization and a 24-month payment window. Open the supplier payment history for the full picture.
| Lot | Status | Estimated | Awarded | Contract date |
|---|---|---|---|---|
| Lot 1 | Awarded | — | €15,150 | 8 Oct 2024 |
Awards in this category usually come in at 100% of the estimate (middle half 97%–100%), across 740 awarded tenders. A typical contract is 20,200€.
This tender: 95% of its estimate.