View
0
Download
0
Category
Preview:
Citation preview
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>
<Emri dhe Mbiemri> <Emri dhe Mbiemri>
<Nënshkrimi> <Nënshkrimi>
Personi për kontakt: Kontrolluar ga: Përgjegjësi për siguri në
TIK
<Emri dhe Mbiemri> <Emri dhe Mbiemri>
<Nënshkrimi> <Nënshkrimi>
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
4. Në raport nuk ka rresht 1
5. Në raport nuk ka rresht 2
6. Ne raport nuk ka rresht 3
7. Ne raport nuk ka rresht 4
8. Ne raport nuk ka rresht 5
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.
13. Rreshti 5 nuk i ka të gjitha fushat.
Faqe 12 nga 140
14. Rreshti 10 nuk i ka të gjitha fushat.
15. Rreshti 16 nuk i ka të gjitha fushat.
16. Rreshti 17 nuk i ka të gjitha fushat.
17. Rreshti 18 nuk i ka të gjitha fushat.
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ë.
22. Rreshti 20 nuk i ka të gjitha fushat.
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
o Përmbledhja tabelore e të dhënave duhet të shfaqë analitiken e nënsistemit TP nga
njësitë AT sipas kriterit të shumës totale të faturave të lëshuara
o Përmbledhja tabelore e të dhënave duhet të shfaqë analitiken e nënsistemit TP nga
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ë
lëshuar një faturë e re, ose shuma ka pasur një reduktim domethënës
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ë
lëshuar një faturë e re, ose shuma ka pasur një reduktim domethënës
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
Kërkesat themelore funksionale që duhet të sigurohen janë si më poshtë:
Ç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.
Kërkesat themelore funksionale për të siguruar janë si më poshtë:
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.
Kërkesat themelore funksionale për të siguruar janë si më poshtë:
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
Kërkesat themelore funksionale për të siguruar janë si më poshtë:
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
Kërkesat themelore funksionale që duhet të sigurohen janë si më poshtë:
Ë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
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.
Kërkesat themelore funksionale për të siguruar janë si më poshtë:
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ë
Kërkesat themelore funksionale për të siguruar janë si më poshtë:
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.
Kërkesat themelore funksionale që duhet të sigurohen janë si më poshtë:
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ë:
Specifikimi i kërkesave funksionale
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.
Kërkesat themelore funksionale që duhet siguruar janë si më poshtë:
Specifikimi i kërkesave funksionale
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.
Kërkesat themelore funksionale që duhet siguruar janë si më poshtë:
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.
Balancues të ngarkesës
Server HTTP
Serveri i aplikacionit JAVA
Anëtar 1 ... Anëtar N
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.
Balancues të ngarkesës
Server HTTP
Serveri i aplikacionit JAVA
Anëtar 1 ... Anëtar N
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)
Komponent teknik fizik i
serverit për Java
aplikacione në cilësinë e
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)
Komponent teknik fizik i
serverit për Java
aplikacione në cilësinë e
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)
Komponent teknik fizik i
serverit për Java
aplikacione në cilësinë e
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
Komponent teknik fizik i
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)
Komponent teknik fizik i
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)
Komponent teknik fizik i
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)
Komponent teknik fizik i
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)
Komponent teknik fizik i
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
Disponueshmëri e lartë dhe redundancë e komponentëve harduerik pa asnjë mundësi të vetme
për dështim (en. no single point of failure), të cilat mund të ndikojnë në sistem si 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ë
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
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 si 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ë
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
ekuivalent Processor 8
Oracle BI Suite Extended Edition ose ekuivalent Processor 2
Oracle BI Data Visualization ose ekuivalent Processor 2
Oracle WebLogic ServerEnterprise Edition ose
ekuivalent Processor 28
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 aktivitetit: T+ 60 ditë
Përfundimi i statusit: Konfirmimi i planit te projektit
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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 aktivitetit (T): T+ 60 ditë
Fillimi i statusit: Krijimi i një organizimi të projektit dhe mbështetja logjistike Është konfirmuar plani i projektit
Përfundimi i aktivitetit: T+ 120 ditë
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
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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 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 aktivitetit: T+ 210 ditë
Përfundimi i statusit: Prodhimi i "Regjistrit të tatim paguesve"
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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"
Administrata Tatimore
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 aktivitetit (T): T+ 210 ditë
Fillimi i statusit: Prodhimi/Produkcioni i "Regjistrit të Tatimpaguesve"
Përfundimi i aktivitetit: T+ 270 ditë
Përfundimi i statusit: Prodhimi/Produkcioni i "Regjistrit të Tatimpaguesve"
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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
e kërkesave të përdoruesit"
T+230 ditë
Faqe 115 nga 140
Fillimi i aktivitetit (T): T+ 210 ditë
Fillimi i statusit: Prodhimi/Produkcioni i "Regjistrit të Tatimpaguesve"
Përfundimi i aktivitetit: T+ 270 ditë
Përfundimi i statusit: Prodhimi/Produkcioni i "Regjistrit të Tatimpaguesve"
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
18.
Verifikimi i dokumentit "Specifikimet e Kërkesave të Përdoruesit" për "Zyrat e Tatimpaguesve"
Autoriteti Kontraktor Administrata Tatimore
Autoriteti Kontraktor ka konfirmuar "Specifikimin e Kërkesave të Përdoruesit«
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
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+255 ditë
21. Testimi nga zyrtarët e DPT-së Ofertuesi
Njohja me një zyrtar të DPT-së me një plan testimi
Testime në përputhje me planin e testimit
Korrigjimi i mangësive të zbuluara Krijimi i një raporti testimi
T+255 ditë
22. 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+265 ditë
23. Është ne publikim nënsistemi i "Zyrës së Taksapaguesve"
Autoriteti Kontraktor Dorëzimi i procesverbalit Lëshimi i Certifikatës se Mundësisë
Operacionale T+270 ditë
Prona e tatim paguesit
Fillimi i aktivitetit (T): T+ 210 ditë
Fillimi i statusit: Prodhimi/Produkcioni i "Regjistrit të Tatimpaguesve"
Përfundimi i aktivitetit: T+ 17 muaj
Përfundimi i statusit: Prodhimi/Produkcioni i "Regjistrit të Tatimpaguesve"
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
24.
Analiza e Bizneseve dhe Kërkesave Teknike për Zhvillimin dhe Zbatimin e Modulit "Pasuritë e Tatimpaguesve"
Ofertuesi
Analiza e kërkesave të biznesit të Autoriteti Kontraktor
Analiza e kërkesave teknike dhe mjedisit
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
e kërkesave të përdoruesit"
T+8 muaj
25.
Analiza e Biznesit dhe Kërkesat Teknike për Zhvillimin dhe Zbatimin e Modulit të "Pasurive të Tatimpaguesve"
Administrata Tatimore
Autoriteti Kontraktor ka konfirmuar "Specifikimin e Kërkesave të Përdoruesit«
T+9 muaj
26.
Zhvillimi dhe implementimi i modulit "Patundshmëritë e tatim paguesve"
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+10 muaj
27.
Zhvillimi dhe implementimi i modulit "Luhatshmeria e tatim paguesve"
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+11 muaj
28.
Zhvillimi dhe zbatimi i modulit "Pasuritë financiare të tatimpaguesit"
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
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
Fillimi i aktivitetit (T): T+ 210 ditë
Fillimi i statusit: Prodhimi/Produkcioni i "Regjistrit të Tatimpaguesve"
Përfundimi i aktivitetit: T+ 17 muaj
Përfundimi i statusit: Prodhimi/Produkcioni i "Regjistrit të Tatimpaguesve"
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
30.
Zhvillimi dhe implementimi i modulit "Regjistri qendror i vlerësimit të pasurive/aseteve"“
Ofertuesi
Dizajnimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+14 muaj
31.
Analiza e performancës së modulit "Pasuritë e 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+15 muaj
32. 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+15 muaj
33. 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+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 aktivitetit: T+ 300 ditë
Përfundimi i statusit: Korniza legjislative e miratuar nga parlamenti
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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 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 aktivitetit: T+ 300 ditë
Përfundimi i statusit: Korniza legjislative e miratuar nga parlamenti
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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 aktivitetit (T): T+30 ditë
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
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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 aktivitetit (T): T+60 ditë
Fillimi i statusit: Definimet e përcaktuara të biznesit dhe modeli organizativ Specifikimi i konfirmuar i arkitekturës së sistemit.
Përfundimi i aktivitetit: T+200 ditë
Përfundimi i statusit: Nënsistemi TP është në funksionim
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
46.
Analiza e Bizneseve dhe Kërkesave Teknike për Zhvillimin dhe Zbatimin e Nënsistemit TP
Ofertuesi
Analiza e kërkesave të biznesit të Autoriteti Kontraktor
Analiza e kërkesave teknike dhe mjedisit
Krijimi i një dokumenti "Analizimi i Biznesit dhe Kërkesave Teknike"
Krijimi i një modeli logjik
T+60 ditë
Faqe 118 nga 140
Fillimi i aktivitetit (T): T+60 ditë
Fillimi i statusit: Definimet e përcaktuara të biznesit dhe modeli organizativ Specifikimi i konfirmuar i arkitekturës së sistemit.
Përfundimi i aktivitetit: T+200 ditë
Përfundimi i statusit: Nënsistemi TP është në funksionim
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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
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+180 ditë
51. 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ë
52. 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+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ë
Operacionale T+200 ditë
Portali Qendror për Kontrollimin dhe Menaxhimin e Tatimpaguesve në TP (PQKM)
Fillimi i aktivitetit (T): T+60 ditë
Fillimi i statusit: Definimet e përcaktuara të biznesit dhe modeli organizativ Specifikimi i konfirmuar i arkitekturës së sistemit.
Përfundimi i aktivitetit: T+365 ditë
Përfundimi i statusit: Portali Qendror PQKM është ne funksionim
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
54.
Analiza e biznesit dhe kërkesave teknike për zhvillimin dhe zbatimin e sistemit të PQKM
Ofertuesi
Analiza e kërkesave të biznesit të Autoriteti Kontraktor
Analiza e kërkesave teknike dhe mjedisit
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 e
kërkesave të përdoruesit"
T+150 ditë
55.
Konfirmimi i dokumentit "Specifikimet e kërkesave të përdoruesit" për PQKM
Autoriteti Kontraktor Autoriteti Kontraktor ka konfirmuar
"Specifikimin e Kërkesave të Përdoruesit«
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
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
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
Fillimi i aktivitetit (T): T+60 ditë
Fillimi i statusit: Definimet e përcaktuara të biznesit dhe modeli organizativ Specifikimi i konfirmuar i arkitekturës së sistemit.
Përfundimi i aktivitetit: T+365 ditë
Përfundimi i statusit: Portali Qendror PQKM është ne funksionim
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
Testimi i programimit
59.
Zhvillimi dhe zbatimi i modulit "Menaxhimi i anomalive në sistemin e pagesave në para të gatshme"
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+290 ditë
60.
Analiza e performancës së portalit PQKM WEB dhe akordimi 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+300 ditë
61. 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+330 ditë
62. 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+350 ditë
63. Portali Qendror PQKM është ne funksionim
Autoriteti Kontraktor Dorëzimi i procesverbalit Lëshimi Certifikatës se Mundësisë
Operacionale T+365 ditë
Sistemi SMR për Sistemin e TP (Sistemi i Menaxhimit të Riskut)
Fillimi i aktivitetit (T): T+200 ditë
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
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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
Analiza e kërkesave teknike dhe mjedisit
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
Autoriteti Kontraktor ka konfirmuar "Specifikimin e Kërkesave të Përdoruesit«
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
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
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 aktivitetit (T): T+90 ditë
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 aktivitetit: T+365 ditë
Përfundimi i statusit: Monitorimi Online për nevojat e sistemit TP funksionon
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
73. Analiza e biznesit dhe të kërkesave teknike
Ofertuesi
Analiza e biznesit kërkesat Autoriteti Kontraktor
Analiza e kërkesave teknike dhe mjedisit
Krijimi i një dokumenti "Analizimi i Biznesit dhe Kërkesave Teknike"
Krijimi i një modeli logjik Krijimi e një modeli fizik Krijimi i një dokumenti "Specifikimet e
kërkesave të përdoruesit"
T+150 ditë
74.
Konfirmimi i dokumentit "Specifikimet e Kërkesave të Përdoruesit" për Kontrollet e Taksapaguesve Online
Autoriteti Kontraktor Autoriteti Kontraktor ka konfirmuar
"Specifikimin e Kërkesave të Përdoruesit«
T+160 ditë
75. Zhvillimi dhe zbatimi i modulit "Planifikimi i kontrollit Tatimor"
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+200 ditë
76.
Zhvillimi dhe Implementimi i Modulit të "Rregullores së Inspektimit Tatimor"
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+220 ditë
77.
Zhvillimi dhe Implementimi i Modulit të „Njoftimi për Inspektimin Tatimor“
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+240 ditë
78.
Zhvillimi dhe zbatimi i modulit "Procesverbalet "Inspektimi Tatimor"
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+260 ditë
79.
Zhvillimi dhe zbatimi i modulit "Zgjidhjet e Kontrollit të Taksave"
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+280 ditë
80.
Analiza e performancës së sistemit dhe rregullimi i hollësishëm i sistemit
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+310 ditë
81. 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
T+320 ditë
69. Analiza e Performancës së Sistemit RMS
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+17 muaj
70. 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+17 muaj
71. 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+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 aktivitetit (T): T+90 ditë
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 aktivitetit: T+365 ditë
Përfundimi i statusit: Monitorimi Online për nevojat e sistemit TP funksionon
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
Korrigjimi i mangësive të zbuluara Krijimi i një raporti testimi
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
Autoriteti Kontraktor
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 aktivitetit (T): T+200 ditë
Fillimi i statusit: Nënsistemi TP në funksion
Përfundimi i aktivitetit: T+365 ditë
Përfundimi i statusit: Nënsistemi është ne funksion duke i mbështetur inspektorët e taksave në sistemin TP
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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
Analiza e biznesit kërkesat Autoriteti Kontraktor
Analiza e kërkesave teknike dhe mjedisit
Krijimi i një dokumenti "Analizimi i Biznesit dhe Kërkesave Teknike"
Krijimi i një modeli logjik Krijimi e një modeli fizik Krijimi i një dokumenti "Specifikimet e
kërkesave të përdoruesit"
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"
Autoriteti Kontraktor Autoriteti Kontraktor ka konfirmuar
"Specifikimin e Kërkesave të Përdoruesit«
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
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+290 ditë
87.
Zhvillimi dhe zbatimi Nënsistemit Mbështetës për inspektorët e taksave në TP - versioni nativ celular
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+290 ditë
88.
Analiza e performancës së Nënsistemit celular dhe rregullimi i hollësishëm i sistemit
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+290 ditë
89. Testimi nga zyrtarët e DPT-së Ofertuesi
Njohja me një zyrtar të DPT-së me një plan testimi
Testime në përputhje me planin e testimit
Korrigjimi i mangësive të zbuluara Krijimi i një raporti testimi
T+320 ditë
90. 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+340
Faqe 122 nga 140
Aplikacion mobile - RTP për tatimpaguesit
Fillimi i aktivitetit (T): T+ 365 ditë
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
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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
Analiza e biznesit kërkesat Autoriteti Kontraktor
Analiza e kërkesave teknike dhe mjedisit
Krijimi i një dokumenti "Analizimi i Biznesit dhe Kërkesave Teknike"
Krijimi i një modeli logjik Krijimi e një modeli fizik Krijimi i një dokumenti "Specifikimet e
kërkesave të përdoruesit"
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
"Specifikimin e Kërkesave të Përdoruesit«
T+13 muaj
95.
Zhvillimi dhe zbatimi i nënsistemit mobil "Zgjidhja e telefonit zgjuar telefonik - për qytetarët"
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+14 muaj
96. Analiza e performancës 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+15 muaj
97. Testimi nga zyrtarët e DPT-së Ofertuesi
Njohja e një zyrtari 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+15 muaj
98. 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+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
Autoriteti Kontraktor Dorëzimi i procesverbalit Lëshimi i Certifikatës se Mundësisë
Operacionale T+16 muaj
Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret
Fillimi i aktivitetit (T): T+ 365 ditë
Fillimi i statusit: Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret “ është lëshuar
Përfundimi i aktivitetit: T+500 ditë
Përfundimi i statusit: Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret “ është lëshuar, në funksion
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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
Analiza e kërkesave teknike dhe mjedisit
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
Autoriteti Kontraktor Dorëzimi i procesverbalit Lëshimi i Certifikatës se Mundësisë
Operacionale T+365 ditë
Faqe 123 nga 140
Fillimi i aktivitetit (T): T+ 365 ditë
Fillimi i statusit: Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret “ është lëshuar
Përfundimi i aktivitetit: T+500 ditë
Përfundimi i statusit: Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret “ është lëshuar, në funksion
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
mobile ne e-albania per qytetaret
Krijimi i një dokumenti "Analizimi i Biznesit dhe Kërkesave Teknike"
Krijimi i një modeli logjik Krijimi e një modeli fizik Krijimi i një dokumenti "Specifikimet
e kërkesave të përdoruesit"
102. Certifikata e dokumentit Autoriteti Kontraktor Autoriteti Kontraktor ka konfirmuar
"Specifikimin e Kërkesave të Përdoruesit«
T+400 ditë
103.
Zhvillimi dhe zbatimi i Nënsistemit mobil "Zgjidhja e telefonit zgjuar/mençur telefonik - për qytetarët"
Ofertuesi
Dizajnimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+460 ditë
104.
Analiza e performancës së Nënsistemit celular dhe rregullimi i hollësishëm i sistemit
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+470 ditë
105. Testimi nga zyrtarët e DPT-së
Ofertuesi
Njohja e një zyrtari të AT 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+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
Autoriteti Kontraktor Dorëzimi i procesverbalit Lëshimi i Certifikatës se Mundësisë
Operacionale T+500 ditë
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 aktivitetit: T+ 20 muaj
Përfundimi i statusit: Nënsistemi TP është lëshuar, në funksion
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
109. Analiza e kërkesave të biznesit dhe teknike për zhvillimin dhe zbatimin e nënsistemit TJP
Ofertuesi
Analiza e kërkesave të biznesit të Autoriteti Kontraktor
Analiza e kërkesave teknike dhe mjedisit
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
Dizajnimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+18 muaj
112. Zhvillimi dhe Implementimi i nënsistemit eReport
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+18 muaj
113.
Zhvillimi dhe zbatimi i nënsistemit te evidentim dhe ndjekjes së pagesave të TJP
Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
T+18 muaj
114. WEB portal Ofertuesi
Dizenjimi i arkitekturës së softuerit Encoding dhe Dokumentim Krijimi i një GUI Testimi i programimit
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ë
programit Dokumentimi i rezultateve të testimit
T+18 muaj
117. Testimi nga zyrtarët e DPT-së Ofertuesi
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
118. 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+18 muaj
119. Nënsistemi TP është lëshuar, ne funksion
Autoriteti Kontraktor Dorëzimi i procesverbalit Lëshimi i Certifikatës se Mundësisë
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 aktivitetit: T+ 20 muaj
Përfundimi i statusit: Përfundimi i trajnimit te zyrtarëve të DPT-së
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
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
Ofertuesi Autoriteti Kontraktor
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
Autoriteti Kontraktor
Mbajtja e seminareve, Workshop-e Zbatimi i procesit të vlerësimit të
njohurive të fituara
T+ 20 muaj
124.
Trajnimi i zyrtarëve të DPT-së në sistemin e ri të monitorimit të taksapaguesve në sistemin TP
Ofertuesi Autoriteti Kontraktor
Mbajtja e seminareve, Workshop-e Zbatimi i procesit të vlerësimit të
njohurive të fituara
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 aktivitetit (T): T+ 23 muaj
Fillimi i statusit: Të gjitha komponentët e projektit të implementuara dhe të integruara TI në mjedisin e DPT-së
Përfundimi i aktivitetit: T+ 24 muaj
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
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
126. Përgatitja e raportit përfundimtar mbi shpërndarjen e sistemit
Ofertuesi Autoriteti Kontraktor
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
Autoriteti Kontraktor
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 aktivitetit (T): T+ 23 muaj
Fillimi i statusit: Konfirmimi i Raportit Përfundimtar mbi Projektin e Implementimit dhe Mbylljes së Projektit
Përfundimi i aktivitetit: T+ 24 muaj
Përfundimi i statusit: Përfundimi i mirëmbajtjes
ID Dorëzimet
Aktivitet Përgjegjësi Përshkrimi i aktiviteteve Data
dorëzimit
128. Përcaktimi i qëllimit dhe planit të mirëmbajtjes
Ofertuesi Autoriteti Kontraktor
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
Ofertuesi Autoriteti Kontraktor
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
Ofertuesi Autoriteti Kontraktor
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)
Autoriteti Kontraktor
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
Procesverbalet nga Takimi i Projektit të BD
(Bordi i Drejtoreve)
Autoriteti Kontraktor
Konfirmimi i pranimit të Modelit dhe specifikimit të proceseve të procesit dhe organizimit
Procesverbalet nga Takimi i Projektit të BD
(Bordi i Drejtoreve)
Autoriteti Kontraktor
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.
Procesverbalet nga Takimi i Projektit të BD
(Bordi i Drejtoreve)
Autoriteti Kontraktor
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
Krijimi i udhëzimeve, informacioneve, broshurave
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)
Autoriteti Kontraktor
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
Krijimi i udhëzimeve, informacioneve, broshurave
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)
Autoriteti Kontraktor
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
Krijimi i udhëzimeve, informacioneve, broshurave
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)
Autoriteti Kontraktor
Zhvillimi dhe zbatimi i sistemeve TP
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
Materialet e trajnimit për zyrtarët e DPT-së
Materiali për e-Learning Ofertuesi
Certifikata e Pranimit të Dokumenteve Procesverbalet nga
Takimi i Projektit të BD (Bordi i Drejtoreve)
Autoriteti Kontraktor
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti Autoriteti Kontraktor
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
Raporti i testimit të kryer Dokumenti Ofertuesi
Dokumentacioni teknik Dokumenti Ofertuesi
Manuali i përdorimit Materiali për e-Learning
Ofertuesi
Materialet e trajnimit për zyrtarët e DPT-së
Materiali për e-Learning Ofertuesi
Certifikata e Pranimit të Dokumenteve Procesverbalet nga
Takimi i Projektit të BD (Bordi i Drejtoreve)
Autoriteti Kontraktor
Procesverbali i migrimit të të dhënave Dokumenti Ofertuesi
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti Autoriteti Kontraktor
Ofertuesi
Zyrat e Tatimpaguesve
Analizimi i punëve dhe kërkesave teknike
Dokumenti Ofertuesi
Specifikimet e kërkesave të përdoruesit
Dokumenti Ofertuesi
Raporti i testimit të kryer Dokumenti Ofertuesi
Dokumentacioni teknik Dokumenti Ofertuesi
Doracaku i përdorimit Materiali për e-Learning Ofertuesi
Materialet e trajnimit për zyrtarët e DPT-së
Materiali për e-Learning Ofertuesi
Certifikata e Pranimit të Dokumenteve Procesverbalet nga
Takimi i Projektit të BD (Bordi i Drejtoreve)
Autoriteti Kontraktor
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti Autoriteti Kontraktor
Ofertuesi
Menaxhimi i organizimit të brendshëm të DPT-së
Analizimi i punëve dhe kërkesave 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
Materialet e trajnimit për zyrtarët e DPT-së
Materiali për e-Learning Ofertuesi
Certifikata e Pranimit të Dokumenteve Procesverbalet nga
Takimi i Projektit të BD (Bordi i Drejtoreve)
Autoriteti Kontraktor
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti Autoriteti Kontraktor
Ofertuesi
Prona e tatimpaguesit
Analizimi i punëve dhe kërkesave teknike
Dokumenti Ofertuesi
Specifikimet e kërkesave të përdoruesit
Dokumenti Ofertuesi
Raporti i testimit të kryer Dokumenti Ofertuesi
Dokumentacioni teknik Dokumenti Ofertuesi
Doracaku i përdorimit Materiali për e-Learning Ofertuesi
Materialet e trajnimit për zyrtarët e DPT-së
Materiali për e-Learning Ofertuesi
Certifikata e Pranimit të Dokumenteve Procesverbalet nga
Takimi i Projektit të BD (Bordi i Drejtoreve)
Autoriteti Kontraktor
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti Autoriteti Kontraktor
Ofertuesi
Portali Qendror për Kontrollimin dhe Menaxhimin e
Tatimpaguesve në TP (PQKM)
Analizimi i punëve dhe kërkesave 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
Materialet e trajnimit për zyrtarët e DPT-së
Materiali për e-Learning Ofertuesi
Certifikata e Pranimit të Dokumenteve Procesverbalet nga
Takimi i Projektit të BD (Bordi i Drejtoreve)
Autoriteti Kontraktor
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti Autoriteti Kontraktor
Ofertuesi
Sistemi SMR për Sistemin e TP (Sistemi i Menaxhimit të Riskut)
Analizimi i punëve dhe kërkesave teknike
Dokumenti Ofertuesi
Specifikimet e kërkesave të përdoruesit
Dokumenti Ofertuesi
Faqe 129 nga 140
Raporti i testimit të kryer Dokumenti Ofertuesi
Katalogu i riskut për nënsistemin TP Dokumenti Ofertuesi
Dokumentacioni teknik Dokumenti Ofertuesi
Doracaku i përdorimit Materiali për e-Learning Ofertuesi
Materialet e trajnimit për zyrtarët e DPT-së
Materiali për e-Learning Ofertuesi
Certifikata e Pranimit të Dokumenteve Procesverbalet nga
Takimi i Projektit të BD (Bordi i Drejtoreve)
Autoriteti Kontraktor
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti Autoriteti Kontraktor
Ofertuesi
Mbikëqyrja Online e tatimpaguesve në
sistemin TP
Analizimi i punëve dhe kërkesave 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
Materialet e trajnimit për zyrtarët e DPT-së
Materiali për e-Learning Ofertuesi
Certifikata e Pranimit të Dokumenteve Procesverbalet nga
Takimi i Projektit të BD (Bordi i Drejtoreve)
Autoriteti Kontraktor
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti Autoriteti Kontraktor
Ofertuesi
Sistemi për "Mbështetjen e
Inspektorëve të Taksave në Sistemin TP"
Analizimi i punëve dhe kërkesave 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
Materialet e trajnimit për zyrtarët e DPT-së
Materiali për e-Learning Ofertuesi
Certifikata e Pranimit të Dokumenteve Procesverbalet nga
Takimi i Projektit të BD (Bordi i Drejtoreve)
Autoriteti Kontraktor
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti Autoriteti Kontraktor
Ofertuesi
Aksesimi i sistemit me RTP npm tabletave me-
për tatimpaguesit
Analizimi i punëve dhe kërkesave 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
Materialet e trajnimit për zyrtarët e DPT-së
Materiali për e-Learning Ofertuesi
Certifikata e Pranimit të Dokumenteve Procesverbalet nga
Takimi i Projektit të BD (Bordi i Drejtoreve)
Autoriteti Kontraktor
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti Autoriteti Kontraktor
Ofertuesi
Sherbim i dedikuar ne aplikacionin mobile ne e-albania per qytetaret.
Analiza e biznesit dhe kërkesave teknike
Dokumenti Ofertuesi
Specifikimet e kërkesave të përdoruesit
Dokumenti Ofertuesi
Raporti i testimit të ekzekutimit Dokumenti Ofertuesi
Dokumentacioni teknik Dokumenti Ofertuesi
Manuali i përdorimit Materiali për e-Learning Ofertuesi
Materiali për trajnimin e zyrtareve te DPT-së
Materiali për e-Learning Ofertuesi
Certifikata e Pranimit të Dokumenteve
Procesverbalet nga Takimi i Projektit të BD
(Bordi i Drejtoreve) Autoriteti Kontraktor
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti Autoriteti Kontraktor
Ofertuesi
Zhvillimi dhe zbatimi i sistemeve TP
Analiza e biznesit dhe kërkesave teknike
Dokumenti Ofertuesi
Specifikimet e kërkesave të përdoruesit
Dokumenti Ofertuesi
Raporti i aprovimit te testimit Dokumenti Ofertuesi
Faqe 130 nga 140
Dokumentacioni teknik Dokumenti Ofertuesi
Manuali i përdorimit Materiali për e-Learning Ofertuesi
Materialet e trajnimit për zyrtarët e DPT-së
Materiali për e-Learning Ofertuesi
Certifikata i Pranimit të Dokumenteve
Procesverbalet nga Takimi i Projektit të BD
(Bordi i Drejtoreve) Autoriteti Kontraktor
Dorëzim procesverbali Certifikata Operacionale e Pranimit
Dokumenti 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
Materiali për e-Learning Ofertuesi
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ë
Materiali për e-Learning Ofertuesi
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
Dokumenti Autoriteti Kontraktor
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
Dokumenti Autoriteti Kontraktor
Ofertuesi
Përditësimi dokumentacionit Dokumenti Ofertuesi
Raporti Përfundimtar mbi Mirëmbajtjen dhe Përfundimi i mirëmbajtjes
Dokumenti Autoriteti Kontraktor
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
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ë 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
o Minimum 2x SSD 240Gb SATA
o Kontrollues hardware RAID
o 4x Gigabit Ethernet LAN
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
o Minimum 2x SSD 240Gb SATA
o Kontrollues hardware RAID
o 4x Gigabit Ethernet LAN
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
Instaluar dhe konfiguruar në qendrën e të dhënave primare
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
Recommended