Përmirësimi i modulit të menaxhimit të kontrollit të faturimit

REPUBLIKA E SHQIPËRISË

KËSHILLI I MINISTRAVE

AGJENCIA KOMBËTARE E SHOQËRISË SË INFORMACIONIT

Përmirësimi i modulit të menaxhimit të kontrollit të

faturimit

Versioni 1.0

01.05.2018

Faqe 2 nga 140

FAQJA E KONTROLLIT TË DOKUMENTEVE

Historia e dokumenteve të versioneve dhe ndryshimeve

Datë Autor Versioni Shënime rreth Shqyrtimeve

1.0

NËNSHKRIMET E MIRATIMIT

Miratuar nga: Menaxheri i Projektit Miratuar nga: Përgjegjësi për procese në

TIK

<Emri dhe Mbiemri> <Emri dhe Mbiemri>

<Nënshkrimi> <Nënshkrimi>

Përgatitur nga: Përgjegjësi i TIK Përgatitur nga: <Funksioni i anëtarit të

grupit punues për hartimin e Termave të

Referencës, shto funksione tjera sipas

nevojës>



Personi për kontakt: Kontrolluar ga: Përgjegjësi për siguri në

TIK



Të dhënat e personit për kontakt:

Emri dhe Mbiemri

Pozicioni

Adresa e E-mailit

Nr. i Telefonit

Faqe 3 nga 140

PËRMBAJTJE

FAQJA E KONTROLLIT TË DOKUMENTEVE 2

NËNSHKRIMET E MIRATIMIT 2

PËRMBAJTJE 3

1 HYRJE 7

1.1 Përfituesi /Autoriteti Kontraktues 7

1.2 Hyrje 7

1.3 Synimi i projektit 7

1.4 Përdoruesit 7

2 GJENDJA AKTUALE 9

2.1 Historiku 9

2.2 Gjendja aktuale në sektor 9

2.3 Arkitektura e sistemit të pajisjeve fiskale. 10

2.4 Problematika të sistemit aktual të pajisjeve fiskale dhe administrimi i të gjithë

procesit. 11

2.5 Pajisjet fiskale 12

2.6 Detyrimi për Përdorimin e Pajisjeve Fiskale 12

2.7 Shoqëritë e autorizuara 13

2.8 Përjashtohen nga detyrimi i lëshimit të kuponit tatimor: 14

2.9 Statistika e pajisjeve fiskale. 14

2.10 Pajisjet fiskale dhe sistemi fiskal 15

2.11 Komunikimi ndërmjet pajisjeve fiskale dhe DPT-së 15

3 OBJEKTIVAT, QËLLIMI DHE REZULTATET E PRITURA 17

3.1 Objekti i Përgjithshëm 17

3.2 Qëllimi 18

3.3 Synimi 19

3.4 Rezultatet që duhen arritur nga kontraktuesi 19

4 SUPOZIMET DHE RISQET 21

4.1 Supozimet e Projektit 21

4.2 Risqet 21

5 SHËRBIMET / QËLLIMI I PUNËS 22

5.1 Zona gjeografike që duhet mbuluar 22

5.2 Grupi i synuar 22

5.3 Siguria e sistemit 22

5.4 Shërbimet e konsulencës 24

5.4.1 Kuadri ligjor 24

5.4.2 5.1.2 Përshtatja e strukturës organizative Error! Bookmark not defined.

Faqe 4 nga 140

5.4.3 Organizimi dhe metodologjia e monitorimit tatimor të tatimpaguesve në

nënsistemin TP 29

5.4.4 Sistemi i menaxhimit të sigurisë së informacionit - (ISMS) 34

5.4.5 Treguesit kryesore të performancës 39

5.4.6 Strategjia e PR 41

5.5 Softueri 43

5.5.1 Zhvillimi, evidentimi dhe përcjellja e transaksioneve ME para NE DORE 43

5.5.2 Portali qendror për kontrollin dhe menaxhimin e tatimpaguesve në Nënsistemin

e pagesave me para në dorë (PQKM) 45

5.5.3 Moduli i kontrollit tatimor 51

5.5.4 Sistemi i menaxhimit të riskut në transaksionet me para në dore 60

5.5.5 Zhvillimi, regjistrimi dhe përcjellja e transaksioneve pa para të gatshme 61

5.5.6 Regjistri i tatimpaguesve (RTP-së) dhe degëve tyre 67

5.5.7 Organizimi i administratës tatimore dhe sistematizimi i vendeve të punës Error!

Bookmark not defined.

5.5.8 Pasuria e tatimpaguesit 70

5.6 Përshkrimi i arkitekturës së sistemit 72

5.6.1 Hyrje në arkitekturën e sistemit 72

5.6.2 Modeli i bazuar në KOMPONENTË 74

5.6.3 Modeli operativ 77

5.6.4 Shtresat e sistemit 82

5.7 Kërkesa të tjera 93

5.7.1 DWH 93

5.7.2 INTELIGJENCA e biznesit dhe Analitika e biznesit 95

6 LOGJISTIKA DHE KOHA 97

6.1 Vendodja 97

6.2 Data e fillimit dhe periudha e zbatimit të detyrave 97

7 TESTIMI DHE SIGURIMI I CILËSISË 98

7.1 Testimi para shkarkimit 98

7.2 Qëllimi 98

7.3 Kriteret e futjes 98

7.4 Proces / Procesi 98

7.5 Përgatitja për testim 99

7.6 Zbatimi i testimit të sistemit 99

7.7 Testimi i pranueshmërisë operacionale 99

7.7.1 Zbatimi i testimit të integrimit 99

7.7.2 Zbatimi i testimit të pranueshmërisë nga ana e përdoruesit 100

7.8 Sigurimi i cilësisë 100

Faqe 5 nga 140

8 RAPORTIMI 101

8.1 Kërkesat e raportimit 101

8.2 Dorëzimi dhe miratimi i raporteve 101

9 KOMUNIKIMI ME SISTEMET TJERA 102

10 GARANCIA 103

10.1 Garancia 103

10.2 Mbështetje operative për përdoruesit e sistemit 103

11 MIRËMBAJTJA 104

11.1 Mirëmbajtja operacionale e Sistemit dhe sënsistemit 105

11.2 Mirëmbajtja proaktive 105

11.3 Mirëmbajtja reaktive 105

11.4 Mirëmbajtja e Infrastrukturës së Serverit - Serverët aplikativ - JAVA Technology

108

11.5 Servisimi i infrastrukturës së serverit - DBA Oracle teknologjia 108

11.6 Mirëmbajtja e pajisjeve dhe shërbimet e inxhinierisë së sistemit 109

12 PLANIFIKIMI I BUXHETIT PËR ZBATIMIN E PROJEKTIT 110

12.1 Specifikimi i harduerit 110

12.1.1 Data management tier 110

12.1.2 Middleware tier 110

12.1.3 Middleware tier 111

12.2 Përllogaritja e pjesëve të projektit 111

13 AFATI KOHOR I PROJKETIT DHE LISTA E DOKUMETEVE TË CILAT

OFERTUESI DUHET TË DORËZOJË 113

13.1 Plani i implementimit 113

13.2 Lista e dokumenteve të dorëzimit 126

14 TË DREJTAT E KODIT PËR APLIKACIONIN 131

15 MONITORIMI I PERFORMANCËS DHE RAPORTIMI ANALITIK 132

15.1 Monitorimi i performancës 132

15.2 Raportimi i Analitikes 132

16 KËRKESAT JO-FUNKSIONALE DHE TEKNIKE 133

16.1 Performanca e kërkuar e sistemit 133

16.2 Kërkesat e përgjithshme 133

16.3 Ndërfaqja e përdoruesit 133

16.4 Siguria 133

16.5 Mjedisi i sistemit dhe administrimi 135

16.6 Kërkesat harduerike 136

16.7 Menaxhimi i të dhënave 136

Faqe 6 nga 140

16.8 Shtresa e mesme 137

16.9 Shtresa e bazës për ruatje 138

16.10 Kërkesa të tjera teknike dhe jo teknike 139

16.10.1 Certifikimi Elektronik (nënshkrim ELEKTRONIK) 139

Faqe 7 nga 140

1 HYRJE

1.1 Përfituesi /Autoriteti Kontraktues

Drejtoria e Përgjithshme e Tatimeve / AKSHI

1.2 Hyrje

Sistemi i Menaxhimit dhe Kontrollit të Faturave (MKF) është një grup i procedurave dhe mjeteve ligjore,

organizative dhe teknike, qëllimi kryesor i të cilave është kontrolli i transaksioneve me pagesa me para

në dorë dhe pagesa me para jo cash. Në përputhje me dispozitat e Ligjit që do të miratohet në

Republikën e Shqipërisë (RSH), qarkullimit e parasë është një pagesë për mallrat ose shërbimet e

ofruara me kartëmonedha dhe monedha që konsiderohen si shpenzime, kartë krediti dhe debiti, çek

ose metoda të tjera të ngjashme të pagesës, përveç pagesës së drejtpërdrejt në llogari. Duke përdorur

lidhjen në internet, Administratë Tatimore do të ketë një pasqyrë të qartë në secilën llogari. Kjo eliminon

evazionin fiskal dhe kontribuon në rritjen e ndërgjegjësimit të tatimpaguesve për të paguar tatimet, duke

rezultuar kështu në një financim të drejtpeshuar të shpenzimeve publike.

Për më tepër, MKF do të jetë një instrument i vlefshëm statistikor dhe analitik për mbikëqyrjen e

rreziqeve tatimore, monitorimin e efektivitetit të strukturës organizative dhe segmenteve të saj si dhe të

zyrtarëve të Administratës Tatimore.

Ndër të tjera, MKF do të mundësojë monitorimin dhe analizën e përputhshmërisë me afatet e pagesës

midis pjesëmarrësve në sistemet e pagesave, duke ofruar kështu masa më të gjera për politikat

makroekonomike dhe monetare.

1.3 Synimi i projektit

Projekti përbehet nga njësitë e mëposhtme

1. Shërbimet e konsulencës

1.1. Sistemi i evidentimit dhe ndjekjes së transaksioneve me para në dorë

1.2. Kontrolli tatimor i tatimpaguesve në sistemin e pagesave me para në dorë

1.3. Sistemi për menaxhimin e riskut për pagesa me para në dorë

1.4. Krijimi, regjistrimi dhe ndjekja e transaksioneve jo cash.

1.5. Regjistri i tatimpaguesve me degët e tatimpaguesve dhe API

1.6. Sistemi i menaxhimit të sigurisë së informacionit - (ISMS)

1.7. Strategjia e PR

2. Softueri

2.1. Sistemi i evidentimit dhe ndjekjes së transaksioneve me para ne dore

2.2. Kontrolli tatimor i tatimpaguesve në sistemin e pagesave me para ne dore

2.3. Sistemi për menaxhimin e riskut për pagesa me para në dore

2.4. Krijimi, regjistrimi dhe ndjekja e transaksioneve jo cash

2.5. Pasuria e tatimpaguesve

2.6. Regjistri i tatimpaguesve me degët e tatimpaguesve dhe API

3. Infrastruktura fizike

1.4 Përdoruesit

Përdoruesit e këtyre nënsistemeve do të jenë:

1. Zyrtarët e Ministrisë së Financave të Republikës së Shqipërisë, sipas rregullave të brendshme

Faqe 8 nga 140

2. Zyrtarët e Administrates Tatimore të Republikës së Shqipërisë

3. Personat dhe organet me autoritet publik në Republikën e Shqipërisë, sipas rregullave të

brendshme

4. Tatimpaguesit në Republikën e Shqipërisë

5. Qytetarët e Republikës së Shqipërisë

6. Përdoruesit e huaj, në përputhje me rregulloret e veçanta të Republikës së Shqipërisë

Faqe 9 nga 140

2 GJENDJA AKTUALE

2.1 Historiku

Vitet e fundit në Drejtorinë e Përgjithshme të Tatimeve ka pasur një zhvillim të konsiderueshëm në

fushën e Teknologjisë së Informacionit. Ky zhvillim konsiston në ngritjen dhe përmirësimin e sistemeve

dhe shërbimeve të TIK. Qëllimi i këtyre ndryshimeve është rritja e efektshmërisë së punës në

administratë, lehtësimin dhe disponueshmërinë e funksioneve të sistemeve për tatimpaguesit. Periudha

e dixhitalizimit po transformon në mënyrë të shpejtë lidhjen ndërmjet administratës tatimore dhe

tatimpaguesve. Të shtyrë nga dëshira për më shumë të ardhura, efiçencë më të madhe si dhe

përmirësim të përmbushjes tatimore, administrata tatimore po shtrihet gjithnjë e më shumë në

mbledhjen dhe analizimin e të dhënave për të lehtësuar mbledhjen e tatimeve në kohë reale dhe

vlerësimin e atyre të dhënave.

2.2 Gjendja aktuale në sektor

Sistemi aktual i pajisjeve fiskale në DPT përdoret nga Drejtoritë Rajonale Tatimore, nga shoqëritë e

autorizuara si dhe nga tatimpaguesit. Ky sistem është instaluar në DPT më datën 01.06.2010 ku të

dhënat financiare kryhen nëpërmjet transmetimeve të raporteve tatimore ditore “Z” i cili vazhdon deri

në ditët e sotme. Para kësaj date, transmetimet nga pajisjet fiskale kryheshin 1 herë në muaj.

Aktualisht pajisjet fiskale transmetojnë të dhëna në sistemin qendror nëpërmjet GPRS, në fund të ditës

së punës. Sistemi aktual është i centralizuar. Gjithashtu sistemi nuk identifikon kuponin në kohë reale,

por transmeton vetëm totalin e xhiros dhe numrin total të kuponëve të printuar nga çdo pajisje fiskale

një herë në ditë. Mungon një analize e detajuar për menaxhimin e riskut dhe kontrollit, nuk identifikon

faturat e lëshuara në mënyrë elektronike biznes-biznes dhe faturat me blloqe ngaqë nuk deklarohen

shitësi dhe blerësi, elemente këto të domosdoshme për procesin e punës së DPT-së.

Proceset që kryhen në DPT sipas kontratës së mirëmbajtjes të sistemit.

Ngarkimi dhe përpunimi i të dhënave nga Nexusclient në Nexusserver

Ngarkimi dhe përpunimi i skedarëve të transmetimit në data bazën Nexusserver

Mbarëvajtje e programit të kërkimit të pajisjeve fiskale me kritere të ndryshme kërkimi

Mbarëvajtje e programit të nxjerrjes së gjithë detajeve të transmetimeve për çdo shoqëri dhe

drejtori rajonale.

Mbarëvajtje e programit të kërkimit të transmetimeve të një subjekti ose pajisje fiskale.

Mbarëvajtje e programit të nxjerrjes së statistikave sipas shoqërive dhe drejtorive rajonale.

Mbarëvajtje e programit të kërkimit të operatorëve.

Mbarëvajtje e programit të menaxhimit të usërave të përdorimit të sistemit për DPT, drejtorive

rajonale.

Mbarëvajtje e programit të menaxhimit të usërave të përdoruesve të dokumentit zëvendësues

fiskale.

Organizmi i të drejtave në aplikacion sipas roleve përkatëse.

Mbarëvajtje e gjithë programeve të tjera.

Mbarëvajtje e të gjithë sistemit të raportimit dhe moduleve shtesë.

Proceset që kryhen nga shoqëritë e autorizuara nëpërmjet Sistemit:

1. Hedhja në sistem e kontratave të lidhura midis shoqërive të autorizuara dhe tatimpagueseve.

2. Kryerja e fiskalizimit të pajisjeve nëpërmjet sistemit.

3. Kryerja e procesit të zëvendësimit të modemit nëpërmjet sistemit.

4. Kryerja e procesit të zëvendësimit të memories fiskale nëpërmjet sistemit.

Faqe 10 nga 140

5. Kryerja e procesit të rifreskimit të çelësave (skadenca të përkohshme-2 vjet sipas kontrollit

periodik).

6. Kryerja e procesit të risetimit të pajisjeve fiskale nëpërmjet sistemit.

7. Kryerja e procesit të zëvendësimit të SIM nëpërmjet sistemit.

8. Kryerja e procesit të ndryshimit të adresës së subjektit nëpërmjet sistemit.

9. Kryerjen procesit të mbylljes së aktivitetit të pajisjeve fiskale nëpërmjet sistemit.

10. Kryerjen e procesit të riprogramimit të pajisjeve fiskale nëpërmjet sistemit.

11. Hedhjen e kodit të çdo operatori nëpërmjet sistemit.

12. Hedhjen e IMEI të modemit dhe ICC-ID te SIM kartave nëpërmjet sistemit.

13. Menaxhimi i llogarive të përdoruesve dhe dhënia e të drejtave sipas roleve përkatës.

2.3 Arkitektura e sistemit të pajisjeve fiskale.

Qëllimi kryesor i Platformës Nexus është administrimi i plotë i procesit për instalimin, fiskalizimin dhe

mirëmbajtjen e pajisjeve fiskale dhe sistemeve fiskale. I gjithë informacioni vjen në mënyrë automatike

nga puna që bëjnë operatorët ekonomik të licencuar si dhe nga transmetimi i pajisjeve fiskale apo

sistemet fiskale.

Ky sistem e administron informacionin në mënyrë të detajuar dhe të ndarë sipas:

Pajisjet Fiskale

Sistemet Fiskale për stacionet e karburantit shitje me pakicë

Sistemet Fiskale për depot e karburantit shitje me shumicë

Më poshtë është paraqitur skema aktuale e sistemit të pajisjeve fiskale:

Figura 1: Modeli aktual operativ logjik

Faqe 11 nga 140

2.4 Problematika të sistemit aktual të pajisjeve fiskale dhe administrimi i të gjithë

procesit.

1. Sistemi nuk jep të drejta për organin tatimor për fiskalizimet apo çfiskalizimet, kasat e reja dhe

ekzistuese apo adresat, aktualisht e bëjnë vetëm shoqëritë e autorizuara.

2. Sistemi aktual nuk ka modulin e hartës dixhitale ku të lokalizohen pajisjet fiskale.

3. Sistemi nuk menaxhon ndërhyrjet e teknikëve të autorizuar dhe të japë të drejtat e ndërhyrjes

apo roleve.

4. Kasat fiskale kanë transmetuar shume raporte me mospërputhje vlerash.

5. Teknikët e autorizuar fiskalizojnë të dhëna të pa sakta të subjekteve tek kasa fiskale jo sipas

ekstraktit te QKB. Ndryshimet e adresave të kasave fiskale nuk përputhen sipas të dhënave të

sistemit E-Tax.

6. Sistemi nuk bën kalimin automatik të pajisjes fiskale sipas DRT ku është i regjistruar

tatimpaguesi.

7. Subjektet e kryejnë në mënyrë manuale mbylljen ditore të kasës fiskale duke mos transmetuar

të dhënat financiare për një periudhë të gjatë kohore. Sistemi duhet të bëj mbyllje automatike në

fund të ditës .

8. Kuponi tatimor nuk ka një numër serik unik për çdo transaksion dhe për këtë nuk identifikohet në

sistem kur ai transmetohet në raportin “Z”.

9. Pajisjet fiskale duhet të kenë modem të integruar. Në shumë raste janë hasur probleme me

modemin e transmetimit jo cilësor dhe në raste vjedhje\humbje duhet të ndryshohet manualisht

në sistem seriali i modemit që aktualisht e bën shoqëria e mirëmbajtjes së sistemit duke mos ja

dhënë këtë të drejtë DPT. (Serialet e reja të modemit apo të kartës SIM duhet të përditësohen

nga sistemi dhe të drejtat të jenë të administratës tatimore).

10. Vështirësi në nxjerrjen e të dhënave për sa i përket xhiros sipas datave, muajve, vitit duke qenë

se ka disa skedarë të transmetimit që nuk janë ngarkuar në rregull. Konkretisht kur pajisjet fiskale

standarde transmetojnë më shumë se një datë brenda një skedari, dhe skedari ka brenda disa

rreshta me nr. 10, ngarkohet në sistem vetëm rreshti i parë (rreshti 10 i datës së parë). Rreshtat

e tjerë që përmbajnë xhiron ditore të datave te tjera nuk ngarkohen. Kjo ndikon të gjithë raportet

që dalin mbi xhiron e pajisjes fiskale duke vështirësuar nxjerrjen e xhiros për një kasë fiskale.

(ditore, mujore, vjetore).

11. Pajisjet fiskale kanë kapacitet kufizues për të memorizuar deri në 1800 raporte ditore. Tejkalimi i

këtij kapaciteti ndikon në rritjen e kostos së mirëmbajtjes të tatimpaguesit.

12. “Nexus client” (sistemi aktual) nuk duhet të jetë me ndërfaqe të veçanta për 4 kompani të

autorizuara, për arsye sigurie duhet të jetë me një ndërfaqe dhe me të drejta të kontrolluara.

13. Shumë pajisje fiskale shfaqin “gabim” kur tentojnë të transmetojnë raportin ditor.

Më poshtë janë tipet e “gabimeve” të evidentuara në sistem sipas protokollit të transmetimit:

Viti më i madh se aktuali.

1. 0 rreshta në raport

2. Raporti ka më pak se gjashtë rreshta.

3. Në raport nuk ka rresht 0



6. Ne raport nuk ka rresht 3



9. Nuk ka rresht 99

10. Rreshti 0 nuk i ka të gjitha fushat.

11. Hash i file i panjohur.

12. Raporti ka më pak se gjashtë rreshta.


Faqe 12 nga 140





18. Në raport ka vlera negative

19. Rreshti 99 nuk i ka të gjitha fushat. (ky error është më i shpeshtë mungojnë çelësat

e sigurisë RSA që nënshkruhet raporti Z)

20. Mungojnë disa info për KASËN. Rreshtat 11-15

21. Mungon rreshti shtatëmbëdhjetë.


23. Emri i File gabim

24. Prapashtesa e file nuk është .TXT

25. Rreshti 19 nuk i ka të gjitha fushat

26. Tek rreshti 20 data është bosh.

27. Data e raportit është më vonë se sot.

28. Nr. kuponëve të lëshuar në dite është më shumë se 6000

29. Raporti i Xhiros B progresive me TVSh B progresive është më i madh se 6.2

30. Raporti i Xhiros B progresive me TVSh B progresive është më i vogël se 5.8.

31. Xhiro ditore është zero ndërsa TVSh ditore nuk është zero.

32. TVSh ditore është zero ndërsa xhiro ditore nuk është zero.

33. Xhiro progresive është zero ndërsa TVSh nuk është zero.

34. File nuk mund të Importohet(shkallët e TVSh gabim dhe në vend të numrave ka

simbole)

35. TVSh progresive është zero ndërsa xhiro progresive nuk është zero.

36. Raporti i Xhiros B ditore me TVSh B progresive është më i madh se 6.2

37. Raporti i Xhiros B ditore me TVSh B progresive është me i vogël se 5.8.

38. Në raport ka shitje me xhiro zero.

39. Mungon rreshti shtatëmbëdhjetë.

40. Data raportit gabim

41. Më shumë se një raport në file.

2.5 Pajisjet fiskale

Instalimi i pajisjeve fiskale dhe përdorimi i tyre, është një proces shumë i rëndësishëm i cili ka për qëllim

forcimin e rregullave të konkurrencës së lirë në treg si dhe luftën kundër evazionit fiskal. Vendosja e

pajisjeve fiskale është realizuar në përputhje me Ligjin "Për procedurat tatimore në RSH" dhe aktet

nënligjore të nxjerra në zbatim të tij. Ligji 9920 i Proceduarave Tatimore datë 19.05.2008, i

ndryshuar Neni 55 përcakton detyrimin për përdorimin e pajisjeve fiskale.

2.6 Detyrimi për Përdorimin e Pajisjeve Fiskale

“Tatimpaguesit, që kryejnë qarkullimin e mallrave dhe të shërbimeve, për të cilat pagesat nuk kryhen

nëpërmjet bankës, janë të detyruar të përdorin sistemin fiskal, nëpërmjet përdorimit të pajisjeve fiskale,

për regjistrimin e pagesave me para në dorë dhe për lëshimin, në mënyrë të detyrueshme, të kuponit

tatimor”.

Mbi bazën e këtij ligji u miratua VKM-ja Nr. 781, datë 14.11.2007 e ndryshuar, “Për karakteristikat

teknike dhe funksionale të pajisjeve fiskale sistemit të integruar të kompjuterizuar për transmetimet

periodike automatike të deklarimeve financiare, sistemit të komunikimit, për procedurën e

dokumentacionin për miratimin e tyre dhe për kriteret për pajisjen, me autorizim, të shoqërive të

Autorizuara për ofrimin e pajisjeve fiskale”, dhe Udhëzimi i Ministrit të Financave Nr. 16. datë

03.05.2010.

Faqe 13 nga 140

Në VKM-në 781, datë 14.11.2007 e ndryshuar, është përcaktuar procedura e aplikimit dhe e autorizimit

të shoqërive të autorizuara, dhe kriteret për përzgjedhjen e aplikantëve për “Shoqëri të autorizuar” të

përcaktuara me urdhër të Ministrit të Financave.

Pranë Ministrisë së Financave ngrihet Komisioni i Përhershëm i Shqyrtimit të Aplikimeve për Shoqëri

të Autorizuar. Komisioni miratohet nga Ministri i Financave dhe përbëhet nga përfaqësues të Ministrisë

së Financave, Drejtorisë së Përgjithshme të Tatimeve, Agjencisë Kombëtare të Shoqërisë së

Informacionit (AKSHI), Drejtorisë së Përgjithshme të Metrologjisë, dhe sipas rastit, nga përfaqësues të

ministrisë së linjës apo të institucioneve të tjera, të cilët gjykohen se kanë lidhje me veprimtarinë që do

të kryhet nga shoqëria. Autorizimi nënshkruhet nga Ministri i Financave dhe shoqërohet me kontratën

e lidhur ndërmjet Ministrisë së Financave dhe shoqërisë së autorizuar, ku specifikohen të drejtat dhe

detyrimet që do të kenë palët përkatëse.

2.7 Shoqëritë e autorizuara

Aktualisht janë 4 shoqëri të Autorizuara të cilat tregtojnë dhe mirëmbajnë pajisjet fiskale:

Shoqëritë e autorizuara për furnizimin me pajisje apo sisteme fiskale janë të detyruara të certifikojnë

llojet që do të hedhin në treg, në laboratorë ndërkombëtarë/shqiptarë të certifikuar, njohur nga sistemi

akreditues shqiptar.

Pajisjet dhe sistemet fiskale, para se të vihen në zbatim, miratohen nga komisioni i ngritur me urdhër të

Ministrit të Financave. Komisioni kryen verifikimin, kontrollin e dokumentacionit të certifikimit të tyre, të

mënyrës së lidhjes dhe, në përgjithësi, përputhshmërinë e sistemit me kërkesat e këtij vendimi. Pas

shqyrtimit të dokumentacionit përkatës të paraqitur nga shoqëritë, komisioni merr vendim për

autorizimin ose jo të shoqërive për t’i lejuar për tregtimin e këtyre pajisjeve. Aktualisht janë 27 modele

padisje fiskale të certifikuara nga KMF-ja dhe që tregtohen nga shoqëritë e autorizuara.

Me poshtë paraqitet tabela sipas modeleve të miratuara nga KMF sipas shoqërive të autorizuara:

Pajisjet fiskale të certifikuare

Shoqëria e

Autorizuar

Kodi i Modelit (K.M.F) Nr. i autorizimit Data

AE DISTRIBUTION 88/1 NESSO ALPHA AE02 AE02001491536136 6/16/2010

AE DISTRIBUTION 88/1 ZIP EJ AE01 AE01001342913630 6/16/2010

AE DISTRIBUTION 88/1 GRILLO EJ AE04 AE04000108170599 6/17/2010

AE DISTRIBUTION 88/1 SWEDA POINT AE03 AE03000603569762 6/17/2010

AE DISTRIBUTION 88/1 GB01 AE50 AE50000001598896 7/2/2010

BNT

ELEKTRONICS

88/1 Super Cash S BN03 BN03000140552586 7/8/2010

BNT

ELEKTRONICS

88/1 CRL BN06 BN06000111168353 8/24/2010

BNT

ELEKTRONICS

88/1 CRD BN01 BN01000123137699 8/27/2010

IVA ELEKTRONIK 88/1 MP-55L IV04 IV04222444524178 9/16/2010

IVA ELEKTRONIK 88/1 MP-55B IV06 IV06555666319379 9/16/2010

IVA ELEKTRONIK 88/1 DP-50 IV11 IV11888999629550 9/29/2010

CKV NOKI 88/1 CR20 CK14 CK14000558735717 11/25/2010

CKV NOKI 88/1 QPRINT FM CK10 CK10000556726006 12/3/2010

BNT ELEKTRONICS 88/1 ACLAS CRB BN07 BN07123457847828 12/7/2010

CKV NOKI 88/1 EURO 50T Mini CK12 CK12100001574255 1/12/2011

CKV NOKI 88/1 QMP 5000 CK09 CK09003366579473 1/11/2011

DAISY & ETM 17331/1 Expert DE10 DE10000222956967 1/27/2011

Faqe 14 nga 140

DAISY & ETM 17331/1 Micro DE20 DE20000111855293 1/31/2011

BNT

ELEKTRONICS

88/1 MP55L BN32 BN32123321370181 7/4/2011

IVA ELEKTRONIK 88/1 DP-500 IV31 IV31000002148931 10/20/2011

CKV NOKI 88/1 Unimep PCR 09 CK40 CK40990803871743 3/8/2011

AE DISTRIBUTION 88/1 DI-50 AE05 AE05000001370906 24/02/2012

DAISY ETM 17331/1 ex 300 DE30 DE30000001593677 23/02/2012

BNT

ELEKTRONICS

17331/1 PP7X BN08 BN08000001576502 14/09/2012

DAISY & ETM 15783/2 CR21 DE50 DE50000001653465 15/12/2015

DAISY & ETM 15783/2 QPRINT FM DE40 DE40000001106319 15/12/2015

IVA ELEKTRONIK 1058 DP-25 IV05 IV05000001708035 18/01/2016

Procesi i instalimit të pajisjeve fiskale kaloi në disa faza të përcaktuara në VKM-në 781, datë

14.11.2007 i ndryshuar:

a. Nëntor 2008 – Maj 2009, u instaluan pajisjet fiskale për personat e regjistruar për TVSH-në dhe

tatimin mbi fitimin të cilët administrohen nga Drejtoria Rajonale Tatimore e Tatimpaguesve të

Mëdhenj dhe Drejtoria Rajonale Tatimore, Tiranë;

b. Janar – Dhjetor 2009, u instaluan pajisjet fiskale për personat e regjistruar për TVSH-në dhe

tatimin mbi fitimin të cilët administrohen nga Drejtoritë e tjera Rajonale Tatimore;

c. Qershor 2010, u instaluan pajisjet fiskale për personat e regjistruar në biznesin e vogël, të cilët

ushtrojnë veprimtari në Bashkitë e Tiranës, Durrësit, Vlorës, Gjirokastrës, Fierit, Lushnjës,

Beratit, Sarandës, Korçës, Pogradecit, Elbasanit, Shkodrës e Lezhës. Po brenda këtij afati, janë

të detyruar të mbajnë regjistrime, nëpërmjet pajisjeve fiskale edhe tatimpaguesit e biznesit të

vogël në komunat: Shëngjin, Golem, Rashbull, Orikum, Himarë dhe Ksamil;

d. Dhjetor 2010, u instaluan pajisjet fiskale për të gjithë tatimpaguesit e tjerë të biznesit të vogël.

e. Menjëherë pas hyrjes në fuqi të këtij vendimi, u instaluan pajisjet fiskale për tatimpaguesit me

TVSH dhe që janë subjekt i biznesit të vogël.

2.8 Përjashtohen nga detyrimi i lëshimit të kuponit tatimor:

a. Tatimpaguesit që paguajnë tatime mbi të ardhurat nga kryerja e veprimtarive për shuma të vogla

të të ardhurave neto, me përjashtim të aktivitetit të shërbimit të taksive;

b. Personat që nuk janë tregtarë dhe e realizojnë qarkullimin e produkteve bujqësore dhe të

papërpunuara mbi tezga, në tregjet e organizuara, si dhe jashtë merkatove;

c. Individët që lëshojnë me qira mjedise biznesi;

d. Veprimtaritë të cilat ushtrohen në zona të larta malore, me popullim më pak se 300 individë dhe

që janë të ndryshme nga vendet turistike.

e. Kompania e licencuar për ushtrimin e Lotarisë Kombëtare me ligjin nr. 95/2013 “Për miratimin e

marrëveshjes së licencës për Lotarinë Kombëtare ndërmjet Ministrisë së Financave, si autoritet

i autorizuar dhe shoqërisë “Oesterreinchische Lotterien”, GmbH, nëpërmjet shoqërisë “OLG

Project” sh.p.k., nuk është e detyruar të instalojë e të përdorë pajisje fiskale. Biletat e Lotarisë

Kombëtare janë kupon fiskal.

f. Ambulantët dhe shërbimi i transportit, të përcaktuar në shtojcën nr. 5 të Ligjit nr. 9632, datë

30.10.2006 "Për sistemin e taksave vendore”.

2.9 Statistika e pajisjeve fiskale.

Totali i pajisjeve fiskale (standarde) është 166.004.

Nga të cilat janë aktive 138.530 dhe joaktive 27.474.

Totali i sistemeve të monitorimit të qarkullimit (karburantet) është 5.438.

Nga të cilat aktive janë 2.954 dhe jo aktive 2.484.

Faqe 15 nga 140

Totali i sistemeve fiskale (depo) është 41

Nga të cilat 19 depo janë aktive dhe 22 depo janë joaktive.

Totali i sistemeve fiskale (magazine të lira) është 41.

Nga të cilat 28 magazina të lira janë aktive dhe 19 magazina të lira janë joaktive.

Me poshtë është numri i pajisjeve fiskale dhe sistemeve të monitorimit aktive sipas Drejtorive Rajonale

Tatimore:

Nr. DRT Nr. subjekteve

1 FIER 12.752

2 TIRANA 50.482

3 BERAT 5.420

4 VLORË 7.122

5 SARANDË 3.593

6 KORÇË 8.115

7 GJIROKASTËR 3.768

8 DURRËS 16.931

9 LEZHË 5.003

10 ELBASAN 9.969

11 KUKËS 1.403

12 DIBËR 2.258

13 SHKODËR 8.742

14 DTM 5.926

TOTALI 141.484

2.10 Pajisjet fiskale dhe sistemi fiskal

Pajisjet fiskale dhe sistemi fiskal (të përdorur në sektorë specifikë) shërbejnë për të regjistruar të dhënat

për vlerën e mallrave të shitura dhe shërbimeve të kryera për klientët, duke siguruar në këtë mënyrë

gjenerimin e raporteve të veçanta.

Pajisja fiskale ka si qëllim të regjistrojë dhe të transmetoje të dhënat në sistem, si dhe të printohen në

kupon tatimor.

Në përfundim të orarit të punës çdo tatimpagues, pasi ka mbyllur shitjet ditore, duhet t'i raportojë ato

on-line në serverin e DPT-së, por ky raportim nuk duhet të kalojë orarin më të fundit të pranueshëm të

orës 24:00, pas të cilit fillon një datë e re.

Fillimi i raportimit të shitjeve ditore pas disa ditë ndërprerjesh për arsye të ndryshme kryhet ditën e parë

të fillimit të përdorimit të pajisjes fiskale.

2.11 Komunikimi ndërmjet pajisjeve fiskale dhe DPT-së

Shoqëritë e autorizuara kontraktojnë me Telekom Albania për transmetimin e të dhënave në serverin

e DPT-së.

Kompania mobile ndërton një rrjet privat APN dhe me anë të pajisjeve transmetuese lidhet me sistemin

qendror të DPT. Në mënyrë të vazhdueshme (pa ndërprerje) serverët e DPT-së lidhen me rrjetin e

komunikimit celular GSM në mënyrë që shoqëritë e autorizuara POS të kenë akses dhe secila të

përdorë një linjë të veçantë të drejtpërdrejt në mënyre që të lidhen me rrjetin kryesor të GPRS dhe të

bëjnë të mundur instalimin dhe konfigurimin e pajisjeve fiskale që të realizohet transmetimi i të dhënave.

Më poshtë është paraqitur rrjeti i transmetimit të pajisjeve fiskale

Faqe 16 nga 140

Figura 2: Rrjeti i komunikimit dhe transmetimit midis pajisjeve fiskale

Faqe 17 nga 140

3 OBJEKTIVAT, QËLLIMI DHE REZULTATET E PRITURA

3.1 Objekti i Përgjithshëm

Tatimet zbatohen për të mbuluar shpenzimet kryesore të shtetit dhe për të siguruar qëndrueshmërinë

e tyre. Të ardhurat e mbledhura shërbejnë për mirëmbajtjen dhe zhvillimin e shërbimeve publike.

Mbledhja e shumës së saktë të tatimit në përputhje me ligjin është gjithmonë me rëndësi të madhe. Me

qëllim që të mbrohen të drejtat e qytetarëve dhe të ruhen përfitimet dhe shërbimet që qytetarët presin

nga shoqëria, është me rëndësi që tatimet të mblidhen në mënyrë të plotë dhe në kohë, dhe që

mashtrimi tatimor, evazioni fiskal dhe shmangia e pagesës së tatimit të parandalohen dhe luftohen. Kjo

gjithashtu është çështje e drejtësisë që mundëson që tatimpaguesit e ndershëm të mos ngarkohen me

tatime shtesë për shkak se tatimpaguesit e tjerë nuk i përmbushin detyrimet e tyre dhe nuk paguajnë

tatimet.

Parakusht për funksionimin e mirë të shtetit është që të gjithë qytetarët të përmbushin detyrimet tatimore

dhe të kontribuojnë në mbledhjen e tatimeve. Tatimpaguesit mund të presin që administrata tatimore të

mbledhë vetëm tatimet e nevojshme dhe me ato tatime të mbledhura të financojë përfitimet dhe

shërbimet publike. Nga njëra anë, shteti duhet të sigurojë një kuptim më të mirë dhe më të gjerë të

rëndësisë së tatimeve për shoqërinë. Në mënyrë që të sigurohet që tatimpaguesit zbatojnë detyrimet

tatimore në mënyrën më të lehtë, Administrata Tatimore duhet të bashkëpunojë ngushtë me

tatimpaguesit.

Është shumë e rëndësishme që të ketë një bashkëpunim të fortë, besim dhe mirëkuptim midis

Administratës Tatimore dhe tatimpaguesve, dhe është gjithashtu me rëndësi të sigurohet transparencë

më e madhe e të drejtave dhe detyrimeve të të dyja palëve dhe të inkurajohet mënyra e afrimit të

shërbimit të Administratës Tatimore.

Mashtrimi tatimor dhe evazioni fiskal kufizojnë aftësinë e shtetit për të mbledhur tatimet dhe për të

zbatuar politikën ekonomike. Mashtrimi tatimor është formë e shmangies së qëllimshme të tatimit që në

përgjithësi dënohet me Kodin Penal. Kjo përfshin edhe situatat ku qëllimshëm paraqiten raporte ose

dokumente të rreme. Evazioni fiskal zakonisht përmban aktivitete të paligjshme ku detyrimi tatimor

fshehët ose shpërfillet, d.m.th., tatimpaguesi paguan më pak tatim sesa kërkohet me ligj për të paguar

duke fshehur të ardhurat ose informacionet per Administraten Tatimore.

Për të siguruar këtë, është me rëndësi të madhe të ngrihet efikasiteti dhe efektiviteti i menaxhimit të

mbledhjes së tatimeve. Për këtë arsye, Administrata Tatimore duhet vazhdimisht të përpiqet të

përmirësojë efikasitetin e saj.

Qëllimi kryesor i MKF-së për Administratën Tatimore është të përdorë me efikasitet burimet e saj, të

luftojë mashtrimin tatimor dhe evazionin fiskal dhe të ulë deficitin tatimor / të rrisë të ardhurat tatimore

dhe njëkohësisht të mbajë shpenzimet e tatimpaguesit në nivelin më të ulët të mundshëm. E gjithë kjo

mund të arrihet duke:

përdorur një sistem të përmirësuar të menaxhimit të kontrollit të transaksioneve me para në

dorë (B2C) dhe me para jo cash (B2B) në kohë reale,

kornizë të fuqishme ligjore,

punonjës të trajnuar,

zgjidhje elektronike.

Për të ndaluar mashtrimin tatimor nevojitet që autoriteti tatimor të mbledh informacione të sakta dhe në

kohë në lidhje me natyrën e transaksioneve mashtruese dhe ky informacion duhet të jetë i

disponueshëm në kohë reale.

Faqe 18 nga 140

Gjithashtu, objektiv më të përgjithshme të KFM-së janë:

Zvogëlimi i ekonomisë informale

Lufta kundër konkurrencës së pandershme

Ulja e deficitit buxhetor

Kontroll më i mirë i transaksioneve tregtare midis tatimpaguesve

Kontroll më i mirë i pagesave të vonuara midis tatimpaguesve

Mashtrimi mund të vazhdojë të ekzistojë, por ky hendek duhet të mbyllet me një kontroll më efektiv.

Përveçse ndikon në kapacitetin e kufizuar të qeverisë për të përdorur fondet “e humbura” për zbatimin

e politikave ekonomike dhe sociale, për të parandaluar ose tejkaluar ndonjë krizë ekonomike, evazioni

fiskal dhe mashtrimi tatimor janë veprime të pandershme, sepse ato vënë në pozitë më të privilegjuar

shoqëritë dhe individët të cilët nuk paguajnë tatim në krahasim me të tjerët që rregullisht i përmbushin

detyrimet tatimore. Prandaj, qëllim i MKF-së duhet të jetë pikërisht për të parandaluar mashtrimin dhe

evazionin fiskal.

3.2 Qëllimi

Qëllimet themelore të nënsistemit TP janë:

për të parandaluar evazionin fiskal në transaksionet me para në dorë,

përmirësimi i procedurës së monitorimit tatimor,

monitorimi i orarit të punës së bizneseve, degëve dhe punonjësve (të regjistruar), e cila ka

pasoja të tërthorta në uljen e punës në të zezë,

ngritja e vetëdijes qytetare për rëndësinë e marrjes dhe kërkimit të faturës,

luftimin e konkurrencës së pandershme,

reduktimin e ekonomisë informale.

Bazuar në këto synime, nënsistemi TP duhet:

të sigurojë të ardhura të qëndrueshme tatimore dhe mbushje të buxhetit të shtetit, që është i

rëndësishëm për funksionimin e mirë të organeve shtetërore,

të mundësojë, në afat të gjatë, uljen e mbështetjes publike ndaj të papunëve dhe përfitimeve

sociale,

të mundësojë rritje ekonomike dhe një politikë sociale më të drejtë,

të mbrojë tatimpaguesit, qytetarët dhe shtetin.

Qëllimi i Sistemit është të sigurojë të dhëna të mira dhe cilësore që do të mundësojnë kontroll më të

mirë të tatimpaguesve, si dhe raportime më të mira statistikore dhe analiza më të mira në përgjithësi.

Gjithashtu, qëllim është krijimi i parakushteve për kontroll më të mirë dhe matje të shpenzimeve tatimore

në kuptimin e numrit të faturave të lëshuara me normën zero të TVSH-së, përkatësisht shumën e

transaksioneve të përjashtuara nga pagesa e TVSH-së dhe shumën “e humbur” të të ardhurave

tatimore.

Qëllimet themelore të nënsistemit TJP janë:

parandalimi i evazionit fiskal në transaksionet me para jo ë cash, veçanërisht të paguara në

monedha virtuale ose kripto, d.m.th. të paguara nëpërmjet instrumenteve që nuk përfshijnë

sektorin bankar,

përmirësimi i procedurave të kontrollit tatimor,

ngritja e vetëdijes së tatimpaguesve (B2B) për rëndësinë e marrjes / kërkimit të faturës (fatura

që nuk verifikohet nga DPT nuk mund të shërbejë si dokument komercial i vlefshëm - nuk

Faqe 19 nga 140

përmban garanci, zëvendësim, riparim të mallit dhe as nuk mund të iniciohet masa e pagesës

së detyrueshme)

luftimi i konkurrencës së pandershme,

rritje e efikasitetit në proceset administrative,

reduktim të barrës administrative për sipërmarrësit (heqja e formularëve të tepërt dhe nevojës

për të siguruar të dhëna, pasi që shumica e të dhënave duhet të gjenerohen nga sistemi),

ulje të ekonominë informale.

Qëllimet themelore të eFaturës janë:

lehtësimi i përpunimit të faturës, dërgim më të shpejtë të faturës klientit dhe ruajtje më të lehtë

qendrore me shpenzime shumë të ulëta,

shkurtimi i kohës për dërgimin dhe pagesën e faturës,

rritja e sigurisë në transaksionet komerciale,

shpenzime më të ulëta administrative në transaksionet midis B2G,

ndikim pozitiv ekologjik,

ulja e mundësisë për të bërë gabime,

rritja e efikasitetit në proceset administrative.

Qëllimet themelore të ndjekjes së pagesave me para jo cash:

mbrojtja e tatimpaguesve të vegjël dhe të mesëm në transaksionet tregtare me tatimpaguesit e

mëdhenj (në lidhje me afatet e pagesës)

funksionalitet dhe efikasitet më i mirë në treg, si dhe një mjedis më i mirë për bizneset,

siguri më të madhe ligjore - më shumë investime të huaja,

parandalim i krizave të borxheve me procedura më efikase, më të shpejta dhe më të

automatizuara për fillimin e procesit të pagesës brenda afatit të caktuar,

siguron mundësi për kreditorët për të mbledhur pagesat dhe zbatuar në kohë masat që u

mundësojnë atyre plotësisht dhe në mënyrë efektive realizimin e drejtave të tyre për pagesat e

vonuara,

ballafaqim i debitorëve me masa të rrepta që i pengojnë ata nga vonesat në pagesa ose nga

vendosja e afateve tepër të gjata të pagesës.

3.3 Synimi

Krijimi i një sistemi të mbikëqyrjes në kohë reale të pajisjeve fiskale që operojnë me para në dorë dhe

atyre jo cash, në mënyrë që të ulet evazioni fiskal dhe mashtrimi tatimor. Qëllimi përfundimtar i këtij

projekti është rritja e të ardhurave buxhetore dhe zbatimi i kontrollit efektiv mbi transaksionet cash dhe

jo cash në Republiken e Shqiperise.

3.4 Rezultatet që duhen arritur nga kontraktuesi

Duke përdorur lidhjen në internet, Administrata Tatimore do të shoh çdo faturë të lëshuar dhe të paguar

në ose jo cash. Kjo eliminon evazionin fiskal dhe kontribuon në rritjen e ndërgjegjësimit të

tatimpaguesve për të paguar tatimin.

Një çështje tjetër me rëndësi e këtij projekti është se do të vendosë bazën e të dhënave nën juridiksion

të Administratës Tatimore me të gjitha të dhënat e transaksioneve të tatimpaguesve. Mbyllja e hendekut

mund të mos jetë tepër e vështirë dhe humbjet e taksave që rrjedhin nga ky hendek mund të

neutralizohen në shumë raste (për shkak se nuk janë paraqitur kërkesat për kthim). Zbatimi mund të

jetë në kohë reale.

Faqe 20 nga 140

Rezultatet që duhen arritur janë:

Sistemi i përmirësuarduhet të jetë gjithëpërfshirës dhe të përfshijë transaksionet B2C dhe B2B;

Duhet të jetë më e lehtë dhe më e shpejtë për konsumatorët që të kontrollojnë nëse pranimi ka

kaluar verifikimin (skanimi i kodit QR me telefonin celular - të gjitha të dhënat shfaqen) ;

Duhet të përfshijë transaksione jo cash, d.m.th. pagesa nga një llogari bankare në tjetrën, por

edhe pagesa të bëra nga modele të reja duke përdorur monedhën virtuale dhe kripto, të cilat nuk

janë të kontrolluara nga institucionet financiare dhe si të tilla i japin anonimitet paguesit;

Duhet të mundësojë ndjekjen e afateve të pagesës në kuadër të transaksioneve B2B dhe kështu

të shërbejë si një mekanizëm rregullator për Direktivën e Pagesave me vonesë në Transaksionet

e Biznesit;

Do të mundesojë plotesimin automatik të formularëve që tatimpaguesit (psh. librat e shitjes dhe

blerjes, apo te parambush fusha të caktuara te deklarates se TVSH) duhet të dorezojnë pranë

autoriteteve tatimore;

Duhet të mundësojë monitorim më të mirë të të gjithë tatimpaguesve dhe auditimit të synuar,

zvogëlimin e kostove administrative dhe rritjen e efikasitetit të Administratës Tatimore;

Duhet të lejojë një zvogëlim të numrit të formularëve që tatimpaguesit duhet të paraqesin me

autoritetet tatimore sepse raportet duhet të jenë të mundshme për të gjeneruar automatikisht nga

sistemi - një kosto më të ulët tatimpaguesi administrative;

Duhet të ofrojë të dhëna më të mira për prodhimin e raporteve statistikore dhe vlerësimin e

efekteve të rregulloreve;

Në rastin e pagesës jo cash, duhet të jetë më e lehtë të mbahen gjurmët e parave, ose nëse një

transaksion është realizuar në të vërtetë ose është fiktiv vetëm për të zvogëluar detyrimin tatimor;

Me përpunimin e të dhënave (në varësi të sasisë së të dhënave që do të dorëzohen në AT -

mund të jenë specifike për një sektor ose mallra luksoze) duhet të jetë më e lehtë për të

përcaktuar çmimet e tregut, d.m.th. Nëse çmimet e transaksionit raportohen mbi parimin e

paanshëm ose transaksionet nuk janë të vërteta (transaksione fiktive);

Duhet të jetë e mundur të reagohet më shpejt në rast të mashtrimit dhe të ketë kontroll më të

mirë të TVSH-së;

Në transaksionet B2B, duhet të jetë e mundur që blerësi të përcaktojë menjëherë nëse furnizuesi

është me të vërtetë një pagues tatimor i TVSH-së apo jo;

Të dhënat duhet të dorëzohen në kohë reale;

Duhet të ketë më pak mundësi të manipulimit të të dhënave;

Duhet të ketë kontroll më të mirë dhe krahasim të të dhënave;

Blerësit (qytetarët) duhet të kenë mundësinë për të marrë pjesë drejtpërdrejt në luftën kundër

ekonomisë informale, duke kontrolluar vërtetimin e arkëtimeve nëpërmjet QR kodi;

Duhet të jetë e mundur të bëhet auditimi i synuar, duke mundësuar veprime të shpejta (ndalimi i

punës deri në heqjen e parregullsive, urdhrat për kundërvajtje etj.);

duhet të rezultojë në një sistem më modern me një gamë më të gjerë të përdorimit, veçanërisht

në aspektin e pagesave pa para në dorë dhe monedhës së re virtuale;

Duhet të jetë e mundur të krijohet një tablo më e gjerë e pajtueshmërisë së tatimpaguesve;

Duhet të jetë e mundur që menjëherë të kontrollohen elementet e faturës dhe nëse TVSH-ja e

ngarkuar është në përputhje me ligjin;

Faqe 21 nga 140

4 SUPOZIMET DHE RISQET

4.1 Supozimet e Projektit

Koordinimi me institucionet e tjera do të ketë një ndikim të konsiderueshëm në këtë projekt, pasi ato do të përfshihen në këtë sistem. Angazhim dhe mbështetje e plotë nga të gjithë aktorët të përfshirë në këtë projekt. Bashkëpunimi i plotë i institucioneve pjesë e këtij projekti

4.2 Risqet

Rreziqet kryesore të zbatimit të projektit qëndrojnë para së gjithash në përgatitjen e kuadrit ligjor dhe

organizativ, si dhe në stafin dhe trajnimin.

Për më tepër, ekziston rreziku i rezistencës së konsiderueshme nga grupe të interesit që nuk i përgjigjen

detyrimeve tatimore. Ky fenomen tashmë është parë në vendet që zbatojnë një sistem të ngjashëm.

Prandaj, është e domosdoshme të zbatohet një fushatë e fuqishme e PR dhe marketingut përmes së

cilës qytetarët, të gjithë pjesëmarrësit dhe taksapaguesit në sistem, njihen me përparësitë dhe dobitë e

këtij sistemi për të gjithë vendin.

Mosdalja në kohë e ndryshimeve ligjore dhe akteve nënligjore për realizimin e kërkesave të

projektit.

Aftësia e institucioneve, që të jenë pjesë e projektit, për të siguruar reagimet e nevojshme për

përmbushjen e kërkesave të projektit.

Analiza dhe dizajni i gabuar i sistemit.

Mospërmbushja e të gjitha kërkesave operacionale dhe teknike.

Mospërshtatja e sistemit bazë (CATS) për pritjen e të dhënave që do të plotësojnë automatikisht

deklarimin.

Mungesa e bashkëpunimit te sektorit privat për zhvillimin e projektit.

Reagimi negativ i aktoreve kryesore të këtij projekti jashtë administratës tatimore (tatimpaguesit,

shoqëritë e autorizuara).

Përshtatja e pajisjeve fiskale aktuale me përmirësimin e sistemit.

Kosto e lartë për plotësimin e kërkesave të sistemit nga tatimpaguesi.

Përvoja e personelit të autoritetit kontraktues në projekt.

Koha e zbatimit për të dorëzuar projektin në kohë.

Faqe 22 nga 140

5 SHËRBIMET / QËLLIMI I PUNËS

5.1 Zona gjeografike që duhet mbuluar

Projekti ofron një zgjidhje që mbulon të gjithë territorin e Republikës së Shqipërisë.

5.2 Grupi i synuar

Grupet e synuara përfshinë: Administraten Tatimore, tatimpaguesit në Republikën e Shqipërisë,

organizatat jofitimprurëse, qytetarët e Republikës së Shqipërisë dhe subjektet e tjera.

5.3 Siguria e sistemit

Aksesi në sistem duhet të jetë HTTPS duke përdorur emrin e përdoruesit dhe fjalëkalimin. Duhet të

përdoren certifikatat elektronike e lëshuara nga Organi Certifikues, AKSHI,. USB token. Protokolli i

komunikimit duhet të jetë të paktën TLS 1.2 ose më i lartë.

Sistemi duhet të zbatojë teknikat më të avancuara të sigurisë së sistemeve kompjuterike si:

I. Mekanizmat e autentikimit:

a. Sistemi duhet të ketë identifikim me dy faktorë të inkorporuar në çdo veprim: faktori i parë

duhet të jetë kombinimi i emrit të përdoruesit me kodin e tij dhe faktori i dytë duhet të jete një

kod unik i gjeneraur në varësi te kohës.

b. Opsionet e identifikimit duhet të jenë të konfigurueshme në sistem (pa nevojë programimi

shtesë).

c. Masa te tjera:

Sistemi nuk duhet të lejojë krijimin e llogarive pa fjalëkalime.

Sistemi duhet të ketë aftësinë të mos lejojë përdorimin e “3” fjalëkalimeve të fundit.

Duhet të detyrojë ndryshimin e fjalëkalimeve, detyrimin e kohës limit të vlefshmërisë për

përdoruesit.

Duhet të ketë mundësi kontrolli për të detyruar krijimin e fjalëkalimeve komplekse.

Administratorët nuk duhet të shikojnë fjalëkalimet e përdoruesve, pra ato duhet të ruhen

të shifruar në data bazë.

"Reset" i fjalëkalimit prej administratorëve apo ndryshime të tjera duhet të lajmërojnë

përdoruesin (me e-mail).

Ndryshimet administrative qe përfshijnë, dhënien apo heqjen e privilegjeve, shtimin,

çaktivizimin e përdoruesve që kryhen, duhet të ruhen si gjurmë të cilat mund të shikohen

për arsye auditimi.

Përdoruesi mund të rikuperojë llogarinë nëpërmjet instruksioneve të dërguara

automatikisht nga sistemi me e-mail.

Sistemi duhet të ketë CAPCHA në login për të parandaluar tentativat e automatizuara për

gjetjen e kodeve të aksesit (Brute Force Attacks).

II. Opsionet:

a. Opsione të granularizuara për përdorues, grupe, role, read-write, read-only, no access, etj.

b. Opsione vizibilitetesh sipas statuseve dhe cikleve "lifecycle" të regjistrimeve, dokumenteve

dhe çështjeve.

c. Opsione të shumta në nivel objektesh, çështjesh, regjistrimesh.

d. Opsionet e të drejtave dhe vizibiliteteve të jenë gjithashtu në nivel regjistrimi (p.sh. regjistrime

të caktuara marrin vizibilitete të caktuara megjithëse ndodhen në objekte me vizibilitete me të

përgjithshme) dhe në nivel fushash individuale brenda regjistrimeve.

e. Opsionet të jenë dinamike sipas grupeve/përdoruesve/statuseve p.sh. grupe të ndryshme

mund të shikojnë regjistrime të ndryshme në foldera të njëjtë.

Faqe 23 nga 140

f. Sistemi duhet të mundësojë ndryshimin e vizibiliteteve të fushave në mënyre dinamike

përgjatë çështjeve apo proceseve. P.sh. origjinatori i çështjes mund të ketë akses në disa

fusha minimale për krijimin e çështjes, pasi kalohet çështja në përdorues të ndryshëm, ashtu

shtohen (apo edhe mund të pakësohen) të drejtat e vizibiliteteve të fushave për individët e

ndryshëm.

g. Grupet e përdorueseve do të jenë:

Supervizor

Administrator i sistemit

Drejtor Drejtorie

Operator/Specialist

Shoqëritë e kasave

Tatimpaguesit

III. Shifrimet.

a. Mundësi shifrimi i të gjitha tipave të dokumenteve me teknologji të sigurta SHA2 (Secure Hash

Algorithm).

b. Mundësi shifrimi i të gjitha vlerave sensitive të sistemit në data bazë (fjalëkalimet, hashet,

auditimet, etj.).

c. Fushat në data bazë të konfiguruara “custom” nga institucioni të cilat janë të konsideruara

"sensitive" prej tij, sistemi duhet të ketë mundësinë që t’i shifrojë në data bazë nëpërmjet

veglave të administrimit të sistemit.

d. Komunikime të shifruara SSL.

e. Siguri e lartë aksesimi i "web services" nëpërmjet kanaleve SSL.

f. Aksesimi i metodave të webservice-ve nëpërmjet teknikës NONCE për krijimin e vlerave unike

kriptografike.

IV. Gjurmimi i veprimeve, detektimi dhe parandalimi i ndërhyrjeve, auditimi.

a. Sistemi duhet të regjistrojë në mënyrë automatike veprimet tentative për manipulime.

b. Auditim i gjurmëve të aktivitetit të përdoruesve në sistem.

c. Auditim i të gjitha njoftimeve të dërguara nga sistemi (e-mail).

d. Auditim i login-eve të dështuara

e. Sistemi duhet të kalojë auditimin e automatizuar për testet e sigurisë së sistemit me një prej

sistemeve më të njohur për auditim si p.sh.: Acunetix, Nikto, Blurp Suite etj.

f. Sistemi duhet të detektojë tentativat për të marrë akses të pa-autorizuar në sistem dhe duhet

të komunikoje me Firewall1 të Sistemit të Operimi për krijimin automatik të rregullave të

ndalimit të trafikut nga adresat IP nga të cilat vjen trafiku i dyshimtë.

g. Të gjitha auditimet duhet të jenë të raportueshme.

h. Sistemi duhet të ofrojë konfigurimin e rregullave të cilat përcaktojnë të drejtat e aksesimit të

përdoruesve lidhur me adresën IP nga e cila aksesohet sistemi.

i. Sistemi duhet të përdorë vlerat verifikuese (Check sum) në nivel të regjistrimeve në data bazë

për të kuptuar rastet kur ka modifikime direkt në data bazë.

j. Sistemi duhet të implementoje në nivel të komponentes së ndërfaqesimit me data bazën

algoritme për shifrimin e të dhënave, në mënyrë të tille që fushat me informacion sensitiv të

ruhen të shifruara.

Para se të publikohet, skanohet nga teknologjitë që skanojnë Aplikacionet për vulnerabilitete dhe

dështime të sigurisë nga Skanues të njohur për të gjeneruar raport mbi masat e sigurisë të aplikuara

dhe vulnerabilitete të mundshme:

a. Nëse identifikohen vrima në siguri apo vulnerabilite, njoftohet aplikuesi për ri-kodimin e

vulnerabiliteteve.

b. Nëse nuk identifikohen vrima në siguri apo vulnerabilitete, atëherë website publikohet online.

c. Këto skanime duhet të bëhen në mënyrë periodike si dhe të aplikohen WAF Web Application

Firewall.

Faqe 24 nga 140

5.4 Shërbimet e konsulencës

Autoriteti Kontraktor nga eksperienca të ngjashme në venet fqinje gjykon se operatori

ekonomik duhet të mundësojë minimumi 1400 ditë pune konsulencë, së bashku.

5.5 Kuadri ligjor

5.5.1.1 Përshkrim i përgjithshëm

Kontrolli gjithëpërfshirës i qarkullimit të pagesave me para ne dore dhe të parave jo cash duhet të

rezultojë në një rritje të të ardhurave (buxhetore), që do të mundësojë rritjen ekonomike dhe rritjen e

sigurisë sociale të qytetarëve. Me permiresimin e sistemit duhet të kontribuojë në barazi dhe drejtësi

në sistemin tatimor, që do të thotë se në përmbushjen e nevojave publike, të gjitha palët duhet të marrin

pjesë në përputhje me aftësitë e tyre ekonomike. Këto përmiresime do të ulin mundësinë e evazionit

fiskal, i cili do të kontribuojë edhe krijimin e në një konkurrencë të ndershme të tregut, pasi do të

shmang konkurrencën e pandershme.

Për zbatimin e suksesshëm të kesaj metodologjie është e nevojshme të njoftohet i gjithë publiku me

qëllimet e projektit dhe të bëhet një analizë gjithëpërfshirëse e kuadrit normativ ekzistues, situatës

ekonomike, opinionit publik si dhe të sigurohet zbatimi dhe analiza e strukturës së informatikës.

Analiza e kuadrit ekzistues normativ duhet të përfshijë ligjet dhe aktet nënligjore të miratuara nga DPT-

ja për mbledhjen e tatimeve, dhe ligjet e përgjithshme dhe të veçanta që përcaktojnë kompetencat e

DPT-së. Gjithashtu është me rëndësi të analizohet edhe legjislacioni për mbrojtjen e të drejtave dhe

lirive të njeriut, dhe në këtë kuptim duhet analizuar ligjet që rregullojnë mbrojtjen e të dhënave

personale, sekretit bankar, sigurinë e informacionit dhe fshehtësisë, në mënyrë që të dihet nëse për

shkak të këtij modeli të ri është e nevojshme të ndryshohen këto ligje. Analiza duhet të përfshijnë edhe

ligjet që kanë të bëjnë me sistemin financiar, siç është ligji që rregullon sistemin e pagesave, ligji për

institucionet kreditore, ligji i sigurimeve, etj., sepse mund të jenë të rëndësishëm në transaksionet në

para jo cash, ligjin për shoqëritë tregtare dhe ligjin për marrëdhëniet e detyrimeve, përkatësisht ligjet

që rregullojnë marrëdhëniet ndërmjet subjekteve në këmbimet e ndërsjella. Në kuadër të projektit mund

të analizohen edhe ligjet që rregullojnë mbledhjen e pagesave të detyrueshme në mënyrë që të

lehtësojë më tej procedurat për mbledhjen e detyrueshme në bazë të transaksioneve të regjistruara në

sistemin e ri si dhe ligji për mbrojtjen e konsumatorit. Meqenëse Republika e Shqipërisë është kandidat

për anëtarësim në BE, duhet kryer një analizë e kuadrit ligjor të BE-së në mënyrë që në të ardhmen e

afërt të mos ketë nevojë të ndryshohet përsëri legjislacioni.

Në bazë të analizës së kuadrit normativ do të hartohet një plan i aktiviteteve normative që do të përfshijë

të gjitha ndryshimet e nevojshme legjislative për zbatimin e sistemit.

Për zbatim të suksesshëm të sistemit , përveç analizimit të kuadrit ligjor, në mënyrë paralele dhe në

fazën më të hershme, duhet të fillojë diskutimi publik për të përgatitur opinionin publik. Por, edhe kjo

duhet të merret parasysh në legjislacionin kombëtar. Prandaj, menjëherë pas propozimit të aktiviteteve

normative për zbatimin e sistemit, përkatësisht gjatë hartimit të tezave për ligje të caktuara, duhet të

fillojë debati publik. Pjesëmarrja në debatin publik duhet t’u mundësohet të gjitha grupeve të interesit,

ndërsa për ato grupe që do të jenë palë në modelin e ri, do të zhvillohet plani i veprimit. Debati publik

duhet të ndjekë të gjitha fazat e projektit duke filluar nga ideja e projektit dhe tezave në DPT deri në

fazën e ligjvënies në parlament për të siguruar mbështetjen e publikut dhe mbështetjen parlamentare

në bazë të objektivave të sistemit të përmirësuar.

Faqe 25 nga 140

Zbatimi i zgjidhjes së informatizimit dhe zhvillimi i legjislacionit të nën akteve, që do të zbatohet

menjëherë pas hyrjes në fuqi të ligjeve të reja ose të ndryshuara.

Parakusht për zbatimin e suksesshëm të sistemit është krijimi i një kuadri ligjor të fuqishëm që do të

jetë në përputhje me kuadrin ligjor ekzistues të BE-së në tiparet e tij thelbësore. Sistemin e TI-së duhet

ta mbështesë plotësisht kuadrin e ri ligjor dhe të sigurojë sinergji të nevojshme në përputhje me

rrethanat.

Kuadri i ri legjislativ duhet të përcaktojë qartë të gjitha detyrimet e tatimpaguesve në nënsistemet TP

dhe TJP në një vend, i cili duhet të rezultojë në paraqitjen e saktë të obligimeve, gjetjen, përdorimin dhe

interpretimin e detyrimeve ligjore të tatimpaguesit, duke eliminuar nevojën për sqarime dhe udhëzime

të mëtejshme nga DPT-ja.

Përveç aktiviteteve legjislative, është e rëndësishme t’i kushtohet vëmendje prezantimit në media të

sistemit , që do të zbatohet nga tatimpaguesit. Është gjithashtu e rëndësishme të bëhet një vlerësim i

ndikimit të rregullave të reja duke analizuar mundësitë dhe përparësitë e ndryshme të opsioneve të

përzgjedhura, d.m.th. përparësitë, rreziqet dhe shpenzimet.

5.5.1.2 Analiza e hendekut ekzistues legjislativ

Në mënyrë që projekti të jetë i suksesshëm, së pari duhet të identifikohen problemet dhe pengesat më

të mëdha që ndikojnë në mos pagesë të rregullt të tatimit nga tatimpaguesit, dhe pse qytetarët/blerësit

marrin pjesë në mashtrim (nuk marrin faturën/nuk raportojnë mos faturimin edhe pse paguan çmimin

me TVSH/nuk raportojnë mos faturimin kur çmimi i mallrave ose shërbimeve nuk përfshin TVSH-në

etj.).

Prandaj, analiza e kuadrit ligjor ekzistues duhet të përfshijë segmentet e mëposhtme:

• hulumtimi i tregut

• analizë të kuadrit ligjor ekzistues në Republikën e Shqipërisë

• analizë të të dhënave ekzistuese mbi tatimpaguesit në Republikën e Shqipërisë

• identifikimi i elementeve kryesore

• analizë të kuadrit ligjor aktual të BE-së

Hulumtimi i tregut duhet të përfshijë:

o situatën ekonomike në Republikën e Shqipërisë në 10 vitet e fundit dhe tendencat e Prodhimit

të Brendshëm Bruto (PBB-së)

o numrin e të papunëve në Republikën e Shqipërisë dhe tendencat

o numrin e të punësuarve, të vetë punësuarve dhe tendencat

o numrin e personave juridikë-tatimpaguesve që paguajnë tatim në fitim dhe tendencat

o pagën mesatare në Republikën e Shqipërisë dhe tendencat

o standardin e jetesës dhe tendencat

o çmimin e shportës së konsumit dhe tendencat

o degët më të rëndësishme të industrisë që gjenerojnë më së shumti të ardhura dhe tendencat

o shtrirjen e ekonomisë informale dhe tendencat

o shtrirjen e përdorimit të internetit dhe në përgjithësi pjesa e ekonomisë dixhitale cili është

mendimi i tatimpaguesve për:

Administratën tatimore dhe punonjësit e saj

legjislacionin tatimor

normat e tatimeve (në veçanti TVSH-së)

procesin e përmbushjes së detyrimeve tatimore

Faqe 26 nga 140

barrën administrative gjatë përmbushjes së detyrimeve tatimore

shpenzimin e mjeteve buxhetore që janë burim i të ardhurave tatimore

informacionin e nevojshëm në dispozicion për përmbushjen e detyrimeve tatimore

tatimpaguesve që nuk paguajnë tatim

o sa është hendeku i TVSH-së sipas metodologjisë së Bashkimit Evropian

o mbulesa me internet në Republikën e Shqipërisë

o në cilët sektorë / lloje të aktivitetit është pjesa më e madhe e mashtrimit tatimor

o analizë të sistemeve ekzistuese të monitorimit të rrjedhës së parave në cash dhe jo cash, e-

Faturës dhe monitorimit të pagesave në vende të tjera etj.

Ofertuesi duhet të kryej një analizë të hollësishme të kuadrit ekzistues ligjor në Republikën e Shqipërisë

me qëllim të përcaktimit të ligjeve dhe akteve nënligjore që duhet të ndryshohen, në mënyrë që të

përmbushen nevojat e permiresimeve të sistemit në kuadër të këtij projekti, ashtu që të mos ketë

përkime me dispozitat në akte të ndryshme ligjore.

Për këtë arsye është e nevojshme që në veçanti të bëhet një analizë e kornizës legjislative në vijim:

Ligji nr.: 9920, datë 19.5.2008 "Për procedurën tatimore në Republikën e Shqipërisë".

Ligji nr. : 8438, datë 28.12.1998 "Për tatimin mbi të ardhurat"

Ligji nr. : 92/2014 "Për Tatimin mbi Vlerën e Shtuar"

Ligji nr.: 9975 "Për taksat kombëtare"

Ligjit nr.: 9632 "Sistemin e taksave vendore,i ndryshuar "

Ligji nr.: 9136 "Për mbledhjen e kontributeve të detyrueshme të sigurimeve shoqërore dhe

shëndetësore në Republikën e Shqipërisë"

Aktet tjera ligjore dhe nënligjore që kanë të bëjnë me ligjet e lartpërmendura

Kodi penal

Ligje të tjera të rëndësishme jo tatimore (legjislacioni financiar, legjislacioni nga fusha e ekonomisë,

legjislacioni bankar, ligjet që përcaktojnë sekretin bankar, mbrojtja e të dhënave etj.)

Ofertuesi kërkohet të bëjë një analizë të hollësishme të tatimpaguesit që përfshin:

- Analizimi i të dhënave ekzistuese që ka në dispozicion DPT mbi tatimpaguesit për të përcaktuar

pozicionin fillestar me qëllim të vlerësimit të projektit pas zbatimit të tij

- Analizimi i nivelit të raportuar i të ardhurave/fitimit/TVSH-së nga tatimpaguesit

- Analizimi i të dhënave mbi qarkullimin e regjistruar përmes pajisjeve fiskale

- Analizimi i tendencave, sidomos nëpër aktivitete të ndryshme ekonomike, dhe përcaktimi i

madhësisë së ndërmarrjeve (të vogla, të mesme, të mëdha)

- Analizimi i të gjitha të dhënave në dispozicion mbi kontrollet e kryera tatimore dhe përcaktimi i

numrit dhe llojeve të parregullsive që ndodhin

Pas kryerjes së analizave, është e nevojshme të identifikohen elementet kryesore të rëndësishme për

zbatimin e suksesshëm të projektit:

Cila është gjendja aktuale

Çfarë duhet të bëjmë për të arritur qëllimet

Si të arrijmë ato

Sa kushton

Sa kohë nevojitet

Cilat janë rreziqet dhe problemet e mundshme të zbatimit?

Edhe pse Republika e Shqipërisë nuk është shtet anëtar i BE-së, Ofertuesi është i obliguar që në

bashkëpunim me Ministriee e Financave dhe Ekonomise dhe Administraten Tatimore të harmonizojë

Faqe 27 nga 140

të gjitha aktet e ardhshme legjislative në masën e mundshme me kuadrin ligjor ekzistues të BE-së.

Prandaj është thelbësore që të bëhet një analizë e kornizës ligjore ekzistuese e BE-së, në veçanti:

parimet themelore të së drejtës së BE-së

parimet themelore në fushën e tatimeve

Direktiva kundër Shmangies së Tatimit

Direktiva për Bashkëpunimin Administrativ

VIES (Sistemi i shkëmbimit të informacionit të TVSH-së)

Sistemi MOSS për TVSH-në në telekomunikacion, transmetim dhe shërbime elektronike

Plani i Veprimit për Forcimin e Luftës kundër Mashtrimit në Tatim dhe Shmangies së Tatimit

Komunikatë mbi “Sistemin tatimor të drejtë dhe efikas në Bashkimin Evropian për tregun e

përbashkët dixhital”

Direktiva e TVSH-së

Direktivat për mbrojtjen e konsumatorit

Direktiva e pagesës me vonesë

Rregullorja (BE) Nr. 910/2014 e datës 23 korrik 2014 mbi shërbimet elektronike të identifikimit

dhe besimit për transaksionet elektronike në tregun e brendshëm

Vendimi Zbatues i Komisionit (BE) 2015/296 e datës 24 shkurt 2015 mbi marrëveshjet

procedurale për bashkëpunimin e MS në eID

Rregullorja Zbatuese e Komisionit (EU) 2015/1501 e datës 8 shtator 2015 mbi Kornizën e

Interoperabilitetit

Rregullorja Zbatuese e Komisionit (BE) 2015/1502 e datës 8 shtator 2015 mbi vendosjen e

standardeve minimale për mjetet e identifikimit elektronik

Vendimi Zbatues i Komisionit (BE) 2015/1984 i datës 3 nëntor 2015 që përcakton rrethanat,

formatet dhe procedurat e njoftimit

Direktiva 2014/55 / BE për faturimin elektronik në prokurimin publik

Direktiva 2013/34 / BE mbi Pasqyrat Vjetore Financiare, Pasqyrat Financiare të Konsoliduara

dhe Raportet përkatëse për disa lloje të ndërmarrjeve

GDPR - Rregullorja e Përgjithshme e Mbrojtjes së të Dhënave

Është shumë e rëndësishme që aktet e reja ligjore dhe zbatuese për këtë projekt nuk bien në

kundërshtim me kuadrin ligjor të BE-së, në mënyrë që të mos ndryshohen në të ardhmen, dhe të

sigurohet stabiliteti i sistemit dhe siguria ligjore, por edhe të shmangën shpenzimet shtesë për shkak të

ndryshimeve të mundshme, si për tatimpaguesit ashtu edhe për DPT-në.

5.5.1.3 Përgatitja e një kuadri të ri ligjor

Përmbajtja dhe zhvillimi i një kornize të re ligjore mund të varet nga:

1. Qëllimet dhe nevojat që duhet të arrihen përmes zbatimit të këtij projekti,

2. Analiza e kuadrit ligjor në fuqi,

3. Analiza e legjislacionit të BE-së,

4. Specifikat e tregut,

5. Shpenzimet e parashikuara,

6. Kapacitetet zbatuese (njerëzore dhe teknike).

Përgatitja e kuadrit ligjor duhet të jetë:

Gjithpërfshirës - është e nevojshme të përshkruhen në hollësi dhe të parashikohen sa më

shumë të jetë e mundur situatat nga përvoja që kanë ndodhur ose mund të ndodhin; është e

nevojshme të plotësohen standardet ekzistuese ose të futen standarde të reja në një kuadër

ligjor të veçantë që është thelbësor për këtë sistem dhe funksionimin e tij efikas

I sigurt nga aspekti ligjor për një periudhë të gjatë kohore

Faqe 28 nga 140

I kuptueshëm dhe i qartë (duhet të sigurohet zbatim i barabartë nga ana e subjekteve që e

zbatojnë)

I thjeshtë (i zbatueshëm në atë mënyrë që subjektet nuk shmangin aplikimin e sistemit për

shkak të kompleksitetit të tij)

Transparent (draft kuadri ligjor duhet të jetë në dispozicion të publikut për palët e interesuara

për diskutim)

Kuadri ligjor duhet të rregullojë dispozitat themelore si në vijim:

Detyrimi (vs. opsioni) për të zbatuar sistemin me permiresimet e tij.

Identifikimi i subjekteve që do të zbatojnë zgjidhjen e dhene

Mbulimi i sistemit: pagesat në para cash dhe jo cash

Përjashtimet nga zbatimi i zgjidhjes se re

eFatura (fatura elektronike)

Përcaktimi i procedurave për zbatimin e sistemit të permiresuar

Përmbajtja e faturës – harmonizimi me rregulloret e veçanta

Afatet për hyrjen në fuqi dhe zbatimi i sistemit të permiresuar – harmonizimi me rregulloret e

veçanta

Detyrimet dhe afatet për ruajtjen e faturave – harmonizimi me rregulloret e veçanta

Maksimumi i parave në arkë – harmonizimi me rregulloret e veçanta

Mbrojtja e të dhënave - harmonizimi me rregulloret e veçanta

Përdorimi i të dhënave

Monitorimi i zbatimit të sistemit

Nevojat teknike dhe parashikimet

Dispozitat kundërvajtëse

Hyrja në fuqi

Kuadri ligjor kërkon:

Përgatitjen e projektligjit të ri për permiresimin e sistemit

Përgatitjen e drafteve të rregullave zbatuese, udhëzimeve, metodologjisë

Përgatitjen e harmonizimit të rregulloreve ekzistuese tatimore

Përfshirjen në sistemin ligjor ekzistues dispozitat e reja, nëse është e nevojshme

5.5.1.4 Debati publik

Pas hartimit të një propozimi të ri legjislativ, Ministria e Financave dhe Ekonomise dhe Administrata

Tatimore do të zhvillojë një dëgjim publik për të mbledhur mendime nga palët e interesuara, d.m.th. të

të gjitha palëve të interesuara të cilët do të jenë të detyruar të zbatojnë një model të ri, siç janë qytetarët,

subjektet juridike, sipërmarrësit, shoqatat e sipërmarrësve, shoqatat e bankave, dhomat e tregtisë,

organizatat, përfaqësuesit e sektorit të TI-së etj. Ofertuesi duhet të ndihmojë MFE dhe Administraten

Tatimore (AT) me sqarime dhe përgjigje për pyetjet e mundshme të palëve të interesuara.

Për nevoja të projektit, MFE dhe AT gjithashtu do të krijojë një grup të fokusit (këshilltarët tatimor,

përfaqësuesit e tatimpaguesve, shoqatat e ndërmarrësisë, etj.) për të paraqitur modelin e ri dhe t’u

lejojë atyre të bëjnë pyetje dhe të sugjerojnë idetë e tyre për përmirësimin e sistemit, përkatësisht duke

marrë parasysh specifikat e caktuara të subjekteve ekonomike.

Nga Ofertuesi pritet:

Pjesëmarrje aktive në debatin publik.

Sugjerimi i pyetjeve për grupin e fokusit

Përgatitja e materialeve dhe prezantimeve për diskutime publike

Faqe 29 nga 140

Pas opinioneve të grumbulluara përmes dëgjimit publik dhe diskutimit brenda grupit të fokusit, Ofertuesi,

në bashkëpunim me MFE dhe AT do të:

Analizojë komentet dhe sugjerimet e pranuara

Përgatisë përgjigje, sqarime pyetjeve nga debati publik dhe fokus grupet

Hartojë propozimin përfundimtar të kuadrit ligjor

5.5.1.5 Miratimi i Ligjit

Gjatë miratimit të Ligjit nga organi legjislativ, Ofertuesi do të sigurojë:

Mbështetje në lidhje me prezantimin publik të kuadrit të ri ligjor

Përgatisë përgjigje për gazetarët dhe publikun e interesuar, duke përfshirë edhe kohën gjatë

fushatës afirmative të zbatimit të sistemit të ri

5.5.1.6 Miratimi i ligjeve për zbatim

Gjatë dhe pas procedurës së kuadrit ligjor, Ofertuesi në bashkëpunim me MFE dhe AT do të:

Hartojë të gjitha udhëzimet e nevojshme për tatimpaguesit

Propozojë hartimin e rregulloreve të nevojshme zbatuese për implementimin e kuadrit ligjor

Sigurojë mbështetje për bashkëpunim të plotë me tatimpaguesit në zgjidhjen e problemeve

tatimore

Shqyrtojë brenda kuadrit ligjor të përshkruar, rrethana të veçanta që kanë ndikim në

tatimpaguesit

Analizojë, gjatë zbatimit të projektit, kuadrin ligjor dhe të propozojë ndryshimet potenciale dhe

përmirësimin e akteve nënligjore

5.5.2 ORGANIZIMI DHE METODOLOGJIA E MONITORIMIT TATIMOR TË TATIMPAGUESVE NË

NËNSISTEMIN TP

5.5.2.1 Përmbledhje

Monitorimi i tatimeve të tatimpaguesve është element kryesor në politikën tatimore të secilës

Administrate Tatimore. Në këtë kuptim, monitorimi i tatimeve mund të kryhet me metodën e

përzgjedhjes së rastësishme, që do të thotë se tatimpaguesi është përzgjedhur rastësisht.

Sistemi me permiresimet e tij duhet t’i mundësojë AT të marrë të gjitha të dhënat dhe informacionin

përkatës mbi tatimpaguesin, të analizojë dhe krahasojë ato, të marrë të dhënat nga sistemi SMR për të

identifikuar tatimpaguesin që nuk vepron në përputhje me legjislacionin tatimor. Një analitikë e tillë për

monitorim të tatimpaguesit duhet të sigurojë monitorim të shënjestruar dhe në kohë të tatimeve të

tatimpaguesve në nënsistemin TP.

Çdo tatimpagues mund të emërojë një konsulent tatimor ose një konsulent i cili së bashku me të do të

marrë pjesë në procedurën e kontrollit tatimor.

Qëllimi dhe objektivat e nënsistemit të ri të kontrollit tatimor janë:

1. për të arritur monitorim të shënjestruar tatimor të tatimpaguesve më kritik

2. që, duke përdorur e-monitorimin, rritet numri i kontrolleve

3. për të zvogëluar shpenzimet për çdo rast të monitorimit.

4. për të menaxhuar në mënyrë më efikase kapacitetet njerëzore

Faqe 30 nga 140

5.5.2.2 Analiza e procedurave ekzistuese tatimore dhe rregulloreve për kontrollin e taksave

Ofertuesi duhet të kryejë një analizë të procedurave ekzistuese të monitorimit tatimor, i cili përfshin:

o të analizojë të gjitha aktet e shkruara që përcaktojnë procedurën ekzistuese të monitorimit të

tatimit në përgjithësi në Administratën Tatimore dhe procedurës së veçantë për kontrollin e

pajisjeve fiskale

o të kryejë një analizë të hollësishme të dispozitave të përgjithshme procedurale që rregullojnë

procedurën e monitorimit dhe ndjekjes se tatimeve, dokumenteve në procedurën tatimore, të

drejtat dhe detyrimet e tatimpaguesve në procedurat tatimore etj.

o të identifikojë qartë dobësitë kryesore dhe të tregojë nëse ka nevojë për ndryshime ligjore në

përshpejtimin e procedurës tatimore

o analizojë strukturën aktuale organizative të njësisë së monitorimit të tatimit (në cilin nivel

organizativ dhe në cilat njësi organizative kryhet monitorimi, kush kontrollon pajisjet fiskale dhe

në çfarë mënyre, a janë prodhuesit objekt i kontrollit të punës së tyre etj.)

o analizojë në hollësi regjistrat ekzistuese të tatimpaguesve, për të përcaktuar grupet (kategoritë)

e tatimpaguesve që do të përfshihen në monitorim dhe numri i individëve brenda secilit grup

5.5.2.3 Procedura e kontrollit tatimor

Në thelb, monitorimi tatimor i tatimpaguesve në nënsistemin TP dhe TJP zbatohet duke përdorur të

njëjtat metoda dhe procedura. Megjithatë, Ofertuesi duhet të marr parasysh se ekziston një dallim në

shkallën e rrezikut për transaksionet në para në dorë (prirja për të shmangur pagesën e tatimit- një

numër më i madh i tatimpaguesve mashtrues, per shuma të vogla) dhe ata që paguajnë në para jo

cash fatura fiktive etj.), kështu që monitorimi tatimor do të jetë specifik për secilin grup.

Theksi për monitorimin tatimor të tatimpaguesve të nënsistemit TP do të duhet të zbatohet në

korrelacion me informatat e tjera financiare të tatimpaguesit dhe monitorimin paralel tatimor të

pjesëmarrësve të përfshirë në një transaksion (ndjekja e transaksioneve).

Faqe 31 nga 140

AK

SH

IG

DT

TA

XP

AY

ER

TA

X A

UD

IT P

RO

CED

UR

E (G

DT)

Call

centreAPI

DMS

API

Inspector for audit

Notification of

irregularity

Order

for audit

API

HRMS

DMS

HRMS

AUDIT

Audit

proceedings

ComplaintBusiness

premises

Completion of

TA audit

OnLine

audit

Audit

notice to TP

Audit

pronouncement

Figura 3: Kontrolli i procesit të biznesit

Specifikimet e kërkesave të biznesit:

o të përcaktojë grupet e tatimpaguesve të cilët zbatojnë nënsistemin e ri të pagesave në para

cash dhe para jo cash

o të përcaktojë numrin e tatimpaguesve në secilin grup sipas kriterit të “llojit të veprimtarisë” për

pagesat në para cash dhe para jo cash.

o të përcaktojë numrin e tatimpaguesve në secilin grup sipas kriterit të “statusit të tatimpaguesit”

për pagesat në para cash dhe para jo cash (persona fizikë ose juridikë)

o të përcaktojë numrin e tatimpaguesve në secilin grup sipas kritereve të “juridiksionit rajonal” për

pagesat në para cash dhe para jo cash

o përcaktojnë numrin e tatimpaguesve në secilin grup sipas kritereve të “llojit të veprimtarisë” dhe

“statusit të tatimpaguesit” për secilin kriter të “juridiksionit rajonal” për pagesat në para cash

dhe para jo cash

o të përcaktojë numrin e tatimpaguesve sipas numrit të inspektorëve në dispozicion sipas kriterit

të “juridiksionit rajonal”

o vendos standardet për monitorim në online vs. metodat tradicionale (në%)

o të përcaktojë nevojën për shpërndarjen e inspektorëve në dispozicion midis rajoneve

o të përcaktojë nevojën për ndarjen e orarit të punës të inspektorëve

o të përcaktojë bartësit e proceseve nëpër njësi organizative dhe individualisht nga inspektori

o të specifikojë dokumentet tatimore të përcaktuara me ligj në procedurë (njoftim, procesverbal,

vendim etj.)

o të përcaktojë grupet e synuara të tatimpaguesve sipas afatit kohor të monitorimit të tatimit (duke

marrë parasysh aktivitetet sezonale)

o të përcaktojë grupet e synuara të tatimpaguesve sipas rezultatit të analizës së riskut

o të përcaktojë metodat e sanksionimit (të lehta dhe të rënda)

o të përcaktojë procedurën e sanksionimit (brenda AT ose organit gjyqësor)

Faqe 32 nga 140

o të përcaktojë procedurën e analizës ex post (Analiza ex post është një analizë e avancuar dhe

komplekse e tatimpaguesve duke u bazuar në të gjitha informacionet në dispozicion. Kjo

analizë shërben për planifikim më efikas të auditimit tatimor ( i ashtuquajturi auditim i

shënjestruar))të përcaktojë procedurën e analizës ex post, sipas njësisë organizative, dhe çdo

inspektori

o të përcaktojë procedurën pas analizës ex post

5.5.2.4 Identifikoni komponentët kryesorë të riskut të kuadrit të ri ligjor

Brenda rreziqeve të përcaktuara, Ofertuesi duhet të identifikojë rreziqet që inspektorët tatimor duhet të

përqendrohen në shqyrtimin e analizës aktuale të sjelljes së tatimpaguesit në nënsistemin TP dhe

rreziqet që do te dalin nga rezultatet e monitorimit të viteve të kaluara, p.sh. nëse ekziston një risk më

i lartë i mos faturimit ose përdorimi i një sistemi të dyfishtë.

Është gjithashtu e nevojshme të përcaktohet risku i brendshëm i zbatimit të ligjit: a do të jenë në gjendje

palët kryesore të interesit në procesin e ri të punës të përmbushin kërkesat që do të vendosen para

tyre, pavarësisht nëse janë të arsimuar në mënyrë të mjaftueshme për të kryer e-monitorimin, etj.

5.5.2.5 Përgatitja e procedurave të reja të ndjekjes dhe monitorimit të tatimeve

Ofertuesi duhet të përgatisë një propozim me shkrim për një kornizë të re ligjore (ndryshimet dhe

plotësimet ligjore, metodologjinë dhe udhëzimet) me të cilat përcaktohen procedurat dhe metodat për

zbatimin e monitorimit tatimor, të përcaktojë qartë dokumentet që lidhen me procedurën.

Më tej, Ofertuesi duhet të përgatisë:

o ndjekje organizative të dokumenteve të lëshuara ligjore dhe zbatuesve

o përcaktimi i mënyrave të përpunimit statistikor të rezultateve të monitorimit tatimor për të gjithë

parametrat, veçmas për tatimpaguesit dhe inspektorët / shërbimet / njësitë rajonale

o Metodologjinë, organizimin dhe procedurat për Qendrën e Thirrjeve

o parakushtet e TI-së për e-monitorimin e tatimpaguesve në nënsistemin TP

o modelet standarde për e-monitorimin e tatimpaguesve në nënsistemin TP

o organizimin e procedurave të e-monitorimit të tatimpaguesve në nënsistemin TP

o Sistemin e monitorimit tatimor “nga zyra” dhe identifikimi i njësive organizative për zbatim

o procedurën e e-monitorimit dhe inspektorëve të përfshirë tatimor

o procedurën e metodave tradicionale të monitorimit tatimor në të gjitha organizatat e monitorimit

tatimor

Metodologjia e monitorimit tatimor në nënsistemin TP është një dokument i shkruar të cilin e lëshon një

organ tatimor kombëtar, i cili përcakton mënyrën, hapat dhe procedurat për monitorimin tatimor dhe

përcaktohet në përputhje me rregullat ligjore që rregullojnë një procedurë të tillë.

Nënsistemi i ri i tatimeve,në krahasim me metodat tradicionale klasike të monitorimit tatimor, duhet të

rezultojë në:

o shkurtimin e kohës së monitorimit tatimor (hartimin e metodologjisë që do të sigurojë

parakushte për monitorim tatimor të shumëfishtë gjatë një dite të vetme)

o monitorimin e thjesht tatimor në nënsistemin TP

o reduktimin e “letrës” në proces e sipër

o Nivel të lartë të disponueshmërisë së të gjitha dokumenteve në mënyrë elektronike

o Kryerje e procedurave “nga distanca” të monitorimit tatimor pa kontakt fizik me tatimpaguesin

Faqe 33 nga 140

Bazuar në këto nevoja, vendimi për metodologjinë e monitorimit tatimor duhet të bazohet në supozimet

e efikasitetit dhe efektivitetit, duke maksimizuar përdorimin e mjeteve bashkëkohore dhe metodave të

monitorimit tatimor të tatimpaguesve në nënsistemin TP (online ose e-monitorim).

Supozimet bazë të secilës metodologji janë:

1) pjesëmarrësit në këtë proces

2) rregullat mbi të cilat bazohet procedura

3) mënyra e komunikimit midis tatimpaguesve dhe AT

4) mjetet juridike

Me qëllim monitorimin dhe zbatimin e një sistemi të monitorimit tatimor, metodologjia duhet të përfshijë:

- përkufizimin e grupeve (kategorive) të synuara të tatimpaguesve për të cilët zbatohet ligji

- përkufizimin e llojit të dërgesave të mallrave dhe / ose shërbimeve ndaj të cilëve zbatohet ligji

- përkufizimim e kategorisë (kategorive) të tatimpaguesve që përjashtohen nga zbatimi (përjashtimet institucionale) dhe llojet e dërgesave të mallrave dhe / ose shërbimeve të përjashtuara nga zbatimi (përjashtimet funksionale) të sistemit të monitorimit tatimor të tatimpaguesve në nënsistemin TP

- Identifikimin e njësive organizative të përfshira në monitorimin e zbatimit të sistemit të monitorimit tatimor të tatimpaguesve në nënsistemin TP

- identifikimin e mënyrave të kontrollit të zbatimit bazuar në informacione të ndryshme: paralajmërime nga qytetaret, qendra e thirrjeve, rezultati i BI, informacione nga njësia tjetër e AT, kërkesa nga organet e tjera shtetërore, etj.

- përshkrimin e proceseve të punës sipas treguesve të përbashkët - përshkrimin e proceseve të punës që ndryshojnë në krahasim me të dhënat e regjistruara - përshkrimin e procedurave minimale administrative që duhet të zbatohen në lidhje me legjislacionin kombëtar (dispozitat e përgjithshme procedurale që zbatohen nga Administrata tatimore) - përshkrimin se si do të regjistrohen rezultatet e aktiviteteve të monitorimit tatimor - identifikimin e kritereve për efikasitetin e monitorimit tatimor - përshkrimin e mënyrës dhe kohës së raportimit - identifikimin e procesit të përpunimit statistikor të rezultateve të monitorimit tatimor në bazë të kritereve të ndryshme.

Pas zbatimit (futjes) së eFaturës, është e nevojshme të hartohet metodologjia:

Metodologjia e monitorimit tatimor eFatura të organeve administrative të Republikës së Shqipërisë

Metodologjia e monitorimit tatimor e-Fatura të tatimpaguesve në sistemin TJP

Pas zbatimit të fazës së fundit të projektit, evidentimi dhe monitorimi i pagesave në sistemin TJP dhe

pasi të gjitha institucionet të jenë të përfshira në proces, si nga aspekti ligjor ashtu edhe organizativ,

procedura e monitorimit tatimor duhet të përfshijë:

o Identifikimin e nevojës për të përshtatur procedurat për organet e monitorimit tatimor

o modifikimin, sipas nevojës, të metodologjisë për monitorimin e tatimpaguesve në nënsistemin

e TJP.

5.5.2.6 Miratimi i monitorimit të ri të tatimit dhe ndjekja e procedurave

Pas diskutimeve dhe analizave brenda AT mbi propozimin e ri të Metodologjisë dhe udhëzimeve,

Ofertuesi do të:

shqyrtojë dhe analizojë të gjitha komentet dhe sugjerimet e pranuara.

përgatitjen e përgjigjeve dhe sqarimeve

Faqe 34 nga 140

nëse është e nevojshme, të modifikojë dhe / ose plotësojë metodologjitë dhe udhëzimet para

miratimit të tyre përfundimtar.

5.5.2.7 Trajnimi i zyrtareve të Departamentit për mbikëqyrje tatimore

Pas miratimit të metodologjisë dhe udhëzimeve për mbikëqyrjen e taksave, Ofertuesi do të:

Përgatitni të gjithë materialin për personelin (prezantime, udhëzime, broshura, etj.).

Aktiv për të marrë pjesë

5.5.3 SISTEMI I MENAXHIMIT TË SIGURISË SË INFORMACIONIT - (ISMS)

Menaxhimi i sigurisë së informacionit kryesor të biznesit është i nevojshëm për të kryer të gjitha proceset

e punës në këtë projekt.

Me një numër mekanizmash kontrolli dhe të strukturës së përcaktuar të përgjegjësisë dhe procedurave,

Ofertuesi duhet të sigurojë që siguria e informacionit të jetë pjesë përbërëse e të gjitha proceseve,

operacioneve dhe menaxhimit të proceseve të punës.

Përcaktimi i politikes së sistemit të menaxhimit të sigurisë së informacionit dhe fushës së detajuar të

zbatimit duhet të përcaktohet në dokumentin Sistemi i Menaxhimit të Sigurisë së Informacionit (tutje

ISMS – Information Security Management System), i cili përfshin të gjitha aktivitetet profesionale dhe

administrative.

5.5.3.1 Politika e ISMS

Siguria e informacionit është një nga faktorët më të rëndësishëm që ndikojnë në cilësinë dhe

transparencën e punës dhe përmes zbatimit të Sistemit të Menaxhimit të Sigurisë së Informacionit

synohet të sigurohet tërësia dhe integriteti i të gjithë informacionit në dispozicion dhe menaxhimi pa

pengesa të të gjitha proceseve.

I. PARIMET DHE QËLLIMET E ISMS

Ofertuesi duhet të respektojë parimet e mëposhtme:

Sigurimi i mbrojtjes së aseteve të informacionit nga të gjitha rreziqet - si të brendshme ashtu

edhe të jashtme, si me dashje dhe aksidentale

përmes menaxhimit të riskut, reduktojnë vazhdimisht rreziqet në fushën e sigurisë së

informacionit dhe marrin masat e kontrollit

të sigurojë harmonizimin me rregullat ligjore dhe kërkesat e tjera në fushën e sigurisë së

informacionit

të sigurojë konfidencialitetin e të dhënave të ndjeshme në përputhje me rregullat ligjore dhe

praktikat e mira të biznesit

të sigurojë disponueshmërinë e informacionit kur kërkohet nga palët e interesuara në përputhje

me Ligjin për të drejtën e ofrimit të informacionit

të sigurojë vazhdimësinë e aktiviteteve kur shfaqen ngjarje të padëshiruara në përputhje me

planin e qëndrueshëm të biznesit

trajnimin e vazhdueshëm të punonjësve në lidhje me rregullat e zbatimit të sigurisë së

informacionit

të gjitha incidentet që lidhen me sigurinë e informacionit do të raportohen tek personat përgjegjës

dhe do të ndërmerren veprime të përshtatshme korrigjuese

Faqe 35 nga 140

Objektivat e sigurisë së informacionit në fushën e veprimit të ISMS janë:

1) përcaktimi dhe menaxhimi i rreziqeve të sigurisë së informacionit në një nivel të pranueshëm,

2) menaxhimi efektiv i sigurisë së informacionit,

3) krijimi dhe mirëmbajtja e një sistemi efikas të kompetencave dhe përgjegjësisë për sigurinë e

informacionit,

4) përmbushja e detyrimeve të kontratës, ligjore dhe rregullatore të sigurisë.

Të gjithë punonjësit dhe personat e tretë juridikë ose fizikë të përfshirë në proceset e biznesit duhet të

sillen në përputhje me politikën e ISMS-së, të gjitha politikat dhe procedurat, masat teknike dhe

organizative të sigurisë dhe të gjitha kërkesat e biznesit, ligjore dhe rregullative që identifikohen në

fushën e veprimit të ISMS-s.

Punonjësit dhe palët e treta të përfshirë në çfarëdo mënyre në proceset e punës janë të detyruar të

njihen vazhdimisht me të gjitha politikat dhe procedurat e sigurisë që zbatohen. Në këtë mënyrë, ata

marrin përgjegjësinë për sigurinë e informacionit, dhe në rast të shkeljeve të politikave dhe procedurave

të sigurisë, përgjigjen në përputhje me detyrimet e kontratës dhe aktet e brendshme.

Kontrolli i rregullt i zbatimit të politikës së sistemit të menaxhimit të sigurisë së informacionit do të kryhet

përmes aktiviteteve të brendshme të ISMS-së si dhe kontrollit të efikasitetit të kontrolleve të zbatuara

të sigurisë.

II. STRUKTURA E PËRGJEGJËSISË PËR SIGURINË E INFORMACIONIT

Autoriteti kontraktor do të sigurojë:

Vendosjen dhe respektimin e politikës së ISMS-së dhe objektivave të sigurisë në fushën e ISMS-

së gjatë kohëzgjatjes së projektit,

Përcaktimi i qëllimit të ISMS,

Sigurimi që punonjësit e AT të punojnë së bashku për të siguruar zbatimin efikas të masave të

sigurisë së informacionit në të gjitha fushat brenda ISMS-së

Ofertuesi, në kuadër të përmirësimit të sistemit, do të kryejë:

o Identifikimin e fushave për harmonizim (sfidat e brendshme dhe sfidat ndaj organeve

rregullatore

o Krijimin e regjistrit të shërbimeve të TI-së dhe përpunimi që përfshin të dhënat

personale

o Analizën e procesit, të drejtat dhe detyrimet

o Analiza e procesit të krijimit, menaxhimit dhe rrjedhjes së të dhënave në organizatë,

struktura e të dhënave për qëllime të klasifikimit të të dhënave.

o Analiza e harmonizimit të akteve ligjore të Autoritetit kontraktor

o Analiza e proceseve të menaxhimit të rreziqeve të sigurisë së informacionit

o Analiza e aspekteve të sigurisë në procesin e zhvillimit të sistemit

o Menaxhimi i kontrollit të hyrjeve, menaxhimi i ciklit të kohëzgjatjes së identitetit, Backup,

monitorimi i logeve te aksesit, analiza e cenueshmërisë teknike, siguria e rrjetit, etj.

o Analiza e procesit të menaxhimit të ngjarjeve dhe incidenteve të sigurisë

o Analiza e mekanizmave ekzistues për mbrojtjen e të dhënave

o Analiza e mbrojtjes së të dhënave personale të punonjësve dhe kontrolleve të tyre të

sigurisë

o Analiza e aspektit të sigurisë me furnizuesit

o Analiza e aspekteve fizike të sigurisë në zonat e sigurisë

Faqe 36 nga 140

o Zhvillimi i rekomandimeve për përafrimin me Rregulloren e Përgjithshme të Mbrojtjes

së të Dhënave (RrPMD, e njohur si GDPR)

o Përcaktimi i prioriteteve dhe aktiviteteve konkrete me qëllim të harmonizimit adekuat

dhe në kohë me GDPR, mbledhjes së informacionit dhe dokumentacionit të rishikuar,

së bashku me personat përgjegjës të Autoritetit kontraktor

o Përveç aspektit të teknologjisë, të analizohen edhe ndryshimet organizative ose

proceset që mund të adresojnë boshllëkun e gjetur.

o Analizat duhet të kryhen sipas parimit “vendor neutral”, duke pasur parasysh specifikat

e tregut lokal dhe rrethanat, veçoritë dhe gjendjen në organizatën e Autoritetit

kontraktor. Aspektet e burimeve gjithashtu do të merren parasysh gjatë zbatimit të një

zgjidhjeje të caktuar, gjithnjë duke vlerësuar kapacitetin aktual njerëzor dhe financiar të

Autoritetit kontraktor dhe duke marrë parasysh afatin kohor në të cilin duhet të zbatohet

zgjidhja.

o Hartimi i rekomandimeve për riorganizimin e proceseve dhe procedurave ekzistuese të

Mministrisë së Financave dhe Ekonomisë dhe Administratës Tatimore

o Hartimi i rekomandimeve për zbatimin e masave të duhura organizative dhe ligjore

(proceset dhe procedurat) si dhe masave teknologjike (zgjidhjet e sigurisë dhe mjetet

tjera) për harmonizimin e sistemeve me kërkesat e Rregulloreve GDPR, si zhvillimin e

Politikave për menaxhimin e të dhënave personale dhe zhvillimin e strukturës

organizative për mbrojtjen e të dhënave personale, harmonizimin ligjor të mënyrave

ekzistuese të grumbullimit dhe përpunimit të të dhënave personale me rregulloren

GDPR dhe ndryshimin e proceseve sipas nevojës, harmonizimin ligjor në marrëdhëniet

me palët e treta, , krijimin e regjistrit të pëlqimeve/ bazës ligjore / bazës së kontratës

për përpunim në nivel të të dhënave individuale personale dhe harmonizimin e

shërbimeve të TI-së që nuk i plotësojnë kërkesat funksionale.

o Analiza e ndikimit në mbrojtjen e të dhënave personale nga shërbimi dhe përpunimi i

të dhënave; Analiza duhet të përfshijë aktivitetet e identifikuara të përpunimit,

vlerësimin e riskut të të drejtave dhe lirive të subjekteve, matjen e identifikimit të riskut

si dhe masat dhe mekanizmat e sigurisë.

III. VLERËSIMI DHE MENAXHIMI I RREZIKUT TË SIGURISË SË INFORMACIONIT

Vlerësimi i rreziqeve të sigurisë së informacionit kryhet në përputhje me metodologjinë e përshkruar në

Metodologjinë e vlerësimit të rrezikut të sigurisë së Informacionit.

Kriteri i rrezikut të pranueshëm përcaktohet nga Metodologjia e vlerësimit të rrezikut të sigurisë së

informacionit.

Në bazë të rezultateve të vlerësimit të rreziqeve, duhet të përcaktohet një Plan për trajtimin e rreziqeve,

i cili do të identifikojë të gjitha aktivitetet dhe përgjegjësitë për menaxhimin e rreziqeve të papranueshme

të sigurisë së informacionit.

Me miratimin e Planit për trajtimin e rreziqeve, Drejtoria e DPT-së jep autorizimin për zbatim të

kontrolleve të përzgjedhura të sigurisë dhe implementimin e ISMS-së.

IV. RUAJTJA, VERIFIKIMI DHE PLOTËSIMI I DOKUMENTEVE TË ISMS DHE DOKUMENTEVE

TË SIGURISË SË INFORMACIONIT

Për verifikimin dhe plotësimin e politikës për ISMS-në dhe të gjitha dokumenteve që përcaktojnë

politikat, procedurat dhe hapat brenda fushëveprimit të ISMS-së, duhet të jetë përgjegjës Drejtuesi i

sigurisë së informacionit të Ofertuesit, i cili do të shqyrtojë dokumentet sipas nevojës gjatë kohëzgjatjes

së këtij projekti.

Faqe 37 nga 140

Menaxheri i sigurisë së informacionit duhet të kujdesët për disponueshmërinë e të gjitha dokumenteve

dhe të sigurojë që politikat e sigurisë, të gjitha standardet, udhëzimet, planet operacionale dhe

procedurat që lidhen me sistemin e menaxhimit të sigurisë së informacionit janë të kuptueshme për të

gjithë punonjësit dhe palët e treta.

Çdo mosrespektim i dispozitave të kësaj politike, ligjeve, akteve të përgjithshme dhe të gjitha

dokumenteve që rregullojnë politikat, përgjegjësitë, procedurat dhe hapat në sistemin e menaxhimit të

sigurisë së informacionit duhet të sanksionohen në përputhje me rregullat ligjore dhe aktet e

brendshme.

5.5.3.2 Analiza e pajtueshmërisë (analiza e pajtueshmërisë dhe rekomandimet) (GDPR)

Objektivat kryesore:

a) rritja e vetëdijes për rëndësinë e Rregullores së Përgjithshme të Mbrojtjes së të Dhënave

(GDPR),

b) vlerësimi i konformitetit ( assessment) me kërkesat e rregullores së GDPR dhe identifikimin e

pikave jokonforme

c) rekomandimet e masave të nivelit të lartë për të arritur pajtueshmërinë me Rregullorën GDPR.

Aktivitetet e Ofertuesit duhet të përfshijnë:

o Njohja me kërkesat që sjell Rregullorja e Përgjithshme për Mbrojtjen e të Dhënave (GDPR)

Trajnimi i punonjësve të AT në lidhje me ndikimin e këtyre kërkesave në proceset e punës

o Trajnimi i zyrtareve të AT mbi rrjedhën e të dhënave personale në organizatë dhe jashtë

organizatës

o Përgatitja e materialeve për personelin

o Organizimi i workshop-eve me personat përgjegjës për menaxhimin e marrëdhënieve

kontraktore me përdoruesit dhe furnizuesit (p.sh. / propozim: përfaqësues të sektorit për

financa, shërbimeve ligjore dhe menaxhimit të burimeve njerëzore). Qëllimi i seminarit është

të prezantojë ndikimin e GDPR në dokumentet ligjore / kontratat dhe të ofrojë udhëzime për

modifikimin e kontratës për të identifikuar rreziqet e mundshme dhe harmonizimin me GDPR

o Hartimi i udhëzimeve për ndryshimin e kontratave të furnizuesve dhe përdoruesve, me qëllim

që të arrihet harmonizimi me GDPR

o Analiza e harmonizimit të nivelit të lartë me GDPR

o përcaktimin e nivelit të harmonizimit me GDPR

o identifikimi i rreziqeve më të rëndësishme, vlerësimi i pjekurisë së proceseve

ekzistuese për menaxhimin e të dhënave personale

Rishikimi i politikave dhe procedurave ekzistuese në lidhje me mbrojtjen dhe menaxhimin

e të dhënave personale në DPT, me qëllim të përcaktimit të mangësive në kuadër të

kërkesave të GDPR

o Regjistrimet e aktiviteteve të përpunimit

o Organizimi i workshopeve me përfaqësuesit kryesor, me qëllim të kuptimit të situatës aktuale

në nivelin më të lartë, identifikimi i fushave kryesore të mospërputhjes dhe rreziqeve më të

rëndësishme

o Hartimi i Raportit të kryerjes së analizës së harmonizimit me GDPR në nivelin më të lartë me

elementët e mëposhtëm:

o Lista e mospërputhjeve të identifikuara në lidhje me kërkesat e GDPR dhe rreziqet që

lidhen me të

o Rekomandimet e harmonizimit (në nivel të lartë)

o Propozimi i planit të aktiviteteve dhe zbatimi i rekomandimeve

Faqe 38 nga 140

5.5.3.3 Sistemi i menaxhimit të vazhdueshmërisë së punës (SMVP)

Puna e Administratës Tatimore varet kryesisht nga sistemet e bazuara në teknologjinë e informacionit

dhe komunikimit. Çdo ndërprerje e procesit të punës shkakton pasoja të drejtpërdrejta operative për

Administratën Tatimore dhe rrjedhimisht edhe për buxhetin e Republikës së Shqipërisë.

Qëllimi i SMVP është që t'i sigurojë AT-së mundësi për t'iu përgjigjur në mënyrë efektive ndaj

kërcënimeve të tilla si fatkeqësitë natyrore ose humbja e të dhënave, dhe të mbrojë të gjitha sistemet e

Administratës Tatimore. SMVP duhet të bazohet standardet ndërkombëtare ISO për vazhdimësinë e

punës.

Rezultat i projektit duhet të jetë:

të përcaktojë kuadrin për identifikimin e rrezikut të ekspozimit të Administratës Tatimore ndaj

kërcënimeve të brendshme dhe të jashtme.

të kuptojë nevojat e vazhdueshmërisë dhe gatishmërisë së punës, si dhe të nevojës për krijimin

e një plani për menaxhimin e vazhdueshmërisë së punës në kuadër të qëllimeve të Administratës

Tatimore.

Vendosja e kontrollit për zbatim dhe funksionim duke përfshirë edhe masat për menaxhimin në

vazhdimësi të rreziqeve në kuadër të Administratës Tatimore

Monitorimi dhe rishikimi i performancës dhe efektivitetit të sistemit të menaxhimit të

vazhdueshmërisë së punës në Administratën Tatimore

Përmirësim i vazhdueshëm i sistemit duke u bazuar në matje objektive.

Sistemi i menaxhimit të vazhdueshmërisë së punës, si pjesë e këtij projekti, duhet të përfshijë:

a. rimëkëmbjen nga dështimet,

b. rimëkëmbja e punës,

c. menaxhimin e krizave,

d. menaxhimin e incidenteve,

e. menaxhimin e emergjencave dhe

f. planifikimin e emergjencave.

Projekti duhet të ofrojë:

o Përcaktimi i politikës për vazhdueshmëri të punës

o Vlerësimi i rrezikut

o Pyetësorët e vlerësimit të rrezikut

o Tabela e rrezikut

o Analiza e Impaktit të Biznesit, BIA

o Pyetësorët e Analizës së Impaktit të Biznesit

o Raporti i Analizës së Impaktit të Biznesit

o Katalogu i burimeve kritike

o Hartimi i strategjisë së menaxhimit të vazhdueshmërisë së punës

o Strategjia e vazhdueshmërisë së punës

o Hartimi dhe dokumentimi i planeve të vazhdueshmërisë së punës

o Plani kryesor

o Plani i vlerësimit të dëmeve

o Plani i mbrojtjes së të dhënave kritike

o Plani i PR

o Funksionet kritike të punës / proceset dhe planet e rimëkëmbjes

o Planet e testimit

Faqe 39 nga 140

o Skenarët për testim të planeve të vazhdueshmërisë së punës

o Raporti i testimit

o Trajnimi

o Materialet për trajnim

5.5.4 TREGUESIT KRYESORE TË PERFORMANCËS

Treguesit kryesor të performancës të sistemit duhet të jenë të matshëm dhe të sigurojnë informacion

nëse sistemi funksionon mirë, nëse janë të nevojshme përshtatje të caktuara për një zbatim më të lehtë

dhe nëse janë përmbushur qëllimet kryesore për të cilat është zbatuar ky sistem.

Për çdo element të sistemit të permiresuar do të ketë tregues të ndryshëm kryesor të performancës

(TKP):

TKP për nënsistemin TP

TKP për eFatura

TKP për monitorimin e pagesave në nënsistemin e TJP

TKP për kontrollin e tatimeve të nënsistemit

TKP për strukturën organizative të nënsistemit.

5.5.4.1 TKP-të për nënsistemin TP, në veçanti, janë:

Ulja e hendekut të TVSH-së

Reduktimi i diferencës midis dërgesave të raportuara (për llogaritjen e TVSH-së) dhe qarkullimit

të regjistruar përmes sistemit

Reduktimi i diferencës në qarkullimin e raportuar nëpërmjet sistemit për tatimpaguesit e

ngjashëm të cilët kryejnë të njëjtin lloj të aktivitetit në të njëjtin vend ose në një vend tjetër të

ngjashëm

Rritje e të ardhurave të deklaruara nga tatimpaguesit për llogaritjen e tatimit mbi të ardhurat /

tatimin në fitim në krahasim me situatën para futjes së sistemit

Reduktimi i gabimeve (të qëllimshme ose rastësishme) gjatë lëshimit të faturës (për shembull,

elemente të pasakta të faturës, mungesa e elementeve të faturës, përllogaritje e gabuar e

TVSH-së, etj.)

Rritja e numrit të faturave të lëshuara dhe të evidentuara nëpërmjet nënsistemit TP

Reduktim i kundërvajtjeve të përsëritura nga tatimpaguesit, monitorimi i të cilëve është kryer

disa herë

Rritja e numrit të tatimpaguesve të monitoruar nga inspektorët tatimor në një kohë më të

shkurtër (duke përcjellë të dhënat online në zyrë në kohë reale, jo vetëm në terren)

Së fundi, reduktim i numrit të tatimpaguesve të regjistruar në grupin më kritik të tatimpaguesve

sipas kritereve të përcaktuara (p.sh. numri i faturave të anuluara, diferenca midis numrit të

faturave të lëshuara dhe qarkullimit të regjistruar në raport me mesataren etj.)

Rritje e pagesës së TVSH-së, tatimit mbi të ardhurat dhe tatimit mbi fitimin, së bashku me

kushtet e tjera të pandryshuara

Rritje e numrit të ankesave të qytetarëve për mos lëshim të faturave ose faturave të lëshuara

gabimisht

Rritje e numrit të kontrolleve për verifikim të faturave nga blerësit përmes numrit të veçantë në

faturë

5.5.4.2 TKP-të për Nënsistemin TJP, në veçanti, janë:

Reduktimi i diferencave në dërgesat e raportuara (për llogaritjen e TVSH-së) dhe evidentimi i

qarkullimit përmes nënsistemit TJP

Faqe 40 nga 140

Reduktimi i diferencës në qarkullimin e raportuar për tatimpaguesit e ngjashëm që kryejnë të

njëjtin lloj të aktivitetit në të njëjtin vend ose në një lokacion shumë të ngjashëm

Rritja e të ardhurave të deklaruara të tatimpaguesve për llogaritjen e tatimit mbi të ardhurat /

tatimin mbi fitimin në krahasim me situatën para futjes së nënsistemit

Reduktimi i gabimeve (të qëllimshme ose rastësishme) gjatë lëshimit të faturave, siç janë

elemente të pasakta të faturës, mungesa e elementeve të faturës, përllogaritje e gabuar e

TVSH-së, etj.)

Reduktim i kundërvajtjeve të përsëritura nga tatimpaguesit, monitorimi i të cilëve është kryer

disa herë

Rritja e numrit të tatimpaguesve të monitoruar nga inspektorët tatimor në një kohë më të

shkurtër (duke përcjellë të dhënat online në zyrë në kohë reale, jo vetëm në terren)

Së fundi, reduktim i numrit të tatimpaguesve të regjistruar në grupin më të prekshëm të

tatimpaguesve sipas kritereve të përcaktuara (p.sh. numri i faturave të anuluara, diferenca

midis numrit të faturave të lëshuara dhe qarkullimit të regjistruar në raport me mesataren etj.)

Rritje e pagesës së TVSH-së, tatimit mbi të ardhura dhe tatimit në fitim, së bashku me kushtet

e tjera të pandryshuara

Reduktimi i mashtrimit me TVSH (për shembull, kur blerësi kërkon rimbursimin e TVSH-së

bazuar në rimbursimet e TVSH-së të paguara nga një blerës tek një furnizues i cili nuk është

regjistruar si tatimpagues dhe nuk kryen pagesën e TVSH-së në buxhetin e shtetit)

Zvogëlimi i mashtrimit në të cilin blerësi dhe furnizuesi me vetëdije dhe qëllimisht marrin pjesë

përmes angazhimeve jo autentike, përkatësisht me fatura fiktive (për shembull, kur furnizuesi

nuk është në sistemin e TVSH-së dhe kur blerësi nuk ka paguar TVSH-në por e ka paraqitur

atë tek DPT-ja sikur të jetë paguar)

Ulja e hendekut të TVSH-së.

5.5.4.3 TKP-të për e-Fatura në veçanti janë:

Më shpejtë dhe më e sigurtë dërgimi i eFatura

Kosto më të ulëta të pagesës

Kostot administrative më të ulëta të përpunimit

Përfitimet ekologjike të eFaturës, reduktim i përdorimit të letrës (shpenzime më të ulëta të

materialeve të zyrës)

Zvogëlim kohe midis faturimit dhe pagesës

Reduktimi i gabimeve në fatura (numri i tatimpaguesit i pasaktë, faturat pa të gjitha elementet

e përshkruara, llogaritja e pasaktë e TVSH-së, etj.)

Rritje e efikasitetit në proceset administrative (cilësi dhe organizim më i mirë i kontabilitetit - më

pak gabime të paqëllimshme në procesin e auditimit)

reduktim i numrit të “faturave fiktive, përkatësisht të faturave të cilat për nga përmbajtja

paraqesin biznes fiktiv të ligjshëm

Kontroll më i mirë i transaksioneve ndërmjet personave të lidhur - cilësi më e mirë e të dhënave

për të vlerësuar riskun e tatimit, që rezulton në kontrolle më të mira, më të fokusuara dhe më

efikase të tatimeve dhe shpenzime administrative më të ulëta, pasi që numri i monitorimeve

tatimore mbi tatimpaguesit të cilët nuk paraqesin risk (“tatimpaguesit e ndershëm”) reduktohet.

mundësi më e vogël e korrupsionit dhe ryshfetit në organet publike të lidhura me prokurimin

publik (të gjitha prokurimet publike do të jenë të dukshme dhe transparente).

5.5.4.4 TKP-të për ndjekjen e pagesave në nënsistemin e TJP-së janë, në veçanti:

reduktim i afateve të pagesës, vonesave të pagesave në transaksionet e biznesit

reduktimi i korrupsionit dhe ryshfetit (kontroll më i mirë i afateve të pagesës, ndërsa autoritetet

publike mund të ndërmarrin automatikisht veprimet e parashikuara nga direktiva për luftën

kundër vonesave në pagesa në transaksionet e biznesit pa ndërhyrje njerëzore

Faqe 41 nga 140

reduktimin e problemeve në marrëdhëniet tregtare midis sipërmarrësve

reduktimin e barrës administrative për shkak të përgatitjes dhe dorëzimit të raporteve për

pagesa të vonuara

reduktimi i shpenzimeve të huamarrjes për ndërmarrjet e vogla dhe të mesme, që mundëson

kushte më të drejta të tregut, përkatësisht pozitë më të mirë për negocim në lidhje me

tatimpaguesit e mëdhenj

funksionalitet më i mirë dhe efikasitet në treg si dhe një mjedis më i mirë biznesi

përmirësimi i sigurisë ligjore - klimë më e mirë për investime - më shumë investime të huaja

në planin afatgjatë – ndryshim i kulturës së të bërit biznes dhe ulje e pabarazisë në treg.

5.5.4.5 TKP-të për monitorimin e taksave të nënsistemit, në veçanti, janë:

Më shumë monitorime standarde tatimore të subjekteve në nënsistemet TP

Më shumë monitorime standarde tatimore në nënsistemin TP

Më shumë monitorime tatimore online të tatimpaguesve në nënsistemin TP

Reduktim i kohëzgjatjes mesatare të monitorimit tatimor të subjekteve afariste në nënsistemin

TP

Numri i parregullsive të identifikuara gjatë procesit të monitorimit tatimor të tatimpaguesve në

nënsistemin TP (si rezultat i monitorimit të shënjestruar tatimor) - rritja e përqindjes së

parregullsive të identifikuara në raport me numrin e përgjithshëm të tatimpaguesve në

Nënsistemin TP në monitorimin tatimor)

Reduktim i përqindjes së parregullsive të identifikuara në raport me numrin e përgjithshëm të

tatimpaguesve në nëngrupin TP (si rezultat i përmbushjes më të madhe vullnetare të

detyrimeve tatimore)

Në vitin e parë, rritja e numrit të përgjithshëm të ankesave të qytetarëve rreth faturave të

palëshuara ose të lëshuara gabimisht (qytetarët përfshihen më shumë në luftën kundër

mashtrimit tatimor dhe evazionit fiskal).

5.5.5 STRATEGJIA E PR

Ekziston nevoja për të zhvilluar një strategji PR sepse pranimi i disiplinës në aspektin e pagesës së

detyrimeve tatimore shkakton rezistencë nga grupe të ndryshme të interesit. Prandaj është e nevojshme

të zhvillohet një seri e marrëdhënieve me publikun dhe hapa të ndërgjegjësimit si në vijim:

T’u ofrojë tatimpaguesve informacion të saktë dhe në kohë

Të ofrojë informacionin të përditësuar

Të rrisë njohuritë dhe mirëkuptimin e tatimpaguesve duke komunikuar me grupe të synuara dhe

me informacion të përshtatur për të përmbushur nevojat e këtyre grupeve

Të vendos mënyra gjithëpërfshirëse dhe pro-aktive të komunikimit

Të ofrojë udhëzime pro aktive që të ndihmojë tatimpaguesit të parashikojnë detyrimet e tyre

tatimore dhe të zvogëlojnë gabimet

Të organizojë një fushatë së gjerë reklamuese

Të përdor gjerësisht mediat sociale etj.

PR duhet të jetë një proces strategjik komunikimi që do të ndërtojë marrëdhënie reciproke të dobishme

mes AT dhe tatimpaguesve

Ofertuesi do të ofrojë mbështetje dhe këshilla Administratës Tatimore, të tilla si:

o Të bind tatimpaguesit përmes metodave pa pagesë, qoftë përmes mediave, rrjeteve sociale

ose komunikimit me balle per balle për te mira e sistemit

Faqe 42 nga 140

o Të mbrojë, përmirësojë ose ndërtojë reputacionin e AT përmes mediave, rrjeteve sociale

o Të përmirësojë marrëdhëniet midis tatimpaguesve dhe AT, duke theksuar në shfaqjet publike

parimet e përgjithshme të mëposhtme, të cilat janë bazë për tatimin efikas

o ligjshmërinë dhe sigurinë ligjore

o mos diskriminimi dhe barazia e tatimpaguesve

o respektimi i ligjit

o paanshmëri dhe pavarësi

o ruajtjen e sekretit tatimor dhe mbrojtjen e të dhënave

o privatësinë

o Të jetë pro aktiv në identifikimin e nevojës për informata të përgjithshme tatimore dhe

parandalimin e problemeve të mundshme që mund të pengojnë tatimpaguesit në përmbushjen

e detyrimeve tatimore.

o Të shpërndajë njoftime për shtyp për permiresimet ne sistem

o Të organizojë evente të veçanta me qëllim të krijimit të kontaktit me publikun dhe përmirësimin

e marrëdhënieve me mediat në lidhje me permiresimet e sistemit.

o Të jepen njoftime nëpër faqe web për ndryshimet dhe mënyrën e funksionimit të sistemit

o Të përcaktojë strategjinë e menaxhimit të krizave në marrëdhëniet me publikun në lidhje me

futjen e sistemit.

o Të shkruajë lajme të personalizuara për rrjetet sociale, të cilat duhet të jenë të lehta për t’u

kuptuar dhe të shkurtra, si dhe të promovoje sistemin e perditesuar në mënyra specifike për

çdo rrjet social ku lajmet duhet të jenë të dukshme:

o Twitter

o Instagram

o Facebook

o Kanali i YouTube

o Të bëjë komunikimin relevant dhe efikase me tatimpaguesit duke përdorur PR dixhital, i cili

përbëhet nga elementët e mëposhtëm:

o hulumtim,

o identifikimi i personave nga influenca,

o zhvillimin dhe shpërndarjen e përmbajtjes

Një kuptim më i mirë i sjelljes së tatimpaguesve që përmbushin detyrimet e tyre tatimore dhe atyre që

nuk përmbushin, mund të ndihmojë DPT-në që të zbatojë një praktik që rrit përmbushjen e detyrimeve

tatimore në baza vullnetare, si dhe për të përmirësuar efikasitetin e AT në reduktimin e mos

përmbushjes së detyrimeve tatimore. Ofertuesi do të ndihmojë AT në analizimin e të dhënave në

dispozicion të aktiviteteve të AT në të kaluarën, me qëllimin kryesor për të përmirësuar përmbushjen

vullnetare të detyrimeve tatimore.

Meqenëse është shumë e rëndësishme që për të përmirësuar moralin për tatim duhet të ketë dhe të

përdoret një stimul i menduar mirë i kombinuar me anët negative dhe pozitive për tatimpaguesit dhe

qytetarët (dhe subjektet e tjera të synuara). Ofertuesi do të ndihmojë DPT-në në hartimin dhe zhvillimin

e stimuleve pozitive që do të përshtaten më së miri në arritjen e qëllimeve kryesore. Stimulimet duhet

të marrin parasysh:

Lloji i shpërblimit

Efekti në krahasim me shumën e të ardhurave

Zbulimi i një tatimpaguesi "të mirë"

Madhësia e shpërblimeve dhe efekti i kostos mbi tatimpaguesit

Sjellje strategjike

Efektet e kohës

Qytetarët vs biznesit.

Faqe 43 nga 140

5.6 Softueri

5.6.1 ZHVILLIMI, EVIDENTIMI DHE MONITORIMI I TRANSAKSIONEVE ME PARA NE DORE

Evidentimi dhe monitorimi i transaksioneve në para në dorë përfshijnë të dhënat dhe monitorimin nga

AT e Republikës së Shqipërisë të të gjitha transaksioneve të pagesës së faturës me para ne dore. Në

këtë drejtim, qëllimi i zbatimit të këtij nënsistemi është që t’i sigurojë AT monitorimin në kohë reale të

transaksioneve me para ne dore.

Transaksionet në para në dorë përfshijnë pagesat e mallrave dhe shërbimeve në para cash, çeqe, karta

debiti dhe krediti për të cilat është lëshuar një faturë për pagesën. Çdo transaksion në para në dorë

duhet të regjistrohet në DPT në kohë reale. Gjatë procesit të regjistrimit të një transaksioni të vetëm në

para ne dore, AT-ja do të ndajë një numër identifikues për çdo transaksion në para në dorë i njohur si

Identifikuesi i veçantë i transaksionit në para në dorë si një shenjë identifikimi e qartë dhe e

papërsëritshme.

Para lëshimit të faturës, të gjithë tatimpaguesit në sistemin TP janë të detyruar të kërkojnë dhe instalojnë

një certifikatë të nënshkrimit elektronik në sistemet e tyre përpara se të lëshojnë një fature me para në

dorë.Certifikata elektronike sigurohet nga Agjencia Kombetare e Shoqerise se Informacionit, e cila

eshte i vetmi institucion qendror shtetëror që gjeneron certifikata elektronike. Certifikimi elektronik do

të ofrojë hyrje në nënsistemin TP të AT të Republikës së Shqipërisë në bazë të së cilit tatimpaguesi

identifikohet si përdorues i vlefshëm (i vërtetë) i nënsistemit TP. Gjithashtu, certifikata elektronike

shërben për nënshkrimin elektronik të një fature të vetme në nënsistemin TP dhe garanton kredibilitetin

e çdo transaksioni individual.

Pasi tatimpaguesi të ketë marrë certifikatën elektronike, ai duhet ta instalojë atë në një ose më shumë

pajisje fiskale (kasa). Çdo pajisje e fiskale duhet të ketë ID e vet të veçantë që gjenerohet në kartën

RTP të tatimpaguesit - Dega e Tatimpaguesit.

Pas instalimit të certifikatës elektronike, tatimpaguesi, pas gjenerimit të faturës për pagesë në para të

në dorë, dërgon faturën në AT në kohë reale në formatin XML / PDF, duke e pershtatur me sistemin

aktual të nënshkrimit elektronik.

Pas pranimit të kërkesës (porosisë) nga tatimpaguesi, DPT është e detyruar të verifikojë origjinalitetin

e nënshkrimit elektronik, korrektësinë e strukturës XML / PDF, si dhe të kryejë verifikime shtesë të

kërkesës së pranuar (mesazhit) në kohë reale. Pas verifikimit të korrektësisë së faturës, DPT-ja ruan

faturën e pranuar në bazën e transaksioneve me para ne dore, ruan porosinë në tërësi në formatin XML

/ PDF në bazën e të dhënave, ndërsa në kohë reale nënsistemi gjeneron numrin e veçantë të

identifikuesit të transaksionit me para cash. Pas gjenerimit të identifikuesit të veçantë të transaksionit

me para cash, DPT-ja nënshkruan në mënyrë elektronike përgjigjen ndaj kërkesës së lëshuesit të

faturës dhe e dërgon në pajisjen e faturimit të tatimpaguesit nga i cili ka ardhur kërkesa (fatura).

Pasi sistemi i faturimit të tatimpaguesit merr përgjigjen nga DPT-ja, ai verifikon përmbajtjen e përgjigjes

dhe nënshkrimin elektronik të AT. Nëse vlefshmëria kryhet me sukses, tatimpaguesi është i detyruar të

shtyp faturën me elementet e përshkruara të faturës (elementet e faturës do të përcaktohen me

rregullore) duke përfshirë edhe identifikuesit e vecante te transaksionit me para ne dore e pranuar nga

AT-ja. Detyrimi i tatimpaguesit është që elementet e përshkruara të faturës duke përfshirë identifikuesit

e vecante te transaksionit me para cash të jenë të shtypura në faturë për pagesë në para në dorë në

formë të dukshme. Fatura për pagesë me para në dorë duhet gjithashtu të përmbajë një kod QR me të

gjitha elementet e faturës. Pas shtypjes së faturës për pagesë në para të gatshme, tatimpaguesi është

i detyruar që faturën t’ia japë menjëherë blerësit të mallrave ose shërbimeve.

Faqe 44 nga 140

Lëshuesi i faturës

në para të

gatshme

Krijimi i faturës në

para të gatshme

Hapi 1.

Dërgimi i faturës në

para të gatshme në

AT

Hapi 2.

Gjenerimi i kodit

dhe dërgimi i

përgjigjës

Hapi 3.

Hapi 6.

Hapi 5.

Blerësi

Hapi 7.

Shtypja e faturës

Evidentimi dhe

kontrollimi i

transaksionit në

para të gatshme

nga AT

Hapi 4.

Figura 4: Skema e procesit logjik në Nënsistemin TP

Të dhënat e AT të mbledhura nga nënsistemi TP do të përdorën për:

a) Analizën TP,

b) Analizën e tatimeve të mbledhura

c) Përcaktimin e planit të monitorimit të tatimpaguesve në nënsistemin TP

d) Identifikimin e tatimpaguesve kritik

e) Parandalimin e evazionit fiskal

Ky nënsistem duhet të zbatohet në nënsistemin e Integrimit të përshkruar në arkitekturën teknike.

Specifikimi i kërkesave funksionale

o Çdo tatimpagues i nënsistemit TP duhet të marrë një certifikatë për lëshimin e faturave nga AT-

ja ose organi kompetent, përmes rrugëve elektronike të kanaleve ekzistuese të komunikimit

elektronik me AT-në ose në kohën e regjistrimit (për të rinjtë)

o Nënsistemi i regjistrimit të pagesave me para në dorë duhet të mbështesë formatin XML / PDF

si një format shkëmbimi i të dhënave midis tatimpaguesve dhe AT

o Tatimpaguesi në nënsistemin TP do të gjenerojë një skedar elektronik në formatin XML / PDF

që përmban të gjitha të dhënat e kërkuara për faturën.

o Tatimpaguesi në nënsistemin TP do të nënshkruajë në mënyrë elektronike skedarin e

gjeneruar, bazuar në certifikatën elektroike, me qëllim që të sigurojë vërtetimin dhe autorizimin

e mesazhit

o Skedari do të dërgohet (nëpërmjet lidhjes në internet) tek AT-ja në bazën qendrore të AT

o Transferim (dërgimi) i mesazhit të nënshkruar do të jetë një “kërkesë për regjistrimin dhe

miratim” për lëshimin e një fature për pagesë me para në dorë

o DPT do të veprojë ndaj kërkesës për miratim.

Procesi i autorizimit nënkupton kontrollet e mëposhtme:

o Verifikimi i autorizimit duhet të jetë i automatizuar plotësisht (pa ndërhyrje njerëzore)

o Kontrollimi i skedarëve XML / PDF – harmonizimi i skemës, saktësia, tërësia

o Verifikimi i nënshkrimit elekronik të mesazhit

o Pas përfundimit të procesit të autorizimit, nënsistemi do të ruajë skedarin XML / PDF nëse

skedari XML / PDF është miratuar

o Nënsistemi do t’i kthejë tatimpaguesit një mesazh në nënsistemin TP (përgjigje ndaj kërkesës)

në lidhje me autorizimin që do të përfshijë:

Faqe 45 nga 140

o Identifikuesit e vecante te transaksionit me para cash - do të lejojë akses në faturën

elektronike përmes internetit. Çelësi për akses do të jetë një seri bitësh alfa-numerikë i

cili do të riprodhohet edhe si një kod QR.

o Mesazhi kthyes (përgjigja) do të nënshkruhet në mënyrë elektronike nga DPT-ja

o Autorizimi i mesazhit duhet të zgjasë më pak se një minutë. Tatimpaguesi në nënsistemin TP,

pas marrjes së përgjigjes, duhet të:

o Pranojë përgjigjen

o Shtyp të dhënat e përcaktuara me rregulla në faturë duke përfshirë identifikuesit e

vecante te transaksionit me para cash dhe të shtyp faturën në letër së bashku me kodin

QR dhe t’ia japë drejtpërdrejt blerësit.

o Blerësi duhet të jetë në gjendje të përdorë një QR reader nga telefoni mobile dhe menjëherë

përmes kodit QR, për të verifikuar vlefshmërinë e faturës së pranuar në telefonin e tij mobil.

Kontrollet TP pas kontrollimit të autorizimit të cilat nënsistemi TP duhet të sigurojë:

o Kontrollimi i datës dhe kohës së dërgimit të faturës (paralajmërimi për faturat për të cilat

koha e faturimit është më shumë ose më pak se 3 orë nga data dhe koha e pranimit të

faturës në nënsistemin TP).

o Kontrollimi i datës dhe kohës së lëshimit të faturës (paralajmërim për faturat për të cilat

koha e faturimit është më shumë ose më pak se 6 orë nga data dhe koha e pranimit të

faturës në nënsistemin TP).

o Kontrollimi i numrit të faturës (paralajmërim për faturat të cilat kanë numrin e faturës 0 ose

nëse ekzistojnë dy ose më shumë fatura me të njëjtin numër të faturës të lëshuara nga i

njëjti tatimpagues ose dega e tij)

o Kontrollimi i korrektësisë së normës tatimore (paralajmërim për faturat në të cilat është

deklaruar një shkallë jo ekzistuese e TVSH-së). Ky kontroll bëhet nëse tatimpaguesi është

në sistemin e TVSH-së.)

o Kontrollimi i bazës individuale për llogaritjen e TVSH-së sipas normave të ndryshme ose

me një normë zero në raport me shumën totale të faturës (paralajmërim për fatura e

lëshuara nga tatimpaguesi që është në sistemin e TVSH-së). Ky paralajmërim bëhet nëse

shuma e të gjitha bazave është e ndryshme nga totali i faturës).

o Kontrollimi i shumës së faturuar të TVSH-së (paralajmërim për fatura të cilat nënsistemi

TP ka vërtetuar një devijim të zbritjes së TVSH-së në raport me vlerën e deklaruar të

TVSH-së në faturë dhe se kjo shumë e devijimit tejkalon kufirin e poshtëm apo të sipërm

të rrumbullakimit). Ky kontroll bëhet nëse tatimpaguesi është në sistemin e TVSH-

së.Kontrollimi i shumës totale në faturë (paralajmërim për fatura të cilat nënsistemi TP ka

verifikuar një devijim në llogaritjen e shumës totale të faturës në raport me shumën e

sendeve të veçanta në faturë dhe se kjo shumë e devijimit tejkalon kufirin e poshtëm ose

të sipërm të rrumbullakimit). Ky kontroll bëhet nëse tatimpaguesi deklaron në faturë se ai

është në sistemin e TVSH-së.

o Nënsistemi TP duhet të mundësojë dhe të parametrojë kufijtë e rrumbullakimit.

5.6.2 PORTALI QENDROR PËR KONTROLLIN DHE MENAXHIMIN E TATIMPAGUESVE NË

NËNSISTEMIN E PAGESAVE ME PARA NË DORË (PQKM)

PQKM është një nënsistem kompleks i përcaktuar si një nënsistem i integrimit të të dhënave nga

nënsistemi i pagesave me para në dorë.

PQKM ka për qëllim:

1. Krijimin e një sistemi funksional dhe efikas për monitorimin e të dhënave kryesore nga nënsistemi

TP;

2. Krijimin e një sistemi për identifikimin e anomalive dhe trendëve nga nënsistemi TP;

Faqe 46 nga 140

3. Harmonizimin dhe standardizimin e të gjitha fazave të procesit të monitorimit të tatimpaguesve

në nënsistemin TP;

4. Krijimin e një sistemi të thjeshtë të raportimit të tatimpaguesve nga nënsistemi TP.

Nënsistemi PQKM duhet të ketë modulet e mëposhtme:

1. PQKM në funksion të monitorimit të trendëve dhe efekteve të sistemit të pagesave me para në

dorë

2. Analiza e tatimpaguesve në sistemin TP në mbulimin hapësinor;

3. Analiza e tatimpaguesve në sistemin TP;

4. Menaxhimi i anomalive në sistemin e pagesave me para në dorë.

Ky nënsistem duhet të ketë komponentët funksionalë si në vijim:

1) Komponenti PQKM - Funksioni i monitorimit të tendencave dhe efekteve të sistemit të pagesave

në para në dorë duhet të zbatohet në nënsistemin e Menaxhimit të përshkruar në arkitekturën

teknike;

2) Komponenti i PQKM - Analiza e tatimpaguesve në sistemin TP në mbulimin hapësinor duhet të

zbatohet në nënsistemin e Menaxhimit të përshkruar në arkitekturën teknike;

3) Komponenti PQKM - Analiza e tatimpaguesve në sistemin TP duhet të zbatohet në nënsistemin

Analitik dhe monitorues të përshkruar në arkitekturën teknike;

4) Komponenti PQKM - Menaxhimi i anomalive në sistemin e pagesave në para në dorë (duhet të

zbatohet në nënsistemin e Menaxhimit të përshkruar në arkitekturën teknike).

5.6.2.1 PQKM në funksion të monitorimit të trendëve dhe efekteve të sistemit të pagesave me

para në dorë

Duke pasur parasysh nevojën për të monitoruar trendët në nënsistemin TP dhe monitorimin e

tatimpaguesve në nënsistemin TP në kohë reale, është e nevojshme të sigurohet një pasqyrë

gjithëpërfshirëse e të dhënave krahasuese në kohë reale.

Ky modul i sistemit PQKM duhet të ofrojë një pasqyrë të thjeshtë të performancës së sistemit bazuar

në parametrat kryesor.

Statistikat e performancës së sistemit duhet të paraqiten si të dhëna agregate dhe analitike të ndara

horizontalisht:

a. sipas njësive organizative të AT

b. sipas kategorive të tatimpaguesve

c. sipas ndarjes administrativetë Republikës së Shqipërisë.

d. sipas aktiviteteve të tatimpaguesve

e. sipas detyrimeve tatimore

Pasqyra e të dhënave duhet të jetë e thjeshtë dhe e qartë. Paraqitja e të dhënave kryesore duhet të

përcaktohet përmes pamjeve tabelore dhe grafike.

Analiza e trendëve dhe efekteve në nënsistemin TP duhet të mbështetet nga sistemi DWH.

Kërkesat themelore funksionale të nevojshme për të siguruar janë si më poshtë:

o Ofertuesi duhet, në bashkëpunim me AT, të hartojë të gjitha TKP-të e nevojshme për

të përcaktuar funksionalitetin e këtij moduli PQKM. TKP-të e përmendura do të jenë

parakusht për ndërtimin e sistemit DWH dhe raportimit për këtë modul

o Paraqitja e parametrave kryesor të agreguar sipas njësive organizative të DPT-së

Faqe 47 nga 140

o Paraqitja e parametrave kryesor të agreguar sipas zyrave rajonale të DPT-ës

o Paraqitja grafike e parametrave kryesor të agreguar të nënsistemit TP krahasuar me

periudhën e mëparshme

o Paraqitje grafike e tendencave në nënsistemin TP

o Përmbledhja tabelore e të dhënave duhet të shfaqë analitiken e nënsistemit TP nga

njësitë AT sipas kriterit të numrit të përgjithshëm të faturave të lëshuara


njësitë AT sipas kriterit të shumës totale të faturave të lëshuara


njësitë e AT sipas shumës totale të TVSH-së

o Përmbledhja tabelore e të dhënave duhet të shfaqë analitiken e nënsistemit TP për

njësitë organizative të AT sipas kriterit për krahasim të qarkullimit dhe TVSH-së në

raport me njësitë e tjera organizative të AT

o Përmbledhja tabelore e të dhënave duhet të shfaqë analitiken e nënsistemit TP sipas

kriterit të koeficientit i cili tregon rritje ose ulje të qarkullimit të tatimpaguesit në krahasim

me të njëjtën periudhë të vitit të kaluar

o Shfaqja tabelore e numrit të monitorimeve të kryera sipas njësive organizative të AT

për intervalin e zgjedhur kohor

o Paraqitje grafike e të dhënave në TP (tendencat) për të gjitha vitet sipas numrit të

faturës

o Paraqitje grafike e TP (tendencave) për të gjitha vitet sipas TVSH-së së realizuar

o Paraqitje grafike e numrit të faturave për vitin aktual

o Paraqitje grafike e shumës totale të TP (faturave) për vitin aktual

o Pasqyrë grafike e shumës totale të TVSH-së në TP (faturave) për vitin aktual

o Paraqitje grafike e përqindjes së rritjes / uljes së numrit të TP (faturave) krahasuar me

të njëjtën periudhë të vitit të kaluar

o Paraqitje grafike e përqindjes së rritjes / uljes së shumës totale të TP (faturave)

krahasuar me të njëjtën periudhë të vitit të kaluar

o Paraqitje grafike e përqindjes së rritjes / uljes së shumës totale të TVSH-së në faturat

e lëshuara në Nënsistemin e TP krahasuar me të njëjtën periudhë të vitit të kaluar

o Paraqitje grafike e përqindjes së rritjes / uljes së numrit të monitorimeve tatimore

krahasuar me të njëjtën periudhë të vitit të kaluar

o Paraqitje grafike e përqindjes së rritjes / uljes së numrit të tatimpaguesve të Nënsistemit

TP krahasuar me të njëjtën periudhë të vitit të kaluar

o Paraqitje grafike e përqindjes së rritjes / uljes së numrit të tatimpaguesve që kanë

lëshuar më pak fatura sesa numri mesatar i faturave në nivel ditor / javor / mujor /

tremujor / vit

5.6.2.2 Analiza e tatimpaguesve në sistemin e pagesave me para në dorë në mbulimin

hapësinor

Monitorimi online i tatimpaguesve paraqet një paradigmë të re të kontrollit të tatimpaguesve në

nënsistemin TP. Qëllimi i prezantimit të këtij sistemi është menaxhimi efektiv i burimeve të monitorimit

nga DPT-ja me qëllim të rritjes së numrit të "monitorimit" me angazhim minimal të burimeve njerëzore.

Analiza e tatimpaguesve në nënsistemin TP përfshin mbulimin hapësinor të tatimpaguesve dhe

llogaritjen automatike të vlerave mesatare dhe vlerën e devijimeve krahasuar me tatimpaguesit e tjerë

që plotësojnë kriteret e njëjta të përzgjedhura në mbulimin hapësinor të përcaktuar.

Ky modul PQKM duhet të lejojë një analizë krahasuese të numrit të faturave të lëshuara, analizës së

qarkullimit, numrit dhe shumës së faturave të tatimpaguesve të kthyera/storno brenda një zone të

zgjedhur brenda intervalit për tatimpaguesit të njëjtë apo të ngjashëm bazuar në kriteret më të

rëndësishme të grupimit (aktiviteti, madhësia e hapësirës së biznesit, etj.).

Faqe 48 nga 140

Ky modul PQKM si bazë teknologjike duhet të përdorë Gjeoportalin Kombetar, qe menaxhohet nga

Autoriteti Shtetëror për Informacionin Gjeohapësinor.

Objektivi i mbulimit hapësinor dhe analizës krahasuese sipas kriterit të veprimtarisë ose klasifikimit të

tatimpaguesve të njëjtë apo të ngjashëm duhet të jetë një analizë e qarkullimit të tatimpaguesve dhe si

rrjedhim ofrimi i parakushteve për planifikimin të shënjestruar të monitorimit tatimor të rregullt ose të

jashtëzakonshëm dhe zbatimit të të ashtuquajturit “monitorim online”.

Kërkesat themelore funksionale për të siguruar janë si më poshtë:

o Ofertuesi duhet, në bashkëpunim me AT, të hartojë të gjitha TKP-të e nevojshme për

të përcaktuar funksionalitetin e këtij moduli PQKM. TKP-të e përmendura do të jenë

parakusht për ndërtimin e sistemit DWH dhe raportimit për këtë modul.

o Në navigacione të këtij moduli PQKM, është e nevojshme të mundësohet që sistemi i

analizës së tatimpaguesve të fillohet duke përdorur teknologjinë gjeo-hapësinore (gjeo-

lokacionin). Duke aktivizuar këtë funksion, hapet një faqe interneti brenda ndërfaqes

së sistemit me pamjen e hartes se Gjeoportalit Kombëtar dhe fushën e kërkimit për

tatimpaguesin

o Mundësia e kërkimit të tatimpaguesve sipas gjeo-lokacionit (NIPT, emri ose adresa e

lokacionit për të cilën dëshirohet të bëhet analiza hapësinore). Pas futjes së kritereve

të dëshiruara, sistemi paraqet të gjithë tatimpaguesit që plotësojnë kriteret e futura për

kërkim.

o Ky modul duhet të mundësojë përcaktimin e mbulimit hapësinor për analizën e

tatimpaguesve (100, 250 ose 500 metra). Tatimpaguesi i synuar shfaqet në harten e

Gjeoportalit Kombetar me gjeo-lokacionin e tij. Duke pasur parasysh përzgjedhjen

hapësinore, një grafik paraqitet në rreth që tregon të gjithë tatimpaguesit në

nënsistemin TP sipas kritereve të zgjedhura të aktivitetit të biznesit.

o Ky modul duhet të mundësojë përcaktimin e kritereve të llojit të tatimpaguesit në bazë

të vlerave të paracaktuara (aktiviteti, madhësia e hapësirës së biznesit, etj.)

o Për tatimpaguesit për mbulimin e zgjedhur hapësinor dhe kohor ky modul duhet të llogarisë

automatikisht vlerat e mëposhtme:

o Vlera mesatare e qarkullimit

o Vlera maksimale e qarkullimit

o Vlera minimale e qarkullimit

o Ky modul duhet të llogarisë automatikisht vlerat e mëposhtme

o Llogaritje dhe paraqitje e përqindjes së devijimit të qarkullimit mesatar për

tatimpaguesin e shënjestruar

o Llogaritje dhe paraqitje e përqindjes së devijimit nga qarkullimi mesatar për

tatimpaguesit e tjerë në mbulimin hapësinor dhe kohor

o Krahasimi i vlerës për të njëjtën periudhë të vitit të kaluar

o Ky modul duhet të shfaqë të gjitha vlerat e llogaritura si një tabelë të dhënash dhe paraqitje

grafike të të dhënave

o Ky modul duhet të sigurojë akses të lehtë në të dhënat tjera relevante për çdo tatimpagues në

mbulimin hapësinor dhe kohor.

o Ky modul duhet të ofrojë akses në të dhënat e monitorimit për secilin tatimpagues në mbulimin

hapësinor dhe kohor

o Ky modul duhet të ofrojë akses në të dhënat e vlerësimit të rreziqeve për çdo tatimpagues në

nënsistemin TP në mbulimin hapësinor dhe kohor

o Ky modul duhet të mundësojë gjenerimin e informacionit të e-monitorimit / monitorimit elektronik

për ata tatimpagues në nënsistemin TP që devijojnë ndjeshëm nga vlera mesatare e

veprimtarive të tatimpaguesve tjerë të mbulimit hapësinor dhe kohor. Njoftimi për e-

përcjelljen/e-monitorimin i dërgohet tatimpaguesit në adresën e e-mailit.

o Ky modul duhet të regjistrojë të gjitha njoftimet e dërguara me e-mail.

Faqe 49 nga 140

5.6.2.3 Analiza e tatimpaguesve në modulin e transaksioneve me para në dorë

Analiza e tatimpaguesit në modulin e pagesës me para në dorë nënkupton një rishikim të të dhënave

përkatëse si në nivelin e tatimpaguesit ashtu dhe në nivelin e adresave sekondare të tatimpaguesit.

Sistemi duhet të ofrojë akses në të dhënat kryesore të tatimpaguesve të grumbulluar brenda modulit

me listën e adresave të tija.

Të dhënat kryesore në lidhje me tatimpaguesit merren nga sistemi qendror i tatimpaguesve të AT.

Duke zgjedhur një tatimpagues, sistemi duhet të tregojë të dhëna të grumbulluara për një interval kohor

të përcaktuar, përkatësisht:

o Ofertuesi duhet, në bashkëpunim me AT, të hartojë të gjitha TKP-të e nevojshme për të

përcaktuar funksionalitetin e këtij moduli PQKM. TKP-të e përmendura do të jenë parakusht për

ndërtimin e sistemit DWH dhe raportimit për këtë modul

o Ky modul PQKM duhet të sigurojë kërkimin për tatimpaguesit bazuar në kriteret e mëposhtme:

o Emri i tatimpaguesit,

o Emri i degës së tatimpaguesit,

o NIPT,

o Aktivitetet

o Vendndodhjen gjeografike (adresat) ose përmes hartës së Gjeoportalit Kombëtar

o Ky modul PQKM duhet të sigurojë akses në të dhënat për tatimpaguesin e përzgjedhur nga të

gjitha regjistrat e disponueshëm të AT

o Ky modul PQKM duhet të ofrojë një krahasim të të dhënave të qarkullimit nga nënsistemi TP dhe

burime të tjera të të dhënave në analizën e paraqitjes së tatimeve të AT.

o Ky modul PQKM duhet të paraqet informacionet kryesore të tatimpaguesit:

o qarkullimin e tij,

o listën e degëve të tij dhe pjesën e qarkullimit të degëve në qarkullimin e tatimpaguesit,

o të dhënat mbi numrin dhe sasinë e faturave të lëshuara dhe të kthyera dhe të

qarkullimit,

o llogaritjen e vlerës mesatare të qarkullimit për tatimpaguesin,

o analiza krahasuese e biznesit të degës.

o Ky modul i PQKM-së duhet të paraqesë dhe të ofrojë mundësinë për të analizuar tatimpaguesit

dhe të gjitha degët me të dhënat bazë të biznesit.

o Ky modul PQKM duhet të ofrojë akses në informacionet e degës së biznesit:

o informatat kryesore të degës,

o qarkullimi në degë,

o të dhënat për numrin dhe sasinë e faturave të lëshuara dhe të kthyera dhe të qarkullimit

o Ky modul gjithashtu paraqet të gjitha monitorimet për tatimpaguesin dhe për të gjitha degët e

tatimpaguesit, të renditura sipas rendit kronologjik të monitorimit nga më të rejat në më të vjetra.

o Ky modul duhet të jetë në gjendje të sigurojë aksesin në të gjitha dokumentet përkatëse nga

monitorimi i tatimpaguesit në Nënsistemin TP, në formatin PDF

o Ky modul duhet të sigurojë grumbullimin e të dhënave për tatimpaguesin sipas kritereve të

mëposhtme

o sipas kriterit të qarkullimit

o sipas kritereve të numrit të faturave të lëshuara, veçanërisht për TP dhe TJP dhe

përmbledhëse

o sipas numrit të faturave të kthyera, veçanërisht për TP dhe TJP dhe përmbledhëse

o sipas kriterit të zhvlerësimit të qarkullimit duke anuluar faturën për të cilën nuk është

lëshuar një faturë e re, ose shuma ka pasur një reduktim domethënës

o Ky modul duhet të sigurojë grumbullimin e të dhënave për secilën degë të tatimpaguesit

individual sipas kritereve të mëposhtme

Faqe 50 nga 140

o sipas kriterit të qarkullimit

o sipas kriterit të numrit të faturave të lëshuara

o sipas kriterit të numrit të faturave të anuluara

o sipas kriterit të zhvlerësimit të qarkullimit duke anuluar faturën për të cilën nuk është


o Të dhënat e grumbulluara gjithashtu duhet të paraqiten grafikisht sipas mënyrë së përzgjedhur

të të dhënave në intervalin kohor, përkatësisht në intervalin e ditor, javor, mujor dhe vit.

o Ky modul duhet të sigurojë paraqitje tabelore të të dhënave të mëposhtme për periudhën e

përzgjedhur kohore:

o numri i faturave të lëshuara të tatimpaguesit

o qarkullimi i tatimpaguesit

o numri i faturave të anuluara të tatimpaguesit

o paraqitje tabelore zhvlerësimit të qarkullimit duke anuluar faturën për të cilën nuk është


o krahasimi i qarkullimit dhe numri i faturave krahasuar me vitin paraprak

o Ky modul duhet të ofrojë një vështrim grafik:

o Qarkullimi i përgjithshëm i tatimpaguesit dhe pjesa e faturave të kthyera nga

tatimpaguesi dhe degë

o Paraqitje grafike e qarkullimit ditor, javor, mujor, vit

o Paraqitje grafike e qarkullimit të një dege që është e integruar horizontalisht me monitorimin

dhe krahasimin e qarkullimit në raport me monitorimin.

5.6.2.4 Menaxhimi i anomalive

Sipas një vlerësimi, nënsistemi TP në nivel vjetor, do të duhej të pranojë rreth 1.000.000.000 fatura.

Përqindja e parashikuar statistikisht e faturave të gabuara (anomalitë e shumës së llogaritur) mund të

jetë rreth 0.0001 deri 0.0002%, ose rreth 130.000 deri në 260.000 fatura në vit.

Duke pasur parasysh ndikimin e mundshëm matematikor të anomalive në sistemin e raportimit,

përkatësisht të dhënat e mbledhura nga nënsistemi TP, është e nevojshme të krijohet një model

identifikimi i faturës me anomali.

Ky modul PQKM duhet të mundësojë identifikimin automatik të tatimpaguesve faturat e të cilëve kanë

anomali. Qëllimi i këtij segmenti nuk është identifikimi i faturave të këqija në aspektin e shumës së

faturës por sinjalizimi i punonjësve të AT që punojnë në këtë modul në ato fatura që kanë një element

matematikor të anomalive të modelit. Moduli apriori nuk liston "fatura të gabuara", por paralajmëron për

një devijim nga vlera e zakonshme e qarkullimit të tatimpaguesit.

Kërkesat themelore funksionale që duhet të sigurohen janë si më poshtë:

o Ofertuesi në bashkëpunim me MFE dhe AT do të hartojë të gjitha TKP-të e kërkuara

për të përcaktuar funksionalitetin e këtij moduli PQKM. TKP-të e përmendura do të jenë

parakusht për ndërtimin e sistemit DWH dhe raportimit për këtë modul.

o Llogaritja automatike e anomalive për tatimpaguesin në një përqindje të përcaktuar të

devijimit standard

o Paraqitje e anomalive të mundshme në formë tabelore

o Shfaqje automatike e një pasqyre javore të qarkullimit në kohë të njëjtë me paraqitjen

e anomalisë

o Shfaqje automatike e një pasqyre ditore të qarkullimit në kohë të njëjtë me paraqitjen

e anomalisë

o Shfaqje automatike e një pasqyre në bazë të orës të qarkullimit në kohë të njëjtë me

paraqitjen e anomalisë

Faqe 51 nga 140

o Akses në fatura të caktuara për periudhën (në orë) në të cilat është identifikuar

anomalia

o Akses në fatura të caktuara për periudhën (në ditë) në të cilat është identifikuar

anomalia

o Mundësia për të gjeneruar automatikisht korrespodencën elektronike për

tatimpaguesin me një listë të faturave që njihen si transaksione me anomali

o Mundësia e dërgimit automatik të njoftimit elektronik tek referenti kompetent në zonën

e të cilit ndodhet tatimpaguesi

5.6.3 MODULI I KONTROLLIT TATIMOR

Kontrolli i tatimor është një Iloj auditimi i ligjshëm, për te përcaktuar nëse taksat e duhura janë paguar

plotësisht nga subjekti që kontrollohet. Kontrolli mund të bëhet rastësisht, që do të thotë që tatimpaguesi

është zgjedhur rastësisht ose mund të ndërmerret për shkak se administrata tatimore ka informacione,

rezultate, analiza apo tregues të tjerë që tatimpagues të caktuar nuk veprojnë në përputhje me

legjislacionin tatimor.

Në nivelin parësor, auditimi i tatimpaguesve në modulin e pagesës me para në dorë dhe tatimpaguesit

e modulit jo cash kryhet duke përdorur të njëjta metoda dhe procedura. Dallimi është në shkallën e

riskut, d.m.th. tatimpaguesit tradicional që paguajnë produktet dhe / ose shërbimet e tyre me para në

dorë janë më të prirur për të shmangur pagesën e tatimeve.

Funksionalitetet që lidhen me auditimin e tatimpaguesve për të dy llojet e transaksioneve

Të përcaktojë grupe të tatimpaguesve që kryejnë transaksione me para në dorë dhe

transaksionet jo cash.

Të përcaktojë numrin e tatimpaguesve në grup sipas kritereve të "llojit të veprimtarisë" për

transaksione me para në dorë dhe transaksionet jo cash.

Të përcaktojë numrin e tatimpaguesve në grup sipas kritereve të "person fizik ose "person

juridik" për transaksione me para në dorë dhe transaksionet jo cash.

Të përcaktojë numrin e tatimpaguesve në grup sipas kriterit të "kornpetencës rajonale" për

transaksione me para në dorë dhe transaksionet jo cash.

Të përcaktojë numrin e tatimpaguesve në grup sipas kritereve të "lIojit të aktivitetit" dhe "statusit

të tatimpaguesit" për secilin kriter të "kompetencës rajonale" për transaksione me para në dorë

dhe transaksionet jo cash.

Të përcaktojë kriteret sipas numrit të tatimpaguesve dhe numrit të inspektoreve në dispozicion

sipas kriterit të “kornpetencës rajonale".

Të përcaktojë standardet për monitorimin online kundrejt metodave tradicionale (në %).

Të përcaktojë nevojën për rishpërndarjen e inspektoreve në dispozicion sipas rajoneve.

Të përcaktojë grupet e synuara të tatimpaguesve sipas afatit kohor të auditimit (duke marrë

parasysh aktivitetet sezonale).

Të identifikoje grupet e synuara të tatimpaguesve sipas rezultatit të analizës së riskut.

Të përcaktojë metodën e sanksionimit (të lehta dhe të rënda).

Ky sistem duhet të përbëhet nga nënsistemet e mëposhtme:

1. Planifikimi i mbikëqyrjes

2. Urdhri për monitorim

3. Njoftimi për monitorim tatimor

4. Procesverbalet e monitorimit tatimor

5. Vendimi tatimor

6. Nënsistemi për Web - për punën e inspektorëve në zyrë

7. Aksesimi i sistemit npm tabletave per punen e inspektoreve ne teren

Faqe 52 nga 140

8. Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret.

Monitorimi i taksave të transaksioneve me para në dorë duhet të mbështesë proceset e mëposhtme të

punës:

1. Planifikimin e monitorimit

2. Urdhrin për monitorim

3. Njoftimin për monitorimin

4. Procesverbalin e monitorimit

5. Vendimin tatimor


Çdo procedurë e monitorimit duhet të trajtohet si rast i veçantë dhe duhet të zbatohet në

përputhje me rregullat ligjore

Ky modul duhet të sigurojë një pasqyrë të të gjitha dokumenteve relevante që kanë dalë gjatë

monitorimit individual

Ky modul duhet të sigurojë monitorimin e treguesve financiarë të dënimeve të caktuara me

mandat të ngarkuar sipas rasteve individuale

Ky modul duhet të jetë i thjeshtë për t'u përdorur

Ky modul duhet të sigurojë parakushte për lidhjen me DMS (Data Management System) të

DPT-së.

Ky modul duhet të kete mundesine e aksesit te tij npm tabletit

Procesi i biznesit - Planifikimi i mbikëqyrjes

Planifikimi i monitorimit të tatimpaguesve në nënsistemin TP është një segment i veçantë i sistemit të

monitorimit të tatimpaguesve.

Planifikimi i monitorimit të rregullt të tatimpaguesve në nënsistemin TP bëhet në përputhje me rregullat

e biznesit në fund të çdo viti për vitin vijues. Planifikimi i monitorimit tatimor të tatimpaguesve në

nënsistemin TP duhet të bëhet në përputhje me kriteret e faktorit e rreziqeve dhe raportimin e

parregullsive. Duke pasur parasysh dinamikën e ndryshimit të kritereve dhe listën e tatimpaguesve të

përfshirë në planin monitorues, plani i monitorimit do të duhej të paraqiste një shkallë kohore të listës

së tatimpaguesve.


Ky modul duhet të kete mundesine e aksesit te tij npm tabletitPlanifikimin e monitorimit të

tatimpaguesve në nënsistemin TP duhet të mundësojë gjenerimin automatik të planit për tërë

vitin ose muajin në bazë të kritereve të paracaktuara ose modeleve standarde. Ky funksion

nënkupton që me inicimin e funksionit krijimi i planit përcaktohen kriteret për monitorim

Ky modul duhet të sigurojë një repozitorin të planit të monitorimit të tatimpaguesve në

nënsistemin TP

Ky modul duhet të sigurojë integrimin e planit të monitorimit me sistemin e faktorëve të rreziqeve

të tatimpaguesve në nënsistemin TP

Ky modul duhet të sigurojë përcjelljen e disponueshmërisë së kapaciteteve njerëzore

Ky modul duhet të gjenerojë lista të tatimpaguesve në nënsistemin TP të paraparë për

monitorim

Ofertuesi në bashkëpunim me MFE dhe AT duhet të përcaktojë kriteret e TKP-së për

përpunimin statistikor dhe analizën e planit të monitorimit

Ky modul duhet të mundësojë përcjelljen e monitorimeve të kryera në krahasim me planin e

monitorimit

Faqe 53 nga 140

5.6.3.1 Procesi i biznesit - Urdhri për monitorim

Urdhëresat për monitorim të tatimpaguesve në nënsistemin TP paraqesin pikën burimore për fillimin e

procesit të monitorimit të tatimpaguesit në nënsistemin TP.


Ky modul duhet të tregojë shkallën kohore të monitorimit

Urdhri duhet të krijohet si:

o Urdhër i bazuar në planin e monitorimit,

o Urdhër i bazuar në analizën e tatimpaguesit nga sistemi PQKM

o Urdhër i bazuar nga kallëzimet e qytetarëve në Qendrën e Thirrjeve

Urdhri duhet të ruhet në depon e urdhrave

Nga urdhri duhet të mundësohet gjenerimi i njoftimit për monitorim

Ky modul duhet të mundësojë gjenerimin e numrit të Urdhrit në mënyre automatike. Numri i

urdhrit mund të përcaktohet në skemën e sistemit duke i mundësuar administratorit të sistemit

të zgjedhë se si të gjenerojë numrin e urdhrit (lidhje automatike me të dhënat e agjendës ose

futjen manuale)

Lista e urdhrave duhet të shfaqet në mënyrë tabelore dhe urdhrat duhet të renditen sipas të

gjitha atributeve të tabelës

Kërkimi i tabelës së urdhrave duhet të jetë i mundur në bazë të numrit tatimor, emrit të degës,

datës së urdhrit, statusit të urdhrit, inspektorit

Ky modul, bazuar në procesin e punës dhe fazën e metodologjisë, duhet të përditësojë

automatikisht statusin e urdhrit të monitorimit

Urdhri duhet të plotësohet dhe ndryshohet duke iniciuar funksionin e duhur

Urdhri në formatin PDF duhet të ruhet përgjithmonë në repozitorij pas mbylljes së urdhrit

Ky modul duhet të sigurojë mundësinë për të gjeneruar njoftimet e monitorimit dhe Urdhrat e

monitorimit me atributet përkatëse

Kur të gjenerohet Urdhri, ky modul duhet automatikisht të marrë parasysh zyrtarët që do të

caktohen për monitorim në mënyrë që të ketë një shpërndarje të barabartë të numrit të urdhrave

për të gjithë zyrtarët

Ky modul duhet të mundësojë nënshkrimin dixhital të urdhrit për monitorim tatimor të

tatimpaguesve në nënsistemin TP

5.6.3.2 Procesi i biznesit - Njoftimi për monitorim tatimor

Njoftimi i monitorimit të tatimpaguesve në nënsistemin TP është një formë zyrtare standarde me

formular zyrtar përkatës me metadata. Zyrtari i autorizuar i AT duhet të jetë në gjendje të lëshojë llojet

e mëposhtme të njoftimit të monitorimit:

1) Njoftimi elektronik i monitorimit - i gjeneruar nga sistemi PQKM

2) Njoftimi përmes letrës për monitorim - bëhet në njësinë kompetente organizative përgjegjëse për

monitorimin e tatimpaguesve në Nënsistemin TP dhe sipas metodologjisë së përcaktuar


Ky modul duhet të mundësojë nënshkrimin elektronik të urdhrit të monitorimit të tatimpaguesve

në nënsistemin TP

Njoftimi për monitorim të tatimpaguesve në nënsistemin TP duhet të përfshijë elementet e

përshkruara (emri i organit tatimor, numri dhe data e dokumentit tatimor, emri ose emërtimi i

tatimpaguesit të cilit i referohet, objekti i monitorimit tatimor ose aktivitete të tjera që do të kryhen

Faqe 54 nga 140

gjatë monitorimit tatimor, datën e fillimit të monitorimit, etj. në përputhje me metodologjinë e

monitorimit të tatimpaguesve në nënsistemin TP)

Lista e njoftimeve për monitorim tatimor duhet të tregohet në mënyrë tabelore

Kërkimi i tabelës me njoftimet e monitorimit tatimor duhet të jenë i mundur në bazë të NIPT-it,

emrit të degës, datës së njoftimit, inspektorit

Njoftimet duhet të klasifikohen sipas metadatave tabelore

Metadatatnë tabelën e monitorimit duhet të jenë:

o Data e monitorimit

o Kohën e zbatimit të monitorimit tatimor

o Dega e tatimpaguesit

o Adresa e degës së tatimpaguesit,

o Lloji i monitorimit

o Bartësi i monitorimit tatimor

o Statusi i Njoftimit për monitorimin tatimor

Shtypja e njoftimit për monitorimin tatimor

Të dhënat në tabelën e monitorimit duhet të jenë:

o Njoftimi për monitorim tatimor duhet të gjenerohet me kërkesë të zyrtarit nga urdhri i

monitorimit tatimor. Është e mundur të gjenerohet vetëm një njoftim për monitorim

tatimor nga një urdhër i vetëm.

o Njoftimi për monitorim tatimor nuk mund të fshihet nëse në bazë të së cilit është kryer

monitorimi tatimor.

Ky modul duhet të ketë një repozitor/depo të njoftimit të monitorimit tatimor

Ky modul duhet të jetë në gjendje të shtypë njoftimet mbi monitorimin tatimor në formatin PDF

Ky modul duhet të mundësojë nënshkrimin elektronik të Njoftimit të monitorimit tatimor nga

zyrtari i AT

5.6.3.3 Procesi i biznesit – Procesverbalet e monitorimit tatimor

Procesverbali tatimor i tatimpaguesit në nënsistemin TP është një akt tatimor që tregon të gjitha

veprimet, dëshmitë dhe faktet e gjetura. Në procesverbal të monitorimit tatimor, brenda afatit të

përcaktuar me ligj, mund të parashtrohet ankesë. Monitorimi i tatimpaguesit në Nënsistemin TP

përcaktohet nga metodologjia e monitorimit të tatimpaguesve në Nënsistemin TP.

Në procesverbalin e monitorimit tatimor paraqiten faktet e gjetura gjatë monitorimit tatimor të

tatimpaguesit në Nënsistemin TP.

Pas përfundimit, procesverbali i monitorimit tatimor i jepet për nënshkrim personit përgjegjës

tatimpaguesit. Pas nënshkrimit, procesverbali tatimor duhet të gjenerohet dhe të ruhet në depon e

dokumenteve si dhe duhet të jetë e mundur të aksesohet sërish pa pasur nevojë të rigjenerohet.

Statusi i procesverbalit të monitorimit tatimor mund të jetë

1) Procesverbali për monitorimin tatimor është i rregullt

2) Procesverbali ku shënohen gjetjet e parregullsive gjatë monitorimit tatimor


Është e nevojshme të përcaktohet magazina e Procesverbaleve të monitorimit tatimor

Është e nevojshme të jetë në gjendje të kërkohet Procesverbali i monitorimit tatimor sipas

kritereve të numrit tatimor, emrit të tatimpaguesit, datës

Ky modul duhet të lejojë hapjen e Procesverbalit të monitorimit tatimor në mënyrë që shihen të

gjitha të dhënat

Faqe 55 nga 140

Është e nevojshme të mundësohet redaktimi i të dhënave para se të përfundohet Procesverbali

i monitorimit tatimor

Ky modul duhet të jetë në gjendje të përcaktojë statusin e Procesverbalit të monitorimit tatimor

në lidhje me dokumentet e tjera të rrjedhës së kontrollit

Ky modul duhet të mundësojë gjenerimin e Procesverbalit të monitorimit tatimor dhe të ruajë

atë në formatin PDF në depon e dokumenteve

Ky modul duhet të jetë në gjendje të shtyp Procesverbalin e monitorimit tatimor në formatin

PDF

Paraqitje e lëndëve të monitorimit sipas shenjave të klasifikimit për të gjitha dokumentet që

janë në lëndë

5.6.3.4 Procesi i biznesit – Vendimi tatimor

Vendimi tatimor është një akt administrativ i nxjerrë nga DPT-ja. Në vendimin tatimor përshkruhen

parregullsitë dhe shqiptohen masa ndaj tatimpaguesit që ka qenë objekt i monitorimit tatimor për

pagesa në para të gatshme. Ndaj vendimit tatimor, tatimpaguesi ka të drejtë të ankohet te organi i

përcaktuar sipas rregullave ligjore.

Masat e propozuara mund të jenë:

1) Vërejtja

2) Ndëshkimi në mandat (financiar) dënimi

3) Mbyllja e objektit dhe ndëshkimi financiar

Shuma e dënimit për kundërvajtje varet nga lloji dhe pesha e shkeljes së konstatuar në Procesverbalin

e monitorimit. Gjobat dhe shkallët e gjobave përcaktohen me ligj.


Duhet të përcaktohet depoja për Vendimet e monitorimit tatimor

Ky modul duhet të mundësojë lidhjen automatike për lëshimin e një Vendimi të monitorimit

tatimor si akt administrativ me sistemin e punës së zyrës së AT

Duhet të jetë në gjendje të kërkojë Vendimin e monitorimit tatimor në bazë të numrit tatimor,

emrit të tatimpaguesit, datës

Ky modul për monitorim tatimor të tatimpaguesve në Nënsistemin TP duhet të jetë në gjendje

të hapet në një mënyrë paraprake me një pamje të të gjitha të dhënave

Ky modul duhet të sigurojë gjenerimin automatik të masave dhe dënimeve të detyrueshme në

lidhje me parregullsitë e gjetura gjatë procedurës së monitorimit të tatimpaguesit në

Nënsistemin TP kur gjeneron Vendimin e monitorimit tatimor

Vendimi i monitorimit tatimor duhet të mundësojë që pas përfundimit të rastit dhe të lëshimit të

vendimit të monitorimit tatimor, të mos ketë mundësi të redaktohet apo ndryshohet

Gjenerimi i Vendimit të monitorimit tatimor nga Procesverbali i monitorimit tatimor dhe ruajte e

modelit në formatin PDF në depon e dokumenteve

Paraqitje e lëndëve të monitorimit sipas shenjave të klasifikimit për të gjitha dokumentet që janë

në lëndë

5.6.3.5 Sistemi i mbështetjes për inspektorët e tatimeve në Nënsistemin TP

Si pjesë e një sistemi të monitorimit të tatimpaguesve në Nënsistemin TP, ky nënsistem duhet të

zhvillohet si një mbështetje e TI për inspektorët për të monitoruar tatimpaguesit në Nënsistemin TP për

punën në terren.

Faqe 56 nga 140

Përfituesit kryesor të këtij nënsistemi përfshinë inspektorët tatimor dhe eprorët e tyre, të cilët janë

përgjegjës për sigurimin e transparencës dhe efikasitetit të punës së inspektorëve tatimor përgjegjës

për monitorimin e tatimpaguesve në Nënsistemin TP, si dhe sigurimin e harmonizimit të punës së tyre

me ligjet dhe rregulloret. Çdo përdoruesi të këtij nënsistemi do t’i ndahen të drejta të caktuara në varësi

të punës dhe / ose funksionit të tyre.

Nënsistemi duhet të përbëhet nga komponentët e mëposhtëm:

1. Versioni në Web - për punën e inspektorëve në zyrë

2. Versioni i aksesueshem npm tabletit - për inspektorët në terren

Aksesimi i :

1. për të mundësuar punën e inspektorëve në zyrë

2. automatizimi i proceseve të punës së monitorimit të tatimpaguesve në Nënsistemin TP

3. përcjellja e subjektit

4. sigurimi i kushteve për punë pa letër.

Qëllimi i prezantimit të një zgjidhjeje mobile është:

për të rritur performancën e inspektorit,

për të përshpejtuar procesin e monitorimit të tatimpaguesve në Nënsistemin TP,

për të krijuar trajtim të njëjtë për të gjithë inspektorët e autorizuar për të monitoruar tatimpaguesit

në Nënsistemin TP,

për të mundësuar monitorimin e efikasitetit të punës së inspektorëve tatimor.

Aksesimi i sistemit npm tabletit duhet të mbështesë plotësisht proceset e punës të përshkruara në këtë

dokument (proceset e biznesit).

Kjo duhe te mundesoje:

1. përshpejtimin dhe thjeshtësimin e punës së inspektorëve për monitorim të tatimpaguesve në

nënsistemin TP

2. automatizoj punën e inspektorit

3. për të krijuar parakushte për të ashtuquajturën zyra e lëvizshme mobile e inspektorëve tatimor

4. sigurimi i kushteve për punë pa letër

Nënsistemi duhet të përbëhet nga komponentët funksionalë si në vijim:

• Komponenti - Web versioni - për punën e inspektorit në zyrë duhet të zbatohet në nënsistemin e

Menaxhimit të përshkruar në arkitekturën teknike;

• Komponenti i versionit per aksesimin npm tableit - për inspektorët në terren duhet të zbatohet

duke përdorur nënsistemin e kontrollit të përshkruar në arkitekturën teknike.

Mbështetja e inspektorëve të autorizuar për monitorim të tatimpaguesve në Nënsistemin TP duhet të

përcaktohet në versionet e mëposhtme:

5.6.3.6 Nënsistemi për Web - për punën e inspektorëve në zyrë


Versioni për Web duhet të jenë në gjendje të ketë akses në të dhënat nga sistemi i planifikimit

të mbikëqyrjes së nënsistemit të SMR të tatimpaguesve në nënsistemin TP

Faqe 57 nga 140

Versioni për Web duhet të sigurojë pasqyra të subjekteve të monitorimit sipas shenjave të

klasifikimit për të gjitha dokumentet e lëndës

Versioni për Web duhet të ketë akses në të gjitha Urdhrat, Njoftimet dhe Procesverbalet e

monitorimeve tatimore të tatimpaguesve në Nënsistemin TP

Versioni për Web duhet të mundësojë gjenerimin automatik të Vendimit tatimor të bazuar në

Procesverbalin e monitorimit

Versioni për Web duhet të jetë në gjendje të tërheqë atributet nga procesi i AT nëpërmjet

shërbimit WEB

Versioni për Web duhet të mundësojë ruajtjen e Vendimeve tatimore të nënshkruara në mënyrë

elektronike në një prej formateve standarde në depon qendrore të Vendimeve tatimore në DPT

Versioni për Web duhet të lejojë dërgimin automatik të Vendimit tatimor të nënshkruar në

mënyrë elektronike Tatimpaguesit

Versioni për Web duhet të mundësojë pranimin dhe regjistrimin e Ankesave ndaj një Vendimi

tatimor. Nënsistemi Web duhet të mundësojë përcjelljen e kohëzgjatjes së rasteve individuale

të monitorimit të tatimpaguesve në Nënsistemin TP

Ofertuesi duhet, në bashkëpunim me AT, të përcaktojë të gjitha kriteret e TKP-së për

përpunimin statistikor të Procesverbalit për monitorim tatimor, Vendimeve të monitorimit tatimor

dhe Ankesave ndaj Vendimeve tatimore në nënsistemin TP

Versioni për Web duhet të mundësojë një analizë statistikore të Procesverbalit të monitorimit

tatimor dhe Vendimeve të monitorimit tatimor në raport me kriteret e përcaktuara të TKP-së

5.6.3.7 Zgjidhja e aksesimit te sistemi npm tabletit - për punën e inspektorëve në terren

Kërkesat themelore funksionale që duhen siguruar janë si më poshtë:

aksesim i sistemit npm tabletit duhet të mbështesë procesin e punës së mbikëqyrjes së

tatimpaguesit në Nënsistemin TP në tërësinë e tij.

Versioni i mobile duhet të dizajnohet për përdorim në platformat IOS dhe Android

Versioni i mobile duhet të jetë intuitiv dhe i lehtë për t'u përdorur

Versioni i mobile duhet të ofrojë mundësi që tatimpaguesi dhe inspektori tatimor të

nënshkruajnë me nënshkrime elektronike të gjitha dokumentet qe gjenerohen nga versioni

mobile

Inspektori tatimor akseson versionin mobile duke futur emrin e përdoruesit dhe fjalëkalimin.

Emri i Përdoruesit dhe fjalëkalimi definohen në regjistrin qendror të DPT të sistemit të

informacionit të përdoruesit

Versioni Mobile duhet të jetë në gjendje të ruajë certifikatën elektronike të inspektorit tatimor

Pas regjistrimit në sistem, në dashboard të inspektorit të regjistruar tatimor duhet të paraqiten

funksionet themelore të zgjidhjes mobile

o Kalendari

o Njoftimet e mia

o Shënimet e mia

o Statistika ime

o Tatimpaguesit.

o Konfiguracioni i sistemit.

o Versioni mobileduhet të jetë në gjendje të ruajë certifikatën elektronike të inspektorit tatimor

o Inspektori i taksave duhet të ketë kalendarin e tij për të hyrë në të gjitha aktivitetet e tij të

planifikuara dhe të zbatuara. Angazhimet afatgjata ose aktivitetet e planifikuara u dërgohen

inspektorëve nga sistemi qendror i DPT-ës, d.m.th. departamentit të planifikimit dhe analizës,

PQKM ose nga Qendra e thirrjeve të DPT-ës

o Është e nevojshme të jesh në gjendje çdo ditë të marrësh një pasqyrë të tatimpaguesve në

Nënsistemin TP mbi të cilën është e nevojshme te kryet kontrolli

o Është e nevojshme të sigurohet akses intuitive në detajet e njoftimit.

Faqe 58 nga 140

o Versioni mobile i aksesismit te sistemit duhet të jetë në gjendje të ofrojë informacionin e

mëposhtëm brenda njoftimit

o Të dhënat e biznesit të degës

o NIPT

o Emri i tatimpaguesit me informacionin tatimor

o Emri dhe adresa e degës së subjektit

o Numri unik i njoftimit dhe data e lëshimit

o Lloji i njoftimit

o Data dhe koha e planifikuar e mbikëqyrjes

o Statusi i njoftimit

o Shënim me njoftim

o Bashkangjitur me njoftim.

o Versioni mobile duhet të lejojë që njoftimi tatimor të dërgohet në formatin PDF në adresën e-

mailit të tatimpaguesit, që njoftimi i mbikëqyrjes të shtypet në formatin PDF ose që njoftimi i

mbikëqyrjes, pasi tatimpaguesi ta ketë lexuar atë, të nënshkruhet në mënyrë elektronike

o Versioni mobile duhet të jetë në gjendje të krijojë automatikisht Proces Verbal mbi monitorimit

e tatimpaguesit në nënsistemin TP

o Është e nevojshme të shfaqen të gjitha Proceset mbi monitorimin me statuse përkatës.

Tregohen vetëm ato të dhëna që janë rezultat i punës së zyrtarit të DPT-ës

o Versioni mobile duhet të lejojë që të futen elementët e mëposhtëm

o Data dhe koha e mbikëqyrjes

o Evidentimi i personave të pranishëm në rastin mbikëqyrës

o Kontrollet e elementeve të llogarisë,

o Të dhënat që lidhen me monitorimin dhe bilancin e arkës,

o Parregullsitë e vërejtura,

o Të dhënat tjera esenciale për mbikëqyrjen e tatimpaguesit në Nënsistemin TP

o Versioni mobile duhet të sigurojë që tatimpaguesi ose personi prezent nga tatimpaguesi në

momentin e mbikëqyrjes nënshkruan në mënyrë elektronike Proces Verbalin e mbikëqyrës

o Pas nënshkrimit elektronik të Procesit Verbalit të mbikëqyrjes, duhet të jetë e mundur që

Procesi i monitorimit të

o të shtypet menjëherë në vend

o Dërgohet tatimpaguesit përmes e-mail.

o Pas mbarimit të Procesit Verbalit të mbikëqyrjes, duhet të jetë e mundur ruajtja e Procesit

Verbalit të mbikëqyrjes të nënshkruar në mënyrë elektronike në formatin PDF në bazën e

dokumenteve

o Versioni mobile duhet të lejojë gjenerimin automatik të Vendimit mbi mbikëqyrjen nga Proces

Verbali i mbikëqyrjes

o Gjatë hartimit të Vendimit të mbikëqyrjes, duhet të jetë i mundur përcaktimi i masave ashtu që

sistemi në bazë të parregullsive të vëzhguara nga Proces Verbali vetë të sugjeroj llojin dhe

nivelin e masave kundërvajtëse të përcaktuara, por inspektori tatimor duhet të ketë mundësinë

të ndryshojë llojin e masës dhe shumën e dënimit

o Versioni mobile duhet të mundësojë "mbylljen" e Proces Verbalit pas përfundimit të procedurës.

Në momentin e "mbylljes", të gjitha të dhënat duhet të marrin statusin "vetëm për lexim" dhe

nuk mund të ndryshohen në asnjë mënyrë

o Versioni mobile duhet të sigurojë që tatimpaguesi ose personi i autorizuar nga tatimpaguesi

nënshkruan në mënyrë elektronike Vendimin e mbikëqyrjes

o Pas nënshkrimit elektronik të Vendimit të kontrollit, versioni mobile duhet të lejojë që Vendimi i

mbikëqyrjes

o të printohet në vend

o dërgohet tatimpaguesit përmes e-mailit

o Pas përfundimit të procedurës, Vendimi për mbikëqyrje duhet të jetë në gjendje të ruhet, në

format PDF, në bazën e dokumenteve

Faqe 59 nga 140

o Versioni mobile duhet t'i sigurojë mbikëqyrësit akses në kohë reale në të gjitha të dhënat

relevante të tatimpaguesit në Nënsistemin TP. Aksesimi i të dhënave nënkupton:

o Të dhënat e tatimpaguesit (të dhënat bazë, të dhënat e qarkullimit, niveli i riskut për

tatimpaguesin)

5.6.3.8 Sherbimi i dedikuar online për qytetarët nepermjet sherbimit ne e-albania

Sherbimi i dedikuar online për qytetarët npm e-albaniaështë një shërbim i ri i që do t'u mundësojë

qytetarëve të kontrollojnë faturat e tyre të parasë duke përdorur këtë kanal komunikimi. Duke përdorur

kanalin e komunikimit të lartpërmendur, qytetarët gjithashtu do të jenë në gjendje të regjistrojnë dhe të

raportojnë tatimpaguesit që nuk lëshojnë fatura në para në dorë ose lëshojnë fatura në para në dorë

pa elementet që kërkohen të jenë të pranueshëm për faturat e parave të gatshme në nënsistemin TP.

Objektivat e zhvillimit dhe zbatimit të shërbime online në portalin e-albania për qytetarët janë:

a. për t'u siguruar qytetarëve një mjet verifikimi për faturat në para në dorë të lëshuara nga

tatimpaguesit në nënsistemin TP

b. raportimi i mos lëshimit të faturave me para në dorë

c. për të zgjeruar bazën e të dhënave të qytetarëve ose pjesëmarrësve në procedurat e

kontrollit civil në procesin e lëshimit të faturave të pagesave

Kërkesat themelore funksionale që duhet të zbatohen janë si më poshtë:

o Shërbime online në portalin e-albania - për qytetarët ka për qëllim të kontrollojë evidencat e

faturave të lëshuara të parave cash përmes kodit QR

o Shërbime online në portalin e-albania për qytetarët duhet të mbështes dy platformat më të

zakonshme mobile IOS dhe Android

o Shërbime online në portalin e-albania - për qytetarët duhet të mbështes funksionet e

mëposhtme:

o Mundësinë e skanimin e QR kodit

o Shërbime online në portalin e-albania për qytetarët duhet të lexohet automatikisht dhe

të paraqes në ekranin e Smart phone të gjitha të dhënat e faturës së parasë së gatshme

përmes kodit QR,

o pasi të jetë ngarkuar fatura e parasë, qytetari duhet të jetë në gjendje të paraqesë një

kërkesë për kontrollimin e faturës së parasë së gatshme në qendrën e nënsistemit TP

në DPT

o Pas pranimit të kërkesës për kontrollimin e faturës së parasë cash, sistemi qendror i

DPT-ës kontrollon mesazhin e marrë (kërkesën e verifikimit) dhe e dërgon përgjigjen për

evidentimin e llogarinë me para, saktësinë e faturës së parasë së gatshme, shumën e

faturës së parave të gatshme, datën e faturës dhe degën që ka lëshuar llogarinë.

o Nëse një faturë në para nuk regjistrohet në nënsistemin TP, dërguesi i kërkesës së

verifikimit merr një përgjigje nga DPT-ja se fatura e parasë nuk është regjistruar në

nënsistemin TP.

o Në rast se nënsistemi TP qendror e ka përcaktuar që një faturë në para nuk gjendet në

nënsistemin TP, ai duhet të paralajmërojë automatikisht një parregullsi dhe të krijojë

një njoftim për gabim të faturës së parave të gatshme me agjentin e gjeolokimit më të

afërt të autorizuar për mbikëqyrje dhe që zbaton mbikëqyrje

o Shërbime online në portalin e-albania për qytetarët duhet të lejohet të raportojë mos

pagesën e faturave të parave të gatshme ose të faturave të parregullta të parave të

gatshme në mënyrë të tillë që një përdorues të mund të fotografoj një faturë të pasaktë

ose të raportojë mos lëshimin e faturave në para të gatshme.

o Shërbime online në portalin e-albania për qytetarët duhet automatikisht të shënojë

gjeolokacionin dhe ta përcjellë mesazhinnë DPT me atributet shoqëruese

Faqe 60 nga 140

o Pas përpunimit të kërkesës, nensistem TP do të kthejë tek dërguesi njoftimin për

statusin e kërkesës

5.6.4 SISTEMI I MENAXHIMIT TË RISKUT NË TRANSAKSIONET ME PARA NË DORE

Menaxhimi i riskut është baza për planifikimin dhe zbatimin e kontrollit të taksapaguesve në

Nënsistemin TP. Analiza e riskut së tatimpaguesve në Nënsistemin TP duhet t'u mundësojë zyrtarëve

të departamentit të planifikimit që të sigurojnë një parakusht për përzgjedhjen e saktë të atyre

taksapaguesve tek të cilët duhet të zbatohet mbikëqyrja e TP.

Para fillimit të auditimit tatimor, inspektori tatimor për monitorimin e tatimpaguesve në Nënsistemin TP

duhet të ketë aftësinë për të analizuar të dhënat e tatimpaguesit që i nënshtrohen mbikëqyrjes tatimore.

Për nevojat e këtij Nënsistemi DWH, sistemi i DPT-ës duhet të zgjerojë/ndërtojë një bazë të dhënash,

e cila do të përmbajë shumicën e të dhënave të nevojshme për analizën e riskut të tatimpaguesit.

Ofertuesi është i detyruar të parashikojë mbulimin e të dhënave nga burimet e treta dhe përfshirjen e

tyre të mundshme në Nënsistemin e SMR për qëllimet e Nënsistemit TP, duke parashikuar paraprakisht

ruajtjen e të dhënave në DPT DWH dhe përdorimin e tyre të mundshëm të mëvonshëm.

Ky Nënsistem duhet të ketë komponentët funksionalë si në vijim:

a) Komponenti i nënsistemit SMR i përdorur nga Zyrtarët e AT së Republikës së Shqipërisë

duhet të zbatohet në nënsistemin e kontrollit të përshkruar në arkitekturën teknike

b) Komponenti i nënsistemit SMR i përdorur nga tatimpaguesit e Republikës së Shqipërisë

duhet të ekzekutohet në nënsistemin e Vetëshërbimit të përshkruar në arkitekturën

teknike.

c) Komponenti i Nënsistemit SMR i përdorur nga përdoruesit e tjerë të organeve publike të

Republikës së Shqipërisë duhet të Ekzekutohet në nënsistemin e kontrollit të përshkruar

në specifikimetteknike.

Kërkesat minimale funksionale që Ofertuesi duhet të ofrojnë janë si më poshtë:

o Nënsistemi i SMR duhet të ofrojë informacion mbi të dhënat e mbledhura të DPT-ës si dhe

paraqitjen e duhur të tyre duke futur thjesht identifikuesin e tatimpaguesit në formularin e dhënë

o Ofertuesi kërkohet, në bashkëpunim me Klientin, që të krijoj një Katalog të riskut në

Nënsistemin TP

o Tatimpaguesit në Nënsistemin TP duhet të grupohen në 5 grupe risku, nga të cilat grupi 1 është

tatimpaguesi më i ulët i riskut dhe grupi 5 tatimpaguesit me risk më të lartë

o Nënsistemi SMR duhet të ofrojë mundësinë e plotësimit të rrezikut të ri të përcaktuar përmes

parametrave të nënsistemit SMR

o Pas përcaktimit të kritereve të rrezikut, Nënsistemi SMR duhet të mundësojë shënimin e

rrezikut brenda pesë kategorive të rrezikut

o Nënsistemi SMR duhet të sigurojë që në konfigurime të përcaktohen kriteret e rrezikut specifik

tatimor në Nënsistemin TP

o Nënsistemi SMR duhet pas nisjes të llogarisë automatikisht faktorin e rrezikut për një

tatimpagues ose tatimpaguesit të përcaktuar brenda një grupi ose aktiviteti të caktuar pas fillimit

të një funksioni të analizës

o Nënsistemi SMR duhet të ketë një pamje grafike dhe kërkim të tatimpaguesve në Nënsistemin

TP dhe analizën e rrezikut për tatimpaguesit individual sipas të gjitha kritereve të rrezikut

o Nënsistemi SMR, duke përdorur algoritme llogaritëse, gjeneron një risk të përgjithshëm për

tatimpaguesin në Nënsistemin TP

o Përcaktimi i riskut kundrejt qarkullimit mesatar (më i ulët se mesatarja në %)

Faqe 61 nga 140

o Përcaktimi i riskut në lidhje me numrin e faturave të lëshuara (më pak se mesatarja në %)

o Përcaktimi i rreziqeve në lidhje me numrin e faturave të kthyera (në%) Shuma e faturave të

kthyera (në%)

o Përcaktimi i riskut në lidhje me diferencën midis TVSH-së së raportuar dhe të dhënave agregate

nga Nënsistemi TP

o Përcaktimi i riskut në lidhje me numrin e inspektimeve të kryera

o Përcaktimi i riskut në lidhje me numrin e kontrolleve me parregullsi të identifikuara

o Përcaktimi i riskut në krahasim me mos lëshuarjen e faturës

o Përcaktimi i riskut në lidhje me elementët e faturës së pasaktë (Nr.)

o Përcaktimi i riskut ne krahasim me gabimet llogaritjes së TVSH-së (numri)

o Përcaktimi i riskut në lidhje me diferencën e parave të gatshme të gjetura në arkë - deficiti (në

%)

o Përcaktimi i riskut në lidhje me diferencën e parave të gatshme të arkëtuara - teprica (në %)

o Përcaktimi i riskut që lidhet me numrin e paralajmërimeve online të lëshuara tek tatimpaguesi

o Përcaktimi i rreziqeve sipas numrit të paralajmërimeve të lëshuara ndaj tatimpaguesit

o Përcaktimi i riskut në lidhje me shumën e gjobave të vendosura ndaj tatimpaguesit

o Përcaktimi i riskut në lidhje me numrin e vulosjes si masë përfundimtare ndaj tatimpaguesit

o Nënsistemi SMR duhet të mundësojë krijimin e një tablo vlerësimi të bazuar në rrezik me qëllim

të rritjes ose zvogëlimit të kritereve bazë për secilin grup individual që paraqet rrezik.

5.6.5 ZHVILLIMI, REGJISTRIMI DHE PËRCJELLJA E TRANSAKSIONEVE NÊ PARA JO CASH

Futja e regjistrave të eFaturës, monitorimi dhe përcjellja është një tjetër segment kyç i kontrollit të

rrjedhave financiare në Republikën e Shqipërisë.

eFatura është faturë që është lëshuar, përcjellë dhe pranuar në formë elektronike të strukturuar që

mundëson përpunimin e tij automatik dhe elektronik, ndërsa pagesa bëhet në para në dorë.

Regjistrimi, monitorimi dhe përcjellja e transaksioneve në para jo cash përfshin regjistrimin dhe

kontrollin nga AT për të gjitha transaksionet e kryera në kuptim të pagesave në para jo cash. Në këtë

drejtim, objektivi i zbatimit të këtij nënsistemi është t’i sigurojë AT monitorim të transaksioneve në para

cash në kohë reale.

Transaksionet në para jo cash përfshijnë pagesën e mallrave dhe shërbimeve që nuk përfshijnë pagesa

në para cash, çeqet, kartat e debitit dhe kreditit për të cilat është lëshuar një eFaturë për pagesë në

para jo cash.

Sistemi i monitorimit dhe regjistrimi i pagesave në para jo cash duhet të mbështetet nga procesi në

vijim:

Çdo transaksion në para jo cash dhe kohëzgjatja duhet të regjistrohet në AT në kohë reale.

Gjatë regjistrimit të një transaksioni të vetëm në para jo cash, AT do t’i caktojë çdo transaksioni

në para jo cash identifikuesin e veçantë të transaksionit në para jo cash si një identifikues të

vetëm dhe të papërsëritshëm.

Para lëshimit të eFaturës, të gjithë tatimpaguesit në nënsistemin TJP duhet të kërkojnë dhe instalojnë

një certifikatë elektronike nga autoriteti i ofrimit te nenshkrimit elektronik ne Republikës së Shqipërisë

(AKSHI), para se të prodhojnë sistemet e tyre të informacionit ose para lëshimit të eFaturës. Certifikata

elektronike do të sigurojë akses në nënsistemin TJP të AT-së, në bazë të së cilës tatimpaguesi

identifikohet si përdorues i vlefshëm i nënsistemit TJP. Certifikata elektronike gjithashtu shërben për të

nënshkruar në mënyrë elektronike çdo eFaturë në Nënsistemin TJP dhe garanton kredibilitetin e secilit

transaksion individual në para jo cash

Faqe 62 nga 140

Pasi tatimpaguesi të ketë marrë certifikatën elektronike, ai duhet ta instalojë atë në sistemin e tij të

eFaturës.

Pas instalimit të certifikatës elektronike, tatimpaguesi që është emetues i eFaturës krijon eFaturën

dalëse dhe pas përfundimit të procesit të eFaturës, e njëjta dërgohet në DPT në kohë reale në formatin

e përcaktuar XML / PDF.

Pas pranimit të eFaturës nga lëshuesi i faturës, DPT-ja është e detyruar të verifikojë saktësinë e

nënshkrimit elektronik të eFaturës, korrektësinë e strukturës së XML / PDF të eFaturës, si dhe të kryejë

kontrolle shtesë të kërkesës së pranuar (mesazhit) në kohë reale. Pasi të jetë verifikuar vlefshmëria e

eFaturës, DPT-ja ruan eFaturën në bazën e të dhënave të transaksioneve të faturave në para jo të

gatshme, e ruan mesazhin në tërësinë e tij në formatin XML / PDF në bazën e të dhënave, dhe në kohë

reale, Nënsistemi TJP gjeneron IVTPJG si identifikues i veçantë i transaksionit të vetëm në para jo

cash. Pas gjenerimit të IVTJPG, DPT nënshkruan në mënyrë elektronike përgjigjen ndaj kërkesës së

emetuesit të eFaturës dhe e dërgon atë në sistemin e lëshuesit të eFaturës nga i cili ka ardhur kërkesa

(eFatura).

Pasi tatimpaguesi merr përgjigje nga DPT-ja verifikon përmbajtjen e përgjigjes dhe nënshkrimin

elektronik të AT. Nëse verifikimi është kryer me sukses, tatimpaguesi i jep eFaturën, me elementet e

përshkruara të eFaturës (elementet e eFaturës do të përcaktohen me ligj/VKM/Udhezim) duke përfshirë

identifikuesin e veçantë të transaksionit në para jo cash të pranuar nga AT-ja, pranuesit të eFaturës.

Nëse eFatura nuk e ka kaluar verifikimin sepse është e pasaktë, AT-ja i dërgon tatimpaguesit një

mesazh se fatura është e pasaktë dhe tatimpaguesi duhet të korrigjojë eFaturën dhe të përsërisë

procedurën.

Pasi që Lëshuesi e dërgon eFaturën të tatimpaguesi i cili është Pranues i eFaturës, eFatura paraqitet

në WEB portalin eFatura të AT, ndërsa eFatura merr statusin “Në përpunim”.

Pasi eFatura është dërguar të tatimpaguesi i cili është Pranues i eFaturës, Nënsistemi TJP i dërgon një

njoftim tatimpaguesit i cili është pranues i eFaturës.

Tatimpaguesi i cili është pranues i eFaturës mund të:

a) Pranojë eFaturën – konfirmimi i pranimit të eFaturës ndryshon statusin e eFaturës nga “Në

përpunim” në “E pranuar”. Në kohën e konfirmimit të pranimit të eFaturës nga tatimpaguesi i cili

është pranues i eFaturës, ndryshimi i statusit të eFaturës regjistrohet në Nënsistemin TJP në

DPT, ndërsa për emetuesin dhe pranuesin e eFaturës gjenerohet në mënyrë automatike detyrimi

tatimor.

b) Refuzojë eFaturën – me refuzimin e pranimit të eFaturës nga tatimpaguesi i cili është pranuesi i

eFaturës ndryshon statusi i eFaturës nga “Në përpunim” në “E refuzuar”. Në kohën e refuzimit të

pranimit të eFaturës nga tatimpaguesi i cili është pranuesi i eFaturës ndryshimi i statusit

regjistrohet në Nënsistemin TJP në DPT, ndërsa për emetuesin dhe pranuesin e eFaturës nuk

lind asnjë detyrim tatimor. Tatimpagues i cili është pranues i eFaturës mund që brenda tridhjetë

(30) ditësh, të ndryshojë statusin e eFaturës refuzuar më parë në statusin “E pranuar”. Në këtë

rast gjenerohet në mënyrë automatike detyrimi tatimor. Në rast se e-Fatura edhe pas një

periudhe prej tridhjetë (30) ditësh ka statusin “E refuzuar”, ajo eFaturë fshihet nga lista e portalit

eFatura në WEB portalin e AT, ndërsa Nënsistem TJP i dërgon një njoftim përfundimtar

tatimpaguesit i cili ka lëshuar eFaturën se eFatura është “Refuzuar” dhe si i tillë nuk do të

regjistrohet në sistemin e faturave të lëshuara nga tatimpaguesi. Pavarësisht faktit se eFatura

është refuzuar, e njëjta ruhet në arkivin eFaturave në bazën e të dhënave të faturave të refuzuara.

Faqe 63 nga 140

Tatimpaguesi i cili është pranues i eFaturës, pas pranimit të eFaturës, duhet të lëshojë urdhërpagesën

për eFaturën e pranuar dhe të verifikuar në institucionin e tij financiar ose të kryejë pagesën

drejtpërdrejt. Institucioni financiar, ndërmjetësi financiar ose vetë tatimpaguesi, nëse kryen pagesën

drejtpërdrejt, duhet të dërgojë një njoftim të urdhërpagesës në mënyrë elektronike në DPT, pasi të jetë

bërë pagesa. DPT regjistron pagesën e eFaturës elektronike bazuar në identifikuesin e veçantë të

transaksionit në para jo cash në Nënsistemin TJP. Pagesa e eFaturës së pranuar dhe të konfirmuar

mund të jetë:

a) e pjesshme – pagesa e pjesshme e eFaturës. Nënsistemi TJP regjistron shumën e pagesës,

evidenton në mënyrë automatike ndryshimin tatimor, eFatura merr statusin “Pjesërisht e paguar”,

ndërsa tatimpaguesi që ka lëshuar eFaturën nëpërmjet Nënsistemit, merr njoftimin për pagesën

e pjesshme të eFaturës dhe shumën e pagesës. eFatura e paguar pjesërisht vazhdon të shfaqet

në WEB portalin e eFaturës në DPT derisa të paguhet plotësisht.

b) është paguar plotësisht – pranuesi ka paguar plotësisht eFaturën e pranuar dhe të konfirmuar.

Nënsistemi TJP regjistron shumën e pagesës, evidenton në mënyrë automatike ndryshimin

tatimor, eFatura merr statusin “E paguar plotësisht”, ndërsa tatimpaguesi që ka lëshuar eFaturën

nëpërmjet Nënsistemit merr njoftimin për pagesën e plotë të eFaturës dhe shumën e pagesës.

eFatura e paguar plotësisht nuk shfaqet në WEB portalin e eFaturës në DPT por ruhet në bazën

e të dhënave të eFaturës në DPT.

Emetuesi i

faturës me para

jo të gatshme

Krijimi i faturës

jo para të

gatshme

Hapi 1.

Dërgimi i faturës jo

para të gatshme në

DPT

Hapi 2

Evidentimi dhe

emetimi i

IUTJP në DPT

Hapi 3.

Hapi 5.

Hapi 6.

Hapi 4.

Marresit të

faturës jo para

të gatshme

Konfirmimi i

llogarisë

Refuzimi

i faturës

Hapi 6.

Evidentimi në

DPT

Hapi 7.

Hapi 7.

Hapi 8.

Njoftim

emetuesit

Fundi i procesit

të faturimit

Urdhërpagesa

Hapi 9.

Bankë

Hapi 10.

Përpunimi dhe

kontrollimi i

urdhërave

Hapi 11.Hapi 12.

Zbatimi i

urdhërave

Hapi 13.

Fundi i procesit

të faturimit

Njoftim tek

emetuesi dhe

marrësi

Hapi 14.

Figura 5: Skema e procesit logjik në Nënsistemin TJP

Ky nënsistem duhet të përbëhet nga komponentët e mëposhtëm:

a) Komponenti i krijimit dhe regjistrimit të transaksioneve në para jo cash (që do të zbatohet në

nënsistemin e Integrimit të përshkruar në arkitekturën teknike).

b) Komponenta e portalit Qendror Kombëtar të Shkëmbimit dhe Menaxhimit të eFaturave (që do të

zbatohet në nënsistemin e Vetë-shërbimit të përshkruar në arkitekturën teknike.

Faqe 64 nga 140

Kërkesat themelore funksionale të cilat duhet të sigurohen janë si më poshtë:

o Lëshuesi i eFaturës krijon, nënshkruan në mënyrë elektronike dhe dërgon eFaturën në bazën

qendrore të eFaturës me atributet e përcaktuara të eFaturës

o Sapo të pranohet eFatura, e njëjta kontrollohet dhe regjistrohet në DPT dhe merr identifikuesin

e veçantë të transaksionit

o Pasi që fatura të jetë verifikuar dhe ka marrë identifikuesin e veçantë të transaksionit, pranuesi

i eFaturës mund ta pranojë (pranimi) eFaturën ose ta refuzojë pranimin e eFaturës. Në të dyja

rastet, vendimi i pranuesit të faturës regjistrohet në DPT. Në rast se pranuesi ka pranuar

eFaturën e pranuar, për tatimpaguesin në proces lind detyrimi tatimor. Nëse pranuesi, për

çfarëdo arsye nuk e ka pranuar ose konfirmuar pranimin e eFaturës së pranuar, ky veprim

gjithashtu regjistrohet në DPT, ndërsa dërguesi merr njoftimin se eFatura e dërguar nuk është

pranuar.

o Pasi të dërgohet dhe pranohet eFatura, institucioni financiar ose ndërmjetësuesi financiar që

kryen procesin e pagesës ose vetë tatimpaguesi, nëse kryen pagesën e drejtpërdrejt të

eFaturës, është i detyruar të regjistrojë identifikuesin e veçantë të transaksionit në para jo cash

në secilin transaksion kur kryen transaksionin, pavarësisht nëse eFatura paguhet tërësisht ose

pjesërisht dhe duhet të dërgojë një mesazh në mënyrë elektronike në DPT se eFatura është

paguar. Pagesa e eFaturës regjistrohet në DPT me atributet e saj përkatëse.

o Pas pagimit të eFaturës, në tërësi ose pjesërisht, Dërguesi i eFaturës merr një Njoftim për

pagesë të plotë ose të pjesshme

o Tatimpaguesit janë të detyruar të hartojnë eFaturën sipas një skeme të standardizuar XML /

PDF, përkatësisht në formatin që do ta përcaktojë AT

o Kërkesat themelore funksionale që duhet të sigurohen janë se eFatura është një sistem me

origjinë të besueshme, përmbajtje të plotë dhe të lexueshme.

o Është e nevojshme të përcaktohet një vend (repozitorij) i pavarur për ruajtje të eFaturave në

DPT

o eFatura duhet të ketë të gjitha elementet e përcaktuara me rregulla, ndërsa ato minimale janë

o shenjat e procesit dhe faturës;

o periudhat që fatura mbulon;

o të dhënat e shitësit;

o të dhënat e blerësit;

o të dhënat e pranuesit të pagesës;

o të dhënat e përfaqësuesit tatimor të shitësit;

o referimi në kontratë (faturat që dorëzohen tek autoritetet publike);

o detajet e dorëzimit;

o udhëzimet për pagesë;

o të dhënat për detyrimet pagesat;

o të dhënat mbi artikujt në faturë;

o shumën totale të faturës;

o paraqitja e ndarë e TVSH-së

o Tatimpaguesit në bashkëpunimin e tyre ekonomik do të duhej të jenë në gjendje të

shkëmbejnë skedarët (eFaturat) ndërmjet vete, sipas një skeme të standardizuar XML

/ PDF.

o Shkëmbimi i eFaturës duhet të realizohet duke përdorur SSL (Secure Sockets Layer).

o Mbrojtja e integritetit të eFaturës duhet të sigurohet duke përdorur nënshkrimin

Elektronik të eFaturës. Nënshkrimi elektronik i eFaturës kryhet përmes një certifikate

të kualifikuar ose të zakonshme. Çdo tatimpagues do jetë i detyruar të marrë

certifikatën e tij nga autoriteti kompetent i Republikës së Shqipërisë

o Tatimpaguesit në Nënsistemin TJP mund të bëjnë shkëmbimin e eFaturave duke

përdorur WEB Portalin Kombëtar për Shkëmbimin e eFaturave.

Faqe 65 nga 140

Lëshimi i eFaturës duhet të mbështesë proceset e mëposhtme:

o Tatimpaguesit në sistemin TJP mund të bëjnë shkëmbimin e eFaturave duke përdorur WEB

Portalin Kombëtar për Shkëmbimin e eFaturave ose duke përdorur ndonjë ofrues tjetër të këtij

shërbimi.

o Krijimin e faturave dalëse.

o Nënshkrimin e faturave dalëse.

o Dërgimin e eFaturës dalëse nga ana e dërguesit të faturës

o Pasi emetuesi të krijojë, nënshkruajë dhe dërgojë eFaturën, eFatura dhe konfirmimi

regjistrohen në sistemin e AT. Nënsistemi duhet të mundësojë validimin e eFaturës dhe të

caktojë identifikuesin e veçantë të transaksionit në para jo cash.

Nënsistemi TJP duhet të mund të validojë:

o Korrektësinë e skemës së eFaturës.

o Korrektësinë e nënshkrimit elektronik të lëshuesit të eFaturës.

o Korrigjimin e normës tatimore të llogaritur, shumën totale dhe tatimin total.

o Identifikuesin e veçantë të transaksionit në para jo cash i eFaturës duhet të jenë i veçantë për

eFaturën, i cili do të jetë një lidhje për ndjekjen e gjurmëve gjatë gjithë jetës së përcjelljes të

eFaturës e cila përfundon me regjistrimin e pagesës së plotë (mbylljes) së faturës nga pranuesi

i eFaturës ose institucioni i tij financiar.

o Çdo eFaturë duhet të ketë një strukturë themelore identike të përbërë nga:

o Kreu i eFaturës (HeaderSupplier)

o Te dhëna e eFaturës (Data)

o Të dhënat (Data) përcaktohen për secilin mesazh veç e veç, ndërsa brenda elementit gjendet

struktura XML / PDF e cila është e ndryshme në varësi të mesazhit. Mesazhet që përmbajnë

struktura të pavarura XML / PDF futën në një “zarf” (p.sh. InvoiceEnvelope) të tipit base64binary

që përmban XML / PDF origjinal të koduar në Base64

Kontrollet e eFaturave pas vërtetimit të tatimpaguesit i cili paraqet kërkesë për verifikim të faturës

(përkatësisht verifikimit të certifikatës elektronike dhe nënshkrimit elektronik të tatimpaguesit):

o Kontrollimi i datës dhe kohës së dërgimit të faturës (paralajmërimi për faturat për të cilat koha

e faturimit është më shumë ose më pak se 3 orë nga data dhe koha e pranimit të faturës në

Nënsistemin TJP).

o Kontrollimi i datës dhe kohës së lëshimit të faturës (paralajmërim për faturat për të cilat koha e

faturimit është më shumë ose më pak se 6 orë nga data dhe koha e pranimit të faturës në

Nënsistemin TJP).

o Kontrollimi i numrit të faturës (paralajmërim për faturat të cilat kanë numrin e faturës 0 ose nëse

ekzistojnë dy ose më shumë fatura me të njëjtin numër të faturës të lëshuara nga i njëjti

tatimpagues ose dega e tij)

o Kontrollimi i korrektësisë së normës tatimore (paralajmërim për faturat në të cilat është

deklaruar një shkallë jo ekzistuese e TVSH-së). Kjo kontroll bëhet nëse tatimpaguesi është në

sistemin e TVSH-së.)

o Kontrollimi i bazës për llogaritjen e TVSH-së me shumën totale të bazës tatimore (paralajmërimi

për faturat nëse tatimpaguesi është në sistemin e TVSH-së. Ky paralajmërim jepet nëse shuma

e të gjitha bazave është e ndryshme nga shuma e përgjithshme e bazës tatimore).

o Kontrollimi i shumës së faturuar të TVSH-së (paralajmërim për fatura të cilat Nënsistemi TP ka

vërtetuar një devijim të TVSH-së në raport me vlerën e deklaruar të TVSH-së në faturë dhe se

kjo shumë e devijimit tejkalon kufirin e poshtëm apo të sipërm të rrumbullakimit). Kjo kontroll

bëhet nëse tatimpaguesi është në sistemin e TVSH-së.

o Nënsistemi TP duhet të mundësojë të parametrojë kufijtë e rrumbullakimit.

Faqe 66 nga 140

o Kontrollimi i shumës totale në faturë (paralajmërim për fatura të cilat Nënsistemi TP ka verifikuar

një devijim në llogaritjen e shumës totale të faturës në raport me shumën totale në faturë dhe

se kjo shumë e devijimit tejkalon kufirin e poshtëm ose të sipërm të rrumbullakimit). Kjo kontroll

bëhet nëse tatimpaguesi deklaron në faturë se ai është në sistemin e TVSH-së.

o Nënsistemi TP duhet të mundësojë të parametrojë kufijtë e rrumbullakimit.

Nënsistemi TJP duhet të sigurojë monitorimin e statusit të eFaturës:

o eFatura për pranim - eFatura është pranuar në depo qendrore të eFaturës në DPT

o eFatura është në përpunim – fatura është në validim

o Fatura për procedim të suksesshëm - validimi i eFaturës është bërë dhe eFatura është në

rregull, përcaktimi i identifikuesit te veçantë të transaksionit në para jo cash është dërguar dhe

konfirmuar Pranuesit të eFaturës

o Gabimi në përpunim të eFaturës - eFatura është e pasaktë (nuk ka kaluar validimin e AT.

Emetuesi i faturës merr njoftimin për llojin dhe tipin e gabimit të eFaturës

o eFatura është pranuar dhe konfirmuar (pagesa në valutë) – Pranuesi ka pranuar dhe

konfirmuar eFaturën dhe kështu ka dhënë pëlqimin për faturën e pranuar

o eFatura e pranuar dhe konfirmuar (skadimi i afatit të pagesës) – Pranuesi ka pranuar dhe

konfirmuar eFaturën dhe kështu ka dhënë pëlqimin për faturën e pranuar, por eFatura është

jashtë afatit te pagesës.

o eFatura është refuzuar nga ana e pranuesit. Pranuesi refuzoi të konfirmojë pranimin e eFaturës

o eFatura është paguar në tërësi - eFatura është paguar në tërësi nga ana e Pranuesit eFaturës

o eFatura është paguar pjesërisht – Pranuesi është paguar pjesërisht

Ofertuesi është i obliguar që të zhvillojë dhe zbatojë WEB Portalin Kombëtar për Shkëmbimin e

eFaturës (PKSHF)

o Në PKSHF do të kenë akses të gjithë tatimpaguesit e akredituar

o PKSHF duhet të sigurojë pranimin automatik të eFaturës nga sistemi ERP i tatimpaguesve

bazuar në skemën e përgatitur XML / PDF

o PKSHF duhet të ofrojë paraqitje grafike, mundësi për kërkim dhe statusin e të gjitha eFaturave

të tatimpaguesve (Katalogu i eFaturave hyrëse dhe Katalogu i eFaturave dalëse)

o PKSHF duhet të ofrojë akses në detaje për çdo eFaturë duke aktivizuar funksionet e detajeve

të eFaturës

o PKSHF duhet të sigurojë krijimin e eFaturës për tatimpagues të vegjël

o PKSHF duhet të ofrojë mundësinë e kthimit/anulimit të eFaturës

o Ofertuesi është i detyruar të krijojë dhe përgatisë për publikim WEB shërbimet për integrimin e

sistemeve ekzistues ERP të tatimpaguesve

o PKSHF duhet të sigurojë mundësinë e njoftimit të emetuesit dhe pranuesit të eFaturës për

ndryshimin e statusit eFaturës

o PKSHF duhet të ofrojë mundësinë e informimit të emetuesit dhe pranuesit të eFaturës mbi

shumën e pagesës eFaturës

o PKSHF duhet të sigurojë ruajtjen e të gjitha eFaturave dhe artikujve shoqërues që janë

shkëmbyer përmes shërbimit të eFaturës

o PKSHF duhet të sigurojë ruajtjen e eFaturave në formën origjinale elektronike sipas rregullave

ligjore në fuqi

o PKSHF duhet të sigurojë të gjithë tatimpaguesit akses Online për të parë arkivin e eFaturave

të dërguara dhe të pranuara në një periudhë të caktuar që do të përcaktohet nga DPT-ja

Faqe 67 nga 140

5.6.6 REGJISTRI I TATIMPAGUESVE (RTP-SË) DHE DEGËVE TYRE

5.6.6.1 Regjistri i tatimpaguesve (RTP-së)

Ofertuesi është i obliguar të zhvillojë dhe zbatojë Regjistrin e Nënsistemit të tatimpaguesve me qëllim

të mundësimit të regjistrimit të të gjithë tatimpaguesve të Republikës së Shqipërisë. RTP duhet të jetë

gjithëpërfshirës dhe të përmbajë të gjitha atributet e nevojshme për të menaxhuar në mënyrë efikase

tatimpaguesit.

RTP është një bazë e të dhënave e të gjithë tatimpaguesve që përmban të gjithë informacionin e

nevojshëm për identifikimin e tatimpaguesve (informatat e përgjithshme të tatimpaguesit),

korrespondencën me tatimpaguesit, përcaktimin e detyrimeve tatimore të tatimpaguesve ose bazën

mbi të cilën ata janë tatimpagues, përcaktimin e të drejtës së tatimpaguesve për lehtësira, të dhënat

mbi aktivitetet e tatimpaguesve, pasuritë e tatimpaguesve, tatimpaguesit e lidhur, të gjitha degët e

tatimpaguesve, etj. RTP duhet të jetë i qartë, i lehtë për t’u përdorur, funksional, i arsyeshëm dhe duhet

të sigurojnë ruajtjen dhe regjistrat e tatimpaguesve të cilat nuk do të kërkohen sa herë që tatimpaguesi

dorëzon deklaratën tatimore, etj. RTP duhet të ketë mundësinë e përditësimit të vazhdueshëm në

mënyrë që të dhënat të jenë të sakta dhe të përdorshme.

Nënsistemin RTP do të mund ta përdorin:

a) Zyrtarët e Republikës së Shqipërisë - kanë të drejtë të hyjnë në RTP në tërësi dhe kanë të drejtë,

bazuar në rolin e tyre, të redaktojnë metadatet në RTP. Ata gjithashtu kanë për detyrë për të

verifikuar të dhënat e regjistruara nga tatimpaguesi

b) Përdoruesit e tjerë të organeve administrative të Republikës së Shqipërisë në përputhje me

rregullat - Kanë autoritet të vetëm për të shqyrtuar të dhënat pa mundësinë e redaktimit të të

dhënave.

Ky nënsistem duhet të ketë komponentët funksionalë si në vijim:

a) Komponenti i Nënsistemit të cilin përdorin Zyrtarët e AT të Republikës së Shqipërisë duhet të

ekzekutohet në Nënsistemin e Menaxhimit të përshkruar në arkitekturën teknike.

b) Komponenti i Nënsistemit që përdoret nga tatimpaguesit e Republikës së Shqipërisë duhet të

zbatohet në Nënsistemin e vetë-shërbimit të përshkruar në arkitekturën teknike.

c) Komponenti i Nënsistemit që përdore nga përdoruesit e tjerë të organeve administrative të

Republikës së Shqipërisë duhet të zbatohet në sistemin e Menaxhimit të Nënsistemit të

përshkruar në arkitekturën teknike.


o RTP duhet të jetë i plotë, gjithëpërfshirës, integrues dhe duhet të përmbajë të gjithë

informacionin e nevojshëm për operacionin e DPT

o RTP duhet të jetë në gjendje të redaktohet dhe mirëmbahet nga zyrtarët e AT dhe

tatimpaguesit, varësisht nga modulet brenda RTP

o RTP duhet të jetë në dispozicion si WEB portal

o RTP gjithashtu duhet të jetë në dispozicion si një aplikacion mobil për nevojat e tatimpaguesve,

deri në masën që duhet të përcaktohet bazuar në modelin e të dhënave dhe funksionalitetit që

do të përcaktohet nga zgjidhja e portalit

o Përdoruesit e RTP-së do t’i qasen portalit duke përdorur certifikatën me nenshkrim elektronik

o Tatimpaguesit në RTP duhet të jenë në gjendje të përcaktohen sipas kriterit të personave

juridikë dhe fizikë me atribute specifike

Nënsistemi i RTP-së duhet të mbështesë përkufizimin e grupeve të mëposhtme të të dhënave:

Faqe 68 nga 140

o Më shumë lloje të informacioneve të kontaktit për një tatimpagues

o Regjistrimi dhe përcjellja e disa personave përgjegjës të tatimpaguesit

o Regjistrimi dhe përcjellja e shumë adresave të tatimpaguesit

o Regjistrimi dhe përcjellja e të gjitha llogarive për tatimpaguesin

o Regjistrimi dhe përcjellja e më shumë aktiviteteve të biznesit për tatimpaguesin duke përcaktuar

aktivitetet si statusin e tyre

o Ofertuesi duhet të sigurojë pranimin e të dhënave ekzistuese, të krijojë procedura të migrimit

të të dhënave dhe të jetë në dispozicion të Autoritetit kontraktues gjatë gjithë procesit të migrimit

dhe validimit

5.6.6.2 Degët e Tatimpaguesve

Ofertuesi duhet të zhvillojë dhe zbatojë brenda RTP-së modulin për të përshkruar dhe menaxhuar

atributet e degëve të tatimpaguesit. Ky modul nevojitet për funksionimin e sistemit të regjistrave dhe

monitorimit të tatimpaguesve në sistemet TP dhe TJP.

Ky Nënsistem duhet të ketë komponentët funksionalë si në vijim:

a) Komponenti për menaxhimin e Degëve të tatimpaguesit të cilin e përdorin zyrtarët e AT duhet të

zbatohet në Nënsistemin e Menaxhimit të përshkruar në arkitekturën teknike.

b) Komponenti i regjistrimit dhe përditësimit të Degëve të tatimpaguesve të cilin përdorin

tatimpaguesit duhet të zbatohet në Nënsistemin e Vetë-shërbimit të përshkruar në arkitekturën

teknike.

c) Komponenti i përcjelljes së Degëve të tatimpaguesve duhet të zbatohet në Nënsistemin e

Menaxhimit të përshkruar në arkitekturën teknike.

d) Komponenti i analizës së Degëve të tatimpaguesve nga zyrtarët e AT duhet të zbatohet në

Nënsistemin Analitik dhe monitorues të përshkruar në arkitekturën teknike.

Kërkesat themelore funksionale që duhet siguruar janë si më poshtë:

o Çdo degë e tatimpaguesit duhet të përfshijë informacion rreth statusit të tij (i hapur, i mbyllur,

përkohësisht i mbyllur dhe i mbyllur përgjithmonë)

o Moduli i “Degëve të tatimpaguesit” si pjesë e Nënsistemit të RTP duhet të lejojë regjistrimin dhe

konfirmimin e adresës së degës për të cilën zbatohet. Pas ruajtjes së të dhënave të adresës,

ky modul duhet të regjistrojë automatikisht gjeo-lokacionin e degës

o Moduli i “Degëve të tatimpaguesit” si pjesë e Nënsistemit të RTP-së duhet të mbështesë

përcaktimin e kohës së punës për secilën degë individualisht sipas kritereve të mëposhtme:

o E përhershme, sezonale

o Përcaktimi i punëve me turne ose afatshkurtra

o Përcaktimin e ditëve të punës

o Përcaktimin e ditëve të festave ose ditëve të pushimit.

o Përcaktimin e intervalit kohor të punës të një dege

o Kombinimin e kritereve të mësipërme

o Moduli i “Degëve të tatimpaguesit” si pjesë e nënsistemit të RTP-së duhet të lejojë shënimin e

madhësinë së degës sipas llojit të përdorimit të hapësirës

o Moduli i “Degëve të tatimpaguesit” si pjesë e nënsistemit të RTP-së duhet të mundësojë një

pasqyrë të të gjitha transaksioneve në sistemin e pagesave në para në dorë në mënyrë

individuale për secilën zyrë të tatimpaguesit

o Moduli i “Degëve të tatimpaguesit” si pjesë e nënsistemit të RTP-së duhet të mundësojë një

pasqyrë përmbledhëse të të gjitha transaksioneve në sistemin e pagesave në para në dorë për

tatimpaguesit.

o Moduli i “Degëve të tatimpaguesit” si pjesë e nënsistemit të RTP-së duhet të mundësojë

kërkimin e degëve sipas emrit ose adresës.

Faqe 69 nga 140

o Moduli i “Degëve të tatimpaguesit” si pjesë e nënsistemit të RTP-së duhet të mbështesë një

sistem për zbulimin e gabimeve gjatë regjistrimit, futjes, validimit, ruajtjes, redaktimit ose fshirjes

së një atributi me paralajmërim për llojin dhe tipin e gabimit dhe udhëzimet se si duhet të futen

dhe ruhen drejtë të dhënat

o Moduli i “Degëve të tatimpaguesit” si pjesë e nënsistemit të RTP-së duhet të sigurojë verifikimin

/ konfirmimin e të dhënave të degës si funksion të mbulimit hapësinor të tatimpaguesit në

Nënsistemin TP

o Moduli i “Degëve të tatimpaguesit” si pjesë e nënsistemit të RTP-së duhet të mundësojë

caktimin e aktiviteteve për secilën degë individualisht në mënyrë që aktiviteti të zgjidhet nga

lista e veprimtarive të cilat përcaktohen për tatimpaguesin me mundësinë e ndryshimit të

statusit të veprimtarisë për degë individuale

o Ofertuesi duhet të hartojë Katalogun e prodhuesve dhe mirëmbajtësve të softuerit të cilët

përdoren në Nënsistemin TP.

o Katalogun e prodhuesve dhe mirëmbajtësve të softuerit për TP duhet të mundësojë atribuonim

futjen e atributeve për secilin prodhues / mirëmbajtës të softuerit për TP.

o Moduli i “Degëve të tatimpaguesit” si pjesë e Nënsistemit të RTP-së duhet të sigurojë verifikimin

e ndryshimeve të reja ose të ndryshuara nga zyrtari i AT. Vetëm pas verifikimit të të dhënave

të zyrës nga zyrtari i DPT-ës, të dhënat mund të përdoren si besueshme

5.6.6.3 Aplikacion mobile - RTP për tatimpaguesit

Nënsistemi mobil Smart Phone - RTP për tatimpaguesit është krijuar si një kanal për komunikim i

tatimpaguesit me DPT-ën.

Ky nënsistem duhet të siguroj mbështetjen e procesit vijues të punës:

Të gjithë tatimpaguesit e Republikës së Shqipërisë duhet të marrin falas aplikacionin mobile te

lartpërmendura ose nga faqja e internetit e DPT të Republikës së Shqipërisë ose nga dyqanet online.

Pasi nënsistemi të instalohet në celularin e tatimpaguesit, tatimpaguesi duhet të ngarkoj certifikatën e

tij elektronike në pajisjen celulare.. Pas nisjes fillestare të nënsistemit me fjalëkalimin e caktuar,

përdoruesi do të jetë në gjendje të ndryshojë fjalëkalimin për të hyrë në menin e Nënsistemit në pajisjen

celulare.

Në rast se tatimpaguesi humb pajisjen celulare ose nuk përdor ose pushon së punuari, tatimpaguesi

është i detyruar ta raportojë këtë ngjarje në kohën më të shkurtër në DPT-ën më të afërt personalisht,

me telefon ose nëpërmjet e-mailit zyrtar të tatimpaguesit të krijuar pranë AT.

Ky Nënsistem duhet t'i mundësojë një tatimpaguesi të regjistruar që të shikojë kartën e tij tatimore, të

shoh borxhet e tij tatimore, treguesit kryesorë të biznesit të regjistruar në AT, të regjistrojë një degë të

re të tatimpaguesit, të modifikojë informatat tatimore të tatimpaguesit ekzistues, të regjistrojë ose të

çregjistroj punonjësin e tatimpaguesit.

Ky Nënsistem duhet gjithashtu t'i sigurojë tatimpaguesit të regjistruar statusin e kërkesës për dorëzimin

e Vendimit/Konfirmimit të AT-ës të nënshkruar në mënyrë elektronike, të cilat janë në katalogun e

dokumenteve të lëshuara nga AT-ja me kërkesë të tatimpaguesit.

Duke përdorur këtë kanal të komunikimit, tatimpaguesi duhet të jetë në gjendje të:


o Të ketë akses në kartelën e tij/saj të RTP,

Faqe 70 nga 140

o Dërgoj kërkesë ne menyre elektronikepër dorëzimin e certifikatave të nënshkruara

elektronikisht të lëshuara nga DPT-ja (Vërtetimi i gjendjes së borxhit tatimor, Vërtetimi i

anëtarëve të mbajtur të familjes, Konfirmimi mbi cenzusin e të ardhurave etj.)

o Shikimin e informacionit të xhiros

Qëllimet e shërbimeve online në portalin e-albania - RTP për tatimpaguesit janë:

1) Ofroj akses tatimpaguesve në të dhënat kryesore nga karta e tyre RTP

2) Sigurimi i shërbimeve shtesë si shërbim publik për tatimpaguesit

3) Zvogëlimi i numrit të ardhjeve dhe pritjeve në DPT

4) Kursimi i kohës dhe rritja e efikasitetit të DPT-ës

5) Sigurimi i kushteve për biznes pa letër.



o shërbimet online në portalin e-albania - RTP për tatimpaguesit do të jetë shërbimi që do të

ngarkohet pa pagesë nga faqet zyrtare të AT të Republikës së Shqipërisë

o Tatimpaguesit duhet të përdorin shërbime online në portalin e-albania - RTP për tatimpaguesit,

për të hyrë në kartën e tyre RTP. Parakusht për të hyrë në kartën personale RTP është të

instaloni një certifikatë elektronike mobile të tatimpaguesit

o Tatimpaguesi pas regjistrimit në shërbimeve online në portalin e-albania - RTP për

tatimpaguesit do të jetë në gjendje të përdorë të gjitha shërbimet e DPT-ës në dispozicion

o Gjatë regjistrimit në shërbimeve online në portalin e-albania - RTP për tatimpaguesit,

tatimpaguesi përpos certifikatës elektronike do të duhet të vendos edhe PIN unik për përdorimin

e shërbimeve online në portalin e-albania - RTP për tatimpaguesit

o Tatimpaguesi duhet të jetë në gjendje të kontrollojë gjendjen e borxhit tatimor sipas llojit të

tatimit

o Tatimpaguesi duhet të jetë në gjendje të kontrollojë qarkullimin e tatimpaguesit për ditën, javën,

muajin dhe vitin

o Tatimpaguesi duhet të ketë mundësinë të kontrollojë qarkullimin e tatimpaguesit në total sipas

degëve të tij në ditë, javë, muaj dhe vit

o Tatimpaguesi duhet të jetë në gjendje të marrë Vërtetimet/Vendimet/Njoftimet e nënshkruara

në mënyrë elektronike

o Tatimpaguesi duhet të jetë në gjendje të hyjë në kutinë e postës elektronike zyrtare (e-mail) të

hapur pranë DPT

o Tatimpaguesi duhet të jetë në gjendje të monitorojë gjendjen e lëndëve të tij të cilat ndodhen

në procedurat e DPT-ës

5.6.7 PASURIA E TATIMPAGUESIT

Ofertuesi është i detyruar të zhvillojë dhe zbatojë një nënsistem për përcjellje të pasurisë së

tatimpaguesit. Nënsistemi për përcjellje të pasurisë së tatimpaguesit duhet të mbulojë të gjithë pasurinë

e tatimpaguesit.

Qëllimi i këtij nënsistemi "Pasuria e tatimpaguesit" është të krijojë një sistem unik për monitorimin e

pasurisë së tatimpaguesve, parandalimin e evazionit fiskal, rritjen e efikasitetit të mbledhjes së tatimit

dhe automatizimin, përmirësimin dhe shumëllojshmërinë e procesit të mbledhjes së tatimit nga pasuria

dhe integrimin me nënsistemet TP dhe TJP.

Ky nënsistem duhet të ketë komponentët funksionale si në vijim:

Faqe 71 nga 140

a) Komponenti i menaxhimit me Pasurinë e tatimpaguesit që përdorin zyrtarët e DPT-së duhet të

zbatohet në nënsistemin e Menaxhimit të përshkruar në arkitekturën teknike.

b) Komponenta e rishikimit të Pasurisë së tatimpaguesit që përdorin tatimpaguesit duhet të zbatohet

në nënsistemin e Vetëshërbimit të përshkruar në arkitekturën teknike.


o Ofertuesi duhet të hartojë Katalogët e pasurisë të tatimpaguesit.

o Ofertuesi duhet të hartojë dhe zbatojë një Regjistër Qendror gjithëpërfshirës të Pasurive te

Patundshme (RQPP) të Republikës së Shqipërisë.

o Regjistri Qendror i Pasurive të Patundshme duhet të përfshijë regjistrimin e ndërtesave dhe të

tokës dhe pronarëve të tyre në Republikën e Shqipërisë.

o Regjistri Qendror i Pasurive te Patundshme duhet të përcaktohet në mënyrë të tillë që një pjesë

e të dhënave të pandryshuara të patundshmërive të përcaktohet si një njësi e veçantë që

automatikisht do të lidhet me regjistrin e tokave me qëllim të marrjes së të dhënave të pasurive

të paluajtshme

o Regjistri Qendror i Pasurive te Patundshme duhet të mbështesë regjistrin e transaksioneve

individuale për çdo ndryshim të pronësisë së paluajtshme

o Regjistri Qendror i Pasurive te Patundshme duhet të lejohet të marrë informata përkatëse të

ndryshueshme për çdo pronë individuale me qëllim të krijimit të një baze të dhënash të kërkuar

për tatim (statusi i pasurive të paluajtshme, përshkrimi i pronës, sa është prona e pajisur, etj.)

o Regjistri Qendror i Pasurive te Patundshme duhet të sigurojë një model transaksional të

shitësve dhe të blerësve të pronave, vlerës së pasurive të paluajtshme dhe burimit të fondeve

të blerjes së pronës

o Ofertuesi duhet të zhvillojë dhe zbatojë një regjistër Qendror gjithëpërfshirës të Pasurive të

Luajtshme (RQPL) të Republikës së Shqipërisë

o Regjistri Qendror i Pasurive të Luajtshme duhet të përfshijë të dhënat e automjeteve rrugore,

avionëve, anijeve, pronave luksoze, veprat e artit dhe pronarëve të tyre në Republikën e

Shqipërisë

o duhet të mbështesë regjistrin e transaksioneve individuale për çdo ndryshim të pronësisë së

luajtshme

o Regjistri Qendror i Pasurive te Luajtshme duhet të lejohet të marrë informata përkatëse të

ndryshueshme për çdo pronë individuale me qëllim të krijimit të një baze të dhënash të kërkuar

për tatim (statusi i pasurive të luajtshme, përshkrimi i pasurisë së luajtshme, etj.)

o Regjistër Qendror i Pasurive të Luajtshme duhet të sigurojë një regjistër transaksional për

lëvizjet e shitësit dhe blerësit, vlerën e pasurisë së luajtshme dhe burimet e blerjes së pasurisë

së luajtshme

o Ofertuesi duhet të zhvillojë dhe zbatojë një regjistër Qendror gjithëpërfshirës të pasurive të

luajtshmetë Republikës së Shqipërisë

o Regjistër Qendror i Pasurive të Luajtshme duhet të përfshijë të dhënat e pronësisë intelektuale,

pronës industriale (patentat, vulat tregtare, dizajnin industrial, origjinën gjeografike etj.). Të

drejtën e autorit dhe të drejtat e lidhura me to dhe pronarët e tyre në Republikën e Shqipërisë

o Regjistër Qendror i Pasurive të Luajtshme duhet të mbështesë evidentimet e transaksioneve

individuale për çdo ndryshim individual të pronësisë së luajtshme

o Regjistër Qendror i Pasurive të Luajtshme duhet të sigurojë një model transaksional të shitësit

dhe blerësit për pasuritë e luajtshme, vlerën e pasurive të luajtshme dhe burimet e fondeve për

blerjen e pasurive të luajtshme

o Ofertuesi duhet që të zhvillojë dhe zbatojë regjistrin gjithëpërfshirës Qendror të pasurive

financiare (RQPF) të Republikës së Shqipërisë

o Regjistri Qendror i Pasurive Financiare duhet të përfshijë të dhënat e aseteve financiare:

aksionet e biznesit, letrat me vlerë, aksionet në fondet e investimeve dhe subjektet e tjera të

ndërmarrjeve të përbashkëta, derivateve, kriptovalutat, etj.

Faqe 72 nga 140

o Regjistri Qendror i Pasurive Financiare duhet të mbështesë evidentimet e transaksioneve

individuale për çdo ndryshim individual të pronësisë së pasurisë financiare

o Regjistri Qendror i Pasurive Financiare duhet të sigurojë një model transaksional të shitësit

blerësve të pasurisë financiare, vlerën e aseteve financiare dhe burimet e fondeve për blerjen

e pasurisë financiare

o Regjistri Qendror i Pasurive Financiare duhet të ofrojë, nëpërmjet shërbimit WEB, azhurnimin

dhe validimin e të dhënave me institucionet përkatëse, përkatësisht regjistrat e tyre, të cilët janë

përgjegjës për monitorimin e tregut të kapitalit

o Ofertuesi duhet të zhvillojë dhe zbatojë Regjistrin Qendror të Tatimeve të Vlerësuesve të

certifikuar të Pasurisë (RQTVP) me atributet përkatëse me vlerësuesit

o Ofertuesi duhet të zhvillojë dhe zbatojë regjistrin Qendror të vlerësimit të pasurisë (RQTV)

o Ofertuesi duhet të zhvillojë dhe zbatojë algoritme për valorizimin automatik dhe vlerësimin e

çmimit të shitjes së një aseti të caktuar bazuar në të dhënat nga RQTV. Algoritmet e vlerësimit

automatik duhet të jenë specifike për secilin lloj të aseteve sipas atributeve të aseteve të

përshkruara

o Nënsistemet që mbulojnë fushën e pasurisë së tatimpaguesve duhet të përcaktohen në mënyrë

të tillë që organet shtetërore të Republikës së Shqipërisë dhe personat me autoritet publik të

mund të marrin përsipër mundësinë e futjes së të dhënave kur lidhin kontratë për një pronë të

caktuar

o Organet publike të Republikës se Shqipërisë dhe personat me autoritet publik duhet të

aksesojne regjistrat bazuar në autentifikimin ne sistem duke perdorur certifikatën e tyre me

nenshkrim elektronik.

o Të gjitha pasuritë e tatimpaguesve duhet të jenë në dispozicion për sa i përket qartësisë në

kartën e tatimpaguesit (kartela RTP)

o Në rast të shikimit te pasurisë të një tatimpaguesi, është e nevojshme të jetë në gjendje të

marrë një pasqyrë historike të aktiveve të tatimpaguesit

5.7 Përshkrimi i arkitekturës së sistemit

5.7.1 HYRJE NË ARKITEKTURËN E SISTEMIT

Vëzhguar nga këndi teknik, sistemi është tërësi e njëtrajtshme që duhet t'u mundësojë përdoruesve të

përmbushin me lehtësi, në mënyrë të sigurt dhe efikase proceset e tyre të punës duke përfillur kërkesat

e përcaktuara funksionale dhe ato jofunksionale. Sistemi duhet të përcaktojë kanale të ndërveprimit

kundrejt përdorueseve dhe po ashtu mundësi të integrimit me sisteme të partnerëve të tjerë. Përdoruesit

e sistemit duhet të ndahen në:

1. Tatimpagues,

2. Qytetarë

3. Përdorues të brendshëm si:

a. Zyrtarë të Administratës tatimore;

b. Zyrtarë tjerë të organeve publike;

c. Njerëz me autoritet/kompetenca publike

d. Përdorues të jashtëm.

Faqe 73 nga 140

Figura 6.: Konteksti i sistemit

Figura 7 paraqet ndarje të një tërësie logjike të sistemit në nënsisteme përkatëse duke synuar nivel të

lartë sigurie, transparencë, disponueshmëri dhe mundësi zgjerimi. Duhet të përcaktohen këto

nënsisteme

1. Nënsistemi integrues,

2. Nënsistemi vete shërbyes,

3. Nënsistemi analitik dhe mbikëqyrës

4. Nënsistemi analitik dhe mbikëqyrës.

INTEGRIMI I

NËNSISTEMIT

MENAXHIMI I

NËNSISTEMIT

VETËSHËRBIMI I

NËNSISTEMIT

ANALITIKA DHE

MBIKËQYRJA E

NËNSISTEMIT

Figura 7.: Ndarja e Sistemit

Koncepti i kërkuar i sistemit përcaktohet nga nevoja për të zbatuar entitete (tërësi) të ndara për arsye

sigurie, ndërlidhja e të cilave do të përcaktohet në mënyrë të saktë për të maksimizuar mbrojtjen e të

gjithë komponentëve të sistemit.

Secili prej këtyre nënsistemeve shpjegohet në kapitujt e mëposhtëm.

Faqe 74 nga 140

5.7.2 MODELI I BAZUAR NË KOMPONENTË

Kjo pjesë përshkruan arkitekturën e nevojshme të sistemit bazuar në kërkesat funksionale. Ky model

duhet të jetë ndërmjetës midis kërkesave funksionale dhe sistemit. Modeli ndihmon në vizualizimin dhe

kuptimin e sistemit duke përdorur diagramat strukturore.

Çdo komponent në model duhet të jetë njësi modulare funksionale me gjendjen e brendshme.

Komponentët duhet të përcaktohen nga këndi aplikativ dhe teknik. Komponentët aplikativ duhet të jenë

njësi funksionale që plotësojnë kërkesë te caktuar, ndërsa komponentët teknik ndihmojnë në realizimin

e komponentëve aplikativ.

5.7.2.1 Nënsistemi integrues

Nënsistemi integrues duhet të jetë tërësi e veçantë dhe komponent themelor i komunikimit kundrejt

përdoruesve të jashtëm - tatimpagueseve. Nënsistemi integrues duhet të bazohet në një kanal të sigurt

të komunikimit, disponueshmëri të lartë dhe me mundësi për zgjerim, i cili duhet të plotësojë kushtet

teknike për kërkesat funksionale që kanë të bëjnë me regjistrimin e pagesave me para në dorë (cash)

dhe me para jo cash

Nënsistemi integrues nënkupton arkitekturë te komponentëve teknik të përbërë nga:

1. komponenti për balancim të ngarkesës (load balancer),

2. komponenti për API gateway (API gateway),

3. komponenti për server me Java aplikacione (Java Application Server)

4. komponeti për bazen e të dhënat

5. komponentë të tjerë përcjellës me qëllim të plotësimit të kërkesave funksionale dhe jofunksionale

të Sistemit.

Balancues të ngarkesës

Serveri API

Serveri i aplikacionit JAVA

Anëtar 1 ... Anëtar N

Baza e të dhënave

Figura 8: Komponentët e Nënsistemit integrues

Nënsistemi integrues duhet të ketë disponueshmëri të lartë

Nënsistemi integrues duhet të jetë i zgjerueshem për tu përshtatur ngarkesave të ardhshme

Nënsistemi integrues duhet të jetë i disponueshëm 24 orë në ditë, 7 ditë në javë dhe 365 ditë në vit

Përshkueshmëria minimale e nënsistemit integrues duhet të jete 2000 porosi për sekondë

Koha e reagimit të nënsistemit integrues duhet të jete 2 sekonda për 90% të porosive

Faqe 75 nga 140

5.7.2.2 Nënsistemi menaxhues

Nënsistemi menaxhues duhet të jetë tërësish i veçantë, i sigurt dhe i disponueshëm që ndërvepron me

përdoruesit e brendshëm. Përdoruesit duhet të kenë akses në nënsistem në mënyrë të sigurt dhe

transparente duke përdorur mundësitë e infrastrukturës PKI të Agjencisë Kombëtare të Shoqerisë së

Informacionit.

Me nënsistem duhet nënkuptuar një arkitekturë teknike komponentësh të përbërë nga:

a. komponenti për balancim të ngarkesën (load balancer),

b. komponenti HTTP server (HTTP server),

c. komponenti i serverit për Java aplikacione (Java application server),

d. komponenti për menaxhimin e aksesimit (Access manager),

e. komponenti për listë të përdorueseve (user directory),

f. komponent për bazën e të dhënave (database)

g. komponentë të tjerë përcjellës me qëllim të plotësimit të kërkesave funksionale dhe jofunksionale

të Sistemit.


Server HTTP



Baza e të dhënave

Menaxheri i

qasjes

Përdoruesit

Figura 9: Komponentët e Nënsistemit menaxhues

Nënsistemi menaxhues duhet të ketë disponueshmëri të lartë

Nënsistemi menaxhues duhet të jetë i zgjerueshem për përshtatje ngarkesës në te ardhmen

Pritet që nënsistemi menaxhues të ketë disponueshmëri në 98% të kohës

5.7.2.3 Nënsistemi vetshërbyes

Nënsistemi vetshërbyes duhet të ketë një nderfaqe të jashtme dhe ka për qëllim mbështetjen e

përdorueseve të jashtëm (tatimpagueseve dhe qytetarëve) në bashkëveprim me sistemin. Përdoruesit

duhet të kenë akses në nënsistem në mënyrë të sigurt dhe transparent, duke përdorur mundësitë e

infrastrukturës PKI të Agjencisë Kombëtare të Shoqerisë së Informacionit.

Nënsistemi nënkupton arkitekturë teknike të përbërë nga:

a. komponent për balancim të ngarkesës (load balancer),

b. komponent HTTP server (HTTP server),

c. komponentët e serverit për Java aplikacione (Java application server),,

d. komponent për menaxhimin e aksesimit (Access manager),

e. komponent për listë të përdorueseve ( user directory),

Faqe 76 nga 140

f. komponent për bazën e të dhënave (Database)

g. komponentë të tjera përcjellëse me qëllim të plotësimit të kërkesave funksionale dhe

jofunksionale të sistemit.


Server HTTP



Baza e të dhënave

Menaxheri i

qasjes

Përdoruesit

Figura 10: Komponentët e Nënsistemit vete shërbyes

Nënsistemi vetshërbyes duhet të ketë disponueshmëri të lartë

Nënsistemi vetshërbyes duhet të ketë mundësi zgjerimi për tu përshtatur ngarkesave të ardhshme

Nënsistemi është i paraparë për 1,000,000 kërkesa në muaj

5.7.2.4 Nënsistemi analitik dhe mbikqyrës (monitorimit)

Nënsistemi analitik dhe mbikqyrës duhet të jetë i veçantë dhe i sigurt për të siguruar njohuri mbi të

dhënat analitike dhe mbikqyrëse për përdorues të përzgjedhur. Përdoruesit duhet të kenë akses në

nënsistem në mënyrë të sigurt dhe transparente duke përdorur mundësitë e infrastrukturës PKI të

Agjencisë Kombëtare të Shoqerisë së Informacionit.

Nënsistemi nënkupton arkitekturë teknike komponentësh të përbërë nga

a. komponent për balancim të ngarkesën (load balancer),

b. komponent HTTP server (HTTP server),

c. komponent për analizë të biznesit (Business analytics),

d. komponent për integrim të të dhënave (data integration),

e. komponent për menaxhimin e aksesit (Access manager),

f. komponent softuerik për mbikqyrje ( monitoring software),

g. komponent për listë të përdorueseve ( user directory),

h. komponent për bazën e të dhënave

i. komponentë të tjera përcjellëse me qëllim të plotësimit të kërkesave funksionale dhe

jofunksionale të sistemit.

Faqe 77 nga 140

balancues të ngarkesës

Server HTTP

Integrimi i të

dhënave

Analiza e

Biznesit

Serveri i

kontrollit

Baza e të dhënave

Menaxheri i

qasjes

Përdoruesit

Figura 11: Komponentët e sistemit analizues dhe mbikëqyrës

Nënsistemi analitik dhe mbikqyrës duhet të ketë disponueshmëri të lartë

Nënsistemi analitik dhe mbikqyrës duhet të ketë mundësi zgjerimi për përshtatje të ngarkesave të

ardhshme

Pritet që nënsistemi menaxhues të ketë disponueshmëri në 98% të kohës

5.7.3 MODELI OPERATIV

5.7.3.1 Modeli logjik

Modeli logjik i synuar (Figura 12) duhet të përbëhet nga:

a. pika logjike nga të cilat përdoruesit logohen në sistem,

b. grupe funksionale vertikalisht të kufizuara,

c. zona të aksesit horizontalisht të kufizuara

d. anëtarë logjikë që realizojnë ose mbështesin funksionalitetin e Sistemit

Figura 12: Modeli operativ logjik

Faqe 78 nga 140

Ndarja vertikale e sistemit është e paraqitur në ilustrimin shoqërues (Figura 12) duke përdorur vija

vertikale të ndërprera që kufizojnë katër njësi logjike të ndara:

a. Nënsistemin integrues

b. Sistemin vetë shërbyes

c. Nënsistemin menaxhues

d. Nënsistemin analitik dhe atë mbikëqyrës

Vështruar horizontalisht, sistemi duhet të ndahet në zona logjike, të cilat kontrollojnë shkallën e aksesit

dhe sigurinë e Sistemit:

a. Zona DMZ

b. Zona aplikative

c. Zona e sigurisë

d. Zona e të dhënave

e. Zona e ruajtjes së të dhënave

Shpjegim i detajuar i komponentëve individualë logjik është dhënë në Tabelën 2

Emri i komponentit logjik Përshkrimi

LN_LoadBalancer_IS

Komponenti logjik i cili duhet të sigurojë disponueshmëri të lartë dhe baraspeshë të ngarkesës për komponentët e varur në zonat tjera të Nënsistemit integrues. Gjithashtu, ky komponent ka për detyrë ndërprerjen e lidhjeve përmes SSL-së si dhe të sigurojë autentifikim të njëanshëm dhe dyanshëm përmes SSL-së duke përdorur certifikatat X.509.

LN_LoadBalancer_SS_MS_AMS

Komponent logjik i cili duhet të sigurojë disponueshmëri të lartë dhe barazpeshë të ngarkesës për komponentët e varur në zonat tjera të Nënsistemit vetë shërbyes, Menaxhues, Analitik dhe atij Mbikëqyrës. Gjithashtu, ky komponent ka për detyrë ndërprerjen e lidhjeve përmes SSL-së si dhe të sigurojë autentifikim të njëanshëm dhe dyanshëm përmes SSL-së duke përdorur certifikatat X.509.

LN_APIGateway_IS Komponent logjik i cili duhet të sigurojë akses të kontrolluar në ndërfaqet aplikative programuese (API) të nënsistemit integrues.

LN_HttpServer_SS Komponent logjik, përgjegjës për proxy të kundërt (reverse proxy) dhe aftësi për identifikim të njëhershëm (single sign-on) në nënsistemin vetshërbyes.

LN_HttpServer_MS_AMS Komponent logjik, përgjegjës për proxy të kundërt (reverse proxy) dhe aftësi për identifikim të njëhershëm (single sign-on) në Nënsistemin menaxhues dhe atë Analitik e mbikëqyrës.

LN_IntegrationSystem Komponent logjik i cili duhet të realizojë funksionet e nënsistemit integrues në përputhje me funksionet e përcaktuara.

LN_ServiceSystem Komponent logjik i cili duhet të realizojë funksionet e nënsistemit vetëshërbyes në përputhje me funksionet e përcaktuara.

LN_ManagementSystem Komponent logjik i cili duhet të realizojë funksionet e nënsistemit menaxhues në përputhje me funksionet e përcaktuara.

LN_AnalyticalSystem Komponent logjik i cili duhet të realizojë funksionet e nënsistemit analitik në përputhje me funksionet e specifikuara.

LN_MonitorigSystem Komponent logjik i cili duhet të realizojë funksionet e Sistemit mbikqyrës.

LN_AccessManager Komponent logjik i cili duhet të ofrojë autentifikim të centralizuar, përkatësisht mjedis per single sign-on dhe të sigurojë të gjitha burimet aplikative nga Nënsistemi vetë shërbyes, menaxhues dhe atij analitik e mbikëqyrës.

LN_UserDirectory Komponent logjik i cili duhet të sigurojë ruajtjen dhe menaxhimin e llogarive të përdoruesve, grupeve dhe të dhënave tjera.

LN_OLTPDatabase Komponent logjik i cili duhet të mundësojë përpunimin e të dhënat të transaksioneve online (OLTP).

LN_DWHDatabase

Komponent logjik për deponimin e të dhënave dhe operacioneve analitike (DWH) dhe po ashtu të një kopje të qëndrueshme të të dhënave për përpunimin e transaksioneve në internet (OLTP) në modalitet të gatishmërisë (stanbdby mode).

LN_SharedStorage Komponent logjik i cili duhet të sigurojë vend për ruajtjen e kopjeve të bazave të të dhënave OLTP dhe DWH, ruajtjen e dokumenteve të shtresës aplikative dhe ruajtjen e të dhënave virtuale.

5.7.3.2 Modeli fizik

Modeli fizik (Figura 13) duhet të përfaqësojë interpretim fizik të modelit logjik. Modeli duhet të përbëhet

nga:

Faqe 79 nga 140

a. pikat fizike nga të cilat përdoruesit logohen në sistem,

b. shtresat e kufizuara horizontalisht

c. komponentët fizikë që realizojnë komponentët teknik dhe aplikativ të sistemit.

Figura 13 Modeli operativ fizik

Modeli fizik përcakton shtresën e aksesimit (Access layer), Shtresën core (Core layer), Shtresën e të

dhënave (Data layer) dhe Shtresën e ruajtjes së të dhënave (Storage layer).

Realizimi i pritshëm i sistemit duhet të bazohet në disponueshmëri dhe zgjerueshmëri të lartë duke

përdorur teknologji të drejtpërdrejtë harduerike dhe virtuale. Arkitektura e preferuar e shtresës së

aksesit nënkupton akses të drejtpërdrejtë të harduerit, ku komponenti për balancim të ngarkesës

instalohet drejtpërdrejtë mbi serverin fizik në dispozicion. Shtresa core duhet të bazohet në teknologjinë

e virtualizimit. Anëtarët fizik të shtresës core duhet të instalohen në serverë virtualë të pavarur. Shtresa

e të dhënave dhe shtresa për ruajtjen e të dhënave duhet të përdorin akses të drejtpërdrejtë harduerike.

Mjedisi duhet të përcaktojë grupin minimal të koponenteve fizik të paraqitur në tabelën më poshtë.

Tabela paraqet emrin e një komponenti të vetëm fizik, numrin e paracaktuar të bërthamave të CPU-së,

numrin e përgjithshëm të instancave të një anëtari të vetëm fizik dhe së fundi bazën që paraqet akses

të drejtpërdrejtë harduerike ose virtuale.

Emri i komponentit fizik CPU Gjithsej Baza

PN_LoadBalancer_IS 4 bërthama 2 instancë Harduer fizik

PN_LoadBalancer_SS_MS_AMS 4 bërthama 2 instanca Harduer fizik

PN_HttpServer_SS 2 bërthama 2 instanca

Komponent virtual

PN_HttpServer_MS_AMS 2 bërthama 2 instanca

Komponent virtual

PN_JavaAS_Cluster_IS 8 bërthama 4 instanca

Komponent virtual

PN_JavaAS_Cluster_SS 4 bërthama 2 instanca

Komponent virtual

PN_JavaAS_Cluster_MS_AMS 4 bërthama 2 instanca

Komponent virtual

Faqe 80 nga 140

PN_AnalyticalSystem 4 bërthama 2 instanca

Komponent virtual

PN_MonitoringSystem 2 bërthama 1 instancë

Komponent r virtual

PN_AccessManager 2 bërthama 2 instanca

Komponent virtual

PN_UserDirectory 2 bërthama 2 instanca

Komponent virtual

PN_OracleDB_OLTP 16 bërthama 1 instancë Harduer fizik

PN_OracleDB_DWH 16 bërthama 1 instancë Harduer fizik

PN_SharedStorage 2 kontrollues 1 instancë Harduer fizik

PN_VM_Manager 2 bërthama 1 instancë Harduer fizik

Është gjithashtu e nevojshme të sigurohet mjedis testues sipas specifikimeve të tabelës më poshtë.

Pajisjet e mjedisit testues duhet të hostohen në mjedis të veçantë të ndarë ngamjedisi prodhues, duke

respektuar përvojën më të mirë. Pajisjet fizike si baza e të dhënave dhe administruesit të akseseve

mund të mbështesin njëkohësisht mjedise të shumëfishta.

Emri i komponentit fizik CPU Gjithsej Baza

PN_LoadBalancer_Test 2 bërthama 1 instancë Komponent

virtual

PN_HttpServer_Test 2 bërthama 1 instancë Komponent

virtual

PN_JavaAS_Cluster_Test 4 bërthama 2 instancë Komponent

virtual

Të gjithë komponenetet fizikë prodhues dhe testues janë paraqitur në më poshtë me një përshkrim të

komponentëve të pritur të softuerit të instaluar. Komponentë të caktuar softuerik mund të

bashkëveprojnë me komponentë të tjerë softuerik që ofertuesi duhet të parashikojë dhe të instalojë në

pajisjetnë dispozicion.

Emri i i komponentit fizik Përshkrim Komponentët e instaluar

fizikë

PN_LoadBalancer_IS

Server fizik me softuer të instaluar për barazim të ngarkesës që plotëson kërkesat e modelit logjik (LN_LoadBalancer_IS)

Komponent teknik fizik për administrim të balancuesit të ngarkesës (load balancer)

PN_LoadBalancer_SS_MS_AMS

Server fizik me softuer të instaluar për barazim të ngarkesës që plotëson kërkesat e modelit logjik (LN_LoadBalancer_IS)

Komponent teknik fizik për administrim të balancuesit të ngarkesës (load balancer)

PN_LoadBalancer_Test

Server testues virtual me softuer të instaluar për barazim të ngarkesës që plotëson kërkesat e modelit logjik (LN_LoadBalancer_IS dhe LN_LoadBalancer_SS_MS_AMS)

Komponent teknik fizik për administrim të balancuesit të ngarkesës (oad balancer)

PN_HttpServer_SS Server virtual me softuer të instaluar me mbështetje për HTTP që plotëson kërkesat e modelit logjik (LN_HttpServer_SS)

Komponent teknik fizik, HTTP server (HTTP Server)

PN_HttpServer_MS_AMS Server virtual me softuer të instaluar me mbështetje për HTTP që plotëson kërkesat e modelit logjik (LN_HttpServer_MS_AMS)

Komponent teknik fizik, HTTP server ( HTTP Server)

PN_HttpServer_Test Server testues virtual me softuer të instaluar me mbështetje për HTTP që plotëson kërkesat e modelit logjik (LN_HttpServer_SS, LN_HttpServer_MS_AMS)

Komponenti teknik fizik HTTP Server (HTTP Server)

PN_JavaAS_Cluster_IS

Server virtual me softuer të instaluar me mbështetje për server për Java aplikacione në modalitetin klaster të punës e që plotëson kërkesat e modelit logjik (LN_IntegrationSystem)

Komponent teknik fizik i

serverit për Java

aplikacione në cilësinë e

klasterit

Komponent fizik aplikativ i Nënsistemit integrues

PN_JavaAS_Cluster_SS

Serveri virtual me softuer të instaluar me mbështetje për Java server aplikativ në modalitetin klaster të punës që plotëson kërkesat e modelit logjik logjik (LN_ServiceSystem)


serverit për Java


klasterit

Faqe 81 nga 140

Komponent fizik aplikativ i Nënsistemit menaxhues

PN_JavaAS_Cluster_MS

Server virtual me softuer të instaluar me mbështetje për

server për Java aplikacione në modalitetin klaster të punës e

që plotëson kërkesat e modelit logjik

(LN_ManagementSystem)


serverit për Java


klasterit

Komponent fizik aplikativ i Nënsistemit menaxhues

PN_JavaAS_Cluster_Test

Serveri virtual testues me softuer të instaluar me mbështetje

për server për aplikacione në modalitetin klaster të punës e

që plotëson kërkesat e modelit logjik

(LN_IntegrationSystem, LN_ServiceSystem, LN_ManagementSystem)


serverit për Java


klasterit

Komponent fizik aplikativ i

Nënsistemit integrues

Komponent fizik aplikativ i

Nënsistemit vetëshërbyes

Komponenti fizik aplikativ i nënsistemit kontrollues

PN_AnalyticalSystem

Server virtual me softuer të instaluar me mbështetje për operacione analitike që plotësojnë kërkesat e modelit logjik (LN_AnalyticalSystem) duke përfshirë mjetet e inteligjencës së biznesit dhe integrimin e të dhënave në modalitetin aktiv-pasiv


serverit për Java

aplikacione

Komponent teknik fizik

për analiza te biznesit

Komponent teknik fizik për integrimin e të dhënave (data integration)

PN_MonitoringSystem

Server virtual me softuer të instaluar për mbikëqyrje të punës dhe administrim që plotëson kërkesat e modelit logjik (LN_MonitorigSystem)


serverit për Java

aplikacione

Komponent teknik fizik për mbikëqyrje të punës dhe administrim ( monitoring)

PN_AccessManager

Server virtual me mbështetje të instaluar software për autentifikim dhe autorizim të centralizuar që plotëson kriteret e modelit logjik (LN_AccessManager)


serverit për Java

aplikacione

Komponent teknik fizik për administrimin e akseseve

PN_UserDirectory

Server virtual me softuer të instaluar për ruajtjen dhe administrimin e llogarive dhe grupeve të përdoruesve që plotëson kërkesat e modelit logjik (LN_UserDirectory)

Komponent teknik fizik për ruajtjen dhe administrimin e llogarive dhe grupeve të përdoruesve

PN_OracleDB_OLTP

Server fizik me softuer të instaluar për baza e të dhënave me mbështetje për transaksionet që plotësojnë kërkesat e modelit logjik (LN_OLTPDatabase)


bazës së të dhënave

Oracle OLTP

PN_OracleDB_DWH

Serverë fizikë me softuer të instaluar për baza të të dhënave me mbështetje për transaksione që plotësojnë kërkesat e modelit logjik (LN_DWHDatabase)


bazës së të dhënave

Oracle DWH

PN_SharedStorage

Serverët fizik me sistem të përbashkët të të dhënave që

plotëson kërkesat e modelit logjik (LN_DWHDatabase)

Specifikimi i mjedisit harduerik është përcaktuar në

Emri i grupit harduerik Përshkrim

HW_LoadBalancer_1 Grupi nënkupton të paktën dy (2) serverë fizik në regjim redundant të

punës sipas specifikimeve të harduerit

HW_LoadBalancer_2 Grupi nënkupton të paktën dy (2) serverë fizik në regjim redundant të

punës sipas specifikimeve

Faqe 82 nga 140

HW_VM_Cluster Grupi përbëhet nga të paktën tetë (8) serverë fizikë me

disponueshmëri të lartë, në regjim redundant të punës me qëllim të

krijimit të mjedisit shërbyes virtual sipas specifikimeve

HW_VM_Cluster_Manager Grupi nënkupton të paktën një (1) server fizik për mbikëqyrje dhe

administrim të klasterit virtual sipas specifikimit

HW_Exadata_1 Grupi nënkupton një mjedis harduerik sipas specifikimit të Oracle

Exadata

HW_Exadata_2 Grupi nënkupton një mjedis harduerik sipas specifikimit të Oracle

Exadata

HW_StorageSystem Grupi nënkupton një mjedis harduerik për ruajte të përbashkët të të

dhënave me së paku dy (2) kontrollera te pavarur

5.7.4 SHTRESAT E SISTEMIT

Kapitulli përshkruan shtresat individuale të sistemit nga një vështrim i kërkesave jo funksionale me

përkufizim të komponentëve softuerik dhe harduerik përkatës. Shtresat e sistemit vëzhguar sipas

modelit fizik janë shtresa e aksesit, Shtresa core, shtresa e të dhënave dhe shtresa e ruajtjes së të

dhënave.

Të gjitha shtresat dhe të gjithë anëtarët fizik të sistemit duhet të jenë të instaluar, konfiguruar dhe të

dorëzohen në data center.

5.7.4.1 Shtresa e aksesimit

Shtresa e aksesimit është pjesë e zonës logjike DMZ dhe përfshin komponentë për balancim të

ngarkesës, duke përfshirë resurset softuerike dhe harduerike, me qëllim përmbushjen e të gjitha

kërkesave për performancë dhe siguri të lartë të sistemit, si terminim të SSL-it, kërkesave për filtrim etj.

Arkitektura përcakton komponentin fizik për balancim të ngarkesës si zgjidhje softuerike drejtpërdrejtë

në mjedis harduerik, duke marrë parasysh kërkesën për disponueshmëri të lartë. Për shkak të kërkesës

për disponueshmëri të lartë, arkitektura aktiv dhe pasiv ( active-passive cluster) me IP adresë të

lëvizshme (floating IP address).

I. Softuer për balancim të ngarkesës

Softueri për balancim të ngarkesës (load balancing software) është komponent teknik për menaxhimin

e ngarkesës i cili realizon praktikat e disponueshmërisë së lartë dhe shpërndarjen e ngarkesës në

serverë të tjerë. Komponenti përdor algoritme të përcaktuara mirë për shpërndarjen e ngarkesës, duke

mundësuar zgjërueshmëri horizontale (scalable), punë redundante dhe disponueshmëri të lartë.

Komponenti ekzekutohet në harduer për menaxhim të ngarkesës së nënsistemit integrues dhe harduer

për menaxhimin e ngarkesës së nënsistemeve tjera.

o Komponenti duhet të përmbushë më së miri shpërndarjen e ngarkesës

o Pritet disponueshmëri e lartë e komponentit ( high availability)

o Komponenti duhet të ketë mbështetje për SSL dhe autentikimin përmes certifikatës në anën e

klientit

o Komponenti duhet të mbështesë algoritme të shumëfishta për balancim të ngarkesës, si Round

Robin, Source, Random, URL etj.

o Mbështetje për sesione që nënkupton mekanizmin e sigurimit të aksesit në të njëjtin server

gjatë gjithë ndërveprimit të përdoruesit me sistemin

o Mbështetje për ACL lista dhe përcaktim të rregullave të aksesimit

o Komponenti duhet të sigurojë zbatimin e rregullave me qëllim që të lëshoj vetëm atë që është

e lejuar në mënyrë eksplicite

Faqe 83 nga 140

o Komponenti duhet të mbështesë rishkrimin dhe ridrejtimin e URL-ve.

o Mbështetje për mbikqyrje të komponentëve

o Mbështetje për logim dhe statistikë

o Licencat duhet të jenë të përhershme për numër të pakufizuar përdoruesish

II. Hardueri për balancim të ngarkesës së nënsistemit integrues

Hardueri për balancim të ngarkesës ( load balancing hardware) së nënsistemit integrues siguron

platformë harduerike në të cilën ekzekutohet komponenti softuerik për balancim të ngarkesës. Është

pjesë e grupit harduerik HW_LoadBalancer_1 dhe mundëson realizimin e instancës fizike të

komponentit PN_LoadBalancer_IS me përbërës softuerik të instaluar për balancim të ngarkesës.

III. Hardueri për balancim të ngarkesës së nënsistemeve tjera

Hardueri për balancim të ngarkesës ( load balancing hardware) së nënsistemeve tjera siguron platformë

harduerike në të cilën ekzekutohet komponenti softuerik për balancim të ngarkesës. Është pjesë e

grupit harduerik HW_LoadBalancer_2 dhe mundëson realizimin e instancës fizike të komponentit

PN_LoadBalancer_SS_MS_AMS me përbërës softuerik të instaluar për balancim të ngarkesës.

5.7.4.2 Shtresa bërthamë (core)

Shtresa e bërthamës (Core layer) është një tërësi e cila dinstancon komponentët logjikë nga Zona DMZ,

Zona aplikative dhe Zona e sigurisë. Të gjithë anëtarët fizikë janë nën kontrollin e një mjedisi virtual

mbikqyrës (hipervisor). Mjedisi virtual ekzekutohet mbi serverët harduerik (HW_VM_Cluster) orkestruar

nga serveri i menaxhimit (HW_VM_Cluster_Manager). Shtresa core supozon ekzistencën e një sistemi

të përbashkët për ruajtjen dhe mbajtjen e të dhënave të serverit virtual (HW_StorageSystem).

I. HOSTI FIZIK PËR SERVERË VIRTUAL

Hosti per makinen virtuale është pjesë elementare e shtresës core që mundëson ekzekutimin e

serverëve virtuale. Serveri fizik do te hostoje servera virtual për mjedisin prodhues dhe atë testues.

II. HARDUERI PËR MENAXHIMIN E MJEDISIT VIRTUAL

Hardueri për menaxhimin e mjedisit virtual (virtual machine management) paraqet komponent

menaxhimi dhe monitorimi të një mjedisi virtual. Komponenti ka të instaluar konsolën qendrore për

menaxhim.

III. SOFTUERI VIRTUALIZUES

Softueri virtualizues (Virtual Machine Software) mundëson realizimin e serverave virtual, shtresës core

për të arritur disponueshmëri dhe përshtatshmëri të lartë të komponentëve për ngarkesa në sistem.

Softueri virtualizues është i instaluar mbi grupin harduerik HW_VM_Cluster, me përjashtim të një

konsole për menaxhim, të instaluar në serverin fizik HW_VM_Cluster_Manager.

o Softueri virtualizues duhet të ketë konsolë qendrore për menaxhim

o Softueri virtualizues duhet të menaxhojë serverët fizik

o Softueri virtualizues duhet të mbështesë dhe menaxhojë serverat virtual

o Lidhja e komponentëve NIC dhe menaxhimi i rrjeteve VLAN

o Softueri virtualizues duhet të mbështesë menaxhimin e ruajtjes të të dhënave

o Softueri virtualizues duhet të menaxhojë një cikël të jetës virtuale të serverit, d.m.th., të

mundësojë krijimin virtual të serverit duke përdorur mediume instalimi ose template, të

mundësojë ndezjen , fikjen dhe fshirjen e serverëve virtual.

o Softueri virtualizues duhet të mbështesë dublikimin dhe migrimin e serverëve virtual

Faqe 84 nga 140

o Softueri virtualizues duhet të menaxhojë me disponueshmëri të lartë shpërndarjen e resurseve

o Softueri virtualizues duhet të zbatojë veçorinë e ashtuquajtur Anti-Affinitiy

o Softueri virtualizues duhet të mbështesë akses në bazën e të dhënave.

o Licencat duhet të jenë të përhershme për numër të pakufizuar përdoruesish

IV. SERVERI PËR JAVA APLIKACIONE

Serveri për Java aplikacione (Java Application Server) është komponent softuerik teknik që mundëson

ekzekutimin e aplikacioneve të bazuara në Java platformë. Serveri është i instaluar në pajisje fizike,

PN_JavaAS_Cluster_IS, PN_JavaAS_Cluster_SS dhe PN_JavaAS_Cluster_MS,

PN_JavaAS_Cluster_Test dhe anëtarë të tjerë fizikë të mundshëm, në përputhje me parakushtet e

komponentëve tjerë të softuerit. Serveri për Java aplikacione ekzekuton komponentët e aplikacionit nga

domainet e nënsistemit integrues, vetë shërbyes dhe atij menaxhues dhe analitik. Serveri për Java

aplikacione nënkupton një lidhje integrale me shtresën e sigurisë për të arritur nivel të lartë sigurie.

Serveri për Java aplikacione përdoret në mjedisin prodhues dhe atë testues, në komponente fizikë ose

mjedise të veçanta. Numri i përgjithshëm i serverëve të instaluar për Java aplikacione përcaktohet nga

modeli fizik.

o Serveri për Java aplikacione duhet të përmbushë standardin Java EE 7

o Serveri për Java aplikacione duhet të mbështesë mekanizmin e ashtuquajtur “hot redeploy”,

përkatësisht mundësi që versioni i ri i aplikacionit të mund të instalohet gjatë kohës që serveri

është në punë. Ky mekanizëm nënkupton që versioni i vjetër i aplikacionit hiqet automatikisht

pas një kohe ose me përfundim të të gjitha sesioneve të përdoruesve

o Serveri për Java aplikacione duhet të mbështesë një grup praktik funksionesh: krijim të

serverëve, instalim të aplikacioneve, mbikëqyrje dhe administrim të performancës së serverit

si dhe diagnostikim.

o Serveri për Java aplikacione duhet të ofrojë mjete të tilla si konsolë administruese përmes

shfletuesit (browser) me qëllim të automatizimit dhe administrimit të detyrave; mundësi për

konfigurim të lehtë e të shpejtë; mundësi për punë përmes vijës komanduese dhe mbështetje

për protokollin SNMP.

o Serveri për Java aplikacione duhet të sigurojë mjete për mbikëqyrje, diagnostikim dhe që

mundësojnë grumbullimin, analizimin, izolimin dhe diagnostikimin e gabimeve dhe problemeve

tjera në performancë.

o Serveri për Jave aplikacione duhet të mundësojë përcaktim të përparësisë së punëve bazuar

në rregullat e përcaktuara dhe të vëzhgimit të statistikës aktuale të punëve që janë në kryerje

e sipër.

o Serveri për Java aplikacione duhet të mundësojë integrimin me mjetet për zhvillim “Maven”

o Serveri për aplikacionet Java duhet të ofrojë mbështetje për protokollet komunikuese RESTful

dhe WebSocket.

o Serveri për Java aplikacione duhet të sigurojë mjet për ngarkim (lexim) klasash, mjet ky për të

analizuar problemet në procesin e ngarkimit të klasave ( class loading).

o Licencat duhet të jenë të përhershme për numër të pakufizuar përdoruesish.

o Serveri për Java aplikacione duhet të jetë i certifikuar dhe i mbështetur nga hardueri i

përzgjedhur, sistemi operativ dhe softueri virtualizues

o Serverët për Java aplikacione duhet të jenë plotësisht të licencuar (të gjithë procesorët,

memoria dhe disku) për të gjitha mjediset

V. SERVERI HTTP

Serveri HTTP është komponent softuerik i cili mundëson akses në përmbajtje dhe aplikacione në

internet duke siguruar single sign-on dhe disponueshmëri të lartë. Serveri HTTP është i instaluar në të

gjitha instancat e planifikuara të komponentëve fizikë PN_HttpServer_SS, PN_HttpServer_MS_AMS,

Faqe 85 nga 140

PN_HttpServer_Test por dhe anëtarët tjerë fizikë të mundshëm, në përputhje me kushtet e

komponentëve tjerë softuerik.

Serveri HTTP përdoret në mjedisin prodhues dhe atë testues por në anëtarë fizikë ose mjedise të

veçanta. Numri i përgjithshëm i serverëve HTTP të instaluar përcaktohet nga modeli fizik.

- Serveri HTTP duhet të ketë mbështetje të integruar për enkriptim përmes protokollit SSL, duke

përfshirë mundësi për enkriptim në server por edhe në klient

- Serveri HTTP duhet të ketë mbështetje të integruar për single sign-on

- Serveri HTTP duhet të ketë mbështetje të integruar për proxy

- Serveri HTTP duhet të ketë mbështetje të integruar për WebSocket

- Licencat duhet të jenë të përhershme për numër të pakufizuar përdoruesish

VI. MENAXHUESI I AKSESIT

Menaxhuesi i aksesit është komponent teknik softuerik përgjegjës për autentifikim të centralizuar,

autorizimin dhe single sign-on në sistem. Menaxhuesi i aksesit ekzekutohet në të gjitha instancat e

planifikuara të anëtarit fizik PN_AccessManager.

Menaxhuesi i akseseve përdoret në mjedisin prodhues dhe atë testues në komponente fizikë ose

mjedise të veçanta. Numri i përgjithshëm i menaxhuesve të akseseve të instaluar përcaktohet nga

modeli fizik

Menaxhuesi i aksesit duhet të këtë mbështetje për autentifikim, autorizimin dhe identifikimin të

njëhershëm (single sign-on)

Menaxhuesi i aksesit duhet të këtë mbështetje për administrimin e rregullave të sigurisë (policy

administration)

Menaxhuesi i aksesit duhet të mundësojë vëzhgimin (përcjelljen) e sesioneve të përdoruesve

në kohë reale

Menaxhuesi i aksesit duhet të sigurojë mundësi për auditim te akseseve.

Menaxhuesi i aksesit duhet të mbështesë skema të ndryshme për autentifikim; përmes

certifikatës digjitale X.509, protokollit Kerberos, LDAP dhe autentifikimit me emrin të përdoruesit

dhe fjalëkalim

Menaxhuesi i aksesit duhet të mbështesë nivele të ndryshme të identifikimit, në varësi nga

llojet e aplikacioneve që do të mbrohen

Menaxhuesi i aksesit duhet të siguroj disponueshmëri të lartë

Menaxhuesi i aksesit duhet të siguroj zgjërueshmëri për tu përshtatur ngarkesës të ardhshme

në Sistem

Menaxhuesi i aksesit duhet të sigurojë konsolë administruese të bazuar ne shfletues (browser)

për menaxhim dhe mbikëqyrje

Licencat duhet të jenë të përhershme për numër të pakufizuar përdoruesish

VII. LISTA E PËRDORUESVE

Lista e përdoruesve është komponent teknik softuerik i bazuar në standardin LDAP për ruajtjen e

centralizuar të llogarive të përdoruesve të sistemit (user account). Lista e përdoruesve ekzekutohet në

të gjitha instancat e planifikuara të komponentit fizik PN_UserDirectory.

Lista e përdoruesve përdoret në mjedisin prodhues dhe atë testues por në anëtarë fizikë ose mjedise

të veçanta. Numri i përgjithshëm i listës së përdoruesve të instaluar përcaktohet nga modeli fizik.

Lista e përdoruesve duhet të mbështesë protokollin LDAP

Faqe 86 nga 140

Lista e përdoruesve duhet të mbështesë integrim me zgjidhje të tjera të bazuara në LDAP për

sinkronizim të llogarive të përdoruesve

Lista e përdoruesve duhet të sigurojë disponueshmëri të lartë edhe në nivel të ruajtjes së të

dhënave

Lista e përdoruesve duhet të sigurojë zgjërueshmëri për tu përshtatur ngarkesave të ardhshme

në sistem

Lista e përdoruesve duhet të sigurojë konsolë administrimi të bazuar ne shfletues (browser)

për administrim dhe mbikëqyrje

Lista e përdoruesve duhet të sigurojë mjete për migrim dhe sinkronizim të të dhënave me

sisteme të jashtme LDAP

Lista e përdoruesve duhet të ketë mbështetje për autentifikim për përdoruesit e jashtëm,

përkatësisht autentifikim përmes partnerëve të LDAP-së si Microsoft Active Directory etj.

Licencat duhet të jenë të përhershme për numër të pakufizuar përdoruesish

VIII. SISTEMI MBIKQYRËS

Sistemi mbikqyrës është përgjegjës për mbikqyrjen dhe menaxhimin e të gjithë komponentëve teknik

si sistemeve për baza të të dhënave, sistemeve për balancim të ngarkesës, serverëve për aplikacione

Java, serverëve HTTP, menaxhuesve të aksesit, listave të përdoruesve etj. Sistemi mbikqyrës

ekzekutohet në të gjitha instancat e planifikuara të komponentit fizik PN_MonitoringSystem.

Sistemi mbikqyrës përdoret në mjedisin prodhues dhe atë testues në komponentë fizikë ose mjedise të

veçanta. Numri i përgjithshëm i sistemeve mbikëqyrëse të instaluara përcaktohet nga modeli fizik.

- Sistemi mbikëqyrës duhet të mundësojë mbikëqyrjen dhe menaxhimin e komponentëve teknikë të

sistemit

- Sistemi mbikëqyrës duhet të ketë mbështetje për menaxhimin e ciklit jetësor dhe statusit të agjentëve

të konsolës qendrore administruese

- Sistemi mbikëqyrës duhet të ketë mbështetje për zbulimin e komponentëve në rrjet dhe aksesin e

tyre në sistemin mbikëqyrës

- Sistemi mbikëqyrës duhet të mundësojë grumbullimin e resurseve në grupe.

- Sistemi mbikëqyrës duhet të mundësojë ndarjen e akeseve për përdoruesit dhe grupet.

IX. ANALIZA E BIZNESIT

Të dhenat analitike te biznesit (Business Analytics) është platformë analitike e cila i mundëson

organizatës të analizojë probleme të ndryshme të biznesit, pothuajse përmes secilës pajisje.

Përdoruesve u sigurohet akses i lehtë dhe analizë e të dhënave nga burime të ndryshme, aftësi për të

kryer analiza inteligjente, shpërndarje efikase dhe shkëmbim informacionesh brenda organizatës, si

dhe pasqyrë gjithëpërfshirëse në biznes, me qëllim rritjen e performancës së proceseve të organizatës.

Komponentët e softuerit për analizë të biznesit mund të përdoren në serverët X86 për të siguruar

redundancë harduerike të komponentëve të shtresës aplikative. Në këtë rast, disponueshmëria e lartë

dhe konfigurim i klasterizuar ”aktiv-pasiv“ dhe „aktiv-aktiv“ i komponentëve softuerik për analizë të

biznesit, nuk është e nevojshme.

Licencë e vazhdueshme (perpetual) për mjedisin prodhues dhe atë testues si dhe shërbim të

mirëmbajtjes teknike

Platforma duhet të sigurojë mbështetje për zyrtarët të AT-së dhe Ministrisë së Financave të

Republikës së Shqipërisë

Në mbështetje të BA-së, është e mundur të integrohen të dhënat e ruajtura në databazë, dhe

të dhënat nga sistemet e transaksioneve

Faqe 87 nga 140

Mundësi për t’u lidhur njëkohësisht me burime të shumta të të dhënave si: të dhëna në format

XML, procedura të ruajtura, baza relacionale të të dhënave, baza shumëdimensionale të të

dhënave, burime Big Data dhe sisteme të optimizuara inxhinierike për baza të të dhënave

Burime të ndryshme dhe komplekse të të dhënave fizike grumbullohen në një model logjik të

kuptueshëm, domethënë model biznesi që është i lehtë për t'u përdorur nga përdoruesit e

organizatës. Gjithashtu, të gjithë komponentët e analitikes së biznesit mund të përdorin këtë

model të përbashkët të ”metadata-ve”

Shprehjet komplekse nga burimet fizike të të dhënave, përdoruesve të fundëm u paraqiten

përmes një terminologjie të lehtë dhe të kuptueshme

Përdoruesit fundore në BA e aksesojne përmes shfletuesit për internet (p.sh. Internet Explorer,

Firefox, etj)

Zgjidhja duhet të sigurojë API standarde për akses në modelin e metadata-ve

Mbështetje për "write-back", d.m.th. shkrim ose futje të të dhënave në bazë relacionale të të

dhënave nëpërmjet panelit të BA-së .

Funksione për seri kohore (p.sh. First Time Period, Year to Date, Year Ago, Month Ago, etj.)

Platforma, përkatësisht zgjidhja e ofruar duhet të ofrojë mbështetje për gjuhën programuese R,

për të mundësuar zgjerim të mjeteve analitike në BA.

Sistemi duhet të ofrojë union të pyetjeve për burime të ndryshme të të dhënave, d.m.th. pasqyrë

të të dhënave nga të gjitha burimet.

Përkthim automatik i pyetjes logjike në atë fizike.

Mundësi për të shtuar udhëzime të përshtatshme „online“ për të ndihmuar përdoruesit e panelit

kontrollues (dashboard) të ofrojnë përdorim më të thjeshtë dhe më të informuar të paneleve

dhe raporteve përkatëse

Mbështetje për sisteme të ndryshme operative si Linux, Unix dhe Windows.

Zgjidhja duhet t'u mundësojë përdoruesve të fundëm të shikojnë të dhëna nga burime të shumta

brenda një objekti të njëjtë (tabelës ose grafit) në raport. Shembull, brenda të njëjtës tabelë,

përdoruesit shikojnë të dhënat e shitjes që vijnë nga tabelat relacionale dhe të dhënat tekstuale

që vijnë nga të dhënat në OLAP ose Excel.

Mbështetje për nën-filtra. Shembull, përdoruesit mund të përdorin rezultatet e një raporti si filtër

për një raport tjetër.

Mbështetje për llogaritje analitike dhe funksione matematikore të tilla si ato për seri kohore

(time-series), „moving averages“, "weighted averages", "rolling sums", llogaritje kumulative,

përqindje në kolona e rreshta në raport me shumën e nivelit të hierarkisë etj.

Mundësi për përdoruesit për të ndërtuar raporte të reja dhe analizë nëpërmjet shfletuesit për

internet.

Mundësi për përdoruesit që në mënyrë interaktive nëpërmjet shfletuesit për internet të

përcaktojnë kritere për filtrimin e të dhënave.

Të gjithë përdoruesit mund të bëjnë „drill-down“ në nivel më të ulët në hierarki, si dhe të hapin

raporte të lidhura, panele, ueb faqe etj., dhe të gjithë këtë përmes shfletuesit për internet.

Mundësi për përdoruesit për të shtuar shprehje / llogaritje / shtylla logjike në raportin që

funksionon brenda shfletuesit për internet

Mundësi për të krijuar raporte të formatuara mirë për krijimin e formularëve dhe raporteve

zyrtare.

Mbështetje për funksionin "report bursting", d.m.th. aftësi për të dërguar përdoruesve ose

grupeve përdoruesish të ndryshëm vetëm pjesë të caktuara të një raporti.

Mundësi për të krijuar formate standarte (templates) që përdorin font, CSS. Këto mostra

përdoren për të siguruar pamje të qëndrueshme të raporteve të krijuara.

Analizë e udhëzuar me parametra përcjellës.

Të gjithë përdoruesit mund të zgjedhin parametra për filtrim të të dhënave, të rendisin dhe

analizojnë të dhënat në panel, të bëjnë „drill-down“, të filtrojnë të dhëna duke përdorur menutë

kontekstuale, të modifikojnë panelet ekzistuese dhe të krijojnë BA raporte si dhe panele të reja

Faqe 88 nga 140

Mundësi për të fshehur rresht ose pjesë të një raporti të krijuar. Shembull, nëse të gjitha njësitë

janë të barabarta me zero, rreshtat automatikisht janë të fshehur

Mundësi për të krijuar raporte financiare dhe menaxhuese të formatuara mirë

Raportet e krijuara mund të shpërndahen menjëherë, ose të planifikohet për t'u shpërndarë në

kanale të ndryshme në intervale të caktuara kohore.

Mundësi e kombinimit të të dhënave nga burime të ndryshme në një raport koheziv

Mbështetja për paraqitjen e të dhënave në hartë brenda panelit të BA-së.

Përdoruesit e fundëm nuk kanë nevojë të dinë burimin fizik të të dhënave për të krijuar analiza

ad-hoc, raporte dhe panele interaktive.

Përdoruesit e fundëm mund të krijojnë raporte pa pasur nevojë për programim

Përdoruesit mund të planifikojnë shpërndarjen e raportet dhe analizave të gatshme

Ndërfaqet e përdoruesit duhet të jenë të përcjellura me funksione „drag-and-drop“, „point-and-

click“ për të gjitha funksionet e duhura, përfshirë edhe krijimin e raporteve, sipas analizave

Përdoruesit të fundëm i paraqitet pamje logjike e të dhënave pa kompleksitetin e burimeve

heterogjene të të dhënave. Përdoruesi i fundëm nuk është e nevojshme të dijë vendndodhjen

e databazave fizike për të ardhur deri tek të dhënat relevante.

Nivel i shumëfishtë i sigurisë, d.m.th. mbështetje për llogaritë e përdoruesve, grupeve, roleve

aplikative etj.

Kufizimi i pyetjeve në nivel të përdoruesve, grupeve, roleve aplikative dhe burimeve të të

dhënave në mënyrë që administratori të mund të përcaktojë numrin maksimal të rreshtave që

përmban pyetja, si dhe kohën kur përdoruesi i caktuar, grupi i përdoruesve ose roli aplikativ

mund t'i qasen sistemit të BA-së.

Mbështetje e integruar për ndjekjen e aktiviteteve të përdoruesit, grupeve të përdoruesve ose

roleve aplikative.

Mundësi për të bërë kufizime të sigurisë për përdoruesit apo grupet e përdoruesve në nivel të

rreshtit, shtyllës, objektit (p.sh., dimensioneve) dhe nivelit të hierarkisë

Mundësi për të anashkaluar ekzekutimin e pyetjeve nëpërmjet ueb klientit

Përdoruesit mund të kufizohen duke u dhënë akses vetëm në të dhënat përkatëse

Nëpërmjet mjedisit vetë shërbyes (self-service), të gjithë përdoruesit e fundëm kanë të drejtë

të krijojnë raporte.

Sistem inteligjentë e shumë-përdorues për cash (caching).

Teknologjia BA duhet të ketë mundësi për cache të të dhënave në nivelin e serverit të

inteligjencës së biznesit dhe për ndarje të të dhënave cache nga përdorues të shumëfishtë.

Mundësi për administrim të përshtatshëm të cache-se për të parandaluar që të dhënat e cache-

se të mos jenë të vjetruara

Mbështetje për "multi-threading"

Të dhënat mund t'u dërgohet automatikisht përdoruesve në intervale kohore të dëshiruara ose

të paralajmërohen kur ndodh ndonjë ngjarje.

Paralajmërimet (alerts) mund të dërgohen tek përdoruesit ose grupet e përdoruesve.

Përdoruesit e fundor mund t'i ruajnë analizat e tyre, d.m.th. raportet, t'i planifikojnë ato për tu

ekzekutuar në mënyrë automatike, të vendosin kufijte dhe përcaktojnë se kush duhet të

paralajmërohet nëse pragu i përcaktuar tejkalohet

Suport për indikacione ndihmëse nëpër panel (dashboard)

Integrim me paketen Microsoft Office: Excel, PowerPoint dhe Word

Komponentët e avancuar për të ashtuquajturën "data discovery" duhet të ofrojnë mbështetje

për "data mashup", d.m.th. aftësia për përdoruesit e biznesit për të regjistruar burime të reja të

të dhënave (p.sh. file Excel, MS SQL Server, Oracle, DB2, Google Drive, Cassandra, ODBC,

JDBC dhe të tjerë) pa ndihmën e specialistëve të trajnuar të IT-së, t'i lidhin me "metadata“nga

sistemi BA, të krijojnë raporte dhe të analizojnë të dhëna.

Faqe 89 nga 140

Të gjitha mjetet e përdoruesit të fundëm (si panelet, raportet, analizat BI, mjetet për "data

discovery", etj.) mund të përdorin të njëjtën metadate, që shërben si burim i vetëm i të vërtetës

("single source of truth") për të gjitha mjetet e përdoruesve të fundëm

Përdoruesit e fundëm mund të krijojnë filtra përmes operacioneve "brushing".

Mjetet e avancuara për "data discovery", në kuadër të mjeteve BI, përfshijnë edhe funksionin

self-service ETL, i cili u mundëson përdoruesve të fundëm të lidhen direkt me burime të

ndryshme të të dhënave, t'i bashkojnë ato, të filtrojnë të dhënat hyrëse, të kryejnë transformime

të thjeshta, të kryejnë "data flows“ të tilla ose të bëjnë planifikimin e tyre për ekzekutim të

mëvonshëm.

Mbështetje për krijimin e grafeve me bosht të dyfishtë X dhe Y (shembull, një graf ka dy boshte

X dhe dy boshte Y)

IV. INTEGRIMI I TË DHËNAVE

Për të marrë vendime cilësore të biznesit, përdoruesit kanë nevojë për të dhëna të përditësuara dhe të

sakta të biznesit. Megjithatë, rritja e pakontrolluar e të dhënave çon deri në atë shkallë kur proceset

kyçe në organizata punuese bazohen në të dhëna të fragmentuara, të dyfishta, të vjetra, jo të plota dhe

kontradiktore, duke rezultuar kështu në njohuri të dobta në punën e organizatës.

Për të adresuar shtytje të tilla, përdoren teknologji për integrimin e të dhënave, të bazuara në arkitekturë

të hapur dhe të integruar E-LT (Extraction Load Transformation). Komponentët softuerik për integrimin

e të dhënave mund të përdoren gjithashtu në serverët X86 dhe platformat e në bazave të të dhënave.

Mbështetje për mënyra të ndryshme të integrimit të të dhënave, duke përfshirë, por pa u

kufizuar në:

o Mbështetje për lëvizje fizike të të dhënave në sasi të mëdha ndërmjet bazave të të

dhënave ("bulk data movement")

o Mbështetje për replikim të të dhënave ndërmjet skemave dhe bazave homogjene dhe

heterogjene të të dhënave

o Zgjidhja për integrim të të dhënave duhet të mbështesë teknologji të ndryshme të

integrim të cilat përfshijnë, por nuk kufizohen vetëm në:

o Mbështetje për ELT

o Mbështetje për ETL

o Mbështetje për Web serviset

Mbështetje për platforma të ndryshme: Windows, UNIX, Linux, Windows në platforma të

ndryshme harduerike

Është e rëndësishme që zgjidhja të jetë e zgjërueshme për të siguruar mbështetje të duhur në

rast të rritjes së vëllimit të të dhënave, përmasave apo frekuencës dhe kompleksitetit të procesit

të integrimit

Produkti u mundëson administratorëve të mbikëqyrin ngarkesën gjatë punës, performancën

dhe të marrin masa për përmirësimin e tyre

Instalimi i produktit për integrimin e të dhënave nuk kërkon pajisje harduerike shtesë dhe mund

të instalohet në të njëjtin server me bazën e të dhënave

Mbështetje për planifikim.

Mundësi për të përdorur komanda për baza specifike të të dhënave me qëllim permirësimin e

dukshëm përgjatë procesit të nxjerrjes dhe futjes së të dhënave dhe mundësi për operacione

komplekse me të dhëna, si përdorimi i trigerëve ose procedurave

Mundësi për "pushdown" dhe transformime në bazat e të dhënave që shërbejnë si burim i të

dhënave ose destinacion i të dhënave, me mundësi për përshtatje

Kodi i shkruar një herë, duke përfshirë këtu edhe logjikën e procesit dhe vetë punës, të ketë

mundësi të përdorimit të shumëfishtë

Faqe 90 nga 140

Mjeti për integrimin e të dhënave duhet të sigurojë mbështetje të fileve të sheshta (flat file)

përmes ndërmjetësuesit softuerik për JDBC, i cili ndihmon në konfigurimin e lidhjeve të shumta

për akses më të shpejtë

Mjeti duhet të ofrojë akses deklarative në dizenjimin e një sistemi për integrimin e të dhënave

që siguron zhvillim të shpejtë, fleksibilitet, lexueshmëri të sistemit, veçori të përdorimit të

shumëfishtë të komponentëve njëherë të krijuara, lehtësi në ndryshime dhe mirëmbajtje të

zgjidhjes në të ardhmen

Zgjidhja për integrimin e të dhënave duhet të vijë me mostra të gatshme të cilat mund të

përdoren për të kryer detyra specifike në integrimin e të dhënave përgjatë infrastrukturës.

Po ashtu, përmban koleksion të gatshëm të opsioneve paraprakisht të ndërtuara për

operacione të transformimit të të dhënave me kompleksitet të ndryshëm (konvertim të tipit të të

dhënave, manipulim me vargje shkronjash (strings), "lookups", operacione për zëvendësim e

grumbullim të dhënash etj.)

Mundësi për ndërveprim me burimet e të dhënave përmes një sërë adapterësh, duke përfshirë

por jo kufizuar në ODBC dhe JDBC.

Mbështetje për "multi-threading" dhe "multi-tasking"

Mundësi për përpunim paralel

Mbështetje për versionim

Licencuar për bazën e të dhënave DWH, atë prodhuese dhe testuese, në DWH Exadata me 8

"perpetual", "full use" licenca procesorësh

Certifikimi dhe mbështetja për platformat harduerike, sistemet operative dhe bazat e të dhënave

në DWH Exadata data warehouse.

5.7.4.3 Shtresa e të dhënave

Shtresa e të dhënave duhet të përbëhet nga dy sisteme të veçanta të bazave të të dhënave dhe lidhjes

me shtresën e ruajtjes së të dhënave i cili përdoret për krijimin e kopjeve (backup) të bazave të të

dhënave. Sistemet e bazave të të dhënave bazohen në shtrirjen e platformës ekzistuese të bazës së

të dhënave në AKSHI për të ruajtur investimet në harduer, softuer dhe resurse njerëzore, duke përdorur

kështu sisteme inxhinierike të optimizuara si Oracle Exadata dhe Oracle bazë të të dhënave dhe për

ngarkesa të transaksioneve punuese (OLTP) por edhe për depo të të dhënave dhe përpunim analitik

(DWH).

Është e domosdoshme të ofrohen dy sisteme fizike të ndara të bazës së të dhënave:

1. Sistem të bazës së të dhënave për përpunimin e transaksionit online (OLTP) që përmbajnë baza

të dhënash prodhuese (PROD) dhe testuese (TEST).

2. Sistem bazash të të dhënave për bazen e të dhënave dhe analitikë të biznesit (DWH) që

përmbajnë bazat e të dhënave prodhuese (PROD) dhe testuese (TEST) por edhe replikë të

qëndrueshme të bazave të të dhënave të transaksioneve prodhuese me bazat e të dhënave të

sistemit OLTP (STANDBY).

Sistemi i deponimit do të përdoret si zgjidhje për krijim kopjeve të shpejta të bazës së të dhënave OLTP

dhe DHW nga të dy sistemet Exadata.

Sistemi i bazave të të dhënave për përpunim online të transaksioneve (OLTP)

Sistemi i bazave të të dhënave për përpunim online të transaksioneve (OLTP) përbëhet nga një

instancë Oracle Exadata Database Machine të gjeneratës së re me softuer përkatës Oracle Exadata

Storage Server dhe Oracle Database.

Sistemi i bazave të të dhënave për OLTP do të përdoret për bazat e të dhënave prodhuese dhe

testimeve të transaksioneve.

Faqe 91 nga 140

I. HARDUERI ORACLE EXADATA DHE KËRKESAT SOFTUERIKE TE SISTEMIT

Harduer i ridhe me softin perkates n

Disponueshmëri e lartë dhe redundancë e komponentëve harduerik pa asnjë mundësi të vetme

për dështim (no single point of failure), të cilat mund të ndikojnë në sistem në tërësi

Arkitekturë e zgjërueshme e sistemit që duhet të mundësojë rritje të ngarkesën punuese dhe

zgjerim të konfiguracionit dhe burimeve harduerike për tu shmangur pikave të dobëta në

performancë

Harduer i ri, i papërdorur më parë dhe me mbështetje për versionin e softuerit sistemor


për dështim (en. no single point of failure), të cilat mund të ndikojnë në sistem si tërësi



performancë

Licenca të përhershme/vazhdueshme (perpetual)

Pajisjet fizike duhen dorezuar , instaluar dhe konfiguruar në DataCenterin Qeveritar

II. SOFTUERI ORACLE PËR BAZA TË TË DHËNAVE

Oracle Database 12c Enterprise Edition - licenca të përhershme për 8 procesorë (full use

perpetual license), për numër të pakufizuar të përdoruesve dhe një vit mbështetje teknike me

të drejtë për versione dhe përditësime të reja

I instaluar dhe konfiguruar në OLPD Exadata për databazat prodhuese dhe ato testuese

Baza e të dhënave Oracle e implementuar dhe konfiguruar në klaster aktiv – aktiv për të

siguruar disponueshmëri të lartë. Të dy serverët e bazës së të dhënave Exadata lexojnë dhe

shkruajnë njëkohësisht në një bazë të vetme dhe të përbashkët të dhënash, në sistemin e

deponimit Exadata në mënyrë transparente për aplikacione (pa nevojë të përshtatjes së kodit

aplikativ)

Përfshirë këtu kompresimin dhe deduplikimin e të dhënave të pastrukturuara (teksteve,

fotografive) si dhe kompresimin e të dhënave të transaksioneve dhe indekseve gjatë

operacioneve të manipulimit me të dhëna (DML) siç janë futja dhe përditësimi me ngarkesë

minimale në performancë

Përfshirë ndarjen e tabelave të bazës së të dhënave dhe indekseve në objekte ose pjesë më

të vogla që të mund tu qaset dhe menaxhohen në mënyrë të pavarur, për të përmirësuar

performancën, disponueshmërinë e të dhënave dhe menaxhueshmërinë, plotësisht në mënyrë

transparente për aplikacione (nuk ka nevojë për përshtatje të kodit aplikativ).

Përfshirë maskimin dinamik të të dhënave konfidenciale të paraqitura, bazuar në kontekst të

sesioneve të përdoruesve dhe enkriptimin e të dhënave konfidenciale në sistemet e ruajtjes së

të dhënave, në mënyrë transparente për përdoruesit e bazës së të dhënave dhe aplikacionit

me sistem të integruar të menaxhimit përmes çelësave

Përfshirë mjetet grafike të integruara për mbikëqyrje automatike, menaxhim dhe diagnostikim

të bazave të të dhënave Oracle dhe platformave Exadata në kohë reale, raportim mbi

disponueshmërinë dhe performancën por dhe depo të centralizuar të të dhëna të performancës

së sistemit.

Përfshirë mjetet grafike ueb, të integruara për përshtatje automatike të kodit SQL dhe

ekzekutimin e mbikëqyrjen e tij në kohë reale (real-time SQL monitoring)

Zbatim dhe ruajtje të sinkronizuar automatikike të kopjet të të gjitha bazave të të dhënave OLTP

në sistemin DWH Exadata në qendrën primare të të dhënave me qëllim të mbrojtjes së bazave

prodhuese të të dhënave OLTP nga rënia, gabimet njerëzore e korrupsioni dhe rritja e

disponueshmërisë. Bazat e të dhënave standby të ndërtuara mbi DWH Exadata duhet të jenë

në gjendje të përdoren për raportim, krijim të kopjeve backup dhe operacione për lexim, por në

Faqe 92 nga 140

të njëjtën kohë duke u përditësuar me ndryshimet që vijnë nga transaksionet në bazat e të

dhënave prodhuese OLTP dhe për përmirësim të të dhënave nga problemet fizike në mënyrë

transparente për përdoruesit.

III. SISTEMET E BAZAVE TË TË DHËNAVE PËR RUAJTJEN E TË DHËNAVE DHE ANALIZË

TË BIZNESIT (DWH)

Sistemi i bazave të të dhënave për ruajtjen e të dhënave dhe analizë të biznesit (DWH) përbëhen nga

një Oracle Exadata Machine i gjeneratës së fundit me softuer përkatës - Oracle Exadata Storage Server

dhe Oracle Database.

Sistemi i bazës së të dhënave DWH do të përdoret për baza prodhuese dhe testuese të të dhënave

DWH dhe po ashtu për kopje (replika) të qëndrueshme të transaksioneve të bazës së të dhënave OLTP

nga sistemi OLED Exadata.

IV. HARDUERI ORACLE EXADATA DHE SISTEMI SOFTWARE

Harduer i ri, i papërdorur më parë me mbështetje te version të fundit të softuerit


për dështim (no single point of failure), të cilat mund të ndikojnë në sistem si tërësi



performancë

Licenca të përhershme (perpetual)

I dorëzuar, instaluar dhe konfiguruar në qendrën primare të prodhimit të të dhënave

V. SOFTUERI ORACLE DATABASE

Oracle Database 12c Enterprise Edition - licenca të përhershme për 8 procesorë (full use

perpetual licencec), për numër të pakufizuar të përdoruesve.

I instaluar dhe konfiguruar në DWH Exadata për bazat e të dhënave prodhuese dhe atyre

testuese por dhe për kopjene qëndrueshme të transaksioneve OLTP të bazave prodhuese të

të dhënave

Baza e të dhënave Oracle e implementuar dhe konfiguruar në klaster aktiv – aktiv për të

siguruar disponueshmëri të lartë. Të dy serverët e bazës së të dhënave Exadata lexojnë dhe

shkruajnë njëkohësisht në një bazë të vetme dhe të përbashkët të dhënash, në sistemin e

deponimit Exadata në mënyrë transparente për aplikacione (pa nevojë të përshtatjes së kodit

aplikativ)

Përfshirë këtu kompresimin dhe deduplikimin e të dhënave të pastrukturuara (teksteve,

fotografive) si dhe kompresimin e të dhënave të transaksioneve dhe indekseve gjatë

operacioneve të manipulimit me të dhëna (DML) siç janë futja dhe përditësimi me ngarkesë

minimale në performancë

Përfshirë ndarjen e tabelave të bazës së të dhënave dhe indekseve në objekte ose pjesë më

të vogla që të mund tu qaset dhe menaxhohen në mënyrë të pavarur, për të përmirësuar

performancën, disponueshmërinë e të dhënave dhe menaxhueshmërinë, plotësisht në mënyrë

transparente për aplikacione (nuk ka nevojë për përshtatje të kodit aplikativ).

Përfshirë maskimin dinamik të të dhënave konfidenciale të paraqitura, bazuar në kontekst të

sesioneve të përdoruesve dhe enkriptimin e të dhënave konfidenciale në sistemet e ruajtjes së

të dhënave, në mënyrë transparente për përdoruesit e bazës së të dhënave dhe aplikacionit

me sistem të integruar të menaxhimit përmes çelësave

Përfshirë mjete grafike të integruara për mbikëqyrje automatike, menaxhim dhe diagnostikim

të bazave të të dhënave Oracle dhe platformave Exadata në kohë reale, raportim mbi

Faqe 93 nga 140

disponueshmërinë dhe performancën por dhe depo të centralizuar të të dhënave mbi

performancën e sistemit.

Përfshirë mjete grafike ueb të integruara për përshtatje automatike të kodit SQL dhe

ekzekutimin e mbikëqyrjen e tij në kohë reale ( real-time SQL monitoring)

Zbatim dhe ruajtje e sinkronizuar automatikike e kopjet të të gjitha bazave të të dhënave OLTP

në sistemin DWH Exadata në qendrën primare të të dhënave me qëllim të mbrojtjes së bazave

prodhuese të të dhënave OLTP nga rënia, gabimet njerëzore e korrupsioni dhe rritja e

disponueshmërisë. Bazat e të dhënave standby të ndërtuara mbi DWH Exadata duhet të jenë

në gjendje të përdoren për raportim, krijim të kopjeve backup dhe operacione për lexim, por në

të njëjtën kohë duke u përditësuar me ndryshimet që vijnë nga transaksionet në bazat e të

dhënave prodhuese OLTP dhe për përmirësim të të dhënave nga problemet fizike në mënyrë

transparente për përdoruesit.

5.7.4.4 Shtresa për ruajtjen e të dhënave

Shtresa për ruajtjen e të dhënave është bazë për ndarjen/shpërndarjen e të dhënave në nivel të rrjetit,

element themelor i të cilës është sistemi për ruajtje. Shtresa për ruajtjen e të dhënave përdor elemente

nga shtresa themelore, shtresa e të dhënave e ndoshta edhe nga sisteme tjera partnere.

I. SISTEMI PËR RUAJTËN E TË DHËNAVE (DEPONIM)

Element themelor i Shtresës për ruajte të të dhënave është sistem ruajtjes (storage system). Sistemi

për ruajtën e të dhënave është i gjithë hardueri dhe softueri që mundëson një rrjet të përbashkët për

ruajtjen e të dhënave. Sistemi i ruajtjeparashikon realizimin e komponentit fizik PN_SharedStorage i cili

siguron disponueshmëri të lartë dhe akses të përshtatshme të të dhënave përmes rrjetit nga grup

klientësh heterogjen.

Qëllimi kryesor i shtresës për ruajte është::

1) Ruajtja e kopjeve të bazave të të dhënave OLTP dhe DWH

2) Ruajtja e dokumenteve të ndryshme nga shtresa aplikative

3) Ruajtja e të dhënave për mbështetje të teknologjisë virtualizuse në Shtresën themelore

Sistemi për ruajtje përdoret për mjedisin prodhues dhe atë testues, duke marrë parasysh përvojën e

mirë të izolimit mjedisor.

5.8 Kërkesa të tjera

5.8.1 DWH

Për të ofruar me të vërtetë informacion në mënyrë te përhapur, kërkohet një platforme për menaxhimin

e informacionit, e cila duhet të jetë në gjendje të ngarkojë, transformojë, integrojë dhe kërkojë të dhëna

në të njëjtin nivel saktësie dhe të ketë disponueshrneri të larte siç pritet nga çdo sistem tjetër operativ.

Me vëllimet gjithnjë në rritje të të dhënave dhe me kërkesat më të thella për analizë, gjithashtu rrjedh

se një platformë e menaxhimit të informacionit duhet të jetë në gjendje të shkallëzohet për të

përmbushur kërkesat e ardhshme dhe për të menaxhuar ciklin e jetës së informacionit, për të ulur kostot

dhe krijuar një platforme reale dhe te sigurt.

Për të përdorur në mënyrë efikase këto sfida, nevojitet përdorim i platformave të Data Warehouse (DW)

dhe Business Intelligence (BI).

Faqe 94 nga 140

Inxhinieria softuerike për analizën e punës nuk është e ndryshme nga softuerët inxhinierik tradicional,

por disa hapa mund të jenë të nevojshëm për të siguruar që janë teresisht në përputhje me praktikat

më të mira. Këto hapa mbështesin variacionet në SDLC (software development life cycle) të tilla si:

Kërkesat dhe dizenjimi duhet të shqyrtohen nga pikëpamja analitike dhe informative. Këto

këndvështrime mund të jenë disi të ndryshme nga njeri-tjetri.

Ndarja e punës ndërmjet përdoruesve fundor dhe stafit të TI-së. Projektet tradicionale shpesh

kryhen tërësisht nga stafi i TI-së, ndërsa zgjidhjet analitike mund të krijohen nga përdoruesit

fundor.

Një ekzaminim i shërbimeve ekzistuese për të përmbushur disa nga nevojat e informacionit ose

analizës së të dhënave ose burimeve të të dhënave. Anasjelltas, një vlerësim i kërkesave për të

përcaktuar nëse të dhënat duhet të zhvillohen për ripërdorimin e aseteve në projektet e

ardhshme.

Hapat për të arkivuar të dhënat dhe ripërdorimin e analitikes dhe / ose aseteve të informacionit

nëpër projekte.

Modeli dimensional është një metode e standardizimit dhe organizimit të të dhënave në një mënyrë që

përfaqëson hierarkinë e punës. Për shembull, një inspektor tatimor punon në një zonë e cila është pjesë

e Drejtorisë Rajonale Tatimore. Po ashtu, një tatimpagues mund t’i përkasë një lIoji të biznesit, i cili nga

ana tjetër mund t'i përkasë një tipi të nivelit më të lartë të grupit të biznesit. Secila nga këto dy hierarki

është konsideruar si një dimension. Ngjarjet e biznesit mund të lidhen me disa dimensione të ndryshme.

Për shembull, një faturë që lëshohet mund të lidhet me dimensionet që përfaqësojnë faturën e

tatimpaguesit, vendndodhjen dhe kohën. Ngjarja ose matja e asaj që ndodh quhet fakt. Faktet

përgjithësisht ruhen në tabela që lidhen me tabelat e dimensioneve nëpërmjet një koleksioni të foreign

keys.

Prandaj kërkohet data warehouse e centralizuar e të dhënave që ofron një pike të vetme të menaxhimit

të të dhënave historike. Kjo mund të zbatohet në mënyrë graduale, por të gjitha të dhënat menaxhohen

në një data warehouse të vetme. Të dhënat grumbullohen nga sistemet operative në një vend të

përkohshëm. Pasi grumbullohen dhe pastrohen të gjitha të dhënat e lidhura, warehouse rifreskohet,

ndërsa azhornimi mund të kryhet në ritme të ngadalta ose të shpejta.

Të dhënat historike dhe të versioneve do të trajtohen në data warehouse. Përdorimi i një sistemi DBMS

të vetëm ndihmon në promovimin e qëndrueshmërisë së të dhënave të strukturuara duke eliminuar

nevojën për te zbatuar në mënyrë manuale konformitetin në të gjithë të dhënat e shumëfishta.

Gjithashtu ndihmon në reduktimin e kompleksitetit duke eliminuar shumë nga shqetësimet e integrimit

që mund t'i atribuohen të dhënave të mbledhura.

Në mënyrë që të mbledhim, analizojmë dhe krahasojmë të dhënat me te dhënat transaksionale,

nevojitet Big Data në mënyrë që të dhënat të mund të përpunohen në një mënyrë të tillë që i bën ato të

përputhshme me të dhënat e strukturuara. Mënyra teknike e zakonshme është që të filtrojë dhe të

zvogëlojë grupin e Big Data në një grup shumë më të vogël të të dhënave që mund te kombinohen ose

lidhen me të dhëna të strukturuara. Qëllimi është të nxjerrim atë që konsiderohet e dobishme, e

vlefshme dhe e identifikueshme. Duke qenë të identifikueshme, të dhënat kanë aftësinë për t’u lidhur

me format e tjera të të dhënave. Duke qenë të dobishme dhe të vlefshme, të dhënat konsiderohen me

vlerë të larte si të dhëna që duhen menaxhuar për një kohë afatgjate. Pasi të kryhet ky korrelacion,

analiza mund të kryhet në lloje të ndryshme të të dhënave duke përdorur një serë mjetesh.

Detyrat për analizën e punës:

Përcaktimi i kërkesave

o Të dhënat analitike

Faqe 95 nga 140

o Kërkesa e informacionit

Zgjidhje për analizën dhe dizenjimin

o Analiza e lntegrimit

o Analiza e shërbimeve të të dhënave

o Arkitekture konceptuale

Ndërtimi

o Modelimi i informacionit

o Zhvillimi i zgjidhjeve

o Zhvillimi i shkëmbimit të të dhënave

o Trajnimi për përdoruesit

Tranzicioni

o Testimi i QA

o Testimi i performancës

o Testimi i integrimit

5.8.2 INTELIGJENCA E BIZNESIT DHE ANALITIKA E BIZNESIT

Platforma e analitikes fuqizon gjithë organizatën dhe mundëson parashtrimin e pyetjeve për çdo të

dhënë në çdo ambient dhe në çdo pajisje. Ajo gjithashtu ofron një sërë mundësish për analiza

inteligjente, duke e bërë atë një mënyrë efektive për të përfshirë më shumë njerëz në analizë dhe për

të zgjeruar ekspertizën e organizatës.

Suite BI duhet të përbëhet nga disa produkte që mund të përdoren së bashku ose në mënyrë të pavarur:

BI Server: model i zakonshëm i punës me shtresë të abstraksionit që gjeneron çështje të

përshtatura për secilin burim të të dhënave, i agregon ato dhe i paraqet rezultatet e përdoruesve

brenda një shfletuesi të njohur Ueb përmes paneleve të lehtë për t’u përdorur dhe për të

raportuar. BI Server duhet të përfshijë gjithashtu mjetet e ekzekutimit paralel të çështjeve,

menaxhimin e kujtesës dhe lidhjes së të dhënave me kapacitet të lartë për të lejuar burime dhe

agregime të të dhënave në mënyrë efikase që minimizojnë kohën e rikthimit të të dhënave. Kjo

platformë shumë e shkallëzuar me aftësitë grumbulluese dhe kapëse është zemra e asaj që

drejton komponentët e tjerë të suitës.

BI Interactive Dashboards: shumë ndërveprues, 100% panel i informacioneve (dashboards) që

i ofrojnë përdoruesve informacion të filtruar dhe të personalizuar për identitetin e tyre, funksionin,

ose rolin bazuar në rregullat e përcaktuara të sigurisë. Ndërfaqja e pasur dhe interaktive e bën

prezantimin e të dhënave intuitive, relevante dhe të kuptueshme. Si rezultat, përdoruesit

udhëhiqen për të marrë vendime të informuara dhe efektive që rrisin performancën e gjithë

organizatës.

Duhet të mbështesë monitorimin dhe alarmimin e aktivitetit në mënyrë proaktive. Ky sistem

sinjalizuesduhet të nxisë rrjedhat e punës në bazë të ngjarjeve të biznesit dhe të njoftojë palët e

interesuara nëpërmjet mesazhit dhe kanalit të tyre të preferuar pothuajse ne kohe reale

Duhet të mundësojë raportimin dhe shpërndarjen e raporteve të përsosura në hollësi. Duhet të

lejojë krijimin e shablloneve (templates), raporteve dhe dokumenteve me format të lartë. Është

zgjidhja më efektive dhe më e shkallëzuar e raportimit e disponueshme për mjedise komplekse

dhe të shpërndara. Siguron një arkitekturë qendrore për gjenerimin dhe dhënien e informacionit

në mënyrë të sigurt dhe në formatin e duhur. Më e bukura e kësaj është se përdoruesit mund të

punojnë me mjete të njohura si Microsoft Word ose Adobe Acrobat për paraqitjen e raporteve.

Vizualizimi i të dhënave: siguron aftësi analitike të vetë-shërbimit, të dhëna “grumbulluese” dhe

të dhëna “kontradiktore”. Përdoruesit thjesht mund të lidhen me numrin e burimeve të ndryshme

të të dhënave, duke përfshirë dokumentet Excel, tabelat krahasuese dhe të dhëna të tjera të

mëdha, të ngarkojnë dhe përziejnë të dhënat, pa ndonjë modelim të duhur ashtu që kryejnë

ndonjë analizë të shpejtë e cila është në dispozicion të secilit në organizatë. Të dhënat

Faqe 96 nga 140

prezantohen duke përdorur vizualizime mahnitëse dhe lehtë për t’u krijuar - zgjidh dhe kliko.

Vizualizimi i të dhënave gjithashtu mundëson përzierjen e të dhënave personale me të dhënat e

menaxhuara.

Faqe 97 nga 140

6 LOGJISTIKA DHE KOHA

6.1 Vendodhja

AKSHI, Tiranë

6.2 Data e fillimit dhe periudha e zbatimit të detyrave

Data e fillimit të projektit është data e nënshkrimit të kontratës, ndërsa periudha e implementimit të

kontratës do të jetë 24 muaj, duke filluar nga ajo datë dhe 2 vjet mirëmbajtje

Faqe 98 nga 140

7 TESTIMI DHE SIGURIMI I CILËSISË

7.1 Testimi para shkarkimit

Përveç testimit standard nga ofertuesi dhe testimit të konfiguracionit, ofertuesi (me ndihmën klientit)

duhet të kryejë testimin e sistemit dhe të nënsistemit para se të konsiderohet se instalimi është kryer

dhe se klienti do të lëshojë Certifikatën e instalimit

Sistemi i plotë: Testimi i para-shkarkimit për të gjithë sistemin e përgjithshëm përfshin aktivitetet e

mëposhtme:

1) përgatitja për testim.

2) kryerjen e testimit të sistemit.

Kushtet: të dhënat e testimit.

Kriteret e suksesit: të gjitha testet janë kaluar me sukses

7.2 Qëllimi

Qëllimi i testit është të kontrollojë nëse komponentët individualë të sistemit që kanë kaluar me sukses

testimin e proceseve individuale dhe testimin e integrimit gjatë fazës së zhvillimit:

Plotësojnë kërkesat funksionale;

Plotësojnë nevojat e DPT-ës;

Përputhen me të gjitha detyrimet, kufizimet fizike dhe marrëveshjet për nivel shërbimesh; dhe

Funksionojnë siç përshkruhet në Udhëzimet e përdoruesit dhe në manualin me udhëzime për

punë.

7.3 Kriteret e futjes

Para fillimit të Fazës së integrimit dhe testimit, i gjithë sistemi duhet të jetë gati për aktivizimin dhe

testimin e integrimit. Kjo nënkupton:

Të gjithë komponentët e konfigurimit të softuerëve dhe pajisjeve janë të gatshme dhe testohen

me sukses.

Të gjitha planet e testimit integrues janë përgatitur.

Është përgatitur një plan kalimi në sistem lëshimi për të dhënat ekzistuese dhe proceset që do

të ripërdoren.

7.4 Proces / Procesi

Gjatë kësaj faze duhet të kryhen testime të hollësishme për të siguruar që zgjidhja e zhvilluar të

plotësojë kërkesat e përcaktuara në specifikimin e kërkesave funksionale. Gjatë fazës së testimit do të

kryhen disa lloje të testeve.

1) Së pari, testimi i nënsistemit të integruar do të kryhet dhe vlerësohet si dëshmi se komponentët

e programit janë integruar siç duhet në nënsisteme dhe se nënsistemet janë integruar siç duhet

në sistem.

2) Pastaj, vazhdon vlerësimi i sistemit për të siguruar që sistemi i zhvilluar të plotësojë të gjitha

kërkesat teknike, duke përfshirë kërkesat e performancës.

3) Pas kësaj, testimi i sigurisë duhet të kryhet për të verifikuar përputhjen me kërkesat e sistemit sa

i përket futjes në sistem dhe sigurinë e të dhënave

4) Në fund, përdoruesit marrin pjesë në testimin e përshtatshmërisë për të konfirmuar se sistemi i

zhvilluar i plotëson të gjitha kërkesat e përdoruesit. Testimi i përshtatshmërisë do të zhvillohet në

një mjedis përdorues të simuluar të "vërtetë" ku përdoruesit do të përdorin platforma të simuluara

ose platforma reale të synuara dhe infrastruktura.

Faqe 99 nga 140

7.5 Përgatitja për testim

Ofertuesi do të përgatisë një ambient testues, do të krijojë dhe ngarkoj bazën/at testuese së të dhënave

dhe një përgatitje eventuale e programit që simulojnë përdoruesit ose sistemet e jashtëm.

7.6 Zbatimi i testimit të sistemit

Të gjitha komponentët që janë të reja, të ndryshuara, të prekura ose të kërkuara për të arritur aplikimin

e përgjithshëm, i nënshtrohen testimit për të verifikuar funksionimin e tyre të duhur, duke siguruar që

sistemi po vepron në përputhje me specifikimet e kërkesave funksionale. Gabimet ndodhin, ato

korrigjohen dhe testohen përsëri. Ky proces vazhdon derisa të plotësohen kriteret e daljes në vijim:

Sistemi i plotëson të gjitha kërkesat e dokumentuara të biznesit dhe kërkesat funksionale;

Nuk ka mangësi që do të ishin me rëndësi kritike dhe përbënin pengesë për kalimin në testimin

e Integrimit; dhe

Të gjitha palët relevante kanë miratuar testet e kryera.

Testimi i pranueshmërisë operative.

7.7 Testimi i pranueshmërisë operacionale

Pas instalimit, autoriteti kontraktues, DPT dhe MFE (me ndihmën e ofertuesit) do të kryejë testet e

mëposhtme të sistemit për të përcaktuar nëse sistemi i plotëson të gjitha kërkesat e nevojshme për

pranueshmërinë operacionale:

5) testimi i integrimit

6) testimi i përshtatshmërisë nga përdoruesi.

Sistemi i përgjithshëm: Testimi i para-shkarkimit për tërë sistemin përfshin testimin e integrimit dhe

testimin e pranimit të përdoruesit. Nëse të dhënat aktuale nuk janë të disponueshme, duhet të përdoren

të dhënat e testimit.

7.7.1 ZBATIMI I TESTIMIT TË INTEGRIMIT

Procesi i testimit të integrimit verifikon nëse sistemi duhet të ndërveprojë me sistemet dhe aplikacionet

e tjera, duke përfshirë ato në pronësi të ofruesve të jashtëm, partnerëve ose klientëve. Meqë testimi i

integrimit duhet t'i nënshtrohet validimit të kërkesave funksionale dhe jo funksionale, është e mundur të

kryhen disa lloje të testimeve, duke përfshirë:

Testimi i përputhshmërisë që siguron që sistemi të funksionojë siç duhet me sistemet e tjera të

konfiguruara bazuar në ato që përdoruesit posedojnë ose mund të kenë. Për shembull, tek testimi

i ueb faqeve ky nënkupton testimin e pershtatjes me shfletues të ndryshëm dhe shpejtësitë e

lidhjeve.

Testimi i performancës verifikon shkallëzimin e sistemit. Kjo është veçanërisht e rëndësishme

kur përcaktohet pikat e dobeta (bottlenecks) në aplikimet me frekuencë të lartë të përdorimit.

Testimi nën presion vlerëson performancën e sistemit me ngarkesa të simuluara që janë më të

larta se normale. Vendosja e një sistemi ose aplikimi nën një barrë të tillë do të thotë se ata

punojnë përtej kufijve të kërkesave të tyre specifike, ka për qëllim të përcaktojë shkallën në të

cilën ato bëhen të pasuksesshme dhe si manifestohen. Testimi i tillë është padyshim prova më

e rëndësishme për sistemet kritike.

Testimi i ngarkesës vlerëson sjelljen e sistemit në kushte "normale" të sistemit në prodhim

(production) dhe mat kohën e reagimit për transaksionet kritike ose proceset për të përcaktuar

nëse ato janë brenda kufijve të përcaktuar në kërkesat e biznesit dhe dokumentacionin e fazës

së projektimit, p.sh. marrëveshjet në nivel shërbimi..

Faqe 100 nga 140

Me shfaqjen e gabimeve, ato korrigjohen dhe testohen përsëri. Ky proces vazhdon derisa të plotësohen

kriteret e daljes në vijim:

Të gjitha sistemet e përfshira kanë kaluar testimin e integrimit dhe plotësojnë kërkesat

funksionale të rëna dakord dhe kërkesat e performancës;

Identifikohen dhe dokumentohen humbjet e mbetura dhe i paraqiten klientit

Me rezultate të kënaqshme kryhen testimi nën presion, testimi i performancës dhe testimi i

ngarkesës;

Plani i implementimit është në fazën përfundimtare; dhe

Mbahet një mbledhje mbi kalimin e testimit, pranohet të gjitha nënshkrimet.

7.7.2 ZBATIMI I TESTIMIT TË PRANUESHMËRISË NGA ANA E PËRDORUESIT

Testimi i pranueshmërisë nga ana e përdoruesit (UAT) do të kryhet para se klienti të marrë sistemin e

ri. TPP do të zbatojnë përdoruesit aktual të sistemit. E njëjta do të bazohet në specifikimet që kanë

ndodhur gjatë Fazës së dizenjimit, domethënë që kanë dalë nga nevojat origjinale të biznesit. Në

qendër të testit do të jetë kontrolli përfundimtar i funksionit të kërkuar të biznesit dhe funksionimit të

sistemit.

Testet do të kryhen në një mënyrë që simulon përdorimin aktual të sistemit, qëllimi është të verifikojë

(dhe të tregojë për përdoruesit) nëse sistemi funksionon në një mënyrë që është e mundshme dhe pa

probleme gjatë përdorimit standard. Rezultatet e testeve të tilla do t'i mundësojnë klientit dhe ofertuesit

të fitojnë besim në sistem, që do të thotë që sistemi të funksionojë ashtu siç është projektuar.

7.8 Sigurimi i cilësisë

Ofertuesi, në përputhje me kërkesat e projektit në kuptim të monitorimit të cilësisë së zhvillimit të

sistemit, do të përgatisë një plan të cilësisë. Plani i cilësisë së projektit do të përgatitet në përputhje me:

standardet dhe procedurat që do të zbatohen në secilën fazë;

kriteret e hyrjes në, d.m.th. dalja nga secila fazë;

verifikimet, testimet dhe validimet që do të kryhen;

planifikimin e verifikimit, testimit dhe vlefshmërinë, duke përfshirë orarin e aktiviteteve, burimeve

dhe organeve autorizuese për dhënien lejeve; dhe përgjegjësi të veçanta në aspektin e cilësisë.

Faqe 101 nga 140

8 RAPORTIMI

8.1 Kërkesat e raportimit

Kontraktuesi do të paraqesë raportet e mëposhtme në gjuhen shqipe dhe angleze në origjinal dhe në

formë elektronike:

Raporti Fillestar prej maksimumi 12 faqesh duhet të hartohet pas një jave nga fillimi i zbatimit.

Në raport kontraktuesi duhet të përshkruajë gjetjet fillestare, progresi në mbledhjen e të dhënave,

vështirësitë e hasura, përveç programit të punës apo udhëtimeve të stafit. Kontraktuesi duhet të

vazhdojë me punën e tij / saj derisa Autoriteti Kontraktues të dërgojë komente mbi raportin

fillestar.

Raporti Përfundimtar do të shoqërohet me të njëjtat specifika si drafti i raportit përfundimtar, i cili

do të përmbajë komentet e pranuara nga palët në draft raport. Afati i fundit për dërgimin e raportit

përfundimtar është 30 ditë pas marrjes së komenteve në draft raportin përfundimtar. Raporti

duhet të përmbajë një përshkrim mjaft të hollësishëm të opsioneve të ndryshme që ndihmojnë

në marrjen e një vendimi të saktë. Analizat e hollësishëm që i mbështesin rekomandimet do të

paraqiten në shtojca në raportin kryesor. Raporti përfundimtar duhet të dërgohet së bashku me

faturën përkatëse.

8.2 Dorëzimi dhe miratimi i raporteve

Raporti i përmendur më sipër duhet t’i dorëzohet Menaxherit të Projektit të identifikuar në kontratë.

Menaxheri i Projektit është përgjegjës për aprovimin e raporteve.

Faqe 102 nga 140

9 KOMUNIKIMI ME SISTEMET TJERA

Me qëllim që sistemi të krijohet jo vetëm me institucionet që tashmë kanë sisteme elektronike, por edhe

me institucione të tjera që ende nuk i kanë ato, duhet të ndërtohet një sistem për t'u lidhur me

komponentin DIS (Department Integration Server) të ESB (Enterprise Service Bus). Kjo do të

mundësonte shkëmbimin e informacionit me palët e treta.

Çdo marrëdhënie me projektet ose ndërfaqet e sistemeve të tjera të të njëjtit institucion apo

institucioneve të tjera duhet të përfshihet në këtë projekt, veçanërisht:

Për pagesat në para të gatshme

o Me një listë të certifikatave të revokuara

o Komunikimi me sistemin që ka një numër unik të subjekteve afariste

Për BI dhe analizën e riskut

o Lidhja me sistemin e informacionit të TA-së

Për pagesat pa para të gatshme

Integrimi me ofruesit e-Faturave elektronike

Komunikimi i sistemit nga ky dokumentacion me sistemet tjera në Republikën e Shqipërisë nënkupton

aksesi në të dhënat ekzistuese me qëllim të krijimit të një interoperabiliteti ndërmjet sistemeve.

Komunikimi do të zhvillohet përmes shërbimit XML dhe si kriter të përbashkët do të ketë numrin

identifikues të tatimpaguesit. Ky sistem do të mundësojë shikim të të dhënave të tatimpaguesit nga

regjistrat tjerë si dhe dërgim të të dhënave tatimore për tatimpaguesit në sistemet tjera.

Projekti duket të ofrojë komunikim me regjistrat në vijim:

• Regjistri Kombëtar i Klasifikimit të Veprimtarive të Republikës së Shqipërisë (Kodi Nace)- QKB

• Regjistri i Bizneseve të Republikës së Shqipërisë (eRegjister) – Qendra Kombëtare e Biznesit

• Sistemi elektronik për menaxhimin e kontributeve - Instituti i Sigurimeve Shoqërore

• Regjistri i të Siguruarve - Fondi i Sigurimit të Detyrueshëm të Kujdesit Shëndetësor

• Regjistri Kombëtar i Gjendjes Civile - Drejtoria e Përgjithshme e Gjendjes Civile

• Regjistri i subjekteve të licencuara – Banka e Shqipërisë

• Regjistri i Organizatave Jofitimprurëse - DPT

• Regjistri i Gjykatave të Republikës së Shqipërisë – Ministria e Drejtesise

• Asycuda World - Dogana e Republikës së Shqipërisë

• Me sistemet e brendeshme do te kete komunikim direkt kurse me institucionet e tjera do te

kalohet me ane te ws npm ESB.

Faqe 103 nga 140

10 GARANCIA

10.1 Garancia

Kontrata duhet të përfshijë llojet e garancive në vijim:

Garantimi për respektimin e afateve në Planin e Projektit përsa i përket dërgimit me kohë dhe

përmbushjes cilësore të punëve në formë të analizës së situatës aktuale, një propozim për

kuadrin normativ, një propozim për organizimin e ri të punës, një propozim për konceptin e ri të

mbikëqyrjes në sistemin e pagesave në para në dorë dhe pa para të gatshme

Garanci në bazë të realizimit me kohë dhe përmbushjes cilësore të zgjidhjes softuerike në

aspektin e zbatimit të të gjitha funksioneve të specifikuara

Garanci për trajnimin cilësor dhe të realizuar në kohë të palëve të interesuara

Garanci për Mirëmbajtjen e Sistemit

Garancia e pajisjeve do te jete 3 vjet

10.2 Mbështetje operative për përdoruesit e sistemit

Në këtë aktivitet, ofrohen detyrat për të siguruar mbështetjen e klientëve që do t'u mundësonin atyre të

punonin në mënyrë efikase me sistemin dhe ta përdorin sistemin siç duhet.

Detyrat e këtij aktiviteti janë:

Përmbushja e kërkesave të përdoruesit

Ofrim të informacionit ku mund të gjenden informacione specifike në sistem

Ofrim të interpretimeve të rezultateve të marra nga sistemi

Shpjegim i proceseve që zbatohen në sistem që çojnë në rezultate

Ofrim informacioni mbi përdorimin e sistemit (p.sh. numri i përdoruesve, intensiteti i përdorimit)

Ofrim të dokumenteve në dispozicion në lidhje me sistemin

Mbështetje për menaxhimin e të drejtave të futjes

o Këshillimi mbi mundësitë me rastin e përcaktimit të drejtave te futjes

o Mbështetja gjatë hapjes së emrave të rinj të përdoruesit dhe ndryshimit dhe modifikimit

të drejtave te futjes

o Konsultime gjatë planifikimit të përmirësimeve të sistemit ose përcaktimit të

funksionalitetit të ri.

Faqe 104 nga 140

11 MIRËMBAJTJA

Mirëmbajtja e Sistemit do të zgjasë 2 vjet nga dita e marrjes ne dorezim te sistemit.

Ofertuesi duhet të ofrojë:

1. Mirëmbajtja e Sistemit dhe të gjitha nënsistemeve që janë objekt i prokurimit dhe identifikimi i

problemeve të mundshme në funksionimin e nënsistemeve individuale.

2. Mirëmbajtja e infrastrukturës fizike të komponentëve të sistemit dhe software-it të sistemit

Llojet e mirëmbajtjes së pajisjeve të dorëzuara ose të nënsistemit të aplikimit janë përshkruara në

vazhdim.

Mirëmbajtja parandaluese

Kjo mirëmbajtje përfshin ndjekjen dhe përshtatjen e të gjithë parametrave të harduerit dhe

softuerit aplikativ. Stafi përgjegjës do të kontrollojë periodikisht punën e tyre për të kryer të gjitha

veprimet e nevojshme me qëllim parandalimi në mënyrë që hardueri dhe softueri të funksionojnë

gjithmonë në mënyrë optimale dhe të saktë. Ajo kryhet sipas planit që i dorëzohet rregullisht

mbikëqyrësit të mirëmbajtjes brenda raportit mujor. Mirëmbajtja preventive nuk ka kosto shtesë

për Klientin.

Mirëmbajtja korrektuese

Mirëmbajtja korrektuese nënkupton eliminimin e shkakut të mosfunksionimit të çdo pjese të

harduerit ose softuerit që është shkaktuar nga gabime (bugs) në hardware ose softuerit aplikativ.

Mirëmbajtja korrektuese kryhet pas njoftimit të një dështimi ose mosfunksionimi në punë, të

raportuara nga Klienti, ose nëse Ofertuesi e përcakton këtë mosfunksionim. Veprimet tipike të

mirëmbajtjes korrigjuese janë:

o diagnostikimi i shkakut të dështimit të një sistemi

o eliminimi i shkakut të dështimit të punës së sistemit nëse dështimi është për shkak të një

dështimi të harduerit ose sistemit aplikativ ose përdorimit të tij joadekuat

o duke raportuar për shkaqet e bllokimit dhe për të gjitha veprimet e ndërmarra për kthimin e

sistemit në gjendjen para bllokimit

Gabim nuk konsiderohet:

o Incidenti që është i papërsëritur në ditën e diagnostikimit

o Probleme teknikisht të pazbatueshme

Përdoruesit munden, nëpërmjet menaxherit të mirëmbajtjes së blerësit, ose vetë ai, të bëjë

kërkesë duke supozuar se është një ”bug”. Nëse në analizë konstatohet nëse rasti nuk është

një “bug” ose problemi i raportuar është një funksionalitet standard i sistemit ose nuk mund të

përsëritet ose riprodhohet qartë, koha për raportimin e problemeve dhe hetimit të shkakut të

problemit nuk hyn në mirëmbajtjen korrektive dhe është konsideruar tashmë si "konsultim

ekspertësh"

Mirëmbajtja korrektuese nuk ka kosto shtesë për Klientin.

Përmirësimi i sistemit

Kërkesat që përfaqësojnë ndonjë zgjatje të funksionalitetit të sistemit, d.m.th. nuk mbulohen

nga mirëmbajtja parandaluese dhe korrigjuese, konsiderohen si përmirësim. Kërkesat e tilla do

të mblidhen nga menaxheri i mirëmbajtjes së Klientit dhe do të njofton për to menaxherin e

mirëmbajtjes së Ofertuesit. Pasi Ofertuesi të marrë një kërkesë për përmirësim, Ofertuesi do

të vlerësojë kohën e nevojshme për të përmirësuar sistemin. Në rast se vlerësimi është miratuar

nga Klienti, Ofertuesi do të filloj përmirësimin e sistemit.

Ekspertiza këshilluese dhe diagnostikimi i problemeve

Ekspertiza këshilluese paraqet një ndihmë për punonjësit e Klientit në kryerjen e mirëmbajtjes

korrigjuese, siç thuhet në tekstin e mësipërm.

Ajo përfshin punët e mëposhtme:

Faqe 105 nga 140

o konsultim për përdorimin e softuerit aplikativ (krijim raportesh, administrata)

o konsultim gjatë përdorimit të një aplikacioni për të ndjekur proceset e punës

o konsultim në interpretimin e të dhënave ose raporteve të aplikacionit.

11.1 Mirëmbajtja operacionale e Sistemit dhe sënsistemit

Ofertuesi duhet të ofrojë mirëmbajtjen operative të Sistemit dhe Nënsistemit që është lëndë e prokurimit

dhe zbulimin e problemeve të mundshme në funksionimin e nënsistemeve të veçanta. Ky aktivitet kryhet

me qëllim të ruajtjes së Sistemit në një nivel funksional të prodhuar përmes aktiviteteve të mëparshme.

Aktivitetet e mirëmbajtjes së sistemit ndahet në dy grupe detyrash:

1) mirëmbajtje proaktive

2) mirëmbajtja reaktive

11.2 Mirëmbajtja proaktive

Mirëmbajtja proaktive - Përfshin përmbushjen periodike të detyrave për të mirëmbajtur dhe korrigjuar

sistemin dhe nënsistemet e tij. Aktivitetet zhvillohen në orët e rregullta të punës së Klientit nga ora 08:00

deri në orën 17:00 gjatë ditëve të javës. Është e detyrueshme të dorëzohen raporte për aktivitetet e

kryera në muajin paraprak.

Monitorimi i rregullt dhe periodik i funksionimit të duhur të sistemit - identifikimi i problemeve në

ditarët e përdorimit, bazës së të dhënave dhe në mjedis, gjatë operacioneve të sistemit dhe

nënsistemit ose gjatë proceseve të automatizuara;

Verifikon nëse sistemi i plotëson nivelet e pritura të shërbimit të përcaktuara nga SLA ( Service

Level Agreement);

Zhvillimi i kërkesave për ndryshime me qëllim korrigjimin, përkohësisht zbutjen dhe anashkalimin

e gabimeve dhe anomalive të gjetura në mënyrë pro aktive;

Korrigjimi i problemeve të njohura në mënyrë pro aktive që nuk kërkojnë ndryshime në kod;

Theksimi i ndryshimeve të nevojshme (dhe rekomandimeve për ndryshime) në mjedisin e sistemit

(p.sh. burimet e jashtme të të dhënave ose çështjet e infrastrukturës) që ndikojnë në zbatimin e

duhur të proceseve të biznesit;

Zhvillimi i modifikimit në kod, modele, raporte, ose punë në ETL të nevojshme për të zgjidhur

gabimet e gjetur në mënyrë pro aktive;

Testimi i një kodi ose modelit të zhvilluar për të zgjidhur problemet e identifikuara në mënyrë pro

aktive;

Promovimi në testimin dhe lëshimin e nënsistemeve të gabimeve të njohura në mënyrë pro

aktive;

Dokumentimi i modifikimeve pas ndërhyrjes pro aktive;

Kontrollet pas ndryshimeve të bëra që korrigjojnë pro aktivisht një gabim të njohur

Monitorim i rregullt dhe periodik i performancës së të gjithë komponentëve softuer, middleware,

sisteme operative dhe mjedise virtuale;

Instalimi pajisjeve të softuerëve dhe harduerëve

11.3 Mirëmbajtja reaktive

Mirëmbajtja reaktive - Përfshin detyra që lidhen me reagimin e ofertuesit të përzgjedhur ndaj ngjarjeve

ose incidente të caktuara të raportuara nga Klienti.

Aktivitetet e mirëmbajtjes reaktive zhvillohen në orët e rregullta të punës prej orës 08:00 - 16:00, në ditë

pune.

Faqe 106 nga 140

Dorëzimi obligativ i raporteve për aktivitetet e kryera në muajin e kaluar:

Marrja e ngjarjeve të krijuara nga sistemi i survejimit me detektimin e incidenteve përkatëse

Marrja e një kërkese të përdoruesit me detektimin e incidenteve përkatëse

Përzgjedhja e incidenteve (prioritizimi, kategorizimi, zbulimi i gabimeve, caktimi i agjentëve

përkatës, monitorimi i zbatimit dhe reagimi për përdoruesin);

Zhvillimi i kërkesave për ndryshim me qëllim të korrigjimit, zbutjes së përkohshme dhe shmangies

së gabimeve dhe anomalive të gjetura;

Korrigjimi i problemeve të identifikuara në mënyrë reaktive që nuk kërkojnë ndryshime;

Cekja e ndryshimeve të nevojshme (dhe rekomandimeve për ndryshime) në mjedisin e sistemit

(p.sh. burimet e jashtme të të dhënave ose problemet e infrastrukturës) që ndikojnë në zbatimin

e duhur të proceseve të punës;

Mbështetje gjatë mirëmbajtjes dhe ndryshimit të mjedisit të sistemit dhe përmirësimin e zgjidhjeve

për të punuar siç duhet pas aktiviteteve të tilla;

Zhvillimi ose modifikimit i kodit, modeleve, raporteve ose aktiviteteve të ETL që janë të nevojshme

për të zgjidhur problemet e gjetura reaktive;

Testimi i një kodi ose modeli të zhvilluar për zgjidhjen e gabimeve reaktive;

Promovimi në testimin dhe lëshimin e zgjidhjeve të gabimeve të identifikuara reaktive;

Dokumentimi i modifikimeve pas ndërhyrjes reaktive;

Kontrollet pas ndryshimeve të paraqitura për të korrigjuar një gabim të njohur reaktiv;

Zgjidhja e incidenteve që lidhen me funksionimin e sistemeve operative dhe middleware;

Përshtatja e arkitekturës në rast nevoje gjatë aktiviteteve reaktive dhe sigurimi i përputhshmërisë

së arkitekturës me të gjitha zgjidhjet e incidenteve reaktive;

Zbatimi i kërkesave të reja në nivel të sistemit dhe softuerit operativ;

Çdo ngjarje e njohur në një mjedis që kërkon ndërhyrje (mirëmbajtje reaktive) do të përfshihet në

veglën e ndjekjes së aktiviteteve.

Kërkesat për funksionalitete të reja monitorohen përmes proceseve të ndara. Futjet e incidenteve

kryhen nga punonjësit e AT të Republikës së Shqipërisë dhe të dhënat e tilla përmbajnë të dhënat

minimale në vijim:

Përshkrimi i kërkesës / ngjarjes / incidentit

Nënsistemi që i përket kërkesës/ngjarjes/incidentit (p.sh. Nënsistemi i RTP)

Lloji i regjistrimit (kërkesa për informacion/kërkesë për ndërhyrje/ngjarje /incident i njohur në

mënyrë pro aktive)

Autori i dorëzimit të kërkesës/ngjarjes/incidentit

Koha e raportimit të kërkesës/ngjarjes/ incidentit

Ofertuesit i kërkohet të definojë/zhvillojë dhe zbatojë platformën/veglën për raportimin e

ngjarjes/kërkesës/incidentit, e cila do të mbështesë plotësisht nevojat e procesit të përshkruar këtu.

Pranimet e kërkesave/ngjarjeve/incidenteve me telefon ose postë lejohen në mënyrë të

jashtëzakonshme (aplikacionet kritike). Raportimet e pranuara me telefon ose postë duhet të

evidentohen më pas në sistemin e kërkesave/ngjarjeve/incidenteve.

Ngjarjet në mjediset që kërkojnë ndërhyrje dhe incidentet e njohura pro aktive merren nga punonjësit e

Punëdhënësit dhe dokumentohet momenti kur e kanë zgjidhur kërkesën/incidentin dhe japin një

përshkrim të shkurtër të zgjidhjes në njejtin ambient. Kërkesat e përdoruesit për ndërhyrje klasifikohen

më tej, fillimisht nga punonjësi i AT-ës i cili krijon kërkesën - klasifikimi konsiderohet si: kontributi i

ndikimit dhe vlerësimi i ndikimit, nga çfarë mund të përcaktohet prioriteti sipas matricës vijuese.

Faqe 107 nga 140

NDIKIMI (IMPACT)

I lartë MESME I ulët I ulët

EMERGJENCA (URGENCY)

I lartë 1 2 3

I mesëm 2 3 4

I ulët 3 4 5

Kërkesa për ndërhyrje në shkallën PRIORITETET klasifikohet si më poshtë:

I. "Prioritet i "Urgjencë e Lartë" - në rast se mosfunksionimi i sistemit lidhet me mbylljen e

proceseve të biznesit që duhet të përfundojë gjatë ditës dhe nuk ka zgjidhje për anashkalimin e

problemit.

II. Prioriteti i "Urgjencës së mesme" është caktuar për kërkesat që lidhen me mosfunksionimin që

shkakton që të ndalet proceset e biznesit të cilat duhet të përmbushen gjatë ditës, por mund të

zgjidhen me anë të anashkalimit ose kërkesave që nuk kanë afat aq afër përfundimit të procesit

të punës.

III. Prioriteti "Urgjencë e ulët" - kërkesat pa ndikuar në efikasitetin e proceseve të biznesit dhe nuk

ka rrezik të dëmtimit.

Kërkesa e ndërhyrjes bazohet në shkallën e NDIKIMIT si në vijim:

I. "Ndikimi i lartë" - i caktohet kërkesave tek të cilat parregullsia e ndërlidhur prek të gjithë

përdoruesit e sistemit që kanë këtë funksionalitet të caktuar, përkatësisht nëse asnjë përdorues

i disponueshëm nuk mund të arrijë funksionalitetin e sistemit.

II. "Ndikimi i mesëm" u atribuohet kërkesave që lidhen me mosfunksionim nga një numër më i

madh përdoruesish, por funksionalitetin përdoruesi alternativ mund të arrijë.

III. "Ndikimi i vogël" është menduar për aplikacione ku mosfunksionimi i lidhur ndikon në ndonjë

individ.

Pas futjes dhe klasifikimit, përgjegjësia e ofruesit të shërbimeve të zgjedhura është të marrë përsipër

kërkesën e ndërhyrjes së përpunimit, të përcaktojë personin përgjegjës për plotësimin e kërkesës ose

zgjidhje të incidentit. Nëse është e nevojshme, një ri klasifikim (ndryshim i prioritetit) është i mundur në

marrëveshje me zyrtarët përgjegjës të DPT-ës. Koha e shkarkimit do të regjistrohet në sistem dhe

kështu do të mund të paraqitet koha e reagimit (koha e kaluar që nga koha e futjes së kërkesës deri në

kohën e marrjes). Pritet që 95% e kërkesave të plotësohen në kohën vijuese të reagimit:

I. Prioriteti 1 < 4 orë punë

II. Prioriteti 2 < 8 orë punë

III. Prioriteti 3 < 16 orë punë

IV. Prioriteti 4 < 24 orë punë

V. Prioriteti 5 < 32 orë punë

Orët e punës numërohen midis orës 8:00 dhe 16:00 dhe koha nuk zgjatet jashtë kësaj periudhe. Në

rast se kërkesa nuk mbulohet nga një kontratë e bazuar në këtë tender, procesverbali mund të mbyllet,

por koha e kaluar për shkarkim do të matet.

Përgjegjësia e punonjësit të cilit i është dhënë kërkesa është:

a) analizën e kërkesës,

b) vlerësimi i kohëzgjatjes së pritur të zgjidhjes dhe

Nëse zgjidhja e kërkesës varet nga faktorë të jashtëm (pritje për sqarime të mëtejshme ose riparim të

ndonjë ndikimi të jashtëm), punonjësi përgjegjës duhet të dokumentoj këtë në sistem. Gjithashtu, në

qoftë se sasia e punës në plotësimin e kërkesave apo riparim është me arsye më shumë se sa pritej,

duhet që në marrëveshje me punonjësit e AT-ës të dokumentohet arsyeja e zgjidhjes së zgjatur. Gjatë

Faqe 108 nga 140

mbylljes së proces verbalit, përgjegjësia e punonjësit që e mbyll, është regjistrimi i momentit kur është

plotësuar kërkesa. Specialisti i cili e ka zgjidhur problemin nga kërkesa apo ka përmbushur kërkesat

regjistron atë moment, dhe pastaj kërkuesi konfirmon nëse zgjidhja është e kënaqshme. Në rast të

pranimit të zgjidhjeve, kohëzgjatja e zgjidhjes mund të matet deri në kohën e përfundimit, dhe jo deri

në momentin e pranimit. Është e mundur që gjatë përpunimit të kërkesave përgjegjësi të kenë edhe

punonjësit të cilët nuk janë nën përgjegjësinë e kontraktorit (p.sh.. Një modifikim të një burim i jashtëm

që nuk modifikohet si pjesë e aktiviteteve të këtij tenderi) kështu që është e rëndësishme të

dokumentohet koha e saktë të cilën punonjësit e zbatuesit e kalojnë në mënyrë që zyrtarët e AT të

vlerësojë nëse disa kohë të zgjidhjes janë në përputhje me atë që pritet.

11.4 Mirëmbajtja e Infrastrukturës së Serverit - Serverët aplikativ - JAVA Technology

Punët që duhet të kryhen në serverët e aplikacionit:

Kontrolli i performancës dhe mesazheve të alarmeve.

Menaxhimi i përdoruesve, rrotullave dhe privilegjeve

Konfiguro manualisht alarme për gabime të rëndësishme që nuk janë bërë ende

Migrimi i serverit të aplikacionit sipas nevojës

Instalimi një serveri aplikacioni

Instalimi i patcheve të serverit të aplikacionit.

Ndryshimi i parametrave të serverit aplikativ për të përmirësuar performancën e aplikacionit

Monitorimi i rregullt i punës së serverit aplikativ

o testimi i shërbimit web, formularëve dhe raporteve të shërbimit,

o testimin e shpejtësisë së tyre,

o ngarkesa e procesorëve dhe komponentëve të tjerë të sistemit

o monitorimin e mbushjes së hard diskut

o analiza e log fileave

Backup i serverave aplikativ dhe kontrolloni në ekzekutimin e të njëjtave

Heqja e gabimeve në serverët e aplikacioneve

Rivendosja e serverit aplikativ (kur klienti krijon kërkesat e nevojshme për infrastrukturën për të)

11.5 Servisimi i infrastrukturës së serverit - DBA Oracle teknologjia

Detyrat që duhet të kryhen në serverët e aplikacioneve dhe serverët e bazave të të dhënave:

Monitorimi i logeve

Monitoroni përmbushjes së hard disk

Monitorimi i ngarkesës së procesorit dhe komponentët e tjerë të sistemit

Monitorimi i statusit të job-eve, veçanërisht ato që kryejnë backup të bazës së të dhënave

Kontrolli i performancës dhe alarmi i mesazhit gabim

Backup i bazës së të dhënave në log archive dhe mode logun noarchive (kur krijohen nga klienti

parakushtet e nevojshme të infrastrukturës)

Mbajtja e indeksit (tuning, rebuilding)

Kontrolloni i integritetit të bazës së të dhënave

Përditësimi i statistikave të bazës së të dhënave

Menaxho përdoruesit, rrotullat dhe privilegjet

Konfiguro manualisht alarme për gabime të rëndësishme

Kontrollimi dhe pastrimi i log tabelave

Instaloni i patcheve të bazës së të dhënave në marrëveshje me blerësin

Ruajtja e tabelave të indeksit dhe të dhënave

Kontrolli i rregullsisë së përmbajtjes backup të bazës së të dhënave

Ndrysho parametrat e bazës së të dhënave për të përmirësuar performancën e aplikacionit

Faqe 109 nga 140

Heqja e gabimeve në funksionimin e bazës së të dhënave

Rivendosja e bazës së të dhënave (kur për këtë Blerësi krijon parakushte të nevojshme të

infrastrukturës)

Replikimi i të dhënave - përsëritje standarde bazë dhe replikim përmes kodit programor

Ofruesi i shërbimeve kërkohet të raportojë çdo muaj në lidhje me statusin e sistemit DB në format e

bashkangjitura:

Raportin e statusit të të gjithë serverëve

Raport i detajuar mbi kontrollet e bëra dhe punët në secilin server

11.6 Mirëmbajtja e pajisjeve dhe shërbimet e inxhinierisë së sistemit

Gjatë mirëmbajtjes së pajisjeve, gjatë periudhës së garancisë, Ofertuesi duhet të ofrojë shërbimet e

mëposhtme:

Mirëmbajtja e pajisjeve të klientit të furnizuara gjatë periudhës së garancisë

Servisim, d.m.th. mirëmbajtja parandaluese dhe korrektuese e pajisjeve (hardware) gjatë

periudhës së garancisë

Rregullimi i dëmtimeve sipas kërkesës së klientit, sipas prioriteteve të mirëmbajtjes për

kohëzgjatjen e periudhës së garancisë

Riparimi në bazë të kërkesës së klientit mbi defektin e sherbimit d.m.th. mirëmbajtja preventive dhe

korrigjuese e pajisjes (harduerit), përfshin aktivitetet e mëposhtme:

Diagnostikën

Pjesë këmbimi dhe zëvendësimi i pjesëve të dëmtuara

Puna për aftësimin e sistemit

Testimi përfundimtar i sistemit

Raportimi i gjendjes dhe mënyra e zgjidhja e problemeve të evidentuara

Faqe 110 nga 140

12 PLANIFIKIMI I BUXHETIT PËR ZBATIMIN E PROJEKTIT

12.1 Specifikimi i harduerit

12.1.1 DATA MANAGEMENT TIER

DATA

MANAGEMENT

TIER

Product Njësia Sasia Çmimi Vlera

Exadata Database Machine X7-2 High Capacity

(HC) Eighth Rack ose ekuivalent System 2

Exadata Storage Server Software ose ekuivalent Disk Drive 36

Oracle Database Enterprise Edition ose

ekuivalent Processor 16

Oracle Real Application Clusters ose ekuivalent Processor 16

Oracle Partitioning ose ekuivalent Processor 16

Oracle Advanced Compression ose ekuivalent Processor 16

Oracle Advanced Security ose ekuivalent Processor 16

Oracle Diagnostic Pack ose ekuivalent Processor 16

Oracle Tuning Pack ose ekuivalent Processor 16

Oracle Active Data Guard ose ekuivalent Processor 16

ESTIMATED Install and config services (ACS) Services 2

ESTIMATED Additional cost: transceivers,

freight fee,… 2

ESTIMATED Additional configuration service:

Data Guard impl, DB backup impl to ZFS SA,

OEM configuration

Services 1

TOTALI PA TVSH

12.1.2 MIDDLEWARE TIER

MIDDLEWARE

TIER

Product Njesia Sasia Çmini Vlera

Hardware Servers for Java Appl & BI ose

ekuivalent System 1

ESTIMATED Install and config services: servers,

Linux, VMs (ACS)+ Freight fee Services 1

Hradware Server for Management: EM, VM

Manager, ODI console ose ekuivalent System 8

Hardware - Load balancer ose ekuivalent System 4

ESTIMATED Install and config services: servers,

Linux (ACS) + Freight fee Services 8

ESTIMATED Install and config services for EM +

ODI Console Services 1

Oracle Data Integrator Enterprise Edition ose


Oracle BI Suite Extended Edition ose ekuivalent Processor 2

Oracle BI Data Visualization ose ekuivalent Processor 2

Oracle WebLogic ServerEnterprise Edition ose


Oracle HTTP Server ose ekuivalent Processor 5

API Gateway ose ekuivalent System 2

Oracle Access Manager ose ekuivalent Processor 4

Load Balancer SW ose ekuivalent System 4

Faqe 111 nga 140

Oracle Directory ose ekuivalent Processor 4

ESTIMATED Install and config services for BI,

ODI, WL Services 1

Totali pa TVSH

12.1.3 MIDDLEWARE TIER

DATABASE

BACKUP

STORAGE

Product Njesia Sasia Çmimi Vlera

Oracle ZFS Storage Appliance ZS5-2 ose

ekuivalen System 1

ESTIMATED Install and config services (ACS) +

Freight fee Services 1

Totali pa TVSH

12.2 Përllogaritja e pjesëve të projektit

Tabela e mëposhtme paraqet aktivitetet e zbatimit të projektit dhe shpenzimet që lidhen me secilën

kategori.

Sasia Çmimi

KUADRI LIGJOR / KËSHILLTARËT

Sistemi i evidentimit dhe përcjelljes së transaksioneve me para në dorë

1

Kontrolli tatimor i tatimpaguesve në sistemin e pagesave me para në dorë

1

Sistemi për menaxhimin e riskut për pagesa me para në dorë

1

Krijimi, regjistrimi dhe përcjellja e transaksioneve jo cash 1

Regjistri i tatimpaguesve me degët e tatimpaguesve dhe API

1

Sistemi i menaxhimit të sigurisë së informacionit - (ISMS) 1

Strategjia e PR 1

TOTAL pa TVSH

SOFTUERI

Sistemi i evidentimit dhe përcjelljes së transaksioneve me para në dorë

1 copë

Portali qendror për kontrollin dhe menaxhimin e taksapaguesve në nënsistemin e pagesave me para në dorë (PQKM)

1 copë

PQKM në funksion të përcjelljes së tendencave dhe efekteve të sistemit të pagesave me para në dorë

1 copë

Analiza e tatimpaguesve në sistemin e pagesave në para në dorë në mbulimin hapësinor

1 copë

Analiza e tatimpaguesve në nënsistemin TP 1 copë

Menaxhimi i anomalive në nënsistemin TP 1 copë

Kontrolli tatimor i tatimpaguesve në sistemin e pagesave me para në dorë

1 copë

Aksesimi i sistemit npm tabletit- për punën e inspektorëve në terren

1 copë

Shërbim i dedikuar në aplikacionin mobile- për qytetarët 1 copë

Sistemi për menaxhimin e riskut për pagesa me para në dorë

1 copë

Krijimi, regjistrimi dhe përcjellja e transaksioneve me pagesa jo cash

1 copë

Pasuria (Asetet) e tatimpaguesve 1 copë

Regjistri i tatimpaguesve me degët e tatimpaguesve dhe API

1 copë

TOTAL pa tvsh -

Faqe 112 nga 140

Hardueri

Data management tier 1

Middleware tier 1

Database backup storage tier 1

TOTAL pa TVSH -

Emërtimi Sasia Vlera pa TVSH

Trajnimet (set) 1

Mirembajtje HW dhe SW (vite) 2

Totali pa TVSH

Faqe 113 nga 140

13 AFATI KOHOR I PROJKETIT DHE LISTA E DOKUMETEVE TË CILAT

OFERTUESI DUHET TË DORËZOJË

13.1 Plani i implementimit

Fillimi i projektit

Fillimi i aktivitetit (T): T+ 0

Fillimi i statusit: Data e nënshkrimit të kontratës

Përfundimi i aktivitetit: T+ 30 ditë

Përfundimi i statusit: Krijimi i një organizimi të projektit dhe mbështetja logjistike

ID Dorëzimet

Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data

dorëzimit

1.

Përcaktimi i organizimit të projektit, dokumentacionit dhe mbështetjes logjistike

Ofertuesi Administrata Tatimore Autoriteti Kontraktor

Përcaktimi i rolit të projektit. Përcaktimi i listës përfundimtare të

dokumentacionit Krijimi i mbeshtjetjes logjike.

T+25 ditë

2. Konfirmimi i organizimit të projektit dhe mbështetja logjistike

Autoriteti Kontraktor Organizim i konfirmuar i projektit

dhe mbështetje logjistike T+30 ditë

Plani i projektit dhe Plani i sigurimit të cilësisë

Fillimi i aktivitetit (T): T+ 30 ditë

Fillimi i statusit: Krijimi i një organizimi të projektit dhe mbështetja logjistike


Përfundimi i statusit: Konfirmimi i planit te projektit

ID Dorëzimet


dorëzimit

3. Plani i projektit dhe plani i sigurimit të cilësisë

Ofertuesi Administrata Tatimore Autoriteti Kontraktor

Hartimi i planit të projektit. Rishikimi i planit te projektit së

bashku me Autoriteti Kontraktor T+45 ditë

4. Konfirmimi i planit të projektit Porositësi Verifikuar nga autoriteti kontraktues T+60 ditë

Specifikimi i arkitekturës së sistemit dhe modelit të biznesit


Fillimi i statusit: Krijimi i një organizimi të projektit dhe mbështetja logjistike Është konfirmuar plani i projektit


Përfundimi i statusit: Proceset e përcaktuara të biznesit/punës dhe modeli organizativ Specifikimi i konfirmuar i arkitekturës së sistemit

ID Dorëzimet


dorëzimit

5. Analiza e biznesit dhe kërkesave teknike

Ofertuesi

Kërkesat e rishikuara Modelet dhe specifikat e proceseve

të biznesit dhe organizimin e sistemeve CP dhe NCP

T+80 ditë

6.

Përkufizimi/Definicioni i Arkitekturës së Sistemit të Nivelit të Lartë (HLA)

Ofertuesi

Specifikimi i HLA dhe platforma teknike.

Përkufizimi/Definicioni i shkëmbimit të të dhënave dhe ndërfaqeve me sisteme të tjera

Specifikimet e nevojshme te harduerit, pajisjeve, softuerit të sistemit dhe softuerit të licencuar të palëve të treta për testimin e mjedisit, mjedisit të trajnimit dhe mjedisit të produktit

T+150 ditë

7. Përcaktimi/Definicioni i modulit të sigurisë

Ofertuesi Specifikimi i sigurisë së sistemit Kontrolli i definicionit në sistemin e

informacionit T+150 ditë

8.

Konfirmimi i kërkesave të biznesit, modeli i biznesit dhe organizimit dhe arkitektura e sistemit

Administrata Tatimore

Kërkesat e konfirmuara të biznesit Modeli i konfirmuar i biznesit dhe

organizative. Arkitektura e konfirmuar e sistemit Konfirmim i të Drejtës Operacionale

T+120 ditë

Regjistri i tatim paguesve

Faqe 114 nga 140


Fillimi i statusit: Proceset e përcaktuara të biznesit dhe modeli organizativ Specifikimi i konfirmuar i arkitekturës së sistemit


Përfundimi i statusit: Prodhimi i "Regjistrit të tatim paguesve"

ID Dorëzimet


Dorëzimit

9.

Analiza e Bizneseve dhe Kërkesave Teknike për Zhvillimin dhe Zbatimin e Nënsistemit "Regjistri i Tatim paguesve

Ofertuesi

Analiza e sistemit ekzistues Analiza e kërkesave të biznesit të

Autoriteti Kontraktor Analiza e kërkesave teknike dhe

mjedisit Krijimi i një dokumenti "Analiza

Kërkese" Krijimi i një modeli logjik Krijimi e një modeli fizik Krijimi i një dokumenti "Specifikimet

e kërkesave të përdoruesit"

T+150 ditë

10.

Verifikimi i dokumentit "Specifikimet e Kërkesave të Përdoruesit" për "Regjistrin e Tatim paguesve"


Autoriteti Kontraktor ka konfirmuar analizën e kërkesave të biznesit dhe teknike

Autoriteti Kontraktor ka konfirmuar "Specifikimin e Kërkesave të Përdoruesit«

T+155 ditë

11.

Zhvillimi dhe Implementimi i Nënsistemit "Regjistri i Tatim paguesve"

Ofertuesi

Dizenjimii i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit

T+160 ditë

12.

Analiza e performancës së nënsistemit "Regjistri i Tatimpaguesve" dhe rregullimi i hollësishëm

Ofertuesi

Instalimi në mjedisin e testimit të Autoriteti Kontraktor

Matja e performancës së nënsistemit

Optimizimi i procedurës dhe kodit të programit

Dokumentimi i rezultateve të testimit

T+160 ditë

13. Testimi nga zyrtarët e DPT-së Ofertuesi

Njohja me një zyrtar të DPT-së me një plan testimi

Kryen testet në përputhje me planin e testimit

Korrigjimi i mangësive të zbuluara Krijimi i një raporti testimi

T+180 ditë

14. Trajnimi i zyrtarëve të DPT-së Ofertuesi Krijimi i një manuali përdoruesi Workshop-e për zyrtarët e DPT-së Vlerësimi i rezultateve

T+200 ditë

15. Migrimi i të dhënave në "Regjistrin e Tatimpaguesve"

Ofertuesi

Analiza e të dhënave ekzistuese Përcaktoni procedurat e migracionit Pergatitja e të dhënave të migrimit Analiza dhe testimi i të dhënave të

migruara

T+200 ditë

16. Është ne produkt sistemi "Regjistri i Tatimpaguesve"

Autoriteti Kontraktor Dorëzimi i procesverbalit Lëshimi i Certifikatës se Mundësisë

Operacionale T+210 ditë

Zyrat e Tatim paguesve


Fillimi i statusit: Prodhimi/Produkcioni i "Regjistrit të Tatimpaguesve"


Përfundimi i statusit: Prodhimi/Produkcioni i "Regjistrit të Tatimpaguesve"

ID Dorëzimet


dorëzimit

17.

Analiza e kërkesave të biznesit dhe teknike për zhvillimin dhe zbatimin e modulit "Zyrat e Tatimpaguesve"

Ofertuesi

Analiza e kërkesave të biznesit të Autoriteti Kontraktor

Analiza e kërkesave teknike dhe mjedisit

Krijimi i një dokumenti "Analiza e Kërkesës"

Krijimi i një modeli logjik Krijimi e një modeli fizik Krijimi i një dokumenti "Specifikimet


T+230 ditë

Faqe 115 nga 140





ID Dorëzimet


dorëzimit

18.

Verifikimi i dokumentit "Specifikimet e Kërkesave të Përdoruesit" për "Zyrat e Tatimpaguesve"

Autoriteti Kontraktor Administrata Tatimore


T+235 ditë

19.

Zhvillimi dhe zbatimi i modulit "Zyrat e Tatimpaguesve"

Ofertuesi

Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit

T+250 ditë

20.

Analiza e performancës së modulit "Zyrat e Tatimpaguesit" dhe rregullimi i hollësishëm

Ofertuesi





T+255 ditë



Testime në përputhje me planin e testimit


T+255 ditë


T+265 ditë

23. Është ne publikim nënsistemi i "Zyrës së Taksapaguesve"



Prona e tatim paguesit



Përfundimi i aktivitetit: T+ 17 muaj


ID Dorëzimet


dorëzimit

24.

Analiza e Bizneseve dhe Kërkesave Teknike për Zhvillimin dhe Zbatimin e Modulit "Pasuritë e Tatimpaguesve"

Ofertuesi



Krijimi i një dokumenti "Analizimi i Biznesit dhe Kërkesave Teknike"

Krijimi i një modeli logjik Krijimi i një modeli fizik Krijimi i një dokumenti "Specifikimet


T+8 muaj

25.

Analiza e Biznesit dhe Kërkesat Teknike për Zhvillimin dhe Zbatimin e Modulit të "Pasurive të Tatimpaguesve"



T+9 muaj

26.

Zhvillimi dhe implementimi i modulit "Patundshmëritë e tatim paguesve"

Ofertuesi


T+10 muaj

27.

Zhvillimi dhe implementimi i modulit "Luhatshmeria e tatim paguesve"

Ofertuesi


T+11 muaj

28.

Zhvillimi dhe zbatimi i modulit "Pasuritë financiare të tatimpaguesit"

Ofertuesi


T+12 muaj

29.

Zhvillimi dhe implementimi i modulit "Pasuritë jo materiale të tatimpaguesit"

Ofertuesi

Dizajnimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit

T+13 muaj

Faqe 116 nga 140





ID Dorëzimet


dorëzimit

30.

Zhvillimi dhe implementimi i modulit "Regjistri qendror i vlerësimit të pasurive/aseteve"“

Ofertuesi


T+14 muaj

31.

Analiza e performancës së modulit "Pasuritë e tatimpaguesve" dhe rregullimi i hollësishëm

Ofertuesi





T+15 muaj





T+15 muaj


T+16 muaj

34. Është ne publikim sistemi "i aseteve/pasurive të

Autoriteti Kontraktor

U nënshkrua dorëzimi i procesverbalit

Lëshimi Certifikatës se Mundësisë Operacionale Mirefunksionimit

T+17 muaj

Kuadri legjislativ

Fillimi i aktivitetit (T): T+120 ditë

Fillimi i statusit: Proceset e përcaktuara të biznesit dhe modeli organizativ Specifikimi i konfirmuar i arkitekturës së sistemit.


Përfundimi i statusit: Korniza legjislative e miratuar nga parlamenti

ID Dorëzimet


dorëzimit

35. Analiza e Kornizës Ligjore të GAP (CP, NCP)

Ofertuesi

Hulumtimi i tregut Shqyrtimi i legjislacionit ekzistues

në Republikën e Shqipërisë Analiza e të dhënave Identifikimi i elementeve kyçe Analiza e kuadrit ligjor ekzistues

relevant të BE-së Krijimi i një dokumenti "Analiza e

GAP e kuadrit ligjor"

T+180 ditë

36. Përgatitja e një kuadri të ri ligjor Ofertuesi

"Propozim i ri legjislativ" "Propozim për ndryshimin e ligjeve

të tjera tatimore" "Propozim për ndryshimin dhe

plotësimin e ligjeve të tjera të ndërlidhura"

"Vlerësimi i ndikimit të opsioneve të ndryshme"

T+270 ditë

37. Konfirmimi i Dokumentit Autoriteti Kontraktor

Konfirmimi Propozim i ri i kornizës legjislative "

Konfirmimi "Ndryshimet e propozuara në ligjet e tjera tatimore"

Konfirmim "Propozim për ndryshime në ligjet tjera të ndërlidhura"

Konfirmimi "Vlerësimi i Ndikimit të Opsioneve të Ndryshme"

T+200 ditë

38. Debat publik Administrata Tatimore

MFE Ofertuesi

Diskutim nga fokus grupet Mblidhja dhe analizimi i propozimit Ndryshimet e mundshme në

propozimin e kornizës legjislative pas konsultimit

T+230 ditë

39. Përgatitja e rregulloreve zbatuese

Ofertuesi Propozimi i ri i kornizës legjislative

ka mbaruar T+260 ditë

Faqe 117 nga 140


Fillimi i statusit: Proceset e përcaktuara të biznesit dhe modeli organizativ Specifikimi i konfirmuar i arkitekturës së sistemit.


Përfundimi i statusit: Korniza legjislative e miratuar nga parlamenti

ID Dorëzimet


dorëzimit

Krijimi i udhëzimeve, informacioneve, broshurave

40. Procedura për miratimin e kornizës legjislative

Administrata Tatimore MFE

Ofertuesi

PR mbështetje Duke iu përgjigjur pyetjes së

zbatimit të tatimpaguesit Sqarim i kuadrit ligjor për palët e

interesuara

T+290 ditë

41. Korniza legjislative e miratuar nga parlamenti

Administrata Tatimore MFE

Konfirmimi i të Drejtës Operacionale Ligji është botuar në një lajmëtar

publik T+300 ditë

Organizimi dhe metodologjia e monitorimit tatimor të tatimpaguesve në sistemin TP


Fillimi i statusit: Krijimi i një organizimi të projektit dhe mbështetja logjistike

Përfundimi i aktivitetit: T+150 ditë

Përfundimi i statusit: Është zbatuar organizimi dhe metodologjia e monitorimit tatimor të tatimpaguesve në sistemin TP

ID Dorëzimet


dorëzimit

42.

GAP analiza e procedurave ekzistuese të kontrollit të taksave

Ofertuesi

Analiza e procedurave ekzistuese të auditimit tatimor

Krijimi Identifikimi i rreziqeve kryesore të

komponentëve të një kuadri të ri ligjor Krijimi i një metodologjie të re tatimore Propozim për të ndryshuar rregulloret

e tjera

T+90 ditë

43.

Përcaktimi i procedurave të monitorimit dhe monitorimit të tatimeve për tatimpaguesit në sistemin TP

Ofertuesi

Analiza e procedurave ekzistuese të auditimit tatimor

Identifikimi i rreziqeve kryesore të komponentëve të një kuadri të ri ligjor

Krijimi i një metodologjie të re tatimore Propozim për të ndryshuar rregulloret

e tjera

T+110 ditë

44.

Miratimi i procedurave të monitorimit dhe kontrollimit të taksave

Autoriteti Kontraktor Procedura e miratuar për monitorimin

dhe monitorimin e tatimeve të tatimpaguesve

T+140 ditë

45. Metodologjia e auditimit tatimor është zbatuar

Autoriteti Kontraktor Trajnimi i zyrtareve-nëpunësve DT punon sipas metodologjisë së re

tatimore T+150 ditë

Zhvillimi dhe zbatimi i sistemeve TP


Fillimi i statusit: Definimet e përcaktuara të biznesit dhe modeli organizativ Specifikimi i konfirmuar i arkitekturës së sistemit.


Përfundimi i statusit: Nënsistemi TP është në funksionim

ID Dorëzimet


dorëzimit

46.

Analiza e Bizneseve dhe Kërkesave Teknike për Zhvillimin dhe Zbatimin e Nënsistemit TP

Ofertuesi




Krijimi i një modeli logjik

T+60 ditë

Faqe 118 nga 140




Përfundimi i statusit: Nënsistemi TP është në funksionim

ID Dorëzimet


dorëzimit

Krijimi e një modeli fizik Krijimi i një dokumenti "Specifikimet e

kërkesave të përdoruesit"

47.

Konfirmimi i dokumentit "Specifikimet e kërkesave të përdoruesit" për Nënsistemin TP

Autoriteti Kontraktor Autoriteti Kontraktor ka konfirmuar

"Specifikimin e Kërkesave të Përdoruesit«

T+70 ditë

48. Zhvillimi dhe Implementimi i Nënsistemit TP

Ofertuesi

Dizenjimimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit

T+100 ditë

49.

Krijimi i specifikimeve teknike për sistemet e pagesave ne aparate te përdoruesve të fundit

Ofertuesi

Dizenjimimi i i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit

T+160 ditë

50.

Analiza e performancës së Nënsistemit TP dhe akordimi i hollësishëm

Ofertuesi


Matja e performancës së nënsistemit Optimizimi i procedurës dhe kodit të

programit Dokumentimi i rezultateve të testimit

T+180 ditë





T+180 ditë


T+190 ditë

53. Nënsistemi TP është ne funksionim

Autoriteti Kontraktor U nënshkrua dorëzimi i procesverbalit Lëshimi Certifikatës se Mundësisë


Portali Qendror për Kontrollimin dhe Menaxhimin e Tatimpaguesve në TP (PQKM)




Përfundimi i statusit: Portali Qendror PQKM është ne funksionim

ID Dorëzimet


dorëzimit

54.

Analiza e biznesit dhe kërkesave teknike për zhvillimin dhe zbatimin e sistemit të PQKM

Ofertuesi




Krijimi i një modeli logjik Krijimi i një modeli fizik Krijimi i një dokumenti "Specifikimet e


T+150 ditë

55.

Konfirmimi i dokumentit "Specifikimet e kërkesave të përdoruesit" për PQKM



T+200 ditë

56.

Zhvillimi dhe zbatimi i modulit "PQKM në funksion të ndjekjes së tendencave dhe efekteve të sistemit të pagimit në cash"

Ofertuesi Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Testimi i programimit

T+220 ditë

57.

Zhvillimi dhe implementimi i modulit "Analiza e tatimpaguesve në sistemin TP në mbulimin hapësinor"

Ofertuesi


T+250 ditë

58.

Zhvillimi dhe zbatimi i modulit "Analiza e Tatimpaguesve në Sistemin TP"

Ofertuesi Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI

T+270 ditë

Faqe 119 nga 140




Përfundimi i statusit: Portali Qendror PQKM është ne funksionim

ID Dorëzimet


dorëzimit

Testimi i programimit

59.

Zhvillimi dhe zbatimi i modulit "Menaxhimi i anomalive në sistemin e pagesave në para të gatshme"

Ofertuesi


T+290 ditë

60.

Analiza e performancës së portalit PQKM WEB dhe akordimi i hollësishëm

Ofertuesi




T+300 ditë





T+330 ditë


T+350 ditë

63. Portali Qendror PQKM është ne funksionim

Autoriteti Kontraktor Dorëzimi i procesverbalit Lëshimi Certifikatës se Mundësisë


Sistemi SMR për Sistemin e TP (Sistemi i Menaxhimit të Riskut)


Fillimi i statusit: Sistemi TP në funksionim

Përfundimi i aktivitetit: T+18 muje

Përfundimi i statusit: RMS për nevojat e sistemit TP në funksionim

ID Dorëzimet


dorëzimit

64.

Analiza e biznesit dhe të kërkesave teknike për zhvillimin dhe vendosjen e Nënsistemeve SMR për nevojat e Nënsistemit TP

Ofertuesi

Analiza e biznesit dhe kërkesave të Autoriteti Kontraktor


Krijimi i një dokumenti "Analiza e biznesit dhe kërkesave teknike"

Krijimi i një modeli logjik Bërja e një modeli fizik Krijimi i një dokumenti "Specifikimet e

Kërkesave të Përdoruesit"

T+10 muaj

65. Krijimi i një Katalogu të Riskut për Nënsistemin TP

Ofertuesi

Analiza e tatimpaguesve Analiza e të dhënave të Transaksionit

të Parave te gatshme Krijimi i një Katalogu të Riskut

T+12 muaj

66. Zhvillimi dhe Implementimi i Nënsistemit RMS



Autoriteti Kontraktor ka konfirmuar Katalogun e Riskut

Autoriteti Kontraktor ka konfirmuar "Specifikimet e Kërkesave të Përdoruesit" për RMS

T+14 muaj

67. Zhvillimi dhe Implementimi i Nënsistemit të Sistemit RMS

Ofertuesi


T+15 muaj

68. Integrimi i SMR për nënsistemin TP me sisteme të tjera të DT-së

Ofertuesi

Integrimi i Modulit të të Dhënave TP të Nënsistemit Data

Integrimi i Nënsistemit me modelin DWH të nënsistemit TP

Integrimi i Nënsistemit me GUI RTP Testimi i Performancës dhe

Rezultateve të Integrimit

T+16 muaj

Faqe 120 nga 140

Mbikëqyrja Online e tatimpaguesve në sistemin TP


Fillimi i statusit: Krijimi i një organizimi të projektit dhe mbështetja logjistike Konfirmimi i planit të projektit Nënsistemi TP funksionon


Përfundimi i statusit: Monitorimi Online për nevojat e sistemit TP funksionon

ID Dorëzimet


dorëzimit

73. Analiza e biznesit dhe të kërkesave teknike

Ofertuesi

Analiza e biznesit kërkesat Autoriteti Kontraktor



Krijimi i një modeli logjik Krijimi e një modeli fizik Krijimi i një dokumenti "Specifikimet e


T+150 ditë

74.

Konfirmimi i dokumentit "Specifikimet e Kërkesave të Përdoruesit" për Kontrollet e Taksapaguesve Online



T+160 ditë

75. Zhvillimi dhe zbatimi i modulit "Planifikimi i kontrollit Tatimor"

Ofertuesi


T+200 ditë

76.

Zhvillimi dhe Implementimi i Modulit të "Rregullores së Inspektimit Tatimor"

Ofertuesi


T+220 ditë

77.

Zhvillimi dhe Implementimi i Modulit të „Njoftimi për Inspektimin Tatimor“

Ofertuesi


T+240 ditë

78.

Zhvillimi dhe zbatimi i modulit "Procesverbalet "Inspektimi Tatimor"

Ofertuesi


T+260 ditë

79.

Zhvillimi dhe zbatimi i modulit "Zgjidhjet e Kontrollit të Taksave"

Ofertuesi


T+280 ditë

80.

Analiza e performancës së sistemit dhe rregullimi i hollësishëm i sistemit

Ofertuesi




T+310 ditë




T+320 ditë

69. Analiza e Performancës së Sistemit RMS

Ofertuesi




T+17 muaj





T+17 muaj


T+17 muaj

72. RMS për nevojat e sistemit TP në funksionim

Autoriteti Kontraktor Dorëzimi i procesverbalit Lëshimi Certifikatës se Mundësisë

Operacionale T+18 muaj

Faqe 121 nga 140


Fillimi i statusit: Krijimi i një organizimi të projektit dhe mbështetja logjistike Konfirmimi i planit të projektit Nënsistemi TP funksionon


Përfundimi i statusit: Monitorimi Online për nevojat e sistemit TP funksionon

ID Dorëzimet


dorëzimit


82. Trajnimi i zyrtarëve të AT Ofertuesi Krijimi i një manuali përdoruesi Workshop-e për zyrtarët e DPT-së Vlerësimi i rezultateve

T+350 ditë

83. Monitorimi Online për nevojat e nënsistemi TP funksionon


U nënshkrua dorëzimi i procesverbalit Autoriteti Kontraktor ka lëshuar

Certifikatën e Mundësisë Operacionale

T+365 ditë

Nënsistemi për "Mbështetjen e Inspektorëve të Taksave në Sistemin TP"


Fillimi i statusit: Nënsistemi TP në funksion


Përfundimi i statusit: Nënsistemi është ne funksion duke i mbështetur inspektorët e taksave në sistemin TP

ID Dorëzimet


dorëzimit

84.

Analiza e biznesit dhe kërkesave teknike për zhvillimin dhe zbatimin e Nënsistemit "Mbështesin inspektorët e taksave në sistemin e TP"

Ofertuesi






T+220 ditë

85.

Verifikimi i "Specifikimeve të Kërkesave të Përdoruesit" Dokumenti për Nënsistemin "Mbështetja e inspektorëve tatimorë në sistemin e TP"



T+230 ditë

86.

Zhvillimi dhe Implementimi i Nënsistemit Mbështetës për Inspektorët e Taksave në Sistemin TP-WEB versioni

Ofertuesi


T+290 ditë

87.

Zhvillimi dhe zbatimi Nënsistemit Mbështetës për inspektorët e taksave në TP - versioni nativ celular

Ofertuesi


T+290 ditë

88.

Analiza e performancës së Nënsistemit celular dhe rregullimi i hollësishëm i sistemit

Ofertuesi




T+290 ditë



Testime në përputhje me planin e testimit


T+320 ditë


T+340

Faqe 122 nga 140

Aplikacion mobile - RTP për tatimpaguesit


Fillimi i statusit: Nënsistemi TP ne funksion

Përfundimi i aktivitetit: T+16 muje

Përfundimi i statusit: Aplikacion mobile - RTP për tatimpaguesit

ID Dorëzimet


dorëzimit

93.

Analiza e kërkesave të biznesit dhe teknike për zhvillimin dhe implementimin e Nënsistemit mobil "Zgjidhja per telefon të zgjuar (Martphone) -

Ofertuesi






T+13 muaj

94.

Verifikimi i dokumentit "Specifikimet e Kërkesave të Përdoruesit" për "Zgjidhjen e Telefonisë Celulare Smart"

Ofertuesi Autoriteti Kontraktor ka konfirmuar


T+13 muaj

95.

Zhvillimi dhe zbatimi i nënsistemit mobil "Zgjidhja e telefonit zgjuar telefonik - për qytetarët"

Ofertuesi


T+14 muaj

96. Analiza e performancës Ofertuesi




T+15 muaj


Njohja e një zyrtari të DPT-së me një plan testimi



T+15 muaj


T+15 muaj

99.

Përgatitja dhe instalimi ne mjedisin për shkarkimin masiv të nënsistemit celular nga faqja zyrtare e DPT dhe nga dyqanet ne WEB të

Ofertuesi Instalimi në Mjedisin Testimi

T+15 muaj

100. Telefoni i zgjuar/mençur zgjidhje native mobile - RTP për tatimpaguesit ne funksion


Operacionale T+16 muaj

Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret


Fillimi i statusit: Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret “ është lëshuar


Përfundimi i statusit: Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret “ është lëshuar, në funksion

ID Dorëzimet


dorëzimit

101.

Analiza e kërkesave të biznesitdhe kërkesave teknike për sherbimin e dedikuar ne aplikacionin

Ofertuesi

Analiza e biznesit kërkesat Autoriteti Kontraktor dhe AT


T+390 ditë

91.

Përgatitja dhe instalimi i një ambienti funksionon për shkarkimin masiv të zgjidhjes së programimit celular nga faqja zyrtare e WEB e DPT

Ofertuesi Instalimi funksionon ne Mjedisit e

Autoriteti Kontraktor Testimi i shkarkimit

T+340 ditë

92.

Mbështetja e sistemit të mbikëqyrjes tatimore TP (WEB dhe Mobile) funksionon



Faqe 123 nga 140


Fillimi i statusit: Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret “ është lëshuar


Përfundimi i statusit: Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret “ është lëshuar, në funksion

ID Dorëzimet


dorëzimit

mobile ne e-albania per qytetaret


Krijimi i një modeli logjik Krijimi e një modeli fizik Krijimi i një dokumenti "Specifikimet


102. Certifikata e dokumentit Autoriteti Kontraktor Autoriteti Kontraktor ka konfirmuar


T+400 ditë

103.

Zhvillimi dhe zbatimi i Nënsistemit mobil "Zgjidhja e telefonit zgjuar/mençur telefonik - për qytetarët"

Ofertuesi


T+460 ditë

104.

Analiza e performancës së Nënsistemit celular dhe rregullimi i hollësishëm i sistemit

Ofertuesi





T+470 ditë

105. Testimi nga zyrtarët e DPT-së

Ofertuesi

Njohja e një zyrtari të AT me një plan testimi



T+480 ditë

106. Trajnimi i zyrtarëve të DPT-së

Ofertuesi Krijimi i një manuali përdoruesi Workshop-e për zyrtarët e DPT-së Vlerësimi i rezultateve

T+490 ditë

107.

Përgatitja dhe instalimi i një ambienti prodhimi për shkarkimin masiv të Nënsistemit celular nga faqja zyrtare e internetit WEB të DPT-së

Ofertuesi Instalimi i nënsistemit në mjedisin e

funksionit, lëshimit Testimi i shkarkimit

T+490 ditë

108. "Zgjidhja e telefonit zgjuar celular - për qytetarët" u lëshua, në funksion



Zhvillimi dhe zbatimi i sistemit TJP

Fillimi i aktivitetit (T): T+12 muaj

Fillimi i statusit: Nënsistemi TP është leshuar në funksion RMS për nevojat e sistemit TP është lëshuar në funksion


Përfundimi i statusit: Nënsistemi TP është lëshuar, në funksion

ID Dorëzimet


dorëzimit

109. Analiza e kërkesave të biznesit dhe teknike për zhvillimin dhe zbatimin e nënsistemit TJP

Ofertuesi



Përcaktimi i proceseve të biznesit Përcaktimi i skenarëve Krijimi i një dokumenti "Analiza e

biznesit dhe kërkesat teknike" Krijimi i një modeli logjik Krijimi e një modeli fizik Krijimi i një dokumenti "Specifikimet

e Kërkesave të Përdoruesit"

T+14 muaj

110. Certifikata e dokumentit Autoriteti Kontraktor

Autoriteti Kontraktor ka konfirmuar Analizën e Bizneseve dhe Kërkesave Teknike

Autoriteti Kontraktor ka konfirmuar dokumentin "Proceset e Biznesit në TJP"

T+14 muaj

Faqe 124 nga 140

Trajnimi i zyrtareve DPT-së

Pranueshmëria operacionale (integrimi i plotë i sistemit) dhe mbyllja e projektit

Konfirmimim "Specifikimet e Kërkesave të Përdoruesit"

111. Zhvillimi dhe Implementimi i Nënsistemit të evidentimit të TJP-së

Ofertuesi


T+18 muaj

112. Zhvillimi dhe Implementimi i nënsistemit eReport

Ofertuesi


T+18 muaj

113.

Zhvillimi dhe zbatimi i nënsistemit te evidentim dhe ndjekjes së pagesave të TJP

Ofertuesi


T+18 muaj

114. WEB portal Ofertuesi


T+18 muaj

115. prodhimin e specifikimeve teknike

Ofertuesi Encoding dhe Dokumentim Testimi i programimit

T+18 muaj

116.

Zhvillimi dhe implementimi i portalit WEB për nënsistemin TJP

Ofertuesi

Instalimi në mjedisin e testimit Matja e performancës së

nënsistemit Optimizimi i procedurës dhe kodit të


T+18 muaj


Njohja e një zyrtari të AT me një plan testimi

Testet në përputhje me planin e testimit

Korrigjimi i mangësive të zbuluara gjatë testimit

Krijimi i një raporti testimi

T+18 muaj


T+18 muaj

119. Nënsistemi TP është lëshuar, ne funksion


Operacionale

T+20 muaj

Fillimi i aktivitetit (T): T+ 4 muaj

Fillimi i statusit: Korniza legjislative e miratuar nga parlamenti U miratua një skemë e re organizative ne DPT-së Është zbatuar organizimi dhe metodologjia e monitorimit tatimor të tatimpaguesve në sistemin TP


Përfundimi i statusit: Përfundimi i trajnimit te zyrtarëve të DPT-së

ID Dorëzimet


dorëzimit

120. Përgatitja e materialeve edukative

Ofertuesi Autoriteti Kontraktor

Krijimi i plani i trajnimit Krijimi i materialeve edukative Krijimi e prezantimeve

T+ 4 muaj

121. Certifikata e dokumentit Autoriteti Kontraktor Pranimi i Planit te trajnimit Pranimi i materialeve edukative

T+ 4 muaj

122. Trajnimi i zyrtarit të AT në kuadrin e ri ligjor


Mbajtja e seminareve, Workshop-e Zbatimi i procesit të vlerësimit të

njohurive të fituara

T+ 20 muaj

123. Trajnimi i zyrtarëve të AT Ofertuesi




T+ 20 muaj

124.

Trajnimi i zyrtarëve të DPT-së në sistemin e ri të monitorimit të taksapaguesve në sistemin TP




T+ 20 muaj

125. Procesi i trajnimit përfundoi Autoriteti Kontraktor Përfundimi i trajnimit te zyrtarëve të

AT T+ 20 muaj

Faqe 125 nga 140


Fillimi i statusit: Të gjitha komponentët e projektit të implementuara dhe të integruara TI në mjedisin e DPT-së


Përfundimi i statusit: Procesi i trajnimit ka mbaruar. Sistemi është i vendosur plotësisht. Nënshkrimi i fundit i proces verbalit Raporti përfundimtar është konfirmuar

ID Dorëzimet


dorëzimit

126. Përgatitja e raportit përfundimtar mbi shpërndarjen e sistemit


Krijimi i një sistemi të raportimit përfundimtar

Krijimi i një raporti përfundimtar mbi trajnimin e zyrtarëve të DPT-së

Krijimi i një raporti përfundimtar mbi trajnimin e zyrtarëve të DPT-së për të punuar me një sistem informacioni të integruar

T+23 muaj

127.

Konfirmimi i Raportit Përfundimtar mbi Projektin e Implementimit dhe Mbylljes së Projektit


Pranimi i sistemin e raportimit të implementimit përfundimtar

Raport përfundimtar mbi trajnimin e zyrtarëve të DPT-së

Një raport përfundimtar mbi trajnimin e zyrtarëve të DPT-së për të punuar me një sistem informacioni të integruar është pranuar

Projekti i përfunduar

T+23 muaj

Mbështetja dhe mirëmbajtja e sistemit


Fillimi i statusit: Konfirmimi i Raportit Përfundimtar mbi Projektin e Implementimit dhe Mbylljes së Projektit


Përfundimi i statusit: Përfundimi i mirëmbajtjes

ID Dorëzimet


dorëzimit

128. Përcaktimi i qëllimit dhe planit të mirëmbajtjes


Përcaktimi i Detyrave dhe Aktiviteteve

Përcaktimi kohës dhe metodat e reagimit, teknikat, mjetet dhe mbështetjen logjistike.

Përgatitja dhe nënshkrimi i marrëveshjeve të nivelit të shërbimit (SLAs)

T+ 23 muaj

129. Mirëmbajtja e licencave të produktit

Ofertuesi

Versione të reja të softuerit Menaxhimi ndryshimit Trajnimi i zyrtarëve të DPT-së Përditësimi i dokumentacionit

T+ 23 muaj

130. Zgjidhja e problemeve Ofertuesi

Pranimi dhe regjistrimi i gabimeve dhe devijimeve Mbështetje zgjidhja e problemeve

Trajnimi i zyrtarëve të DPT-së

T+ 23 muaj

131. Sigurimi i cilësisë Ofertuesi

Mjetet për menaxhimin dhe ndjekjen e sistemeve dhe proceseve kryesore

Mjete pro aktive dhe parandaluese për shmangien e problemeve teknike

Mjetet shtesë për përmirësimin e efikasitetit

Trajnimi i punonjësve te DPT-së Përditësoni dokumentacionin

T+ 23 muaj

132. Kërkesat për përmirësimet dhe funksionalitetin e ri


Përgatitni një kërkesë për ndryshim Merrni dhe miratoni përditësimet

T+ 23 Muaj

133. Zbatimi i funksioneve të reja Ofertuesi Përditësimi i dokumentacionit T+ 23 Muaj

134. Mbështet verifikimin përfundimtar mbi mbajtjen dhe mbarimin e mbajtjes


Mbarimi i mirëmbajtjes T+ 24 muaj

Faqe 126 nga 140

13.2 Lista e dokumenteve të dorëzimit

Për gjithë kohëzgjatjen e projektit, Ofertuesi është i detyruar t'ia dorëzojë Dokumentacionin e Projektit

Autoriteti Kontraktor. Listat e listuara e rezultateve për dërgesat individuale është vetëm një model i

përgjithshëm për përcaktimin e dokumenteve bazë.

Autoriteti Kontraktor pret që Ofertuesi të aplikojë metodologjinë e vet dhe më të përshtatshme për

dorëzimin e dokumentacionit. Në përputhje me metodologjinë e përdorur, Ofertuesi mund të modifikojë

listën e dokumenteve për një dërgesë të veçantë

Autoriteti kontraktues është i obliguar t'i dorëzojë ofertuesit sipas listës së dokumenteve në këtë kapitull

në kohë dhe në përputhje me afatet e dokumenteve të planit si rezultat i aktiviteteve dhe detyrimeve të

tij nga ky projekt

Ofertuesi është i detyruar në çdo kapitull të përcaktojë minimalisht:

a) Emri i dokumentit

b) Versioni i dokumentit

c) Data e dokumentit

Ofertuesi është i detyruar të paraqesë të gjithë dokumentacionin në formatin e mëposhtëm:

a) Formati i letrës - dokumentacioni i bashkangjitur në regjistrues. Dokumentacioni duhet të

numërohet.

b) Formati elektronik - në formatin PDF

Të gjitha dokumentet duhet të jetë në gjuhën shqipe.

Fazat e projektit Emri i dokumentit Lloji Përgjegjësia

Fillimi i projektit Vendimi për themelimin e strukturës organizative dhe logjistike të projektit

Dokumenti Autoriteti Kontraktor

Ofertuesi

Plani i projektit dhe Plani i sigurimit të cilësisë

Plani i projektit Dokumenti Ofertuesi

Metodologjia e zbatimit Dokumenti Ofertuesi

Plani i organizimit dhe burimeve Dokumenti Ofertuesi

Plani i testimit Dokumenti Ofertuesi

Plani i dokumentacionit Dokumenti Ofertuesi

Plani i trajnimit Dokumenti Ofertuesi

Plani dhe metodologjia e sigurimit të cilësisë

Dokumenti Ofertuesi

Përcaktimi i kritereve për përcaktimin e pranueshmërisë së produkteve të dorëzuara

Dokumenti Ofertuesi

Vlefshmëria dhe pranimi ose refuzimi i produkteve të dorëzuara

Dokumenti Ofertuesi

Konfirmimi i planit të Projektit

Konfirmimi i planit të Projektit dhe Plani i sigurimit të cilësisë

Procesverbalet nga Takimi i Projektit të BD

(Bordi i Drejtoreve)


Specifikimi i arkitekturës së sistemit dhe modelit

të biznesit

Specifikime të platformës së lartë të arkitekturës dhe teknologjisë

Dokumenti Ofertuesi

Modeli dhe specifikimi i punës se proceseve dhe organizimit të procesit

Dokumenti Ofertuesi

Specifikimi i pajisjeve të nevojshme, pajisjeve, softuerit të sistemit dhe softuerit të licencuar të palëve të treta për mjedisin e testimit, mjedisin e trajnimit dhe mjedisin e prodhimit.

Dokumenti Ofertuesi

Specifikimi i sigurisë së sistemit Dokumenti Ofertuesi

Vërtetimi i pranimit të arkitekturës së nivelit të lartë dhe Specifikimeve të platformës teknologjike




Konfirmimi i pranimit të Modelit dhe specifikimit të proceseve të procesit dhe organizimit




Faqe 127 nga 140

Verifikimi e pranimit të Specifikimeve të hardware, pajisjeve, software-it të sistemit dhe softuerit të licencuar nga palët e treta për testimin e mjedisit, mjedisit të trajnimit dhe mjedisit të produktit.




Kuadri legjislativ

GAP analiza e kuadrit ligjor Dokumenti Ofertuesi

Propozim i ri i kuadrit ligjdhënës Dokumenti Ofertuesi

Propozimi për ndryshimin e ligjeve të tjera tatimore

Dokumenti Ofertuesi

Propozim për ndryshimin dhe plotësimin e ligjeve të tjera të ndërlidhura

Dokumenti Ofertuesi

Vlerësimi i ndikimit të opsioneve të ndryshme

Dokumenti Ofertuesi


Dokumenti Ofertuesi

Përgjigjet ndaj pyetjeve gjatë seancës publike

Dokumenti Ofertuesi

Materialet e trajnimit për zyrtarët e DPT-së

Dokumenti Ofertuesi

Certifikata e Pranimit të Dokumenteve Procesverbalet nga

Takimi i Projektit të BD (Bordi i Drejtoreve)


Organizimi i brendshëm i DPT-së se Republikës

së Shqipërisë

GAP analiza e strukturës organizative Dokumenti Ofertuesi

Propozim i ri i kuadrit ligjdhënës Dokumenti Ofertuesi

Propozimi për ndryshimin e ligjeve të tjera tatimore

Dokumenti Ofertuesi

Propozim për ndryshimin dhe plotësimin e ligjeve të tjera të ndërlidhura

Dokumenti Ofertuesi

Vlerësimi i ndikimit të opsioneve të ndryshme

Dokumenti Ofertuesi


Dokumenti Ofertuesi

Përgjigjet ndaj pyetjeve gjatë seancës publike

Dokumenti Ofertuesi


Dokumenti Ofertuesi

Certifikata e pranimit të dokumenteve

Procesverbalet nga



Organizimi dhe metodologjia e

monitorimit tatimor të tatimpaguesve në

sistemin TP

GAP analiza e strukturës organizative Dokumenti Ofertuesi

Propozim i ri i metodologjisë së auditimit tatimor

Dokumenti Ofertuesi

Propozim për të ndryshuar rregulloret e tjera

Dokumenti Ofertuesi


Dokumenti Ofertuesi


Dokumenti Ofertuesi





Analizimi e biznesit dhe kërkesat teknike

Dokumenti Ofertuesi

Specifikimet e kërkesave të përdoruesit

Dokumenti Ofertuesi

Raporti i testimit të kryer Dokumenti Ofertuesi

Dokumentacioni teknik Dokumenti Ofertuesi

Manuali i përdorimit Materiali për e-Learning Ofertuesi


Materiali për e-Learning Ofertuesi




Dorëzim procesverbali Certifikata Operacionale e Pranimit


Regjistri i tatimpaguesve

Analizimi i punëve te biznesit dhe kërkesave teknike

Dokumenti Ofertuesi

Specifikimet e kërkesave të përdoruesve

Dokumenti Ofertuesi

Faqe 128 nga 140



Manuali i përdorimit Materiali për e-Learning

Ofertuesi






Procesverbali i migrimit të të dhënave Dokumenti Ofertuesi



Ofertuesi

Zyrat e Tatimpaguesve

Analizimi i punëve dhe kërkesave teknike

Dokumenti Ofertuesi


Dokumenti Ofertuesi



Doracaku i përdorimit Materiali për e-Learning Ofertuesi








Ofertuesi

Menaxhimi i organizimit të brendshëm të DPT-së


Dokumenti Ofertuesi


Dokumenti Ofertuesi











Ofertuesi

Prona e tatimpaguesit


Dokumenti Ofertuesi


Dokumenti Ofertuesi











Ofertuesi

Portali Qendror për Kontrollimin dhe Menaxhimin e

Tatimpaguesve në TP (PQKM)


Dokumenti Ofertuesi


Dokumenti Ofertuesi











Ofertuesi

Sistemi SMR për Sistemin e TP (Sistemi i Menaxhimit të Riskut)


Dokumenti Ofertuesi


Dokumenti Ofertuesi

Faqe 129 nga 140


Katalogu i riskut për nënsistemin TP Dokumenti Ofertuesi










Ofertuesi

Mbikëqyrja Online e tatimpaguesve në

sistemin TP


Dokumenti Ofertuesi


Dokumenti Ofertuesi











Ofertuesi

Sistemi për "Mbështetjen e

Inspektorëve të Taksave në Sistemin TP"


Dokumenti Ofertuesi


Dokumenti Ofertuesi











Ofertuesi

Aksesimi i sistemit me RTP npm tabletave me-

për tatimpaguesit


Dokumenti Ofertuesi


Dokumenti Ofertuesi











Ofertuesi

Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret.

Analiza e biznesit dhe kërkesave teknike

Dokumenti Ofertuesi


Dokumenti Ofertuesi

Raporti i testimit të ekzekutimit Dokumenti Ofertuesi



Materiali për trajnimin e zyrtareve te DPT-së


Certifikata e Pranimit të Dokumenteve


(Bordi i Drejtoreve) Autoriteti Kontraktor



Ofertuesi


Analiza e biznesit dhe kërkesave teknike

Dokumenti Ofertuesi


Dokumenti Ofertuesi

Raporti i aprovimit te testimit Dokumenti Ofertuesi

Faqe 130 nga 140





Certifikata i Pranimit të Dokumenteve


(Bordi i Drejtoreve) Autoriteti Kontraktor



Ofertuesi

ISMS

Krijimi i një shërbimi TI dhe përpunimi i regjistrit që përfshin informacione personale

Dokumenti Ofertuesi

Analiza e proceseve, të drejtave dhe detyrimeve

Dokumenti Ofertuesi

Krijimi i rekomandimeve për përafrimin me Rregulloren e Përgjithshme të Mbrojtjes së të Dhënave (GDPR)

Dokumenti Ofertuesi

Analiza e Ndikimit në Mbrojtjen e të Dhënave Personale nga Shërbimi dhe Përpunimi i të Dhënave

Dokumenti Ofertuesi

Plani i Përpunimit të Riskut Dokumenti Ofertuesi

Përgatitja e materialeve për Workshop-e


Hartimi i udhëzimeve për ndryshimin e kontratave të furnitorëve dhe konsumatorëve, dhe për të arritur përputhjen me GDPR

Dokumenti Ofertuesi

Raportet e analizës së pajtueshmërisë/përputhshmërisë së kryer me Rregulloren e Lartë të Nivelit të Lartë për Mbrojtjen e të Dhënave

Dokumenti Ofertuesi

Trajnimi i nëpunësve të AT-së

Plani i detajuar i trajnimitt Dokumenti Ofertuesi

Materiali e trajnimit për zyrtarët e DPT-së


Rezultatet e vlerësimit/evaluimit zyrtar sipas llojit të trajnimit

Dokumenti Ofertuesi

Pranueshmëria operacionale (integrimi i

plotë i sistemit) dhe mbyllja e projektit

Raport Përfundimtar mbi Sistemin e Zbatimit

Dokumenti Ofertuesi

Raporti final mbi trajnimine zyrtarëve të DPT-së

Dokumenti Ofertuesi

Raport Përfundimtar mbi Trajnimin e Zyrtarëve të DPT-së për të punuar me Sistemin e Integruar të Informacionit

Dokumenti Ofertuesi

Dorëzimi i procesverbalit Certifikata Operacionale e Vërtetimit/Pranimit


Ofertuesi

Mbështetja dhe mirëmbajtja e Sistemit

Specifikimi i detyrave dhe aktiviteteve, përcaktimi i kohës së përgjigjes dhe metodave, teknikave, mjeteve dhe mbështetjes logjistike gjatë periudhës së mirëmbajtjes

Dokumenti Ofertuesi

Raporti final mbi trajnimin e zyrtarëve të DPT-së

Dokumenti Ofertuesi

Marrëveshja e nivelit të shërbimit (SLA)

Dokumenti Ofertuesi

Raportet mujore të mirëmbajtjes Dokumenti Ofertuesi

Specifikimi i kërkesave të modifikimit / përmirësimit/rindërtimit të sistemit

Dokumenti

Autoriteti Kontraktor Ofertuesi

Dorëzimi i procesverbalit Certifikata Operacionale e Vërtetimit/Pranimit


Ofertuesi

Përditësimi dokumentacionit Dokumenti Ofertuesi

Raporti Përfundimtar mbi Mirëmbajtjen dhe Përfundimi i mirëmbajtjes


Ofertuesi

Tabela 1: Dokumentacioni që ofertuesi duhet të dorëzojë gjatë projektit

Faqe 131 nga 140

14 TË DREJTAT E KODIT PËR APLIKACIONIN

Të gjitha të drejtat mbi kodin burimor dhe dokumentacionin teknik i përkasin Autoritetit Kontraktues.

Sistemi do të dërgohet së bashku me kodin e burimit të strukturuar me komente, së bashku me

dokumentacionin teknik përfshirë dokumentacionin teknik të moduleve në veçanti dhe dokumentacionin

teknik në përgjithësi.

Faqe 132 nga 140

15 MONITORIMI I PERFORMANCËS DHE RAPORTIMI ANALITIK

15.1 Monitorimi i performancës

Për monitorimin e rregullt dhe matjen e performancës në AT do të kenë nevojë për një lidhje midis

planeve strategjike dhe operacionale dhe performancës. Megjithatë, ekziston një nevojë për një sërë

mjetesh që mundësojnë masat e performancës për të përmbushur qëllimet e përcaktuara, për të ndjekur

progresin në baza të rregullta dhe për të komunikuar me të gjithë strukturën e AT-së.

Kjo përshin detyrat e mëposhtme:

Demonstrimin dhe zhvillimin e strukturës së llogaridhënies brenda AT-së bazuar në aktivitetet e

mëposhtme:

o Krijimin e një kuadri metodologjik unik të menaxhimit të performancës që identifikon fushat

kryesore të matjes së performancës

o Krijimin e degëve strategjike që tregojnë qëllimet strategjike të nivelit të lartë në iniciativat,

proceset dhe veprimet strategjike

o Caktimin e punonjësve për punë në qëllime ose veprime strategjike

o Krijimin e skemës së përgjegjësive në hierarkinë e raportimit

Vlerësimin e efektivitetit të elementeve të strategjisë, segmenteve organizative dhe stafit të AT-

përmes:

o Zhvillimit e masave për kuantifikim të të dhënave që janë çelës për menaxhimin e proceseve

të punës siç janë trendët e evazionit fiskal etj.

o Krijimi i tabelave të rezultateve që vlerësojnë ecurinë e ndonjë nismë ose veprimi të veçantë

strategjik, pjesës organizative dhe menaxherit të saj, si dhe punonjësve individualë

o Monitorimi dhe reagimi ndaj ndryshimeve duke përdorur abonimin për njoftimet që

pjesëmarrësit paralajmërojnë kur kryejnë masat kryesore të punës larg sferës së pranueshme

Gjenerimin e raporteve që pasqyrojnë ecurinë e nismave strategjike, elementeve të përgjegjësisë

dhe punonjësve

15.2 Raportimi i Analitikes

Sistemi duhet të sigurojë monitorimin e punës së inspektorëve, bazuar në metodologjinë e punës, sipas

kritereve në vijim:

Numri total i mbikëqyrjes së pagesave në para të gatshme

Numri total dhe llojet e masave tatimore të vendosura ndaj tatimpaguesve

Analiza e numrit dhe strukturës së mbikëqyrjes tatimore

Analiza e numrit të mbikëqyrjeve nga njësitë organizative të AT-së

Analiza e numrit të kërkesave të monitorimit të pranuara dhe të përpunuara

Analiza e ngarkesës së punës së inspektorit për kontrollin e pagesës në para të gatshme, kohën

e përgjigjes ndaj kërkesës dhe numrin e kërkesave të përpunuara

Trendet e veprave të përsëritura

Trendet totale të veprave

Monitorimi i performancës së sistemit nga perspektiva e monitorimit të trendeve të mbledhjes së

tatimeve

Faqe 133 nga 140

16 KËRKESAT JO-FUNKSIONALE DHE TEKNIKE

16.1 Performanca e kërkuar e sistemit

Karakteristikat në vijim kërkohen për të mbështetur MKF-së:

Për sistemin transaksional:

Koha e punës është 24/7/365

2000 mesazhe në sekondë

Përgjigje nën 1 sekondë për 90% të mesazheve

Niveli SLA 99.95

RPO = 0, RTO = 0 me kusht që të ekzistojë rimëkëmbja nga dështimit:

Sistemi i Raportimit të Punës

Orari i Punës: Standard për Zyrtarët e Administratës Tatimore

SLA 99.95, parametrat e disponueshmërisë lidhen me kohën e punës së sistemit

16.2 Kërkesat e përgjithshme

o Mbështetja e gjuhëve: Të gjitha teknologjitë informative duhet të ofrojnë mbështetje në gjuhën

shqipe. Në veçanti, të gjitha teknologjitë dhe softueri i ekranit duhet të mbështesin grupin e

karaktereve ISO 8859-2 dhe të lejojnë opsionet e klasifikimit në përputhje me alfabetin shqiptar

o Sistemi duhet të ndahet të paktën në nivelet e mëposhtme:

o niveli i të dhënave, o niveli i logjikës së punës, o niveli i prezantimit

o Çdo transaksion është e nevojshme të regjistrohet veçmas:

o bazuar në dokumentin në të cilin ka ndodhur transaksioni, o kush ka vepruar si nxitës i transaksionit kur është realizuar transaksioni ("afati kohor"), o kush e ka miratuar transaksionin (nëse është e nevojshme).

16.3 Ndërfaqja e përdoruesit

o Ndërfaqja e përdoruesit duhet të dorëzohet në gjuhën shqipe

o Sistemi dhe/ose nënsistemet do të kenë një WEB ndërfaqe të përdoruesit kompatibile me

shfletuesit e mëposhtëm;

o Chrome o Internet Explorer o Mozilla Firefox o Safari o Etj

o Navigacioni duhet të jetë unik, i thjeshtë, kontekstual dhe konfiguruar përmes lidhjeve të

përshtatshme

16.4 Siguria

o Përdoruesit e sistemit do të jenë

o Zyrtarët e DPT-së o Zyrtarë të organeve publike juridike të Republikës së Shqipërisë o Personat me autoritet publik të Republikës së Shqipërisë o Tatimpaguesit e Republikës së Shqipërisë o Qytetarët e Republikës së Shqipërisë o Përdoruesit e huaj në përputhje me rregulloret e veçanta të Republikës së Shqipërisë

o Aksesimi në sistemet e transaksionit duhet të jetë HTTPS si dhe aplikacionet publike të

internetit.

o Është e nevojshme të përdoren Certifikatat nga organi i caktuar. Protokolli i komunikimit duhet

të jetë të paktën TLS 1.2 ose më i ri.

Faqe 134 nga 140

o Kanali i sistemit të transaksionit duhet të përdorë shërbimet e mbrojtjes së sigurisë DDoS.

Mungesa e disponueshmërisë e shkaktuar nga një sulm DDoS nuk është një parametër që

përcakton disponueshmërinë ndaj SLA

o Është e nevojshme përmbajtja me të gjitha rregullat pozitive që rregullojnë çështjen e

përcaktimit të karakteristikave të përdoruesit si dhe parametrave të tjerë të sistemit të

informacionit të sigurisë

o Në çdo pikë ku ka ndërveprime midis përdoruesit dhe sistemit, si dhe në komponentët që janë

pjesë e sistemit, janë të nevojshme për të zbatuar masat e sigurisë të bazuara në role

o Kërkohet verifikimi i besueshmërisë së përdoruesit të sistemit, pas së cilës është e mundur,

bazuar në rolin e tyre, të përcaktohet autorizimi për të përdorur funksionalitetin e sistemit

o Siguria e të gjitha nënsistemeve duhet të mbështesë premisën themelore që "një përdorues që

nuk ka të drejtë për një funksion brenda një nënsistemi as nuk e sheh këtë funksion"

o Siguria dhe hyrja në sistem dhe nënsisteme duhet të përcaktohen në nivel:

o Bazat e të dhënave o Ndërfaqja GUI

o Kontrolli i të drejtave të aksesit në funksione specifike duhet të implementohet në nivelin e

kontrollit gjatë ngarkimit të çdo faqe WEB individuale në raport me përdoruesin e raportuar

o Siguria Sistemit duhet të përfshijë

o Kontrollimi i aksesit dhe regjistrimi në nivel aplikimi. Është e nevojshme të sigurohet autenticiteti i secilit përdorues individual përmes një identifikuesit individual për regjistrim dhe fjalëkalime.

o Kontrolli i aksesit dhe identifikimi në nivelin e ekranit. Disa përdorues do të kenë të drejtë aksesi vetëm në disa kategori (për shembull, të drejtat e administratorit të sistemit lejojne pamjen e te gjitha kategorive).

o Kontrolli i aksesit dhe regjistrimi në nivel funksional. Hyrja në disa pamje dhe funksione të caktuara do të jetë e mundur vetëm për disa përdorues. Për shembull, disa përdorues do të kenë hyrje të drejtë në opsionin e fshirjes, ndërsa të tjerët nuk do të jenë në gjendje ta bëjnë këtë.

o Administrimi i konfigurimeve të sigurisë së sistemit dhe nënsistemit (ARMS – Aplication rights

management system) duhet të jetë një sistem i veçantë.

o Sistemi dhe nënsistemet, nga aspekti i sigurisë dhe drejtës së aksesit, duhet të jenë të integruar

dhe të përdorin informacionin mbi akreditimet e përdoruesve nga lista e emrave të nënsistemit

SMDA dhe katalogut të sistemit SMDA

o Aksesi në nënsistemin SMDA do të kenë vetëm zyrtarët me akreditime speciale

o Nënsistemi SMDA duhet të lejojë administrimin dhe përcaktimin e të drejtave të futjes në sistem

dhe çdo nënsistem, modulet e tij, faqet WEB ose funksionet individuale, duke përfshirë

dhënien, kufizimin, ndalimin ose futjen e pjesshme ose përdorimin e sistemit ose nënsistemit,

modulet e tyre dhe WEB faqet individuale ose funksionet e bazuara në të drejtat e përdoruesit

për akses.

o Nënsistemi SMDA duhet të sigurojë administrimin e të drejtave të futjes në mënyrë të tillë që

sistemi dhe nënsistemet, modulet e tij, WEB faqet dhe funksionet për të cilat përdoruesi nuk ka

të drejta, nuk do të drejtohen ose shfaqen tek përdoruesi

o Në nënsistemin SMDA duhet të integrohet katalogu i nënsistemit. Katalogu i nënsistemit duhet

të përmbajë një listë të të gjithë Nënsistemeve dhe moduleve të tyre që janë pjesë e këtij DT-

je me meta data përkatëse me mundësin e menaxhimit të të dhënave meta.

o Nënsistemi SMDA duhet të integrojë Katalogun e të gjitha nënsistemeve të WEB me të dhëna

meta relevante me mundësi për të menaxhuar të ”metadata”. Ky katalog duhet të lidhet me

katalogun e nënsistemit

o Në nënsistemin SMDA duhet të integrohet një katalog i të gjitha funksioneve të nënsistemit me

”metadata” përkatëse me mundësi të menaxhimit të “metadatave”

o Nënsistemi SMDA duhet të mundësojë lidhjen e të dhënave nga katalogu i funksionit me të

dhënat e Katalogut nga WEB faqja e nënsistemit

o Nënsistemi SMDA duhet të jetë një katalog i integruar i emërimeve të të gjithë përdoruesve të

sistemit

Faqe 135 nga 140

o Të dhënat në katalog të përdoruesve duhet të jenë në gjendje të shkarkohen dhe azhurnohen

automatikisht nga një server i direktorisë me informacionin e përdoruesit të sistemit. Ofertuesi

kërkohet që të zhvillojë dhe implementojë shërbimet e nevojshme të WEB për të shkarkuar dhe

azhurnuar të dhënat mbi përdoruesit nga shërbimi i listës së emrave.

o Nënsistemi SMDA duhet gjithashtu të mundësojë futjen manuale të përdoruesve në katalogun

e përdoruesve

o Nënsistemi SMDA duhet të lejojë një administrator të menaxhojë përdoruesit e sistemit duke u

caktuar atyre, individualisht ose në masë, rolet dhe duke krijuar një hierarki të autorizimit të

përdoruesit

o Nënsistemi SMDA duhet të lejojë administratorin të përcaktojë të drejtat/kufizimet e futjes në të

dhënat e tatimpaguesit për përdoruesit e Sistemit dhe/ose Nënsistemit

o Nënsistemi i SMDA-së duhet të mundësojë krijimin e një grupi të tatimpaguesve bazuar në

kriterin e të drejtës së futjes në të dhëna, përkatësisë gjeografike, përkatësisë organizative të

tatimpaguesit tek organi kompetent organizativ i DPT-ës

o Futja në sistem do të evidentohet automatikisht. Evidentimi do të përmbajë informacione të

detyrueshme si më poshtë: ora, përdoruesi, aplikacioni/moduli i aplikacionit, të dhënat e

sesionit. Të dhënat e sesionit do të varen nga aplikacioni, por duhet të kenë identifikuesin e

tatimpaguesit të zgjedhur nga përdoruesi

o Për të gjitha të dhënat që ruajnë sistemi dhe/ose nënsistemet në bazën e të dhënave duhet të

ofrohen masa sigurie që parandalojnë përdoruesit keqdashës nga futja e paautorizuar në të

dhëna.

o Baza e të dhënave që mbështet sistemin dhe/ose nënsistemet duhet të jetë mjaft e fuqishme

për të ruajtur të dhënat gjatë viteve të përcaktuara

o Ndryshimet e të dhënave duhet të evidentohen në një mënyrë që lejon ndjekjen e ndryshimeve

dhe identifikimin e përdoruesve që kanë bërë ndryshimet.

16.5 Mjedisi i sistemit dhe administrimi

Duke pasur parasysh ndryshimet e shpeshta në sistemin e taksave (ndryshimet në ligjet tatimore,

ndryshimet në bazën e të dhënave të tatimpaguesit në të cilat bazohet sistemi, ndryshimet në sjelljen

e tatimpaguesve, ndryshimet në procedurat e trajtimit tatimor etj.), shpesh do të ketë nevojë për

azhurnimin e sistemit. Ofertuesi duhet të ofrojë një sistem të konfigurimit i cilit do të jetë i thjeshtë dhe

në të cilin DPT-ja do të jetë në gjendje të bëjë konfigurimin e nevojshëm nëse është e nevojshme.

Ofertuesi duhet të japë shpjegime se cilat parametra të sistemit të ofruar mund të konfigurohet dhe si.

o Nënsistemet duhet të sigurojnë mbrojtjen e të dhënave nga hyrjet e paautorizuar ose

aksidentale në të dhëna

o Për të testuar sistemin

o DPT-ja do të japë të dhënat e testimit dhe do të sigurojë që rezultatet e testimit të mos

kenë ndikim në sistem me të dhëna reale;

o Të dhënat reale të DPT-ës mund të përdoren gjithashtu për testimin e sistemit.

o Sistemi duhet të jetë funksional, i besueshëm dhe të rimerret shpejt pas defekteve

o Ofertuesi duhet të bëjë udhëzime të hollësishme për rimëkëmbjen e sistemit ne menyre të qarta

dhe logjike. Udhëzimet duhet të përcaktohen sipas metodologjisë së “nese – atehere”

o Sistemi i integruar duhet të evidentojë automatikisht të gjitha proceset (duhet të ketë

një gjurmë të tyre)

Faqe 136 nga 140

16.6 Kërkesat harduerike

16.7 Menaxhimi i të dhënave

16.7.1.1 Baza e të dhënave Oracle Exadata Database për bazat e të dhënave transaksionale

(OLTP)

Baza e vetme e të dhënave Oracle Exadata Baza e gjeneratës së fundit me Oracle Exadata Storage

Server software dhe licencat e softuerit Oracle Database

Kërkesat minimale per pajisjet Oracle Exadata Database:

Rack 42 U

Pajisjet fizike duhet te jene te reja dhe po ashtu dhe versionet e softeve

Dy serverë të bazës së të dhënave, secila me: min. 24 core Intel dhe min. 384GB memorie, porta

10Gb ethernet ose F OptikeTre Servera Storage Exadata, secila me: min. 10 core Intel dhe min.

192GB memorie, 6x 10TB disqe me min. 7,200 RPM dhe 2x min. 6.4TB NVMe PCIe 3.0 Flash

Totali i kapacitetit të diskut duhet te jete min. 50 TB të përdorshëm, të pa kompresuar, me

redundancë të lartë (pasqyrim në 3 drejtime). Kapaciteti i përdorshëm matet duke përdorur fuqitë

normale të 2 hapësirave terminologjike me 1 TB = 1024 * 1024 * 1024 * 1024 bytes.

Duhet te kete te pakten 2 PDU per shpërndarjes së energjisë (PDU)

Dy switch me min. 36-portesh QDR 40 Gb / s InfiniBand

Oracle Exadata Storage Server software – min. 18 disqe me përdorim të plotë të licencave të

përhershme

Mbështetje teknike e përfshirë për hardware Oracle Exadata Database Machine

Disponueshmëria e lartë e komponentëve harduare pa mundësi të dështimit që mund të ndikojë

në sistemin si tërësi

Arkitektura e shkallëzuar që mund të akomodojë rritjen e ngarkesës së punës dhe të lejojë

zgjerimin e përsosur nga konfigurimet e vogla në të mëdha duke shmangur pengesat në

performancës

Instaluar dhe konfiguruar në qendrën e të dhënave primare

Kërkesat minimale të softuerit Oracle Database:

Oracle Database Enterprise Edition - 8 Procesor i cili shfrytëzon plotësisht licencat e përhershme

Zbatim në bazë të të dhënave aktiv-aktiv me hapësirë ruajtje të përbashkët për disponueshmëri

të lartë

Mjetet grafike të integruara ueb për monitorimin dhe diagnostifikimin e performancës automatike

të bazës së të dhënave, raportimin e performancës dhe disponueshmërisë.

Mjetet grafike të integruara për akordimin automatik të SQL dhe monitorimin në kohë reale të

SQL

Maskim dinamik i integruar i të dhënave të ndjeshme në ekran dhe shifrim të të dhënave në

pjesën tjetër me menaxhimin e integruar të çelësave, transparent për aplikimet e bazës së të

dhënave

Zgjidhjen e integruar të rimëkëmbjes nga dështimet dhe të mbrojtjes së të dhënave që mund të

mbajnë në mënyrë transparente një kopje të bazave të të dhënave në kohë reale dhe të ofrojnë

mbrojtje të plotë nga dështimet primare të bazave të të dhënave në faqe. Bazat e të dhënave të

gatishmërisë duhet të hapen për operacione për lexim dhe përditësohen nga baza kryesore në

të njëjtën kohë për të shkarkuar raportimin dhe ruajtjen nga bazat e të dhënave primare. Zgjidhja

duhet të mundësojë riparimin automatik ne menyre qe sistemi te jete gjithmone aktiv.

Faqe 137 nga 140

16.7.1.2 Baza e të dhënave Oracle Exadata Database për bazat e të dhënave analitike dhe

databaza e të dhënave (DWH)

Baza e vetme e të dhënave Oracle Exadata Baza e gjeneratës së fundit me Oracle Exadata Storage

Server software dhe licencat e softuerit Oracle Database dhe një vit mbështetjeje teknike.

Kërkesat e pajisjes për Minimum Oracle Exadata Database:

Rack 42 U Dy serverë të bazës së të dhënave, secila me: 24 core Intel dhe 384GB memorie

10Gb Ethernet ose Fiber optike

Tre Servera Storage Exadata, secila me: min. 10 cores Intel dhe min. 192GB memorie, 6x 10TB

disqe min. 7,200 RPM dhe 2x min. 6.4TB NVMe PCIe 3.0 Flash

Totali i kapacitetit të diskut 50 TB të përdorshëm të pa kompresuar, me redundancë të lartë

(pasqyrim në 3 drejtime). Kapaciteti i përdorshëm matet duke përdorur fuqitë normale të 2

hapësirave terminologjike me 1 TB = 1024 * 1024 * 1024 * 1024 bytes.

Duhet te kete te pakten 2 PDU per shpërndarjes së energjisë (PDU)

Dy switche me min. 36-portesh QDR 40 Gb / s InfiniBand

Oracle Exadata Storage Server software - 18 disqe përdorim të plotë të licencave të përhershme

Mbështetje teknike e përfshirë për hardware Oracle Exadata Database Machine, sistemin

operativ

Disponueshmëria e lartë e komponentëve hardware pa mundësi të dështimit që mund të ndikojë

në sistemin si tërësi

Arkitektura e shkallëzuar që mund të akomodojë rritjen e ngarkesës së punës dhe të lejojë

zgjerimin nga konfigurimet e vogla në të mëdha duke shmangur pengesat e performancës


Kërkesat minimale të softuerit Oracle Database:

Oracle Database Enterprise Edition - 8 Procesor i cili shfrytëzon plotësisht licencat e përhershme

Zbatim në bazë të të dhënave aktiv-aktiv me hapësirë ruajtje të përbashkët për disponueshmëri

të lartë

Mjetet grafike të integruara ueb për monitorimin dhe diagnostifikimin e performancës automatike

të bazës së të dhënave, raportimin e performancës dhe disponueshmërisë.

Mjetet grafike të integruara për akordimin automatik të SQL dhe monitorimin në kohë reale të

SQL

Maskim dinamik i integruar i të dhënave të ndjeshme në ekran dhe shifrim të të dhënave në

pjesën tjetër me menaxhimin e integruar të çelësave, transparent për aplikimet e bazës së të

dhënave

Zgjidhjen e integruar të rimëkëmbjes nga dështimet dhe të mbrojtjes së të dhënave që mund të

mbajnë në mënyrë transparente një kopje të bazave të të dhënave në kohë reale dhe të ofrojnë

mbrojtje të plotë nga dështimet primare të bazave të të dhënave në faqe. Bazat e të dhënave të

gatishmërisë duhet të lejojne leximin e operacioneve dhe përditësohen nga baza kryesore në të

njëjtën kohë për të shkarkuar raportimin dhe ruajtjen nga bazat e të dhënave primare. Zgjidhja

duhet të mundësojë riparimin automatik ne menyre qe sistemi te jete gjithmone aktiv.

16.8 Shtresa e mesme

16.8.1.1 Balancues i ngarkesës së harduerit në Nënsistemin e integrimit (Redundance)

Pajisja fizike duhet te jete e re dhe sistemi i azhornuar

I përshtatshëm për ndryshime dhe i vendosur në opsionin aktiv - pasiv

Dy (2) serverë identikë me konfigurim minimal ose me te mire:

o x86 CPU e brezit të fundit me minimum 8 core per CPU me frekuencë 2.2GHz

Faqe 138 nga 140

o Memoria minimale 32 GB DDR4

o Minimum 2x SSD 240Gb SATA

o Kontrollues hardware RAID

o 4x Gigabit Ethernet LAN

16.8.1.2 Balancues i ngarkesës së harduerit për nënsistemet e tjera (Redundance)

Pajisja fizike duhet te jete e re dhe sistemi i azhornuarI përshtatshëm për ndryshime dhe i

vendosur në opsionin aktiv - pasiv

Dy (2) serverë identikë me konfigurim minimal ose me te mire:

o x86 CPU e brezit të fundit me minimum 8 core per CPU me frekuencë min. 2.2GHz

o Memoria minimale 32 GB DDR4




16.8.1.3 Hardueri kryesor i pajisjes virtuale (Redundance)

Pajisja fizike duhet te jete e re dhe sistemi i azhornuarTetë (8) serverë identikë x86 në grup me

kërkesat minimale të hardware për server ose me te mire:

o Dy (2) x86 CPU të brezit të fundit. Çdo CPU duhet të ketë të paktën 10 cores Frekuenca

min. 2.2GHz; dhe 13MB L3 cache

o Minimum 256 GB memorie DDR4 2666 MHz

o 2 x 1 / 10GbE Base-T porta Ethernet

o 4 x 1 / 10GbE SFP + porta Ethernet

o Portin e dedikuar të menaxhimit ILOM të Ethernet RJ-45

o 3 x PCI-Express 3.0 slot PCI

o 12 Gb / sec SAS-3 RAID Nivelet e mbështetjes HBA: 0, 1, 5, 6, 10, 50 dhe 60 me memorien

2GB flash-backed write-back

o 2 x 480GB SATA SSD M.2, ose ekuivalent në kapacitet dhe performancë

o 1 × Porta e jashtme USB

o Fuqia redundant dhe hot-swap, 220V, 50Hz

o Kabllot e rrymës të përfshirë

Një hypervisor i instaluar dhe funksional për ekzekutimin e serverëve virtual të hostuar me

sistem operativ të certifikuar dhe nevojshë për zbatim të anëtarëve fizikë të Shtresës qendrore

16.8.1.4 Harduer për menaxhim të mjedisit virtual (Redundance)

Një (1) server me konfigurim minimal ose me i mire:

o x86 CPU e brezit të fundit me minimum 8 core per CPU dhe një frekuencë min. 2.2GHz

o Memorie minimale 16 GB DDR4




16.9 Shtresa e bazës për ruatje

Pajisja e propozuar për ruajtje (Backup) në disk duhet të plotësojë kërkesat teknike të mëposhtme:

Pajisja fizike duhet te jete e re dhe sistemi i azhornuarPërfshin të paktën dy kontrollorë aktiv

aktiv me min. 360 GB memorie

Çdo kontrollues duhet të përfshijë të paktën portat lidhëse të mëposhtme: 3 × 1/10 Gb / s Base-

T Ethernet, 2 × 1/10 Gb / s SFP + Ethernet dhe 4 × QDR 40 Gb / s InfiniBand

Faqe 139 nga 140

Minimumi 400 GB flash / SSD me catche të optimizuar

Minimumi 95 TiB (i pakompresuar) me kapacitet të përdorshëm pas mbrojtjes së dyfishtë

Duhet të zgjerohet ne të paktën 1.2 PB të kapacitetit RAW

Mbështetje për protokollet NFS, CIFS dhe iSCSI. Nëse nevojiten licenca shtesë për protokollet

e përmendura, ato duhet të ofrohen nga ofertuesi.

Te suportoje snapshot, klonim, deduplikimin në rresht, ngjeshje, provizionim, (cyphering) dhe

licencat e replikimit nga distanca

Softuar për menaxhim të monitorimit, raportimin e gabimeve dhe hyrjeve, analizë të

performancës dhe monitorim të ngarkesës së punës.

Mbështet funksionin ”call-home”

Mbështetje teknike për harduerin e sistemeve të ruajtjes, sistemin operativ dhe softuerin


16.10 Kërkesa të tjera teknike dhe jo teknike

16.10.1 CERTIFIKIMI ELEKTRONIK (NËNSHKRIM ELEKTRONIK)

Siguria e futjes në Sistem e përdoruesve të jashtëm duhet të përcaktohet duke përdorur certifikatat

elektronike, nivelin standard të sigurisë FIPS 140-3. Certifikata elektronike (nënshkrimi elektronik) duhet

të përdoret me qëllim të vërtetimit të tatimpaguesit dhe nënshkrimit elektronik të të dhënave në faturë.

Qëllimi i certifikatës elektronike është autenticiteti i padiskutueshëm i tatimpaguesit, i cili është i

besueshëm dhe i sigurt për Administratën Tatimore dhe garanton që fatura vjen nga ai tatimpagues

dhe gjate dergimit te fatures behet i mundur integriteti i te dhenave.

Një certifikatë me nenshkrim elektronik lejon përdorimin e nenshkrimit elektronik ne nje dokument

elektronik që garanton integritetin e përmbajtjes së nënshkruar, duke siguruar kështu që të dhënat në

faturë nuk janë ndryshuar pas nënshkrimit në procesin e dërgimit të të dhënave nga tatimpaguesi në

DPT

Certifikata me nenshkrim elektronik ofrohet nga Agjencia Kombetare e Shoqerise se Informacionit, i cili

eshte i vetmi institucion qendror shteteror qe ka te ngritur infrastrukturen Qeveritare PKI,

Vlefshmeria e certifikates elektronike eshte 1 vit. Pas afatit 1 –vjecar eshte i detyrueshem rinovimi i saj.

Pajisja me certifikatës elektronike mund të kërkohet ekskluzivisht nga tatimpaguesi i cili është pagues i

nënsistemit TP dhe TJP.

Specifikimi i kërkesave jofunksionale

Ofertuesi duhet të studioje infrastrukturen PKI te AKSHI-t , ne menyre qe te beje te mundur

integrimin e sistemit me kete infrastrukture.

Ofertuesi duhet të sigurojë që sistemi të përdor një certifikatë me nenshkrim elektronik

E njëjta certifikatë me nenshkrim elektronik për Nënsistemet TP dhe TJP duhet të përdoret ()

në shumë pika të shitjes dhe në shumë pajisje për një tatimpagues, pavarësisht nga numri i

degëve të tatimpaguesve.

Sistemi dhe/ose nënsistemet duhet të përdorin infrastrukturën e PKI për të siguruar vërtetësinë

e dokumenteve elektronike në kontakt me tatimpaguesin dhe me pjesëmarrësit e tjerë.

Skedari i firmosur elektronikisht duhet të ekzekutohet me një certifikatë të kualifikuarte

nenshkrimit elektronik .

Sistemi dhe/ose Nënsistemet duhet të mundësojnë nënshkrimin elektronik të dokumenteve të

lëshuara nga DPT-ja nga një ose më shumë aktorë (zyrtari, eprorët, sistemi në emër të DPT-

ës)

Faqe 140 nga 140

Sistemi dhe/ose Nënsistemet duhet të integrohen me dorëzimin elektronik të dokumenteve tek

tatimpaguesi dhe marrjen e dokumenteve elektronike nga tatimpaguesi

Documents

Përmirësimi i modulit të menaxhimit të kontrollit të faturimit