täieliku e hangete võimekuse loomine eelanalüüs...[1] leping nr 2.1-4/00057 täieliku e-hangete...

© AS Datel 2016

Täieliku e-hangete võimekuse loomine

Eelanalüüs

v1.0

Tellija: Rahandusministeeriumi Infotehnoloogiakeskus

Registrikood: 70009244

Lõõtsa 8a, Tallinn, 11415

Täitja: AS Datel

Registrikood: 10324057

Endla 4, Tallinn, 10142

Täieliku e-hangete võimekuse loomine Eelanalüüs v1.0

© AS Datel 2016 2/120

Versioonid

ID Kuupäev Koostaja Selgitus

v0.1 24.11.2015 Kadri Ollo Dokumendi esmane versioon

v0.2 29.02.2016 Kadri Ollo Dokumendi vaheversioon hankijatele tutvustamiseks

v1.0 28.03.2016 Kadri Ollo Dokumendi lõplik versioon


© AS Datel 2016 3/120

Sisukord

1 SISSEJUHATUS ........................................................................................................................................... 7

1.1 DOKUMENT .............................................................................................................................................. 7 1.2 MÄÄRATLUSED JA LÜHENDID .................................................................................................................. 7 1.3 VIITED ..................................................................................................................................................... 7

1.3.1 Analüüsi alusdokumendid ............................................................................................................... 7 1.3.2 Analüüsi lisad .................................................................................................................................. 7 1.3.3 Esitusviis ......................................................................................................................................... 8

2 ERHR KASUTAJALIIDESE ÜLDKONTSEPTSIOON ........................................................................... 9

2.1 LÄHTEOLUKORRA KIRJELDUS .................................................................................................................. 9 2.2 ARENDUSE EESMÄRK .............................................................................................................................. 9

2.2.1 Registri edasiarenduse võimalikud variandid ............................................................................... 10 2.3 SÜSTEEMI ARHITEKTUUR ....................................................................................................................... 11

2.3.1 eRHR Moodulid. ............................................................................................................................ 11 2.3.2 eRHR Paigaldusvaade................................................................................................................... 14

2.3.2.1 X-Tee turvaserver / X-Tee ......................................................................................................................... 14 2.3.2.2 SMTP server / E-maili server .................................................................................................................... 15 2.3.2.3 Apache httpd server ................................................................................................................................... 15 2.3.2.4 eRHR Backend .......................................................................................................................................... 15 2.3.2.5 eRHR frontend........................................................................................................................................... 16 2.3.2.6 Moodul CAS .............................................................................................................................................. 16 2.3.2.7 Oracle andmebaas ...................................................................................................................................... 17 2.3.2.8 Kasutaja veebilehitseja .............................................................................................................................. 17 2.3.2.9 E-kataloogi moodul ................................................................................................................................... 17

2.4 ÜLDISED NÕUDED KASUTAJALIIDESELE ................................................................................................. 17

3 KASUTAJAD JA ROLLID ........................................................................................................................ 19

3.1 LIGIPÄÄSUÕIGUSTE TASANDID ............................................................................................................... 19 3.2 KASUTAJA ROLLID ................................................................................................................................. 20

4 KASUTAJATE ESMAREGISTREERIMINE JA HALDUS ................................................................. 21

4.1 SÜSTEEMI SISENEMINE – EESTI KASUTAJAD ........................................................................................... 21 4.2 SÜSTEEMI SISENEMINE - VÄLISMAALASED ............................................................................................. 21 4.3 KASUTAJAKS REGISTREERUMINE ........................................................................................................... 22 4.4 KASUTAJA REGISTREERIMINE JA HALDUS PEAKASUTAJA POOLT ............................................................ 22 4.5 OMA ANDMETE HALDAMINE .................................................................................................................. 23

5 SÜSTEEMIS TEGUTSEVAD ASUTUSED ............................................................................................. 24

5.1 ASUTUSTE ANDMED ............................................................................................................................... 24 5.1.1 Hankijad ........................................................................................................................................ 24 5.1.2 Ettevõtjad: taotlejad ja pakkujad .................................................................................................. 25 5.1.3 Kontrollasutused ........................................................................................................................... 25

5.2 ASUTUSTE KEHTIVUS ............................................................................................................................. 26 5.3 ASUTUSTE ESMAREGISTREERIMINE ........................................................................................................ 26

5.3.1 Eesti asutuste registreerimine ....................................................................................................... 26 5.3.2 Eesti füüsilise isiku ettevõtjaks registreerimine ............................................................................ 27 5.3.3 Välismaiste asutuste registreerimine ............................................................................................. 28 5.3.4 Allüksuste registreerimine ............................................................................................................. 28

5.4 ASUTUSTE ANDMETE KONTROLL JA HALDUS.......................................................................................... 28 5.5 ASUTUSTE DOKUMENDIPANK ................................................................................................................. 29

6 KASUTAJATE VOLITUSED ASUTUSE JA HANKE JUURES .......................................................... 30

6.1 KASUTAJATE VOLITUSED ASUTUSE JUURES ............................................................................................ 30 6.1.1 Kasutaja volitused hankija juures ................................................................................................. 30 6.1.2 Kasutaja volitused ettevõtja juures ............................................................................................... 30 6.1.3 Kasutaja volitused kontrollasutuse juures ..................................................................................... 31

6.2 KASUTAJA SEOSTAMINE ASUTUSEGA ..................................................................................................... 31 6.2.1 Esindatava asutuse vahetamine..................................................................................................... 32

6.3 HANKEMEESKONNA HALDAMINE ........................................................................................................... 32


© AS Datel 2016 4/120

6.3.1 Hanke hankijapoolne meeskond .................................................................................................... 32 6.3.2 Hanke ettevõtjapoolne meeskond .................................................................................................. 33

7 HANKE MENETLEMINE ........................................................................................................................ 35

7.1 HANGE ................................................................................................................................................... 35 7.2 HANKE ANDMETEGA TUTVUMINE .......................................................................................................... 35

7.2.1 Hanke päis ..................................................................................................................................... 35 7.2.2 Üldandmed .................................................................................................................................... 36 7.2.3 Kaasatud hankijad ........................................................................................................................ 37 7.2.4 Hankija meeskond ......................................................................................................................... 37 7.2.5 Ettevõtja meeskond ........................................................................................................................ 37 7.2.6 Hankes osalejad ............................................................................................................................ 37 7.2.7 Alusdokumendid ............................................................................................................................ 37 7.2.8 Hanke teated.................................................................................................................................. 38 7.2.9 Teabevahetus ................................................................................................................................. 38 7.2.10 Taotlused / Pakkumused ................................................................................................................ 38 7.2.11 Tulemdokumendid ......................................................................................................................... 38 7.2.12 Lepingud ........................................................................................................................................ 39 7.2.13 Vaidlustused .................................................................................................................................. 39

7.3 MENETLUSPROTSESS.............................................................................................................................. 39 7.3.1 Hanke osade menetlemine ............................................................................................................. 40 7.3.2 Hanke seisundid ............................................................................................................................ 40 7.3.3 Tegevused hanke menetlemisel ...................................................................................................... 42

7.3.3.1 Tegevustega seotud andmed ...................................................................................................................... 43 7.3.3.2 Tegevused vanade hangete puhul .............................................................................................................. 44

7.3.4 Hanke tööleht ................................................................................................................................ 44 7.3.4.1 Hanke tööleht hankija vaates ..................................................................................................................... 44 7.3.4.2 Hanke tööleht ettevõtja vaates – ettevõtja tööleht ...................................................................................... 45

8 HANKE ETTEVALMISTAMINE ............................................................................................................ 46

8.1 UUE HANKE LISAMINE ............................................................................................................................ 46 8.2 HANKE ETTEVALMISTAMISE TEGEVUS ................................................................................................... 46

8.2.1 Hanke kooskõlastamine ................................................................................................................. 47 8.2.2 Ettevalmistamise lõpetamine ......................................................................................................... 48

8.3 HANKE ALUSANDMETE PARANDAMINE .................................................................................................. 48 8.4 HANKE ALUSANDMETE TÄIENDAMINE PAKKUMUSE ESITAMISEKS ......................................................... 49 8.5 HANKE TINGIMUSED .............................................................................................................................. 49

8.5.1 Keskkonnahoidlikud tingimused .................................................................................................... 50 8.6 HANKEPASS ........................................................................................................................................... 51

8.6.1 Hankepassi koostamine ja täitmine keskse teenuse abil ................................................................ 52 8.6.2 Hankepassi integreerimine eRHR registrisse ................................................................................ 52 8.6.3 Tingimuste ettevalmistamine ......................................................................................................... 52 8.6.4 Ettevalmistatud tingimuste kasutamine ......................................................................................... 53 8.6.5 Hankepassi formeerimine .............................................................................................................. 53 8.6.6 Hankepassi täitmine ettevõtja poolt .............................................................................................. 54 8.6.7 Tingimuste kontrollimine hankija poolt......................................................................................... 54

8.7 HINDAMISKRITEERIUMID JA NUMBRILISED NÄITAJAD ............................................................................ 54 8.7.1 Näitajate lisamine käsitsi .............................................................................................................. 55 8.7.2 Hindamiskriteeriumite kuvamine .................................................................................................. 56

8.8 HANKE TEADE ........................................................................................................................................ 57

9 TAOTLUSE / PAKKUMUSE KOOSTAMINE JA ESITAMINE .......................................................... 58

9.1 HANKES OSALEJAKS REGISTREERUMINE ................................................................................................ 58 9.1.1 Hankes osaleja registreerimine hankija poolt ............................................................................... 58 9.1.2 Ettevõtja poolse meeskonna komplekteerimine ............................................................................. 59

9.2 PAKKUMUSE KOOSTAMINE..................................................................................................................... 59 9.2.1 Pakkumuse koostamise alustamine ............................................................................................... 59 9.2.2 Kaaspakkujate valimine ................................................................................................................ 59 9.2.3 Pakkumusega seotud hanke osad .................................................................................................. 60 9.2.4 Pakkumuse osalemistingimuste sisestamine .................................................................................. 60 9.2.5 Pakkumuse näitajate sisestamine .................................................................................................. 60 9.2.6 Pakkumuse dokumentide üleslaadimine ........................................................................................ 60 9.2.7 Pakkumuse esitamine .................................................................................................................... 61


© AS Datel 2016 5/120

9.3 PAKKUMUSE PARANDAMINE JA TAGASIVÕTMINE ................................................................................... 61 9.4 PAKKUMUSE LISAMINE 2-ETAPILISES MENETLUSES ............................................................................... 61 9.5 ALTERNATIIVSE PAKKUMUSE LISAMINE ................................................................................................. 62 9.6 PAKKUMUSE KOHANDAMINE ................................................................................................................. 62

10 TAOTLUSTE / PAKKUMUSTE MENETLEMINE ........................................................................... 63

10.1 TAOTLUSE JA PAKKUMUSE SEISUNDID ................................................................................................... 64 10.1.1 Taotluse seisundid ......................................................................................................................... 64 10.1.2 Pakkumuse seisundid..................................................................................................................... 65

10.2 MENETLUSTEGEVUSED .......................................................................................................................... 65 10.2.1 Taotluste ja pakkumuste avamine.................................................................................................. 66 10.2.2 Taotlejate / pakkujate kvalifitseerimine......................................................................................... 66

10.2.2.1 Kvalifitseerimine kinnituste alusel ........................................................................................................ 66 10.2.2.2 Kvalifitseerimine tõendite alusel ........................................................................................................... 67 10.2.2.3 Tingimuste kontrollimine automaatsete päringutega ............................................................................. 68 10.2.2.4 Kvalifitseerimise tegevuse käik............................................................................................................. 68

10.2.3 Pakkumuste vastavuse kontroll ..................................................................................................... 68 10.2.4 Pakkumuste hindamine .................................................................................................................. 69

10.2.4.1 Hindamistulemuste avalikustamine pakkujaile ..................................................................................... 71 10.2.5 E-oksjoni korraldamine ................................................................................................................. 71 10.2.6 Eduka pakkuja valik ...................................................................................................................... 71 10.2.7 Pakkumuste tagasilükkamine ........................................................................................................ 71

10.3 LÄBIRÄÄKIMISTE KORRALDAMINE......................................................................................................... 72 10.3.1 Läbirääkimiste tegevus .................................................................................................................. 72 10.3.2 Pakkumuste kohandamine ............................................................................................................. 73

10.4 TULEMDOKUMENDID ............................................................................................................................. 73 10.4.1 Süsteemi kaudu loodavad tulemdokumendid ................................................................................. 74

11 TEABEVAHETUS .................................................................................................................................. 75

11.1 ÜLDIST ................................................................................................................................................... 75 11.1.1 Teabevahetuse manused ................................................................................................................ 75 11.1.2 Saadetiste nähtavus ....................................................................................................................... 75 11.1.3 Teabevahetuse jälgimine ............................................................................................................... 75

11.2 SAADETISTE LIIGID ................................................................................................................................ 76 11.2.1 Küsimus ja teade hankijale ........................................................................................................... 76 11.2.2 Küsimus ja teade ettevõtjale .......................................................................................................... 77 11.2.3 Läbirääkimiste kutse ja dialoogi alustamise ettepanek ................................................................. 77 11.2.4 Pakkumuse esitamise ettepanek..................................................................................................... 77

11.3 TEABEVAHETUSE ESITLEMINE ................................................................................................................ 77

12 LEPINGUTE HALDUS .......................................................................................................................... 79

12.1 LEPINGUTE LIIGID .................................................................................................................................. 79 12.2 LEPINGU SEISUNDID ............................................................................................................................... 80 12.3 LEPINGUTE SÕLMIMINE .......................................................................................................................... 80

12.3.1 Lepingute sõlmimine hanke pakkumuste alusel ............................................................................. 80 12.3.2 Lepingu sõlmimise teate esitamine ................................................................................................ 81 12.3.3 Lepingu andmete muutmine .......................................................................................................... 82 12.3.4 Lepingu lõpetamine ....................................................................................................................... 82 12.3.5 Hankelepingu akteerimiskava ....................................................................................................... 82

12.4 HANKIMINE RAAMLEPINGUTE ALUSEL ................................................................................................... 82 12.4.1 Raamlepingu alusel hankelepingu sõlmimine ............................................................................... 83 12.4.2 Minikonkursi loomine .................................................................................................................... 83 12.4.3 Minikonkursi menetlemine ............................................................................................................ 83

12.5 LEPINGUTE LEHT RAAMLEPINGU HANKES .............................................................................................. 84

13 INFO OTSIMINE, TELLIMINE JA KOONDAMINE ....................................................................... 85

13.1 KASUTAJA TÖÖLAUD ............................................................................................................................. 85 13.1.1 Töölaua menüü .............................................................................................................................. 85 13.1.2 Töölaua hanked ............................................................................................................................. 85 13.1.3 Töölaua kujundamine kasutaja poolt ............................................................................................ 87

13.2 HANKE OTSING ...................................................................................................................................... 87 13.2.1 Otsingutingimuste sisestamine ...................................................................................................... 87 13.2.2 Otsingutingimuste salvestamine .................................................................................................... 89


© AS Datel 2016 6/120

13.2.3 Hangete nimekiri ........................................................................................................................... 90 13.2.4 Hanke andmete eksport ................................................................................................................. 91

13.3 MINU HANKED NIMEKIRI ........................................................................................................................ 91 13.4 LEPINGU OTSING .................................................................................................................................... 92 13.5 INFOTELLIMUSED ................................................................................................................................... 93

13.5.1 Infotellimuse teenuse leitavus ........................................................................................................ 93 13.5.2 Minu infotellimused ....................................................................................................................... 93 13.5.3 Infotellimuse lisamine ................................................................................................................... 94

13.5.3.1 Infotellimuse kehtivus ja pikendamine .................................................................................................. 94 13.5.4 Infotellimuse täitmine .................................................................................................................... 95 13.5.5 Infotellimuse kustutamine .............................................................................................................. 95

14 ELEKTROONILISED VAIDLUSTUSED ........................................................................................... 96

14.1 VAIDLUSTUSTE KUVAMINE HANKE JUURES ............................................................................................ 97 14.2 VAIDLUSTUSTE OTSING .......................................................................................................................... 97

15 ÄRILOOGIKAT TOETAVAD TEAVITUSED ................................................................................... 98

15.1 TEAVITAMISE TEENUS ............................................................................................................................ 98 15.1.1 Teenuse sisend ............................................................................................................................... 98 15.1.2 Teenuse metakeel .......................................................................................................................... 99

15.2 TEAVITUSTE LIIGID .............................................................................................................................. 100 15.3 TEAVITUSE ATTRIBUUDID .................................................................................................................... 100 15.4 TEAVITUSTE KUVAMINE REGISTRIS ...................................................................................................... 101

15.4.1 Teavituste kuvamine kasutaja töölaual ....................................................................................... 101 15.4.2 Teavituste kuvamine hanke andmetes .......................................................................................... 102 15.4.3 Teavituste kuvamine registri peakasutajale ................................................................................ 102

16 ELEKTROONILISED TÖÖRIISTAD ............................................................................................... 103

16.1 KONSOLIDEERITUD HANKED ................................................................................................................ 103 16.1.1 Ühishange ................................................................................................................................... 103 16.1.2 Keskne hange .............................................................................................................................. 103

16.2 DÜNAAMILINE HANKESÜSTEEM ........................................................................................................... 104 16.2.1 DHS-i loomine ............................................................................................................................. 104 16.2.2 DHS-i kehtivuse muutmine .......................................................................................................... 104 16.2.3 DHS-i raames hankimine ............................................................................................................ 105 16.2.4 DHS raames esitatud pakkumuste hindamine ja lepingu sõlmimine ........................................... 105

16.3 KVALIFITSEERIMISSÜSTEEM ................................................................................................................ 106 16.3.1 KS-i loomine ................................................................................................................................ 106 16.3.2 KS-i muutmine ............................................................................................................................. 106 16.3.3 KS-i raames hankimine ............................................................................................................... 107 16.3.4 KS raames esitatud pakkumuste hindamine ja lepingu sõlmimine .............................................. 107

16.4 ERIMENETLUS ...................................................................................................................................... 108 16.4.1 Sotsiaal- ja eriteenused ............................................................................................................... 108 16.4.2 Kontsessioon ............................................................................................................................... 108

16.5 E-OKSJON ............................................................................................................................................. 109 16.5.1 E-oksjoni ettevalmistamine ......................................................................................................... 109 16.5.2 E-oksjoni alustamine ................................................................................................................... 109 16.5.3 E-oksjoniga tutvumine ................................................................................................................. 110 16.5.4 Pakkumiste tegemine e-oksjonil .................................................................................................. 110 16.5.5 E-oksjoni automaatne pikenemine ............................................................................................... 111 16.5.6 E-oksjoni lõpetamine ................................................................................................................... 111

16.6 E-KATALOOG ....................................................................................................................................... 111 16.6.1 E-kataloogi kasutajad ................................................................................................................. 112 16.6.2 eRHR ja e-katakoogi seos hanke menetlemisel ........................................................................... 112

16.6.2.1 E-kataloogi hanke ettevalmistamine.................................................................................................... 112 16.6.2.2 Pakkumuse tegemine e-kataloogi vormis ............................................................................................ 113 16.6.2.3 Esitatud pakkumuste hindamine hankija poolt .................................................................................... 113

16.6.3 E-kataloogist tellimine ................................................................................................................ 113

17 MUUDATUSTE KOKKUVÕTE ......................................................................................................... 115

17.1 KÄESOLEVAS ANALÜÜSIS KAJASTAMATA TEEMAD .............................................................................. 118


© AS Datel 2016 7/120

1 SISSEJUHATUS

1.1 Dokument

Käesolev eelanalüüsi dokument on koostatud lepingu [1] raames ning kirjeldab kavandatavaid

muudatusi e-riigihangete keskkonna funktsionaalses toimimises ja kasutajaliidese

ülesehituses.

1.2 Määratlused ja lühendid

Mõiste, lühend Selgitus

eRHR elektrooniline Riigihangete Register ehk e-Riigihangete Register

VAKO riigihangete vaidlustuskomisjon

RHS riigihangete seadus

TED Tenders Electronic Daily

Euroopa Liidu Teataja elektrooniline andmebaas

ELT Euroopa Liidu Teataja

ESPD European Single Procurement Document - Euroopa ühtne hankedokument ehk

hankepass

1.3 Viited

1.3.1 Analüüsi alusdokumendid

[1] Leping nr 2.1-4/00057 Täieliku e-hangete võimekuse loomine 3.11.2015 Rahandusministeeriumi

Infotehnoloogiakeskus, AS Datel.

[2] Riigihangete seaduse eelnõu 08.01.2016

[3] Seletuskiri RHS eelnõu juurde

[4] Riigihangete registri põhimäärus

[5] EUROOPA PARLAMENDI JA NÕUKOGU DIREKTIIV 2014/23/EL, 26. veebruar 2014,

kontsessioonilepingute sõlmimise kohta

[6] EUROOPA PARLAMENDI JA NÕUKOGU DIREKTIIV 2014/24/EL, 26. veebruar 2014,

riigihangete kohta ja direktiivi 2004/18/EÜ kehtetuks tunnistamise kohta

[7] EUROOPA PARLAMENDI JA NÕUKOGU DIREKTIIV 2014/25/EL, 26. veebruar 2014, milles

käsitletakse vee-, energeetika-, transpordi- ja postiteenuste sektoris tegutsevate üksuste

riigihankeid ja millega tunnistatakse kehtetuks direktiiv 2004/17/EÜ

[8] KOMISJONI RAKENDUSMÄÄRUS (EL) 2015/1986, 11. november 2015, millega kehtestatakse

riigihankega seotud teadete tüüpvormid ja tunnistatakse kehtetuks rakendusmäärus (EL) nr

842/2011

[9] Euroopa Parlamendi ja nõukogu direktiiv 2009/81/EÜ, 13. juuli 2009, millega kooskõlastatakse

teatavate kaitse- ja julgeolekuvaldkonnas ostjate poolt sõlmitavate ehitustööde ning asjade ja

teenuste riigihankelepingute sõlmimise kord

[10] Euroopa Komisjoni rakendusmäärus (EL) 2016/7, millega kehtestatakse Euroopa ühtse

hankedokumendi standardvorm http://eur-lex.europa.eu/legal-

content/ET/TXT/?uri=CELEX:32016R0007

[11] Kasutajatelt laekunud tagasiside registri parendusvajaduste kohta

[12] Iseteeninduskeskkonna raamistik, Trinidad Consulting

https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistik.pdf

[13] Ärivisioon: Täieliku e-hangete võimekuse loomine, Rahandusministeerium 2015

1.3.2 Analüüsi lisad

[14] Funktsionaalsuste ja õiguste maatriks.xlsx

[15] eRHR prototüüp http://tarkvara.datel.ee/proto/erhr

http://eur-lex.europa.eu/legal-content/ET/TXT/?uri=CELEX:32016R0007

http://eur-lex.europa.eu/legal-content/ET/TXT/?uri=CELEX:32016R0007

https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistik.pdf

http://tarkvara.datel.ee/proto/erhr


© AS Datel 2016 8/120

1.3.3 Esitusviis

(P/L) – viide käesoleva dokumendi alajaotusele P leheküljel L, nt (1.3/7);

[D] – viide dokumendile, kus D on dokumendi jrk loetelus, nt [1];

([D] P) – viide dokumendi D pealkirjale või alajaotusele P, nt (1.5 Ülevaade) või ([1] 2.7);

>P – viide jooksva alajaotuse punktile P, nt >12.2.3.


© AS Datel 2016 9/120

2 ERHR KASUTAJALIIDESE ÜLDKONTSEPTSIOON

2.1 Lähteolukorra kirjeldus

Eestis on üks keskne riigihangetega seotud infosüsteem – elektrooniline Riigihangete Register

(eRHR), milles hankega seotud teadete avaldamine on vastavalt kehtivale riigihangete

seadusele hankijatele kohustuslik. Alates 2011. a pakub eRHR hangete elektroonilise

menetlemise võimalust.

Olemasoleva registri muudatusvajadused on ajendatud mitmetest eRHRi sisulistest,

kasutatavusest ja tehnilistest probleemidest ning samuti seotud Euroopa Parlamendi ja

nõukogu uute riigihanke direktiivide jõustumisega. Nendest direktiividest tulenevalt on Eestis

algatatud uus riigihangete seaduse eelnõu, mille jõustumine on planeeritud 2016 a.

aprillikuusse.

Uue riigihangete seaduse eelnõu kohaselt toimuvad riigihanked üksikute eranditega täies

ulatuses elektrooniliselt riigihangete registris. Seega on hankijate jaoks kohustuslik avaldada

elektrooniliselt kõik riigihanke alusdokumendid, korraldada elektrooniliselt kogu riigihankega

seotud teabevahetus ja aktsepteerida üksnes elektrooniliste pakkumuste ja taotluste esitamist.

Täieliku e-riigihangete võimekuse loomine hõlmab ka direktiividest tulenevaid innovaatilisi

e-hanke tööriistu nagu e-kataloogid, dünaamiline hankesüsteem ja e-oksjon, mille

võimaldamine eRHRis on Vabariigi Valitsuse tegevusprogrammi 2015-2019 ülesanne.

Uued direktiivid toovad riigihangete efektiivsemaks läbiviimiseks endaga kaasa ka täiesti

uued lahendused nagu hankepass, innovatsioonipartnerlus, osade eriaegadel menetlemine,

pöördmenetlus, sotsiaal- ja eriteenuste erimenetlus jm.

Protsesside uuendamise peamine eesmärk on muuta riigihangete korraldus tõhusamaks.

Tõhustamise lahutamatud alameesmärgid on tõsta kasutajate rahulolu (süsteemi

kasutusmugavusse panustamine) ning langetada riigihangete kulusid (nii hankijate

halduskulud ja pakkujate osalemiskulud kui ka kaudsed kulud nagu kasutajatugi, nõustamine,

koolitus).

2.2 Arenduse eesmärk

Registri edasiarenduse üheks eelduseks on asjaolu, et elektrooniline teabevahetus, lisaks

hankest teavitamisele, muutub riigihangetes kohustuslikuks, välja arvatud üksikud erandid.

Tuleb luua võimalus, et kõiki riigihankeid oleks võimalik soovi korral e-hangetena menetleda.

E-hangete puhul peavad hanke alusdokumendid olema kättesaadavad registri kaudu. Hangete

menetlemine peab olema lahendatud sedavõrd paindlikult, et oleks kaetud kõigi hankijate

vajadused. Sealhulgas peab olema võimalik menetlemise üksikuid etappe vahele jätta,

teostada neid registriväliselt ning sisestada ainult lõpptulemused registrisse.

E-hangete puhul peab vähemalt pakkujate kvalifitseerimine toimuma registris. Taotlused ja

pakkumused esitatakse samuti registris, kuid mööndusena on lubatud pakkumuse sisu üle

anda ka muul viisil. Hankija määrab hanketingimustes, mis kujul ta pakkumusi ootab. Kui

pakkumuse sisuks on näiteks makett või muu mitte elektroonilist esitamist võimaldav ese, siis

märgib pakkuja registri kaudu esitatavas pakkumuses, et sisu on üle antud muul viisil. Iga

pakkumus peab olema vähemalt ümbrikuna registri kaudu esitatud.

See eeldus ühtlustab tugevalt hangete menetlemise protsessi ning võimaldab rakendada

ühtseid reegleid kõigi hangete osas. Samuti võimaldab see saada täiuslikumat ülevaadet Eestis

läbiviidavatest riigihangetest.


© AS Datel 2016 10/120

Hangete käsitlemise üheks kõige põhilisemaks funktsionaalseks muudatuseks on

protsessikeskne lähenemine hanke menetlemisel ja osade kaupa menetlemise võimaldamine.

Sellise vajaduse tõi esile enamik registri kasutajaid. See tähendab protsessi jagamist eraldi

tegevusteks, mida on võimalik rakendada hanke osadele erinevas järjekorras erinevatel

aegadel. Kõik tegevused peavad siiski järgima hanke menetluse põhiprotsessi loogikat, nö

üldist raami, mis on kirjeldatud käesoleva dokumendi hanke menetlemist puudutavates

peatükkides.

Hanke andmeloogika olulisel määral ei muutu, kuid lisandub hanke tegevusvaade hankijale ja

pakkujale ning samuti muid uutest vajadustest tingitud andmeelemente.

Peale selle lisanduvad juurde täiesti uued funktsionaalsused (nagu näiteks e-kataloog, e-

oksjon mistahes numbriliste näitajate kohta, dünaamiline hankesüsteem jne), mis praeguses

süsteemis puuduvad, kuid mida hangete mugavaks ja eesmärgipõhiseks menetlemiseks vaja

on.

Tänane registri kasutajaliides on arendatud nüüdseks tehniliselt amortiseerunud platvormil,

mis paraku ei võimalda moodsaid ja kasutajasõbralikke vahendeid kasutada. Kõik uued

funktsionaalsused tuleks arendada mingil kaasaegsemal ja jätkusuutlikumal platvormil.

Lõpptulemusena saavad mõjutatud kõik olemasoleva süsteemi osad, st mitte ükski

olemasoleva süsteemi osis ei jää muudatusteta.

Majanduslikult kõige otstarbekam viis arendust teostada oleks jätta olemasolev andmebaas ja

andmeloogika üldjoontes samaks, täiendada, kuid mitte muuta seniseid andmeloogilisi

seoseid olulisel määral. Selle lahenduse suur eelis on, et andmemigratsiooni pole vaja teha,

küll võib esineda juurutuse hetkel uute elementide algväärtustamise vajadus. Lahenduse

miinus on see, et olemasolevat andmeloogikat ei saa tugevalt muuta, kuid muudatused

tooksidki nagunii kaasa teatava andmekao juurutuse hetkel, mis omakorda põhjustaks

tugevaid probleeme pooleli menetlusega hangetes.

2.2.1 Registri edasiarenduse võimalikud variandid

Kasutajaliidese osas on 3 põhimõttelist varianti ülemineku realiseerimiseks.

Variant 1. Arendada uus liides välja vähemalt kogu tänase registri funktsionaalsust katvas

ulatuses uuel moel, juurutada see tänase registri asendusena ning seejärel asuda välja

arendama uusi täiendavaid elektroonilisi funktsionaalsuseid, mis tänases registris puuduvad.

Majanduslikus mõttes oleks see variant kahtlemata kõige otstarbekam, sest kõik kulutatavad

ressursid läheksid siis ainult uue arendusse ja vana täiendamisse ei oleks enam vajadust

vähimalgi määral panustada.

Selle lahenduse miinus on aga see, et kasutajad peavad uusi funktsionaalsuseid väga kaua

ootama. Esimene etapp, mis hõlmaks korraga juurutatava osa arendust, kestaks vähemalt aasta

ning ka selle lõppedes ei saaks kasutajad kohe mitte ühtegi sisuliselt uut tööriista. Või kui

lülitada ka mõni uus tööriist kohe esimese etapi koosseisu, siis kestaks see veelgi kauem ning

oleks veelgi ressursimahukam. Suurim osa arenduse kulutusi saaks tehtud esimeses etapis.

Riskid terviku õnnestumisele oleksid selle variandi puhul kõige suuremad.

Variant 2. Arendada uus liides etapiviisiliselt moodulhaaval ning integreerida uued moodulid

olemasolevasse süsteemi sisse. Selle lahenduse puhul tekib paratamatult ka vana

kasutajaliidese muutmise/täiendamise vajadus ning sõltuvalt integreeritavast moodulist

võivad täiendused olla mahukad.


© AS Datel 2016 11/120

Lahenduse miinus on see, et integreerimisele kuluvad ressursid kannavad väga lühiajalist

eesmärki, sest lõpptulem on igal juhul kogu süsteemi üleminek uuele platvormile. Lahenduse

eelis on aga see, et kasutajad saaksid kiiremini asuda arenduse tulemeid tarbima.

Variant 3. Arendada uus kasutajaliides välja menetlusliikide kaupa. Näiteks realiseerida

esimeses etapis uus liides avatud hankemenetluse jaoks, juurutada see ning asuda uusi avatud

hankeid menetlema uues keskkonnas, samas kui kõik teised jääksid esialgu vanasse

keskkonda. Seejärel täiendada uut liidest teiste menetlusliikidega ning viia nad järk-järgult

kõik uuele platvormile.

Selle lahenduse kõige suurem miinus on segadus kasutajate jaoks, kes peaks harjuma kahe

erineva rakenduse paralleelkasutusega: ühed menetluse liigid ühes, teised teises. Samuti

poleks selle lahenduse puhul võimalik uut liidest rajada samale andmebaasile, sest sama baas

ei saa kindlasti teenindada kaht erineva loogikaga rakendust. Samas peaks hangete otsing

võimaldama otsida nii vana kui uue registri andmetest, mis tähendab otsingu jaoks teatavate

vahetükkide ehitamist. Kaks eraldi rakendust tooks kaasa ka probleeme kasutajate haldamisel,

sest pole ju mõeldav, et kummalgi oleks eraldiseisev kasutajate baas. Samas on aga vajadus

muuta kasutajate rolle ja õigusi – kuigi mitte väga suures ulatuses, siis natuke siiski. Neid

muudatusi ei saaks siis ellu viia ilma et automaatselt oleks vaja ümber häälestada vana

registrit.

2.3 Süsteemi arhitektuur

2.3.1 eRHR Moodulid.

Registri uus kasutajaliides on planeeritud üles ehitada modulaarsena.

Moodul ehk teenus peab omama iseseisvat ja ülejäänust võimalikult sõltumatut

funktsionaalsust. Moodulil peavad olema ülejäänud osistega konkreetsed ja fikseeritud

kokkupuutepunktid. Ainult sellistele kriteeriumitele vastavaid osiseid on mõtet eraldi

moodulitena defineerida. Modulaarsus tagab registri paindlikuma arendusvõimekuse

tulevikus.

Menetlusmoodul on arendatava kasutajaliidese kõige kesksem moodul. Selle võiks

mõtteliselt jagada kolmeks eraldi alam-mooduliks: hankija, pakkuja ja hindamise mooduliks.

Iseseisvaid teenuseid need kolm alammoodulit siiski ei moodusta, sest nad on üksteisega

lahutamatult seotud. Tehes muudatusi hanke ettevalmistamise osas (näiteks hanke tingimuste

sisestamise loogika või osadeks jagamise loogika) avaldab see paratamatult mõju pakkumuste

koostamisele ja kohe seejärel ka pakkumuste hindamisele. Seetõttu tuleb registris muudatuste

tegemisel nende 3 osapoolega pidevalt komplektselt arvestada. Menetlusmoodul hõlmab

endas hanke ettevalmistamist hankija poolt, taotluste ning pakkumuste koostamist ja

esitamist, taotluste ja pakkumuste hindamist, lepingute sõlmimist ehk teisisõnu kogu hanke

menetlemise protsessi.

Teadete moodul on menetlusmooduli täiendus ning sisaldab endas hanke teadete sisestamise

ja muutmise funktsionaalsust, teate failide genereerimist, rahvusvaheliste teadete TED

süsteemile esitamist, avaldamise tagasiside lugemist TEDist.

Teabevahetusmoodul on menetlusmooduli täiendus ning võimaldab hanke piires esitada

küsimusi (nii hankijal kui ka pakkujal) ning vastata küsimustele, saata teateid, ettepanekuid

kutseid. Hankevälist suhtlust kasutajate vahel eRHR ei toeta, st puudub vajadus võimaldada

ühe registri kasutaja pöördumist teise kasutaja poole väljaspool hanke menetlemise konteksti.

Teabevahetusmoodul ei sisalda registri kasutamisel esinevate veateadete edastamist


© AS Datel 2016 12/120

süsteemitoele, registri peakasutajate teavitamist lisandunud kasutajatest, pakkujatest ega muid

taolisi sõnumeid. Nendega tegeleb teavitusmoodul.

E-oksjoni moodul on menetlusmooduli täiendus, mille ülesanne on e-oksjonite läbiviimine.

Menetlusmoodulist laekub e-oksjoni sisend ja oksjoni lõppedes on menetlusmoodulile

kättesaadav oksjoni tulem.

Haldusmoodulisse jäävad kasutajate, hankijate, pakkujate haldus, klassifikaatorite ja

süsteemsete häälestuste muutmine. Samuti kõikvõimalike eelistuste haldamine.

Haldusmoodulis tehtavad määrangud mõjutavad kahtlemata kõigi teiste moodulite tööd.

Teavituste mooduli ülesanne on toota ja saata välja süsteemseid teavitusi registris toimuvate

sündmuste puhul. See moodul on ainsana ka tänases süsteemis eraldiseisvana realiseeritud.

Teistes moodulites toimuvate sündmuste puhul, milliste hulk on arenduse käigus

kokkulepitud, toimub pöördumine teavituste mooduli poole, mis siis koostab vastava teavituse

ja saadab selle ära. Teavituse sisu, saajad, saatmise aeg ja saatmise viis – see kõik on

häälestatav kasutajaliidese kaudu.

Päringumoodulis toimub hangete, teadete, vaidlustuste, pakkumuste jt registri objektide

otsimine, nimekirjade kuvamine, eksportimine.

Infotellimuste moodul on päringumooduli laiendus ja see võimaldab registri kasutajatel

koostada päringutingimusi, mille vastused edastab süsteem kasutajaile automaatsete

teavitustena. Infotellimused on mõeldud peamiselt selleks, et teavitada kasutajaid uutest

avaldatud hangetest, mis võiks neile huvi pakkuda. Üks osa infotellimuste moodulist on ka

RSS uudistevoog.

Statistikamoodul on päringumooduli osa, mis võimaldab koostada statistilisi aruandeid

hangete kohta, sh ka nii hankijate kui hankija allasutuste lõikes.

E-kataloogi moodul on menetlus- ja haldusmooduliga liidestatav eraldiseisev rakendus, mis

talitleb ka iseseisvalt, eRHR süsteemist sõltumatult. Liidestusel realiseeritakse automaatne

andmevahetus moodulite vahel. E-kataloog sisaldab endas tootekataloogi funktsionaalsust:

pakutavate toodete haldamist pakkuja poolt, toodete sirvimist ning tellimuste tegemist hankija

esindajate poolt, arvete koostamist ja edastamist.


© AS Datel 2016 13/120

cmp Moodulid

Menetlusmoodul

Päringumoodul

Haldusmoodul Teav ituste moodul

Teabev ahetusmoodul

Teadete moodul

E-oksjoni moodul

Infotellimuste

moodul

Statistika moodul

E-kataloogi moodul


© AS Datel 2016 14/120

2.3.2 eRHR Paigaldusvaade

2.3.2.1 X-Tee turvaserver / X-Tee

X-Tee andmevahetuskiht.

Kasutusel teiste registritega suhtlemiseks.

Tarbitavad X-tee teenused:

ariregxbrl.aruande_dokument.v1

arireg.detailandmed_v3.v1

cmp Component Model

E-maili serv er

X-tee

Tomcat 7

Tomcat 8 / Weblogic 12c klaster

Apache httpd serv er

Kasutaja Veebilehitseja

eRHR frontend

eRHR Backend

Oracle Andmebaas

RHR_USER

CASU

CAS

X-Tee turv aserv er

SMTP serv er

Kasutaja

RHR Moodulid

- E-oksjoni moodul

- Haldusmoodul

- Infotell imuste moodul

- Menetlusmoodul

- Päringumoodul

- Statistikamoodul

- Teabevahetusmoodul

- Teadete moodul

- Teavituste moodul

E-Kataloogi moodul (arendamisel)


© AS Datel 2016 15/120

riregxbrl.esitatud_aruanded.v1

emta.vptRhs.v1

dhl.getSendingOptions.v2

dhl.sendDocuments.v2

mtr2.ettevotja.v1

tlnopinfo.vptRhs.v1

2.3.2.2 SMTP server / E-maili server

Standardne E-mailide saatmise server.

2.3.2.3 Apache httpd server

Standardne Apache httpd server. Kasutuses https protokolli maha võtjana ja

koormusjaoturina.

2.3.2.4 eRHR Backend

Java REST backend rakendus, eemärgiga asendada vana süsteem.

Rakenduse kasutamine toimub läbi REST päringute, andmevahetuse formaat on JSON.

Rakendus töötab nii Weblogic 12c'ga kui ka Tomcati veebi konteineriga.

Rakendus pakub RHR spetsiifilisi REST teenuseid. Antud teenuste tarbijaks on "RHR

frontend" projekt. Vajadusel saab neid kasutada ka teiste rakenduste jaoks.

Pakutavad teenused jagunevad avalikeks ja privaatseteks. Privaatsed teenused nõuavad

eelnevat meldimist läbi CAS'i ning õigusi RHR süsteemis.

Platvorm Weblogic 12c, Tomcat 8, Java 8

IoC Spring Framework 4.1

Anmebaasi kiht Spring JDBC + Nortal Petit ORM

Turvalisus Spring Security 4.0

Puhverdamine ehcache 2.6

REST Spring MVC 4.1

Ehitamine Gradle 2.X

Turvalisuse aspekt on implementeeritud Spring Security raamistikuga. Autentimine toimub

CASi vastu. Privaatse teenuse kasutamise jaoks peavad olema õigused süsteemis ning

sessioon rakenduses. Sessioon antakse peale rakenduse sisenemist ning hoiatakse küpsise sees

nimega JSESSION tunnusega HTTPOnly. Täiendavalt kasutatakse küpsise kaudu Cross Site

Request Forgery ründe vastumeedet.

Avalike ning privaatsete teenuste jaoks on erinevad URL'id ning erinevad Spring MVC

kontrollerid (annoteeritud Spring Security annotatsioonidega). JSON formaadis andmed


© AS Datel 2016 16/120

läbivad nii enne REST teenusega edastamist (GET päringud) kui REST teenuste poole

pöördumisel (PUT/POST päringud) turvafiltri, mis eemaldab andmetest kõik kontekstivälised

ja tehnilised atribuudid (sh. primaar- ja võõrvõtmed, kirjete loomise/muutmise ajad ja

kasutajatunnused jms).

2.3.2.5 eRHR frontend

Angular JS veebi rakendus. Rakenduse paigaldus koosneb staatilistest failidest (*.html, *.css,

*.js, *.png), mis laetakse kasutaja lehitsejasse "RHR Backend" konteinerist. Kasutaja

lehitsejas käivitatakse javascripti moodul, mis tekitab kogu kasutajaliidese dünaamiliselt.

Andmeid vahetatakse "RHR Backend" mooduliga läbi HTTP REST teenuste. Äriloogikat on

selles moodulis väga minimaalselt, rakenduse sisuline loogika asub "RHR Backend"

moodulis.

Javascripti raamistik AngularJS 1.5

Sõltuvuste haldus Bower 1.5

Ehitamine Grunt 0.4

2.3.2.6 Moodul CAS

Kasutatav CAS on arendatud JA-SIG CAS alusel. CAS toetab järgmiseid autentimise

meetodid: ID-kaart, Mobiil-ID, Parool.

Platvorm Java 7, Tomcat 7+

Ehitamine Maven 3

JA-SIG CAS versioon 3.5.2

Autentimise süsteem on standartne JASIG CAS'i jaoks. Kasutaja logib sisse CAS'i ning saab

sessiooni mõlema rakenduses. Kui kasutaja logib CAS'ist välja, siis sessioon suletakse

mõlemas rakenduses.

Kuna tegemist on klasterdatud rakendusega (klasterdatud CAS, klasterdatud RHR old

rakendus ning klasterdatud RHR Backend), siis kogu liiklus toimub balanseri kaudu. CAS'i

klastris kasutatakse "sticky" sessioone ning sessioon ei replitseeru.


© AS Datel 2016 17/120

Standartne JASIG CAS'i klient ei toeta väljalogimist klasterdatud keskkonnas, seega mõlemas

rakenduses kasutatakse Nortali poolt modifitseeritud JASIG CAS kliendi teeki. Teek hoiab

ticket'i ja sessioni vastavust rakenduse andmebaasis. Kui CAS saadab väljalogimise teate

rakendusele, suunab koormusjaotur teate suvalise klastri õlale. Kui vastavas õlas puudub

sessioon, mis tuleb lõpetada, saadab õlg väljalogimise teate kõigile klastri masinatele ning

salvestab info baasi, et antud sessiooni tuleb lõpetada.

2.3.2.7 Oracle andmebaas

Kasutusel on Oracle 10g andmebaas. Andmebaasi kasutatakse järgmiste lüüskasutajate

vahendusel:

RHR_USER Annab liigipäsu RHR_DATA ning RHR_ARHIIV skeemidele

kasutades Oracle sünonüüme.

CASU Annab liigipäsu CAS skeemidele kasutades Oracle sünonüüme.

2.3.2.8 Kasutaja veebilehitseja

Kasutaja, kes kasutab registrit veebilehitseja vahendusel.

2.3.2.9 E-kataloogi moodul

Loodav eraldiseisev rakendus.

2.4 Üldised nõuded kasutajaliidesele

Tänane E-riigihangete keskkond koosneb avalikult kättesaadavast riigihangete registri osast ja

registreeritud kasutajatele rollipõhiselt kättesaadavast menetluskeskkonnast. Registri juures

asub visuaalselt registriga ühendatud infoportaal (hetkel Liferay lahendus). Rakendus on ja

peab jääma multikeelsuse toega.

Edasiarenduse käigus loobutakse olemasolevast Liferay lahendusest ning seda hakkavad

asendama Rahandusministeeriumi kodulehe vastava suunitlusega veebilehed. Navigeerimine

infomaterjalide ning registri vahel võib jääda analoogseks praegusega.

Registri kasutajaliides peab olema realiseeritud nutiseadmetele kohanduva veebikeskkonnana

(responsive disain).

Registri päis kujundatakse riigi infosüsteemidele kehtestatud nõuetele vastavalt. Päises peaks

olema lisaks registri nimele ja vastutava töötleja logole veel ka kasutatava keele valik ning

info sisseloginud kasutaja kohta või link registrisse sisenemiseks.

Rakenduse peamenüü võiks olla ühetasandiline, et tagada parem ühilduvus nutiseadmetega.

Peamenüü valikute hulk võiks olla nii väike kui võimalik ning samal ajal tagama ligipääsu

kõigi kõigi registri põhifunktsioonide juurde eriti just anonüümse kasutaja vaatenurgast

lähtudes. Peamenüü valikutest avanevad ekraanivormid võivad omakorda sisaldada täiendavat

teise tasandi menüüd registris edasi navigeerimiseks.

Registri avalehena kuvatakse sisseloginud kasutajatele tema õiguste ja vajadustega kohanduv

töölaud. Töölaud peaks olema kujundatud stardiplatvormiks kõigi seda kasutajat puudutavate

tegevuste juurde. Töölaua täpsem kirjeldus asub pt [13.1].


© AS Datel 2016 18/120

Anonüümsetele kasutajatele kuvatakse avalehena hangete otsinguvorm, mille täpsem

kirjeldus asub pt [13.2].

Kõik registris avanevad vormid ja lehed võiksid omada otsepöördumisvõimalust. See

tähendab, et registri iga lehekülg peab kontrollima kasutaja õigusi selle lehe suhtes. Õiguste

süsteem võiks olla realiseeritud võimalikult kompaktselt. See tähendab, et iga lehe või

funktsionaalsuse juures määratletakse õiguste minimaaltasand, mille puhul vastav leht või

funktsionaalsus on kasutatav. Näiteks, kui mingi lehekülg on häälestatud avanema

tavakasutajatele, siis ei ole vaja häälestada teda avanema ka suuremate õigustega kasutajatele,

see õigus laieneb neile iseenesest.

Rakenduses Back nupu kasutamine peab olema võimalik. Kui Back nuppu kasutakse

olukorras, kus ekraanil on salvestamata andmemuudatusi, siis peab alati tulema hoiatus, et

salvestamata muudatused lähevad kaotsi, kas oled kindel.


© AS Datel 2016 19/120

3 KASUTAJAD JA ROLLID

Süsteemi kasutajateks on alati füüsilised isikud – inimesed. Kasutajad võivad olla süsteemis

tuvastatud või siis mitte. Süsteem on teatud ulatuses nähtav ka anonüümsetele isikutele.

Tuvastatud kasutajad on need, kelle andmed on süsteemile teada ja isiku identiteet ehk

vastavus nendele registreeritud andmetele on piisava usaldusväärsusega kontrollitud.

Süsteemi kasutajaks registreerumine ning süsteemi sisenemine on kirjeldatud kasutuslugudes.

Kasutajate õigused süsteemis tegutseda tulenevad tema rollist ning seotusest asutusega ja/või

hangetega.

3.1 Ligipääsuõiguste tasandid

Süsteemis eristatakse üldise ligipääsu ja vaatamisõiguste poolest 3 peamist tasandit:

anonüümne tasand

tavakasutaja tasand

erikasutaja tasand

Anonüümne tasand kehtib süsteemis tuvastamata kasutajatele.

Anonüümsel tasandil saab:

tutvuda kõigi registreeritud ja avaldamise läbinud hangete üldandmetega

vaadata ja allalaadida avalikke hankedokumente (sõltuvalt hankemenetluse liigist võivad

mõned dokumendid olla kättesaadavad ainult valitud pakkujaile)

vaadata kõiki avaldatud (hanke)teateid

näha hanke kohta esitatud avalikke küsimusi ja vastuseid

näha kõigi sõlmitud lepingute üldandmeid

näha kõiki registreeritud vaidlustusi ning vaidlustuste tulemusi

tutvuda hangete statistikaga

tutvuda hangete arhiiviga

Tava- ja erikasutaja tasandid kehtivad ainult süsteemis tuvastatud kasutajatele.

Tavakasutaja tasandil saab lisaks anonüümse tasandi võimalustele veel:

tutvuda kõigi registreeritud hankijate andmetega sh näha nendega seotud kasutajaid ning

kontaktandmeid

tutvuda kõigi registreeritud ettevõtjate andmetega sh näha nendega seotud kasutajaid ning

kontaktandmeid

tutvuda kõigi registreeritud kontrollasutuste andmetega sh näha nendega seotud kasutajaid

ning kontaktandmeid

hallata enda kontaktandmeid, eelistusi ja teavitusi, esitada infotellimusi ning tutvuda nende

tulemustega

Erikasutaja tasandil saab lisaks tavakasutaja tasandi võimalustele veel:

tutvuda kõigi hangetega, sh ettevalmistamisel hangetega

vaadata ja allalaadida kõiki hankedokumente, ka neid, mis on kättesaadavad vaid valitud

pakkujaile

näha hankedokumentide allalaadimise logi

avada (ilma muutmisvõimaluseta) kõiki hanke andmete ja tingimuste sisestusvorme

näha kõiki hankes osalejaid ja registreerumiste ajalugu

vaadata kõiki (hanke)teateid sh koostamisel ja tühistatud teateid

näha kogu hanke teabevahetust: kõiki küsimusi ja vastuseid sh privaatseid, kõiki

teabevahetuse teateid, ettepanekuid, kutseid, hanke süsteemseid teavitusi

näha hankes avatud taotluste ja pakkumuste nimekirja (ilma sisuta)


© AS Datel 2016 20/120

näha kõiki protokolle ja otsuseid sh tühistatuid

Ülalloetletud õiguste kirjeldused on vaid illustreerivad, üldsõnalised ja tasandit

iseloomustavad. Detailsed õigused on kirjeldatud funktsionaalsuste ja õiguste maatriksis [14].

3.2 Kasutaja rollid

Anonüümne kasutaja ei oma rolli. Ta on süsteemis tuvastamata isik. Ta saab tutvuda registri

andmetega anonüümsel tasandil ning mingeid muutmistegevusi ta registris teha ei saa.

Kasutajateks nimetame nüüd ja edaspidi ainult tuvastatud kasutajaid. Igale süsteemis

registreeritud kasutajale omistatakse põhiroll.

Põhirollid on järgmised:

tavakasutaja

vaidlustuskomisjoni liige (VAKO liige)

peakasutaja

kehtetu kasutaja

Tavakasutaja on roll, mis tekib kõigile registreeritud kasutajatele automaatselt. Praeguses

registris on selle rolli nimi „huvitatud isik“. Selle rolli puhul omab kasutaja ligipääsu

süsteemile tavakasutaja tasandil. Ta saab muuta oma kontaktandmeid, sh ka seotud asutuste

juures, hallata infotellimusi, isiklikke eelistusi teavituste jms osas.

Vaidlustuskomisjoni liige (VAKO liige) on selline kasutaja, kelle peamine ülesanne on

vaidlustuste lahendamine. Vaidlustamata hankeid näeb VAKO liige samas ulatuses nagu

tavakasutaja. Tal on õigus registreerida hangetele vaidlustusi, mis laekuvad komisjonile muul

viisil kui registri kaudu, ning samuti kõik vaidlustuste menetlemist ja lahendamist puudutavad

andmed. Lahendamata vaidlustega hankeid näeb VAKO liige erikasutaja tasandil, lisaks näeb

ka kõikide pakkumuste sisu ja hindamisi. Kui kõik hanke vaidlustused saavad lahendatud, siis

kaotab VAKO liige oma laiemad õigused ning näeb hanget taas tavakasutaja tasandil.

Peakasutaja on selline kasutaja, kellele on antud volitused registri seadistamiseks ning

muude spetsiifiliste tegevuste tegemiseks. Peakasutaja ei näe kunagi pakkumuste sisu ega

hindamiskäiku, kuid ülejäänud andmeid näeb ta erikasutaja tasandil. Peakasutaja täidab

muuhulgas hankijate ja pakkujate nõustaja rolli, abistab neid hangete läbiviimisel ja kõigis

registri kasutamist puudutavates küsimustes. Hangete muutmisvõimalust peakasutajal ei ole.

Peale selle kuuluvad peakasutaja tööülesannete hulka veel registri klassifikaatorite ja

seadistuste haldamine, hanke teadete kinnitamine, teiste kasutajate, hankijate, pakkujate ja

kontrollasutuste haldamine, kasutajate sidumine asutustega. Samuti hangete ühelt hankijalt

teisele ümbersuunamine, kui selliseks asjaks peaks vajadus tekkima.

Kehtetu kasutaja roll on tegelikult mõeldud kasutajakonto kehtetuks muutmiseks. Kehtetu

kasutaja ei saa enam süsteemi siseneda.

Praeguses registris esineb veel roll „kontrollija“. See roll kaob ja asendatakse tavakasutaja

rolliga. Kontrollija õigused annab kasutajale seotus kontrollasutusega. Veel esineb roll

„menetleja“, mille järgi samuti vajadus puudub, ja seda asendab peakasutaja roll.

Lisaks põhirollile laienevad kasutaja õigused seotusest asutuse ja hankega. Detailsem

kirjeldus on pt 6.


© AS Datel 2016 21/120

4 KASUTAJATE ESMAREGISTREERIMINE JA HALDUS

4.1 Süsteemi sisenemine – Eesti kasutajad

Eesti isikukoodi omavad kasutajad sisenevad süsteemi ID-kaardiga (sh e-residendi digi-IDga)

või mobiil-IDga.

E-residendi digi-ID-kaardi omanik saab dokumente digitaalselt allkirjastada ja logida sisse

kõikidesse portaalidesse ja infosüsteemidesse, mis tunnistavad Eesti ID-kaarti. Kõigil e-

residentidel on olemas Eesti isikukood ning kuigi neil ei pruugi olla ei Eesti kodakondsust ega

elamisluba, siis loeb eRHR süsteem nad võrdseteks Eesti kasutajatega – kasutajakonto tekib

Eesti riigi tunnusega.

Kui autentimise hetkel tuvastatud isikukoodiga isik ei ole süsteemis veel kasutajana

registreeritud, siis küsib süsteem täiendavalt tema kontaktandmeid, millest kohustuslik on

vähemalt e-posti aadress. Pärast kontaktandmete sisestamist ja salvestamist lisandub süsteemi

uus kasutajakonto tavakasutaja rolliga ning kasutaja on süsteemi sisenenud.

Kui tuvastatud isikukoodiga Eesti kasutajakonto oli olemas, siis võrdleb süsteem kaardi

andmetest loetud ees- ja perenime süsteemis registreerituga. Võrdlemist ei tehta

tõstutundlikult, st suur- ja väiketähtede erinevust ei arvestata. Kui kaardilt loetud nimi erineb

süsteemis registreeritust, siis uuendab süsteem automaatselt kasutaja andmed. Tekib

kasutajakonto uus versioon.

Süsteem kontrollib registreeritud kasutaja rolli. Kui see on „kehtetu kasutaja“, siis väljastab

süsteem vastava veateate ja sisenemine ei õnnestu.

Muul juhul on sisenemine õnnestunud. Kasutaja loetakse süsteemis tuvastatuks.

Sisenemise õnnestumisel kontrollib süsteem kasutaja andmete viimase muutmise aega

(arvestamata äsjasel sisselogimisel tehtud võimalikku nimemuutust). Kui see on varasem

süsteemis häälestatud intervallist, siis palub süsteem kasutajal oma kontaktandmed üle

kontrollida ja kinnitada. Kasutaja saab kontaktandmete kinnitamise ka vahele jätta, see ei ole

takistuseks süsteemi sisenemisel. Sel juhul küsib süsteem temalt kinnitust ka järgmisel

sisenemisel.

4.2 Süsteemi sisenemine - välismaalased

Välismaised kasutajad sisenevad süsteemi kasutajanime ja parooliga. Erandjuhul on

kasutajanime ja parooliga võimalik siseneda ka Eesti kasutajate puhul. Sisenemise eelduseks

on kehtiva kasutajakonto olemasolu süsteemis, kus parooliga sisenemine on aktiveeritud.

Parooli aktiveerimine Eesti kasutajate puhul toimub tähtaegselt.

Sobiva konto puudumisel väljastab süsteem veateateid, millest peab olema võimalik välja

lugeda sisenemise ebaõnnestumise põhjus: kas konto puudub ja on vaja kasutajaks

registreeruda või on parool vale või on konto kehtetu või on parooliga sisenemine

aktiveerimata.

Kõigil juhtudel instrueerib süsteem kasutajat kuidas ta peaks edasi käituma, et sisenemine

õnnestuks.

Teoreetiliselt oleks võimalik välja arendada välismaalaste autentimine STORK teenuse

kaudu. Analoogse võimaluse on loonud e-äriregistri ettevõtjaportaal. Siiski ei ole otstarbekas,

et iga riiklik portaal, register või teenus arendaks enda juures välja liidetuse STORK

teenusega. Planeeritud on, et taolise autentimisvõimaluse arendab välja riigiportaal eesti.ee


© AS Datel 2016 22/120

ning selle kaudu on võimalik siseneda kõigisse teistesse Eesti e-teeninduskeskkondadesse.

Kui see võimekus eesti.ee portaalis realiseerub, siis peaks ka eRHR register pakkuma

sisenemisvõimalust eesti.ee kaudu.

4.3 Kasutajaks registreerumine

Kasutajaks registreerumise võimalust pakub süsteem sisselogimata kasutajatele.

Kasutajaks registreerumine on alternatiiv sisselogimisele.

Kasutajaks registreerumisel kuvab süsteem kasutaja andmete sisestusvormi. Kohustuslikud

andmed on vähemalt:

riik

isikukood (unikaalne riigi piires)

ees- ja perenimi

e-post

kasutajatunnus (unikaalne süsteemi piires, soovitav kasutada näiteks e-posti aadressi)

parool

Eesti riigi valiku puhul süsteem kasutajat registreerida ei võimalda, vaid kuvab teate, et Eesti

kasutajad peavad sisenema süsteemi ID-kaardi või mobiil-ID-ga ning selle tegevuse käigus

luuakse neile ka kasutajakonto.

Muude riikide puhul lisab süsteem uue kasutajakonto ning saadab kasutajale e-kirja koos

lingiga kasutajakonto aktiveerimiseks. Kui kasutaja pöördub registrisse saadud lingi kaudu,

siis aktiveeritakse tema konto ning edaspidi on tal võimalik siseneda juba kasutajanime ja

parooliga.

Aktiveerimislink on vajalik selleks, et veenduda sisestatud e-posti aadressi korrektsuses ja

kasutajaga seotuses. Välisriikide kasutajate kontod aktiveeritakse parooliga logimiseks

vaikimisi tähtajatult.

Muudatus võrreldes olemasoleva süsteemiga seisneb selles, et tänases registris peab registri

peakasutaja uue konto aktiveerima, nüüd aga saab kasutaja seda ise teha.

4.4 Kasutaja registreerimine ja haldus peakasutaja poolt

Registri peakasutajal on võimalik lisada nii Eesti kui välismaiste isikute kasutajakontosid,

samuti muuta ja parandada nende andmeid.

Registri peakasutaja teeb seda erandjuhul, reeglina on võimalik igal kasutajal endal oma

andmed korras hoida.

Ainult peakasutaja volituste hulka kuulub kasutajate põhirolli muutmine, seda ei saa igaüks

ise teha.

Põhirolli muutmist on tarvis ainult VAKO liikmete ja teiste peakasutajate määratlemiseks.

Kõigi teiste kasutajate põhiroll on tavakasutaja ja õigused laienevad seotusest asutuste ja

hangetega.


© AS Datel 2016 23/120

4.5 Oma andmete haldamine

Oma andmete haldamise vormile pääseb iga süsteemi sisenenud kasutaja kas oma töölaualt

või registri päises kasutaja nime juures olevalt lingilt.

Kõik registri kasutajad saavad hallata oma kontaktandmeid.

Välismaised kasutajad saavad parandada ka oma nime ja isikukoodi. Viimast eeldusel, et see

on jätkuvalt riigi piires unikaalne.

Kõik kasutajad näevad oma seotust erinevate asutustega (hankijad / ettevõtjad /

kontrollasutused) ning saavad muuta oma kontaktandmeid selle asutuse juures.

Kõik kasutajad saavad oma andmete haldamise lehel seostada ennast hankijate ja

ettevõtjatega. [6.2]

Kasutaja saab oma andmete haldamise vormilt alustada ka uue asutuse registreerimist [5.3].

Oma andmete vormil saab kasutaja hallata oma infotellimusi, teavituste tellimusi, töölaua

kuvamise eelistusi jms.


© AS Datel 2016 24/120

5 SÜSTEEMIS TEGUTSEVAD ASUTUSED

eRHR süsteemis registreeritakse kolme liiki asutusi: hankijaid, ettevõtjaid ja kontrollasutusi.

Pole välistatud, et üks ja sama asutus saab tegutseda kas kahes või koguni kõigis kolmes

rollis. Näiteks on kontrollasutused tihti samaaegselt ka hankijad, kuid see pole absoluutne

nõue.

eRHR süsteemis registreeritakse need asutused siis mitu korda – igas liigis, kuhu nad

kuuluvad.

Sellel olukorral on 2 põhjendust. Esiteks on asutust kirjeldavad klassifikaatorid jm andmed

sõltuvalt liigist natuke erinevad, teiseks on see ajalooliselt niiviisi kujunenud, et hankijad ja

ettevõtjad registreeritakse eraldi ja pole põhjust hakata seda loogikat muutma. Samaaegselt

hankija ja ettevõtja rolli täitvaid asutusi pole palju.

Kontrollasutused on eRHR süsteemis uus liik asutuse jaoks ja kuna ei eksisteeri nõuet, et

kontrollasutus peab ilmtingimata ka hankija olema, siis lisanduvad nad süsteemi kolmandat

liiki asutusena.

5.1 Asutuste andmed

5.1.1 Hankijad

Hankijad on riigi-, kohaliku omavalitsuse või muud avalik-õiguslikud juriidilised isikud.

Hankijaks võib teatud juhtudel olla ka eraõiguslik juriidiline isik. ([2] §6).

Hankijad tegutsevad erinevates valdkondades, mis jagunevad

klassikaline sektor

võrgustiku sektor

kaitse- ja julgeoleku valdkond

Klassikalise sektori hankijad saavad hankeid läbi viia ka võrgustikega seotud sektoritele

kehtestatud tingimuste kohaselt (nt kohaliku omavalitsuse asutus, tellides transporditeenust),

kuid võrgustiku sektori hankija ei saa läbi viia klassikalise sektori hankeid. Mõlemad sektorid

saavad vajadusel teha hankeid kaitse- ja julgeoleku valdkonnas.

Hankijaid iseloomustavad registris järgmised andmed:

kood

nimi

aadress, sh riik

hankija tegutsemisvaldkond – klassikaline sektor / võrgustik / kaitse ja julgeolekuvaldkond

hankija liik – klassifikatsioon vastavalt hanketeate vormis nõutavale liigitusele

tegevusalade loetelu - klassifikatsioon vastavalt hanketeate vormis nõutavale jaotusele

üldine veebiaadress

üldine e-posti aadress

Lisaks registreeritakse hankijate hulgas asutusi tunnusega „toetuse saaja, kes ei ole hankija

RHS mõistes“. Sellised hankijad saavad registris läbi viia lihthankeid. Nende hangete kohta

RHS ei kehti, neid hankeid ei ole näiteks võimalik vaidlustada.


© AS Datel 2016 25/120

5.1.2 Ettevõtjad: taotlejad ja pakkujad

Ettevõtja on ettevõtja konkurentsiseaduse tähenduses ([2] §4, lg 4). Ettevõtja on äriühing,

füüsilisest isikust ettevõtja või muu majandus- või kutsetegevuses osalev isik või juriidiliseks

isikuks mitteolev ühendus või ettevõtja huvides tegutsev isik. Kui avalik-õiguslikku

funktsiooni täitev isik, riik või kohaliku omavalitsuse üksus osaleb kaubaturul, kohaldatakse

neile ettevõtjate kohta käivaid sätteid.

Pakkuja on pakkumuse esitanud ettevõtja ([2] §4, lg 22). Taotleja on taotluse esitanud

ettevõtja ([2] §4, lg 29).

eRHR süsteemis nimetatakse ettevõtjateks üldistatult kõiki potentsiaalseid pakkujaid ja

taotlejaid ehk neid ettevõtteid, kes on ennast süsteemis ettevõtjana registreerinud.

Konkurentsiseadusest tulenevalt võib ettevõtjaks olla ka juriidilise isikuna mitteregistreeritud

füüsiline isik. Sellest väikesest erandist mitte hoolides nimetame ettevõtjaid üldistatult ikkagi

asutusteks.

Tänases registris nimetatakse kõiki taolisi ettevõtjaid üldistatult pakkujateks, kuid seadusest

tulenevalt pole see mõiste üldistatud tähenduses päris õige. Käesolevas dokumendis

nimetatakse edaspidi pakkumuse esitanud või koostamist alustanud ettevõtjaid pakkujateks.

Ettevõtjaid iseloomustavad registris järgmised andmed

kood

nimi

aadress, sh riik



ettevõtte suurust iseloomustav klassifikaator

tegevusalad – tegevusalade tekstiline loetelu

5.1.3 Kontrollasutused

Kontrollasutused on eRHR süsteemi jaoks uus mõiste. Tänases registris omistatakse vastavas

õigustes kasutajatele põhiroll „kontrollija“ ning see annab kasutajatele laiemad volitused.

Sellisel juhul on aga kontrollijate haldamine täielikult registri peakasutaja ülesanne. Reaalselt

on registris ca 350 kontrollija rolli omavat kasutajat. Kõik nad esindavad mingisugust asutust,

kuid neid asutusi süsteemis ei registreerita.

Uues eRHR registris tuleb hakata registreerima ka kontrollasutusi analoogselt hankijate ja

pakkujatega. Üldine loogika oleks sel juhul sama, et registri peakasutaja registreerib

kontrolliva asutuse ja seob sellega asutuse peakasutaja rollis kasutaja, kes omakorda haldab

oma asutuse teisi kasutajaid. Täna toimub see infovahetus süsteemiväliselt, kus vastavate

kontrollasutuste juhtivad töötajad teavitavad registri peakasutajat vajadustest mõnele isikule

kontrollija rolli omistamiseks, teiselt jälle eemaldamiseks. Tuleb luua võimalus neil ise oma

inimesi registris hallata.

Kontrollasutusi iseloomustavad registris järgmised andmed

kood

nimi

aadress, sh riik




© AS Datel 2016 26/120

5.2 Asutuste kehtivus

Tänases registris puudub asutustel kehtivuse tunnus. Kõik süsteemis registreeritud asutused

on justkui kehtivad. Reaalses elus see pole nii. Asutusi likvideeritakse, nad lõpetavad oma

tegevuse. Ka riigiasutuste puhul pole see sündmus haruldane. Näiteks kohalike omavalitsuste

ühinemisel tekib pidevalt olukord, kus ühed lõpetavad tegevuse ning nende volitused võtab

üle õigusjärgne asutus. Kehtetu asutuse korral võiks registris esineda viide tema

õigusjärglasele.

Asutustel peab olema fikseeritud kehtivuse algus- ja lõpu aeg süsteemis. See ei pea

ilmtingimata kokku langema asutuse juriidilise kehtivuse andmetega, vaid väljendab pigem

asutuse kehtivuse algust ja lõppu eRHR süsteemis.

Kehtivuse algusajast on nähtav, millal vastav asutus eRHR süsteemis tegutsemist algas ja

kehtivuse lõpp näitab, millal see lõppes.

Kehtetu hankija ei saa alustada uusi hankeid, pooleli hanked tuleks suunata õigusjärglasele.

Kehtetu ettevõtja ei saa alustada uute pakkumuste ega taotluste koostamist, samuti ei saa ta

esitada pakkumusi ega taotlusi. Juba esitatud, kuid pooleli menetlemisel pakkumused

automaatselt tühistatuks ei muutu.

Kehtetu hankija või ettevõtjaga võivad jääda seotuks kasutajad, et nad ei kaotaks oma

õiguseid selle asutuse meeskonnas teostatud või lõpetatud hangetele ligipääsuks. Samal

põhjusel peab säilima ka võimalus seostada kasutajaid kehtetu asutusega.

Kehtetu kontrollasutuse juurest tuleks kõik kasutajad eemaldada. Seda võib teha süsteem

asutuse kehtetuks muutmisel automaatselt või siis tuleb realiseerida õiguste süsteemis

täiendav kontroll, et ainult kehtiva kontrollasutusega seotud kasutajad omavad seotusest

tulenevaid eriõiguseid.

5.3 Asutuste esmaregistreerimine

Eesti hankijaid ja ettevõtjaid saavad süsteemis registreerida kõik tavakasutajad.

Uute välismaiste hankijate ja ettevõtjate andmeid saavad tavakasutajad küll registrisse

sisestada, kuid nad muutuvad kehtivaks alles pärast registri peakasutaja poolset kinnitamist.

Esialgu puudub võimalus välismaiste asutuste autentsust automaatselt kontrollida. Kui tekivad

selleks sobivad teenused, näiteks liidestus Euroopa äriregistriga, siis on võimalik ka

välismaiseid asutusi registreerida sama loogika alusel nagu Eesti omi.

Kontrollasutusi registreerib ainult registri peakasutaja. Lisaks on peakasutajal loomulikult

võimalik registreerida ka kõiki teisi asutusi.

5.3.1 Eesti asutuste registreerimine

Eesti asutuste registreerimine toimub ühtemoodi nii hankijate, ettevõtjate kui kontrollasutuste

puhul.

Eesti asutuse registreerimisel on tarvis sisestada tema registrikood. Süsteem teeb automaatselt

päringu RKOARR või Äriregistrisse, et lugeda sealt asutuse põhiandmed. Kui päring

ebaõnnestub, siis pole võimalik asutust registreerida. Suure tõenäosusega on sel juhul

tegemist eksimusega registrikoodi sisestamisel. Kui päring ebaõnnestub tehnilistel põhjustel,

siis tuleb registreerimist mõne aja pärast uuesti proovida.


© AS Datel 2016 27/120

Päritoluregistris kehtetuks muudetud asutusi ei ole võimalik eRHR süsteemis uue asutusena

registreerida.

Iga asutuse kohta loetakse RKOARR või Äriregistrist nimi ja aadress. Neid andmeid registri

peakasutaja ega asutuse peakasutaja käsitsi sisestada ega muuta ei saa. Esmaregistreerimisel

loetakse ka üldine e-posti aadress, kuid seda saab edaspidi käsitsi muuta või sisestada.

Asutust registreeriv kasutaja sisestab kõik ülejäänud eRHR süsteemi jaoks vajalikud andmed

asutuse kohta ning salvestab uue asutuse.

Eesti asutused muutuvad süsteemis kehtivaks kohe lisamise hetkest alates, sest nende

olemasolu on päritoluregistris kontrollitud. Mingit täiendavat kontrolli peakasutaja poolt teha

vaja ei ole.

Kui asutust registreeris tavakasutaja, siis püüab süsteem teda automaatselt asutusega seostada.

Kui asutust registreeris süsteemi peakasutaja, siis teda uue asutusega automaatselt ei seota,

vaid eeldatakse, et peakasutaja ise lisab vajalikud kasutajakontod.

Kui lisandus riigiasutus, millel B-kaarti ei ole olemas, siis saab asutuse lisanud tavakasutajast

automaatselt selle asutuse peakasutaja.

Kui lisandus äriettevõte, siis loeb süsteem äriregistri päringust ka ettevõtte B-kaardil olevad

isikud. Seejärel kontrollib ükshaaval, kas B-kaardil olevate isikute kasutajakontod on eRHR

registris olemas. Kui on olemas, siis lisatakse vastavad isikud automaatselt asutuse

peakasutajateks. Kui ei ole olemas, siis uusi kasutajakontosid ei looda.

Kui asutust registreeriv kasutaja oli ühtlasi ka ettevõtte B-kaardil, siis seostas süsteem ta

asutusega peakasutaja rollis juba ära. Kui asutust registreeriv kasutaja ei olnud ettevõtte B-

kaardil, aga vähemalt 1 peakasutaja asutusega siiski seoti, siis lisab süsteem registreerimist

teinud tavakasutaja asutuse juurde esindaja rollis. Ühtlasi saadab süsteem peakasutajale

vastava teavituse. Kui asutust registreeriv kasutaja ei olnud ettevõtte B-kaardil ja mitte ühegi

B-kaardi isiku kasutajakontot eRHR süsteemis ei leidunud, siis lisab süsteem registreerimist

teinud tavakasutaja asutuse juurde peakasutaja rollis.

5.3.2 Eesti füüsilise isiku ettevõtjaks registreerimine

Kuna ettevõtjana võib tegutseda ka füüsiline isik, siis toetab süsteem olukorda, kus lisatava

Eesti ettevõtja registrikoodiks sisestatakse isikukood.

Tänane register kontrollib ainult isikukoodi struktuuri korrektsust ning lubab sisestada isiku

andmed käsitsi. See annab võimaluse fiktiivsete isikukoodidega ettevõtjate registreerimiseks

süsteemi. Uus register kontrollib andmeid natuke rohkem.

Kui ettevõtjat registreerib süsteemi peakasutaja, siis teeb süsteem isikukoodi alusel päringu

Rahvastikuregistrisse ja pärib sealt isiku nime ja elukoha aadressi. Aadressi on hiljem

võimalik käsitsi muuta. Päringu ebaõnnestumisel isikut ettevõtjaks registreerida ei saa.

Kui ettevõtjat registreerib tavakasutaja, siis kontrollib süsteem, kas sisestatud isikukood

langeb kokku andmeid registreeriva kasutaja isikukoodiga. Kui jah, siis omistab süsteem

automaatselt kasutaja nime ettevõtja nimeks. Ülejäänud andmed sisestab kasutaja käsitsi. Kui

isikukood ei lange kokku, siis ei luba süsteem sellist ettevõtjat registreerida.

Tavakasutaja seob süsteem automaatselt ettevõtjaga peakasutaja rollis.

Kui registri peakasutaja füüsilise isiku ettevõtjaks registreeris, siis teda süsteem ettevõtjaga

muidugi ei seo. Sel juhul otsib süsteem automaatselt sama isikukoodiga kasutajakontot ning

leidumisel seob selle ettevõtja peakasutajaks.


© AS Datel 2016 28/120

5.3.3 Välismaiste asutuste registreerimine

Välismaiste asutuste registreerimine toimub ühtemoodi nii hankijate, ettevõtjate kui

kontrollasutuste puhul. Kuigi tänases registris esineb välismaiseid asutusi ainult pakkujate

hulgas, siis pole välistatud, et nii hankijad kui ka kontrollasutused võiksid olla välismaised.

Näiteks võib tuua ühishanked, milles osalevad ka teiste riikide hankijad või välisriigi

esinduste poolt Eestis läbi viidavad hanked või näiteks Euroopa Liidu institutsioonid, kellel

võib olla voli kontrollida Eestis läbiviidavate rahvusvaheliste hangete sisu.

Välismaise asutuse registreerimisel sisestab kasutaja selle registrikoodi, riigi ja nimetuse.

Süsteem otsib registrikoodi ja riigi alusel, kas selline vastavat liiki asutus on juba

registreeritud.

Kui on, siis kuvab süsteem selle asutuse andmed ning pakub kasutajale enda seostamise

võimalust selle asutusega.

Kui ei ole, siis otsib süsteem nime sarnasuse alusel sama riigi asutusi. Ligikaudse otsingu

tingimused täpsustuvad detailanalüüsi ajal. Ligikaudset otsingut on tarvis teha selleks, et

vältida topelt asutuste registreerimist. Kasutajale kuvatakse nimekiri leitud asutustest ja

palutakse veenduda, et sobiv asutus juba registris ei esine.

Kui kasutaja kinnitab lisamise soovi, siis kuvab süsteem asutuse ülejäänud andmeväljad.

Kasutaja täidab need vajalikul määral ning salvestab.

Välismaised asutused süsteemis kohe kehtivaks ei muutu. Süsteem saadab registri

peakasutajale teavituse uue välismaise asutuse lisandumisest ning registreerimist teostanud

kasutajale annab tagasisidet, et uus asutus on saadetud kinnitamisele.

Registreerimise teostanud kasutaja seotakse uue asutusega peakasutaja rollis.

5.3.4 Allüksuste registreerimine

Uue RHSi kohaselt peab olema võimalik registreerida iseseisvaks hankijaks suurte asutuste

allüksuseid (osakondi), kellel eraldi registrikoodi ei ole, aga kes hankimise osas toimetavad

iseseisvalt.

Selle vajaduse rahuldamiseks tuleb uues lahenduses ette näha võimalus, et iga asutuse

peakasutaja saab registrisse lisada oma registrikoodiga allüksusi. Lisamisel tekib allüksusele

sama registrikood ja märge, et tegemist on allüksusega. Kõik ülejäänud asutuse andmed

(nimi, aadress, kontaktid) on sisestatavad.

Ülemasutuse peakasutaja saab siduda kasutajaid ka kõigi oma allüksusega.

Kuigi RHS räägib taolisest vajadusest ainult hankijate osas, siis tuleks registris sama võimalus

ette näha ka ettevõtjatele. Analoogselt võivad ju ka suurte ettevõtjate allüksused iseseisvalt

pakkumusi teha.

5.4 Asutuste andmete kontroll ja haldus

Asutuse andmeid haldab üldjuhul selle asutuse peakasutaja. Tal on igal ajahetkel võimalik

avada endaga seotud asutuse andmed, neid kontrollida, parandada kontaktandmeid, käivitada

päritoluregistri päringut nime ja aadressi uuendamiseks. Samu tegevusi saab teha ka registri

peakasutaja.

Asutuse juurde salvestub selle viimase kontrollimise/muutmise aeg.


© AS Datel 2016 29/120

Kui see aeg on varasem süsteemis häälestatud intervallist ja süsteemi siseneb asutusega

seotud kasutaja, siis teeb süsteem päritoluregistrisse automaatse kontrollpäringu, et

kontrollida asutuse nime ja aadressi samasust ning asutuse jätkuvat kehtivust.

Kui päring tuvastas nime või aadressi muudatuse, siis teeb süsteem selle paranduse asutuse

andmetes automaatselt ära. Kui sisenev kasutaja on asutusega seotud esindaja rollis, siis teda

ei tülitata, aga peakasutajal palub süsteem üle kontrollida ka asutuse kontaktandmed ning

sobivus kinnitada.

Kui päring tuvastas, et asutus on muutunud päritoluregistris kehtetuks, siis muudetakse

kehtetuks ka asutuse andmed süsteemis. Kasutaja saab teate, et temaga seotud asutus muudeti

kehtetuks, aga kasutaja sisenemist süsteemi see ei takista. Küll aga ei saa see kasutaja valida

kehtetut asutust enda poolt aktuaalselt esindatavaks.

Kui päring tuvastas, et asutuse andmed olid samad ja jätkuvalt kehtivad, siis värskendab

süsteem ainult asutuse andmete kontrollimise/muutmise aega ja kasutajat ei tülita.

Kui kasutajaga on seotud välismaine asutus, siis pole võimalik selle andmeid päringuga

kontrollida. Välismaiste asutuste puhul kuvatakse asutuse peakasutajale sisenemisel kõigi

andmete kontrollimise ja kinnitamise vorm, kui viimase muutmise aeg ületab etteantud

intervalli.

5.5 Asutuste dokumendipank

Tegemist on uue vajadusega eRHR süsteemis. Vajadus puudutab eelkõige hankijaid ja

ettevõtjaid.

Asutustel on tarvis talletada süsteemis endaga seotult mitmesuguseid faile, et neid hangete

juures korduvkasutada.

Kõikides kohtades hanke menetlemise käigus, kus süsteem pakub kasutajale dokumendi

üleslaadimise võimalust, peab kasutaja saama teha seda muuhulgas ka endaga seotud asutuse

dokumendipangast. Dokumendipangast faili valik ja laadimine peab kasutaja jaoks olema

kiirem ja mugavam võimalus, kui oma arvutist faili otsimine ja laadimine.

Dokumendipanka hallatakse asutuse andmete juures. Sinna saavad uusi dokumente lisada

kõik asutusega seotud kasutajad sõltumata rollist. Samuti sealt dokumente eemaldada.

Dokumendipangas peab olema võimalus luua failikatalooge vähemalt 1 tasandi ulatuses, et

oleks võimalik elementaarsel moel faile grupeerida.

Dokumendipangas faile ei versioneerita. Neid saab ainult lisada, kustutada ja tõsta teise

kataloogi. Kataloogi loomise ja nime muutmise õigus on samuti kõigil kasutajatel võrdselt.

Dokumendipangas sisalduva faili nimi koos laiendiga peab olema kataloogi piires unikaalne,

täpselt samamoodi nagu tavalistes failisüsteemides. Täiendavalt saab iga faili juurde sisestada

ka lühikirjelduse, et oleks arusaadav, mis dokumendiga on tegemist. Lühikirjeldus ei ole

kohustuslik ja ei pea olema unikaalne. Iga faili puhul peab olema nähtav selle

dokumendipanka lisamise aeg ja lisanud kasutaja nimi.


© AS Datel 2016 30/120

6 KASUTAJATE VOLITUSED ASUTUSE JA HANKE JUURES

6.1 Kasutajate volitused asutuse juures

6.1.1 Kasutaja volitused hankija juures

Kasutajad seostatakse hankijaga järgmistes rollides:

hankija esindaja – (endine volitatud isik)

hankija peakasutaja – (endine vastutav isik)

Praeguses registris saab kasutajaid siduda ka hindaja rollis, kuid see vajadus pole enam

aktuaalne ja kõik hindajad muutuvad automaatselt hankija esindajateks.

Lisaks rollile on võimalik määrata igale seotud kasutajale e-posti aadress ja telefon selle

hankija juures. Vaikimisi omistatakse need kontaktandmed kasutaja üldandmetest.

Hankija esindaja saab lisaks oma põhirollist tulenevatele õigustele veel:

luua uusi hankeid oma hankija nimel

Hankija esindaja vaatamisõigused ei laiene.

Hankija peakasutaja saab lisaks esindaja õigustele täiendavalt veel:

seostada ja eemaldada teisi kasutajaid selle hankija juures, kelle peakasutaja ta on

muuta hankijaga seotud kasutajate rolli ja kontaktandmeid selle hankija juures

muuta hankija registris kehtetuks ning suunata pooleli hanked teisele hankijale (hankija

vahetamine)

vaadelda oma hankija hankeid erikasutaja tasandil

muuta kõigis oma hankija hangetes vastutavat isikut

Märkus. Hankijaga seostamine ei tohi vähendada kasutajale rollipõhiselt omistatud õigusi.

Näiteks kui hankija esindajaks määratakse peakasutaja rollis olev isik, siis näeb ta jätkuvalt

kõiki hankeid erikasutaja tasandil, kuigi hankija esindaja roll seda ei eelda.

6.1.2 Kasutaja volitused ettevõtja juures

Kasutajad seostatakse ettevõtjaga järgmistes rollides:

ettevõtja esindaja

ettevõtja peakasutaja


ettevõtja juures. Vaikimisi omistatakse need kontaktandmed kasutaja üldandmetest.

Ettevõtja esindaja saab lisaks oma põhirollist tulenevatele õigustele veel:

registreerida oma ettevõtja hangete juurde osalejaks

Ettevõtte esindaja vaatamisõigused ei laiene

Ettevõtja peakasutaja saab lisaks esindaja õigustele täiendavalt veel:

seostada ja eemaldada teisi kasutajaid selle ettevõtja juures, kelle peakasutaja ta on

muuta ettevõtjaga seotud kasutajate rolli ja kontaktandmeid selle ettevõtja juures

muuta ettevõtja registris kehtetuks ning suunata pooleli pakkumused teisele ettevõtjale

(pakkuja vahetamine pakkumuses)

vaadelda oma ettevõtja kõiki esitatud ja koostamisel pakkumusi koos sisuga

muuta kõigis oma ettevõtja hankemeeskondades vastutavat isikut


© AS Datel 2016 31/120

Märkus. Ettevõtjaga seostamine ei tohi vähendada kasutajale rollipõhiselt omistatud õigusi.

Näiteks kui ettevõtja esindajaks määratakse peakasutaja rollis olev isik, siis näeb ta jätkuvalt

kõiki hankeid erikasutaja tasandil, kuigi ettevõtja esindaja roll seda ei eelda.

6.1.3 Kasutaja volitused kontrollasutuse juures

Kasutajad seostatakse kontrollasutusega järgmistes rollides:

kontrollasutuse esindaja

kontrollasutuse peakasutaja


asutuse juures. Vaikimisi omistatakse need kontaktandmed kasutaja üldandmetest.

Kontrollasutuse esindaja saab lisaks oma põhirollist tulenevatele õigustele veel:

vaadelda kõiki hankeid erikasutaja tasandil

Kontrollasutuse peakasutaja saab lisaks esindaja õigustele täiendavalt veel:

seostada ja eemaldada teisi kasutajaid selle asutuse juures, kelle peakasutaja ta on

muuta asutusega seotud kasutajate rolli ja kontaktandmeid selle asutuse juures

Kontrollasutusi esindavad kasutajad näevad küll automaatselt kõigi hangete andmeid

detailselt, aga pakkumuste sisu nad ei näe. Kui on vajadus näha ka pakkumuste sisu, siis peab

kontrollasutust esindav kasutaja taotlema enda hankemeeskonda lisamist.

6.2 Kasutaja seostamine asutusega

Asutusega sidumata kasutajad saavad registris tegutseda ainult nende põhirollist tulenevate

õiguste alusel. Kui kasutaja roll on tavakasutaja ja ta ei ole ühegi asutusega seotud, siis ei ole

tal anonüümse kasutajaga võrreldes oluliselt enam õiguseid.

Seepärast juhendab süsteem taolist kasutajat tema töölaual ennast asutusega seostama.

Asutusega sidumist saab iga kasutaja teha oma andmete haldamise vormil. Seda saavad teha

ka need, kes juba on seotud mõne asutusega. Töölaual juhendamist aga pakub süsteem ainult

ilma asutuse seoseta tavakasutajaile, sest valdav enamus esindabki ainult üht asutust.

Oma andmete haldamise vormil vajutab kasutaja nuppu „Lisan seose ettevõtjaga“ või „Lisan

seose hankijaga“ olenevalt sellest, kumba liiki asutusega ta end seostada soovib.

Kontrollasutusega kasutaja ise end siduda ei saa.

Süsteem kuvab vastavat liiki asutuse otsinguvormi. Kasutaja teostab otsingu ning valib

nimekirjast soovitud asutuse. Kui kasutaja soovitud asutust ei leia, siis saab ta sama

otsinguvormi pealt alustada uue lisamist.

Kui valitud asutus oli Eesti äriettevõte, siis teostab süsteem päringu Äriregistrisse saamaks

teada B-kaardi isikud. Kui kasutaja kuulub B-kaardi isikute hulka, siis seob süsteem kasutaja

asutusega peakasutaja rollis, kui ei kuulu või kui valitud asutus ei ole Eesti äriettevõte, siis

esindaja rollis.

Enne seose lõplikku salvestamist kuvab süsteem veel kontaktandmete sisestuse vormi asutuse

juures: e-post ja telefon. Vaikimisi on need täidetud väärtustega kasutaja üldistest andmetest.

Kasutaja saab sisestada asutuse juurde teistsugused kontaktid, kui on tema üldistes andmetes.


© AS Datel 2016 32/120

6.2.1 Esindatava asutuse vahetamine

Üks kasutaja võib registris olla seotud mitmete asutustega: erinevate hankijate, ette võtjate või

kontrollasutustega.

Kuigi kasutaja õigused registris tegutseda sellest ei vähene, milline esindatav asutus tal

parajasti aktiivselt valitud on, siis on mõne funktsionaalsuse jaoks siiski oluline, et esindatav

asutus oleks üheselt määratud. Üheks selliseks on näiteks töölaua kujundus.

Kasutaja klõpsab registri päises esindatava asutuse nimel.

Süsteem avab modaalse akna, kus on loetletud kõik kasutajaga seotud asutused. VAKO

liikme ja registri peakasutaja jaoks on seal ka valik: esindatav asutus puudub.

Kasutaja teeb oma valiku, mille peale aken automaatselt sulgub.

Süsteem kuvab registri päises kasutaja poolt valitud asutuse nime või kasutaja põhirolli nime

asutuse puudumisel.

6.3 Hankemeeskonna haldamine

Hankega tegelemiseks komplekteerivad nii hankija kui ka hankes osalevad ettevõtjad oma

meeskonnad, kellel on võimalik konkreetse hanke juures menetlustegevusi teha. Kõik

ülejäänud kasutajad, sh registri peakasutaja, saavad hanke andmeid ainult vähemal või

rohkemal määral vaadata.

6.3.1 Hanke hankijapoolne meeskond

Hanke läbiviimiseks komplekteerib hankija meeskonna, kes tegeleb hanke korraldamise ja

läbiviimisega. Hanke meeskonna liikmetel on vaadeldava hanke suhtes oluliselt suuremad

õigused kui ülejäänud kasutajatel.

Hanke meeskonda lisatakse kasutajaid järgmistes rollides:

vaatleja

hindaja

volitatud isik

vastutav isik

Uut hanget saavad registrisse luua kõik hankijaga seotud kasutajad – nii hankija peakasutajad

kui ka esindajad. Sellest isikust, kes uue hanke registrisse loob, saab automaatselt hanke

vastutav isik. Edaspidi on võimalik vastutavat isikut ka vahetada. Seda saab teha hanke

vastutav isik ise määrates enda asemel vastutajaks kellegi teise sama hankijaga seotud

kasutaja või hanke volitatud isikud või siis hankija peakasutajad, kes saavad suunata hankeid

ühelt vastutavalt isikult teisele.

Vaatleja on hankemeeskonnas kõige lihtsam roll. Ta saab hanget vaadata täies ulatuses, sh ka

esitatud ja avatud pakkumusi. Hindamisi ega hanke andmete muutmist teha ei saa. Kui

kontrollasutuse töötaja soovib tutvuda esitatud pakkumuste sisuga, siis lisatakse ta

hankemeeskonda vaatlejaks.

Hindaja rollis hanke meeskonnas olev isik saab hanget vaadata samamoodi täies ulatuses

nagu vaatleja. Lisaks vaatleja õigustele saab ta hinnata pakkumusi, kui hanke menetlemine on

jõudnud vastavasse faasi. Hindaja ei oma hanke andmete muutmise õigust.

Volitatud isik saab hanke juures kõike teha. Volitatud isik ongi selline, keda vastutav isik on

volitanud enda eest hankega tegelema. Volitatud isik saab lisada hankemeeskonda teisi


© AS Datel 2016 33/120

volitatud isikuid ning kõiki muid meeskonnaliikmeid, sh ka vahetada vastutavat isikut.

Volitatud isik hindab pakkumusi nagu ka hindaja rollis meeskonnaliikmed. Volitatud isik

vaatleb hanget samas ulatuses nagu vaatleja. Lisaks sellele on tal õigus muuta kõiki hanke

andmeid (seaduste ja süsteemi ärireeglitega piiratud ulatuses ja tingimustel). Volitatud isikuid

võib hankemeeskonnas olla mitu.

Vastutav isik vastutab hanke sisulise läbiviimise eest. Tema kontaktandmed avaldatakse

hanketeates ning tema poole võib pöörduda seda hanget puudutavates mistahes küsimustes.

Vastutavaid isikuid on igas hankes alati täpselt 1. Registris on vastutaval isikul samad õigused

nagu volitatud isikul.

Vastutavaks ja volitatud isikuks saab määrata ainult hankijaga seotud isikuid. Kui isik

eemaldatakse hankija juurest näiteks põhjusel, et ta ei tööta enam selle hankija juures, siis

kaotab isik automaatselt oma õigused hankemeeskonna liikmena ilma et teda tuleks

meeskonnast eemaldada.

Vaatleja ja hindaja rollis saab hankemeeskonda lisada suvalisi kasutajaid, kes ei pruugi olla

hankijaga seotud. Sellised kasutajad lisatakse hankemeeskonda alati tähtajaliselt. Vaikimisi

on tähtajaks 6 kuud alates lisamise hetkest. Vastutav ja volitatud isik saavad seda tähtaega

korrigeerida lühemaks või pikemaks vastavalt vajadusele.

Kasutaja hankemeeskonna rollist tulenevad õigused mõjuvad täiendava klausliga: kasutaja

peab olema kas hanke hankijaga seotud või peab tema hankemeeskonna rolli kehtivuse

tähtaeg olema tulevikus. Vastasel korral kasutajale hankemeeskonna liikme roll ei mõju.

See lahendus on vajalik selleks, et hankija juurest lahkunud töötajad ning välised kasutajad ei

saaks igavest ligipääsu hanke pakkumustele ning et lahkunud töötajaid ei peaks teostatud

hangete meeskondadest eemaldama.

6.3.2 Hanke ettevõtjapoolne meeskond

Hanke ettevõtjapoolse meeskonna komplekteerib ettevõtja kas pärast hanke juurde osalejaks

registreerumist või hiljemalt selleks ajaks, kui ta on otsustanud hakata koostama pakkumust.

Tänases registris saavad kõik pakkujat esindavad kasutajad ligipääsu kõigile selle pakkuja

pakkumustele. See asjaolu ei sobi eriti just suurtele ettevõtetele, kus tahetakse piirata oma

töötajate ligipääsu erinevatele pakkumustele.

Hanke ettevõtja meeskonda lisatakse kasutajaid järgmistes rollides:

volitatud isik

vastutav isik

Hanke juurde osalejaks registreerumisel saab registreerumise teinud kasutajast automaatselt

selle ettevõtja vastutav isik hankemeeskonnas. Edaspidi on võimalik vastutavat isikut ka

vahetada. Seda saab teha vastutav isik ise määrates enda asemel vastutajaks kellegi teise sama

ettevõtjaga seotud kasutaja või hankemeeskonna volitatud isikud või siis ettevõtja

peakasutajad, kes saavad suunata hanke pakkumuste vastutust ühelt isikult teisele.

Vastutav isik vastutab selle hanke juures nii taotluste kui pakkumuste koostamise eest. Ta on

ühtlasi ettevõtja kontaktisik seda hanget puudutavates küsimustes. Vastutavaid isikuid on iga

ettevõtja meeskonnas alati täpselt 1.

Volitatud isik on hanke ettevõtja meeskonnas samade õigustega kasutaja nagu vastutav isik.

Volitatud isikuid võib meeskonnas olla mitu. Volitatud isik ongi selline, keda vastutav isik on


© AS Datel 2016 34/120

volitanud enda eest hankega tegelema. Volitatud isik saab lisada ettevõtja meeskonda teisi

volitatud isikuid ning vahetada vastutavat isikut.

Hanke ettevõtja meeskonda saab määrata ainult ettevõtjaga seotud isikuid. Kui isik

eemaldatakse ettevõtja juurest, siis kaotab ta oma õigused hanke meeskonnas automaatselt

ilma et teda oleks tarvis meeskonnast eemaldada.

Kõigile ettevõtja meeskonnaliikmetele kehtivad ühesugused õigused. Nad saavad esitada

hanke kohta küsimusi ning vastata ettevõtjale esitatud küsimustele. Nad näevad ainult

osalejaile mõeldud teabevahetust. Nad saavad alustada hanke juures taotluste ja pakkumuste

koostamist. Nad saavad esitada taotlusi ja pakkumusi. Nad saavad registris tutvuda pakkujaile

nähtavate protokollide ja otsustega.


© AS Datel 2016 35/120

7 HANKE MENETLEMINE

7.1 Hange

Riigihange (edaspidi lühidalt hange) on asja ostmine, teenuse tellimine, ideekonkursi

korraldamine, ehitustöö tellimine ja kontsessiooni andmine hankija poolt. ([2] §4, 24).

Hanke esemeks on kas asi, ehitustöö või teenus.

Hanke läbiviimiseks on võimalik kasutada erinevaid menetluskäike.

Hanke eesmärk võib olla kas hankelepingu või raamlepingu sõlmimine, ideekonkursi

korraldamine, dünaamilise hankesüsteemi või kvalifitseerimissüsteemi loomine, kontsessiooni

andmine.

Hanke andmekoosseis jääb üldjoontes muutmata. Hankel on jätkuvalt olemas üldandmed,

tingimused, teated ning muud dokumendid, milliseid hakatakse nüüd üldistavalt nimetama

hanke alusdokumentideks.

Ühis- ja keskse hanke korral esinevad teised hankijad, hanget läbiviiv hankija jääb jätkuvalt

üheselt määratuks.

Hankel on jätkuvalt olemas hankijapoolne meeskond. Hanke juurde registreeritakse osalejaid,

kellel nüüd uuendusena samuti tuleb komplekteerida meeskond.

Hanke juures on jätkuvalt teabevahetuse osa, mis saab olulisi täiendusi kasutatavuse

seisukohast. Süsteem väljastab registris toimuvate sündmuste puhul kasutajatele automaatseid

teavitusi.

Hanke raames esitatakse taotlusi ja pakkumusi, nende läbivaatamise ja hindamise tulemusena

tekivad protokollid ja otsused, mida nüüd hakatakse üldistatult nimetama hanke

tulemdokumentideks.

Hanke tulemusena sõlmitakse lepinguid edukate pakkujatega.

Hanget on võimalik vaidlustada. Vaidlustusi koos tulemustega kuvatakse samuti hanke juures.

7.2 Hanke andmetega tutvumine

Arenduse käigus muutub hanke kuvamise loogika. Tänases registris toimub hanke andmete

kuvamine ja muutmine ühtedel ja samadel vormidel. Seetõttu on vaja mitmeid hanke andmete

vormi lehekülgi kuvada tühjalt lihtsalt selleks, et oleks võimalik alustada lisamist.

Uues registris toimub hanke vormil peaasjalikult ainult andmete kuvamine. Muudatused

tehakse töölehelt avanevate muutmisvormide kaudu. Erandiks on teabevahetus ja meeskonna

haldamine, mida vastavate õiguste olemasolul tõepoolest saab teha otse hanke andmete

vormil.

Hanke andmete ekraanivorm on jaotatud mitmeks leheküljeks. Lehekülgi kuvatakse vastavalt

sellele, kas nendel leidub andmeid või mitte. Kui andmeid pole, siis ei kuva süsteem ka

lehekülje sakki.

7.2.1 Hanke päis

Ekraanivormi ülaservas kuvatakse hanke päis ning päises mõned kõige üldisemad hanke

andmed, et lehekülgede vahetamisel oleks arusaadav, millise hankega parajasti on tegu.


© AS Datel 2016 36/120

Päises kuvatakse hanke kohta järgmised andmed:

hanke viitenumber

nimetus

hankija nimi (ühtlasi link, mis avab hankija üldandmed vaatamiseks)

hanke seisund

alustamise aeg

pakkumuste või taotluste esitamise aeg

7.2.2 Üldandmed

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=hange1_uldandmed

Hanke andmetega tutvumine algab tavapäraselt üldandmete lehelt. Sellele lehele on

koondatud kõik hanke alusandmed, mis on nähtavad anonüümsetele ja tavakasutajatele.

Kui hankest huvitatud kasutajad tutvuvad uue, hiljuti avaldatud hankega, siis saavad nad kogu

vajaliku info kätte üldandmete lehelt ning rohkem lehekülgi neile ei kuvatagi. Kui hange on

juba hilisemas faasis, siis ei mahu kogu info enam ühele lehele ära ning siis tekib hanke

vormile ka lehekülgede menüü.

Hanke kohta tervikuna peab üldandmete lehel sisalduma vähemalt järgmine info:

hanke eesmärk

hankelepingu liik

hankemenetluse liik

menetluse liigi valiku põhjendus (kui see on olemas)

hanke sektor

cpv-koodid koos nimetustega

lühikirjeldus

hanke eeldatav kogumaksumus

hankelepingu kestus

tunnus, kas on tegemist rahvusvahelise hankega (puudub, kui ei ole)

tunnus, kas kasutatakse EL vahendeid

tunnus, kas kasutatakse e-menetlust

tunnus, kas kasutatakse e-oksjonit

tunnus, kas kasutatakse e-kataloogi

tunnus, kas hange on keskkonnahoidlik

hanke vastutava ja volitatud isikute nimed ja kontaktandmed

Viited ja lingid

Viide eelmisele hankele, kui see on olemas: hanke viitenumber, nimetus, hankija nimi.

Ühtlasi link hanke andmete vormi avamiseks.

Viide eelteatele, kui see on hankes olemas: teate tüüpvormi kood, nimetus, avaldamise aeg.

Ühtlasi link teate trükivormi avamiseks.

Viide alustavale teatele: teate tüüpvormi kood, nimetus, avaldamise aeg. Ühtlasi link teate

trükivormi avamiseks.

Link hankedokumentidele. Avaneb hankedokumentide nimekiri, millest omakorda on

võimalik avada hankedokumente.

Link avalikele küsimustele vastustele. Lingilt avaneb ekraanivorm, kus on nähtavad kõik

avalikud küsimused koos vastustega ning linkidega manustele.

Hanke osad

http://tarkvara.datel.ee/proto/erhr/#p=hange1_uldandmed


© AS Datel 2016 37/120

Tunnus, kas hange on jaotatud osadeks. Kui jah, siis teave, kas pakkumisi saab teha ühele,

mitmele või kõigile osadele. Edasi järgneb osade loetelu, kus iga osa detailandmed on

dünaamiliselt avatavad. Iga osa kohta kuvatakse vähemalt järgmised andmed:

osa number ja nimetus

kirjeldus

cpv-koodid koos nimetustega

osa eeldatav maksumus

osa hankelepingu kestus

tunnus, kas kasutatakse EL vahendeid

tunnus, kas kasutatakse e-oksjonit

tunnus, kas kasutatakse e-kataloogi

tunnus, kas hanke osa on keskkonnahoidlik

Kõik andmed esitatakse võimalikult loetaval viisil.

7.2.3 Kaasatud hankijad

Lehekülg kuvatakse ühis- või kesksete hangete korral tavakasutajatele. Lehel on nähtav

hankes osalevate teiste hankijate nimekiri koos vastutava isiku nime ja kontaktandmetega.

Keskse hanke korral on lehel nähtavad ka ministeeriumide jt valdkondlike asutuste

registrikoodid, kellega seotud asutused hankega ühinema on oodatud. Samal lehel on neil

asutustel võimalik ka keskse hankega liituda.

7.2.4 Hankija meeskond

Lehekülg kuvatakse ainult hankija meeskonna liikmetele ning erikasutaja tasandil vaatlejatele.

Lehel on võimalik vaadelda hankija meeskonna liikmete nimekirja ning vastavate õiguste

olemasolul teha selles ka muudatusi.

Tavakasutajad näevad hanke vastutavat ja volitatud isikuid hanke üldandmete lehel.

7.2.5 Ettevõtja meeskond

Lehekülg kuvatakse ainult hankes osaleva ettevõtjaga seotud kasutajatele. Lehel on võimalik

vaadelda ettevõtja meeskonna liikmete nimekirja ning vastavate õiguste olemasolul teha selles

ka muudatusi.

7.2.6 Hankes osalejad


Lehel on võimalik vaadelda hanke juurde registreerunud osalejate nimekirja koos vastutava ja

volitatud isikutega. Ettevõtjad ise seda lehte ei näe, sest neile kuvatakse ainult enda andmed

eelmisel lehel. Teisi osalevaid ettevõtjaid nad ei näe.

Osalejaks registreerumine käib üldandmete lehe kaudu.

7.2.7 Alusdokumendid



© AS Datel 2016 38/120

Tavakasutajad ning hankes osalejad näevad hanke alusdokumente üldandmetest avaneva lingi

kaudu.

Lehel kuvatakse nimekiri hanke alusdokumentidest, sh ka võimalus vaadelda vanu kehtetuks

muudetud versioone. Dokumentide muutmisvõimalust sellel lehel ei ole. Muutmine toimub

ainult menetlustegevuste kaudu.

Peale selle on lehel võimalik jälgida ka hankedokumentide allalaadijaid.

7.2.8 Hanke teated

Lehekülg kuvatakse hankija meeskonna liikmetele ning erikasutaja tasandil vaatlejatele, kuid

ka tavakasutajatele, juhul kui hanke kohta on avaldatud hankelepingu sõlmimise teateid.

Lehel kuvatakse nimekiri hankega seotud teadetest, sh ka võimalus vaadelda vanu kehtetuks

muudetud versioone.

7.2.9 Teabevahetus

Lehekülg kuvatakse hankija ja ettevõtja meeskonna liikmetele ning erikasutaja tasandil

vaatlejatele.

Lehel kuvatakse nimekiri kõigist kasutajale nähtavatest teabevahetuse saadetistest:

küsimustest, teadetest, ettepanekutest, kutsetest jne.

Vastavate õiguste olemasolul on võimalik lisada ka uusi saadetisi.

Hankija meeskonna liikmed ning erikasutaja tasandil vaatlejad näevad siinkohal ka saadetiste

lugemise ja vaatamise logi.

Teabevahetus on täpsemalt kirjeldatud pt 11.

7.2.10 Taotlused / Pakkumused

Lehekülg kuvatakse hankija meeskonna liikmetele ning erikasutaja tasandil vaatlejatele.

Lehel kuvatakse nimekiri hanke kohta esitatud taotlustest ja pakkumustest. Hankija

meeskonna liikmetel on voli tutvuda taotluste ja pakkumustega ka sisuliselt: avada esitatud

faile, tutvuda hindade jt numbriliste näitajatega.

Avalikkusele kuvatakse lehekülg pärast eduka pakkumuse valikut. Avalikkus näeb andmeid

piiratud ulatuses: millised taotlused/pakkumused esitati, kelle poolt ja mis hanke osade kohta.

7.2.11 Tulemdokumendid

Lehekülg kuvatakse hankija meeskonna liikmetele ning erikasutaja tasandil vaatlejatele.

Lehel kuvatakse nimekiri hanke kohta käivatest protokollidest, otsustest jt

menetlusdokumentidest. Täpsem kirjeldus pt 10.4.


© AS Datel 2016 39/120

7.2.12 Lepingud

Lehekülg kuvatakse tavakasutajatele. Lehel kuvatakse nimekiri hanke raames sõlmitud

lepingutest, sh ka alamhangete lepingute andmed. Täpsemalt on lepingutega seonduv

kirjeldatud pt 12.

7.2.13 Vaidlustused

Lehekülg kuvatakse tavakasutajatele. Lehel kuvatakse hanke kohta esitatud vaidlustused.

Uue vaidlustuse lisamine, mida ka tavakasutajad teha saavad, on küll muuhulgas võimalik ka

vaidlustuste lehel, kuid vähemalt esimese vaidlustuse lisamine toimub siiski üldandmete lehel,

sest leht kuvatakse ainult vaidlustuste olemasolu korral.

Vaidlustused on kirjeldatud pt 14.

7.3 Menetlusprotsess

Uues eRHR registris on vajadus olulisel määral muuta hanke menetlusprotsessi.

Tänases registris tuleneb menetlusprotsess üheselt hankemenetluse liigist. See määrab

läbiviidavate tegevuste järjekorra ning seda järjekorda muuta või ümberkorraldada hankija ise

ei saa.

Uues registris määrab hankemenetluse liik vaid üldise raami, nö põhifaasid, mis tuleb läbida.

Lisaks hankijale laieneb menetlusprotsess ka hankes osalevaile ettevõtjatele – taotlejatele ja

pakkujatele. Nemad ei menetle siiski mitte hanget, vaid hanke kohta enda poolt esitatavaid

taotlusi ja pakkumusi.

1-etapiliste menetluste tegevuskäik:

hanke ettevalmistamine

pakkumuste koostamine ja esitamine

pakkumuste menetlemine

lepingute sõlmimine

2- etapiliste menetluste tegevuskäik:

hanke ettevalmistamine

taotluste koostamine ja esitamine

taotluste menetlemine

hanke ettevalmistamine pakkumuste jaoks

pakkumuste koostamine ja esitamine

pakkumuste menetlemine

lepingute sõlmimine

Sõna menetlemine on väga ülekoormatud, sest ka ettevalmistamine on ju sisuliselt

menetlemine. Seepärast nimetame pakkumuste ja taotluse menetlemist eristamise mõttes

hoopis hindamiseks. Hindamine on täht-tähelt võttes üks pakkumuste menetlemise osa, kuid

üldistatult võib seda mõistet kasutada ka kogu esitamise järgse menetluse kohta.

Neid tegevuskäike omakorda üldistades võib välja tuua 2 põhifaasi hankija jaoks -

ettevalmistamine ja hindamine, täpsustamata, mida hetkel ettevalmistatakse või hinnatakse.

Ettevõtja jaoks on üks põhifaas: taotluse/pakkumuse koostamine ja esitamine ehk lühidalt

lihtsalt pakkumise faas.


© AS Datel 2016 40/120

Menetlustegevused seostuvadki nende kõige üldisemate põhifaasidega, nii et edaspidi räägime

ettevalmistamise tegevustest, pakkumise tegevustest ja hindamise tegevustest hanke

menetlemisel.

Konkreetsete menetlustegevuste järjekord nende faaside sees peab olema suures ulatuses

hankija poolt valitav. Samuti peab olema lubatud teatud menetlustoiminguid vahele jätta.

Ettevõtjal palju valida ei ole. Tema tegevused tulenevad hankija omadest, hankija poolt tehtud

valikutest ja otsustest.

7.3.1 Hanke osade menetlemine

Teiseks olulisemaks muudatuseks on hanke osade kaupa menetlemise võimalus. Hanke

osadele peab saama rakendada menetlustegevusi erinevatel aegadel ja erinevas järjekorras.

Hanke faaside läbimine toimub aga ka osade puhul ikka samas kindlas järjekorras.

Uues eRHR registris realiseeritakse tegevuskeskne lähenemine hanke menetlemisele. Hanke

menetlusprotsess koosneb hanget korraldava hankija vastutava ja volitatud isikute poolt

läbiviidavatest tegevustest. Nende tegevuste käigus muutuvad hanke andmed. Muul viisil

hanke andmete muutmine ei ole enam võimalik.

7.3.2 Hanke seisundid

Kuigi hanke menetlemise protsess võib olla suures osas dünaamiline ja hankija poolt valitav,

siis suures plaanis on menetlemise faasid siiski konstantsed, mis toovad kaasa hanke

seisundite loogilise järgnevuse.

Alljärgneval joonisel on kujutatud hanke kui terviku võimalikud seisundid arvestades ka

osadeks jaotatud hankeid.


© AS Datel 2016 41/120

Kui hange on jaotatud osadeks, siis on seisund ka igal osal.

Seisundid ettevalmistamisel, eelteatatud ja alustatud tekivad osadele samaaegselt kui hankele

tervikuna.

Seisund taotlused avatud tekib nii hankele kui ka igale osale ka sel juhul, kui taotluste

avamisel selgub, et mitte ühtegi taotlust tegelikult ei esitatud. Osadeks jaotatud hanke korral

on võimalik, et mõnele osale taotlused laekusid ja mõnele mitte. Siis tehakse nende osade

stm Hanke seisundid

ettev almistamisel

eelteatatud

alustatud

taotlused av atud

pakkumused av atud

leping sõlmitud

täitmisel

lõpetatud

teostatud

menetlus on lõppenud

kõigi lepingute täitmise

tähtaeg on möödunud

hankemenetluse lõpetamise

teate avaldamine

hankemenetluse lõpetamise

teate avaldamine

hankelepingu sõlmimise teate

avaldamine kas kogu hanke või osadega

hanke korral viimase osa kohta

hankes registreeritakse esimene leping

1-etapilisel menetlusel

pakkumuste avamine


pakkumuste avamine


taotluste avamine

alustava teate avaldamine

hanke avaldmine registris

eelteate avaldamine

hanke loomine


© AS Datel 2016 42/120

kohta, millele taotlusi tegelikult ei laekunud või kus taotlus ei kvalifitseerunud, hankelepingu

sõlmimise teade, milles märgitakse ära osad, mille kohta lepingut tegelikult ei sõlmitagi.

Teates tuuakse ära ka põhjus, miks lepingut ei sõlmita. Sellise teate avaldamisel saab nende

osade seisundiks lõpetatud samal ajal kui teisi osi menetletakse edasi.

Täpselt sama stsenaarium kordub ka seisundiga pakkumused avatud.

Kui hankesse jääb veel edasi menetletavaid osi, siis hanke seisund tervikuna jätkab muutumist

vastavalt menetluskäigule. Kui kõik osad saavad lõpetatud seisundi, siis saab selle ka kogu

hange.

Leping sõlmitud on vaheseisund, mis omab tähtsust peamiselt osadega hankes, kus mõne osa

kohta on juba leping sõlmitud ja mõne osa kohta veel mitte. See ongi oluline rohkem osa kui

kogu hanke kontekstis. Kui osa kohta sõlmitakse leping, siis saab osa selle seisundi. Ühtsuse

huvides võiks esimese lepingu sõlmimisel saada selle seisundi ka kogu hange.

Seisundid täitmisel ja teostatud tekivad vaid kogu hanke kohta.

Hangete puhul on vajadus eristada pooleliolevaid hankeid nendest, millega enam aktiivselt ei

tegutseta. Seisundid täitmisel, teostatud ja lõpetatud on kogu hanke kontekstis lõppseisundid,

kusjuures esimesed 2 on positiivsed ja kolmas negatiivne lõppseisund. Täitmisel hanke puhul

on menetlemine küll lõppenud, aga sõlmitud lepingute täitmine veel mitte.

Seisundid leping sõlmitud ja lõpetatud on hanke osade jaoks lõppseisundid, esimene

positiivne ja teine negatiivne. Hanke osa menetlemine ja elutsükkel lõpeb lepingu

sõlmimisega. Lepingu täitmist ja teostamist jälgivad juba lepingu seisundid.

7.3.3 Tegevused hanke menetlemisel

Tegevused on hanke menetlemisprotsessi osised, mille käigus muutuvad hanke andmed.

Tegevuste kaudu ei toimu ainult teabevahetus, hankes osalejate registreerimine,

hankemeeskonna koosseisu muudatused.

Tegevusi alustab ja lõpetab kasutaja. Tegevusel on nimetus, mis peab võimalikult hästi

väljendama selle tegevuse sisu. Eesmärk on, et vaadeldes hankes läbiviidud tegevuste

nimekirja, saab kiire ja selge ülevaate, mis selle hankega toimunud on.

Sündmused on registri poolt automaatselt toimuvad tegevused. Sündmustel on toimumise aeg,

sest nende kestus on reeglina hetkeline.

Eelanalüüsi käigus selgus järgmiste tegevuste läbiviimise vajadus.

Hankija tegevused ja sündmused ettevalmistamise faasis:

hanke ettevalmistamine eelteatamiseks

hanke ettevalmistamine alustamiseks

hanke alusandmete parandamine

hanke alusandmete täiendamine pakkumuse esitamiseks

eelteate avaldamine

hanke avaldamine

alusandmete muudatuse avaldamine

Hankija tegevused ja sündmused hindamise faasis:

taotluste/pakkumuste avamine

taotlejate/pakkujate kvalifitseerimine

taotlejate/pakkujate kõrvaldamise aluste kontroll

läbirääkimised

pakkumuste vastavuse kontroll


© AS Datel 2016 43/120

e-oksjoni läbiviimine

pakkumuste hindamine

eduka pakkuja valimine

pakkumuste tagasilükkamine

lepingu sõlmimine

lepingu andmete muutmine

Ettevõtja (taotleja / pakkuja) poolsed tegevused ja sündmused:

taotluse koostamine

taotluse tagasivõtmine

taotluse täiendamine

taotluste avamine

pakkumuse koostamine

pakkumuse tagasivõtmine

pakkumuse täiendamine

pakkumuste avamine

pakkumuse kohandamine

Detailanalüüsi käigus võib see tegevuste nimekiri täieneda või muutuda. Kuigi loetletud

tegevused peaks hanke menetlemise täielikult katma, siis võib tekkida vajadus paralleel- ja

alternatiivsete tegevuste järele. Neid võib lisada ka hiljem vastavalt vajadusele. Hanke

menetlemise funktsionaalsus on tegevuste kaudu laiendatav ja muudetav.

Iga tegevus arendatakse välja sõltumatuna teistest. Kui edaspidi tekib vajadus lisada uusi

tegevusi või mõni olemasolev tükeldada mitmeks tegevuseks, siis ei põhjusta see teiste

tegevuste ümbertegemise vajadust. Nii võiks vaadelda iga tegevust nagu omaette teenust või

meetodit, kuid kõiki neid ühendab siiski hanke andmestik. Kui tekivad märkimisväärsed

muudatused hanke andmestruktuuris, siis toob see kaasa ka tegevuste kohendamise vajaduse.

Üldjuhul peaks olema korraga pooleli üksainus tegevus hanke piires hankija jaoks ja üks iga

ettevõtja jaoks. Erandiks on osadeks jagatud hanked, kus lisainfona on kirjas, millistele

osadele see tegevus rakendub. Osade korral saab olla korraga pooleli 1 tegevus iga osa kohta.

Iga tegevus saab toimuda kas 1, mitme või kõigi osade kohta.

Süsteemis kehtestatakse ärireeglid tegevuste ja sündmuste võimalike järgnevuste kohta.

Süsteem pakub kasutajale järgmist kõige loogilisemat võimalikku tegevust, kuid pakub ka

alternatiive.

7.3.3.1 Tegevustega seotud andmed

Oluline andmeloogiline täiendus uues registris võrreldes olemasolevaga seisneb selles, et

tegevustega seotud hanke andmekoosseis peab olema lahutatud hanke aktuaalsetest

andmetest. See tähendab, et tegevuse käigus lisatud või muudetud andmed ei muutu avalikuks

enne, kui tegevus lõpetatakse. Sel hetkel toimub andmete aktualiseerimine. Aktuaalsed

andmed on vaadeldavad otse hanke juures. Ajaloolised andmed on vaadeldavad tegevuste

juures.

Mõnede andmete, näiteks hankedokumentide puhul, peab ajalugu olema nähtav ka

avalikkusele. Siis ei sobi tegevuste kaudu ajaloo vaatamine, sest tegevused on nähtavaid vaid

hankemeeskonnale. Hankedokumentide ajaloolised versioonid kuvatakse kehtivate

dokumentide juures ka avalikkusele välja. Kuid hankedokumentide tulevikuversioonid, st

need, mis on lisatud lõpetamata tegevustes, ei tohi mitte kuidagi hanke andmetes kajastuda

enne tegevuse lõpetamist.


© AS Datel 2016 44/120

Lõpetamata tegevust peab olema võimalik ka kustutada ja tühistada. Sellisel juhul peab sama

juhtuma ka tegevuse andmetega. Kui tegevus kustutakse registrist täielikult, siis ka temaga

seotud andmed. Kui poolelolev tegevus tühistatakse (mingil põhjusel on oluline, et jälg

tegevuse katsetusest jääks hankele alles), siis ka jõustamata muudatused jäävad

mittekehtivana alles, aga hanke andmetes nad otseselt kunagi ei kajastu.

Lõpetatud tegevusi ei saa tühistada ja ei saa ka lõpetamist tagasi võtta. Tegevuse käigus

tehtud vigade parandamiseks tuleb teha uus tegevus.

Struktureeritud andmete puhul on oluline tagada, et tegevuse loomisel tuleks tegevusse sisse

hanke andmed aktuaalse seisuga. See tähendab, et kui on tehtud tegevus, selles muudetud

struktuursel kujul hoitavaid andmeid, siis tegevus tühistatud enne lõpetamist ning nüüd

lisatakse uus samu andmeid sisaldav tegevus, siis peab tegevuse andmete lähteseis langema

kokku hanke aktuaalsete andmetega, mitte eelmisest tühistatud tegevusest jäänud seisuga.

Andmeloogiliselt oleks otstarbekas hoida hanke aktuaalseid andmeid ühtedes tabelites, kus

versioone ei teki. Tegevustega seotud andmeid teistes, analoogse struktuuriga tabelites, kus

andmetele lisandub ka tegevuse viit. Tegevuse lõpetamisel kirjutab süsteem aktuaalsed

andmed tegevuses muudetud seisuga üle.

7.3.3.2 Tegevused vanade hangete puhul

Uue registri juurutamise hetkel ei ole mitte ühelgi hankel tegevusi, kuid ometi on hanke

menetlemine pooleli ja vajab jätkamist. Selguse huvides oleks soovitav pooleli hangetes

genereerida tegevus „vanast registrist ületoomine“ vms vähemalt kõigile pooleli hangetele, et

hiljem hanke tegevuslehte vaadetes oleks arusaadav, miks see on poolik.

Kõik tegevused tuleb realiseerida selliselt, et nad oleks kasutatavad ka vanade hangete puhul.

Kui see mingil põhjusel on keeruline või võimatu, siis tuleb arendada paralleeltegevused

vanade hangete jaoks.

Pärast tegevuskeskse menetlusmooduli juurutamist peab olema võimalik jätkata hangete

menetlemist poolelijäänud kohast.

7.3.4 Hanke tööleht

Uues eRHR kasutajaliideses lisandub hankele tegevusvaade ehk hanke tööleht. See tööleht

on hankija ja ettevõtja jaoks erinev, nii nagu ka hankija ja ettevõtja tegevused hanke juures

on erinevad.

Töölehel kuvatakse hanke menetlemise käigus läbiviidud tegevused ning tähtsamad

sündmused. Iga tegevuse juures kuvatakse tema algus ja lõpp, iga sündmuse juures tema

toimumise aeg. Hanke töölehelt peaks kasutaja saama kiire ülevaate hanke menetluskäigust.

7.3.4.1 Hanke tööleht hankija vaates

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=ettevalmistamisel_hanke_tooleht

(ettevalmistamisel hange) http://tarkvara.datel.ee/proto/erhr/#p=hindamisel_hanke_tooleht

(hindamisel hange)

Hanke tööleht peab abistama kasutajat tegevuste valikul.

Esimene tegevus ilmub hanke töölehele automaatselt. Selle tegevuse täpse liigi valib süsteem

hanke lisamise käigus sisestatud andmete põhjal.

http://tarkvara.datel.ee/proto/erhr/#p=ettevalmistamisel_hanke_tooleht

http://tarkvara.datel.ee/proto/erhr/#p=hindamisel_hanke_tooleht


© AS Datel 2016 45/120

Tegevus ise peab olema kujundatud selliselt, et kasutaja saaks intuitiivselt aru kuhu ja

milliseid andmeid ta sisestama peab.

Hanke töölehel on pooleli menetluste korral alati nähtav nupp uue tegevuse lisamiseks. Kui

kasutaja sellele vajutab, siis pakub süsteem talle enda arvates kõige loogilisemat järgmist

tegevust, kuid alternatiivide korral pakub ka neid. Tegevuste valiku juures võiks olla ka

täiendavat informatsiooni, et mida selle tegevusega täpselt teha saab ja mis puhul oleks seda

hea kasutada.

Töölehe võib realiseerida kahel võimalikul moel.

Näiteks võib süsteem lubada järgmist tegevust lisada alles siis, kui eelmine on lõpetatud.

Osadeks jagatud hanke korral on peab arvestama paralleeltegevustega osade kaupa. Iga uus

tegevus lisatakse ükshaaval pärast eelmise lõpetamist. Sõltuvalt hanke hetkeseisust ja

andmetest pakub süsteem talle sobivaimat järgmist tegevust.

Aga võib ka lubada tegevusi nö „ette ära lisada“. Näiteks realiseeritakse süsteemis mingid

näitlikud menetluskavad. Kasutaja võib kohe alguses valida endale sobiva menetlusekava,

mille alusel süsteem lisab töölehele vajalikud tegevused sobivas järjekorras. Selle lahenduse

puhul võib tekkida probleem, et kasutajal on menetluse käigus tarvidus algselt valitud teest

kõrvale kalduda ja nüüd on tal keeruline valitud tegevusjada ümberkorraldada või muuta.

Igal juhul peavad töölehel olema visuaalselt eristatavad lõpetatud, pooleliolevad ja veel

alustamata tegevused. Tegevusi võiks kuvada nende alustamise aja järjekorras, kusjuures veel

alustamata tegevuste järjekorda peab kasutaja saama muuta.

7.3.4.2 Hanke tööleht ettevõtja vaates – ettevõtja tööleht

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=ettevotja_tooleht

Hanke tööleht tekib ettevõtja jaoks hankes osalejaks registreerumise hetkel. Esimese

sündmusena on töölehel kirjas osalejaks registreerumise sündmus.

Esimest tegevust süsteem kohe ei lisa. Ettevõtja ise otsustab kas ja millal ta alustab taotluse

või pakkumuse koostamist. Vastav nupp „Alusta taotluse koostamist“, „Alusta pakkumuse

koostamist“, mille pealkiri sõltub hankemenetluse liigist ja hanke seisundist, kuvatakse

töölaual otsesõnu välja.

Järgmiste tegevuste valikud ilmuvad juba nagu ka hankija vaates nupu „Lisa järgmine

tegevus“ alt.

Teatud juhtudel (alternatiivsete pakkumuste lubatavus) on võimalik ühel ettevõtjal lisada

hankesse ka mitu erinevat pakkumust. Ettevõtja töölehel võib olla korraga pooleli 1 tegevus

iga taotluse või pakkumuse kohta.

Lisaks tegevustele ja sündmustele kuvatakse ettevõtja töölehel ka ettevõtja meekonna

haldamise võimalus.

http://tarkvara.datel.ee/proto/erhr/#p=ettevotja_tooleht


© AS Datel 2016 46/120

8 HANKE ETTEVALMISTAMINE

8.1 Uue hanke lisamine

Uue hanke lisamise link kuvatakse aktiivselt hankija esindajana tegutseva kasutaja töölaual.

Süsteem kuvab uue hanke lisamise vahevormi, kus kasutaja saab

sisestada hanke kõige põhilisemad üldandmed

viidata olemasolevale eelteatele või teha märge, et soovib lisada uue eelteate käesolevasse

hankesse

valida olemasolev hange, millelt andmete näitel uus hange luuakse

Kui uue hanke aluseks ei ole eelteade ega varasem hange, siis sisestab kasutaja ka info hanke

osade kohta. Näiteks võiks kasutaja sisestada selle vormi peal planeeritava osade arvu.

Süsteem loob siis vastava arvu osi, mille andmeid saab edasise töö käigus sisestada. Hanke

osi saab edasise töö käigus nii lisada kui eemaldada.

Kasutaja salvestab uue hanke.

Süsteem kuvab uue hanke töölehe, kuhu on juba automaatselt lisandunud esimene tegevus.

Kui kasutaja soovis lisada eelteate, siis on see tegevus hanke ettevalmistamine eelteatamisega,

kui ei soovinud, siis hanke ettevalmistamine alustamiseks.

Jätkub hanke ettevalmistamise töövoog.

8.2 Hanke ettevalmistamise tegevus

Hanke ettevalmistamise tegevust saab läbi viia hanke vastutav või volitatud isik.

Hanke ettevalmistamise tegevuse käigus sisestab kasutaja kõik hanke alusandmed.

Need on

hanke üldandmed, sh ka osade üldandmed

hankemenetlusest kõrvaldamise alused

kvalifitseerimistingimused

märgib hankepassi koostamise vajalikkuse, kui see ei ole hanke andmetest tulenevalt

kohustuslik

pakkumuse vastavustingimused

pakkumuse hindamise ja maksumuse näitajad

laeb üles lisadokumendid (vormid, näidised) või lisab need hankesse hankija

dokumendisalvest

sisestab teate andmed

Sõltuvalt hankemenetluse liigist ei ole kõigi andmete sisestamine ettevalmistuse ajal alati

kohustuslik. Tegevuse lehel on iga andmerühma juures märge, kas vastavad andmed on

piisava täpsuse ja korrektsusega sisestatud. Vabatahtlike andmete juures on teistsugune

märge.

Kui tegevuse liik on hanke ettevalmistamine eelteatamisega, siis pakub süsteem sisestatavaks

teateks eelteadet. Kui tegevus on hanke ettevalmistamine alustamiseks, siis pakub valikut

alustavatest teadetest, muuhulgas ka eelteateid märkega hanke alustamise kohta.

Kui kasutaja hanke ettevalmistamise käigus oma otsust eelteate ja alustamise suhtes muudab,

siis peab tal olema võimalik vahetada tegevust selliselt, et juba sisestatud andmed kaotsi ei

läheks. Muidu võiks ju disainida ühe tegevuse – hanke ettevalmistamine – mille sees hankija


© AS Datel 2016 47/120

otsustab, kas teeb eelteate või alustava teate, kuid oleks hea, kui see otsus kajastuks hiljem

otse hanke töölehel ilma tegevuse sisse vaatamata. Tõstab ülevaatlikkust.

Kui kõik andmed on sisestatud, siis vajutab kasutaja nuppu, mis genereerib sisestatud

andmete alusel hanke alusandmete dokumendi. See ühtne dokument sisaldab hanke

üldandmeid, osalemistingimusi, vastavustingimusi ning hindamise ja maksumuse näitajaid.

Sellest eraldi jäävad hankepass ja hanke teade ning kõik lisadokumendid.

Kui kasutaja pärast alusandmete dokumendi genereerimist veel sisestatud andmeid muudab,

siis kustutab süsteem genereeritud dokumendi ja see tuleb uuesti luua. Dokumendi juures on

nähtav selle loomise aeg.

Edasi komplekteerib kasutaja hankemeeskonna. Kuigi meeskonna liikmed on ka

tegevusväliselt muudetavad, siis mugavuse ja selguse huvides on meeskonna määramine

toodud ka ettevalmistamise tegevuse sisse. Need isikud, kellelt oodatakse hankedokumentide

kooskõlastust, tuleb lisada meeskonda vähemalt vaatlejaks.

Edasi toimub hanke kooskõlastamine.

Seejärel hanke ettevalmistamise lõpetamine.

Kui hanke ettevalmistamise tegevus on lõpetatud, siis pole seda võimalik enam tagasi võtta.

Andmete parandamiseks tuleb teha järgmine tegevus. Lõpetatud toimingu vaates

sisestusvormid enam nähtavad ei ole. Saab vaadata ainult dokumente. Hanke ajalugu säilibki

dokumentides.

8.2.1 Hanke kooskõlastamine

Hanke kooskõlastamine on hanke ettevalmistamise alamtegevus. See ei ole hankija jaoks

kohustuslik, kuid hankijal peab olema võimalus teostada kooskõlastamist soovi korral

registrisiseselt.

Kooskõlastamise eelduseks on, et kõik isikud, kellelt kooskõlastust oodatakse, on lisatud

hankemeeskonda vähemalt vaatlejaks.

Ettevalmistust teostav hanke vastutav või volitatud isik loob kooskõlastuslehe vajutades

süsteemis vastavat linki.

Süsteem pakub loetelu hankemeeskonna liikmetest. Kasutaja valib need, kellelt soovib

kooskõlastust.

Süsteem kuvab kooskõlastuslehe ekraanivormi, kus on näha kooskõlastajate nimed ja e-posti

aadressid. Soovi korral on võimalik isikuid lehelt eemaldada või lisada. Iga isiku nime taga on

valiknupud kooskõlastan / ei kooskõlasta ning märkuste lahter.

Kasutaja vajutab kooskõlastuslehel nuppu Saada teavitus.

Süsteem saadab kooskõlastajatele teavituse, mis sisaldab muuhulgas ka linki

kooskõlastuslehele.

Teavituse saanud kooskõlastaja avab lingi kaudu hanke kooskõlastuslehe. Samas on nähtav ka

kooskõlastatavate dokumentide nimekiri. Kooskõlastaja vaatab hankedokumendid läbi ja teeb

oma otsuse. Kooskõlastuslehel sisestab oma otsuse ja soovi korral lisab märkuse. Seejärel

kinnitab sisestuse (salvestab). Kooskõlastusele tekib selle lisamise aeg. Iga kooskõlastaja saab

muuta ainult enda otsust ja märkust, aga näeb ka kõiki teisi.

Süsteem ei taga, et pärast kooskõlastamist hankedokumendid enam muutuda ei saa. Kasutaja

saab alati muuta hankedokumente seni, kuni ettevalmistamise tegevus ei ole lõpetatud.

Kooskõlastuse andmise aja ja hankedokumentidel oleva süsteemi lisamise aja alusel on


© AS Datel 2016 48/120

võimalik vahet teha, milliseid versioone üks või teine kooskõlastaja on arvesse võtnud. Iga

hankija otsustab ise, kas on vaja uut kooskõlastust teha, kui hankedokumente muudetakse.

8.2.2 Ettevalmistamise lõpetamine

Kui hanke vastutav või volitatud isik on sisestanud kõik hanke alusandmed, lisadokumendid,

hanget alustava teate, kooskõlastanud need soovi korral teiste meeskonnaliikmetega, siis

märgib ta ettevalmistuse lõppenuks.

Süsteem kontrollib hanke alusandmete piisavust ja korrektsust ning märgib hanget alustava

teate esitatuks.

See sündmus veel hanget registris avalikuks ei tee. Hangete avaldamine toimub kord päevas

automaatselt. Näiteks võib see toimuda igal tööpäeval kell 16.

Vahepeal on registri peakasutajal võimalik tutvuda avaldamiseks esitatud hangetega ning

sisuliste ebakõlade avastamisel hanke avaldamine peatada. Kui registri peakasutaja seda teeb,

siis lisab süsteem hankija jaoks kohe uue tegevuse töölehele koos peakasutaja poolt sisestatud

märkusega. Hankija peab alusandmetes parandused tegema ning uuesti esitama.

Juhul, kui on tegemist rahvusvahelise hankega, siis hange ikkagi kohe registris ei avaldu, vaid

kõigepealt saadetakse hanget alustav teade avaldamiseks TEDi. Hange avaldatakse registris

kohe, kui TEDist laekub avaldamise info või kui TEDi saatmisest on möödunud vähemalt 48

tundi.

Hanke eRHR süsteemis avaldamise hetkel tekib hanke töölehele alustamise sündmus koos

selle toimumisajaga.

Kogu selle aja jooksul, kui hankija on ettevalmistamise lõpetanud, kuid hange veel ei ole

alustatud, on hanke muutmine hankija jaoks tõkestatud. Hankija ei saa alustada muutmise

tegevust enne kui ettevalmistuse lõpetamise protsess on toimunud.

Juhul kui oli tegemist hanke ettevalmistamisega eelteatamiseks, siis toimub kogu tegevuse

lõpetamise protsess täpselt samal moel, kuid selle vahega, et alustamise sündmuse asemel

tekib eelteatamise sündmus.

Väljakuulutamiseta läbirääkimistega hankemenetluse korral alustavat teadet ettevalmistamise

käigus ei tehta. Sellised hanked võib registris alustada kohe vahetult ettevalmistamise

lõpetades. Taoliste hangete nähtavus avalikkusele (tava- ja anonüümsetele kasutajatele) on

juhitav päringumooduli ärireeglitega.

8.3 Hanke alusandmete parandamine

Kui hange on juba alustatud, siis võib ikkagi tekkida vajadus parandada ettevalmistamise

käigus sisestatud andmeid.

Sellisel juhul valib vastutav või volitatud isik hanke töölehel uue tegevuse: alusandmete

muutmine.

Selle tegevuse käigus saab hankija parandada kõiki alusandmeid ning võib tekkida ka uus

teate versioon, kui parandamist vajavad teates olevad andmed.

Süsteem tagab, et parandamise tegevuse käigus muudetud andmed ei muutuks avalikuks enne

tegevuse lõpetamist.


© AS Datel 2016 49/120

Muus osas sarnaneb hanke alusandmete parandamise tegevus hanke ettevalmistamise

tegevusega. Kooskõlastamise osa alusandmete parandamise tegevuses ei ole.

Kui kasutaja lõpetab alusandmete parandamise tegevuse, siis käivitub analoogne protsess

nagu kirjeldatud ettevalmistamise lõpetamise juures.

Kui hange on rahvusvaheline ja muutus ka hanke teade, siis vajab see muudatuse edastamist

TEDi. Taas rakendub kuni 48 tunnine viivitus muudatuse esitamise ja avaldamise vahel, mille

jooksul uued muudatused on hankija jaoks tõkestatud. Pärast muudatuse avaldamist TEDis

jõustuvad muudatused ka eRHR süsteemis. Sellel hetkel saavad muudetud dokumendid ning

struktuursel kujul hoitavad hanke üldandmed muudetud kujul avalikkusele nähtavaks ja

saadetakse välja ka süsteemsed teavitused. Hanke töölehele lisandub sündmus muudatuse

avaldamise kohta registris.

8.4 Hanke alusandmete täiendamine pakkumuse esitamiseks

2-etapilistes menetlustes toimub pärast taotluste avamist ja osalemistingimuste kontrolli

hanke alusandmete täiendamine pakkumusega seotud osas.

Muutuda saavad pakkumuse vastavustingimused, hindamiskriteeriumid, maksumuse näitajad.

Need andmed võivad olla osaliselt sisestatud ka juba varem, enne taotluste esitamist.

Avalikkusele jäävadki nähtavaks taotlustele eelnenud hankedokumendid. Pakkumuse

esitamiseks lisatud täiendavad hankedokumendid on nähtavad vaid eelistatud pakkujaile.

Käesoleva tegevuse käigus valibki hankija välja need kvalifitseerunud taotlejad, kellelt ta

ootab pakkumuse esitamist. Sõltuvalt hankes seatud tingimustest on hankijal mõnikord

võimalik ise piirata taotlejate arvu.

Tegevus lõpeb pakkumuse esitamise ettepaneku saatmisega valitud taotlejaile. Kuigi

teabevahetuse saadetiste lisamine käib üldjuhul tegevuste väliselt, siis oleks soovitav selle

saadetise lisamine ühildada tegevusega. Hankija jaoks peab olema selgesti arusaadav kellele

ja mis hetkel pakkumuse esitamise ettepanek saadetakse.

8.5 Hanke tingimused

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=korvald (kõrvaldamise alused)

http://tarkvara.datel.ee/proto/erhr/#p=kvalif (kvalifitseerimistingimused)

http://tarkvara.datel.ee/proto/erhr/#p=vastavus (pakkumuse vastavustingimused)

Hanke tingimused jagunevad 3 põhimõttelisesse rühma:

hankemenetlusest kõrvaldamise alused

pakkuja kvalifitseerimistingimused

pakkumuse vastavustingimused

Kvalifitseerimistingimuste puhul eristatakse veel 2 eraldi kategooriat:

majanduslik ja finantsseisund

tehniline ja kutsealane pädevus

Hankijal on tingimuste sisestamiseks järgmised võimalused:

käsitsi läbi kasutajaliidese

kopeerimine varasemast hankest

süsteemis ettevalmistatud näidistingimusi kasutades.

http://tarkvara.datel.ee/proto/erhr/#p=korvald

http://tarkvara.datel.ee/proto/erhr/#p=kvalif

http://tarkvara.datel.ee/proto/erhr/#p=vastavus


© AS Datel 2016 50/120

Hankemenetlusest kõrvaldamise alused on EU direktiividega ning Eesti Riigihangete

seadusega kindlaks määratud ning nende puhul tuleb kasutada ainult süsteemis

ettevalmistatud näidistingimusi.

Kõigi tingimuste struktuur on üldjoontes sarnane. Hankija sisestab tingimuse ning soovi

korral seda täpsustava kirjelduse. Edasi määrab ettevõtja poolt sisestatava vastuse tüübi.

Vastuse tüübiks saab olla kas jah/ei valikuna esitatav kinnitus või sisuline vastus (tekst,

number, kuupäev). Sisulise vastuse korral peab hankija konkreetselt ja lühidalt täpsustama

(soovitavalt 1 sõnaga), millist kinnitust ta ettevõtjalt ootab.

Hankepassist tulenevatel tingimustel on keerulisem vastuse struktuur, kuid need on süsteemis

juba eelhäälestatult paigas ja hankija neid muuta ei saa. Hankepassi tingimuste kohta loe pt

8.6.

Tänases registris on ettevõtjal kohustus iga tingimuse kohta laadida üles selle tingimuse

täitmist tõendav dokument. Uues registris ei nõua hankija seda enam mitte ühegi

tingimusrühma korral. Ettevõtja kinnitab hankija poolt määratud vastuse vormis, et ta sellele

tingimusele vastab. Tõendite lisamine ei ole üldse vajalik juhul, kui seda on võimalik teistest

registritest päringute abil kontrollida. Kui see pole võimalik, näiteks välismaiste pakkujate

korral, siis on võimalik tõendeid lisada ka hiljem või soovi korral koheselt, kuid üleslaetavaid

dokumente ei seostata enam otseselt tingimusega.

Pakkumus võib olla üleslaetud ka ühe failina ning pakkuja lihtsalt kinnitab, et tema esitatud

pakkumus vastab kõigile hankija poolt seatud tingimustele.

Osadeks jagatud hangete puhul tuleb kõik tingimused siduda hanke osadega. Erandiks on

hankepassist tulenevad kõrvaldamise alused, mis alati kehtivad hanke kohta tervikuna ning

mis ei saa osade kaupa erineda.

8.5.1 Keskkonnahoidlikud tingimused

Hanke keskkonnahoidlikud tingimused määratakse kindlaks Keskkonnaministeeriumi poolt.

Tingimused kehtivad teatud konkreetsete toodete või teenuste hankimisel. eRHR süsteemi

klassifikaatoris häälestatakse eelnevalt keskkonnahoidlikud tooted ja teenused, mis on selguse

mõttes grupeeritud tooterühmadesse. Iga toote kohta saab häälestada keskkonnahoidlikke

tingimusi.

Tingimused saavad olla nii kvalifitseerimistingimused, vastavustingimused kui ka

hindamiskriteeriumid. Tingimuse sõnastus ja tüüp on määratud keskkonnaministeeriumi poolt

ja muudetav klassifikaatorites. Lisaks tingimuse sõnastusele on täiendavalt kirjeldatud ka

selle tingimuse täitmist tõendavat dokumenti ning iga tingimuse juures on ka juhendi url –

veebileht, kust saab täiendavat informatsiooni selle tingimuse kohta.

Hanke ettevalmistamise ajal saab keskkonnahoidlikke tingimusi valida analoogselt teiste

näidistingimustega. Keskkonnahoidlikke tingimusi saab lisada kvalifitseerimistingimuste,

vastavustingimuste ja hindamiskriteeriumite lehelt nupu „Lisa keskkonnahoidlikke tingimusi“

kaudu.

Hankija valib kõigepealt tooterühma ja toote ning seejärel kuvab süsteem talle selle toote

kohta kehtivad keskkonnahoidlikud tingimused. Hankija valib neist 1, mitu või kõik. Osadeks

jaotatud hanke korral ka hanke osad, mille kohta antud tingimus kehtib.

Kvalifitseerimistingimuste lehel tuleb määrata ka kategooria: majanduslik ja finantsseisund

või tehniline ja kutsealane pädevus. Hindamiskriteeriumite lehel tuleb lisaks sisestada ka

osakaal ja hindamise meetod.


© AS Datel 2016 51/120

Keskkonnahoidlikke tingimusi kuvatakse samas loetelus ülejäänud tingimustega, kuid neil on

juures keskkonnahoidlikkuse tunnus. Hankija ei saa muuta tingimuse sõnastust, kuid tal on

võimalik täpsustada tingimuses kehtivat nõuet.

Näiteks võib olla keskkonnahoidlik tingimus sõnastatud selliselt: „Mööbli kokkupanemisel

kasutatavate liimide lenduvate orgaaniliste ühendite sisaldus ei tohi ületada 10

massiprotsenti“. Hankijal on voli seda nõuet veelgi karmistada ja täpsustada, et antud

konkreetse hanke puhul eeldatakse ainult kuni 8% lenduvaid ühendeid. Selle karmistamisega

nõude keskkonnahoidlikkus ei kao. Kui hankija lõdvendaks nõuet, siis poleks see enam

keskkonnahoidlik. Seetõttu peab hankes jääma nähtavaks nii tingimuse originaalsõnastus,

mida hankija muuta ei saa, kui ka täpsustus, mille hankija saab tingimusele omalt poolt lisada.

Klassifikaatorist valitud keskkonnahoidlikke nõudeid nimetatakse keskkonnahoidlikeks

põhinõueteks. Peale selle saab hankija ka ise sõnastada keskkonnahoidlikke tingimusi, mis ei

tulene otseselt õigusaktidest. Neid nimetatakse keskkonnahoidlikeks lisanõueteks.

Hange või osadeks jaotud hanke korral selle osa saab keskkonnahoidliku tunnuse sel juhul,

kui vähemalt 1 toote kõik põhinõuded on hanke juurde valitud.

Kui hankija on valinud mõne keskkonnahoidliku tingimuse, kuid mitte kõiki põhinõudeid ja

hakkab lõpetama ettevalmistust, siis kuvab süsteem talle hoiatuse, mis selgitab, et kui

põhinõudeid ei ole valitud ei saa ka keskkonnahoidliku riigihanke tunnust.

Keskkonnahoidlike tingimuste täitmine ja menetlemine ei erine ülejäänud tingimustest.

8.6 Hankepass

Hankepass ehk Euroopa ühtne hankedokument (ESPD) on dokument, milles ettevõtja

kinnitab kõrvaldamise aluste esinemist või puudumist, kvalifitseerimise tingimustele

vastavust, kui hankija on need seadnud, ning asjakohasuse korral vastavust kriteeriumidele,

mille alusel hankija valib taotlejad, kellele teeb pakkumise esitamise ettepaneku ([2] § 4, lg

6).

Hankepassi tüüpvorm on kehtestatud Euroopa Komisjoni poolt rakendusmäärusega [10] ning

seda ei ole siiani riigihangete korraldamisel kasutatud. Hankepass ei ole analoogne tüüpvorm

hanke teadetega – teda ei esitata TED-le avaldamiseks nagu teate tüüpvorme.

Hankepass sisaldab hankija ja pakkuja andmeid, hanke lühikirjeldust ja viiteid registritele

ning pakkuja hankemenetlusest kõrvaldamise aluseid. Hankepass võib sisaldada ka muid

kvalifitseerimistingimusi, kuid need on valikulised ja vabatahtlikud. Hankija ei ole kohustatud

hankepassis kirjeldama kõiki kvalifitseerimistingimusi, ta võib teha hankepassi viite, et

kvalifitseerimistingimused on kirjeldatud hankedokumentides.

Hankepassi täidavad kõik pakkumusega seotud ettevõtjad: pakkuja, kaaspakkujad,

alltöövõtjad, kelle näitajatele tuginetakse ning täidetakse iga hanke osa kohta eraldi, kui

tingimustes on erisused. Täidetud hankepassi vorm on rahvusvahelist piirmäära ületavas

klassikalise sektori hankes kohustuslik, võrgustiku sektoris ja erimenetlustes vabatahtlik.

Hankepassil on 2 esitluskuju. Hankija poolt koostatud täitmata vorm sisaldab hankija ja hanke

andmeid ning hankija poolt nõuetena valitud tingimuste kogumit. Pakkuja poolt täidetud

hankepassi vorm sisaldab lisaks ka pakkuja andmeid ning vastuseid hankija poolt püstitatud

tingimustele.

Kõik hankepassis sisalduvad tingimused on kodeeritud. Igale koodile vastava tingimuse

sõnastus on ühtselt paika pandud Euroopa komisjoni poolt ning tõlgitud kõikidesse EL

keeltesse. Igale tingimusele on kehtestatud ka konkreetne vastuse struktuur. Mõnele

tingimusele saab vastata lihtsalt jah/ei valikuga, mõni eeldab tekstilist vastust või numbrite


© AS Datel 2016 52/120

või kuupäevade sisestust. On ka keerulisemaid variante, kus mõnele tingimusele jah

vastamise järel tuleb täiendavalt täpsustada detaile.

8.6.1 Hankepassi koostamine ja täitmine keskse teenuse abil

Märkus. Käesoleva eelanalüüsi teostamise ajal ei olnud hankepassi keskne teenus veel

kasutatav. Keskse teenuse poolt pakutav lahendus hankepassi koostamiseks ja täitmiseks võiks

olla lähtekohaks ka süsteemi integreeritava funktsionaalsuse kujundamisel.

Kui kasutada hankepassi koostamise ja täitmise keskset teenust, siis valib hankija kõigepealt

riigi, kus ta tegutseb. Teenus kuvab selles riigis kehtivad ja võimalikud tingimused. Hankija

valib nende hulgast: mõned on kohustuslikud ja mõned mitte. Seejärel koostab keskne teenus

hankepassi xml-formaadis dokumendi, mille hankija saab allalaadida ning hankele lisada.

Pakkuja laeb pakkumust koostades hankija poolt koostatud hankepassi teenusesse üles, lisab

oma andmed, täidab tingimused vastustega ja seejärel laeb täidetud hankepassi xml-formaadis

dokumendi alla, mille lisab oma pakkumusele.

8.6.2 Hankepassi integreerimine eRHR registrisse

Kui hankepassi täitmiseks kasutada ainult keskset teenust, siis peab ka täidetud hankepasside

võrdlemine ja kontrollimine olema lahendatud keskses teenuses. Selle teenuse võimalused ja

sobivus Eesti hankijate jaoks ei ole veel selgunud.

Samuti jääks keskse teenuse kasutamisel hankijaile kohustus kontrollida hankepassis

mittesisalduvaid kvalifitseerimistingimusi eRHR registris, mis on hankija jaoks kindlasti väga

ebamugav.

Euroopa Komisjoni soovituse kohaselt tuleks igal riigil välja arendada oma vajadustele vastav

teenus hankepassi koostamiseks ja täitmiseks. Komisjon kehtestab hankepassi struktuuri ja

formaadi selleks, et hankepass oleks kõigis riikides üheselt mõistetav ja kergesti tõlgitav.

Kogu keskse teenuse funktsionaalsust dubleerivalt eRHR registris arendada oleks aga väga

kulukas ettevõtmine.

Oluline on, et igas hankes oleks võimalik kerge vaevaga formeerida korrektse struktuuriga

hankepass ja et pakkuja saaks seda täita talle kõige sobivamal ja mugavamal viisil.

eRHR register toimetab sisemiselt jätkuvalt edasi struktuursel kujul hoitavate tingimustega,

mida register oskab kerge vaevaga võrrelda ning mida saab soovi korral registris ka täita.

8.6.3 Tingimuste ettevalmistamine

Registri peakasutaja valmistab ette sobivas sõnastuses kõrvaldamise alused ja muud

kvalifitseerimistingimused. Need salvestuvad registri klassifikaatorite hulka. Analoogne

funktsionaalsus on ka tänases registris olemas.

Kui on tegemist hankepassis sisalduva tingimusega, siis lisab peakasutaja selle tingimuse

juurde ka hankepassi koodi. Mõned hankepassi tingimused on omavahel seotud, st et kasutada

tuleb korraga kogu gruppi. Seega on vajadus moodustada korraga valitavaid tingimusgruppe.


© AS Datel 2016 53/120

Hankepassi tingimuste vastuse struktuur on üheselt määratletud ja see ei saa muutuda.

Muutumise korral tuleb tellida eRHR registri arendus täpselt samuti nagu ka näiteks teate

tüüpvormide muudatuste korral.

Registri peakasutaja hankepassi tingimustele vastusevariante ei häälesta. Kui on tegemist

hankepassis otseselt mittesisalduva tingimusega, siis määrab peakasutaja tingimusele ka

vastuse tüübi, milleks saab olla kas jah/ei valik või sisuline väärtus. Keerukamate vastustega

tingimusi eRHR registrisse vaikimisi ei planeerita.

Iga tingimuse juures on määratletud ka kategooria, millesse see tingimus kuulub: kas

kõrvaldamise alus, majanduslik või tehniline pädevus.

Täpselt samal moel valmistab registri peakasutaja ette ka näidistingimused pakkumuse

vastavusele.

Detailanalüüsi käigus võib selguda, et hankepassi tingimused tuleks siiski jäigalt süsteemi

sisse arendada ning peakasutaja neid häälestusega muuta ei saa. Sel juhul tuleb igasuguse

hankepassi muudatuse korral tellida registri arendus.

8.6.4 Ettevalmistatud tingimuste kasutamine

Hanke tingimuste sisestamise ajal on hankijal võimalik valida süsteemis ettevalmistatud

tingimuste hulgast või ise käsitsi tingimusi sisestada.

Hankemenetlusest kõrvaldamise aluste rubriiki ei saa hankija ise tingimusi lisada, saab ainult

valida ettevalmistatud tingimuste hulgast.

Süsteemis ettevalmistatud tingimusi ei saa hankija ise muuta ega ümber sõnastada. Küll on

hankijal võimalik tingimuse juurde lisada täpsustav või selgitav kirjeldus.

Tuleb meeles pidada, et need täpsustavad ja selgitavad kirjeldused jäävad nähtavaks ainult

registris ja registri poolt genereeritud osalemistingimuste dokumendis. Hankepassi

standardvormi need kirjeldused ei jõua, seega hankepassi keskses teenuses täitvad ettevõtjad

neid kirjeldusi ei näe. Samuti ei toimu süsteemis nende kirjelduste tõlkimist. Hankija peab

kirjeldused ise sisestama nii eesti kui inglise keeles, kui eeldab välismaiste pakkujate

osavõttu.

Osadeks jaotatud hanke korral märgib hankija milliste hankeosade kohta iga tingimus kehtib.

Hankepassist tulenevaid kõrvaldamise alused osadega ei seota. Need kehtivad alati kõigi

osade kohta.

8.6.5 Hankepassi formeerimine

Kui hankija on kõik tingimused sisestanud ja asub genereerima hanke alusandmete

dokumenti, siis moodustab süsteem kohe ka hankepassi xml-formaadis faili. Kõik andmed

selle jaoks on süsteemis olemas. Juhul, kui hanke osadele kehtivad erinevad hankepassi

tingimused, siis formeerib süsteem vastava hulga hankepasse.

Hankepassi dokumenti saab hanke juures vaadata ainult xml kujul. Pdf formaadis hankepassi

süsteem ei tooda. Inimloetaval kujul saab tingimusi vaadelda kas süsteemi poolt genereeritud

hanke alusandmete dokumendis või hanke menetlemise käigus ka struktuursel kujul registris.


© AS Datel 2016 54/120

8.6.6 Hankepassi täitmine ettevõtja poolt

Kui ettevõtja asub registris koostama taotlust või pakkumust, siis kuvab süsteem hankija poolt

määratletud kvalifitseerimistingimused koos vastuse sisestusvõimalusega. Hankepassi

tingimuste vastused sisestatakse vastavalt hankepassi nõuetele.

Ettevõtja saab tingimusi täita kolmel võimalikul viisil.

Esimene võimalus on sisestada kõik vastused registri kasutajaliidese vahendusel käsitsi.

Teine variant on laadida hankedokumentide hulgas olev hankepass üles kesksesse Euroopa

Komisjoni poolt arendatud teenusesse, täita see seal ettevõtjale sobivas keeles, salvestada

täidetud hankepassi dokument enda arvutisse. Seejärel käivitab registris tingimuste juures

oleva funktsionaalsuse - tingimuste lugemine hankepassist. Kasutaja osundab oma arvutis

täidetud hankepassi dokumendile ja käivitab tingimuste lugemise. Süsteem loeb osundatud

failist tingimuste vastused ja omistab need koostamisel olevasse taotlusesse või pakkumusse.

Osundatud faili süsteem taotluse või pakkumuse juurde ei salvesta.

Kolmas variant on kasutada tingimuste vastuste lugemisel mõne varasema hanke kohta

koostatud hankepassi. See on võimalik juhul, kui ettevõtja on juba mõnes varasemas hankes

hankepassi täitnud ja täidetud hankepass on ettevõtjal käepärast kas oma arvutis või siis

süsteemis hoitavas ettevõtja dokumendipangas.

Kõigi variantide puhul peab ettevõtja tingimuste juurde laadima üles ka tingimuse täitmist

tõendavaid dokumente, juhul kui hankija on seda nõudnud. Kui hankija ei ole nõudnud

dokumentide kohest esitamist, saab seda teha hiljem.

Kui ettevõtja on kõik tingimused sisestanud ja asub lõpetama taotluse või pakkumuse

koostamist, siis kontrollib süsteem sisestatud vastuste korrektsust ja reeglipärasust ning

genereerib muuhulgas ka täidetud hankepassi xml-formaadis faili. Süsteem loob täidetud

hankepassi alati ise, ettevõtja ei pea kunagi süsteemiväliselt täidetud hankepassi taotlusse või

pakkumusse üles laadima. Ettevõtjal on võimalik süsteemi loodud täidetud hankepassi fail

endale alla laadida või dokumendipanka salvestada edaspidiseks kasutamiseks.

8.6.7 Tingimuste kontrollimine hankija poolt

Kui hankija asub kontrollima kvalifitseerimistingimusi esitatud taotlustes või pakkumustes,

siis tegutseb ta ainult eRHR registris kuvatavate ekraanivormidega. Puudub vajadus avada ja

vaadata süsteemi poolt genereeritud täidetud hankepassi dokumente, kuigi hankijal on soovi

korral võimalus seda teha. Süsteem tagab, et ekraanivormides kuvatavad tingimuste vastused

ja hankepassi dokument oleks alati korrelatsioonis.

Hankemenetlusest kõrvaldamise aluste kontrollimisel saab hankija Eesti ettevõtjate puhul

kasutada ka eelnevalt ettevalmistatud ja häälestatud liidestusi vastavate x-tee teenustega.

8.7 Hindamiskriteeriumid ja numbrilised näitajad

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=kriteeriumid

Tänases registris on hindamiskriteeriumid ning pakkumuse maksumusvorm eraldi tabelid.

Ometi on mitmesugused numbrilised näitajad tihti samaaegselt ka hindamiskriteeriumiteks.

See on põhjustanud kasutajates palju segadust. Hankija ja pakkuja näevad maksumusvormi

erinevalt. Hankija sisestab numbrilised näitajad hindamiskriteeriumitesse, pakkuja näeb neid

maksumusvormil, kus ta peab ka väärtused sisestama.

http://tarkvara.datel.ee/proto/erhr/#p=kriteeriumid


© AS Datel 2016 55/120

Uues kasutajaliideses moodustavad hindamiskriteeriumid ja pakkumuse maksumus ning

muud numbrilised näitajad kõik ühe terviku.

Hankijal on näitajate sisestamiseks järgmised võimalused:

käsitsi läbi kasutajaliidese

näitajate import spetsiaalse struktuuriga importfailist

kopeerimine varasemast hankest

süsteemis ettevalmistatud näidiskriteeriume kasutades.

8.7.1 Näitajate lisamine käsitsi

Iga näitaja käsitsi lisamisel peab hankija meeles pidama, et tal on võimalik sama vormi kaudu

lisada nii hinnatavaid kui mittehinnatavaid näitajaid. Mittehinnatavad näitajad ei ole otseselt

kriteeriumid, aga näiteks pakkumuse kogumaksumusse summeeruvad näitajad annavad oma

osa ka selle kriteeriumi moodustumisse.

Mittehinnatavad numbrilised näitajad tekitavad üldjuhul segadust nii hankijais kui ettevõtjais.

Tekib küsimus, et miks hankija soovib nende näitajate esitamist, kui ta neid ei hinda. Kui

detailanalüüsi või hankijatelt laekunud tagasiside põhjal peaks tulema otsus, et neid näitajaid

pole üldse vaja registreerida, siis võib selle võimaluse kaotada ning näitajate sisestust selle

võrra lihtsustada. Esialgu jäi see võimalus alles, kuna tänases registris selliseid näitajaid

esineb.

Kõigepealt sisestab hankija kriteeriumi või näitaja nimetuse ja soovi korral lisab selgitava

kirjelduse.

Edasi valib hankija näitaja väärtuse tüübi. Sellest valikust sõltub, mida ta edasi sisestama

peab. Väärtuse valikud on:

hankija sisestab väärtuspunktid oma hindamismetoodika alusel

pakkuja sisestab numbrilise väärtuse

pakkumuse kogumaksumus, mille pakkuja sisestab ühe numbrina

pakkumuse kogumaksumus, mis arvutatakse üksikute näitajate summana

pakkumuse kogumaksumusse summeeruv näitaja

Esimese valiku, hankija sisestab väärtuspunktid, puhul hindavad hankija poolt valitud

hindajad esitatud pakkumuse vastavust kriteeriumile ning sisestavad vastavalt kirjeldatud

metoodikale leitud väärtuspunktid kriteeriumi väärtuseks. Süsteem peab teadma, kas parim

pakkumine on väikseima või suurima väärtuspunktide arvuga pakkumus. Hankijal on

võimalik punktide piirväärtused (min ja max punktide arv) ette anda. Kriteeriumi osakaal

mõjub sisestatud väärtuspunktidele veel täiendavalt.

Pakkuja sisestab numbrilise väärtuse nende kriteeriumite väärtuseks, mida tänases süsteemis

nimetatakse numbrilisteks näitajateks. Selle valiku puhul tuleb sisestada ka ühik, et pakkuja

teaks, milliseid väärtusi temalt oodatakse. Selle valiku puhul võib näitaja olla kas hinnatav või

mittehinnatav. Kui on hinnatav, siis tuleb valida ka hindamismeetod, et süsteem oskaks

sisestatud väärtusi automaatselt hinnata.

Pakkumuse kogumaksumus on selline kriteerium või näitaja, mida saab kogu hanke või

osadeks jaotatud hanke puhul ühe hanke osa kohta esineda ainult üks. Selle kriteeriumi

numbrilist väärtust loetakse hanke (või osa) kogumaksumuseks ja see tuuakse välja ka

pakkumuse üldandmetes. Pakkumuse kogumaksumus peab alati olema väljendatud eurodes,

teised vääringud ei ole eRHRs lubatud. Pakkumuse kogumaksumuse puhul pakub süsteem

vaikimisi hindamismeetodiks „vähim on parim“. Hankijal on võimalik muuta see ka näiteks

mittehinnatavaks näitajaks, juhul kui pakkumuse maksumus pakkumuste hindamisel üldse

rolli ei mängi. Hankija ei ole kohustatud hidama pakkumusi nende maksumuse alusel.


© AS Datel 2016 56/120

Pakkumuse kogumaksumus võib olla pakkuja poolt esitatav 2 võimalikul viisil. Kui hankija

soovib saada pakkumuse kogumaksumust ühe numbrina, siis mingisuguseid maksumusse

summeeruvaid näitajaid üldse lisada ei saa ning vanas mõistes maksumusvormi kui sellist

üldse ei teki.

Teatud juhtudel, eriti just asjade hankimise puhul, võib aga hankija soovida osta palju

erinevaid tooteid või teenuseid ning pakkumuse kogumaksumus arvutatakse nende üksikute

toodete summana.

Kui hankija on valinud, et soovib pakkumuse kogumaksumust ühe numbrina, siis järgmiste

kriteeriumite lisamisel süsteem talle enam kogumaksumuse näitajaid lisada ei võimalda.

Kui hankija on valinud, et soovib pakkumuse kogumaksumust erinevate näitajate summana,

siis pakub süsteem edaspidi lisamiseks ainult pakkumuse kogumaksumusse summeeruvaid

näitajaid.

Sellise tehnikaga püüab süsteem abistada hankijat näitajate sisestamisel

Ühik on sisestatav ainult numbriliste väärtuste puhul. Pakkumuse maksumuse puhul on

ühikuks alati EUR ja hankija poolt hinnatavate kriteeriumite puhul (väärtus)punktid.

Kogus on sisestatav ainult pakkumuse kogumaksumusse summeeruvate näitajate korral.

Ainult siis peab hankija täpsustama kui mitu või kui suure hulga tooteid ta osta soovib.

Ostetavate toodete hulk on pakkuja jaoks oluline ühiku hinna määramisel. Näiteks kui hankija

soovib osta 100 arvutit võib 1 arvuti hind olla hoopis midagi muud kui 1 arvuti ostmisel.

Hindamismeetod näitab, kas on tegemist mittehinnatava numbrilise näitajaga või hinnatava

kriteeriumiga. Viimasel juhul on süsteemi automaatika jaoks tarvilik määrata, kas vähim

väärtus on parim või suurim väärtus on parim. Seda ka hankija poolt sisestatavate punktide

puhul, sest ka need võivad olla nii ja naa: kas kohapunktid, kus väikseim väärtus on parim või

hindepunktid, kus suurim väärtus on parim.

Kriteeriumi tüüp määratakse ainult hinnatavate näitajate ehk hindamiskriteeriumite puhul.

Vastavalt uuele Euroopa Komisjoni poolt kehtestatud reeglistikule saab see olla kas hind

(samastub pakkumuse kogumaksumusega, ka seda saab olla vaid 1 kogu hanke (või osa)

kohta) või kulukriteerium või kvaliteedikriteerium. Tüübi valik on oluline kriteeriumite

hanketeates kuvamise jaoks.

Kriteeriumi osakaal sisestatakse samuti ainult hinnatavate näitajate ehk

hindamiskriteeriumite puhul. Osakaal määratakse alati %-des ning hanke (või osa)

hindamiskriteeriumite osakaalude summa peab alati olema 100% ehk üks tervik.

8.7.2 Hindamiskriteeriumite kuvamine

Kui hange on jaotatud osadeks, siis sisestab hankija kriteeriumid iga osa kohta eraldi. Hanke

kohta tervikuna ühtegi kriteeriumi siis ei teki. Osadeks jagatud hanke puhul valib kasutaja

ühe, mitu või kõik hanke osad, mille kohta lisatav kriteerium kehtib. Süsteem paljundab

lisatava kriteeriumi iga valitud osa kohta. Hiljem on võimalik iga osa juures kriteeriume eraldi

redigeerida või kustutada.

Nii nagu pakkumuse vastavustingimusi, nii ka kriteeriume esitletakse süsteemis hanke osade

kaupa. Iga osa kriteeriumid on eraldi paneelil. Kui hankel pole osi, siis pole ka paneele ja

kriteeriumid kehtivad hanke kohta tervikuna.

Kriteeriume esitletakse hankijale ja pakkujale ühesugusel viisil. Ka hankija näeb pakkuja

poolt täidetavaid lahtreid, ainult nende lahtrite täitmine on takistatud. See funktsionaalsus on


© AS Datel 2016 57/120

vajalik arusaadavuse tõstmiseks, sest praegu ei näe hankija pakkujale kuvatavat vaadet ning ei

oska sellega arvestada.

Näitajad esitletakse 3 alamtabelina, mille struktuur pisut erineb. Tühja tabeli puhul ei kuvata

ka tabeli päist. Tabeli all tuuakse välja sisestatud hindamiskriteeriumide osakaalude summa,

mis peab hanke või selle osa kohta moodustama alati täpselt 100%. Kui see nii ei ole, siis

juhib süsteem probleemile kasutaja tähelepanu.

Tänases registris on võimalik ka variant, et hankija kriteeriume struktuursel kujul ei sisesta,

vaid teeb märke, et kriteeriumid esitatakse hankedokumentides. Täieliku e-hanke

funktsionaalsuse korral on hankija kohustatud kriteeriumid ikkagi struktuursel kujul

sisestama, sest ainult sel juhul on võimalik e-menetlust läbi viia.

8.8 Hanke teade

Mõiste „teade“ on süsteemis kasutuses mitmes tähenduses. On teavituste teated, infotellimuse

teated, teabevahetuse teated jne. Siin ja edaspidi peame ilma täpsustuseta mõiste „teade“

puhul silmas hanke teadet (i.k. contract notice).

Teadetele kehtivad kindlad standardvormid. Need on Euroopa Komisjoni poolt

rakendusmäärusega kinnitatud. Kuigi standardvormid on kohustuslikud ainult rahvusvahelist

piirmäära ületavate hangete korral, mil teated saadetakse avaldamiseks ka TEDi, siis

kasutatakse samu vorme ka ainult eRHRis avaldatavate alla rahvusvahelist piirmäära hangete

puhul.

Teated jagunevad 3 põhimõttelisse rühma:

eelteated

hanget alustavad teated

hanke tulemuste kohta käivad teated.

Kui eelteate vormil sisaldub märge, et selle teate esitamisega loetakse hange alustatuks, siis

tuleb seda teadet käsitleda kui hanget alustavat teadet.

Teadete andmete sisestamine, nende esitamine TEDi ning avaldamise tagasiside lugemine

TEDist on realiseeritud süsteemi teadete moodulis. Teadete moodul on uue süsteemi arenduse

alguseks juba väljaarendatud ning tuleks uude süsteemi integreerida võimalikult väikeste

muudatustega.

Siiski jäävad teadete moodulist esialgu välja kaitse- ja julgeolekusektori valdkonna teated,

mille osas direktiiv 2009/81/EÜ on muutmata. Eksisteerib võimalus, et uue süsteemi arenduse

vältel laekub ka nende teadete kohta uus direktiiv, mis viiks kaitse- ja julgeolekusektori teated

ülejäänutega samadele alustele.

Kui seda siiski ei juhtu, tuleb uue süsteemi arenduse ajal laiendada teadete mooduli

funktsionaalsust ka kaitse- ja julgeolekusektori teadetele, sest eraldi moodulit või eraldi

käsitlust neile pole ka mõtet teha.


© AS Datel 2016 58/120

9 TAOTLUSE / PAKKUMUSE KOOSTAMINE JA ESITAMINE

Taotlused ja pakkumused on ettevõtja poolt hankesse esitatavad dokumentide kogumid.

Olemuslikult on tegemist sarnaste kogumitega.

Taotlused esinevad ainult kaheetapiliste menetluste esimeses etapis ning sisaldavad ainult

osalemistingimusi.

Pakkumused esinevad nii ühe- kui kaheetapilistes menetlustes ja sisaldavad nii

osalemistingimusi, vastavustingimusi kui ka hindamiseks vajalikke näitajaid.

Menetluskeskne tegevusloogika toob kaasa selle, et iga kord, kui taotlust või pakkumust

täiendatakse, muudetakse või kohandatakse, tekib temast uus versioon. Rakenduse kaudu on

need versioonid eristatavad ning on võimalik vaadelda nende versioonide esitamise aega ning

dokumentide koosseisu.

Kaheetapilistes menetlustes luuakse pakkumus taotluse pealt ehk teisisõnu on tegemist

taotluse järgmise versiooniga, mida nüüd nimetatakse pakkumuseks ning mis nüüd sisaldab

lisaks osalemistingimuste dokumentidele veel ka pakkumuse dokumente. Pärast pakkumuse

koostamist taotlust enam edasi ei menetleta, vaid edaspidi menetletakse osalemistingimusi

(näiteks kõrvaldamise aluseid) pakkumuse koosseisus.

9.1 Hankes osalejaks registreerumine

Hankes osalejaks registreerumiseks vajutab aktiivselt ettevõtjaga seotud kasutaja hanke

üldandmete lehel nuppu „Registreeru hanke juurde“. See nupp kuvatakse hanke üldandmetes

ainult siis, kui kasutajaga aktiivselt seotud ettevõtja ei ole veel hankes osalejaks

registreerunud ning hange on osalemiseks sobivas seisus (alustatud).

Süsteem registreerib ettevõtja hankes osalejaks ning registreerumise teinud kasutajast saab

ettevõtja vastutav isik hanke juures. Ühtlasi kuvab süsteem kohe ka hanke töölehe ettevõtja

vaates, kus on nähtav registreerumise aeg ning ettevõtja poolse meeskonna koosseis.

9.1.1 Hankes osaleja registreerimine hankija poolt

Hankijal on võimalik ka ise ettevõtjad hankes osalejaks registreerida. Seda teeb ta kindlasti

näiteks väljakuututamata läbirääkimistega hankemenetluses, kus ettevõtjail endil puudubki

üldse võimalus hankega liituda. Kuid samamoodi võib ka näiteks avatud hankemenetluses

olla hankija soov, et teatud ettevõtjad ikka kindlasti hankes osaleksid ning hankija soovib

saata neile ettevõtjatele pakkumuse esitamise ettepaneku. Selle eelduseks on ettevõtja

registreerimine hankes osalejaks.

Hankija liigub hankes osalejate lehele ning vajutab nuppu „Registreeri hankes osaleja“.

Süsteem kuvab ettevõtjate otsinguvormi, mille kaudu saab otsida ja valida soovitud ettevõtja.

Süsteem kuvab valitud ettevõtjaga seotud kasutajate nimekirja, mille hulgast hankija saab

valida ettevõtja poolse vastutava isiku hanke jaoks. Hankija ei ole siiski kohustatud seda

valikut tegema. Ettevõtja peakasutaja saab hiljem vastutava isiku ise määrata.

Ettevõtja saab hankesse registreerimise kohta süsteemse teavituse.


© AS Datel 2016 59/120

9.1.2 Ettevõtja poolse meeskonna komplekteerimine

Ettevõtja hankemeeskonnas olev kasutaja saab täiendada ettevõtja meeskonda volitatud

isikutega ning vahetada vastutavat isikut, kuid ta peab silmas pidama, et niipea kui ta asendab

iseennast kellegi teisega, ei saa ta enam teha selle hanke juures muudatusi.

9.2 Pakkumuse koostamine

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=pakkumuse_koostamine

9.2.1 Pakkumuse koostamise alustamine

Esimese pakkumuse (kaheetapilise menetluse korral taotluse) koostamise alustamine toimub

ettevõtja töölehelt hanke juures. See esimene tegevus on töölehel otsesõnu välja toodud.

Osadeks jagatud hanke korral valib ettevõtja need hanke osad, mille kohta ta soovib

pakkumust teha.

Süsteem kuvab pakkumuse koostamise tegevuse.

9.2.2 Kaaspakkujate valimine

Täneses süsteemis pidi ettevõtja kohe taotluse või pakkumuse loomise hetkel määratlema kas

tegemist on ühistaotluse või pakkumusega ning valima ka kaaspakkujad. Hiljem polnud tal

enam võimalik ühispakkujate koosseisu muuta.

Uues süsteemis saab ettevõtja pakkumuse koostamise ajal kaaspakkujate koosseisu vabalt

muuta. Seda funktsionaalsust on tarvis näiteks ka sel juhul, kui mõni kaaspakkujatest ei

kvalifitseeru ning hankija annab võimaluse ta asendada.

Kuigi kaaspakkujad vastutavad pakkumuse eest võrdselt, siis nii nagu ühishangete korral nii

ka ühispakkumuste korral üks pakkujatest on see, kes pakkumust registris koostab ja haldab.

Hiljem, kui pakkumust haldav pakkuja peaks näiteks mitte kvalifitseeruma ja kaaspakkujad

jätkavad sama pakkumusega, siis on võimalik teha ka korraldava pakkuja vahetamine.

Esialgu saab korraldav pakkuja lisada ja eemaldada teisi kaaspakkujaid ja allhankijaid.

Uuendusena on vaja pakkumuse juures välja tuua ka need allhankijad, kelle näitajatele

kvalifitseerumisel tuginetakse.

Allhankijad ei vastuta pakkumuse eest sisuliselt. Nii allhankijad kui ka kaaspakkujad peavad

saama registris ise oma osalemistingimusi täita. Allhankijad ei tohi näha pakkumuse sisulist

poolt, sh näiteks maksumust ega muid näitajaid. Kaaspakkujad tohivad näha, kuid nende

näitajate sisestus jääb ikkagi korraldava pakkuja hooleks.

Kaaspakkuja või allhankija lisamise tööprotsess sarnaneb hankija poolt ettevõtja

registreerimisega.

Kasutaja vajutab nuppu „Lisa pakkuja“.

Süsteem kuvab ettevõtjate otsinguvormi, mille kaudu saab otsida ja valida soovitud ettevõtja.

Kui valitud ettevõtja ei ole veel käesoleva hanke juurde registreerunud, siis lisatakse ta kohe

ka hankes osalejate nimekirja. Sel juhul on vaja valida ka vastutav isik selle hanke juures. Kui

valitud ettevõtja on juba käesoleva hanke juurde registreerunud, siis kasutatakse juba

määratud vastutavat isikut.

http://tarkvara.datel.ee/proto/erhr/#p=pakkumuse_koostamine


© AS Datel 2016 60/120

Mõlemal juhul on lõpptulemusena pakkumuse juures nähtav ettevõtja nimi, tema roll

pakkumuses ning vastutava isiku nimi ja kontaktandmed.

9.2.3 Pakkumusega seotud hanke osad

Tänases registris on pakkumusega seotud hanke osad vaja määrata kohe alguses pakkumuse

loomise hetkel ning nende osade koosseisu muutmine hiljem pakkumuse koostamise ajal ei

ole enam võimalik.

Uues lahenduses peab olema võimalik kogu pakkumuse koostamise vältel muuta pakkumuses

osalevate hanke osade koosseisu: osi eemaldada ja lisada.

9.2.4 Pakkumuse osalemistingimuste sisestamine

Osalemistingimuste kinnitused tuleb sisestada iga kaaspakkuja ja allhankija kohta eraldi.

Seda peab saama teha kas vastava ettevõtja esindaja ise või siis pakkumust korraldav pakkuja

nende asemel.

Pakkumuses tuuakse välja osalemistingimused iga osaleja vaates. Tingimuste kinnitusi saab

sisestada registris vastavalt hankepassis või hankija poolt määratud vormingule. Hankepassi

tingimuste kinnitusi saab importida ka mõnest olemasolevast, teise hankesse kuuluvast

hankepassist.

Tingimuste kinnitusi saab sisestada kasutajaliidese ekraanivormide kaudu, hiljem

moodustatakse sisestusest osalemistingimuste dokument ning täidetud hankepassi vormid

süsteemi poolt automaatselt.

9.2.5 Pakkumuse näitajate sisestamine

Pakkumuse vastavustingimuste kinnitused ja pakkumuse maksumus ning muud numbrilised

näitajad sisestab korraldav pakkuja vastavalt hankija poolt määratud vormingule.

Kinnituste sisestamine toimub ekraanivormide kaudu, hiljem moodustatakse sisestusest

kinnituste dokument süsteemi poolt automaatselt.

9.2.6 Pakkumuse dokumentide üleslaadimine

Uues registris ei lae pakkuja enam dokumente iga tingimuse juurde eraldi. Kõik dokumendid

laetakse üles pakkumuse juurde tervikuna. Üleslaadimise asemel saab pakkuja lisada

dokumente ka oma dokumendipangast.

See lahendus toob kaasa asjaolu, et enam ei ole eristatavad osalemistingimusi puudutavad ehk

taotluse dokumendid ja pakkumuse sisulised dokumendid. Kui detailanalüüsi käigus selgub,

et neid siiski oleks vaja eristada, kasvõi näiteks selleks, et hankijale vastavas hindamisega

seotud tegevuses kuvada, siis tuleb pakkumuse dokumentidele lisada märge, et kas tegemist

osalemist puudutava dokumendiga või pakkumuse sisulise dokumendiga.


© AS Datel 2016 61/120

9.2.7 Pakkumuse esitamine

Uues registris ei nõuta enam pakkumuse digitaalset allkirjastamist. See muudatus tuleneb

Euroopa Komisjoni rakendusmäärusest [10], mis sätestab, et nii pakkumuse koosseisus olev

hankepass kui ka kogu pakkumus peab olema esitatud kirjalikus taasesitamist võimaldavas

vormis ning et digitaalset allkirja ei ole vaja kasutada juhul, kui e-hanke platvormi

kasutamiseks nõutakse elektroonilist autentimist.

See muudatus lihtsustab, mugavdab ja kiirendab pakkumuste esitamise protsessi. Pakkuja

vajutab koostamisel oleva pakkumuse lehel nuppu „Esita pakkumus“. Süsteem kontrollib

pakkumuse andmete korrektsust, et kõik kinnitused oleks sisestatud ning pakkumuse

kinnituste dokument genereeritud. Süsteem kontrollib ka esitamise ajakohasust, st et

pakkumuste esitamise tähtaeg poleks möödunud.

Kui kõik on korrektne, siis fikseerib süsteem esitatavate dokumentide komplekti, salvestab

esitaja nime ja esitamise aja ning märgib pakkumuse esitatuks.

9.3 Pakkumuse parandamine ja tagasivõtmine

Enne pakkumuse esitamise tähtaja kättejõudmist on pakkujal alati võimalik oma pakkumust

parandada, täiendada ning uuesti esitada. On võimalik ka pakkumus tagasi võtta ning loobuda

uuest esitamisest.

Kui pakkumus on esitatud, kuid esitamise tähtaeg pole veel saabunud, siis on ettevõtja

töölehel süsteemi poolt pakutavad järgmised tegevused.

Pakkumuse parandamine. Selle tegevuse valimisel toimub kõigepealt pakkumuse

tagasivõtmise sündmus. Pakkumuse esitatud versioon märgitakse tagasivõetuks. Ühtlasi

moodustab süsteem pakkumusest uue versiooni ning lisab pakkumuse parandamise tegevuse,

mis oma sisu ja võimaluste poolest sarnaneb täilikult pakkumuse koostamise tegevusega.

Kasutaja parandab või täiendab pakkumuse andmeid ning esitab pakkumuse uuesti, mis

tekitab järjekordse pakkumuse esitamise sündmuse.

Pakkumuse kui dokumendi viitenumber parandamise käigus ei muutu.

Pakkumuse tagasivõtmisel tekib ainult tagasivõtmise sündmus. Süsteem märgib pakkumuse

esitatud versiooni tagasivõetuks ja uut versiooni ei moodusta. Kui pakkuja hiljem otsustab

siiski uue pakkumuse esitada, siis peab ta alustama uue sisestamist otsast peale. Tekib täiesti

uue viitenumbriga pakkumus.

9.4 Pakkumuse lisamine 2-etapilises menetluses

Kaheetapilises menetluses toimub pakkumuste lisamine pärast taotlejate kvalifitseerimist. Kui

hankijal on õigus taotlejate arvu piirata, siis märgib ta ära need taotlused, millega soovib

menetlust jätkata ja saadab valitud taotlejaile pakkumuse esitamise ettepaneku. Selliselt

tähistatud taotluste alusel on võimalik alustada pakkumuse koostamist.

Kaheetapilises menetluses kontrollib süsteem pakkumuse lisamisel kvalifitseeritud ja hankija

poolt eelistatuks märgitud taotluse olemasolu. Pakkumuse lisamisel kopeerib süsteem

taotluselt kvalifitseerunud taotlejad pakkumusele ning samuti kõik taotluses olevad

dokumendid. Tekib selline pakkumuse koostamise tegevus, kus osalemistingimuste kinnitusi

enam muuta ei saa.

Pakkumusele tekib taotlusest erinev viitenumber.


© AS Datel 2016 62/120

9.5 Alternatiivse pakkumuse lisamine

Kui hankija on ette näinud alternatiivsete pakkumuste esitamise võimaluse, siis on võimalik

hankesse lisada enam kui 1 pakkumus sama pakkuja poolt. Samuti on võimalik lisada

alternatiivseid taotlusi.

Taotleja ei või esitada ühist taotlust, kui ta esitab taotluse ka üksi või kui ta esitab ühise

taotluse koos teiste ühistaotlejatega. Hankija jätab kõik pärast esimest üksi esitatud taotlust

esitatud ühised taotlused või esimest ühist taotlust esitatud taotlused läbi vaatamata. ([2] § 108

lg 3). Analoogne klausel kehtib ka pakkumuste kohta.

See tähendab, et üks ja sama ettevõtja ei või esitada taotlusi ega pakkumusi kombinatsioonis

teiste erinevate ettevõtjatega. Ainult enda nimel või kombinatsioonis samade kaaspakkujatega

võib aga lisada kuitahes mitu taotlust või pakkumust. Need loetakse siis alternatiivseteks

taotlusteks või pakkumusteks.

Osadeks jaotatud hanke puhul on võimalik soovi korral esitada erinevatele osadele eraldi

taotlused või pakkumused. Kui taotlus või pakkumus käib erinevate hanke osade kohta, siis

neid ei loeta alternatiivseteks.

Kaheetapilises menetluses on ühe taotluse alusel võimalik luua mitu erinevat pakkumust.

Üheetapilises menetluses on alternatiivsete pakkumuste korral hankijal soovitav kasutada

pöördmenetlust (kõigepealt valida pakkumus ja alles seejärel kvalifitseerida), et vältida sama

pakkuja korduvat kvalifitseerimist.

9.6 Pakkumuse kohandamine

Pakkumuse kohandamine on tegevus, mis tekib pakkuja jaoks hankija initsiatiivil.

Läbirääkimiste käigus lepivad hankija ja pakkuja kokku täpsustatud nõuded. Hankija teeb

pakkujale ettepaneku pakkumuse kohandamiseks. Selleks märgib ta pakkumusele

kohandamise tähtaja ning suunab pakkumuse kohandamisele.

Ettevõtja töölehele tekib vastav tegevus, mis on juba alustatud. Pakkuja parandab või täiendab

andmeid ja esitab kohandatud pakkumuse uuesti.

Kohandamisele saatmisel eelmist pakkumuse versiooni tagasivõetuks ei märgita. Kui pakkuja

õigeks tähtajaks kohandatud pakkumust ei esita, siis jääb menetlusse alles viimati esitatud

versioon.


© AS Datel 2016 63/120

10 TAOTLUSTE / PAKKUMUSTE MENETLEMINE

Täna kasutusel olevas registris on menetlusetappide järjekord rangelt määratud ning

tagasipöördumine on võimalik vaid ühe etapi kaupa, eelnevalt tühistades rakenduse poolt

toodetud protokollid ja hankijate poolt üleslaetud asjakohased otsused. Osadega hanke puhul

saab edasi-tagasi liikuda ainult kõigi osadega korraga.

Uues lahenduses on hankijale menetlemiseks antud väga suur vabadus. Tähtsamad menetlust

puudutavad ärireeglid on järgmised.

1. Esialgne kvalifitseerimine toimub ettevõtja poolt täidetud hankepassi alusel.

2. Ettevõtja poolt täidetud hankepassis esitatud kinnitusi peab hankija aktsepteerima isegi

mitmeetapilises hankes. Vajadusel on võimalik tõendeid ja selgitusi juurde nõuda. Kui

nõude täitmist on võimalik kontrollida automaatsete päringute kaudu teistest registritest,

siis ei ole ettevõtja poolt täiendavate tõendite esitamine üldse vajalik. Kui nõude täitmist

ei ole võimalik automaatselt kontrollida, siis küsib hankija ettevõtjalt konkreetseid

tõendeid sel hetkel, kui alustab tõendite alusel osalemistingimuste kontrollimist.

3. Osadeks jagatud hanget peab saama menetleda osade kaupa eraldi. Iga osa peab saama

käsitleda nagu eraldiseisvat hanget. Asjakohased protokollid koostatakse keskkonna poolt

sõltumatult teiste osade menetlemise käigust.

4. Hankija peab igal ajahetkel omama ülevaadet hanke menetlemise käigust.

5. Avatud hankemenetluse korral on võimalik kasutada pöördmenetlust – hankija võib

alustada menetlust pakkumuste vastavaks tunnistamisest ja järgnevast pakkumuste

hindamisest. Eduka pakkuja kvalifikatsiooni kontrollitakse koos asjakohase

kinnitusmaterjali väljanõudmisega eduka pakkuja väljaselgitamise käigus.

6. Pakkuja kvalifikatsiooni peab saama kontrollida igas riigihanke etapis, seal hulgas enne

hankelepingu sõlmimist (raamlepingu, dünaamilise hankesüsteemi või

kvalifikatsioonisüsteemi alt hankimisel enne hankelepingu sõlmimist).

7. Pakkumuste avamise kohta ei ole protokolli koostamine nõutud.

8. Asjakohaseid protokolle peab saama koostada kas iga läbitud etapi järgselt või teatud

etappide läbimise järel. Seega on võimalik näiteks avatud hankemenetluses koostada üks

protokoll peale eduka pakkuja väljaselgitamist koos asjakohase otsuse üleslaadimisega.

9. Vajadusel (vaidlustamisel) peab saama kõiki menetlemise etappe uuesti läbida ilma

eelnevate etappide tulemite tühistamisega.


© AS Datel 2016 64/120

10.1 Taotluse ja pakkumuse seisundid

10.1.1 Taotluse seisundid

Kui hange on jaotatud osadeks, siis on seisund ka igal taotluses sisalduval osal.

Seisundid koostamisel, esitatud ja tagasivõetud tekivad osadele samaaegselt kui taotlusele

tervikuna. Ka seisund menetluses tekib avamise järgselt kõigile taotluse osadele.

Ülejäänud seisundid võivad esineda taotluses sisalduvatel hanke osadel erinevalt. Siiski on

üpris vähe tõenäoline, et taotluse osi erinevalt menetletaks. Võimalik on see vaid siis, kui

hanke osadel on erinevad osalemistingimused.

Taotlus tervikuna säilitab seisundi menetluses kuni kasvõi 1 tema osadest on jätkuvalt

menetluses. Kui kõigi osade menetlemine on lõppenud, siis saab taotlus kõige edukama osa

seisundi.

stm Taotluse seisundid

koostamisel

esitatud tagasiv õetud

menetluses

menetlusest

eemaldatud

menetletud v alitud

täiendamisel

eelistatud taotluste

valimine hankija poolt

täiendatud taotluse esitamine

hankija poolt täiendamisele

saatmine (näit. tõendite

l isamiseks)

taotluste avamine

taotlus ei

osutunud

valituks

hankija poolt

valitud

vaidlustuse rahuldamisel

menetlusse ennistamine

taotleja kõrvaldamine,

mittekvalifitseerumine

taotluse lisamine

taotluse

esitamineparandamisele

võtmine

taotluse

tagasivõtmine


© AS Datel 2016 65/120

10.1.2 Pakkumuse seisundid

Kui hange on jaotatud osadeks, siis on seisund ka igal pakkumuses sisalduval osal.

Seisundid koostamisel, esitatud ja tagasivõetud tekivad osadele samaaegselt kui pakkumusele

tervikuna. Ka seisund menetluses tekib avamise järgselt kõigile pakkumuse osadele.

Ülejäänud seisundid võivad esineda pakkumuses sisalduvatel hanke osadel erinevalt.

Pakkumus tervikuna säilitab seisundi menetluses kuni kasvõi 1 tema osadest on jätkuvalt

menetluses. Kui kõigi osade menetlemine on lõppenud, siis saab pakkumus kõige edukama

osa seisundi.

10.2 Menetlustegevused

Järgnevates peatükkides on üksikasjalikumalt kirjeldatud taotluste ja pakkumuste

menetlemisel läbiviidavad tegevused.

stm Pakkumuse seisundid

koostamisel

esitatud tagasiv õetud

menetluses

menetlusest

eemaldatud

menetletud edukas

kohandamisel

eduka pakkumuse

valimine

pakkumuse lisamine

pakkumuse

esitamine

pakkumuse tagasivõtmine

parandamisele

võtmine

pakkumuste avamine

pakkuja kõrvaldamine,

mittekvalifitseerumine,

pakkumuse mittevastavaks

tunnistamine

vaidlustuse rahuldamisel

menetlusse ennistamine

hankija poolt

edukaks

kuulutamine

pakkumus ei

osutunud

edukaks

hankija poolt

kohandamisele

saatmine

kohandatud pakkumuse esitamine


© AS Datel 2016 66/120

10.2.1 Taotluste ja pakkumuste avamine

Avamine on registri uues lahenduses episoodiline tegevus, mis salvestub hanke töölehele

sündmusena.

Kuni avamise tähtaja kättejõudmiseni kuvab süsteem hankijale esitatud taotluste või

pakkumuste arvu. Pärast avamise aja möödumist kuvatakse hankija vastutavale ja volitatud

isikule avamise tegevusnupp, mille vajutamisel toimub avamise sündmus.

Seaduse kohaselt võiks lugeda taotlused ja pakkumused pärast avamise aja möödumist

automaatselt avatuks ilma et hankija üldse midagi peaks tegema. Süsteemi jaoks on aga

avamise hetk väga oluline, sest sel hetkel muutub nii hanke kui ka esitatud taotluste ja

pakkumuste seisund.

Teiseks on nii süsteemi kui ka osalejate jaoks oluline fikseerida, millisel hetkel hankija

tegelikult esitatud pakkumustega tegelema hakkab.

Seega, nii hanke kui ka pakkumuse üldandmetesse jääb nähtavaks esitamise tähtaeg, hanke

töölehele nii hankija kui ka ettevõtja vaates tekib avamise sündmus koos tegeliku avamise

ajahetkega.

10.2.2 Taotlejate / pakkujate kvalifitseerimine

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=osalemis_kontroll

Uues lahenduses toimub kvalifitseerimise tegevus kahes jaos. Kõigepealt toimub

kvalifitseerimine kinnituste alusel ja seejärel kvalifitseerimine tõendite alusel. Need kaks

tegevust ei pea teineteisele vahetult järgnema, vaid nende vahele jäävad tavaliselt pakkumuse

sisuga seotud tegevused.

Eelanalüüsi käigus jäi lahtiseks, kuidas on vaja seda kahekordset kvalifitseerimist realiseerida.

Prototüübis on kajastatud näide, kus esineb üks kvalifitseerimise tegevus, mille sees saab teha

nii kinnituste alusel kvalifitseerimist kui ka tõendite alusel kvalifitseerimist.

Nii näiteks on ühe tegevuse käigus võimalik kvalifitseerida mõni taotleja kinnituste alusel ja

mõni tõendite alusel. Sellisel juhul tekiks ühte liiki kvalifitseerimise protokoll, mille sees

oleks iga taotleja puhul kirjas otsus, kas ta on kvalifitseeritud kinnituste või tõendite alusel.

Selline lahendus üldist ülevaatlikkust hankes toimunu suhtes küll ei tõsta. Otse vastupidi,

tegemist on väga segadusttekitava lahendusega. Palju selgem oleks ikkagi rakendada kõigi

osalejate suhtes võrdset kohtlemist. See tähendab, et on olemas kaks eraldi kvalifitseerimise

tegevust. Kui hankija on otsustanud, et ta kõigepealt kvalifitseerib kinnituste alusel, siis teeb

seda kõigi taotlejate suhtes. Samas ei ole ka välistatud, et hankija kvalifitseerib kohe tõendite

alusel. Sellisel juhul jääb kinnituste alusel kvalifitseerimine üldse ära.

10.2.2.1 Kvalifitseerimine kinnituste alusel

Tegevust võib tinglikult nimetada ka kvalifitseerimiseks hankepassi alusel. EL direktiivides

nimetatakse hankepassiks ESPD ehk Euroopa ühtset hankedokumenti. Eesti RHS eelnõus

peetakse mõistega hankepass silmas laiemalt ka Eesti siseriiklikult kehtivaid tingimusi, mis

juriidilises mõttes küll koonduvad hankepassi tingimuste alla, kui tehniliselt ei sisaldu ESPD

standardis.

See erinevus viib mõiste „hankepass“ hägustumiseni ning kaheti mõistetavuseni.

http://tarkvara.datel.ee/proto/erhr/#p=osalemis_kontroll


© AS Datel 2016 67/120

Kuna ettevõtja esitab oma kinnitused kõigi tingimuste kohta, nii hankepassi standardvormist

tulemevate tingimuste kui ka siseriiklikult kehtivate täiendavate ja täpsustavate tingimuste

kohta, ning kuna uues lahenduses on nagunii kõik tingimused ühele ekraanivormile

koondatud ja eraldi hankepasside läbivaatamist pole vaja teha, siis on selguse huvides

otstarbekam tegevust nimetada kvalifitseerimiseks kinnituste alusel.

Parema ülevaate saamiseks hanke töölehel esineb see tegevus veel täiendavalt 2 pealkirjaga:

taotlejate kvalifitseerimine kinnituste alusel – mida kasutatakse 2-etapilistes menetlustes

pärast taotluste avamist

pakkujate kvalifitseerimine kinnituste alusel – mida kasutatakse 1-etaplistes menetlustes ja

mis võib näiteks pöördmenetluse korral ka sootuks ära jääda

Tegevuse tulemusena tekib „Kinnituste alusel kvalifitseerimise protokoll“.

Kinnituste alusel kvalifitseerimine on täiesti piisav selleks, et hankemenetlusega edasi minna

ning esitada taotlejaile pakkumuse esitamise ettepanek.

10.2.2.2 Kvalifitseerimine tõendite alusel

Sisu ja ülesehituse poolest on see tegevus sarnane eespool kirjeldatud kinnituste alusel

kvalifitseerimisega.

Ka see tegevus võib esineda 2 pealkirjaga, mida sõltuvalt hankemenetluse liigist ja hanke

seisundist süsteem kasutajale sobival hetkel pakub:

taotlejate kvalifitseerimine tõendite alusel;

pakkujate kvalifitseerimine tõendite alusel.

Lisaks võib antud tegevus esineda ka pealkirjaga

eduka pakkuja kvalifitseerimine tõendite alusel.

Viimasesse tegevusse haaratakse ainult valitud osa(de) edukad pakkujad. Teiste suhtes

tõendite alusel kvalifitseerimine üldse ei rakendu.

Alternatiiviks on ka veel

kõrvaldamise aluste kontrollimine.

Selle pealkirjaga alternatiivtegevusse haaratakse ainult kõrvaldamise alused, mida

kontrollitakse tõendite alusel.

Erinevus võrreldes kinnituste alusel kvalifitseerimise tegevusega seisneb selles, et siin on

hankijal võimalik automaatselt kontrollitavate tingimuste puhul käivitada vastavaid

automaatseid päringuid.

Teiseks tekib tegevuse tulemusena teist liiki protokoll: „Tõendite alusel kvalifitseerimise

protokoll“.

Kvalifitseerimise teema toob veelgi kaasa erinevaid nüansse. Näiteks võib hankija otsustada,

et kvalifitseerimistingimusi, so majanduslik- ja finantsseisundi ning tehnilise ja kutsealase

pädevuse kategooriates olevaid tingimusi kontrollib ta kohe tõendite alusel, aga kõrvaldamise

alused jätab hilisemaks, kuna neid tuleb enne hankelepingu sõlmimist nagunii üle kontrollida.

Mis liiki protokoll sellisel juhul tekib ja kuidas kõlab otsus selliselt kontrollitud osalejate

suhtes, jääb esialgu veel lahtiseks.

Suure tõenäosusega lahenevad need lahtised küsimused enne planeeritavat uue arenduse

algust, sest hankepass võetakse kasutusele kohe pärast uue RHS jõustumist 2016 I poolaastal.

Siis tekib ka teatav kasutuspraktika, mida on võimalik uue süsteemi arenduse käigus ära

kasutada.


© AS Datel 2016 68/120

10.2.2.3 Tingimuste kontrollimine automaatsete päringutega

Automaatsed kontrollid häälestatakse tingimuste juurde süsteemi arenduse ajal. On võimalik

realiseerida päringud ka tüüpide kaupa ning tingimuste eelhäälestamise ajal saab süsteemi

peakasutaja märkida iga tingimuse juurde, mis tüüpi automaatset päringut vastava tingimuse

kontrollimiseks kasutada saab.

Kasutaja käivitab tingimuste kontrollimise päringud siiski eraldi. Paljudel juhtudel ei ole

võimalik päringu vastusest automaatselt välja lugeda, kas tingimus on täidetud või ei. Päringu

tulemusena kuvatakse andmed – näiteks dokumentide nimekiri või tabelkujul andmed – mille

sisu uurides on inimesel võimalik teha järeldus, kas vastav osalemistingimus on täidetud või

ei.

Igast käivitatavast x-tee päringust peab süsteemi jääma ka jälg: kes käivitas, millal käivitas,

millise päringu, milliste sisenditega ning milline tulemus saadi. Seda päringute logi peab

olema võimalik süsteemis ka hiljem sirvida.

Täpsem nimekiri automaatseteks kontrollideks kasutatavatest päringutest tekib detailanalüüsi

käigus. Ka tänases süsteemis on mõned neist juba realiseeritud ja kasutusel. Eelistatumalt

võiks tingimuste kontrollimiseks rakendada selliseid päringuid, kus järeldus tingimuse

täitmise osas oleks süsteemi poolt üheselt kindlaks määratav. Siiski sõltub see vastavate

andmekogude teenusepakkujatest, kas neil on või ei ole vastavaid teenuseid eRHR jaoks välja

pakkuda.

10.2.2.4 Kvalifitseerimise tegevuse käik

Hanke vastutav või volitatud isik alustab tegevust hanke töölehel. Osadeks jagatud hanke

korral valib ka hanke osad, mille suhtes tegevus rakendub.

Süsteem haarab tegevusse kõik taotlused / pakkumused, mis neid osi puudutavad.

Kvalifitseerimine toimub pakkumuste kaupa. Pakkumuse avamisel kuvab süsteem kõik

pakkumuses sisalduvad dokumendid ning eraldi lehtedel ettevõtja andmed, kõrvaldamise

alused ja kvalifitseerimistingimused. Kui on tegemis ühispakkumusega või allhankijate

kasutamisega, siis kuvab süsteem tingimuste taga kõigi ettevõtjate kinnitused.

Kui toimub kvalifitseerimine kinnituste alusel, siis vaatab kasutaja kõik need kinnitused läbi

ning teeb otsuse iga ettevõtja kohta iga hanke osa suhtes eraldi. Mittekvalifitseerimisel või

kõrvaldamisel lisab ka tekstilise põhjenduse.

Kui toimub kvalifitseerimine kinnituste alusel, siis tutvub kasutaja lisaks ka pakkumuse

juurde üleslaetud dokumentidega ning käivitab tingimuste juures automaatseid kontrolle.

Vajaduse korral on võimalik teabevahetuse kaudu saata pakkujale teade täiendavate tõendite

lisamiseks pakkumusele.

Kui kõik pakkumused on kontrollitud, siis koostab kasutaja kvalifitseerimise protokolli.

10.2.3 Pakkumuste vastavuse kontroll

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=vastavus_kontroll

Hanke vastutav või volitatud isik alustab tegevust hanke töölehel. Osadeks jagatud hanke

korral valib ka hanke osad, mille suhtes tegevus rakendub.

http://tarkvara.datel.ee/proto/erhr/#p=vastavus_kontroll


© AS Datel 2016 69/120

Süsteem haarab tegevusse kõik pakkumused, mis neid osi puudutavad. Vastavaks

tunnistamine toimub pakkumuste kaupa. Süsteem kuvab kõik pakkumuses sisalduvad

dokumendid ning pakkumuse vastavustingimused koos kinnitustega osade kaupa.

Pakkumuse vastavuse kontrollimisel viiakse uues lahenduses sisse muudatus, et enam ei

oodata süsteemi üksikute hindajate seisukohta. Märkus. Hankijatelt laekunud tagasiside

põhjal selgus, et mõned hankijad siiski vajavad erinevate hindajate seisukohti pakkumuse

vastavuse osas. Seega tuleb ikkagi säilitada üksikute hindajate vastavustulemite sisestuse

võimalus ning koondvastavuse arvutamine üksikute hinnangute alusel. Hankija peab saama

valida, kas ta kasutab üksikuid hinnanguid või ei.

Valdaval enamikul e-menetlusega hangetest üksikuid hindajaid vastavuse kontrolli etapis ei

kasutata. Sellisel juhul on pakkumuse vastavuse kontrollimise tegevuse käik analoogne

kvalifitseerimise kontrolliga.

Kui kasutatakse üksikuid hindajaid, siis sisestab iga hindaja oma arvamuse iga

vastavustingimuse kohta, kas antud pakkumus vastab sellele tingimusele või ei. Eitava otsuse

puhul kirjutab ka põhjenduse. Pakkujate omapoolsed kinnitused sel juhul tähtsust ei oma.

Lõpliku otsuse pakkumuse vastavuse kohta langetab ikkagi hanke vastutav või volitatud isik,

kes sisestab vastavuse kontrolli tulemi koondi. Kui kasutati ka üksikuid hindajaid, siis peab

koondi sisestamisel olema nähtav erinevate hindajate arvamus koos kommentaariga iga

tingimuse osas.

Kasutaja teeb otsuse iga osa kohta eraldi. Mittevastavaks tunnistamisel lisab ka tekstilise

põhjenduse.

Kui kõik pakkumused on kontrollitud, siis koostab kasutaja vastavaks tunnistamise protokolli.

10.2.4 Pakkumuste hindamine

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=hindamise_kontroll

Pakkumuste hindamise tegevuse eelduseks on pakkumuste vastavaks tunnistamine tegevusega

seotud hanke osades. Ainult vastavaks tunnistatud pakkumused osalevad hindamises.

Hindamist teevad üheaegselt mitu hindajat ja kõik nad kannavad oma hindamistulemused

registrisse. Ka vastutav ja volitatud isikud võivad olla hindajad. Hindajad ei tohi üksteise

hindamistulemusi näha enne kui kõik hinnangud on antud.

Tegevust alustab vastutav või volitatud isik. Esimese asjana valib ta hankija meeskonna

liikmete hulgast need, kellelt ootab hinnangute andmist. Kui ta soovib ka ise olla üks

hindajatest, siis peab ta ka ennast hindajate hulka lisama. Seejärel saadab valitud hindajatele

teavituse. Valitud hindajaid on võimalik kogu tegevuse jooksul lisada ja eemaldada. Teavitust

on võimalik saata ka valikuliselt.

Tegevuse lehel on tabel, kus on näha kõik hindajad ja tegevusega seotud pakkumused ning

nende osad. Seda tabelit näevad kõik hindajad, kuid igaüks saab avada pakkumusi ainult oma

hinnangu vaates.

Vastutav või volitatud isik saab piirata, kas hindajad näevad ainult hinnatavaid kriteeriume

või kõiki. Vajadus on tingitud sellest, et mõnikord võib hankes olla pikk nimekiri maksumuse

näitajaid, mis hindaja vaadet lihtsalt koormab. Vajadus ei ole tingitud vaatamisõiguste

piiramisest.

Üksiku hinnangu andmine

Hindamine toimub pakkumuste kaupa. Esimesel lehel näeb hindaja pakkumuse üldandmeid

ning kõiki pakkumuse dokumente. Teisel lehel näeb hindamiskriteeriume hinnatavate osade

http://tarkvara.datel.ee/proto/erhr/#p=hindamise_kontroll


© AS Datel 2016 70/120

kohta. Hindaja tutvub pakkumuse dokumentidega ja omistab igale hankija poolt hinnatavale

kriteeriumile õiglased väärtuspunktid. Kui hankija on kehtestanud kriteeriumile

omistatavatele punktidele piirväärtused (min ja max punktide arvu), siis kontrollib süsteem, et

kasutaja poolt sisestatud väärtuspunktid oleks etteantud piirides. Saab olla määratud ka ainult

alam- või ülempiir. Soovitavalt kirjutab hindaja ka omapoolse põhjenduse hinnangule. Kui

kõik kriteeriumid on hinnatud, siis kinnitab oma hindamise.

Pärast kinnitamist ilmub tegevuse lehel olevasse tabelisse märge vastavate pakkumuste

juurde. See märge annab vastutavale isikule teada, et hindaja on oma hinnangu andnud.

Hindamise sisu ta ikka veel vaadata ei saa.

Koondhinnangu arvutamine

Kui kõik hindajad on oma tulemuse sisestanud ja tegevuse lehel olev tabel on märkeid täis,

siis vajutab vastutav või volitatud isik nuppu arvuta koondhinnang. Süsteem pakub kasutajale

valikut kahest võimalikust koondhinnangu arvutamise meetodist.

Meetod 1 – hindepunktide keskmine. Süsteem arvutab kõigi hindajate omistatud

hindepunktide aritmeetilise keskmise. Sellest keskmisest väärtusest saab kriteeriumi

koondhinnangu punktide väärtus. Edasi arvutab süsteem kriteeriumi hinnanguprotsendi samal

moel nagu numbriliste väärtuste puhul korrutades jooksva hindepunkti suhte parimasse

hindepunkti läbi kriteeriumi osakaaluga.

Meetod 2 – hinnanguprotsentide keskmine. Süsteem arvutab iga üksiku hindaja puhul tema

antud punktide põhjal välja vastava kriteeriumi hinnanguprotsendi. (Märkus. Siin vajab

lahendamist see küsimus, et kui hankija ei ole punktide piirväärtusi ette andnud, siis mida

lugeda parimaks? Kas selle hindaja poolt omistatud parimat väärtust või kõigi hindajate

poolt antud parimat väärtust? Õiglase tulemuse tagaks kindlasti see, kui hankija

piirväärtused, vähemalt parima väärtuse, ette annaks. Kui piirväärtusi pole ette antud ja

hindajaid on mitu, siis annab õiglasema tulemi vast meetod 1.) Hinnangu arvutamine toimub

samal moel nagu numbriliste väärtuste puhul korrutades jooksva hindepunkti suhte parimasse

hindepunkti läbi kriteeriumi osakaaluga. Seejärel leiab süsteem üksikute hindajate

hinnanguprotsentide aritmeetilise keskmise. Nendest protsentidest moodustubki

koondhinnang. Konkreetsed punktilised väärtused jäävad koondhinnangus väärtustamata.

Ükskõik kumma meetodi puhul tekib igale hinnatavale kriteeriumile (nii automaatselt kui ka

hankija poolt hinnatavale kriteeriumile) lõpuks ikkagi koondhinnang. Kõigi kriteerumite

hinnanguprotsendid summeeritakse pakkumuse (või pakkumuse osade) kaupa. Igale

pakkumusele (või pakkumuse osale) tekib üks koondhinnangu number. See koondhinnangu

number iseloomustab kui mitu protsenti ideaalist see pakkumus saavutas. Suurim võimalik

väärtus on 100%.

Pärast koondhinnangute arvutamist on kõigil meeskonnaliikmetel võimalik üksteise

hinnanguid näha.

Tegevuse lehel olevat koondhinnangute tabelit on võimalik ümberjärjestada kas pakkumuste

kaupa või hanke osade kaupa. Kui hange ei ole osadeks jaotatud, siis pole

ümberjärjestamiseks vajadust.

Ka hindajate hinnanguid on võimalik vaadelda kas pakkumuste kaupa või siis võrdlustabelina,

kus iga kriteeriumi taga on näha kõigi pakkumuste väärtus, hinnang ja põhjendus.

Kui hankes puuduvad hankija poolt hinnatavad kriteeriumid, siis tuleb koondhinnangute

arvutamine ikkagi läbi teha, et igale pakkumusele tekiks hinnangu protsent. Seda tuleb teha ka

sel juhul, kui hindamine toimus ainult 1 kriteeriumi, näiteks hinna alusel.

Enne tegevuse lõpetamist koostab kasutaja hindamise protokolli.


© AS Datel 2016 71/120

10.2.4.1 Hindamistulemuste avalikustamine pakkujaile

Hindamiste kokkuvõte kajastub hindamise protokollis. See protokoll kajastab kõigi hindajate

hinnanguid kõigi tegevuses osalenud pakkumuste kohta. Vajadusel võib moodustada eraldi

protokolli ainult koondhinnangu kohta.

Neid protokolle hankija üldjuhul pakkujaile nähtavaks ei muuda. Samas on pakkujail õigus

nõuda oma hindamistulemuste ülevaadet. Mõned hankijad avalikustavad selle info pakkujaile

vabatahtlikult, ilma küsimata.

Soovitav oleks see avalikustamine realiseerida mitte tulemdokumentide kaudu, vaid otse

registris. Vaikimisi hindamistulemused pakkujale nähtavad ei ole. Hankija saab märkida, kas

ta avalikustab koondhinnangud – sel juhul näeb iga pakkuja oma koondhinnangut, või

avalikustab ta ka üksikud hinnangud – sel juhul näeb pakkuja oma hindamistulemusi

detailselt, kuid ka sel juhul ei näe pakkuja hindajate nimesid.

Soovitav oleks see avalikuks märkimine realiseerida tegevusväliselt, sest vajadus hindamise

avalikustamiseks võib tekkida hiljem, kui tegevus on juba lõpetatud.

10.2.5 E-oksjoni korraldamine

Tegevus rakendub teatud erijuhtudel, mida on täpsemalt kirjeldatud pt 16.5.

10.2.6 Eduka pakkuja valik

Eduka pakkuja valimine võiks toimuda ka hindamise tegevuse lõpus, kuid näiteks

pöördmenetluse korral jääb hindamise ja eduka valimise vahele veel kvalifitseerimise

tegevus. Teiseks on tarvis eduka pakkuja valikut mõnikord muuta ka ilma uut hindamist

tegemata.

Tegevuse käik on lihtne ja analoogne eelmistega. Vastutav või volitatud isik alustab tegevust,

valib hanke osad. mille kohta tegevus rakendub. Süsteem kontrollib, kas kõigis pakkumustes

on kõigi nende osade hindamine tehtud, mis menetlusest eemaldatud pole. Kontroll on vajalik

selleks, kui kasutaja eksikombel üritab tegvust teha enne hindamist.

Süsteem kuvab analoogse tabeli nagu hindamise tegevuses, kus pakkumused on

hindamistulemuste alusel osade kaupa järjestatud. Vaikimisi pakub süsteem iga osa kõige

paremat edukaks, kuid kasutajal on võimalik seda valikut muuta. Iga pakkumuse juurde on

võimalik kirjutada ka põhjendus.

Kasutaja koostab pakkumuse edukaks tunnistamise protokolli ja lõpetab tegevuse.

10.2.7 Pakkumuste tagasilükkamine

Hankijal peab olema võimalus ka ilma hindamist tegemata kõik pakkumused tagasi lükata.

See võib toimuda ka pärast hindamist.

Hankija saab seda teha näiteks juhul, kui kõik esitatud pakkumused ületasid hankelepingu

eeldatavat maksumust või kui esineb mõni muu põhjus, mille hankija on alusdokumentides

ette näinud.

Üksiku pakkumuse saab hankija tagasi lükata näiteks põhjendamatult madala hinna tõttu.


© AS Datel 2016 72/120

Tegevus algab tavapärasel viisil. Hankija vastutav või volitatud isik valib hanke osad, millega

seotud pakkumusi ta soovib tagasi lükata. Osadeks jagamata hanke korral haaratakse tegvusse

kõik menetluses olevad pakkumused.

Tegevuse sees teeb kasutaja märke, kas ta soovib kõik pakkumused tagasi lükata või teeb seda

valikuliselt.

Kui lükkab tagasi kõik pakkumused, siis pakkumuste märkimist ei toimu. Süsteem laseb

sisestada ühe ühise põhjenduse pakkumuste tagasilükkamise kohta ning seejärel koostab

kasutaja kõigi pakkumuste tagasilükkamise protokolli.

Kui lükkab tagasi valikuliselt, siis märgistab kasutaja kõigepealt tagasilükatavad pakkumused.

Seejärel sisestab iga märgitud pakkumuse juurde tagasilükkamise põhjenduse. Seejärel

koostab kasutaja pakkumuse tagasilükkamise protokolli, mis onma sisu poolest erineb kõikide

pakkumuste tagasilükkamisest.

Kui tagasilükatavaid pakkumusi on mitu ja iga tagasilükatav pakkumus peab saama oma

protokolli, siis tuleb antud tegevust rakendada ükshaaval iga tagasilükatava pakkumuse kohta.

10.3 Läbirääkimiste korraldamine

Läbirääkimisi peetakse konkurentsipõhise või väljakuututamiseta läbirääkimistega

hankemenetluse, võistleva dialoogi, innovatsioonipartnerluse ja lihtmenetluse korral.

Konkurentsipõhise läbirääkimistega hankemenetluse, võistleva dialoogi või

innovatsioonipartnerluse korral sätestab hankija hanke alusdokumentides miinimumnõuded,

millele pakkumus peab vastama. Pakkuja esitab neile nõuetele vastava pakkumuse. Hankija

teeb vastavuse kontrolli ja alustab seejärel läbirääkimisi. Läbirääkimisi peetakse iga

pakkujaga eraldi.

Läbirääkimiste ajal lepitakse kokku täpsustatud nõuetes. Kokkulepped fikseeritakse

läbirääkimiste protokollis, mille hankija süsteemi üles laeb. Iga pakkujaga läbirääkimisel

tekib eraldi protokoll.

Seejärel saadab hankija läbirääkimistel osalenud pakkumuse kohandamisele. Kohandatud

pakkumustele enam vastavuse kontrolli ei tehta, vaid need liiguvad kohe hindamisele.

Väljakuulutamata läbirääkimistega hankemenetluse, lihthanke ning samuti erimenetluse

korral saab hankija ise valida, mis järjekorras ta tegevusi teeb. Nii on võimalik näiteks

kõigepealt läbirääkimisi pidada ja siis alles vastavaks tunnistada.

10.3.1 Läbirääkimiste tegevus

Läbirääkimised toimuvad üldjuhul süsteemiväliselt. Kui hankija soovib, et ka registris oleks

nähtav läbirääkimiste seis, siis võib ta juba läbirääkimiste alguses luua vastava tegevuse.

Tegevuse sees on võimalik alustada läbirääkimiste kutse või dialoogi alustamise ettepaneku

saatmist märgitud pakkujatele. Üldjuhul lepitakse läbirääkimised iga pakkujaga eraldi kokku.

Samu kutseid on võimalik saata ka otse teabevahetuse lehe kaudu.

Läbirääkimiste tulemusena moodustuvad protokollid. Need protokollid ei ole süsteemi poolt

moodustatavad, vaid luuakse väljaspool ja laetakse tulemdokumentidesse. Laadimist on

võimalik teha ka tegevuse sees.

Peale selle on hankijal võimalus ja ka kohustus saata pakkumused kohandamisele. Pakkujad

ei saa ise oma pakkumusi kohandamisele võtta, initsiatiiv peab tulema hankija poolt. Hankija


© AS Datel 2016 73/120

määrab igale pakkumusele kohandamise tähtaja – need ei pea olema ühesugused. Lisaks peab

hankija saama kohandamisele saatmisel sisestada iga pakkumuse juurde ka tekstilise

kommentaari.

Detailanalüüsi käigus võib kaaluda ka võimalust, kas oleks otstarbekas võimaldada registris

pakkumuste kohandamisele saatmist tegevusväliselt. Sellisel juhul ei oleks hankijal

läbirääkimiste tegevust otseselt üldse vaja. Teisest küljest suurendaks vastava tegevuse

kajastamine hanke töölehel ülevaatlikkust hanke menetluskäigust.

10.3.2 Pakkumuste kohandamine

Pakkumuste kohandamine on tegevus, mis ilmub ettevõtja vaates hanke töölehele hankija

initsiatiivil.

Pakkuja saab muuta numbrilisi näitajaid, pakkumuse maksumust ning samuti pakkumuse

sisulisi dokumente. Osalemistingimusi puudutavaid dokumente ta muuta ei tohiks. Süsteem

saab seda kontrollida vaid sel juhul, kui dokumentidele lisandub vastav tunnus, kas on

sisuline dokument või osalemise dokument.

Seejärel toimub kohandatud pakkumuse esitamine, mis peab kindlasti toimuma enne

kohandamise tähtaega. Pärast tähtaega enam esitada ei saa. Hankijal on võimalik

kohandamise tähtaega pikendada.

Kohandatud pakkumuse üldandmetes kuvatakse nii esitamise aeg, mis on esimese versiooni

esitamise aeg kui ka kohandamise aeg, mis on kohandatud pakkumuse esitamise aeg.

Hanke andmetes peavad olema vaadeldavad ka kohandamisele saadetud pakkumuste

esialgsed versioonid. Hankija peab saama igal ajal võrrelda, mis on kohandamise käigus

muutunud.

Kui pakkuja õigeaegselt kohandatud pakkumust ei esita, siis jääb menetlusse alles

kohandamata pakkumuse versioon ja see läheb hindamisele. Hankijal on ka võimalik teha

kohandamata jäänud pakkumuse tagasilükkamine.

10.4 Tulemdokumendid

Tulemdokumendid on taotluste ja pakkumuste menetlemise käigus tekkinud protokollid ja

otsused.

Vaikimisi on kõik tulemdokumendid nähtavad ainult hankija meeskonna liikmetele ja

erikasutaja tasandil vaatlejaile. Iga tulemdokument aga puudutab reeglina ühte või mitut

hankes osalejat.

Nii näiteks puudutab kvalifitseerimise protokoll neid hankes osalejaid, keda selles protokollis

mainitakse. Üks protokoll ei pruugi sisaldada kõiki taotluse esitanud osalejaid.

Protokollid tekivad valdavalt süsteemis automaatselt. Nende puhul on ka kohe süsteemselt

paigas ettevõtjad, kellel seda dokumenti registris potentsiaalselt võimalik vaadata on.

Reaalselt ei näe nad seda registris aga enne, kui hankija on märkinud tulemdokumendi

ettevõtjaile nähtavaks.

Tulemdokumente, eriti igasuguseid otsuseid, on hankijal võimalik ka vabalt registrisse lisada.

Tegemist on selliste dokumentidega, mis tekivad mujal kui registris, kuid puudutavad siiski

käimasolevat hanget.


© AS Datel 2016 74/120

Tänases registris on tulemdokumentide juures võimalik valida ainult 2 võimalikku väärtust:

nähtav taotlejale ja pakkujale või nähtav ainult pakkujale. Uues registris on aga olukord

keerulisem, sest iga tulemdokument võib puudutada nii taotlejaid kui pakkujaid valikuliselt.

Kui hankija soovib, et üleslaetud dokument oleks nähtav ka ettevõtjaile, siis peab ta hankes

osalejate hulgast valima need, kes seda dokumenti näha võivad.

Kui hankija märgib dokumendi ettevõtjaile nähtavaks, siis peab tal olema võimalik saata ka

teavitus selle kohta. Süsteem peab andma hankijale selget tagasisidet kas ja kellele teavitus

saadeti.

10.4.1 Süsteemi kaudu loodavad tulemdokumendid

Kõigi menetlustegevuste lõpetamisel genereerib süsteem tegevuse tulemuste kohta protokolli

või muu tulemdokumendi. Kasutajal on võimalik enne tegevuse lõpetamist loodud dokumenti

redigeerida. See tähendab, et süsteem loob dokumendi põhja koos vaikimisi andmetega ning

kasutaja saab seda soovikohaselt muuta või ümberkujundada.

Lõppkokkuvõttes salvestub dokument pdf-vormingus ning kasutajal on võimalus, kuid mitte

kohustus seda ka digitaalselt allkirjastada. Allkirjastamise korral jäävad registris nähtavaks nii

pdf-vormingus kui ka digitaalse allkirjaga vormingus failid.


© AS Datel 2016 75/120

11 TEABEVAHETUS

11.1 Üldist

Teabevahetus on eRHRi üks olulisemaid funktsionaalsuseid. Teabevahetus toimub ainult

hangete raames.

Teabevahetuseks nimetame küsimusi, ettepanekuid, kutseid, teateid mida hankija saadab

hankes osalevale ettevõtjale või vastupidi ettevõtja hankijale. Teabevahetuseks ei nimetata

registri süsteemseid teavitusi.

Üldjuhul on teabevahetuse teated kõik ametlikku laadi ja saadetud asutuselt asutusele.

Teabevahetuse teate laekumise kohta saavad vaikimisi kõik saaja asutuse hankemeeskonnas

olevad vastutavad ja volitatud isikud süsteemse teavituse. Võib arendada ka sellise

funktsionaalsuse, et teabevahetuse teate saatja valib need isikud saaja meeskonnast, kes

teavituse saavad, kui selliseks asjaks on reaalne vajadus. Esialgu tundub, et sellist vajadust

pole ja sobib, kui kõik vastutavad ja volitatud isikud teavituse saavad.

Teabevahetuse teadete saatmine on võimalik menetlustegevuste väliselt, st neid saavad

vastutavad ja volitatud isikud hanke teabevahetuse rubriigis vabalt lisada. Teatud juhtudel

võivad mõned teabevahetuse saadetised tekkida ka menetlustegevuste käigus.

Uusi saadetisi saavad teabevahetuse kaudu lisada nii hankija kui ettevõtja meeskonnas olevad

isikud. Saadetise tüüp ja lisamise õigused sõltuvad suuresti ärireeglitest, eelkõige hanke

seisundist, isiku ja temaga seotud asutuse rollist hanke juures.

11.1.1 Teabevahetuse manused

Teabevahetuse saadetise sisu tekst ei tohiks olla väga pikk. Kuna teabevahetust kasutatakse

muuhulgas ka mitmesuguste dokumentide edastamiseks, siis saadetise sisu peaks sel juhul

olema lihtsalt kaaskiri manustele. Pikemad tekstid, juhendid jms tulekski esitada failidena.

Manuseid võib ühel saadetisel olla mitu. Süsteem ei piira manuste arvu.

11.1.2 Saadetiste nähtavus

Üldjuhul on teabevahetuse saadetised nähtavad vaid saatja ja saaja asutuse meeskonnale.

Erandiks on hanget korraldavale hankijale esitatud küsimused, mis teatud juhtudel võivad olla

avalikud. Küsimusele vastamise hetkel saab hankija märkida nii küsimuse kui ka selle vastuse

avalikuks.

11.1.3 Teabevahetuse jälgimine

Nii nagu hankedokumendid, nii on ka teabevahetuse saadetised süsteemse jälgimise all.

Süsteem logib kõik saadetiste vaatamised – kasutaja nime ja vaatamise ajahetke. Seda on

tarvis selleks, et saadetise saatjal oleks ülevaade, kas ja kes on seda saadetist lugenud.

Nagu öeldud, on teabevahetuse saadetised ametlikku laadi ja võrdväärsed hanke alus- ja

tulemdokumentidega. Hanke vaidlustamise korral võib saadetiste vaatamise logi osutuda

juriidiliselt tähtsaks tõendusmaterjaliks.


© AS Datel 2016 76/120

Tänases registris on tekkinud probleem, et kuna süsteemne teavitus juba sisaldab muuhulgas

ka saadetud teabevahetuse saadetise sisu ja see süsteemne teavitus laekub kirjana kasutaja e-

posti aadressile, siis saaja esindaja ei lähe enam registrisse saadetist vaatama ning nii ei teki

registris ülevaadet, et milline teade on loetud ja milline mitte.

Selle probleemi lahendamiseks ei tohiks süsteemne teavitus sisaldada saadetise sisu teksti. Sel

juhul on kasutaja sunnitud sisenema registrisse saadetist lugema.

Kui see lahendus ei ole kasutajate jaoks mugav, siis võib alternatiivina logida teavituse saaja

kohe ka saadetisega tutvunud isikuks.

Teine probleem seisneb selles, et avalikud küsimused ja vastused on nähtavad ka

anonüümsetele kasutajatele. Seetõttu pole võimalik fikseerida nimeliselt kõiki saadetisega

tutvunud isikuid. Nii ei olegi võimalik alati kindlaks teha, kes hankes osalejate ettevõtjate

esindajatest on avalikku küsimust lugenud ja kes mitte. Kuna kõik hankes osalevate

ettevõtjate meeskonnaliikmed saavad avaliku küsimuse ja vastuse lisandumise korral

süsteemse teavituse, siis võib nad alternatiivse lahenduse korral kõik automaatselt küsimusega

tutvunud isikuteks lugeda.

Teabevahetuse jälgimise alla ei kuulu saadetise saatja asutuse meeskonnaliikmed. Näiteks kui

ettevõtja esitab hankijale küsimuse, siis võivad seda küsimust registris avada ja vaadata kõik

pakkuja meeskonna liikmed ilma et süsteem seda vaatamist logiks. Kui hankija vastab

küsimusele, siis vastuse vaatamine juba logitakse.

11.2 Saadetiste liigid

11.2.1 Küsimus ja teade hankijale

Küsimusi ja teateid hanget läbiviivale hankijale saavad esitada kõik hankes osalevate

ettevõtjate meeskonnas olevad isikud kui hanke menetlemine pole veel lõppenud, st hange ei

ole teostatud ega lõpetatud seisundis. Hanke täitmisel seisundis saavad küsimusi esitada need

pakkujad, kellega on sõlmitud lepingud.

Ühis- või keskse hanke puhul osalevad hankes ka teised hankijad. Ka neile on võimalik

teabevahetuse kaudu küsimusi esitada, kuid seda saavad teha ainult nende pakkujate

meeskonnaliikmed, kellega on sõlmitud lepingud. Keskse hanke puhul on küsimuste ja

teadete esitamine võimalik vaid neile hankijaile, kes on hankega liitunud.

Küsimuse ja teate vahe seisneb selles, et küsimusele oodatakse ka vastust, aga teatele mitte.

Hankija saab soovi korral muuta saadetise liiki. Kui hankijale on saadetud küsimusena teade,

millele tegelikult vastust ei oodata, siis saab hankija muuta saadetise tüübiks teade ja sellele

mitte vastata. Küsimuse esitaja saab selle muudatuse kohta süsteemse teavituse.

Küsimusele vastamisel saab hankija märkida selle küsimuse nähtavusulatuse. Hanke alustatud

seisundis on võimalik küsimus koos vastusega märkida avalikuks. 2-etapilistes menetlustes

pärast taotluste avamist pakkumuse esitamiseks esitatud küsimusi saab märkida nähtavaks

kõigile eelistatud pakkujatele.

Teadete ja teiste teabevahetuse saadetiste nähtavust muuta ei saa.

Ühele küsimusele saab vastata mitu korda.


© AS Datel 2016 77/120

11.2.2 Küsimus ja teade ettevõtjale

Hankija esitab küsimusi ettevõtjale peamiselt taotluste ja pakkumuste menetlemise faasis, et

täpsustada pakkumuse sisu või küsida lisadokumente.

Kui hankija soovib, et pakkuja esitaks kvalifitseerumist tõendavaid dokumente, siis on

soovitav saata pakkujale selle kohta teade, dokumendid aga laetaks üles pakkumuse juurde.

Muidugi pole ka välistatud, et hankija esitab oma soovi küsimuse vormis ja pakkuja vastab

dokumentidega. Sellisel juhul pole aga hankijal võimalik mugavalt neid taotluse või

pakkumusega siduda.

11.2.3 Läbirääkimiste kutse ja dialoogi alustamise ettepanek

Läbirääkimiste kutse saatmisega annab hankija pakkujale teada, et ta soovib alustada

läbirääkimisi ning ühtlasi ka teavitab läbirääkimiste aja, koha ja viisi. Kuigi läbirääkimisi

peetakse tavaliselt registriväliselt suulises vormis, siis pole välistatud ka registrisisene

infovahetus küsimuste-vastuste ja teadete kaudu.

Dialoogi alustamise ettepanek on samalaadne saadetis võistleva dialoogi alustamiseks.

11.2.4 Pakkumuse esitamise ettepanek

Pakkumuse esitamise ettepanek on saadetis, millega hankija teavitab tema poolt valitud ja

eelisatud pakkujaid, et pakkumuse esitamiseks vajalikud hankedokumendid on süsteemis

olemas ja kättesaadavad ning et hankija ootab pakkumuse esitamist.

2-etapilise menetluse korral on tegemist alusandmete täiendamise tegevust lõpetava

saadetisega. Saadetis lisandub automaatselt tegevuse lõpetamisel. Sellegipoolest ei ole

välistatud pakkumuse esitamise ettepaneku saatmine ka teabevahetuse kaudu.

Pakkumuse esitamise ettepanek peaks olema vaid kaaskiri süsteemi üleslaetud

hankedokumentidele. Ei ole otstarbekas edastada kogu pakkumuse dokumentatsioon saadetise

manusena. Kuigi seadus sätestab hankijat edastama pakkujale kogu pakkumust puudutav

informatsioon pakkumuse esitamise ettepanekuga, siis e-menetluste korral võib seda

tõlgendada ka nii, et hankija teavitab pakkujaid kuskohast on võimalik vastav

dokumentatsioon leida.

11.3 Teabevahetuse esitlemine

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=teabevahetus

Kõik teabevahetuse saadetised koonduvad hanke andmetes ühte nimekirja. Varasemas

lahenduses olid saadetised lahterdatud liikide kaupa: eraldi küsimused hankijale, küsimused

pakkujale ja muud teated. See tekitas palju segadust, kuna kasutajad pidid otsima oma

saadetisi mitmest kohast.

Nimekirjas kuvatakse ainult kasutajale nähtavad saadetised. Nimekirja on võimalik filtreerida

kõigi nimekirjas nähtavate andmete alusel. Soovitav oleks lahendada see funktsionaalsus ühe

filtriväljaga. Nimekirja on võimalik sorteerida kõigi veergude alusel.

Nimekirjas peavad olema visuaalselt eristuvad lugemata saadetised ja vastamata küsimused.

Kui süsteem ei hakka jälgima saadetiste loetust, vaid teavituse saamine võrdsustatakse

saadetise lugemisega, siis seda eristust pole ka vaja lisada.

http://tarkvara.datel.ee/proto/erhr/%23p=teabevahetus


© AS Datel 2016 78/120

Nimekirjast peab saama avada saadetise täisandmed ning sellele saadetise täisandmete lehele

peab olema võimalik teha ka otsepöördumisi. Kasutaja töölaual kuvatakse lingid mõnedele

viimastele saadetistele.

Nimekirja kõrval on leht, millelt saab vastavate õiguste olemasolul alustada uue saadetise

lisamist. Samas kuvatakse ka saatmata mustandid, nii et pooleli jäänud saatmised on kasutajal

pidevalt nähtaval.


© AS Datel 2016 79/120

12 LEPINGUTE HALDUS

12.1 Lepingute liigid

Võimalikud lepingute liigid on järgmised:

raamleping

hankeleping

raamlepingu alusel hankeleping

ideekonkursi tulem

kontsessioonileping

dünaamilise hankesüsteemi hankeleping

kvalifitseerimissüsteemi hankeleping

e-kataloogi tellimus

Hankeleping on ettevõtja ja hankija vahel sõlmitud rahaliste huvidega seotud leping, mille

esemeks on asjad, teenused või ehitustööd.

Raamleping on ühe või mitme ettevõtja ja ühe või mitme hankija vahel sõlmitud leping,

millega kehtestatakse lepingu kehtivusaja vältel selle alusel sõlmitavaid hankelepinguid

reguleerivad tingimused ([2] § 4 lg 16)

Kontsessioonileping on ühe või mitme ettevõtja ja ühe või mitme hankija vahel sõlmitud

hankeleping, mille puhul kontsessionääri tasu seisneb kas ainult õiguses ehitist ekspluateerida

või teenust osutada või selles õiguses koos rahalise maksega ja nõudluse või pakkumisega

seotud äririsk läheb üle kontsessionäärile ([2] § 4 lg 14)

Ideekonkursi tulemis fikseeritakse süsteemis ideekonkursi võitja ning talle määratav rahaline

auhind.

E-kataloogi tellimus on e-kataloogist laekuv tagasisde e-kataloogist sooritatud ostude ja

tellimuste kohta. (Täpsemalt loe pt 16.6.3)


© AS Datel 2016 80/120

12.2 Lepingu seisundid

12.3 Lepingute sõlmimine

12.3.1 Lepingute sõlmimine hanke pakkumuste alusel

Kui hankes on edukad pakkumused valitud, eduka pakkuja kõrvaldamise alused kontrollitud

ning vaidlustusi ei ole esitatud, siis on kätte jõudnud hetk hakata sõlmima lepinguid.

Hanke vastutav või volitatud isik lisab vastava tegevuse ja osadeks jaotatud hanke korral valib

hanke osad, millele see tegevus rakendub.

Süsteem leiab kõik edukad pakkumused, mis on nende osadega seotud. Lisatava lepingu liik

sõltub hanke korraldamise eesmärgist. Üks leping võib käia mitme hanke osa kohta, kuid ei

pea käima kõigi pakkumuses sisalduvate osade kohta korraga. Ühe pakkumuse alusel saab

sõlmida mitu lepingut, kuid iga lepingu aluseks saab olla täpselt 1 pakkumus.

Näiteks. Pakkumus A on edukaks tunnistatud hanke osade 1, 2 ja 3 osas. Hankija alustab

lepingu lisamise tegevust hanke osade 1 ja 2 osas. Tulemusena moodustub leping, mille

aluseks on pakkumus A ja mis sisaldab hanke osi 1 ja 2.

Kui on tegemist mitme pakkujaga sõlmitava raamlepinguga, siis pakub süsteem kõiki

lepinguid samasse tegevusse.

Näiteks. Pakkumused A, B ja C on edukaks tunnistatud hanke osa 1 suhtes. Hankija alustab

lepingu sõlmimist hanke osale 1. Süsteem loob 3 lepingut eraldi iga pakkumuse kohta.

stm Lepingu seisundid

sõlmimisel

pakkuja

kinnitamisel

täitmisel

teostatud

sõlmitud

hankija edastab

lepingu pakkujale

pakkuja tagastab lepingu

hankijale koos või i lma

kinnituseta

hankija l isab lepingu

hankija märgib lepingu sõlmituks

hankija lõpetab lepingu sõlmimise tegevuse

hankija märgib lepingu lõpetatuks


© AS Datel 2016 81/120

Kuna hanke osa menetlemine on alati tervikprotsess, siis ei ole võimalik seda tükeldada

mitmeks tegevuseks. Lepingute sõlmimine toimub aga vastastikkuse kokkuleppe korras ja see

kokkulepe võidakse saavutada erinevatel aegadel. Süsteem paigutab lepingud ühte tegevusse,

kuid hankija tegeleb iga lepinguga eraldi.

Hankija sisestab lepingule nimetuse, mis sisuliselt võiks olla lepingule hankija poolt

omistatud number, ning sisestab ka lepingu täitmise tähtaja. Edasi teeb hankija märke, kas

leping sõlmitakse registri vahendusel.

Lepingu maksumus tuleneb pakkumuse kogumaksumusest ning kui leping sisaldab enam kui

1 hanke osa, siis tekib maksumus igale osale eraldi. Hankijal on võimalik seda maksumust

veel redigeerida.

Kui sõlmimine toimub registriväliselt, siis sisestab hankija lepingu sõlmimise kuupäeva ja

laeb üles lepingu dokumendid sel hetkel, kui leping registriväliselt sõlmitud sai. Seejärel

kinnitab lepingu sõlmimist, mille tulemusena muutub leping registris sõlmitud seisundisse.

Kui sõlmimine toimub registri vahendusel, siis tekib sõlmimise kuupäev süsteemi poolt.

Hankija laeb üles lepingu dokumendid ning võib need soovi korral digiallkirjastada. Seda

saab ta teha ka pärast pakkujapoolset allkirjastamist.

Allkirjastamise võib jätta ka tegemata, kui hankija seda nii aktsepteerib. Süsteem digiallkirja

olemasolu ei nõua. Süsteem nõuab ainult mõlemapoolset kinnitust.

Hankija saadab lepingu pakkujale ülevaatamiseks ja kinnitamiseks. Saatmise juurde on

võimalik lisada ka kommentaar.

Ettevõtja töölehele tekib lepingu sõlmimise tegevus ning ta saab ka teavituse selle kohta, et

leping ootab kinnitamist. Pakkujal on võimalik leping digiallkirjastada või siis ilma

digiallkirjata kinnitada.

Pakkujal on ka võimalik keelduda lepingu kinnitamisest. Keeldumise korral peab ta sisestama

põhjenduse ning võib laadida lepingu juurde omapoolseid faile – lepinguversioone,

muudatusettepanekuid. Seejärel suunab lepingu hankijale tagasi.

Sellisel moel võib leping kuitahes mitu korda edasi-tagasi pendeldada.

Lõpuks peaks siiski saavutatama olukord, kus lepingu dokumentidel on pakkuja kinnitus

olemas ja kõik vanad ning mittekohased dokumendiversioonid lepingu juures tühistatud. Siis

kinnitab hankija registris lepingu sõlmimist, mille tulemusena muutub leping registris

sõlmitud seisundisse ja tekib ka sõlmimise kuupäev.

12.3.2 Lepingu sõlmimise teate esitamine

Kui ühes lepingu sõlmimise tegevuses on mitu lepingut ja mõnda neist ei sõlmitagi, siis teeb

hankija lepingu juurde vastava märke ja sisestab põhjuse. Selliselt tähistatud lepingud

aktuaalselt registrisse ei teki, kuid ei takista tegevuse lõpetamist ja teate esitamist.

Enne tegevuse lõpetamist moodustab hankija hankelepingu sõlmimise teate, mis sisaldab

andmeid kõigi tegevuses sõlmitud lepingute kohta.

Tegevuse lõpetamine märgib ühtlasi teate registrile esitatuks. Teate avaldamine, muuhulgas

ka TEDi esitamine, toimub üldises korras.

Tegevuse lõpetamisel muutub tegevusega seotud lepingute ning hanke osade seisund –

täitmisel.


© AS Datel 2016 82/120

12.3.3 Lepingu andmete muutmine

Kui tekib vajadus juba sõlmitud lepingute andmeid parandada – muuta maksumust või

tähtaega, eemaldada või asendada lepingu osapooli, siis lisab hanke vatutav või volitatud isik

lepingu muutmise tegevuse ning valib 1 või mitu parandatavat lepingut. See tegevus ei käi

enam mitte hanke osade, vaid lepingute kaupa.

Tegevuses on võimalik parandada kõiki lepingu andmeid, laadida üles muudetud dokumente,

aga muudatuste kahepoolset allkirjastamist enam ei paku.

Sõltuvalt parandatud andmetest on võimalik koostada ka hankelepingu sõlmimise teate

muudatus.

Tegevuse lõpetamisel toimub teate esitamine registrile.

12.3.4 Lepingu lõpetamine

Lepingute lõpetatuks (täidetuks) märkimine ei käi enam tegevuste kaudu, vaid märge tehakse

lepingute lehelt avatavas lepingu andmetes.

Lepingu lõpetamisel tuleb sisestada lepingu tegelik maksumus ja tegelik lõppemise kuupäev.

Saab sisestada ka kommentaari lepingu edukuse kohta. Näiteks kui leping lõpetati

ennetähtaegselt, kui esinesid leppetrahvid vms.

Andmed omavad statistilist tähtsust registri jaoks.

12.3.5 Hankelepingu akteerimiskava

Hankelepingute tasustamine toimub sageli mitmes jaos. Hankija võib soovi korral lepingute

akteerimise ajad ja summad kanda registrisse. See ainult suurendaks ülevaatlikkust lepingu

täitmise kohta.

Akteerimiskava nagu ka lepingu lõpetamise andmed ei kanta registrisse enam mitte tegevuste

kaudu, vaid otse lepingu andmetes.

Hankija lisab planeeritavad akteerimisajad, iga aja juurde planeeritava summa. Kui toimuvad

väljamaksed, siis lisanduvad tegelikud väljamakse ajad ja summad. Süsteem summeerib

tegelikud väljamaksed jooksvalt lepingu tegelikuks maksumuseks. Näiteks leping tähtajaga 1

aasta summas 100 000 eurot, mille väljamaksed tehakse kord kvartalis 25000 eurona, omab

kolmanda kvartali lõpus tegelikku maksumust 75000 eurot.

12.4 Hankimine raamlepingute alusel

Kui hange korraldati raamlepingute sõlmimiseks ja hankes on juba mõned raamlepingud

sõlmitud, siis saab alustada nende alusel hankimist. Ei ole oluline, et raamlepingud oleksid

sõlmitud kõigi hanke osade kohta. Mõne hanke osa puhul võib raamlepingute sõlmimine ka

viibida, see ei ole takistuseks sõlmitud raamlepingute alusel hankimisele.

Kui on tegemist konsolideeritud hankega (ühis- või keskse hankega), siis saavad

raamlepingute alusel hankida ka teised hankijad.

Kõigi hankesse kaasatud hankijate vastutava või volitatud isiku jaoks on nii lepingute lehel

kui ka hanke töölehel olemas nupp vms võimalus alustada hankimist raamlepingu alusel.


© AS Datel 2016 83/120

Esimese asjana palub süsteem valida, kas kasutaja soovib lisada raamlepingu alusel

hankelepingu või luua minikonkursi.

Teiseks palub valida raamlepingu, mille alusel hankimine toimub. Kui hankes on üksainus

raamleping, siis seda valikut ei pakuta. Minikonkursi puhul pakub süsteem vaikimisi kõiki

raamlepinguid, kuid kasutaja saab valikut ka muuta.

12.4.1 Raamlepingu alusel hankelepingu sõlmimine

RL alusel hankelepingu aluseks saab olla täpselt 1 raamleping. Tegevust alustanud hankija

töölehele ilmub lepingu sõlmimise tegevus, millesse on haaratud täpselt 1 leping.

Lepingu osapoolteks on tegevust alustanud hankija ja kõik raamlepingu (kaas)pakkujad. Kui

raamelping käis hanke osade kohta, siis tuleb hankelepingu maksumus sisestada samuti osade

kaupa. Iga hanke osa juures kuvab süsteem selle osa maksumuse vaba jääki ehk summat, mis

on siiani veel hankelepingutega katmata.

Muus osas sarnaneb lepingu sõlmimine eespool kirjeldatud tegevusega.

Kui hankija soovib pakkujalt saada enne lepingu sõlmimist täpsustatud pakkumist, siis üks

võimalustest on teha seda siinsamas lepingu dokumente vahetades nagu kirjeldatud eespool

lepingu sõlmimise toimingu juures. On ka võimalus eelnevalt teabevahetuse kaudu

täpsustatud pakkumust küsida.

12.4.2 Minikonkursi loomine

Minikonkursi loomisel ilmub tavaline uue hanke lisamise ekraanivorm selle vahega, et mõned

andmed on juba süsteemi poolt määratletud ja kasutaja neid muuta ei saa.

Minikonkursi puhul on hanke eesmärk alati raamlepingu alusel hankelepingu sõlmimine.

Hankelepingu liik omistatakse vaikimisi raamlepingu hankest, kasutaja saab seda muuta.

Hankemenetluse liik on alati Minikonkurss. Viidet eelteatele valida ei saa. Viide eelmisele

hankele on alati paigas, viidatakse raamlepingu hankele.

Hanke osad kopeerib süsteem raamlepingu hankest. Kui kasutaja ei valinud minikonkurssi

mitte kõiki raamlepinguid, siis kopeerib süsteem ainult valitud lepingutega seotud hanke osad.

Hankes osalejateks lisab süsteem kõik valitud raamlepingute pakkujad.

Süsteem annab hankijale valiku, kas ta soovib raamlepingu hankest minikonkursile kopeerida

hindamiskriteeriumid ja maksumuse näitajad. Osalemis- ja vastavustingimusi ei kopeerita.

12.4.3 Minikonkursi menetlemine

Minikonkursi menetluskäik sarnaneb väljakuulutamiseta läbirääkimistega menetlusega.

Pärast uue hanke lisamist on hankija töölehel pooleli minikonkursi hanke ettevalmistamise

tegevus. Kasutaja saab sisestada kõik andmed täiesti tavapärasel viisil. Osalemistingimusi ta

ei sisesta, kuid vastavustingimusi võib määrata.

Teateid hankija selle menetlusliigi puhul esitada ei saa. Ettevalmistamise tegevuse

lõpetamisel on hange kohe alustatud seisundis.

Pakkumuse esitamise kutsete saatmine, pakkumuste koostamine ja esitamine, vastavuse

kontroll, läbirääkimised, hindamine – kõik toimub samal moel nagu väljakuulutamiseta

läbirääkimistega menetluses.


© AS Datel 2016 84/120

Raamlepingu alusel hankelepingud sõlmitakse minikonkursi juures. Pärast sõlmimist

muutuvad nad nähtavaks ka raamlepingu hankes.

12.5 Lepingute leht raamlepingu hankes

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=lepingud

Uues süsteemis on vaja raamlepingu hankes kuvada ka raamlepingu alusel sõlmitud

lepinguid. See on vajalik selleks, et tekiks ülevaade nii raamlepingute kui ka raamlepingu

hanke täitmisest tervikuna.

Mitme pakkujaga raamlepingu hankes esineb see keerukus, et raamlepingute eeldatavate

maksumuste summad võivad ületada hanke mahtu, aga raamlepingute alusel hankelepingute

eeldatatavate ja muidugi ka tegelike maksumuste summad ei tohi hanke mahtu ületada. Selle

jälgmiseks tulebki arvutada need summad jooksvalt ja kuvada raamlepingu hankes välja, et

hankijail tekiks kiire ülevaade raamlepingu hanke kasutatud ja kasutamata summadest.

Peale selle kuvatakse lepingute lehel ka minikonkursid koos eeldatavate maksumustega. See

on vajalik selleks, et oleks nähtavad alustatud ja veel mitte lepinguni jõudnud minikonkursid.

Detailanalüüsi käigus on vaja jõuda seisukohale, kas on otstarbekas kuvada minikonkursside

hulgas ka lõppenud ja täitmisel konkursid või oleks parem realiseerida liikumine lõppenud

konkurssidele ainult lepingute kaudu.

http://tarkvara.datel.ee/proto/erhr/#p=lepingud


© AS Datel 2016 85/120

13 INFO OTSIMINE, TELLIMINE JA KOONDAMINE

13.1 Kasutaja töölaud

Prototüüp: http://tarkvara.datel.ee/proto/erhr/#p=toolaud

Igale sisseloginud kasutajale kuvatakse registri avalehena tema töölaud. Töölaua koosseis

sõltub kasutaja rollist, asutuste ja hangetega seotusest.

Töölaua ülesehitamisel lähtutakse eeldusest, et 90% kasutajatest on seotud täpselt 1

asutusega, aga 10% võivad omada seoseid mitme asutusega, sh nii hankijatega kui ka

ettevõtjatega.

Kuna kasutaja saab osaleda hanke hankija meeskonnas ka nii, et ta hankijaga otseselt seotud

üldse ei olegi (kontrollasutuste esindajad, välised hindajad), siis on vajalik töölaual kuvada

hankeid, tegevusi, teavitusi jt objekte sõltumatult aktiivselt valitud esindatavast asutusest.

Mõned tegevused ja viited võivad ka sõltuda aktiivselt valitud esindatavast asutusest.

Teatud ulatuses saab kasutaja ka häälestada, milliseid rubriike ta oma töölaual näha soovib.

Käesolevas eelanalüüsi dokumendis toodud visioon on näide võimalikust töölaua kavandist.

Detailanalüüsi käigus võib see muutuda või täieneda.

13.1.1 Töölaua menüü

Töölaua vasakus ääres on alammenüü linkidega tähtsamatele tegevustele, mida kasutajal

võiks vaja minna. Menüü koostamisel lähtutakse eeldusest, et tähtsamad tegevused oleks 1

hiirekliki kaugusel.

Minu andmed. Avab kasutaja andmete vormi. Sama vorm avaneb ka registri päises kasutaja

nimele klikkimisel, kuid kasutaja ei pruugi taibata seda teha. Menüüs on see link selgelt välja

toodud.

Registreeri ettevõtja. See link kuvatakse neile tavakasutajatele, kes ei ole veel mitte ühegi

asutusega seotud. Eeldatakse, et sellisel juhul on vaikimisi tegemist sellise ettevõtja

esindajaga, kes ei ole veel registrisse kantud. Lingilt avaneb uue ettevõtte registreerimise

vorm. Kui kasutaja on juba mõne asutusega seotud, siis saab ta ettevõtja registreerimist ikka

teha, kuid sel juhul ei kuvata vastavat linki otse töölaual.

Uus hange. See link kuvatakse aktiivselt hankijaga seotud kasutajale. Avab uue hanke

lisamise vormi.

13.1.2 Töölaua hanked

Töölaua keskses sektsioonis on rubriigid kasutajaga seotud hangetele. Rubriikide arv ja

koosseis on näitlik, vastavalt vajadusele võib teha rohkem või vähem rubriike, neid ümber

kujundada jne.

Rubriik „Minu hanked hankija meeskonnas“. Pealkirja järel sulgudes kuvatakse selliste

hangete arv, mille hankijapoolses meeskonnas kasutaja on ning kus tema volitused ei ole

lõppenud. Kui see arv on 0, siis seda rubriiki ega ka mitte tema alam-rubriike üldse töölaual ei

kuvata. Pealkirja järel kuvatakse link vastava nimekirja avamiseks.

http://tarkvara.datel.ee/proto/erhr/#p=toolaud


© AS Datel 2016 86/120

Pealkirja all kuvatakse mõned otselingid nimekirja värskematele hangetele. Kasutaja saab

häälestada kui mitut aktiivset hanget ta avalehel näha soovib, vaikimisi kuvatakse kuni 3

hanget. Lõppseisundis hankeid, kus menetlemine on juba lõppenud, aga kasutaja volitused

meeskonnas siiski kehtivad, avalehel ei kuvata.

Otselingi tekstis tuuakse välja järgmised andmed: hanke viitenumber, hankija nimi, hanke

nimi, kasutaja roll hankemeeskonnas. Otselingile vajutamisel avaneb vastava hanke tööleht.

Alam-rubriik „Pooleli tegevused“. Selles alam-rubriigis kuvatakse otselingid kõigile

hangetele, mille meeskonnas kasutaja on ning mille töölehel on pooleli mõni tegevus.

Vastutavale ja volitatud isikule kuvatakse mistahes pooleli tegevused, hindajale ainult

hindamisega seotud tegevused. Vaatlejale ei kuvata pooleli tegevusi. Kui mitte ühtegi

kasutajaga seotud pooleli tegevust ei ole registris, siis seda rubriiki ei kuvata üldse.

Otselingi tekstis tuuakse välja järgmised andmed: tegevuse nimi, hanke viitenumber, hankija

nimi, hanke nimi, kasutaja roll hankemeeskonnas. Otselingile vajutamisel avaneb vastava

tegevuse leht.

Alam-rubriik „Teabevahetus“. Kuvatakse neile kasutajatele, kes on hankemeeskonnas

vastutava või volitatud isiku rollis. Kuvatakse otselingid kõigile vastamata küsimustele ja

lugemata teabevahetuse teadetele.

Otselingi tekstis tuuakse välja järgmised andmed: teabevahetuse saadetise liik, hanke

viitenumber, hankija nimi, hanke nimi. Otselingile vajutamisel avaneb vastav saadetise vorm.

Saadetise otselink kaob avalehelt, kui küsimus on vastatud või kui teade on märgitud loetuks.

Rubriik „Minu ühishanked“. Pealkirja järel sulgudes kuvatakse selliste ühis- ja kesksete

hangete arv, mille kaasneva hankija meeskonnas kasutaja on ning kus tema volitused ei ole

lõppenud. Kui see arv on 0, siis seda rubriiki üldse töölaual ei kuvata. Pealkirja järel

kuvatakse link vastava nimekirja avamiseks.


häälestada kui mitut hanget ta avalehel näha soovib, vaikimisi kuvatakse kuni 3 hanget. Selles

rubriigis kuvatakse ka täitmisel seisundis hankeid, sest enamasti on ühishangete korral

tegemist raamlepingutega ning need pakuvadki huvi just eelkõige täitmisel faasis.

Rubriik „Täitmisel raamlepingud“. Rubriigis kuvatakse otselingid nendele hangetele, kus

esineb täitmisel seisundis raamlepinguid ning mille hankija meeskonnas kasutaja on vastutava

või volitatud isikuna. Ühis- ja kesksed hanked siia rubriiki ei ilmu. Kui hankes on mitu

täitmisel raamlepingut, siis ilmub link avalehele ühekordselt. Kasutaja saab häälestada

kuvatavate linkide arvu.

Rubriik „Minu hanked ettevõtja meeskonnas“. Pealkirja järel sulgudes kuvatakse selliste

hangete arv, milles osaleva ettevõtja poolses meeskonnas kasutaja on ning kus tema volitused

ei ole lõppenud. Kui see arv on 0, siis seda rubriiki ega ka mitte tema alam-rubriike üldse

töölaual ei kuvata. Pealkirja järel kuvatakse link vastava nimekirja avamiseks.


häälestada kui mitut aktiivset hanget ta avalehel näha soovib, vaikimisi kuvatakse kuni 3

hanget. Lõppseisundis hankeid, kus menetlemine on juba lõppenud, aga kasutaja volitused

meeskonnas siiski kehtivad, avalehel ei kuvata.

Otselingi tekstis tuuakse välja järgmised andmed: hanke viitenumber, hankija nimi, hanke

nimi, ettevõtja nimi, kelle meeskonnas kasutaja on. Otselingile vajutamisel avaneb vastava

hanke tööleht.

Alam-rubriik „Pooleli tegevused“. Selles alam-rubriigis kuvatakse otselingid kõigile

tegevustele, mis on ettevõtja poolt pooleli neis hangetes, mille meeskonnas kasutaja on. Kui


© AS Datel 2016 87/120

mitte ühtegi kasutajaga seotud pooleli tegevust ei ole registris, siis seda rubriiki ei kuvata

üldse.

Otselingi tekstis tuuakse välja järgmised andmed: tegevuse nimi, hanke viitenumber, hankija

nimi, hanke nimi, ettevõtja nimi, kelle meeskonnas kasutaja on. Otselingile vajutamisel

avaneb vastava tegevuse leht.

Alam-rubriik „Teabevahetus“. Kuvatakse otselingid kõigile ettevõtja poolt vastamata

küsimustele ja lugemata teabevahetuse teadetele neis hangetes, mille meeskonnas kasutaja on.

Otselingi tekstis tuuakse välja järgmised andmed: teabevahetuse saadetise liik, hanke

viitenumber, hankija nimi, hanke nimi, ettevõtja nimi, kellele saadetis on suunatud ja kelle

meeskonnas kasutaja on. Otselingile vajutamisel avaneb vastav saadetise vorm. Saadetise

otselink kaob avalehelt, kui küsimus on vastatud või kui teade on märgitud loetuks.

Rubriik „Teavitused“ kuvatakse kõigile kasutajatele alati. Pealkirja taga sulgudes on

lugemata teavituste arv. See rubriik kuvatakse ka sel juhul, kui lugemata teavitusi polegi.

Rubriigis kuvatakse kuni 10 viimast lugemata teavitust. Otselingiga on võimalik vastav

teavitus avada kohe avalehelt. Lisaks on kasutajal võimalik avada saadud teavituste nimekiri,

kus ta saab sirvida nii loetud kui lugemata teavitusi.

13.1.3 Töölaua kujundamine kasutaja poolt

Kasutajal peab olema võimalik kujundada oma töölauda. Süsteemi poolt valmistatakse ette

teatavad rubriigid. Näitlikud rubriigid on kirjeldatud eelmises peatükis. Süsteem kuvab

kasutaja töölaual neist mõned vaikimisi.

Kasutaja peab saama häälestada, milliseid rubriike ta oma töölaual näha soovib ning samuti

kuimitu linki igas rubriigis maksimaalselt kuvatakse.

13.2 Hanke otsing

Hanke otsing on registri kõige kesksem tegevus. Puudub vajadus otsida eraldi teateid,

vaidlustusi, pakkumusi jt objekte. Reaalne vajadus on otsida hankeid erinevate

tingimusrühmade alusel. Näiteks otsida hankeid, millel esineb teatud kriteeriumitele vastav

vaidlustus.

Kasutaja valib registri peamenüüst Hanked. Süsteem kuvab hangete otsingutulemuste

nimekirja. Kui kasutajal on salvestatud vaikimisi eelistusega otsingutingimused, siis kuvab

süsteem nimekirja neile tingimustele vastavatest hangetest. Kui vaikimisi otsingueelistust pole

või kui kasutaja on anonüümne, siis kuvab süsteem nimekirja tühjalt. Kasutaja saab sisestada

oma otsingutingimused või valida süsteemselt ettevalmistatud kiirotsingute hulgast mõni

tingimuskomplekt, näiteks „Viimase 10 päeva jooksul alustatud hanked“ vms.

Anonüümse kasutaja jaoks on hangete otsingukriteeriumid ühtlasi ka registri avaleheks.

13.2.1 Otsingutingimuste sisestamine

Kuna hanke otsingutingimusi on palju, siis kuvab süsteem nad eraldi lehel.


© AS Datel 2016 88/120

Otsingutingimused on jaotatud sektsioonidesse. Üldtingimuste sektsioon on pidevalt avatud

ning selles sisalduvaid tingimusvälju saab alati kasutada koos ühe valitud lisasektsiooni

tingimustega.

Vaikimisi on kõik lisatingimuste sektsioonid suletud. Kasutaja saab avada ühe soovitud

lisasektsiooni. Kui ta avab järgmise lisasektsiooni, siis sulgub automaatselt eelmine ja selles

olevad tingimused ei mõju. Selline piirang on vajalik süsteemi kiiruse säilitamise huvides.

Lisasektsioonis olevate tingimuste alusel teeb süsteem alampäringu, mille tulemusena leitud

hulk mõjub täiendava kriteeriumina üldtingimustele. Kui lubada paralleelselt mitu

alampäringut, siis tekib oht, et süsteem ei suuda online’s seda päringut mõistliku aja jooksul

teostada.

Kui vajadused taoliste päringute teostamiseks siiski eksisteerivad, siis tuleks kaaluda offline

väljavõtete teostamise mooduli arendust süsteemis.

Tingimusrühmade arv ja koosseis võib detailanalüüsi käigus täieneda või muutuda. Näitlikult

on kirjeldatud alljärgnevad rühmad.

Üldtingimused:

hanke viitenumber

hanke nimetus

hanke seisund – valik klassifikaatorist

hankija nimi – tingimuse sisestamisel kasutab süsteem autocomplete tüüpi otsingut ja

pakub kasutajale sisalduvuse alusel võimalikke nimevariante

minu hankija – see kiirvalik kuvatakse ainult aktiivselt hankija esindajana tegutsevale

kasutajale ja see väärtustab hankija nime aktiivselt valitud hankija nimega

hanke ese – valik klassifikaatorist

hankemenetluse liik – valik klassifikaatorist

hanke korraldamise – valik klassifikaatorist eesmärk

hanke alustamise aeg – kuupäevade vahemik

pakkumuse või taotluse esitamise aeg – kuupäevade vahemik

pakkumuste esitamise aeg 2-etapilise menetluse korral – kuupäevade vahemik

hange on jaotatud osadeks – jah / ei / kõik

hankija tegutseb teiste nimel – jah / ei / kõik

e-menetlus – jah / ei / kõik

rahvusvaheline – jah / ei / kõik

vastutava isiku nimi

Hanke või selle osa lisatingimused

CPV kood – valik cpv klassifikaatorist, saab kasutada ligikaudset otsingut

eeldatav maksumus – numbrite vahemik

EL rahastatud - – jah / ei / kõik

e-oksjon – jah / ei / kõik

e-kataloog – jah / ei / kõik

Ettevõtja tingimused

ettevõtja nimi – tingimuse sisestamisel kasutab süsteem autocomplete tüüpi otsingut ja

pakub kasutajale sisalduvuse alusel võimalikke nimevariante

minu ettevõtja – see kiirvalik kuvatakse ainult aktiivselt ettevõtja esindajana tegutsevale

kasutajale ja see väärtustab ettevõtja nime aktiivselt valitud ettevõtja nimega

ettevõtja seos – osaleja / taotleja või pakkuja / edukas



© AS Datel 2016 89/120

ühispakkumus – jah / ei / kõik

Lepingu tingimused

sõlmitud lepingu liik – valik cpv klassifikaatorist, saab kasutada ligikaudset otsingut

lepingu maksumus – numbrite vahemik

sõlmimise aeg – kuupäevade vahemik

lepingu sõlminud ettevõtja nimi - tingimuse sisestamisel kasutab süsteem autocomplete

tüüpi otsingut ja pakub kasutajale sisalduvuse alusel võimalikke nimevariante

Vaidlustuse tingimused

vaidlustatud – jah / ei / kõik

vaidlustuse esitaja nimi - tingimuse sisestamisel kasutab süsteem autocomplete tüüpi

otsingut ja pakub kasutajale sisalduvuse alusel võimalikke nimevariante

minu ettevõtja – see kiirvalik kuvatakse ainult aktiivselt ettevõtja esindajana tegutsevale

kasutajale ja see väärtustab vaidlustaja nime aktiivselt valitud ettevõtja nimega

vaidlustuse esitamise aeg - kuupäevade vahemik

VAKO menetlus pooleli – jah / ei / kõik

VAKO otsus – valik klassifikaatorist

VAKO otsuse staatus – valik klassifikaatorist (jõustumata / jõustunud / edasikaevatud)

VAKO otsuse number

VAKO otsuse kuupäev – kuupäevade vahemik

edasikaevatud haldus- või ringkonnakohtusse

kaebuse tulemus

edasikaevatud riigikohtusse

kaebuse tulemus

Soovitud hangete otsimiseks sisestab kasutaja otsingutingimused või muudab olemasolevaid.

Seejärel vajutab nuppu Otsi.

Süsteem kuvab tingimustele vastavate hangete nimekirja. Nimekirja kuvamisel toimub

pöördumine teisele lehele, kuid otsingutingimuste lehel säilivad kasutaja poolt tehtud valikud.

13.2.2 Otsingutingimuste salvestamine

Kasutajal on võimalik salvestada otsingutingimuste komplekte edasiseks tarbimiseks. Kui

kasutaja on sooritanud otsingu sisestatud tingimuste alusel ja veendunud, et see

tingimuskomplekt on talle edaspidigi vajalik, siis vajutab ta nuppu Salvesta tingimused.

Süsteem kuvab vahevormi, kus kasutaja sisestab otsingule sobiva pealkirja ja seejärel

lisandub salvestatud tingimuskomplekt kasutaja otsingueelistuste hulka.

Analoogseid tingimuskomplekte võib kasutajal olla mitmeid. Kõik nad kuvatakse loeteluna

otsinguvormi lehel Salvestatud otsingud. Kui kasutajal pole ühtegi tingimuskomplekti

salvestatud, siis seda lehte ei kuvata.

Kui kasutaja soovib salvestatud tingimusi rakendada, siis klikib ta loetelus soovitud

tingimuskomplekti nimel. Süsteem väärtustab tingimusväljad salvestatud väärtustega ning

sooritab kohe ka otsingu. Kasutajale kuvatakse leitud hangete nimekiri.

Salvestatud tingimuskomplekti muutmisvõimalust süsteem otseselt ei paku. Kasutaja saab

lähtuda salvestatud seisust, muuta tingimusi ja salvestada need uue nimega. Kui kasutaja


© AS Datel 2016 90/120

üritab salvestada sama nimega, milline tal juba kasutusel on, siis pakub süsteem salvestatud

komplekti asendamist.

Salvestatud tingimuste lehel on kasutajal võimalik määrata üks komplekt vaikimisi

rakenduvaks. Sellisel juhul kuvab süsteem hangete otsingunimekirja kasutaja esimesel

pöördumisel alati selle tingimuskomplekti alusel. Vaikimisi komplekt ei pea olema määratud.

Sellisel juhul toimib vaikimisi otsing süsteemsete vaikeväärtustega.

Salvestatud tingimusi saab kasutaja loetelus ka kustutada.

13.2.3 Hangete nimekiri

Hangete nimekirjas kuvab süsteem vaikimisi hanke kõige üldisemad ja tähtsamad andmed,

mille alusel on võimalik eristada üht hanget teisest.

Need andmed võiks olla vähemalt järgmised:

viitenumber

hanke nimetus

hankija nimi

hanke ese

menetluse liik

hanke alustamise aeg

hanke seisund

Tabeli laiendamine

Hankel on tegelikult väga palju andmeid ning kasutajal võib tekkida soov kuvatavat tabelit

väljade osas laiendada.

Selle vajaduse puhul saab kasutaja tabelis kuvatavaid veergusid ükshaaval juurde tellida.

Võimalike veergude hulk lepitakse kokku süsteemi arenduse käigus.

Tabeli laiendamiseks vajutab kasutaja vastavat nuppu tabeli juures. Süsteem kuvab loetelu

võimalikest veergudest. Kasutaja valib teda huvitavad veerud. Süsteem värskendab tabeli

andmed ning toob juurde ka täiendavad veerud. Kasutajal on võimalus oma eelistus ka

püsivamalt salvestada.

Arvestama peab, et väga palju hanget iseloomustavaid andmeid on mitmese seosega ning neid

on keeruline nimekirjas üheselt välja tuua.

Näiteks võiksid olla realiseeritud järgmised lisaveerud:

hanke korraldamise eesmärk

pakkumuse või taotluse esitamise aeg

pakkumuste esitamise aeg 2-etapilise menetluse korral

hange on jaotatud osadeks

hankija tegutseb teiste nimel

e-menetlus

rahvusvaheline


hanke peamine CPV kood (kui see on üheselt teada)

EL rahastatud (kas hange tervikuna või vähemalt 1 osa)

e-oksjon (kasutusel kas hankes või mõne selle osa juures)

e-kataloog (kasutusel kas hankes või mõne selle osa juures)

hankes osalejate arv

esitatud taotluste arv

esitatud pakkumuste arv


© AS Datel 2016 91/120

kas hange on vaidlustatud

Tabeli sorteerimine

Nimekirja tabelit saab sorteerida veeru päistele klõpsamisel. Päises peab olema nähtav,

millise veeru alusel on tabel hetkel sorteeritud.

Tabelis navigeerimine

Otsinguga leitud kirjete arv peab olema tabeli juures nähtav. Kui tehnilistel põhjustel on vaja

piirata korraga rakendusse sisseloetavate kirjete arvu, siis peab ka see olema tabelis nähtav.

Tabelis kuvatavad kirjed on jaotatud lehekülgedeks. Tekkinud lehekülgede arv ning ühel lehel

korraga kuvatavate ridade arv peab samuti olema nähtav. Korraga kuvatavate ridade arvu

võiks iga kasutaja saada ise häälestada ning oma eelistusena salvestada.

Kasutaja peab saama navigeerida nimekirja lehtede vahel kas järgmisele-eelmisele

liikumisega või konkreetset lehekülje numbrit ette andes.

Kiirotsing

Nimekirja tabeli juures võiks olla võimalus sooritada kiirotsingut hanke viitenumbri või

nimetuse alusel. Tegemist on google-laadse otsingulahtriga, kuhu kasutaja tipib oma tunnused

ning väljalt lahkumise hetkel teostab süsteem koheselt otsingu. Otsing toimub üle kogu

andmebaasi, otsingutingimuste lehel sisestud tingimused kiirotsingu korral ei mõju. Süsteem

kuvab tabelis kiirotsingu alusel leitud hanked.

Otsingutingimuste lehel sisestatud tingimuskomplekti mõju taastamiseks tühjendab kasutaja

kiirotsingu lahtri ja vajutab tabeli kohal nuppu Värskenda. Süsteem sooritab uue otsingu

samal moel nagu oleks kasutaja otsingutingimuste lehel vajutanud nuppu Otsi.

13.2.4 Hanke andmete eksport

Kõikidest hanke nimekirja tabelitest on võimalik teha andmete eksporti csv-formaadis.

Eksporditakse kõik otsingutingimustele vastavad hanked, kusjuures eksportimise hetkel on

võimalik laiendada eksporditavat andmemahtu analoogselt kuva laiendamisega.

Lisaks on võimalik juurde tellida eraldi väljavõtetena ekspordis osalevate hangete teated,

lepingud ja vaidlustused. Süsteem moodustab tellitud eksportfailid, pakib nad kokku ning

pakub kasutajale allalaadimiseks.

Andmete eksportimisel ei mõju korraga rakendusse sisseloetavate kirjete piirang. Mahukate

eksportfailide tootmise võib realiseerida ka asünkroonselt, kus kasutaja esitab

eksporditellimuse ja süsteem pakub valminud failikomplekti allalaadimiseks hiljem kasutaja

töölaualt.

13.3 Minu hanked nimekiri

Minu hanked nimekiri sarnaneb ülesehituse ja funktsionaalsuse poolest hangete

otsingutulemuste nimekirjaga, kuid ei ole siiski päris sama.

Minu hanked nimekirja poole pöördumine toimub alati kasutaja töölaualt. Seal on eraldi

valikud: minu hanked hankija meeskonnas ja minu hanked ettevõtja meeskonnas. Kasutaja

aktiivselt valitud esindatav asutus selle nimekirja tootmisel rolli ei mängi.

Süsteem leiab kõik hanked, kus kasutaja on lisatud kas hankijapoolsesse meeskonda

korraldava hankija juures või teisel juhul ettevõtja meeskonda.


© AS Datel 2016 92/120

Hanke kohta tuuakse välja samad andmed nagu hanke otsingu puhul, kuid täiendavalt

lisatakse veel kasutaja roll hankemeeskonnas ning selle rolli kehtimise tähtaeg. Ettevõtja

hangete puhul ka ettevõtja nimi.

Nimekirjas võidakse välja tuua ka need hanked, kus kasutaja volitused hankemeeskonnas on

lõppenud või siis mitte. Sobivam lahendus täpsustatakse detailanalüüsi ajal.

Tabeli laiendamine

Võib töötada samadel alustel nagu üldise otsingunimekirja laiendamine.

Tabeli sorteerimine, navigeerimine

Funktsionaalsus sama nagu üldise otsingunimekirja puhul.

Tabeli filtreerimine

Minu hanked nimekirja peab saama mõnede andmeväljade alusel filtreerida, kuid mitte

sellises ulatuses ja tingimuste alusel nagu on hanke otsingus. Filtreerida võiks saada kõigi

vaikimisi kuvatavate veergude alusel.

Kuna filtrivälju on vähe, siis võiks kuvada nad tabeli kohal. Filtri komponent võiks olla

kasutaja poolt peidetav/avatav, et tagada ekraaniruumi maksimaalne kasutus.

Klassifikaatoritest valiku puhul peab saama filtritingimuseks valida mitu väärtust. Nimekirja

juures peab olema kasutajale selgesti arusaadav, kas see on filtreeritud või kuvatakse täies

ulatuses – kui palju on nimekirjas kirjeid üldse ja kui palju filtreeritud tingimustele vastab.

Kuna filtritingimused on mugavalt tabeli kohal ja nende hulgas sisalduvad nii hanke

viitenumber kui ka hanke nimetus, siis eraldi kiirotsingu jaoks selles nimekirjas vajadus

puudub.

13.4 Lepingu otsing

Uues registris on vajalik ka lepingute otsimine hankest sõltumatuna.

Otsing realiseeritakse analoogselt hanke otsinguga ning on kättesaadav ka anonüümsele

kasutajale.

Otsingu parameetrid peavad olema vähemalt samad nagu lepingu parameetrid on hanke

otsingus, kuid tõenäoliselt siiski lisandub ka täiendavaid võimalusi.

Otsingu tulemusena kuvatakse nimekiri tingimustele vastavatest lepingutest, kuid nimekirjast

avanevas lepingu detailvaates satub kasutaja siiski vastava hanke konteksti, milles leping

sõlmiti. Lepingute vaatlemine hankest täiesti sõltumatuna ei ole vähemalt raamlepingute,

dünamilise hankesüsteemi ja kvalifitseerimissüsteemi korral eriti otstarbekas, samuti mitte

konsolideeritud hangete korral (ühis- ja kesksed hanked).

Lepingute otsimisega seondub tugevalt ka statistiliste päringute teema. Lepingute otsingu

kaudu võiks tavakasutajatel olla võimalik saada kiiret ülevaadet kulutatud summade kohta

teda huvitavas valdkonnas, mis tähendab, et lisaks lepingute nimekirja kuvamisele võiks

süsteem pakkuda ka näiteks maksumuste summa arvutust.

Detailanalüüsi käigus tuleks lepingute otsingu ja statistika teemad kindlasti kompleksselt läbi

kaaluda.

Lepingute otsing peaks olema orienteeritud pigem poolelilevatele lepingutele ja jooksvatele

muudatustele, statistilised aruanded täidetud lepingutele ja möödunud perioodide


© AS Datel 2016 93/120

kokkuvõtetele. Kuna raamlepingud on oma olemuselt pikaajalised, kestusega kuni 4 aastat,

siis põimuvad ajalugu ja jooksvad muudatused omavahel tihedalt läbi.

Ülevaade lepingute täitmise kohta on võimalik vaid sel juhul, kui kõik kulud kantakse

registrisse võimalikult vahetult pärast nende tekkimist. Kuna tänases registris ei ole võimalik

raamlepingute alt ilma minikonkursita sõlmitud hankelepinguid registrisse kanda ja tegelik

maksumus sisestatakse alles raamlepingu lõppemisel, siis jääb ülevaade pikkadest

raamlepingutest väga puudulikuks ning registri uus arendus ei saa seda puudust tagantjärele

kuidagi likvideerida. Ainus võimalus on edaspidiselt andmeid ajakohasemana hoida.

13.5 Infotellimused

Infotellimused on eRHR registri teenus, mis saadab kasutaja e-postile teavitusi, kui registrisse

lisandub kasutaja huvidele vastav hange.

Vastav teenus on ka tänases registris olemas, kuid see on kasutajate jaoks raskesti leitav ja

arusaamatu. Seda kasutatakse vähe, kuid vajadus tundub kasutajatelt laekunud ettepanekute

põhjal olevat suur. Tänane lahendus ei toeta infotellimuse tingimuste kompleksset valimist,

mis tähendab, et kasutaja, kes soovib saada teavitusi mitme erineva tingimuse kombinatsiooni

kohta, peab iga kord vormistama eraldi infotellimuse.

Infotellimuse funktsionaalsuse kerge leitavus ja kasutusmugavuse parandamine tagab teenuse

kasutajate kasvu. Rahulolu-uuringu kohaselt kasutab täna tervelt 51 % pakkujatest ja 39 %

hankijatest registrit just info otsimiseks. Seega vähendab infotellimuse kättesaadavus registri

koormust, parandab kasutusmugavust ning vähendab pakkujate ja hankijate igapäevast

ajakulu.

13.5.1 Infotellimuse teenuse leitavus

Teave selle kohta, et süsteem infotellimuste teenust pakub, peab olema nähtav ka

anonüümsele kasutajale. Infotellimusi sooritada saavad siiski ainult registreeritud kasutajad.

Üks võimalus kuidas infotellimuste teenust paremini eksponeerida on see, et hangete

otsinguvormile lisada infotellimuste leht.

Kui otsinguvormi avab anonüümne kasutaja, siis kuvab süsteem infotellimuse lehel selgitava

teksti, mida infotellimuse teenus tähendab ja et teenuse kasutamiseks peab olema süsteemi

sisseloginud.

Kui otsinguvormi avab sisseloginud kasutaja siis kuvab süsteem infotellimuste lehel kasutaja

infotellimused. Täpselt sama leht on avatav ka otselingiga kasutaja töölaualt.

13.5.2 Minu infotellimused

Kui kasutaja on juba süsteemi lisanud 1 või mitu infotellimust, siis kuvab süsteem nende

tellimuste andmed. Iga tellimuse juures on nähtav kas ja kui kaua tellimus kehtib, millisele e-

postile tellimus saadetakse ja millistel tingimustel tellimus on tehtud. Salvestatud tellimusi

saab muuta, pikendada ja kustutada.

On ka võimalik lisada uusi tellimusi. Üldjuhul peaks igale kasutajale piisama 1

infotellimusest. Siiski on võimalik, et kasutaja soovib näiteks eeltetamisi saada ühtedel


© AS Datel 2016 94/120

tingimustel, alustamisi teistel ja lepingu sõlmimisi kolmandatel. Sellisel juhul on tarvis

vormistada mitu infotellimust.

Teiseks kuvab süsteem ka loetelu infotellimuse täitmise kohta väljasaadetud teadetest. Kui

tellimuse e-postile saatmisel esines viga (näiteks postkast täis või vale aadress vms), siis on

tabelis nähtav nii teate sisu kui ka saatmisel tekkinud viga. Põhimõte seisneb selles, et

kasutaja joks peab olema lisaks ka registrist kättesaadav kogu info, mida ta on tellinud oma

postkasti.

Kuna teadete loetelu võib olla väga pikk, siis on kasutajal tarvis ka teatavaid

filtreerimisvõimalusi. Näiteks, kuva viimased 30 teadet vms.

Juhul, kui kasutaja ei ole sisestanud veel mitte ühtegi infotellimust, siis kuvab süsteem lehel

uue infotellimuse sisestusvormi.

13.5.3 Infotellimuse lisamine

Infotellimuse lisamise vormil peab olema kasutaja jaoks arusaadavalt kirjeldatud tingimused,

mille alusel infotellimust teha saab. Tingimusi on oluliselt vähem, kui hanke otsingul, kuid

peab olema piisavalt, et kasutaja saaks piisavalt, kuid mitte liiasusega teavet.

Eelanalüüsi käigus tuvastati vajadus järgmiste parameetrite osas.

1. Sündmus, mille puhul süsteem teavituse saadab: hanke eelteatamine, alustamine või

lepingu sõlmimine. Valima peab vähemalt 1 sündmuse, kuid võib valida ka mitu.

2. Tingimused, millele vastavaid hankeid süsteem tellimuse täitmisel arvestab. Mitte ükski

tingimus ei ole kohustuslik. Kõik tingimused mõjuvad teineteist täiendavalt, nii nagu

otsingute puhul üldiselt tavaks.

Hanke eeldatav maksumus. Saab sisestada hinnavahemiku alates ja kuni. Võib ka sisestada

ainult vahemiku alguse või lõpu. Kui hankes eeldatav maksumus ei ole määratud, siis süsteem

infotellimuse täitmisel selle tingimusega ei arvesta. See tähendab, et infotellimus tagastab

hanked, kus eeldatav maksumus on kas soovitud vahemikus või pole määratud.

Hankes sisalduvad cpv-koodid. Arvesse lähevad kõik hanke cpv-koodid, nii hanke kui ka

osade juures registreeritud koodid. Cpv koodi valik lahendadakse üldisel moel, vastavalt

kasutaja soovile kas puukujulisest struktuurist või tabelist. Iga valitud koodi järel kuvatakse

ka selle nimi. Kuna cpv-koodide klassifikaator on hierarhiline (puukujuline), siis on kasutajal

võimalik määrata, kas valitud koodi arvestatakse koos alamliikidega või mitte. Reeglina peaks

kasutaja alati tahtma cpv-koodi üldisemal kujul ehk koos alaliikidega valida. Kasutaja saab

valida tingimuseks mitu koodi. Süsteem teavitab kasutajat hankest, kui hankes on mainitud

kasvõi 1 kasutaja poolt määratud cpv-kood.

Hanget korraldavad hankijad. Kasutajal on võimalik määrata nimeliselt hankijad, kelle

hangetest ta huvitatud on. Hankija valimiseks on autocomplete-tüüpi sisestusväli, kuhu

kasutaja hakkab tippima hankija nime ja süsteem pakub talle loetelu registreeritud hankijatest

teksti sisalduvuse alusel. Süsteem teavitab kasutajat ainult valitud hankijate hangetest.

13.5.3.1 Infotellimuse kehtivus ja pikendamine

Kõigil infotellimustel on ka kehtivusaeg. Tähtajatud ei saa infotellimused olla seetõttu, et

kasutaja võib unustada ametikohalt lahkudes oma infotellimuse tühistada ja süsteem jääbki

saatma kirju aadressidele, mida enam ei kasutata.


© AS Datel 2016 95/120

Infotellimuse lisamisel valib kasutaja selle tellimuse kehtivuse perioodi pikkuse. Vaikimisi on

selleks näiteks 6 kuud. Infotellimuse kehtivus algab selle lisamise hetkest ning lõpp on valitud

perioodi lõpuaeg.

Infotellimuse kehtivust on võimalik pikendada. Pikendamine toimub valitud perioodi kaupa.

Pikendamisel omistab süüsteem infotellimuse kehtivuse lõpuks jooksvast kuupäevast perioodi

pikkuse võrra edasiarvutatud kuupäeva.

Kasutaja saab infotellimust pikendada ühe nupuvajutusega infotellimuse andmetes.

Kõiki infotellimuse andmeid, sh ka kehtivuse perioodi pikkust on kasutajal võimalik muuta.

13.5.4 Infotellimuse täitmine

Infotellimuste täitmine toimub perioodiliselt käivituva automaatse protsessi poolt. Soovitavalt

käivitub igal ööl pärast kuupäeva vahetumist.

Protsess leiab möödunud päeval eelteatatud, alustatud ja lepinguni jõudnud hanked. Seejärel

kontrollib iga infotellimuse kaupa, kas nende hulgas leidub vatavat tellimust puudutavaid

hankeid. Osadeks jaotatud hangete puhul tuleb kontrollida ka hanke osi.

Süsteem moodustab e-kirja milles sisaldub info kõigi tellimust rahuldavate hangete kohta. Iga

hanke kohta mainitakse vähemalt hanke viitenumber, nimetus, hankija nimi, infotellimuse

sündmus ja kuupäev, otselink hankele.

Saadetava e-kirja koosseis täpsustub detailanalüüsi käigus. Lisaks vajab ka täpsustamist, et

kui ühel kasutajal on mitu infotellimust, siis kas ta saab ühe e-kirja kõigi tellimuste kohta või

iga tellimuse kohta eraldi.

13.5.5 Infotellimuse kustutamine

Kui kasutaja ei soovi enam infot e-postile saada, siis kustutab ta oma infotellimuse. Tellimus

kaob kasutaja vaatest, kuid süsteemis jääb ta mittekehtivana alles.

Kustutatud infotellimuste poolt saadetud teated jäävad kasutaja vaatesse vaikimisi alles.


© AS Datel 2016 96/120

14 ELEKTROONILISED VAIDLUSTUSED

Pakkuja, taotleja või riigihankes osalemisest huvitatud ettevõtja võib vaidlustada hankija

tegevuse, kui ta leiab, et hankija on eksinud Riigihangete seaduse vastu ja see eksimus

kahjustab ettevõtja huve. Sellisel juhul esitab ettevõtja riigihangete vaidlustuskomisjonile

(VAKO) asjakohase vaidlustuse. Koos vaidlustusega võib esitada ka kahju hüvitamise

taotluse.

Riigihangete vaidlustamine toimub täna eRHRi väliselt. Vaidlustust saab esitada nii e-posti

teel kui ka paberkandjal. Vaidlustuse esitamise ja tulemuse andmed koos otsuse tekstiga

sisestab RHRi vaidlustuskomisjoni kantselei töötaja.

Eelanalüüsi käigus kaaluti võimalust, et nii vaidlustuste esitamine kui ka vaidlustuste

menetlus võiks toimuda eRHRs. Toimus kaks nõupidamist vaidlustuskomisjoni osavõtul ning

otsustati järgmist.

Vaidlustuste esitamine eRHR registri kaudu ei ole mõistlik seetõttu, et 90% juhtudel esitab

vaidlustuse advokaat, kes ei ole registri kasutaja ja kelle jaoks ei ole mugavam seda just

registri kaudu teha.

Kui siiski teha esitamine registri kaudu võimalikuks, siis tuleks see teha ka seadusega

kohustuslikuks, et esitamine ei killustuks erinevate viiside vahel. Sel juhul tuleks ka kogu

vaidlustuse menetlus realiseerida registris, kuid sel juhul esitab VAKO arendusele palju

omapoolseid nõudeid, mida ilmselt ei ole majanduslikult otstarbekas registris dubleerivalt

realiseerida, kuna see kõik on neil juba e-toimiku lahenduses olemas.

Arutades võimalikke kitsaskohti tänases vaidlustuste lahenduses jõuti järeldusele, et oluline

oleks liidestuda Kohtute Infosüsteemiga selliselt, et sealt laekuks info VAKO otsuste

edasikaebuste kohta. Tänase süsteemi puudus seisneb selles, et VAKO töötajateni ei jõua

info, et nende otsused on edasikaevatud järgmise astme kohtusse. See info jõuab küll

hankijani, kuid hankija ei ole kohustatud edasikaebuste andmeid registrisse sisestama. Selle

tulemusena ei ole registrist kättesaadav tõene info VAKO otsuste jõustumise kohta.

Edasikaebuste registreerimine, samuti edasikaebuste tulemustest teadasaamine peaks toimuma

automaatselt. Eelanalüüsi käigus jäi täpsustamata kas ja kuidas on see tehniliselt võimalik.

Teise probleemina tõstatus eRHR registrisse mittekantud hangete vaidlustamine. Alla

riigihanke piirmäära maksumustega lepinguid võib hankija ettevõtjaga sõlmida otse, ilma et

tal oleks vajadust hanget läbi viia. Kuid ka selliseid lepinguid on võimalik vaidlustada.

See tähendab, et registrisse peaks saama kanda hankega seostamata vaidlustusi. Tänase

lahenduse puhul ei ole see võimalik. Analüüsi käigus jäi lahtiseks küsimus, mis põhjusel

peaks vaidlustuste info olema registris täiuslikum kui hangete info. Kui alla riigihanke

piirmäära maksumusega sõlmitud lepingute puhul ei peeta nende registrisse kandmist

vajalikuks, siis mispärast taoliste lepingute vaidlustused peaks statistilise korrektsuse huvides

registris olema.

Kuni nende küsimuste lahendamiseni ei ole lõplikult selge vaidlustustega seotud arenduste

ulatus uues registris. Kindel on ainult, et uues lahenduses peavad vaidlustused saama

kajastatud vähemalt samas funktsionaalsuses nagu tänases registris.


© AS Datel 2016 97/120

Uues lahenduses võiks vaidlustuste menetlemine toimuda eRHR registris. Ainult vaidlustuse

esitamine eRHR registri kaudu ei ole sobiv lahendus, sest kui menetlemine jääks jätkuvalt

registriväliseks, siis suurendaks registri kaudu vaidlustuste esitamine VAKO liikmete

töökoormust ja hajutaks ülevaatlikkust. Jätkuvalt on tarvis aktsepteerida ka mitte registri

kaudu esitatud vaidlustusi ning neid sisestavad registrisse VAKO töötajad.

14.1 Vaidlustuste kuvamine hanke juures

Kuna ühe hanke kohta on vaidlustusi tavaliselt ikkagi vähe, enamasti 1 – 2, väga harvadel

juhtudel enam kui 3, siis on otstarbekas kuvada hanke andmetes vaidlustused mitte tabelina,

vaid andmekomponendina. Ilma detailandmeid avamata võiks olla nähtav järgmine info

vaidlustuse kohta:

vaidlustuse esitaja ja tema kontaktisik

vaidlustuse esitamise aeg

vaidlustuse objekt

komisjoni otsus menetlusse võtmise kohta

menetluse tüüp

läbivaatamise tulemus

otsuse number ja kuupäev

vaidlustuse seisund

Lisaks kuvatakse hanke üldandmetes

märge, et hange on vaidlustatud, kui hanke juurde on registreeritud lõpetamata vaidlustus

või kui VAKO otsus pole veel jõustunud või on edasikaevatud

märge, et hankijal on luba sõlmida hankeleping vaidlustuse ajal, juhul kui hange on

vaidlustatud ja VAKO on taolise otsuse teinud

märge, et hankemenetlus on peatunud, juhul kui VAKO on taolise otsuse teinud, ning

peatumise algus- ja lõpp-tähtaeg

14.2 Vaidlustuste otsing

Avalikule kasutajale eraldi vaidlustuse otsingut uues eRHRis enam ei tule. On võimalik otsida

hankeid vaidlustuse andmete alusel. Selleks on hanke otsingus olemas vastav tingimuste

rühm.

VAKO liikmete jaoks on aga vaidlustuse otsing olemas. VAKO liikme rolliga kasutaja

töölaual on link vaidlustuste nimekirja avamiseks. Nimekirjas kuvatakse kõik süsteemis

registreeritud vaidlustused ning nimekirja on võimalik filtreerida (nimekirjast otsinguid teha).

Vaikimisi kuvatakse kõik pooleliolevad vaidlustused.

Need pooleliolevad vaidlustused, millega VAKO liige otseselt seotud on, tuuakse töölaual

otselingi kaudu välja.

Lisaks VAKO liikmetele võib otselinke pooleli vaidlustustele kuvada ka menetluse

asjaosaliste töölaual. Vaidlustuse osalised on hankija, vaidlustuse esitaja ja teised

vaidlustusest puudutatud ettevõtjad.


© AS Datel 2016 98/120

15 ÄRILOOGIKAT TOETAVAD TEAVITUSED

Teavituste eesmärk on informeerida eRHR süsteemi kasutajaid registris toimuvaist

sündmustest. Teatud kokkulepitud sündmuse korral genereerib süsteem uue teavituse.

Teavituste saatjaks on alati süsteem, ka sel juhul kui sündmuse initsiaatoriks on teine

kasutaja.

Teavituse adressaat on alati üks konkreetne kasutaja. Kui sama teavituse peab saama mitu

adressaati, siis dubleerib süsteem sama teate iga adressaadi jaoks. Selles osas on erinevus

võrreldes tänase regsitriga, sest täna saab ka asutustele teavitusi saata. Sellisel juhul märgib

teavituse loetuks esimene selle asutusega seotud kasutaja ja teisteni see teadmine tihti ei

jõuagi. Asutuste teavitamine oli tingitud sellest, et ettevõtjatel ei olnud hanke juures

meeskonda ja ei tahetud dubleerida ühte teavitust kõigile asutusega seotud kasutajaile. Nüüd

see mure laheneb, sest nüüd on teada konkreetsete isikute ring, kes hankega tegeleb.

Teavitus salvestub süsteemis ja saadetakse lisaks ka adressaadi e-postile.

Uues lahenduses täieneb teavituste häälestusvõimalus. Teavitustele lisandub prioriteedi

tunnus. Tähtsaid teavitusi ei saa kasutaja enda jaoks ära keelata, aga vähemolulisi saab.

Vaikimisi saadab süsteem kõik teavitused alati kasutaja e-postile. Vähemolulise teate puhul

saab kasutaja märkida, et ei soovi seda teavitust enda e-postile. Sellisel juhul jääb e-kiri

saatmata aga süsteemi tekib teavitus ikkagi.

Teavitused ja teabevahetus on kaks erinevat asja ning neid ei tohiks omavahel segamini ajada.

Teabevahetuse saadetised on ühelt asutuselt teisele saadetavad ametlikud sõnumid. Neid

sõnumeid otse e-posti aadressile ei edastata. Kui ühe asutuse kasutaja lisab teabevahetuse

saadetise, siis saavad teise (saaja) asutuse hankemeeskonna liikmed selle kohta teavituse. See

teavitus võib, kuid ei pea sisaldama teabevahetuse saadetise sisu.

15.1 Teavitamise teenus

Teavituste süsteem on juba tänases registris realiseeritud eraldi moodulina, mis pakub registri

ülejäänud osistele oma teenust.

Teavitusteenusel on konkreetsed sisendid ning tema väljundiks on 1 või mitu uut süsteemi

salvestatud teavitust, samuti uute teavituste saatmine e-kirjaga.

Teavitusteenuse väljakutsed tuleb süsteemi arenduse ajal kõikide vajalike sündmuste juurde

lisada. Süsteemi kasutajatel ei ole võimalik häälestuse kaudu uusi väljakutseid juurde

tekitada. Kui soovitakse uut teavitust, mida seni süsteem ei tootnud, siis tuleb vastava

sündmuse toimumisel või vastavatel kokkulepitud tingimustel pöörduda teavitusteenuse poole

ja selle pöördumise realiseerib süsteemi arendaja. Kui teenus ise arendust ei vaja siis uue

väljakutse lisamine on väga väike töö.

15.1.1 Teenuse sisend

Teenus on loodud põhimõttel, et kõik andmed, mida on võimalik ise andmebaasist lugeda,

neid teenuse sisendisse kaasa ei anta. Sisendis on viidad andmetele ja kogu äriloogika on juba

realiseeritud teenuse sees.


© AS Datel 2016 99/120

Täna on teenuse sisend suhteliselt jäik ja võimaldab ainult üksikuid konkreetseid

andmeviitasid kaasa anda. Arenduse käigus peaks see muutuma dünaamilisemaks, et uusi

andmeelemente oleks võimalikult mugav lisada ja seeläbi teenuse kasutust laiendada.

Teenuse väljakutsel antakse alati kaasa saadetava teavituse liik. Teavituse liigid moodustavad

süsteemis eraldiseisva klassifikaatori ning liikide juures on võimaliks samuti hulk

konstantseid parameetreid ette häälestada.

Teiseks antakse kaasa andmeviitade hulk. Just selles osas annab tänast süsteemi oluliselt

paindlikumaks muuta. Nii näiteks oleks sobiv ette valmistada andmeobjektide hulk, mida

teenus tunneb, ning sisendis anda kaasa massiiv objekt + identifikaator väärtustest.

Näide võimalikest andmeobjektidest:

HANGE – mõeldakse hanke andmeid, mida on võimalik identifikaatori alusel üheselt

baasist lugeda

HANKE_OSA – viida alusel hanke osa kohta üheselt loetavad andmed

HANKIJA – viida alusel on üheselt leitav hankija

KASUTAJA – viida alusel on võimalik leida kasutaja andmed. Teenusesse saab sisemiselt

ehitada äriloogika, et kui sisendis on kasutaja ja hankija andmed, siis loetakse kasutaja

kontaktid selle hankija juurest. Kui kasutaja ei ole hankijaga seotud, siis kasutaja juurest.

jne.

Nimekiri ei ole lõplik, vaid ainult näitlik. Täpsem lahendus selgub detailanalüüsi ajal.

Tänases lahenduses on teenuse sisendiks ka teavituse saaja. Uues lahenduses on vajadus

teavituse saajaid häälestada, seega peab saaja valiku reeglistik tulenema teavituse liigi

klassifikaatorist ja vajalikud identifikaatorid antakse kaasa teenuse sisendis.

15.1.2 Teenuse metakeel

Teavituse teema ja sisu (ühtib e-kirja teema ja sisuga) mallid häälestatakse teavituse liikide

klassifikaatoris. Need mallid on oma olemuselt lünktekstid, kus lüngad tuleb teenuse mootoril

täita andmetega.

Selleks, et teenus seda võimalikult paindlikult teha oskaks, on vaja kõigepealt kokkuleppida

lünkade süntaks. Tänases registris on lünkade süntaks selline: ${tabelinimi.andmeväljanimi}

ehk et lünka paigutatavatele andmetele viidatakse andmebaasi tabeli- ja väljanimedega.

Selle lahenduse puhul oleks tungivalt soovitav, et sisendis olev objektinimi ja tabelinimi oleks

üks ja seesama.

Teine võimalus on kasutada java objektinime ja atribuudinime. Kuigi need nimed võiksid olla

üldjuhul ühesugused, siis alati ei ole siiski võimalik nimede samasust tagada.

Ükskõik kumba valiku puhul on oluline, et registri peakasutajal, kellel on voli teavituse sisu

tekste hallata, oleks täpne ülevaade kõigist võimalikest andmeväljadest, mida teavitustes

kasutada saab, sh ka nendest, mis hetkel mitte üheski tekstis kasutusel ei ole.

Kõige jäigem lahendus oleks see, kui kõik lünganimed oleks kindlalt fikseeritud ja uue

andmevälja lisamiseks teate tekstidesse tuleks teha teenuse arendus. Parem oleks siiski jääda

kas andmebaasi nimetuste juurde (peakasutaja orienteerub andmemudeli alusel) või siis võtta

kasutusele java objektinimed (peakasutaja orienteerub java klassimudeli alusel).

Nende andmete kohta, mida pole võimalik otse andmebaasist lugeda, nagu näiteks link

hankele (moodustatakse dünaamiliselt rakenduse poolt), tuleb kokku leppida viite süntaks.


© AS Datel 2016 100/120

15.2 Teavituste liigid

Teavituse liikide klassifikaatorit haldab süsteemi peakasutaja. Teavituse liikide haldamise

kaudu on võimalik teenuse käitumist juhtida. Tegemist on konstantse klassifikaatoriga, st uute

väärtuste (liikide) lisamine pole võimalik muidu, kui ainult süsteemi arendamise teel.

Tehniliselt on klassifikaatorisse uue liigi lisamine küll väga lihtne, kuid kuna uue liigi

väljakutse tuleb nagunii programmeerida vastava sündmuse juurde, siis ei ole ainult liigi

lisamisest klassifikaatorisse kasu.

Kõige tõenäolisem vajadus uue teavituse jaoks tekib siiski mõne uue, varem ettenägemata

sündmuse kujunemisel.

Teavituse liigil on järgmised atribuudid.

Kood – liigi unikaalne tunnus, omistab süsteemi arendaja uue liigi lisamisel.

Teema – teavituse pealkiri, lühisisu või kokkuvõte. Käsitletakse ühtlasi kui teavituse liigi

nimetust. Samuti saab sellist e-kirja teema. Haldab peakasutaja.

Sisu – teavituse sisu tekst. Ühtlasi ka e-kirja sisu. Haldab peakasutaja.

Sündmus – sündmuse tekstiline kirjeldus, mille korral teavitus tekib. Infoks ja arusaadavuse

huvides. Ei hallata.

Adressaat – tänases registris teavituse saaja tekstiline kirjeldus. Infoks ja arusaadavuse

huvides. Uues lahenduses peab peakasutajal olema võimalik teavituse saajaid hallata. Sobiv

lahendus lepitakse kokku detailanalüüsis. Näited võimalike saajate kohta: hanke vastutav ja

volitatud isik, kõik hanke juurde registreerunud ettevõtjad, pakkumuse pakkujad,

teabevahetuse saadetise saaja, kõik hankija meeskonnaliikmed jne

Andmeobjektid – loetelu andmeobjektidest, mida teavitus kasutab. Detailanalüüsi käigus

selgub, kas peakasutaja saab seda häälestada või on see teavituse liigiga jäigalt seotud ning

vajaduste muutumisel on tarvis teha uus teavitus.

Lingi objekt – andmeobjekt, mille identifikaator on teavitusse paigutuva lingi parameetriks.

Link moodustub registri aadressist, mis on loetav konfiguratsioonist, ning parameetritest,

millest vähemalt 1 viitab konkreetsele lehele ja objektile, mida lehel näidatakse.

Prioriteet – uus atribuut, kõrge või madal. Kõrge prioriteediga teavitusi ei saa kasutaja enda

jaoks ära keelata, madala prioriteediga teavitusi saab. Haldab peakasutaja.

Staatus – kehtiv või kehtetu. Peakasutaja saab märkida teavituse liigi kehtetuks. Sel juhul

süsteem enam seda teavitust ei tooda. Teavituse ärakeelamiseks ei ole vaja süsteemi arendust

teha, piisab häälestamisest.

15.3 Teavituse attribuudid

Ühel teavitusel on järgmised atribuudid.

ID – teavituse üldine jrk.nr süsteeemis, tehniline ja loogiline unikaalne võti, omistab süsteem.

Liik – teavituse liigi kood klassifikaatorist

Adressaat – teavitus saab olla adresseeritud ühele järgnevast valikust

a) konkreetne isik – teavitus omab viidet süsteemi kasutajale

b) konkreetne hankija esindaja – teavitus omab viidet süsteemi kasutajale ja hankijale,

keda ta esindab

c) konkreetne pakkuja esindaja – teavitus omab viidet süsteemi kasutajale ja pakkujale,

keda ta esindab


© AS Datel 2016 101/120

Hange – kui teavitus on seotud konkreetse hankega, siis viide sellele hankele. Kasutatakse

hankega seotud teavituste eristamiseks hanke juures.

Teema – teavituse teema või pealkiri tekstina

Sisu – teavituse tekst. Sisaldab teksti sees ka linki.

Link – süsteemi siseselt teavituse juurest konreetsele teavitusega seotud lehele pöördumise

link

Koostamise aeg – teavituse koostamise ja väljastamise aeg on võrdne sündmuse toimumise

ajaga.

E-post - e-posti aadress, kuhu teavituse tekst saadeti.

Saadetud – märge e-kirja saatmise õnnestumise kohta või saatmisel tekkinud viga või märge,

et adressaat ei soovinud e-posti kaudu teavitust saada

Loetud – märge teavituse avamisest selle adressaadi poolt süsteemi sees.

Kustutatud – märge, kui teavituse saaja on märkinud teavituse enda jaoks kustutatuks.

Peakasutaja jaoks ja hanke siseselt kuvatakse jätkuvalt kõiki teavitusi, et oleks võimalik

süsteemi tööd kontrollida.

Manuseid teavitustele planeeritud ei ole. Mõnel juhul tundub küll olevat ahvatlev neid sinna

lisada. Näiteks kui teavitus saadetakse teabevahetuse saadetise laekumise kohta, siis saadetise

sisu teksti saab küll teavituse sisus kaasa anda, kuid manustega tutvumiseks peab kasutaja

siiski registrisse sisenema. Ilma manuseid avamata pole saadetisega tutvumine täielik.

Teabevahetuse manustele ei ole suuruse piirangut seatud või õigemini tuleneb see piirang

ainult registri tehnilisest võimekusest. Need manused ei pruugi olla e-kirjaga edastamiseks

sobilikud. Ei ole ka olemas ühest kindlat määrangut e-kirja manuse suurusele, see sõltub

saatja ja saaja meiliserveri võimekusest. Kui realiseerida süsteem selliselt, et teavitusega

edastataks ainult need manused, mida eeldatavasti iga meiliserver töödelda suudab, siis oleks

segadus veelgi suurem, sest siis ei teaks ükski kasutaja kunagi kindlalt, kas ta on kõik

manused läbi lugenud või ei.

Normaalne oleks teabevahetuse kohta käivas teavituse sisus edastada teave, kas saadetisel on

manuseid või mitte. Teavitus ise peab igal juhul kasutajani jõudma, see ongi tema eesmärk. Ei

ole otstarbekas seda kohalejõudmist raskendada manuste lisamisega. Manuste olemasolu võib

olla lihtsalt täiendav põhjus miks kiri adressaadini pole jõudnud.

15.4 Teavituste kuvamine registris

15.4.1 Teavituste kuvamine kasutaja töölaual

Kasutaja töölaual kuvatakse rubriik Teavitused ning selle all otselingid N viimase lugemata

teavituse juurde. Lisaks kuvatakse töölaual ka link Minu teavitused nimekirjale.

Minu teavitused nimekirjas peaks kasutaja nägema kõiki süsteemi poolt talle saadetud

teavitusi. Kuvamise optimeerimiseks võiks vaikimisi avaneda viimased 30 teavitust vms.

Lugemata teavitused peaks olema nimekirjas teistest eristuvad. Nimekirjast peab saama otsida

nii teksti kui ka kuupäeva vahemiku alusel. Nimekirjas peaks olema nähtavad teavituse teema,

sisu, koostamise aeg, e-postile saatmise tulemus.


© AS Datel 2016 102/120

Kasutajal peab olema võimalik teavitusi hulgakaupa loetuks / mitteloetuks märkida, samuti

hulgakaupa kustutada. Kustutamine tähendab, et vastav teavitus ei ilmu enam kasutaja

teavituste nimekirja, küll aga jääb ta süsteemi alles.

Teavituse sisu tekst võib olla nimekirjas korraga kuvamiseks liiga pikk. Soovitav oleks

kuvada nimekirjas ainult sisu algust. Nimekirja real klõpsides avaneb kogu teavituse sisu

tervikuna.

Üldjoontes võiks Minu teavitused nimekirja funktsionaalsus sarnaneda enamlevinud

veebipõhiste meilirakenduste funktsionaalsustega. Täiendusena võiks siiski olla võimalik

otsepöördumine nimekirja realt lingiga määratud teavituse objekti juurde ilma teavituse

detailandmeid avamata.

15.4.2 Teavituste kuvamine hanke andmetes

Iga hanke juures on vaja kuvada kõiki selle hanke kohta süsteemi poolt väljastatud teavitusi.

Link vastava nimekirja avamiseks võiks asuda hanke töölehel. Nimekiri oleks kättesaadav

hankija meeskonna liikmetele ning erikasutaja tasandil vaatlejaile ehk teisisõnu kõigile neile,

kes saavad avada hanke töölehte hankija vaates.

Nimekiri sarnaneb üldjoontes Minu teavitused nimekirjale, ainult hanke juures on kindlasti

tarvis välja tuua ka teavituse saaja ning teavitusi peab saama tõhusamalt filtreerida.

Teavituse loetuks märkimise ja kustutamise funktsionaalsust ei ole, aga teavituse

detailandmetes võiks siiski olla nähtav teavituse saaja poolse lugemise ja kustutamise info.

Teavituste kuvamine hanke juures on vajalik selleks, et hankijal oleks ülevaade kas ja millist

infot süsteem on kasutajaile edastanud selle hanke kohta.

15.4.3 Teavituste kuvamine registri peakasutajale

Ka registri peakasutajal peab olema kontroll ja ülevaade kõigist süsteemi poolt saadetud

teavitustest. Link nimekirja avamiseks võiks olla kas seadete menüüs või peakasutaja

töölaual.

Nimekirja funktsionaalsus analoogne hanke juures kuvatava nimekirjaga, kuid filtreerimise

ehk nimekirjast otsingu võimalused võiks olla veelgi suuremad.


© AS Datel 2016 103/120

16 ELEKTROONILISED TÖÖRIISTAD

16.1 Konsolideeritud hanked

16.1.1 Ühishange

Ühishankeks nimetatakse selliseid hankeid, kus üks või mitu hankijat volitavad ühte hankijat

korraldama hankemenetlust. Hanget menetleb üks hankija, teised ühishankijad selles

menetlemise protsessis otseselt ei osale.

Kui hange on edukas ja üks või mitu edukat pakkujat valitakse välja, siis on kõigil

ühishankijail võimalik sõlmida hanke raames eduka pakkujaga lepinguid.

Üldjuhul on ühishanke korral alati tegemist raamlepingu sõlmimisega. Sõlmitud

raamlepingute alusel saavad teised hankijad sõlmida hankelepinguid või korraldada

minikonkursse. Seaduses pole otseselt välistatud ühishanked ka hankelepingu sõlmimiseks,

kuid selle funktsionaalsuse praktiline vajadus on küsitav. Detailanalüüsi käigus on tarvis

jõuda kindlale seisukohale, kas eRHR peab toetama ühishankeid hankelepingu sõlmimiseks.

Ühishanke puhul on tähtis, et kõik ühishankijad peavad olema hanke alusandmetes

määratletud. Nende lisamine ja eemaldamine on võimalik ainult kuni taotluste / pakkumuste

esitamise tähtaajani. Ühishankijate andmed avaldatakse ka hanget alustavas teates.

Uuendusena saavad nüüd ka kõik ühishankijad komplekteerida oma hankemeeskonda. Nad

saavad seda teha kogu hankemenetluse vältel. Meeskonna komplekteerimine toimub

analoogselt korraldava hankija meeskonnaga, kuid selle vahega, et ühishankija vastutav ja

volitatud isik saavad kogu hanke suhtes ainult vaatlemise õigused ning lisaks lepingute

sõlmimise õiguse. Leping või minikonkurss tehakse juba konkreetse ühishankija poolt ning

seetõttu peab taolises lepingus või minikonkursis fikseerima ka hankija osapoole. Tavaliste

hangete lepingute puhul on hankijaks alati hanget läbiviiv hankija.

16.1.2 Keskne hange

Keskne hange on käesolevas registris uus mõiste. Keskne hange on muidu sarnane

ühishankega, ainult selle vahega, et hanke ettevalmistamise ajal ei määratle hanke korraldaja

kõiki asutusi, kes on hankega seotud. Asutused määratletakse ainult üldisel tasemel:

ministeerium, valitsemisala asutus vms.

Nende asutuste määratlemine käib RKOARR registri vahendusel. Mainitud asutused ei pea

isegi olema eRHR registris hankijatena registreeritud. Keskse hanke andmetes loetletakse

nende valitsusasutuste registrikoodid, kelle allasutused keskse hankega ühinema on oodatud.

Hankijad saavad ise liituda keskse hankega. Liitumise sooviavalduse hetkel kontrollib eRHR

süsteem kas liituda sooviv hankija kuulub mõne keskses hankes loetletud valitsusasutuse alla

RKOARR registri andmete põhjal. Kui kuulub, siis liitumine õnnestub.

Hiljem on tarvis perioodiliselt kontrollida, kas juba liitunud hankija kuulub jätkuvalt keskses

hankes määratletud haldusalasse. Selle kontrolli teostamise automaatika sagedus on vaja

täpsustada detailanalüüsi käigus. Igal pöördumisel seda kontrolli ilmselt mõistlik teha pole.

Keskse hankega liitunute fikseerimine hanke juures on vajalik selleks, et ka neil hankijail

oleks võimalik komplekteerida oma hankemeeskonda. See käib analoogselt ühishankijatega

ning ka õigused on samad.


© AS Datel 2016 104/120

Täiendavalt peab olema keskse hanke juures võimalik fikseerida ka ühishankijaid. See on

vajalik sel juhul, kui keskse hankega soovivad liituda ka eraõiguslikud ettevõtted. Keskse

hanke ühishankijate kohta kehtivad samad reeglid nagu ühishanke korral.

16.2 Dünaamiline hankesüsteem

Dünaamiline hankesüsteem (DHS) on elektrooniline hankelepingute sõlmimise menetlus,

millega selle kehtivusajal kvalifitseerimise tingimustele vastavad ettevõtjad võivad jooksvalt

liituda ning hankija võib liitunud taotlejatega sõlmida hankelepinguid ([2] §33, lg 1).

Uue seaduseelnõu kohaselt kohaldatakse dünaamilises hankesüsteemis piiratud

hankemenetluse sätteid, mitte enam avatud hankemenetlust, nagu varem. Hankija ei või

piirata dünaamilise hankesüsteemiga liituda soovivate taotlejate arvu.

DHS-i saab luua kõigis 3 sektoris: nii klassikalises, võrgustiku kui ka kaitse- ja julgeoleku

sektoris.

16.2.1 DHS-i loomine

Kasutaja alustab uue hanke loomist tavapärasel viisil.

Üldandmetes on kindlasti tarvis sisestada:

hanke eesmärk – dünaamilise hankesüsteemi loomine

hankemenetluse liik – piiratud hankemenetlus

hankemenetluse algus- ja lõppaeg kuupäevadena

Edasi tegutseb hankija nagu tavalise piiratud hankemenetluse korral. Sisestab

osalemistingimused, valmistab ette hankepassi, sisestab pakkumuste hindamise kriteeriumid,

komplekteerib hankemeeskonna, koostab hanketeate. Vajadusel saab dünaamilise

hankesüsteemi jagada ka osadeks. Taotluste esitamise tähtaeg on võrdne hankemenetluse

lõppajaga.

DHS-i menetlus algab hanketeate avaldamisega registris. Oodatakse taotluste esitamist.

Hanke seisund on alustatud. Kõik esitatud taotlused loetakse koheselt avatuks. Hankija

vaatab taotlused läbi kümne tööpäeva jooksul nende esitamisest arvates. Seda tähtaega võib

põhjendatud erijuhtudel pikendada 15 tööpäevani, eelkõige tulenevalt vajadusest vaadata läbi

täiendavaid dokumente või muul viisil kontrollida, kas kvalifitseerimise tingimused on

täidetud. Hankija teeb otsuse taotleja kvalifitseerimise kohta ning sama otsusega loetakse

kvalifitseerunud taotleja DHS-ga liitunuks.

Loodud DHSi raames hankeid luua saab hankija pärast hanketeates mainitud DHS algusaja

kättejõudmist. Enne seda on võimalik taotlusi kvalifitseerida ja taotlejaid DHS-ga liita. Ka

pärast DHS alguse kuupäeva on taotlejatel võimalik uusi taotlusi lisada. Seda saab teha kogu

DHS-i kehtivuse jooksul, st kuni kehtivuse lõppajani.

16.2.2 DHS-i kehtivuse muutmine

DHS-i kehtivuse ajal on hankijal õigus süsteemi kehtivusaega muuta. Kui hankija lihtsalt

pikendab või lühendab DHS-i kehtivust, mitte ei lõpeta seda ennetähtaegselt, siis esitab ta

registrile hanketeate muudatuse.


© AS Datel 2016 105/120

Dünaamiline hankesüsteem lõpeb selle kehtivusaja lõppemisega. Kui hankija soovib DHSi

lõpetada ennetähtaegselt, siis esitab ta hankelepingu sõlmimise teate ja selle teate esitamise

aeg loetakse kohe ka DHSi lõppemise ajaks.

Hankijal on õigus parandada ja täpsustada osalemistingimusi jt hanketeates olevaid andmeid

DHS-i kehtivuse ajal, kuid mitte neid oluliselt muuta. Parandusi teeb hankija täpselt samal

kombel nagu piiratud hankemenetluse puhul tavaks.

16.2.3 DHS-i raames hankimine

DHS-i raames lisatakse registrisse uusi hankeid. Analoogia toimub ka

kvalifitseerimissüsteemi raames hankimisega või raamlepingu raames minikonkursside

korraldamisega.

DHSi raames uusi hankeid luua saavad kõik korraldava hankija meeskonnas olevad

vastutavad ja volitatud isikud. Kui DHS-i olid kaasatud ka teised hankijad (ühis- või keskne

hange), siis ka nende meeskonnas vastutavad ja volitatud isikud.

Kasutaja avab DHS-i hanke ning vastavate õiguste olemasolul kuvab süsteem talle nupu uue

hanke lisamiseks DHS raames.

Selle hanke loomisel valib kasutaja need DHS hanke osad, mida ta soovib oma uude hankesse

kaasata. Osadeks jagamata hanke puhul muidugi osi ei valita. Täiendavaid osi ei ole võimalik

lisada, saab kasutada ainult DHS hankes defineeritud osi.

DHS raames hanke või tema osade üldandmed on kindlaksmääratult järgmised:

hanke eesmärk – DHS raames hankelepingu sõlmimine

hankemenetluse liik – piiratud hankemenetlus

hankelepingu liik – vastavalt DHS hankes defineeritule

viide eelmisele hankele – DHSi hanke viitenumber

DHS hankest kopeeritakse loodavasse hankesse veel ka teised üldandmed, cpv-koodid,

osalemistingimused, pakkumuse hindamise kriteeriumid, alusdokumendid. DHS raames

hange on kohe algusest peale taotlused avatud seisundis.

Lisaks kopeerib süsteem loodavasse hankesse kõik DHS hankes kvalifitseerunud taotlejad

koos taotlustega arvestades ka nende seotust hanke osadega.

DHS raames hankes ei saa hankija enam muuta hanke üldandmeid ega osalemistingimusi, st

hanketeates olevaid andmeid. Kehtivad need tingimused, mis olid hanke loomise hetkel. Kui

DHS hankes osalemistingimusi muudetakse, parandatakse või täpsustatakse , siis mõjuvad

need järgmistele hangetele, mis DHS raames luuakse, aga mitte neile, mis juba loodud on.

Sellepärast on vajalik ka tingimuste ja taotluste kopeerimine, et fikseerida osalemistingimuste

ja nende täitmise seis hanke loomise hetkel.

Hankija saab muuta ja lisada pakkumuse vastavustingimusi, pakkumuste hindamise

kriteeriume, maksumuse näitajaid. Hankija sätestab pakkumuste esitamise tähtaja.

Seejärel saadab hankija kõigile hankega seotud kvalifitseerunud taotlejatele pakkumuse

esitamise ettepaneku.

16.2.4 DHS raames esitatud pakkumuste hindamine ja lepingu sõlmimine

DHS raames esitatud pakkumuste hindamine toimub piiratud hankemenetlusele kohaselt.

Leping sõlmitakse pakkujaga, kes on esitanud vastava ja pakkumuste hindamise kriteeriumide

alusel parima pakkumuse.


© AS Datel 2016 106/120

Enne lepingu sõlmimist kontrollitakse muuhulgas ka kõrvaldamise aluseid. Kui neid peaks

ilmnema, siis kõrvaldatakse pakkuja nii DHS raames loodud hankest kui ka DHS-st tervikuna.

DHS raames hankesse lisatud lepingud ilmuvad nähtavaks ka DHS hankes.

Hankelepingu sõlmimise teate esitab registrile lepingu sõlminud hankija DHS raames loodud

hankes.

16.3 Kvalifitseerimissüsteem

Kvalifitseerimissüsteem (KS) sarnaneb olemuselt dünaamilise hankesüsteemiga, kuid on

kasutatav vaid võrgustiku sektori hankijate poolt.

16.3.1 KS-i loomine

Kasutaja alustab uue hanke loomist tavapärasel viisil.

Üldandmetes on kindlasti tarvis sisestada:

hanke eesmärk – kvalifitseerimissüsteemi loomine

hankemenetluse liik – kasutajal on võimalik valida 2-etapiliste hankemenetluste vahel:

piiratud, läbirääkimistega, võistlev dialoog või innovatsioonipartnerlus

hankemenetluse algus- ja lõppaeg kuupäevadena. Soovi korral on võimalik KS luua ka

tähtajatuna. Sel juhul teeb hankija vastava märke ja jätab alguse ja lõpu määramata.

Edasi tegutseb hankija nagu valitud hankemenetluse korral tavaks. Sisestab

osalemistingimused, valmistab ette hankepassi, sisestab pakkumuste hindamise kriteeriumid,

komplekteerib hankemeeskonna, koostab hanketeate. Kvalifitseerimissüsteemi loomise

hanget ei ole võimalik jagada osadeks erinevalt dünaamilisest hankesüsteemist, kus võisid

küll osad olla. Taotluste esitamise tähtaeg on võrdne hankemenetluse lõppajaga, kui see on

olemas.

KS-i menetlus algab hanketeate avaldamisega registris. Oodatakse taotluste esitamist. Hanke

seisund on alustatud. Kõik esitatud taotlused loetakse koheselt avatuks. Hankija teeb otsuse

taotleja kvalifitseerimise kohta ning sama otsusega loetakse kvalifitseerunud taotleja KS-ga

liitunuks.

Loodud KSi raames hankeid luua saab pärast hanketeates mainitud KS algusaja kättejõudmist.

Tähtajatu KSi korral kohe, kui süsteemiga on liitunud taotlejaid. Ettevõtjatel on võimalik

süsteemiga liituda kogu KS-i kehtivuse jooksul.

16.3.2 KS-i muutmine

KS-i kehtivuse ajal on hankijal õigus muuta nii süsteemi kehtivusaega kui ka tingimusi.

Kõigist muudatustest peab ta kindlasti teavitama kõiki hankes osalejaid. Tingimuste

muutmine võib kaasa tuua ka juba kvalifitseerunud taotlejate uuesti kvalifitseerimise

vajaduse.

Kui hankija lihtsalt pikendab või lühendab KS-i kehtivust, mitte ei lõpeta seda

ennetähtaegselt, siis esitab ta registrile hanketeate muudatuse.

Kvalifitseerimissüsteem lõpeb selle kehtivusaja lõppemisega. Kui hankija soovib KSi

lõpetada ennetähtaegselt, siis esitab ta hankelepingu sõlmimise teate ja selle teate esitamise

aeg loetakse kohe ka KSi lõppemise ajaks.


© AS Datel 2016 107/120

16.3.3 KS-i raames hankimine

KS-i raames lisatakse registrisse uusi hankeid. Analoogia toimub ka DHSi raames

hankimisega või raamlepingu raames minikonkursside korraldamisega.

KSi raames uusi hankeid luua saavad kõik korraldava hankija meeskonnas olevad vastutavad

ja volitatud isikud. Kui KS-i olid kaasatud ka teised hankijad (ühis- või keskne hange), siis ka

nende meeskonnas vastutavad ja volitatud isikud.

Kasutaja avab KS-i hanke ning vastavate õiguste olemasolul kuvab süsteem talle nupu uue

hanke lisamiseks KS raames.

KS raames hanke üldandmed on kindlaksmääratult järgmised:

hanke eesmärk – KS raames hankelepingu sõlmimine

hankemenetluse liik – vastavalt KS hankes defineeritule

hankelepingu liik – vastavalt KS hankes defineeritule

viide eelmisele hankele – KSi hanke viitenumber

KS hankest kopeeritakse loodavasse hankesse veel ka teised üldandmed, cpv-koodid,

osalemistingimused, pakkumuse hindamise kriteeriumid, alusdokumendid. KS raames hange

on kohe algusest peale taotlused avatud seisundis.

Erinevusena dünaamilisest hankesüsteemist on KS raames hankeid võimalik jagada osadeks.

Kuna KS loomise hankes osi kunagi ei defineerita ja hanketeade neid ei sisalda, siis pole

välistatud, et hankija soovi korral neid pakkumuste saamiseks lisada ei võiks.

Hankija valib KS hankes kvalifitseerunud taotlejate hulgast need, keda soovib kaasata

loodavasse hankesse, ei pea valima kõiki. Süsteem kopeerib loodavasse hankesse valitud

taotlejad koos taotlustega.

KS raames hankes on hankijal võimalik muuta hanke üldandmeid selles ulatuses, mis ei

sisaldu hanget alustavas teatevormis TV07, st ulatuses, mis ei too kaasa hanketeate muutmise

vajadust. Muuhulgas on võimalik muuta ka hankemenetluse liiki. Näiteks kui KS kuulutati

välja piiratud hankemenetlusena, aga KS raames hankes soovib hankija pidada läbirääkimisi

või võistlevat dialoogi, siis saab ta soovi korral seda rakendada.

Hankija saab muuta ja lisada pakkumuse vastavustingimusi, pakkumuste hindamise

kriteeriume, maksumuse näitajaid. Hankija sätestab pakkumuste esitamise tähtaja.

Seejärel saadab hankija valitud kvalifitseerunud taotlejatele pakkumuse esitamise ettepaneku.

16.3.4 KS raames esitatud pakkumuste hindamine ja lepingu sõlmimine

KS raames esitatud pakkumuste menetlemine toimub valitud hankemenetluse liigile vastavalt.

Leping sõlmitakse pakkujaga, kes on esitanud vastava ja pakkumuste hindamise kriteeriumide

alusel parima pakkumuse.

Enne lepingu sõlmimist kontrollitakse muuhulgas ka kõrvaldamise aluseid. Kui neid peaks

ilmnema, siis kõrvaldatakse pakkuja nii KS raames loodud hankest kui ka KS-st tervikuna.

KS raames hankesse lisatud lepingud ilmuvad nähtavaks ka KS hankes.

Hankelepingu sõlmimise teate esitab registrile lepingu sõlminud hankija KS raames loodud

hankes.


© AS Datel 2016 108/120

16.4 Erimenetlus

Erimenetlus on hankemenetluse liik, mida saab rakendada kas sotsiaal- või eriteenuste

tellimiseks või siis kontsessioonilepingu sõlmimise menetluse korral.

Erimenetlus võimaldab hankijal vabalt valida läbiviidavat menetluskorda. E-hankena

menetlemiseks peab hankija siiski täpsustama, kas ta rakendab erimenetluse puhul 1 või 2-

etapilist menetluskorda ning kas ta alustab hanget eelteatega, hanketeatega või üldse alustavat

teadet avaldamata. Viimasel juhul tuleb hankijal põhjendada oma otsust hanketeadet mitte

avaldada. Põhjendused on klassifitseeritud ja RHS poolt kindlaksmääratud. Lisaks

klassifitseeritud põhjendusele tuleb lisada ka vabas vormis selgitus.

Erimenetlus annab hankijale vabamad tingimused hanke läbiviimiseks. Hankija ei pea

ülalmainitud hangete puhul valima erimenetlust, vaid võib valida ka avatud, piiratud,

konkurentsipõhise läbirääkimistega hankemenetluse, innovatsioonipartnerluse, võistleva

dialoogi või ideekonkursi. Sellisel juhul peab hankija kohaldama ka vastava menetlusliigiga

sätestatud menetluskorda.

16.4.1 Sotsiaal- ja eriteenused

Sotsiaal- ja eriteenuste menetlus rakendub siis, kui hankija on hanke eesmärgiks valinud kas

hankelepingu või raamlepingu sõlmimise, lepingu liigiks teenused ning teinud lisamärke

sotsiaal- ja eriteenuste kasutamise kohta.

Sellisel juhul peab hanke cpv-põhikood kuuluma vastava kategooria koodide hulka. Cpv-

lisakoodid, samuti hanke osadele määratud cpv põhi- ja lisakoodid ei pea olema valitud

sotsiaal- ja eriteenuste kategooria koodide hulgast.

Sotsiaal- ja eriteenuste hanke puhul sõltub hanget alustava teate vorm hanke sektorist:

klassikalise sektori puhul TV21, võrgustiku puhul TV22, kaitse- ja julgeoleku sektori puhul

TV17.

Hankelepingu sõlmimise teatena esitab klassikaline sektor uuesti TV21 ja võrgustik TV22,

kuid kaitse- ja julgeoleku sektori puhul TV18.

Kaitse- ja julgeoleku sektori osas on EL direktiivid esialgu veel muutmata.

16.4.2 Kontsessioon

Kontsessioonilepingu sõlmimise eesmärgiga hanget saavad luua kõigi 3 sektori hankijad: nii

avaliku, võrgustiku kui ka kaitse- ja julgeoleku sektori hankijad.

Kontsessioonilepingu sõlmimise korral saavad hankelepingu liigiks olla vaid ehitustööd või

teenused.

Kontsessioonilepingu sõlmimine võib puudutada ka sotsiaal- ja eriteenuseid.

Ka kontsessioonilepingu sõlmimiseks loodud hankes on võimalik kasutada erimenetlust. Seda

sõltumatult sellest kas kontsessiooni antakse sotsiaal- ja eriteenused või muud teenused või

ehitustööd. Kui hankija kasutab mingit muud menetlusliiki, siis peab ta rakendama ka

vastava liigiga seonduvat menetluskorda.

Muus osas ei erine kontsessioonilepingu sõlmimise menetlus teistest menetlustest.

Üldjuhul algab hange registris hanketeate avaldamisega. Tavaliselt on selleks tüüpvorm TV24

kõigi sektorite puhul. Kui on tegemist sotsiaal- ja eriteenuste kontsessiooniga, siis tüüpvorm

TV23. Teatud juhtudel on lubatud alustada menetlust ka hanketeadet avaldamata.


© AS Datel 2016 109/120

Hankelepingu sõlmimise teatena esitatakse TV25, sotsiaal- ja eriteenuste kontsessiooni puhul

uuesti tüüpvorm TV23.

16.5 E-oksjon

Elektroonilist oksjonit ehk e-oksjonit saab kasutada lihthankemenetluses, avatud

hankemenetluses, piiratud hankemenetluses või konkurentsipõhises läbirääkimistega

hankemenetluses, samuti hankelepingu sõlmimiseks dünaamilises hankesüsteemis või

minikonkursi korraldamisel raamlepingu poolteks olevate pakkujate vahel, kui hankelepingu

eset on võimalik täpselt kirjeldada. ([2] § 37 lg 2).

E-oksjon põhineb kas ühel või mitmel pakkuja poolt sisestatava numbrilise väärtusega

hindamiskriteeriumil.

16.5.1 E-oksjoni ettevalmistamine

Hankija märgib hanke üldandmetes, et tal on plaanis kasutada e-oksjonit.

Süsteem kuvab hanke ettevalmistamise tegevuses e-oksjoni parameetrite sisestamise lehe.

Parameetrite sisestamise eelduseks on, et kõik hindamiskriteeriumid peavad olema määratud.

Osadeks jaotatud hanke korral valib hankija, milliste hanke osade puhul ta e-oksjonit kasutab.

See info jõuab ka hanketeatesse. Iga hanke osa puhul korraldatakse eraldi oksjon ja ka

parameetrid on eraldi häälestatavad.

Ühe hanke osa või osadeks jaotamata hanke kohta sisestatakse jägmised parameetrid:

Oksjoni kestus – valik eelhäälestatud ajavahemike hulgast

Oksjoni lisaaeg - valik eelhäälestatud ajavahemike hulgast

Oksjonil osalevad hindamiskriteeriumid – üks või mitu numbrilist hindamiskriteeriumi. Iga

kriteeriumi kohta sisestab hankija numbri muutmise minimaalse sammu.

Süsteem moodustab e-oksjoni tingimusi kirjeldava hanke alusdokumendi. Selles dokumendis

kajastuvad ülalkirjeldatud parameetrid ning lisaks süsteemis vaikimisi eelhäälestatud osa, mis

kirjeldab e-oksjoni käiku ja tulemuste arvutamiseks kasutatavat matemaatilist valemit koos

näidetega.

16.5.2 E-oksjoni alustamine

Kui hankija on teavitanud e-oksjoni läbiviimisest, siis on tal kohustus seda ka teha, välja

arvatud juhul, kui esitatakse ainult üks vastavaks tunnistatud pakkumus.

Kõigepealt hindab hankija vastavaks tunnistatud pakkumused pakkujate poolt sisestatud

esialgsete numbriliste väärtuste alusel. Tekib pakkumuste pingerida.

Seejärel alustab hankija e-oksjoni tegevust. Seda tegevust on võimalik korraga rakendada

ainult 1 hanke osa kohta. Iga osa jaoks on vajalik eraldi tegevus ehk eraldi e-oksjon.

Selle tegevuse alguses sisestab hankija e-oksjoni algusaja. Kellaaeg peab olema määratud

minuti täpsusega. Süsteem arvutab ise oksjoni lõpuaja algsetes parameetrites valitud kestuse

alusel.

Seejärel moodustab hankija e-oksjoni kutse. See kutse salvestub teabevahtuse saadetistesse.

Kutse sisu on süsteemis eelhäälestatud. Ta sisaldab oksjoni alguse ja lõpu aega, otselinki e-


© AS Datel 2016 110/120

oksjoni lehele, kirjeldust, kuidas iga osaleja oma positsiooni näeb, kuidas saab pakkumisi

teha. Tegevuse juures peab olema nähtav, millised osalejad on kutse saanud.

E-oksjon algab hankija poolt määratud ajal automaatselt. Hankija ei pea alustamiseks rohkem

midagi tegema. Hankija peab ainult hoolitsema, et e-oksjoni alguse ja kutse saatmise ajavahe

oleks seadusega kooskõlas.

16.5.3 E-oksjoniga tutvumine

Iga oksjonil osaleja saab avada oksjoni lehe alates kutse saamise hetkest kuni parima

pakkumuse väljakuulutamiseni. Süsteemi kontekstis tähendab see, kuni pooleliolev e-oksjoni

tegevus on lõpetamata.

Poolel või tulevikus algava e-oksjoni lehele peab nii pakkujail kui hankijail olema võimalik

pöörduda otse oma töölaualt.

Peale selle saab e-oksjoni lehele pöörduda ka hanke töölehe kaudu – vastav tegevus tekib ka

ettevõtjate töölehele.

E-oksjoni lehel peab olema selgesti nähtav oksjoni alguse ja lõpu aeg ning teadmine e-oksjoni

seisudi kohta: kas oksjon pole veel alanud ja kaua on jäänud alguseni või kas e-oksjon käib ja

kaua on jäänud lõpuni või kas e-oksjon on juba lõppenud.

Pakkuja peab nägema e-oksjonil osalejate arvu, enda positsiooni pingereas ning viimase e-

oksjoni pakkumise tegemise aega. Peab nägema oksjonil osalevaid kriteeriume, iga

kriteeriumi kohta tema osakaalu, muudatuse suunda (vähim on parim, suurim on parim),

oksjoni algväärtust (parim väärtus oksjoni alghetkel), endapoolset viimast pakkumist,

muudatuse minimaalset sammu, jooksvalt parimat pakkumist. Pakkuja ei näe teisi e-oksjonil

osalejaid ega nende pakkumisi. Pakkuja ei näe ka enda poolt esitatud väärtuste alusel

arvutatud hindamistulemuse numbrilist väärtust, näeb ainult positsiooni.

Hankija näeb e-oksjonil osalevate pakkumuste pingerida. Pingereas on pakkumused sõltuvalt

kõigi kriteeriumite väärtuste alusel arvutatud hindamistulemusest. Hankija näeb ka selle

hindamistulemuse numbrilist väärtust. Iga pakkumuse kohta saab vaadata ka detailset

hinnangute jaotust kriteeriumite kaupa. Samuti on hankijal võimalik vaadata kõikide esitatud

pakkumiste ajalugu.

Kui e-oksjon käib, siis on ootuspärane, et andmed võivad lehel viibimise ajal muutuda.

Sellepärast on kasutajal vajalik e-oksjoni lehte aeg-ajalt värskendada, et veenduda kuvatavate

andmete ajakohasuses.

16.5.4 Pakkumiste tegemine e-oksjonil

Kui e-oksjon käib, siis on kõigil osalejatel võimalik teha uusi pakkumisi. E-oksjoni lehel on

osaleja jaoks vastav nupp.

Nupu vajutamisel avaneb uue pakkumise sisestamise vorm.

Kui oksjonil on enam kui 1 kriteerium, siis esitab pakkuja kõik väärtused korraga. Vähemalt 1

kriteeriumi osas peab väärtus olema muutunud vähemalt sammu võrra. Näiteks, kui oksjonil

on maksumuse kriteerium ja sammuks on määratud 100 eurot, siis peab osaleja oma viimati

esitatud maksumuse väärtust vähendama vähemalt 100 euro võrra. Võib vähendada ka

rohkem, näiteks 120 eurot. Pakutav väärtus ei pea ilmtingimata olema parem kui kogu e-

oksjoni parim väärtus. Teised oksjonil olevad kriteeriumid ei pea tingimata sisaldama uut


© AS Datel 2016 111/120

väärtust, võib esitada ka oma viimati pakutud väärtuse, kuid see peab siis täpselt võrduma, ei

tohi olla ei halvem ega natuke parem viimati esitatud väärtusest.

Kui oksjonil on pakkumuse kogumaksumus, mis arvutatakse üksikute näitajate summana, siis

peab pakkuja muutma üksikute näitajate hindu selliselt, et pakkumuse kogumaksumus

muutuks vähemalt sammu võrra.

Enne pakkumise esitamist saab pakkuja käivitada arvutuse, kui mitmenda positsiooni taoliselt

esitatav pakkumine talle annaks. Selle arvutuse põhjal saab pakkuja teha lõpliku otsuse, kas

esitada uus pakkumine või muuta seda enne esitamist veel.

Pakkumise esitamisel käivitub uuesti sama arvutus. Kui arvutuse tulemusena pakkuja ei

saavuta esimest positsiooni, siis küsib süsteem pakkujalt esitamisele kinnitust. Pakkuja võib

küll esitada sellised väärtused, mis talle esikohta ei taga, peaasi, et väärtused on sammu võrra

muudetud.

Iga esitatud pakkumise kohta saavad kõik osalejad süsteemse teavituse.

16.5.5 E-oksjoni automaatne pikenemine

Kui e-oksjonile tehakse parim pakkumine vahetult enne oksjoni lõppu, siis pikeneb e-oksjon

automaatselt. Pikenemise aega reguleerib lisaaja parameeter.

Näiteks. E-oksjoni lõpptähtaeg on kell 16:00 ja lisaajaks on määratud 30 minutit. Pakkuja

esitab uue maksumuse kell 15:45 ehk vähem kui 30 minutit enne lõppu. Süsteem pikendab

automaatselt e-oksjoni lõpu aega ja uueks lõpp tähtajaks saab 16:15.

E-oksjoni pikenemise kohta saavad kõik osalejad süsteemse teavituse.

16.5.6 E-oksjoni lõpetamine

Kui e-oksjon on lõppenud ehk oksjoni lõpu aeg on möödunud, siis koostab hankija e-oksjoni

kokkuvõtte. Selle tulemdokumendi toodab süsteem hankijale automaatselt. Tulemdokumendis

on nähtav oksjoni lõplik pingerida, oksjonil tehtud pakkumised ning oksjoni algjärjestus.

Tulemdokumendi avalikustamine osalejate jaoks toimub üldises korras.

Seejärel lõpetab hankija e-oksjoni tegevuse. Selle tulemusena lõppevad automaatselt ka

oksjonil osalevate ettevõtjate töölehel olevad tegevused.

Töölehe kaudu on ka edaspidi võimalik toimunud e-oksjonite tulemusi vaadata.

16.6 E-kataloog

Elektrooniline kataloog ehk e-kataloog on pakkumuste elektroonilise esitamise ja koostamise

ühtne vorming.

Elektroonilise teabevahetuse korral võib hankija nõuda pakkumuse esitamist e-kataloogi kujul

või pakkumusele e-kataloogi lisamist. E-kataloogi kujul esitatud pakkumustele võib lisada

muid pakkumust täiendavaid dokumente. ([2] § 40)

E-kataloogide laiem kasutusele võtmise vajadus tuleneb hankijate vahendite kokkuhoiu

nõudest, kus ühele hankijale või kesksele hankijale on antud volitus koondada kõigi hankijate

vajadused ja viia läbi “katushange”, mille alt on hankijatel võimalik oma hankevajadused

rahuldada. Hanke korraldab (ühis)hankija või keskne hankija. Ühele e-kataloogi positsioonile

saavad ettevõtjad pakkumuses vastata erinevate tootjate toodetega või toote komplektidega.


© AS Datel 2016 112/120

Näiteks olgu toodud hankijate vajadus hankida arvuti töökohti komplektidena erinevatele

kasutajagruppidele – arvutidisainer, tarkvaraarendaja, tava-ametnik (lauaarvuti), kõrgete

nõuetega kasutaja, liikuv kasutaja kasutajate (eri kvaliteedinäitajatega sülearvutid või

tahvelarvutid) jne. Hankija koostatab nimekirja toodetest, millele ettevõtjad saavad teha

pakkumusi.

E-kataloog peab olema kasutatav nii ühe hankija, ühis- kui ka keskse hankija huvides.

E-kataloogi funktsionaalsus arendatakse välja eRHR registrist sõltumatu eraldiseisva

rakendusena. eRHR registri arenduse raames on ette nähtud ainult liidestus e-kataloogi

funktsionaalsusega.

16.6.1 E-kataloogi kasutajad

E-kataloogi ja eRHR registri kasutajate baas võiks olla teatavas ulatuses ühine. Kindlasti on

tarvilik, et eRHR registrisse sisenenud kasutaja saaks siirduda e-kataloogi ilma täendava

logimiseta ning samuti vastupidi.

Esialgse plaani kohaselt hakkavad mõlemad rakendused kasutama ühte ja sama

autentimisteenust. Autentimine toimub eRHR registri kasutajate andmete põhjal.

E-kataloogi detailanalüüsi käigus täpsustub, kas iga eRHR registrisse sisenenud kasutaja saab

pöörduda e-kataloogi ja millistes õigustes ta seal siis tegutseks.

E-kataloogiga seotud rollide ja õiguste haldamine hakkab toimuma e-kataloogi poolel. See

tähendab, et ka e-kataloogi rakendus hakkab salvestama kasutajate andmeid või viiteid

kasutajaile, et neile oleks võimalik õigusi häälestada.

Esialgu ei ole teada vajadus, et e-kataloogi peaks saama kasutada riigihangetega mitteseotud

isikud. Kasutajakonto loomine ning kasutajate sidumine asutustega, nii hankijate kui

ettevõtjatega toimub ainult eRHR keskkonnas. Info seostest ning muudatustest peab jõudma

ka e-kataloogi. E-kataloogi detailanalüüs täpsustab, kuidas ja mis hetkel info liikumine täpselt

toimub. Võib oletada, et see toimub kasutaja pöördumisel e-kataloogi pärast autentimist.

16.6.2 eRHR ja e-katakoogi seos hanke menetlemisel

Enne e-kataloogi detailanalüüsi valmimist on võimalik tulevast liidestust planeerida vaid väga

üldisel kujul. On tungivalt soovitav, et e-kataloogi detailanalüüs võtaks arvesse ka eRHR

registri võimalusi ning vajadusi ja samuti vastupidi. Parimal juhul valmiksid need 2 analüüsi

paralleelselt.

16.6.2.1 E-kataloogi hanke ettevalmistamine

eRHR registris hanget ettevalmistades teeb hankija märke kas kogu hanke kohta või osadeks

jagatud hanke puhul iga hanke osa kohta, kas selles hankes või osas kasutatakse e-kataloogi.

Kui hankija on sellise nõude püstitanud, siis tuleb pakkumust koostavatel ettevõtjatel seda ka

järgida.

Esialgu on täiesti lahtine, mil viisil hankija hanke ettevalmistamise ajal e-kataloogist

tellitavaid tooteid kirjeldab. Kas piisab sellest, et hankija loetleb tellitavate toodete ja/või

teenuste cpv-koodid või luuakse e-kataloogis toodetele oma klassifikatsioon, millele hankija

ettevalmistamise ajal viitab. Eelanalüüsi käigus jäi kõlama mõte, et hankija kirjeldab

tellitavaid tooteid/teenuseid vabas vormis ning laeb kirjelduse hankedokumendina üles.


© AS Datel 2016 113/120

16.6.2.2 Pakkumuse tegemine e-kataloogi vormis

Need ettevõtjad, kes osalevad e-kataloogi kasutavas hankes ning soovivad pakkumust teha,

peavad saama siirduda eRHR registrist e-kataloogi vaadeldava hanke kontekstis.

Pöördumisel peab e-kataloogi kas tekkima või olema sealpool kättesaadav vähemalt järgmine

info:

kasutaja, kes soovib pakkumust koostada

ettevõtja, keda see kasutaja esindab

hange, millele ta soovib pakkumust teha

selle hanke alusdokumendid, mis kirjeldavad e-kataloogi tooteid, cpv-koodid või toodete

koodid e-kataloogi klassifikatsiooni alusel

pakkumuse esitamise tähtaeg

Infovahetus peab toimuma viisil, et andmete valiidsus oleks piisava turvalisusega tagatud.

Sellise pöördumise puhul peab e-kataloog võimaldama kasutajal sisestada või laadida e-

kataloogi tooteid, määrata neile toodeltele hankepõhine hind ja tarnetingimused.

Selle ettevõtja selle hanke toodetele peab tekkima ühtne tunnus, mille alusel on toodete

nimekiri hiljem kiiresti ja üheselt leitav.

See tunnus salvestub tegevuse tagasisidena eRHR registri poolele ning selle tunnuse abil on

ettevõtjal võimalik eRHR registris oma pakkumusele e-kataloogis viidata.

Pakkumuse esitamine toimub eRHR registris tavapärasel viisil.

16.6.2.3 Esitatud pakkumuste hindamine hankija poolt

Hankijal peab olema võimalik esitatud e-kataloogi vormis pakkumusi avada ja omavahel

võrrelda.

Minimaalselt peab olema võimalik pakkumuses sisalduva tunnuse (lingi) abil pöörduda e-

kataloogi esitatud toodete nimekirja vaatlemiseks.

Maksimaalsemal juhul saab hankija pöörduda e-kataloogi hanke kontekstis ning talle

kuvatakse võrdlevalt kõik selle hanke kohta esitatud e-kataloogi pakkumused.

Pakkumuse vastavuse kontrolli tulemid ning hindamistulemused kannab hankija eRHR

registrisse tavapärasel moel.

Kui edukad pakkumused on valitud ja toimub lepingu sõlmimine, siis peab e-kataloogi

jõudma teadmine sõlmitud lepingute kohta. Lepinguga kaetud pakkumustele lisandub

„aktiivne“ tunnus. Peale selle peavad jõudma e-kataloogi andmed lepingu kogumaksumuse

ning tähtaja kohta.

16.6.3 E-kataloogist tellimine

E-kataloogist ostude sooritamine on peaaegu täielikult ainult e-kataloogi rakenduse

funktsionaalsus.

Esialgne kokkulepe on ainult, et e-kataloogi pöörduval kasutajal peab olema tuvastatud seos

ühe või mitme hankijaga ning nende hankijate kaudu peab olema tuvastatav seos aktiivsete e-

kataloogi pakkumusnimekirjadega.


© AS Datel 2016 114/120

E-kataloogi pöörduv kasutaja võib olla aktiivse nimekirjaga (lepinguga) seotud ka mõne

ühishankija või keskse hankega liitnud hankija kaudu.

Ei ole selge millal ja kuidas see seos täpselt tuvastatakse. Eeldame, et kuna kasutaja võib

siseneda e-kataloogi rakendusse otse, mitte eRHR registri kaudu, siis peab e-kataloogi

rakendus tegema päringu eRHR registrisse saamaks seda infot. Selle info dubleerimine e-

kataloogi poolel ei ole väga põhjendatud, sest kasutaja ja asutuse seoste haldamine, samuti

hankijate liitumine keskse hankega – need funktsionaalsused on realiseeritud eRHR registris

ja kui e-kataloog peaks tahtma ka enda juures vastavat infot hoida, siis on vaja kõik

muudatused peegeldada ka e-kataloogi rakendusse.

E-kataloogi rakendus kuvab kasutajale kõigi tema jaoks aktiivsete lepingutega seotud tooted.

Kasutaja peab saama tooteid ostukorvi valida erinevate lepingute ja erinevate hangete alt. Jääb

e-kataloogi detailanalüüsi täpsustada, kas toodete ostukorvi valimine ja ostukorvi kinnitamine

ning tasumine on erinevate rollidega kasutajate ülesanne või pole vaja seda eristada.

Igatahes peab olema vähemalt ostukorvi kinnitamise hetkel kasutajale nähtav, milliseid

hankeid (lepinguid) see tellimus puudutab, milline on nende hangete (lepingute) eeldatav

maksumus, kui suur osa on jooksvaks hetkeks juba ärakulutatud, kui palju on veel vaba

ressurssi ning kuidas mõjutab käesolev tellimus nende hangete jooksvat kulu.

Pärast tellimuse vormistamist peab tagasisidena eRHR poolele jõudma teadmine sellele

tellimusele kulunud summadest hangete kaupa. Tagasiside põhjal formeeritakse eRHR

registris hanke andmetes lepingute lehele e-kataloogi tellimus koos summaga, nii et ka eRHR

registri kaudu oleks pidev ülevaade e-kataloogis kulutatud summadele.

E-kataloogi tellimus võib lisanduda nii raamlepingu kui ka hankelepingu alla, sest pole

välistatud, et e-kataloogist ostmine toimub hankelepingu alusel. Enamasti peaks e-kataloogi

vajadus tekkima siiski ühis- ja kesksete hangete ning raamlepingute korral.


© AS Datel 2016 115/120

17 MUUDATUSTE KOKKUVÕTE

Kasutajad ja rollid.

Registri edasiarenduse käigus ühtlustatakse rollide nimed ja õiguste süsteem. Kaotatakse

ebavajalikud rollid. Õigused realiseeritakse vastavalt funktsionaalsuste ja õiguste maatriksile

võimalikult kompaktselt ja ühekordselt. Näiteks, kui lisandub uus funktsionaalsus, mis on

lubatud tavakasutajale, siis peab see automaatselt muutuma nähtavaks ja kättesaadavaks

kõigile registri kasutajatele, sest kõik registri kasutajad pärivad tavakasutaja õigused.

Kasutajate registreerimine

Üldine suund on lihtsustamise suunas. Kõik kasutajad, nii Eesti kui välismaa päritolu

kasutajad, saavad omale ise kasutajakonto registreerida. Registri peakasutaja osalust enam

vaja ei ole. Laieneb oma andmete ja eelistuste haldamise võimalus. Kasutajal on võimalus

asutuse juures muuta oma kontaktandmed erinevaks põhikonto seadistustest.

Süsteemis tegutsevad asutused

Lisandub kontrollasutuste mõiste. Riigihangete kontrolli teostavad asutused hakkavad ise oma

kasutajaid haldama ja registri peakasutaja koormus väheneb.

Kõigile süsteemis registreeritavatele asutustele (hankijad / ettevõtjad / kontrollasutused) tekib

kehtivuse tunnus. Asutuste peakasutajad saavad ise oma asutuse kehtetuks muuta ning pooleli

hanked / pakkumused õigusjärglasele suunata. Üldine suund on selline, et vähendada registri

peakasutaja osalusvajadust ja et asutused saaksid võimalikult palju ise oma vajadusi katta.

Igale asutusele tekib oma dokumendipank sagedamini kasutatavate failide hoidmiseks.

Kasutajate volitused asutuse ja hanke juures

Kasutajate rollid asutuse juures ühtlustatakse. Asutuste juures eristatakse vaid asutuse

peakasutajaid, kellel on õigus hallata teisi selle asutusega seotud kasutajaid.

Hanke juurde hakatakse komplekteerima ettevõtjapoolset meeskonda, mis tagab suurema

paindlikkuse ettevõtja kasutajate haldamiseks.

Nii hankija kui ettevõtja meeskonnas olevate isikute õigused ei ole enam vaikimisi

piiramatud. Nad kaotavad oma õigused, kui lahkuvad töölt vastavas asutuses. Hankija

meeskonda saab lisada hankijaga mitteseotud kasutajaid tähtajaliselt. Tähtaja möödudes nad

kaotavad oma eriõigused.

Hanke menetlemine

Hanke menetlusprotsess muutub oluliselt. Luuakse tegevuskeskne lähenemine. Andmete

muutmine hakkab toimuma ainult tegevuste vahendusel. Tegevused koondavad endas

andmeversioone. Tegevuse lõpetamine jõustab, muudab registris nähtavaks temaga seotud

andmed.

Hanke ettevalmistamine

Hanke ettevalmistamisel üheks kõige olulisemaks muudatuseks on see, et kõigi tingimuste

täitmist peab pakkuja saama omapoolselt kinnitada ilma vastavaid tõendeid lisamata. See

tähendab, et tingimusele peab hankija määrama kinnituse tüübi. Enamik tingimusi on

süsteemis ettevalmistatud ja hankija ei pea neid ise sõnastama.

Hankepass integreeritakse täielikult süsteemi, selle loomiseks ja täitmiseks on registris

mugavad võimalused. Kasutaja ei pea hankepassi keskse teenuse poole pöörduma, kui ta seda

ei soovi.


© AS Datel 2016 116/120

Hindamiskriteeriumid ja maksumusvorm ühendatakse kokku. Maksumusvorm hakkab olema

pakkumuse kogumaksumuse määramise osa ka visuaalses plaanis.

Kõiki tingimusvorme näevad hankija ja pakkuja täpselt ühesuguses kujunduses.

Lisandub hanke kooskõlastamise võimalus registris.

Taotluse ja pakkumuse koostamine ja esitamine

Suurim muudatus seisneb selles, et enam ei ole kohustust pakkumusi digitaalselt allkirjastada.

Ilma digiallkirjata esitamisel ei ole vajadust tavaallkirjadega dokumenti juurde esitada.

Teiseks tulenevalt hanke ettevalmistamises tehtud muudatustest ei pea ja ei saagi pakkuja

enam üleslaetavaid dokumente tingimustega siduda. Kõik dokumendid laeb pakkuja üles nn

lisadokumentidena ja kinnitab tingimuste täitmist sõnaliselt.

Kõik see peaks tunduvalt lihtsustama pakkumuste esitamist. Tülikam on ainult see, et nüüd

peavad osalemistingimuste kinnitused esitama kõik kaaspakkujad ja allhankijad, kelle

näitajatele pakkuja toetub. Lisaks täitma ka kõik hankepassis nõutavad andmed enda kohta.

Taotluste ja pakkumuste menetlemine

Suurimaks muudatuseks taotluste ja pakkumuste menetlemisel on see, et tegevusi peab saama

teha osade kaupa erinevatel aegadel.

Teiseks suuremaks täienduseks on protokollide redigeerimisvõimalus pärast tootmist süsteemi

poolt ja enne kinnitamist.

Osalemistingimusi peab saama kontrollida kaks korda, alguses kinnituste alusel ja hiljem

tõendite alusel. Süsteemi integreeritud hankepassi funktsionaalsus toob kaasa selle, et täidetud

hankepasse ei pea enam eraldi võrdlema, vaid seda saab teha otse süsteemis.

Muutunud on ka hankijapoolsete hindamistulemuste käsitlus. Hankija ei pea enam oma

hinnanguid kriteeriumi osakaaluga ühtlustama. Hankija võib sisestada oma loogika alusel

arvutatud hindamispunktid süsteemi ja punktide numbriline väärtus ei ole süsteemi jaoks

enam oluline. Oluline on omistatud väärtuspunktide erinevus erinevatel pakkumustel.

Teabevahetus

Teabevahetuse lehel on kõik edastatud saadetised koondatud kokku ühte nimekirja.

Edastamata saadetised sinna hulka ei satu ja neid näeb saadetise lisamise lehel.

Hanke saadetiste nimekirja peab saama kõigi kuvatavate tunnuste alusel filtreerida.

Lepingud

Lepingute osas on suurimaks muudatuseks nende kuvamine raamlepingute hankes, aga

samamoodi ka dünaamilise ostusüsteemi ja kvalifitseerimissüsteemi korral. Minikonkursside,

DHS ja KS hankelepinguid hakatakse kuvama lisaks sellele hankele, mille raames nad loodi

veel ka eelnevas hankes. Raamlepingu hankes hakatakse jooksvalt summeerima ka sõlmitud

hankelepingute esialgset ja tegelikku maksumust.

Teiseks suuremaks muudatuseks on raamlepingu alusel hankelepingu registrisse kandmise

võimalus ilma minikonkursita.

Info otsimine

Oluliselt muutub hanke otsingu vorm. Otsingut on võimalik teha paljude tingimuste alusel.

Kasutaja saab salvestada enam mitte ainult ühte otsingueelistust, vaid võib luua omale

mitmeid lemmikotsingufiltreid, millest ühe saab häälestada vaikimisi rakenduvaks.

Eraldi teate ja vaidlustuse otsingut avalikele kasutajatele enam ei ole. Selle asemel on hanke

otsing teate või vaidlustuse andmete alusel.


© AS Datel 2016 117/120

Avaldamise ootel teadete nimekiri jääb kasutatavaks registri peakasutajale, pooleliolevate

vaidlustuste nimekiri VAKO töötajatele. Need nimekirjad on avatavad otse vastavate

kasutajate töölaualt.

Kasutajate töölaua üldine kujundus peab samuti muutuma. Esialgu teada olevad vajadused on

visandatud, kuid kasutaja töölaua täiendamine peaks lõppkokkuvõttes toimuma kasutamise

käigus tekkivate reaalsete vajaduste ja tagasiside alusel.

Lisandub eraldiseisev lepingute otsing. See on vajalik ülevaate saamiseks konkreetsete

lepingute olemasolust. Nimekirjast avaneb siiski hanke andmete vorm lepingute lehelt, sest

ilma hanke kontekstita lepingute vaatlemine ei anna täit ülevaadet.

Vaidlustused

Vaidlustuse osas lisandub uuendusena võimalus, et kõigil aktiivselt ettevõtja esindajana

tegutsevatel kasutajatel on võimalik registri kaudu hankeid vaidlustada. Vaidlustada saavad

ka otseselt hankega mitteseotud ettevõtjad.

Vaidlustuste sisuline läbivaatamine jääb siiski VAKO ülesandeks. Register ei kontrolli

esitatud vaidlustuse asjakohasust.

Teiseks lisandub vaidlustustele täiendav info edasikaebamiste ning edasikaebamise tulemite

kohta.

Teavitused

Süsteemsete teavituste hulk laieneb. Kuna laieneb süsteemi funktsionaalsuste hulk, siis ka

erinevatest sündmustest teavitamise vajadused laienevad. Samas ühetaoliste teavituste

jadamisi tekkimise hulk peaks vähenema. Kuna hanke alusdokumente ei muudeta enam

ükshaaval, vaid tegevuses sisalduvate portsudena, siis selle kohta laekub ka teavitus

ühekordselt.

Teavitustele lisandub prioriteedi tunnus. Kõige kõrgema prioriteediga teavitusi ei saa kasutaja

enda jaoks ära keelata. Need tekivad alati nii registrisse kui ka e-posti aadressile. Madalama

prioriteediga teavituste korral saab kasutaja häälestada, kas ta neid üldse oma e-postile ei

soovi või soovib saada N päeva koondina. Süsteemi tekivad teavitused ikka otse sündmuse

toimumise hetkel. E-kiri aga võidakse saata välja hiljem ning võib sisaldada mitut

samaliigilist teavitust.

Registri funktsionaalsusesse lisandub vanade teavituste automaatne eemaldamine kasutaja

vaatest. Süsteemi arhiivi jäävad kõik teavitused alles.

Kõik teavitused on kasutaja jaoks personaalsed. Ettevõtja meeskonna määratlemine hankes

toob kaasa võimaluse, et teavituse saavad kõik meeskonnaliikmed eraldi ja enam ei ole vaja

teavitada ettevõtjat kui juriidilist isikut, mille puhul märgiti teavitus süsteemis loetuks, kui

esimene kasutaja seda vaatas.

Elektroonilised tööriistad

eRHR registrisse tekivad arenduse käigus juurde mitmed uued võimalused, mis tänases

registris kas puuduvad või on välja arendatud osaliselt ja kasutamiseks ebasobivalt.

Registris arendatakse välja kesksete hangete loomise võimalus. Ühishanked on juba täna

olemas, kuid see ei kata keskse hanke vajadusi. Nii ühis- kui kesksete hangete puhul saavad

kõik hankes osalevad hankijad määrata oma meeskonda.

Uues registris arendatakse kasutuskõlblikuna ja seadustega kooskõlas olevana välja nii

dünaamiline hankesüsteem kui ka kvalifitseerimissüsteem võrgustiku hankijaile. Mõlemad on

küll ka tänases registris põhimõtteliselt olemas, kuid nad ei toimi selliselt, et kasutajad saaksid

neid enda vajaduste kohaselt rakendada.


© AS Datel 2016 118/120

Uues registris arendatakse välja uus menetluse liik – erimenetlus, mis oma olemuselt ei ole

vastavuses mitte ühegi RHS-s kirjeldatud hankemenetluse liigiga. Hankija saab ise valida

millist menetluskorda ta rakendab. Erimenetlust saab rakendada sotsiaal- ja eriteenuste

tellimisel ning kontsessioonide korraldamisel.

E-oksjon on tänases registris olemas vaid madalaima hinna kriteeriumi korral. Uues

lahenduses saab e-oksjonit kasutada mistahes numbriliste näitajate kohta.

eRHR registriga liidestatakse e-kataloogi funktsionaalsus. E-kataloog arendatakse välja

eRHRst sõltumatuna, kuid selle kasutamine peab siiski haakuma ka üldisesse riigihangete

menetlemise protsessiga. E-kataloogi analüüsi ajal on tarvis ette näha kokkupuutepunktid

eRHR registriga ning täpsustada nendes punktides toimuvate sündmuste sisu.

17.1 Käesolevas analüüsis kajastamata teemad

Käesolev eelanalüüs ei kata järgmisi teemasid.

Teadete moodul: teadete koostamine, esitamine, TEDi edastamine ja sealt laekuva tagasiside

loomine. See funktsionaalsus arendatakse välja olemasoleva registri juurde uuel platvormil

ning tuleks uude registrisse üle võtta ilma oluliste muudatusteta. Kuna käesoleva eelanalüüsi

koostamise ajal ei olnud teadete moodul veel lõplikult projekteeritud, siis ei saanud seda ka

suuremas mahus analüüsis arvestada.

E-kataloogi moodul arendatakse välja eraldi eraldiseisva tööna ning selle mooduli analüüs ei

olnud käesoleva eelanalüüsi koostamise ajal veel lõplik. Käesolev eelanalüüs kajastab vaid

üldist nägemust eRHR ja e-kataloogi ühendamisest, kuid detailsem analüüs saab toimuda alles

siis, kui loodava e-kataloogi võimalused ja realiseeritavad funktsionaalsused on selgunud.

Statistikamooduli uued vajadused ei ole teada ning nende täpsustamine praeguses

eelanalüüsis ei ole otstarbekas seetõttu, et vajadused kindlasti muutuvad pärast uue RHS

jõustumist aprillis 2016. Statistiliste vajaduste väljaselgitamiseks tuleks läbi viia küsitlus

hankijate hulgas, kuid enne RHS jõustumist ei ole oodata adekvaatset tagasisidet. Selge on

ainult, et praeguses registris olevaid hankijapõhiseid aruandeid tuleks laiendada kõigile

hankijatele. Lisada tuleb valdkonnapõhised aruanded, kuid täpsustamist vajab valdkonna

määratlus.

Igal juhul põhineb riigihangete statistika hangete ja lepingute eeldataval ja tegelikul

maksumusel. Seda teadmist arvesse võttes jäeti registri funktsionaalsusesse alles lepingute

tegeliku maksumuse määratlemise nõue, mis RHS kohaselt tegelikult enam hangete

menetlemise protsessi ei kuulu.

Statistiliste aruannetega seondub ka avaandmete temaatika. Tõenäoliselt oleks otstarbekas

luua registrile tootmissüsteemist eraldiasetsev avaandmete baas ehk andmeladu, mille pealt

hakkaksid tööle ka statistilised aruanded. Andmelaos hoitavad andmed võivad olla

denormaliseeritud kujul, nende struktur ja värskendamise protsess vajab täpsustamist

arenduse käigus.

Statistika ja avaandmetega seondub ka hangete arhiveerimine. Hangete arhiiv ja avaandmed

on erinevad vajadused. Arhiveeritakse dokumente, mis oma olemuselt ei pruugi olla

avaandmed. Lahendust vajab juurdepääsuõiguste tagamine arhiivis. Näiteks on vaja

arhiveerida ka pakkumusi ja hanke tulemdokumente, mis ei ole avalikult kasutatavad.

Eraldi analüüsi vajab ka asendustoiming. See on tegevus, mis rakendub süsteemis tehniliste

katkestuste korral. Kui vahetult enne pakkumuste esitamise tähtaega esineb registrile

juurdepääsus või registri töös katkestusi, siis peatub hankemenetlus automaatselt ja

pakkumuste või hankemenetluses osalemise taotluste esitamise tähtpäev ei saabu.


© AS Datel 2016 119/120

Asjassepuutuvad hanked saavad märke „peatunud“. Riigihangete registri töö taastumise

järgselt pikendab hankija peatunud hangete pakkumuste või hankemenetluses osalemise

taotluste elektroonilise esitamise tähtaega mõistliku aja võrra. Registri katkestusi monitoorib

registriväline süsteem. Registri katkestuse ajal saadab monitooringusüsteem e-posti teel

teavituse registri kasutajatoele ja hankijatele, kellel on pooleli hankemenetlused. Kui see ei

ole võimalik, läheb teavitus pärast töö taastumist.

Täiesti uus haru on hangete planeerimise ja turu-uuringute moodul. Tegemist on kas

hankija- või valdkonnakeskse tegevusega kus määratakse kindlaks organisatsioonisisene

hankekord.

Hankekorras sätestatakse muu hulgas:

1) riigihanke planeerimise, sealhulgas iga-aastase hankeplaani koostamise ja kinnitamise kord

ning tähtpäev;

2) riigihanke eest vastutav isik või isikud või nende määramine, sealhulgas hankelepingu

täitmise eest vastutava isiku määramine;

3) alla riigihanke lihthanke piirmäära jäävate asjade ostmise, teenuste või ehitustööde

tellimise kord;

4) vajadusel sotsiaal- ja eriteenuste tellimise kord, sealhulgas alla sotsiaal- ja eriteenuste

rahvusvahelise piirmäära, välja arvatud kaitse- ja julgeolekuvaldkonnas;

5) vajadusel kaitse- ja julgeolekuvaldkonnas lihtsustatud korras tellitavate teenuste tellimise

kord, sealhulgas alla kaitse- ja julgeolekuvaldkonna lihtsustatud korras piirmäära;

6) meetmed huvide konflikti ennetamiseks, tuvastamiseks ja kõrvaldamiseks riigihankel, kui

need meetmed ei ole kindlaks määratud muus organisatsioonisiseses töökorraldust käsitlevas

dokumendis. ([2] § 9 lg 3)

Hankija võib enne riigihanke alustamist hankelepingu eseme täpsemaks piiritlemiseks ja

riigihanke ettevalmistamiseks teha turu-uuringu. Turu-uuringu käigus võib hankija

konsulteerida asjaomases valdkonnas tegutsevate isikute ja ettevõtjatega. Saadud nõuandeid

võib kasutada riigihanke kavandamisel ja läbiviimisel tingimusel, et see ei moonuta

konkurentsi. Turu-uuringu tegemisel ja selle käigus saadud nõuannete kasutamisel riigihankes

tagab hankija mittediskrimineerimise ja läbipaistvuse põhimõtete järgimise. ([2] § 10 lg 1,2)

Registris peab kesksel hankijal olema võimalik määratleda enda poolt esindatavaid asutusi

juba varem, mitte hanke loomise raames, vaid registris üldiselt. Funktsionaalsus on analoogne

nagu kirjeldatud pt 16.1.2.

Kõigepealt selgitab keskne hankija välja enda poolt esindatavate hankijate vajadused. Keskne

hankija määratleb hankeplaani sisendi vormi, mille kaudu ta hankijatelt ettepanekuid ootab.

Turu-uuringud on oma olemuselt justnagu väikesed hanked, mille eesmärgiks on välja

selgitada, milliseid asju või teenuseid pakutakse, milline on pakutavate toodete või teenuste

hinnatase ning kui palju on vastaval turul võimalikke pakkujaid. Samas ei tohi turu-uuringud

segi minna tegelike hangetega ning ettevõtjate jaoks peab olema väga selgesti arusaadav, et

tegemist on turu-uuringuga, mitte pakkumise küsimisega.

Saadud sisendi põhjal hakkab Riigi Tugiteenuste Keskus koostama hankeplaani, kus on

kajastatud kõikide asutuste vajadused ja kus muuhulgas on planeeritud hankega alustamise

eeldatav aeg.

Hankeüksuse (keskse hankija) sisese töö korralduse vaates kantakse hankeplaani järgmised

andmed:

lähteülesande esitamise kuu, aasta;

hanke nimetus ja hanke objekti lühikirjeldus;

hanke objekti täiendus, märkus;

hanke korraldaja (vastutav isik);

kas hange on rahvusvaheline;


© AS Datel 2016 120/120

kas tegemist on ühishankega;

sisendi (lähteülesande) esitaja asutus,

sisendi esitaja kontaktisiku nimi ja andmed;

hankelepingu liik (asjad, teenused);

hankemenetluse liik;

hankelepingu eeldatav maksumus;

eelmise lepingu maksumus;

asja või teenuse vajaduse alates (kuupäev);

lepingu sõlmimise eeldatav kuupäev;

lepinguperioodi pikkus;

lepingu tähtaeg.

Hankeplaani täitmise seisukohast oleks oluline, kui hankeplaani saaks sisestada lisaks

järgmist:

hanke olek (nt ettevalmistamisel, töös, lõpetatud);

lepingu sõlmimise (tegelik) kuupäev;

lepingu (tegelik) maksumus;

probleemid, mis hanke ettevalmistamisel või menetluse läbiviimisel esinesid;

hanke edasi lükkumise või ära jäämise põhjused.

Kõiki hankeplaanis toodud andmeid avalikult ei kuvata, reeglina on kodulehel nähtav üksnes

hanke objekti kirjeldus, sisendi esitaja ehk asutuse nimi, kellele asju või teenust hangitakse,

vastutava isiku nimi, kas tegemist on ühishankega ning millal on lepingu sõlmimise soovitav

kuupäev.