Održavanje i unapređenje aplikativnog dijela informacionog sistema elektronske fiskalizacije i pripadajuće softverske infrastrukture Poreske uprave

Naziv: PORESKA UPRAVA

PIB: 11069169

E-mail: poreskauprava@tax.gov.me

Telefon: 020/448-114

Fax: 020/448-234

Internet adresa: https://www.poreskauprava.gov.me

Adresa: Bulevar Šarla de Gola 2

Grad: Podgorica

Poštanski broj: 81000

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

OSNOVNI PODACI

Opis predmeta javne nabavke

Održavanje i unapređenje aplikativnog dijela informacionog sistema elektronske fiskalizacije i pripadajuće softverske infrastrukture Poreske uprave

TEHNIČKA SPECIFIKACIJA PREDMETA NABAVKE

1. Održavanje i unapređenje aplikativnog dijela informacionog sistema elektronske fiskalizacije i pripadajuće softverske infrastrukture Poreske uprave | 2.1.ARHITEKTURA SISTEMA I DIZAJN

EFI sistem je baziran na aplikacionom softveru koji sadrži sve potrebne module.

Na slici ispod je konceptualna šema aplikacija. Fizički prikaz je u šemi ispod. 2.2.NAMJENA I SMJEŠTAJ HARDVERA

EFI sistem Poreske uprave je definisan kao kritičan sistem i implementiran kao sistem visoke dostupnosti (HA). Pouzdanosti i zaštita od gubitka podataka je postignuta uspotvaljanjem redudantnih podsistema na dvije lokacije, primarnoj lokaciji u Podgorici u okviru data centra Poreske uprave Crne Gore i sekundardnoj lokaciji (rezervnoj - disaster recovery) u okviru DR Data centra organa državne uprave u Bijelom Polju. U okviru svakog od podsistema je odabrana i instalarina serverska i mrežna oprema koja obezbjeđuje najviši nivo pouzdanosti i performantnosti kroz eliminisanje pojedinačnih tačaka ispada čime je obezbijeđen kontinuitet poslovanja u slučaju incidenta na primarnoj lokaciji.

Sva serverska oprema je odabrana tako da obezbijedi odgovarajuće performanse sistema, neophodne za nesmetan rad online fiskalizacije u realnom vremenu, u svim uslovima, uključujući kritične periode kada se očekuje maksimalni broj transakcija u kratkim vremenskim intervalima. Mrežna oprema je odbrana, postavljena i konfigurisana tako da se potpuno integriše u informacioni sistem Poreske uprave i mrežu državnih oragana Crne Gore. Osim toga, njenim postavljanjem je obezbijeđen najveći mogući stepen zaštite od malicioznih uticaja koji bi mogli ugroziti rad EFI sistema, incidenata u smislu otkaza pojedinih komponenti sistema, sa obezbijeđenim visokim nivoom dostupnosti i pouzdanosti sistema.

Standardni softver koji obuhvata sistem za upravljanje bazama podataka, operativnim sistemima i serverskom infrastrukturom je odabran i konfigurisan da zadovolji sve uslove definisane planom implementacije. Kompletna konfiguracija instaliranih servera, mrežne opreme i softvera je izvedena tako da vrijeme zastoja sistema zbog otkaza jedne ili više komponeti (RTO) i eventualni gubitak transakcija (RPO) budu svedeni na najmanju moguću mjeru.

Na svim serverima koristi se Oracle Linux operativni sistem. Na aplikativnim serverima je postavljen Oracle Web Logic Web server softver koji podržava rad svih aplikativnih modula EFI sistema.

Kompletna infrastruktura je, radi obezbijeđenja maksimalne dostupnosti i performantnosti organizovana tako da aplikativni serveri na obje lokacije budu sve vrijeme aktivni. Pristup prema njima je optimizovan Load Balancer uređajima postavljenim ispred aplikativnih servera na obje lokacije uz primjenu odgovarajućih težinskih koeficijenata koji obezbjeđuju optimalnu raspodjelu saobraćaja po lokacijama.

Istovremeno aktivni server baze podataka je na primarnoj lokaciji, dok je server baze na sekundarnoj lokaciji pasivan. Podaci se između njih sinhronizuju u realnom vremenu, a u slučaju zastoja radnog servera, rezervni odmah preuzima sav posao do ponovnog aktiviranja servera baze na primarnoj lokaciji. U slučaju bilo kakvog planiranog isključenja jednog od servera zbog održavanja, prebacivanje sa radnog na rezervni i obrnuto se radi jednostavno i centralizovano, a podaci se nakon ponovnog uključenja sinhronizuju potpuno automatski.

Rezervne kopije svih podataka se na obje lokacije formiraju nezavisno, tako da je opasnost od bilo kakvog gubitka podataka gotovo sasvim isključena. SISTEM ZA UPRAVLJANJE VIRTUELNIM OKRUŽENJEM

Virtuelno okruženje podignuto je na dvije lokacije, i to: -primarna lokacijia sadrži pet fizičkih uređaja namijenjenih za potrebe poslužitelja (servera) virtuelnog okruženja (host –VH). Od toga četiri uređaja služe za potrebe produkcionog virtuelnog okruženja, odnosno produkcionih virtuelnih mašina (VM), dok je jedan uređaj (VH) namijenjen za potrebe testnog virtuelnog okruženja, odnosno testnih VM.

-DR lokacija sadrži dva fizička uređaja namijenjena za potrebe poslužitelja (servera) virtuelnog okruženja (host –VH). Ovi uređaji služe za potrebe produkcionog virtuelnog okruženja, odnosno produkcionih virtuelnih mašina (VM) na DR lokaciji. ZFS STORAGE SISTEM Po jedan ZFS storage sistem je smješten na obje lokacije. Svaki sistem sastoji se od po 2 storage kontrolera i dodatnih šasija za diskove. Nazivi storage kontrolera su su: przscu1 i przscu2 (PRIM) , odnosno drzscu1 i drzscu1 (DR). BACKUP SERVERI Po jedan Backup server, je smješten na obje lokacije. Na DR lokaciji, Backup server je ujedno i server za upravljanje virtuelnim okruženjem. MGMT i OGW SERVERI Mgmt i OGW serveri su smješteni na PRIM lokaciji. Mgmt je server za upravljanje virtualizacijskom okolinom, dok je OGW server Oracle Advanced Gateway za Platinum support. BACKUP TAPE LIBRARY (čuvanje podataka na magnetne trake) Na obije lokacije, uz backup servere smješten je po jedan Backup TAPE library sistem. EXADATA Na obije lokacije smješten je po jedan Exadata database sistem. 2.3.PODSISTEMI Sistem se sastoji od sljedećih podsistema:

•FISKALNI SERVIS – WEB servis za evidentiranje prometa kroz fiskalizaciju gotovinskih i bezgotovinskih računa

•SEP – Samouslužni EFI portal namijenjen poreskim obveznicima koji su obveznici fiskalizacije

•CPKU – Centralni portal za kontrolu i upravljanje namijenjen za potrebe službenika Poreske uprave.

•MAPR – Aplikacija za provjeru računa publikovana na javnu mrežu (internet), služi za provjeru svih računa evidentiranih i izdatih putem ENU-a. Predmetnu aplikaciju koriste sva lica koja vrše provjeru validnosti računa koji dobiju od prodavca odnosno pružaoca usluge, prilikom kupovine proizvoda i/ili izvršene usluge. 2.3.1. FISKALNI SERVIS Servis za fiskalizaciju gotovinskih i bezgotovinskih računa. Servis je izveden kao Web servis (SOAP preko HTTPS), sa strogo definisanim WSDL-om u Java programskom jeziku, korištenjem Spring Boot, Spring WS tehnologija. Autentifikacija i autorizacija klijenata se obavlja pomoću provjere elektronskog potpisa primljene XML poruke. Potpis se generiše kao envelope tip korištenjem https://www.w3.org/TR/xmldsig-core/. 2.3.1.1.Registracija ENU i softvera na ENU Poreski obveznik je dužan da izvrši registraciju ENU prije nego što počne da izdaje i fiskalizuje račune, i to svih ENU na kojim evidentira promet odnosno sa kojih će izdavati i fiskalizovati gotovinske i bezgotovinske račune. 2.3.1.2.Registracija gotovinskog depozita na ENU Poreski obveznik koji je obveznik fizkalizacije dužan je putem fiskalnog servisa, na početku svakog radnog dana, tj. prije početka obavljanja prometa i izdavanja računa, evidentirati gotovinski depozit za svaki ENU putem kog vrši evidentiranje prometa plaćenog gotovinom za taj radni dan. 2.3.1.3.Fiskalizacija računa Poreski obveznik koji je obavezan da izdaje račune i vrši proces fiskalizacije, obavezan je po zakonu da fiskalizuje sve račune za gotovinske i bezgotovinske transakcije. Fiskalizacija znači da se svi izdati računi, kako gotovinski tako i bezgotovinski, evidentiraju u bazi podataka UPC, u realnom vremenu upotrebom fiskalnog servisa EFI sistema UPC. 2.3.1.4.Fiskalizacija korektivnih gotovinskih ili bezgotovinskih računa Poreski obveznik ne može jednostavno korigovati neki izdati gotovinski ili bezgotovinski račun, ili ako kupac vrati robu ili ako je nešto pogrešno na računu koji je izdat i fiskalizovan, p

oreski obveznik može izdati korektivni račun koji se poziva na prvobitni račun čija se ispravka vrši. U slučaju kada nema internet veze, poreski obveznik prvo mora fiskalizovati prvobitni račun, a potom korektivni. 2.3.1.5.Fiskalizacija sumarnih računa Sumarni račun je račun koji obveznik fiskalizacije izdaje određenom kupcu/potrošaču/korisniku usluge, za izvršen promet za koji je na pojedinačnim računima naveden način plaćanja ORDER. Pojedinačni računi na koje se sumarni račun referencira mogu sadržati isključivo način plaćanja ORDER, što ukazuje da u momentu izdavanja ovog računa kupac nije izvršio plaćanje i nije bio poznat način plaćanja tog računa. Sumarni račun je informativnog karaktera i ne stvara obaveze obvezniku fiskalizacije u smislu evidentiranog prometa i obračunatog PDV-a iskazanog na računu, iz razloga što je taj promet i obračunati PDV već evidentiran kroz izdavanje pojedinačnih računa na koje se sumarni račun referencira, već služi kao informativni račun u smislu određivanja načina plaćanja svih pojedinačnih računa sa definisanim načinom plaćanja ORDER. Sumarni račun sadrži podatak o načinu plaćanja u momentu plaćanja od strane kupca svih pojedinačnih ORDER računa.

2.3.1.6.Fiskalizacija periodičnih računa Periodični račun je račun koji obveznik fiskalizacije izdaje određenom kupcu / potrošaču / korisniku usluge, za izvršen promet u toku obračunskog perioda (kalendarski mjesec). Ovaj račun je informativnog karaktera i ne stvara obaveze obvezniku fiskalizacije u smislu evidentiranog prometa i obračunatog PDV-a iskazanog na računu, iz razloga što je taj promet i obračunati PDV već evidentiran kroz izdavanje pojedinačnih računa na koje se periodični račun referencira. Pojedinačni računi na koje se periodični račun referencira mogu sadržati bilo koji definisani način plaćanja u poljima vezanim za način plaćanja (ORDER, BANKNOTE, ACCOUNT, ADVANCE,...). Periodični račun ne sadrži podatak o načinu plaćanja.

2.3.1.7.Fiskalizacija avansnih računa Ovim tipom računa se evidentira izdavanja avansnog računa nakon izvršene avansne uplate u poslovnicama koje se bave maloprodajom i veleprodajom. Avansna uplata može se odnositi na jedan ili više proizvoda odnosno usluga, koje prodavac odnosno pružaoc usluga ima u svom asortimanu, a kao posljedicu avansne uplate, prodavac kupcu, osim avansnog računa, može izdati vaučer, poklon karticu, kompanijsku karticu, ili neku drugu vrstu finansijskog dokumenta ili kartice kojom kupac može izvršiti plaćanje prilikom kupovine proizvoda odnosno korišćenja usluge (SVOUCHER ili COMPANY).

2.3.1.8.Fiskalizacija knjižnih odobrenja Ovim tipom računa se evidentira izdavanje knjižnog odobrenja u poslovanju između dva lica, a što se može odnositi na korekciju prometa nastalog uslijed naknadnog popusta ili povraćaja određenih proizvoda ili korekcije prometa nastalog u smislu ne ostvarivanja određene usluge, a u skladu sa mogućim ugovornim odnosima između prodavca/dobavljača/pružaoca sa jedne i kupca/komintenta/korisnika sa druge strane.

2.3.2.SEP Samouslužni EFI portal je web aplikacija za poreske obveznike koji su obveznici izdavati fiskalne račune. Preko SEP-a korisnici će moći unijeti podatke relevantne za fiskalizaciju računa, pristupiti svim računima koji su mu pridruženi i pregledavati sve eventualne greške nastale u postupku fiskalizacije. SEP je namijenjen korisnicima, obveznicima fiskalizacije, i poreskim obveznicima u službi proizvođača i održavaoca softvera za fiskalizaciju. Funkcionalnosti SEP portala su podijeljene u nekoliko modula: •Registracija poreskog obveznika •Administracija podataka poreskog obveznika •Fiskalizacija računa •Proizvođači i održavaoci softvera. 2.3.2.1.Registracija poreskog obveznika Svaki poreski obveznik koji je obveznik e-fiskalizacije se mora prvo registrovati u Registar obveznika fiskalizacije (ROF), a što obavlja putem SEP portala. Da bi se registrovao preko SEP portala, potrebno je imati odgovarajući certifikat koji izdaju registrovana certifikaciona tijela u Crnoj Gori. Da bi poreski obveznik pristupio fiskalizaciji prvo je potrebno registrovati se u sistem.

2.3.2.2.Administracija podataka poreskog obveznika Kroz SEP portal poreski obveznik može uređivati opšte podatke o sebi:

•Kontakt lica •Adrese •Poslovne aktivnosti •Bankovni računi Osim opštih podataka o poreskom obvezniku, poreski obveznik može:

•Dodavati i uređivati svoje poslovne jedinice

•Dodavati i uređivati podatke o svojim elektronskim naplatnim uređajima

•Dodavati i uređivati podatke o svojim operaterima.

2.3.2.3.Fiskalizacija računa Vezano za fiskalizaciju računa poreski obveznik kroz SEP portal može:

•Pregledati sve fiskalizovane račune koje je fiskalizovao •Pregledati sve račune koji su prilikom fiskalizacije imali grešku. •Kreirati i fiskalizovati bezgotovinski račun

•Unijeti i pregledati gotovinske depozite po elektronskim naplatnim uređajima.

2.3.2.4.Proizvođači i održavaoci softvera

Svi proizvođači i održavaoci softvera za fiskalizaciju se moraju registrovati prije nego se njihov softver počne koristiti u fiskalizaciji. Proizvođači softvera kroz SEP portal registruju softver i verzije softvera koji se koriste u fiskalizaciji, mogu pregledati sve održavaoce koji održavaju njihove softvere i sve poreske obveznike koji fiskalizuju sa njihovim softverom i sa kojom verzijom njihovog softvera. Održavaoci softvera kroz SEP portal registruju softvere koje održavaju i gdje mogu pregledati sve poreske obveznike koji fiskalizuju sa softverom koji oni održavaju. 2.3.3.CPKU

CPKU portal je portal namijenjen službenicima Poreske uprave. Portal je podijeljen u nekoliko modula:

•Registar poreskih obveznika

•Registar softvera, proizvođača i održavaoca softvera

•Fiskalizacija računa

•Izvještaji o nepravilnostima

•Analitički izvještaji

•Statistički izvještaji

•Nadzor

•Registar ovjerenih knjiga računa.

2.3.3.1.Registar poreskih obveznika

Kroz registar poreskih obveznika službenik Poreske uprave pregledava podatke koje je poreski obveznik unio kroz SEP portal:

•Opšti podaci o poreskom obvezniku

•Podaci o poslovnim prostorima

•Podaci o elektroničkim naplatnim uređajima

•Podaci o operaterima.

Osim podataka koje je poreski obveznik unio kroz SEP portal kroz registar poreskih obveznika službenik Poreske uprave može vidjeti i sve aktivnosti koje je poreski obveznik radio vezano za fiskalizaciju računa po pojedinim nivoima poreskog obveznika:

•za cjelokupnog poreskog obveznika •po poslovnim jedinicama

•po elektroničkim naplatnim uređajima.

2.3.3.2.Registar softvera, proizvođača i održavaoca softvera

Kroz registar poreskih obveznika službenik Poreske uprave pregleda podatke koje su proizvođači odnosno održavaoci softvera unijeli kroz SEP portal (softveri i verzije koje oni proizvode tj. održavaju) i mogu pregledati koji poreski obveznici koriste koji softver za fiskalizaciju.

2.3.3.3.Fiskalizacija računa

Kroz modul fiskalizacije računa službenik Poreske uprave može učitavati i pregledati račune poreskih obveznika koji nemaju softver za fiskalizaciju i fiskalizuju svoje račune putem datoteke koja se upload-uje u sistem za fisklizaciju. Uz fiskalizaciju putem datoteke a ne slanjem kroz fiskalni softver Poreska uprava može u ovom modul i pregledati sve račune s greškama koji su stigli u sistem za fiskalizaciju. 2.3.3.4.Izvještaji o nepravilnostima

Službenici Poreske uprave kroz CPKU portal mogu pregledati sledeće izvještaje o nepravilnostima:

•Prijave građana

•Razlike u računima (obveznici) •Obveznici bez računa •Poslovne jedinice bez računa •Naplatni uređaji bez računa •Razlike u računima

2.3.3.5.Analitički izvještaji

Službenici Poreske uprave kroz CPKU portal mogu pregledati sledeće analitičke izvještaje:

•Izdati računi

•Računi obveznika po iznosu

•Odnos korektivnih i ukupnih računa

•Uporedni iznos prometa.

2.3.3.6.Statistički izvještaji

Službenici Poreske uprave kroz CPKU portal mogu pregledati sledeće statističke izvještaje:

•Djelatnost poslovnih jedinica u vremenskom intervalu •Status djelatnosti poslovnog prostora po regiji •Kategorija djelatnosti poslovnih jedinica

•Izvještaj o zakupodavcima

•Tip djelatnosti poslovne jedinice

•Proizvođači i održavaoci softvera

•Izvještaj o ukupnoj cijeni računa

2.3.3.7.Nadzor

Modul nadzora obuhvata nekoliko podmodula koji su prikazani na slici niže:

•Plan nadzora na nivou godine

•Registar prijava odnosno inicijativa za nadzorom

•Analiza podataka za nadzor

•Priprema nadzora

•Nadzor na terenu

•Praćenje nadzora kroz izvještaje. 2.3.3.8.Registar ovjerenih knjiga računa.

Službenik Poreske uprave kroz ovaj modul prima zahtjev za ovjeru knjiga računa za poslovnu jedinicu poreskog obveznika gdje zahtjev prolazi kroz proces ovjere zahtjeva. Službenici Poreske uprave prate knjige računa po poreskim obveznicima i po njihovim poslovnim jedinicama.

2.3.4.MAPR

MAPR je web aplikacija koja je javno dostupna na internetu. Putem ovog aplikativnog rješenja svi učesnici u prometu (građani, privredni subjekti, organi državne uprave) imaju mogućnost izvršiti provjeru validnosti evidentiranog prometa, odnosno validnosti fiskalizacije računa koji su dobili od prodavca odnosno pružaoca usluge kao obveznika fiskalizacije. Ukoliko račun nije evidentiran u skladu sa pozitivnim pravnim propisima kupac odnosno korisnik usluge kao potrošač ima mogućnost prijaviti nepravilnost putem ovog aplikativnog rješenja. U skladu sa navedenim, predmetna aplikacija podržava sljedeće funkcionalnosti:

•Provjera validnosti fiskalizacije računa •Prijava nepravilnosti na računu

2.3.4.1.Provjera validnosti fiskalizacije računa

Provjera računa vrši se na dva načina:

•Skeniranjem QR koda koji je istaktnut na računu i sadrži url adresu za pristup MAPR aplikaciji kao i set podataka sa računa i to: oIKOF

oPIB

oDatum i vrijeme kreiranja računa

oRedni broj računa

oKod poslovne jedinice

oENU kod

oKod softvera

oUkupna cijena iskazana na računu

Skeniranje QR koda može se izvršiti sa bilo kog mobilnog uređaja koji ima instaliranu kameru koja podržava skeniranje, a ukoliko je to potrebno može se besplatno na uređaju preuzeti i instalirati posebna mobilna aplikacija za skeniranje QR koda sa web prodavnica (npr google play store, appstore i sl.) Skeniranjem QR koda i pozivom generisane url adrese aplikacija vraća aplikativnu formu sa prikazom svih elemenata na računu koji je predmet provjere uključujući i stavke sa računa. Ukoliko račun nije fiskalizovan u momentu provjere, aplikacija vraća informaciju da račun nije fiskalizovan i da potrošač može izvršiti dodatnu provjeru u narednih 48h što je Zakonom o fiskalizaciji u prometu proizvoda i usluga definisan rok za slanje računa u slučaju da iz nekog razloga izdavaoc računa nije bio u mogućnosti uspostaviti vezu sa ENU na fiskalni servis EFI sistema UPC. •Ručnim unosom u aplikativnu formu MAPR, podataka sa računa, i to:

oIKOF – obavezan podatak

oPIB – obavezan podatak

oDatum kreiranja računa - obavezan podatak

oVrijeme kreiranja računa - obavezan podatak

oUkupna cijena iskazana na računu - obavezan podatak

Nakon izvršene provjere i prikaza podataka sa računa kroz MAPR aplikaciju kupac odnosno korisnik usluge kao potrošač može prijaviti eventualno utvrđenu nepravilnost na računu. 2.3.4.2.Prijava nepravilnosti na računu

Nakon izvršene provjere od strane kupca odnosno korisnika usluge, i prikaza podataka sa računa koji je predmet provjere, isti u slučaju utvrđene nepravilnosti na računu, ima mogućnost prijaviti uočenu nepravilnost, putem iste aplikativne forme koja je vratila podatke o provjeravanom računu, kada se otvara dodatni prozor (aplikativna forma) za unos informacija vezanih za prijavu nepravilnosti.

Prijava nepravilnosti utvrđene na računu ima podjelu na dva tipa prijave:

•Anonimna prijava sa sljedećim izobrima iz padajućeg menija

TIP nepravilnosti

•Podaci na računu kod provjere ne podudaraju se sa podacima na računu koji je izdat

• Račun je izdat, ali nije evidentiran u predviđenom roku

•Aplikacija izvještava da postoji korektivni račun računa koji se provjerava, a kupac nije dobio korektivni račun

Dodatne napomene u prijavi •Prijava sa unosom kontakt informacija

NAZIV – IME I PREZIME Email adresa

PIB – u slučaju da prijavu vrši privredni subjekt

TIP nepravilnosti

•Podaci na računu kod provjere ne podudaraju se sa podacima na računu koji je izdat

• Račun je izdat, ali nije evidentiran u predviđenom roku

•Aplikacija izvještava da postoji korektivni račun računa koji se provjerava, a kupac nije dobio korektivni račun

Dodatne napomene u prijavi

U oba slučaja prije potvrde slanja prijave, putem reCAPTCHA aplikativnog rješenja neophodno je potvrditi da se ne radi o robotu (mjera zaštite od zlonamjernih automatizovanih prijava i opterećenja u radu servisa).

Sve provjere i prijave evidentiraju se u EFI sistemu UPC, i predmet su izvještavanja kroz izvještajne module CPKU aplikacije EFI sistema UPC. 2.4.KORIŠTENE TEHNOLOGIJE I ALATI U RAZVOJU

KomponentaAlat / Tehnologija

Verzioniranje kodaGit / GitHub / GitLab

Okruženje Oracle WebLogic 12c

BazaOracle Exadata

Razvojno okruženjeSpring Tool Suite (STS)

ReportingTibco JasperSoft Studio

Alat za kontrolu kvalitetu kodaSonarLint

Automatsko generiranje build – aGradle

Razvojni jezik, backend Java

Razvojni jezik - frontend Angular; Ember

JEE razvojno okruženjeSpring Boot

Aplikacijski slojREST

2.4.1.Git/GitHub/GitLab

GitHub je hosting servis na webu koji služi za kontrolu verzioniranja, a verzioniranje se provodi GitHubovim alatom zvanim Git. Nudi mnoštvo opcija, od kontrole koda do slobodnog dijeljenja koda među korisnicima. Dolazi u dvije opcije, besplatni i plaćeni. Besplatni se koristi za open-source projekte.

Na samom servisu je 60-ak miliona repozitorija. Javni su dostupni baš svima, ali samo registrovani korisnici mogu dodati svoje.

GitHub je razvio Atom, editor za open-source tekst i kod, koji smo koristili pri izradi front-end dijela aplikacije.

Git je sistem za kontrolu verzioniranja. Koristi se za praćenje promjena na kodu ili bilo kojem drugom setu datoteka. Originalno je razvijen na Linuxu, ali se koristi na skoro svim operativnim sistemima.

Git se koristi kao aplikacija koja je povezana sa repozitorijem na GitHubu (može ih biti bezbroj, ali se na početku korištenja korisnik spoji s onim koji mu treba) i prati promjene. Preko njega se povlače (pull) zadnje promjene koje su unijeli saradnici na projektu (koji su ih prije toga podigli na zajednički repozitorij), preko njega korisnik postavlja (commit & push) svoje promjene na repozitorij. Ako su radili na istom dijelu projekta, odnosno na istom file-u, Git će pri pushu upozoriti korisnika na to pa on neće moći pushati svoje promjene dok ne ukloni one koje se poklapaju s prije podignutim. Kad se otvori aplikacija, prikazane su baš sve promjene, od najnovije do najstarije.

2.4.2.Oracle WebLogic 12c

Oracle WebLogic Server je najbolji poslužitelj aplikacija u industriji za izgradnju i implementaciju JEE aplikacija, uz podršku za nove značajke za smanjenje troškova operacija, poboljšanje performansi, povećanje skalabilnosti i podršku portfelju aplikacija Oracle. Oracle WebLogic Server dio je Oracle Fusion Middleware portfelja i podržava Oracle, DB2, Microsoft SQL Server, MySQL Enterprise i ostale baze podataka s JDBC-om. Komponente Oracle WebLogic servera su:

•Enterprise Grid Messaging

•JMS Messaging Standard

•JRockit

•Oracle Coherence

•Oracle TopLink

•Oracle WebLogic Server Web Services

•Tuxedo.

Više o Oracle Weblogicu može se naći na stranicama s Oracle dokumentacijom https://docs.oracle.com/middleware/12213/wls/index.html

2.4.3.Oracle Exadata

Oracle Exadata je bazni poslužitelj, rješenje koje podržava, velike, moćne Oracle baze visokih performansi.

2.4.4.Spring Tool Suite (STS)

Spring STS (Spring Tool Suite) je razvojno okruženje otvorenoga koga bazirano na Eclipse razvojnom okruženju koje je prilagođeno za razvoj Spring aplikacija. Ono nudi gotovo okruženje za razvoj, debug, pokretanje i deploy Spring aplikacija ali i uključuje integraciju Pivotal tc Servera, Git-a, Maven-a i sl. te je ažuran s najnovijom Eclipse inačicom. SpringSTS nudi opsežan skup validacija koje se automatski primjenjuje čak i prije pokretanja same aplikacije. Takođe je omogućeno refaktorisanje Spring aplikacija kao i vizualizacija u zavisnosti od bean-ova. Kroz cijelu aplikaciju je dostupan Code Assistent bez obzira da li se piše Spring Xml konfiguracija ili implementacija same aplikacije. SpringSTS je trenutno najpopularnije Java razvojno okruženje za Spring razvojni okvir.

2.4.5.Spring Boot

Spring Boot je projekt Spring programskog okvira koji sadrži sve ostale projekte. To znači da se preko njega može pristupiti svim ostalim projektima koji se žele koristiti u aplikaciji. Spring Boot projekt se kreira pomoću Spring Initializr-a. Spring Initializr je aplikacija koja generiše strukturu Spring Boot projekta (ne generiše nikakav kod same aplikacije, nego samo njenu strukturu). Postoji više načina pomoću kojih se može koristiti Spring Initializr preko Spring Boot web interfejsa, korištenjem razvojnih alata (Spring Tool Suite, Eclipse...) ili korištenjem Spring Boot CLI-a (sam postupak kreiranja aplikacije se neće objašnjavati jer je isti kao kreiranje bilo kojeg drugog projekta). Nakon kreiranja aplikacije kreiraju se dvije datoteke: pom.xml i klasa koja služi za pokretanje aplikacije. Ta klasa je glavna konfiguracijska klasa u aplikaciji i povezuje ostale module aplikacije.

2.4.6.Tibco JasperSoft Studio

Tibco Jaspersoft Studio pruža mogućnost generisanja velikih količina pripremljenih i interaktivnih izvještaja i nadzornih ploča koji pružaju krajnjim korisnicima mogućnost interakcije s njihovim podacima unutar ili izvan organizacije. Informacije se iz jednog ili više izvora podataka kompletiraju i prikazuju u jednostavnom obliku za čitanje za poslovne korisnike. Alat omogućava interaktivni dizajn izvještaja do piksela te ad hoc izvještaje na webu, pisaču ili mobilnom uređaju. Preglednik interaktivnih izvještaja pruža promjene tablica i grafikona, uključujući sortiranje, filtriranje, uslovno formatiranje, premještanje / skrivanje stupaca, pretraživanje nizova, zumiranje, zajedno s promjenama formata koje se mogu spremiti za ponovnu upotrebu. Izvještaji se mogu kreirati iz različitih izvora (Big datam NoSQL, JDBC, XML, JSON, CSV, Hibernate, POJO, Web servisi) te se mogu generisati u različitim oblicima (PDF, XLS, XLSX, XML, HTML, PPT, CSV, DOC, ODT, JSON).

2.4.7.SonarLint

SonarLint je program otvorenoga koda koji se koristi kao proširenje razvojnog okruženja (IDE) gdje detektira greške prilikom pisanja koda. SonarLint već tijekom pisanja samoga koda, označava one dijelove koji su po predefiniranom algoritmu loši te uz upozorenje nudi i alternativna rješenja. Na taj se način povećava kvalitet koda ali i praktikuje pisanje čistog koda. Trenutno je dostupna detekcija za sljedeće programske jezike: Java, JavaScript, PHP i Python te ga je moguće instalirati kao proširenje u gotovo sva poznatija razvojna okruženja kao što su Eclipse/SpringSTS, IntelliJ IDEA, VisualStudio, VS Code i Atom. SonarLint je praktičan iz razloga što prilikom samog programiranja podcrtava dijelove koda koje je potrebno promijeniti, te navodi programera na koji je način potrebno ispraviti određenu grešku pa tako omogućava da se kod ažurira na način kakav očekuje SonarLint kao i standard kog slijedi. Trenutno postoji 487 pravila po kojima SonarLint pretražuje greške u kodu te za svako pravilo postoji odgovarajuće rješenje koje i sam alat nudi. Takođe, pravila su podijeljena u tri grupe, a to su ranjivosti, bug-ovi i nečisti kod. Neke od tipičnih grešaka na koje SonarLint skreće pažnju su nedefinisani logovi, kognitivna kompleksnost koja ne smije imati kompleksnost veću od 15, nekorišteni paketi, varijable, klase i metode, preporučuje kreiranje konstanti ukoliko se neka vrijednost pojavljuje više puta i sl. SonarLint je alternativa za SonarCube ali se takođe mogu međusobno koristiti budući da su pravila oba alata sinkronizirana. Na sljedećoj stranici se nalazi popis grešaka na koje SonarLint skreće pažnju: https://rules.sonarsource.com/java

2.4.8.Gradle

Gradle je build sistem razvijen promatrajući druge build sisteme, te integriranjem njihovih najboljih karakteristika. Gradle je baziran na JVM (Java Virtual Machine) build sistemima što znači da se mogu pisati skripte za buildanje u Java programskom jeziku.

2.4.9.Java

Programski jezik Java nastao je 1995. godine.Ovaj objektno orijentiran programski jezik nastao je s namjerom olakšanja posla razvojnih programera jer koristi mali broj implementacijskih zavisnosti (engl. implementation dependencies). Zamišljen je na način da se programski kôd jednom napiše, a aplikacija se može pokretati na bilo kojoj platformi koja podržava Javu.

2.4.10.Angular

Angular je razvojni okvir (engl. framework) namijenjen razvoju klijentskih web aplikacija. Pisan je u programskom jeziku TypeScript, otvorenog je koda (engl. open source), a razvio ga je Google. Za izradu aplikacija koriste se HTML i TypeScript. Angular aplikacije pišu se komponujući HTML predloške, pisajući klase za komponente koje upravljaju tim predlošcima, dodajući logiku aplikacije u usluge i pakujući komponente i usluge u module. Aplikacija se pokreće tako da se pokrene njen glavni modul. Angular zatim prezentuje sadržaj aplikacije u internet pretraživaču i reaguje na interakcije korisnika prateći instrukcije koje su mu date.

2.4.11.Ember

Ember je JavaScript framework. Baziran je na MVVM shemi – Model-View-ModelView. Koristi se za izradu frontend dijela primarno web-aplikacija, mada se može koristiti i za izradu desktop-aplikacija.

Temeljen je na principima fokusiranja na ambiciozne web-aplikacije te na napretku bez nazadovanja, odnosno dodaju se nove funkcionalnosti u isto vrijeme dok se ažuriraju stare. U Emberu se može napraviti skoro sve što se poželi.

Ključni koncepti su rute (routes), modeli (models), predlošci (templates), komponente (components) i servisi (services).

2.4.12.SOAP

Interfejs za razmjenu podataka između servisa implementiranog na elektronskom naplatnom uređaju (ENU) kod poreskog obveznika i fiskalnog servisa implementiranog u EFI sistemu Poreske uprave, realizovan je putem SOAP web servisa, upotrebom HTTPS protokola za pristup servisu. Za potrebe enkripcije mrežnog saobraćaja na nivou transporta koristi se SSL TLS 1.3 digitalni certifikat. Poruke su u XML formatu prema standardima SOAP poruka, i u skladu sa jasno utvrđenim pravilima i strukturom interfejsa definisanom putem WSDL.

Web servis ima nekoliko operacija koje koriste poreski obveznici koji evidentiraju promet odnosno fiskalizuju račune. XML poruka (XML request) koju nakon generisanja putem softvera na ENU poreskog obveznika, isti šalje fiskalnom servisu EFI sistema UPC je poruka zahtjeva na koju fiskalni servis EFI sistema UPC odgovara slanjem XML odgovora (XML response). Nakon zaprimanja XML poruke EFI sistem UPC vrši osnovu validaciju strukture i sadržaja XML poruke, a u slučaju odbijajuće greške, poruka o grešci šalje se u XML odgovoru sa svojom strukturom. Sve poruke zahtjeva i odgovora (osim poruke o grešci) imaju sljedeće dijelove: zaglavlje (opšti podaci o poruci), podaci (podaci specifični za operaciju), potpis (elektronski potpis lica koje šalje poruku koja sadrži identifikaciju pošiljaoca i informacije za provjeru da nisu promijenjeni podaci poruke).

Autentifikacija i zaštita integriteta i povjerljivosti postiže se upotrebom SSL certifikata (v x509). XML poruka zahtjeva i IKOF element sadržan u zahtjevu digitalno se potpisuju privatnim ključem koji je jedinstven par s važećim javnim ključem generisanim od strane ovlaštenog CA koji je izdao certifikat poreskom obvezniku. Elektronske poruke odgovora EFI sistema UPC digitalno se potpisuju privatnim ključem koji je jedinstven par s važećim javnim ključem certifikata izdatog od strane ovlaštenog CA Poreskoj upravi.

U većini slučajeva privatni ključ koji se koristi za digitalno potpisivanje elektronske poruke zahtjeva i IKOF koda je isti. Izuzetak na osnovu ovog pravila moguć je ako certifikat upotrijebljen u vrijeme početnog kreiranja zahtjeva više nije valjan u trenutku ponovnog slanja zahtjeva. U tom se slučaju privatni ključ iz valjanog odgovarajućeg certifikata mora se upotrijebiti za digitalno potpisivanje elektronske poruke zahtjeva, ali ne i element IKOF podatka, koji ostaje isti.

Elektronske poruke zahtjeva i odgovora digitalno se potpisuju prema standardnoj sintaksi i obradi XML potpisa i obradi dostupnoj na: https://www.w3.org/TR/xmldsig-core/. 2.4.13. REST API

REST API se koristi kao backend interfejs za potrebe apliakativnih rješenja:

-SEP, samouslužni EFI portal

-MAPR, aplikacija za provjeru računa i prijavu nepravilnosti

-CPCM, Centralni portal za kontrolu i upravljanje

Podaci se najčešće prebacuju u JSON formatu iako je dostupan i XML i YAML format. Zasniva se na REST arhitekturi, veoma je fleksibilan i jednostavan za razumijevanje. Može biti izvršen na bilo kojem klijentu ili serveru koji ima HTTP/HTTPS podršku. RESTful servisi imaju slijedeće osobine i karakteristike:

•Nepostojanje stanja (Stateless)

•Mogućnost keširanja (Cacheable)

•Uniformni interfejs (Uniform interface URI)

•Izričito korištenje HTTP metoda

•Transfer XML i/ili JSON

Kod ovog tipa servisa, resursi (npr. statičke stranice, datoteke, podaci iz baze…) imaju vlastiti URL ili URI koji ih identifikuje. Pristup do resursa je definisan HTTP protokolom, gdje svaki poziv čini jednu akciju (kreira, čita, mijenja ili briše podatke). Isti URL se koristi za sve operacije ali se mijenja HTTP metoda koji definiše vrstu operacije. REST koristi CRUD like” HTTP metode kao što su: GET, POST, PUT, DELETE, OPTIONS.

2.4.14.Sistem za upravljanje logovima Kao sistem za upravljanje logovima i vizuelizaciju rezultata analize logova implementiran je softver KIBANA. Kibana je alat koji služi za prikupljanje i vizuelizaciju logova, zasnovan na pretraživaču otvorenog koda, podržava analizu velike količine logova koje prikuplja sa svih uređaja na nivou aplikacije. Kibana prikuplja, analizira i vizualizuje rezultate analize u obliku linijskih grafikona, kružnih grafikona, trakastih grafikona, regionalnih mapa, koordinatnih mapa, mjerača, ciljeva i vremenskog okvira itd. Ova vizualizacija pruža mogućnosu predviđanja ili utvrđivanja eventualnih promjena u trendovima grešaka ili drugih značajnih događaja evidentiranih u logovima koji su predmet prikupljanja i analize. Kibana radi u sinhronizaciji sa elasticsearch-om i logstash-om koji zajedno čine ELK stack. Logovi se prikupljaju i analiziraju u realnom vremenu. Postoje dva okruženja za prikupljanje i analizu logova, za potrebe produkcionog i testnog okruženja. 2.5.INTEGRACIJE

Sistem se integriše sa sljedećim aplikacijama/servisima:

•LDAP Poreske uprave

•CROO Poreske uprave (Centralni registar obveznika i osiguranika) •MUP CRS.

•BI/DWH

2.5.1.LDAP

Autentifikacija i autorizacija korisnika internog CPKU sistema ide putem LDAP-a Poreske uprave. Postoje 2 LDAP-a:

•testni LDAP koji se koristi za testno okruženje

•produkcioni LDAP koji se koristi za predprodukciono i produkciono okruženje.

Na AD-u postoje posebne grupe koje se dodjeljuju korisnicima i svaki korisnik pripada jednoj ili više grupa. Nazivi grupa se podudaraju s nazivima rola u aplikaciji. Kada se kreira nova rola u aplikaciji potrebno je javiti AD timu kako bi oni dodali novu grupu na AD. Osim podatka kojoj grupi pripadaju korisnici na AD-u imaju i atribut s pripadnosti područnoj jedinici ili ekspodituri. U Crnog Gori ima 22 područne jedinice odnosno ekspoziture. 2.5.2.CROO

Centralni registar obveznika i osiguranika (CROO) je postojeća evidencija UPC. Ona sadrži i uvek će sadržati sve one koji će biti upisivani u Registar obveznika fiskalizacije, jer svaki obveznik fiskalizacije prethodno mora biti upisan u CROO.  Registar obveznika fiskalizacije (ROF) predstavlja podskup CROO, odnosno registar svih poreskih obveznika koji su prilikom evidentiranja prometa odnosno izdavanja računa obavezni koristiti fiskalni servis. Registar sadrži specifične grupe podataka vezane za fiskalizaciju gotovinskih i bezgotovinskih računa (prodajna mesta, naplatne uređaje, itd.), a iz CROO povlači osnovne registracione podatke o poreskom obvezniku, odnosno obvezniku fiskalizacije.  CROO je evidencija koja je primarna, jer svaki poreski obveznik mora prethodno biti upisan u ovu evidenciju.  CROO i ROF imaju dio zajedničkih podataka, koje ROF nasljeđuje iz CROO prilikom registracije obveznika fiskalizacije.  Prilikom prve registracije obveznika fiskalizacije u ROF, pozivanjem odgovarajuće metode softverskog servisa sa strane CROO preuzima se deo opštih podataka o poreskom obvezniku i upisuje u ROF.  Na logičkoj šemi (Slika 1) je prikazan način komunikacije između integracionih servisa sa strane CROO (SWS CROO) i strane ROF (SWS ROF).  Smjer slanja osnovnih podataka o poreskom obvezniku je uvek od CROO ka ROF.  Format podataka je XML. Prilikom prvog upisa obveznika fiskalizacije SWS ROF poziva odgovarajuću metodu SWS CROO koja vraća set potrebnih podataka o poreskom obvezniku iz CROO u XML formatu. Ove podatke SWS ROF upisuje u ROF i nastavlja proces registracije kroz SEP.   

Slika 1: Logička šema rada integracionih servisa CROO i ROF  2.5.3.MUP CRS

Prilikom registracije fizičkih lica koja su obveznici fiskalizacije, EFI sistem se putem servisa spaja s MUP servisom (CRS) i od njega na osnovu eID-a iz lične karte povlači osnovne podatke o tom fizičkom licu. Podaci dobijeni od servisa (ime i prezime, JMBG) se upisuju u ROF te se na osnovu dobijenog podatka o JMBG-u poziva CROO servis koji još vrati dodatne podatke o poreskom obvezniku ukoliko je poreski obveznik registrovan u CROO.

2.5.4.BI/DWH

Svi podaci iz transakcionih tabela EFI sistema UPC, koji su predmet izvještavanja povlače se ELT alatom u skladište podataka (DWH) i prezentuju upotrebom BI alata. Takođe aplikativni moduli za izvještavanje EFI sistema UPC mogu kreirati izvještaje sa izvještajnih tabela BI/DWH sistema UPC. BI/DWH sistem realizovan korištenjem Oracle tehnologije (ODI, OBBI).

2.6.DB MODEL

Baza podataka sadrži nekoliko schema:

•CPCM - Schema služi za spremanje podataka o poreskim obveznicima, poslovnim jedinicama, ENU, operaterima, proizvođačima i održavateljima softvera i softverima te svim podacima koji se zapisuju kroz SEP ili CPKU aplikaciju (nadzor, registar ovjerenih knjiga računa).

•KS_EXT - Schema služi za spremanje labela i parametara te korisničkih rola i prava za interne korisnike koji koriste SEP aplikaciju.

•KS_INT- Schema služi za spremanje labela i parametara te korisničkih rola i prava za interne korisnike koji koriste CPKU aplikaciju. •FS - Schema služi za spremanje transakcijskih podataka i xml-ova zaprimljenih fiskalnim servisom.

•FS_OUT - Schema služi za spremanje raspakiranih transakcijskih podataka iz xml-ova zaprimljenih fiskalnim servisom.

•DAT_REP_INT - Schema služi za prikaz read-only podataka i izvještaja u SEP i CPKU aplikacijama.

•DQ - Schema služi za validaciju podataka zaprimljenih fiskalnim servisom i identifikaciju grešaka u podacima.

•REPORT - Schema služi za obradu i pripremu podataka za izvještaje. 3.PODRŠKA RADU SISTEMA

Podrška radu sistema (engl. Supportability) obuhvata različite elemente podrške i održavanja koje treba pružati za vrijeme eksploatacije sistema. Neki od elemenata podrške koje bi trebalo osigurati su: •Jedinstveni centar za prijavu problema i upravljanje zadacima na otklanjanju istih.

•produkciona podrška

oinstalacija, konfiguracija i nadzor rada Sistema oedukacija korisnika opodrška korisnicima u radu sa Sistemom

•help-desk usluge oputem softvera za prijavu problema i upravljanje zadacima na otklanjanju istih, putem telefona, e-pošte, web stranica i sl.

•elementi preventivnog održavanja i praćenje događaja u radu Sistema oidentifikacija i izvještavanje o vanrednim događajima u radu Sistema osistemsko održavanje, održavanje baza podataka, održavanje aplikacija opreventivne zamjene hardvera i sistemskog softvera

•elementi korektivnog održavanja oispravljanje grešaka i uklanjanje kvarova •elementi tehnološkog održavanja

oaplikacija i softverskih paketa novim verzijama kada one budu raspoložive

oprilagođavanje aplikacija, softverskih paketa i podataka novim verzijama

•adaptivno održavanje, po potrebi

•dokumentacija otehnička dokumentacija

okorisnička dokumentacija

•Integracija sa IRMS sistemom (Integrisani sistem za upravljanje prihodima) koji je trenutno u fazi implementacije

•povezivanje s drugim sistemima 3.1.GARANCIJA KVALITETA - USLOVI KOJE PONUĐAČ MORA DA ZADOVOLJI

3.1.1.Dostavljanje dokaza tehničkih sposobnosti u vezu s predmetom nabavke Naručilac traži navedene dokaze tehničkih sposobnosti jer je poslovna politika Naručioca da ne želi izvršenje predmeta nabavke prepustiti privrednim subjektima koji nemaju odgovarajuće poslovno iskustvo s razvojem aplikativnih sistema, a da ne poznaju navedene tehnologije što je izuzetno važno za poslovanje Naručioca i stoga se izvršenje predmeta nabavke smije povjeriti jedino ponuđaču koji se na tržištu u navedenim oblastima dokazao u zadnje tri godine. Navedeni dokazi prema procjeni Naručioca potvrđuju potreban nivo iskustva te poznavanja tehnologija i metodologija rada nužnih za kvalitetno izvršenje predmeta nabavke, odnosno isti osiguravaju potrebni nivo iskustva koje su privrednom subjektu potrebne u svrhu urednog izvršenja ugovora sklopljenog u ovom postupku nabavke. 3.1.2. Ljudski resursi Ponuđač mora da obezbijedi minimum 8 (osam) stručnjaka, koji su zaposleni kod ponuđača, a koje može da angažuje na projektu. Ključno osoblje treba da zadovoljava sljedeće kriterijume:

•1 (Jedan) Vođa projekta

ominimalno 10 godina radnog iskustva na poslovima vođenja razvojnih IT timova u području vođenja, planiranja i implementacije informacionih sistema

oradnim iskustvom u ulozi voditelja razvojnih IT timova na minimalno jednom dovršenom projektu koji se odnose na implementaciju i/ili nadogradnju poslovnih i transkacijskih sistema u javnom sektoru

oNosioc PMI Project Manager Professional (PMP) certifikata ili jednakovrijednog

•1 (Jedan) DB Specijalist - Administrator baze podataka

ominimalno 10 godina radnog iskustva na poslovima administracije i optimizacije baza podataka te implementacije i održavanja informacionih sistema baziranih na Oracle DB tehnologiji / platformi

oradnim iskustvom u ulozi stručnjaka za baze podataka na minimalno dva dovršena projekta koja se odnose na implementaciju i/ili nadogradnju poslovnih i transkacijskih sistema u javnom sektoru na Oracle DB tehnologiji / platformi

oNosioc certifikata iz područja administracije Oracle baze podataka, Oracle database 12c Administrator Certified ili jednakovrijedan

oNosioc certifikata ili potvrde kojom se dokazuje poznavanje Oracle Exadata Database Machine Platforme

•1 (Jedan) PKI Specijalist

ominimalno 5 godina radnog iskustva u radu sa PKI sistemima / PKI baziranim aplikativnim modulima

oradnim iskustvom u ulozi PKI stručnjaka na implementaciji minimalno dva dovršena PKI sistema / PKI aplikativna modula

•4 (četri) Java / JEE Programera

oMinimalno 5 godina radnog iskustva na implementaciji java baziranih informacionih sistema

oRadnim iskustvom u ulozi samostalnog programera na minimalno dva dovršena projekta koja se odnose na implementaciju i/ili nadogradnju transakcijskih informacionih sistema u javnom sektoru

oNosioc certifikata Oracle Certified Professional, minimalno Java SE 7 Programer kao dokaz poznavanja Java tehnologije

•1 (Jedan) Specijalist za testiranje softverskih rješenja

oMinimalno 2 godine radnog iskustva na poslovima testiranja informacionih sistema

oRadnim iskustvom u ulozi Testera IT Rješenja na minimalno dva dovršena projekta koja se odnose na implementaciju i/ili nadogradnju transakcijskih informacionih sistema Ukoliko je nemoguce rješavanje problema drugim načinom Ponuđač je u obavezi da po zahtjevu Poreske uprave obezbijedi fizičko prisustvo odgovornog predstavnika svoje firme do 5 dana mjesečno, na lokacijama informacionih sistema elektronske fiskalizacije Poreske uprave Crne Gore (primarna i DR lokacija). 3.1.3. Reference ponuđača Ponuđač mora imati minimum 2 (dva) uspješno realizovana i puštena u rad projekta vezanih za usluge implementacije poslovnih i transakcionih sistema u javnom sektoru koji zadovoljavaju sljedeće kriterijume: •Da je sistem razvijan na način da bude dostupan 99,5% vremena u načinu rada 24x7x365 uz pretpostavku dostupnosti 100%

•Da su izrađeni korišćenjem Oracle tehnologija i alata

•Da je programski kod baziran na Java /JEE tehnologiji

•Da podržava digitalno potpisivanje i rad sa PKI infrastrukturom

•Da ponuđač posjeduje certifikat o ispunjenosti ISO/IEC 27001:2013 ili jednako priznatom , izdanom od certifikacionog tijela. Navedenim certifikatom Ponuđač dokazuje da osigurava sigurnost i povjerljivost svih informacija te da preduzima i raspolaže organizacionim i tehničkim mjerama sigurnosti, odnosno uključuje sigurnosne zahtjeve u svim fazama prilikom pružanja svojih usluga. 3.2. TEHNIČKI DIO PONUDE MORA DA SADRŽI

•Detaljan opis aktivnosti koje ponuđač planira da vrši u cilju realizacije navedenih usluga održavanja i unapredjenja aplikativnog softvera i baza podataka u ispravnom stanju

•Načelni opis rješenja za nadogradnju sistema

•Broj, strukturu, odgovarajuće certifikate, biografije i reference tehničkog osoblja i konsultanata koji će biti angažovani na održavanju

•Broj i kratak opis sprovedenih i uspješno puštenih u rad projekata vezanih za usluge u javnom sektoru a koji imaju karakteristike navedene u tački reference ponudjača 3.3.MODEL PRUŽANJA USLUGA

3.3.1. Preventivno održavanje U cilju preventivnog održavanja, redovnog kontrolisanja log (auditing) fajlova svih elemenata sistema ponuđač je u obavezi da obezbijedi održavanje i unapređivanje sistema na tehnološkoj platformi postojećeg sistema uz poštovanje bezbjednosnih procedura i zaštite podataka. 3.3.2. Adaptivno održavanje

Adaptivno održavanje softvera je promjena softvera kao odgovor na promjene u njegovom okruženju. Pojavljuje se u situacijama kao što su promjene operativnog sistema u zavisnosti od softvera, hardvera.

Navedeno podrazumijeva i promjenu postojećih i izmjenu postojećih procesa koji se odnose na nabrojane module a nastali su usljed promjene zakonske regulative.

Potrebno je navesti:

•Organizaciju tima i opis aktivnosti promjena softvera u saglasnosti sa zakonskom regulativom

•Postupak i dinamiku vršenja promjena modula i izrade novih procesa

•Osiguranje kvaliteta softvera nakon izvršenih ispravki 3.3.3. Korektivno održavanje

Korektivno održavanje softvera odnosi se na ispravljanje softverskih nedostataka i grešaka. Ove greške se obično primećuju dok je softver u upotrebi i mogu ukazivati na dublje propuste ili greške u dizajnu softvera, logici ili kodu. Ova vrsta održavanja je prilagodljiva. Radi se o ispravljanju uočenih ili prijavljenih grešaka koje utiču na funkcionalnost softvera. 3.3.4. Perfektivno održavanje

Perfektivno održavanje softvera fokusira se na funkcije koje poboljšavaju korisničko iskustvo kroz funkcionalna poboljšanja. Radi se o poboljšanju performansi sistema na načine koji nisu odgovor na grešku ili problem, već kao odgovor na povratne informacije korisnika.

Primjeri su poboljšanja funkcionalnosti koda, promene upotrebljivosti ili optimizacija brzine. Sve ovo poboljšava vrednost softvera i poboljšava korisničko iskustvo. 3.3.5. Intervencije Ponuđač je dužan da omogući da u slučaju greške sistema, gubitak podataka bude ograničen na ne više od trenutnog prenosa podataka koji se unose od strane korisnika u trenutku pojavljivanja greške. Ponuđač je dužan da sačini zapisnik o intervenciji koji mora da sadrži:

•opis stanja prije intervencije

•opis kvara/greške ako je intervencija zbog kvara/greške

•uzrok kvara/greške ako je intervencija zbog kvara/greške

•detaljan opis preduzetih (korektivnih) aktivnosti •opis posljedica preduzetih (korektivnih) aktivnosti na korišćenje softverskog rješenja i redovne procedure u održavanju sistema

•vrijeme utrošeno na intervenciji Zapisnik mora biti odobren od strane ovlašćenog predstavnika korisnika. Ako zapisnik nije odobren smatraće se da intervencija nije izvršena na adekvatan način.

Smatra se da je zahtjev za intervencijom prijavljen kada je ovlašćeni predstavnik korisnika usluga obavjestio ponuđača (putem unaprijed definisanog kanala izmedju naručioca i ponudjača). Pri tome se sačinjava zapisnik u kojem se navodi koja se intervencija zahtjeva i upisuje se vrijeme prijavljivanja. Smatra se da je došlo do kritične greške ukoliko korisnik ne može više koristiti softversko rješenje zbog greške na nekoj od osnovnih funkiconalnosti softverskog rješenja, što ima kritičan uticaj na izvršenje aktivnosti. Takva greška zahtijeva hitnu intervenciju i otklanjanje iste. Primjeri grešaka ove vrste su: problemi sa podacima ili njihovo uništenje, gubitak podataka...Nema zamjenskog (workaround) rješenja za grešku, te je za otklanjanje takve greške potrebna promjena organizacije aplikacije ili velike promjene u aplikaciji.

Ponuđač je dužan da u slučaju kritične greške odmah preduzme mjere za njeno otklanjanje i smanji stepen njene kritičnosti u roku od 48h.

Ponuđač je dužan da podnosi mjesečni izveštaj o izvedenim radovima na održavanju i dokumentuje radove na održavanju na dogovoreni način. 3.3.6.Raspoloživost sistema Ponuđač je dužan da obezbijedi ispravno i kvalitetno funkcionisanje svih softverskih rješenja (instaliranih sistema i podsistema) koja su predmet održavanja i stvaranje uslova za neprekidan rad, u on-line režimu 24/7/365, održavanog softverskog rješenja u dijelu koji zavisi od ponuđača i nije uslovljen drugim spoljnim faktorima (npr. ispravan hardver optimalnih performansi, sistemski softver, odgovarajući antivirus program, odgovarajuća veza sa starim poreskim sistemom i drugo) tokom cijelog perioda održavanja. 3.3.7.Dokumentovanje sistema Ponuđač je dužan da redovno ažurira dokumentaciju izvedenog stanja, te da istu blagovremeno dopunjava.

Ponuđač je dužan dostaviti izvorni kod ako je izvršio bilo kakvu izmjenu u istom. Izvorni kod se dostavlja prije nego se inovirano softversko rješenje stavi u produkciju. Ponuđač je dužan dostaviti izvorni kod za sva proširenja EFI sistema.

Ponuđač je dužan da održava tehničku dokumentaciju u skladu sa tehničkim promjenama na softverskom rješenju. Način kontrole kvaliteta: Komisija Naručioca sastavljena od stručnog osoblja će izvršiti kvalitativan i kvantitativan prijem predmetnih usluga i utvrditi da li izvršene usluge odgovaraju specifikacijama Naručioca iz ove tenderske dokumentacije. Ponuđač snosi troškove naknade korišćenja patenata i odgovoran je za potencijalne slučajeve povrede zaštićenih prava intelektualne svojine trećih lica. 3.4.SPECIFIKACIJA RELEVANTNE ZAKONSKE REGULATIVE KOJA JE BITNA ZA PROJEKAT •Zakon o fiskalizaciji u prometu proizvoda i usluga (Sl. list CG, br. 46/19, 73/19 i 8/21)

•Zakon o porezu na dodatu vrijednost (Sl. list RCG, br. 65/01, 38/02, 72/02, 21/03, 76/05 i Sl. list CG, br. 16/07, 29/13 i 9/15) •Zakon o porezu na dohodak fizičkih lica (Službeni list Republike Crne Gore, br. 065/01 od 31.12.2001, 012/02 od 15.03.2002, 037/04 od 04.06.2004, 029/05 od 09.05.2005, 078/06 od 22.12.2006, 004/07 od 24.01.2007, Službeni list Crne Gore, br. 086/09 od 25.12.2009, 073/10 od 10.12.2010, 040/11 od 08.08.2011, 014/12 od 07.03.2012, 006/13 od 31.01.2013, 062/13 od 31.12.2013, 060/14 od 31.12.2014, 079/15 od 31.12.2015, 083/16 od 31.12.2016, 067/19 od 11.12.2019)

•Zakon o porezu na dobit pravnih lica (Službeni list Republike Crne Gore, br. 065/01 od 31.12.2001, 012/02 od 15.03.2002, 080/04 od 29.12.2004, Službeni list Crne Gore, br. 040/08 od 27.06.2008, 086/09 od 25.12.2009, 040/11 od 08.08.2011, 014/12 od 07.03.2012, 061/13 od 30.12.2013, 055/16 od 17.08.2016)

•Pravilnik o primjeni Zakona o porezu na dodatu vrijednost (Sl. List RCG, br. 65/02, 13/3, 59/4, 79/05, 16/06, 64/08 i 30/13) •Pravilnik o obliku i sadržini prijave za obračun poreza na dodatu vrijednost (Sl. list RCG 79/05, 28/06 i Sl.list 64/11, 30/13)

•Pravilnik o načinu ostvarivanja prava na oslobađanje od plaćanja akcize i poreza na dodatu vrijednost za diplomatska i konzularna predstavništva i međunarodne organizacije (Sl. list CG, br 34/10, 52/13)

•Uredba o upotrebi registar kase i načinu evidentiranja prometa proizvoda, odnosno usluga preko registar kase (Sl. list CG 27/08 40/08 i 8/12)

•Pravilnik o sadržaju evidencije o poreskim kasama (Sl. list CG br 38/08)

•Pravilnik o obliku i sadržaju servisne knjižice poreske kase (Sl. list CG br 38/08)

•Pravilnik o obliku i sadržaju jedinstvene prijave za registraciju poreskih obveznika, obveznika doprinosa i osiguranika u Centralni registar (Sl. list CG broj 10/10, 32/10 i 30/17)

•Zakon o turizmu i ugostiteljstvu (Službeni list Crne Gore, br. 002/18 od 10.01.2018, 004/18 od 26.01.2018, 013/18 od 28.02.2018, 025/19 od 30.04.2019, 067/19 od 11.12.2019, 076/20 od 28.07.2020)

•Zakon o kvalifikaciji djelatnosti (Sl. list RCG, 18/11)

•Zakon o elektronskoj identifikaciji i elektronskom potpisu (Sl. list RCG 55/03, 31/05, i Sl. list CG 41/10, 40/11)

•Zakon o elektronskom dokumentu (Sl. list RCG 05/08 i 40/11).

•Zakon o informacionoj bezbjednosti (Sl. list RCG 14/10, 40/16)

•Zakon o poreskoj administraciji (Sl. list RCG, br. 065/01 od 31.12.2001, 080/04 od 29.12.2004, 029/05 od 09.05.2005, Službeni list Crne Gore, br. 073/10 od 10.12.2010, 020/11 od 15.04.2011, 028/12 od 05.06.2012, 008/15 od 27.02.2015, 047/17 od 19.07.2017, 052/19 od 10.09.2019)

•Zakon o inspekcijskom nadzoru (Sl. list RCG, br. 039/03 od 30.06.2003, Sl. list CG, br. 076/09 od 18.11.2009, 057/11 od 30.11.2011, 018/14 od 11.04.2014, 011/15 od 12.03.2015, 052/16 od 09.08.2016) 2.Zahtjevi u pogledu načina izvršavanja predmeta nabavke koji su od značaja za sačinjavanje ponude i izvršenje ugovora | 1 Komad

Vrsta predmeta: Usluge

CPV: 50324100 - Usluge održavanja sistema

Vrsta postupka: Otvoreni postupak

Službenik za javne nabavke: Rajko Nikolić

Kontakt: Zoran Dujović 067/242-450

Datum objave: 2025-03-11 10:00:00

Napomena

Kako se slike iz tehničke specifikacije nijesu mogle iskopirati u sekciji SPECIFIKACIJA ista se nalazi u okviru sekcije DOKUMENTI u sklopu Tenderske dokumentacije.

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

Procijenjena vrijednost nabavke: 231404.96 EUR

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

ROKOVI

Početak podnošenja: 11.03.2025 10:00

Kraj podnošenja: 11.04.2025 10:00

Datum otvaranja: 11.04.2025 10:00

Rok za donošenje odluke: 10.06.2025 14:00