Käskkiri

Võrgurajatiste andmebaasi ja selle kasutajaliidese viimine Ehitisregistri (EHR) arenduskeskkonnast EHR toodangukeskkonda. Lähteülesanne 1. Taustainfo Võrgurajatiste andmebaas koos kasutajaliidesega on EHR varasema arendusprojekti käigus loodud infosüsteem võrgurajatiste (torustikud, kaablid jmt) ruumi- ja atribuutandmete kogumise ja taaskasutamise võimaldamiseks. Arendusprojekti käigus loodi võrgurajatiste andmebaas, andmevahetus standard, teenused andmevahetuseks ja andmebaasis oleva informatsiooni visualiseerimise võimalus kasutajatele. Võrgurajatiste andmebaasi arendustööd toimusid samaaegselt teiste EHR’i arendustöödega, mis tekitas tänu ristsõltuvustele takistusi arenduse koheseks käiku andmiseks. 2. Eesmärk 2.1. EHR arenduskeskkonnas https://devkluster.ehr.ee/ui/ehr/vra/ olevad võrgurajatiste andmebaasi teenused tuleb integreerida EHR raamkomponenti ja viia üle EHR toodangukeskkonda (raamkomponent ja toodangukeskkond edaspidi koos nimetatud live keskkond). 2.2. EHR arenduskeskkonnas olev võrgurajatiste andmebaas (baasi skeem) tuleb viia üle EHR live keskkonna andmebaasi. 3. Üldised nõuded arendusprotsessile 3.1. Arendustööde üleandmine toimub pärast kõigi arendustööde valmimist ja tellija poolt teostatud testimise edukat lõpetamist. 3.2. Arendusprotsess ja selle lõpptulemused dokumenteeritakse vastavalt MKM IT osakonna poolt kindlaks määratud nõuetele ning agiilse tarkvaraarenduse heale tavale. 3.3. Arendusprotsessi juhtimiseks ja projekti läbiviimiseks kasutatakse MKM projektijuhtimistarkvara JIRA. 3.4. Projekti juhtimiskoosolekud toimuvad iganädalaselt Teams keskkonnas. Koosolekud salvestatakse. Koosoleku protokolli koostab arendaja, protokollid allkirjastatakse digitaalselt nii arendaja kui ka tellija poolt. Protokoll peab sisaldama üheselt arusaadavat kokkuvõtet koosolekul arutatust ja vastu võetud otsuseid. 3.5. Arendus peab vastama MKM Infosüsteemide arendustalituse poolt kindlaks määratud nõuetele, mis on kirjeldatud järgmistes dokumentides: Lisa 1 - e-ehituse platvormi tarkvaraline arhitektuur; Lisa 2 - e-ehituse platvormi ristfunktsionaalsed nõuded (mittefunktsionaalsed nõuded); Lisa 3 - EHR arendustööde läbiviimise ja testimise juhend; Lisa 4 - e-ehituse platvormi stiiliraamat; Lisa 5 - Ehitisregistri (EHR) rakenduse koodi haldamise ja tarnejuhend; Lisa 6 - EHR API teenuste nimetused ja teenuste kirjeldamine; Lisa 7 - Ehitisregistri andmebaasid ja nende uuendamise juhend; 4. Arendustööde teostamise tähtaeg 4.1. Andmebaasi skeemi ning teenuste live keskkonnas toimimise soovituslik tähtaeg on 01.10.2022. 4.1.1.Lepingu lõpptähtaeg määratakse parimas pakkumuses esitatud tööde teostamiseks vajaliku kalendripäevade arvu alusel alates lepingu allkirjastamisest. 5. Arendustööde kirjeldus 5.1. Andmebaas 5.1.1.Arenduskeskkonda loodud andmebaas (baasi skeem) taasluua EHR live keskkonna andmebaasi osana. 5.1.2.Võrgurajatiste andmebaasi väljaarendamise käigus loodud testandmeid ei kanta üle live keskkonda. 5.1.3.Varasemate testimiste käigus loodud klassifikaatorite väärtustest teha tellijale väljavõte. Väljavõtte põhjal koostöös tellijaga määratakse üle kantavad klassifikaatorite väärtused. 5.2. 5G pääsupunktide paigaldamise otsuste avalikustamise teenus (T6) 5.2.1.Teenus on loodud Euroopa Sidedirektiivi nõude täitmiseks. Direktiiv kohustab avalikustama 5G pääsupunktide (small cell) paigaldamise taotlused Riigi ja KOV ehitistele (vt Ehitusseadustik § 6112)) 5.2.2. Ehitisregistri live keskkonnas peab teenus olema infopäringuks kättesaadav kõigile keskkonda sisse loginud kasutajatele. 5.2.3.Täiendada varem loodud teenust, luues võimaluse kaheks võimalikuks töövooks: 5.2.3.1. EHR live keskkonda sisse loginud KOV või Riigi ehitise haldaja esindaja saab üles laadida pääsupunktide asukoha andmefaili ning pääsupunkti rajamise otsuse. Otsuse aluks olev menetlus ei toimu EHR keskkonnas. Pääsupunktide asukohad ja kooskõlastuse tulemused kuvatakse kaardil. 5.2.3.2. Pääsupunkti paigaldamise taotluse esitamine toimub EHR keskkonnas. Arendada edasi varem loodud teenust ja integreerida see EHR menetlusprotsessi vastavate osadega. 5.2.3.2.1. EHR live keskkonda sisse loginud 5G sagedusluba omava ettevõtte kasutaja saab esitada KOV või Riigi ehitisele pääsupunkti paigaldamise taotluse laadides üles andmevahetusfaili, milles on ühe või mitme soovitava pääsupunkti andmed. 5.2.3.2.2. Täiendada varem loodud taotluse vormi ehitise EHR koodi ja aadressiga, millele soovitakse pääsupunkt paigaldada. Samuti lisada taotluse vormile kooskõlastava asutuse valik. 5.2.3.2.3. Ühes taotluses võivad olla ühe kooskõlastava asutuse hallatavatele ehitistele soovitavad pääsupunktid. 5.2.3.2.4. Lisaks varem arendatule tuleb luua võimalus iga pääsupunkti kohta üles laadida projektdokumentatsioon (asendiplaan, vaated, lõiked jmt). 5.2.3.2.5. Esitatud taotlus peab jõudma kooskõlastava asutuse töölauale kasutades EHR menetluse protsessi. 5.2.3.2.6. Kooskõlastamise protsess toimub vastavalt arenduskeskkonnas olevale pääsupunkti kooskõlastamise töövoo loogikale.  5.2.3.2.7. Pääsupunktide asukohad ja kooskõlastuse tulemused kuvatakse kaardil. 5.3. Situatsiooni päring (T1) Situatsiooni päring kujutab endast EHR avakuva, millel kasutajal on võimalik temale huvi pakkuvas piirkonnas näha visuaalselt seal asuvaid võrgurajatisi ja pärida nende tehnilisi andmeid. Samuti on võimalik kasutajal lülitada sisse ja välja erinevaid võrguliike. Infosüsteemi töö stabiilsuse huvides on ära piiratud maksimaalne võimalik kaardi ulatus millel on võimalik korraga võrgurajatisi kuvada. 5.3.1. EHR live keskkonnas autentimata kasutajatele kuvatakse teenuse T1 kaudu vaid võrgurajatiste asukoha- ja üldinfo. Ei kuvata võrgurajatise elementide detailinfot. 5.3.2.EHR live keskkonnas autenditud kasutajatele toimib teenus T1 täies ulatuses. 5.4. Geodeedi teenus (T2) Geodeedi teenus on annab geodeedile võimaluse alla laadida tema poolt määratud piirkonda jäävate võrgurajatiste andmefail, milles olevaid andmeid saab ta kasutada oma töö efektiivsemaks teostamiseks. Peale geodeetilise töö teostamist on geodeedil kohustus täiendatud andmefail üles laadida võrgurajatiste andmebaasi. Protsessi tulemusena täpsustub andmebaasis olev informatsioon ning väheneb vajadus varasemalt mõõdistatud võrgurajatiste üle mõõtmiseks. 5.4.1. Ehitisregistri live keskkonnas on teenus T2 kättesaadav ainult autenditud kasutajatele, kes on seotud geodeetilisi töid teostavate ettevõtetega. 5.5. Võrguvaldaja teenus (T4) Võrguvaldaja teenus annab võrguvaldajatele võimaluse oma valduses olevate võrgurajatiste andmete edastamiseks võrgurajatiste andmebaasi. 5.5.1. Ehitisregistri live keskkonnas on teenus kättesaadav kõigile keskkonna autenditud kasutajatele, kes on seotud võrguvaldaja ettevõttega. 5.5.2. Arendajal tuleb teenust T4 täiendada päringuga, millega autenditud kasutaja saab otsida endaga seotud ettevõtte võrgurajatisi. Päringu tulemus kuvatakse tabelina, milles kasutaja saab rakendada otsinguid kitsendavaid kriteeriumeid ja sorteerida päringu tulemusi. Päringu tulemuses saab kasutaja valida võrgurajatise, mida kuvatakse kaardil. Juhul kui tehniliselt ei ole mõistlik tabulaarse info kuvamine veebilehitseja abil võib arendaja luua .csv formaadis andmefaili, mille saab päringu teinud kasutaja alla laadida ja rakendada teda huvitavad kitsendused. 5.6. Ühisehitus (T7) Ühisehituse teenus on ette nähtud võrguvaldajatele suhtluskeskkonnana samas piirkonnas toimuvate ehitustööde ajastuse koordineerimiseks ja infovahetuseks. 5.6.1. EHR live keskkonnas peab teenus olema kättesaadav kõikidele autenditud kasutajatele, kes on seotud võrguvaldaja ettevõttega. 5.7. Andmete edastamine Maa-ameti kitsenduste infosüsteemi (KPO IS) (T8) Teenus on mõeldud regulaarseks automaatseks võrgurajatiste andmete edastamiseks Maa-ameti kitsenduste infosüsteemile X-tee abil. 5.7.1. Täiendada varem loodud andmepäringut vastavalt võrgurajatiste andmebaasi paiknemisele EHR live keskkonnas. 5.7.2.Kaasajastada X-tee ühendus vastavalt võrgurajatiste andmestikule EHR live keskkonna andmebaasis.  EHR arendustööde läbiviimise ja testimise juhend V4 – 03.12.2020 Käesolev juhend on mõeldud järgimiseks kõigile EHR arendusega seotud osapooltele. Juhendis on kirjeldatud infovahetuse allikad ja kohustused. 1. EHR arendustööde dokumentatsiooni hoitakse Sharepoint dokumendihalduses (SP). Keskkonna halduse ja juurdepääsu eest vastutab MKM. Meeskondade projektijuhid edastavad projekti alguses nimekirja (ees- ja perenimi, isikukood, e-kirja aadress) osalistest, kes peavad juurde pääsema EHR dokumendihoidlale. 2. Projekti alguses luuakse SP-sse projekti kaust, kuhu kogutakse kõik projektiga seotud dokumendid nagu koosolekute protokollid, lähteülesanded, projektiplaanid jm. dokumendid. Juhul, kui dokument paikneb kuskil teises asukohas siis lisatakse SP projektikausta link sellele dokumendile. 3. EHR dokumentatsioon antakse Tellijale üle dokumendihalduse keskkonna kaudu. Juhul, kui samast dokumendist edastatakse mitu versiooni, siis kõik erinevad versioonid tuleb nimetada ühe ja sama failinimega. Versioonid eristuvad SP-s „versiooni ajaloo“ kaudu. 4. EHR dokumentide sisukord (analüüsi, disaini, arhitektuuri, testimise, projektijuhtimise kontekstis) lepitakse kokku enne vastavate projekti tööde algust. Täitja projektijuht, kes hakkab vastavat dokumenti koostama, esitab hiljemalt tööde alguse kuupäeval SP projektikausta dokumendi kavandi, milles on toodud vähemalt dokumendi sisukord ja võimalusel ka vorm. 5. Operatiivse suhtlusvahendina kasutatakse lisaks (mobiil)telefonile ka Skype keskkonda. Projekti osalised lisatakse projekti ühisvestlusesse. Täitja projektijuht edastab vajalike osaliste Skype kontode nimekirja MKM projektijuhile, kes lisab nimekirja liikmed vestlusele. 5.1. Projekti kestel on kõigil meeskonnaliikmetele kohustus osaleda vestluses; 5.2. Projektide vahelisel ajal tööde planeerimiseks või vigade aruteluks, on tehnilistel projektijuhtidel, analüütikutel või arhitektidel kohustus osaleda vestluses; 5.3. Vestluses on kohustuslik informeerida kõiki osapooli kavandatavatest tarnetest. Vt. EHR koodi haldamise ja tarnimise juhendit 6. Osapooled praktiseerivad proaktiivset kommunikatsiooni ning ei varja võimalike vigu ja probleeme. 7. EHR tarnete, arendustööde, vigade ja hooldustööde fikseerimiseks kasutatakse JIRA keskkonda. Meeskondade projektijuhid edastavad projekti alguses nimekirja (ees- ja perenimi, isikukood, e-kirja aadress) osalistest, kes peavad juurde pääsema EHR JIRA keskkonnale. 8. Arendusprojektide läbiviimise alguses koostab Täitja Lepingu lähteülesandes toodud funktsionaalsete nõuete kohta JIRA piletid tüübiga “arendus”. Arenduspiletite koondamiseks luuakse JIRA komponent, nii, et kõik ühe lepinguga seotud (või lepingu alapunktiga) seotud piletid on seotud vastava komponendiga. Komponentide abil saab ülevaate kõigist komponendiga seotud arendustöödest ja veapiletitest, mis vastavas komponendis aja jooksul on tehtud. 9. Lepinguliste tööde arendamiseks, testimiseks ja üleandmiseks koostatakse kõikidest üle antavatest JIRA piletitest sprint, mille kestus on max 1 kuu. Arendustööde sprindi paigaldus ja üleandmine toimub vastavuses EHR koodi haldamise ja tarnimise juhendile 10. Lepinguliste tööde Tellijale üleandmine algab Täitja poolt üleandmise akti esitamisega (või vastavuses Lepinguga). Üleandmise aktis peavad olema viited kõigile üleantavatele tulemitele sh.: 10.1. Lingid üleantavatele koodidele Git-s (git.mkm.ee). Link peab olema koodiharule ja -versioonile, milles asub üleantav kood, 10.2. Viide API teenuste endpointidele Swaggeris (swagger.ehr.ee) 10.3. Viide Katalon automaattestidele, millega üleantavat rakendust saab testida 10.4. Viited projekti tulemdokumentidele SP-s (https://365mkm.sharepoint.com/sites/MKM/EHR) 10.5. Viit, millelt Tellija saab alustada rakenduse testimist 10.6. Üle antava rakenduse Helm Chart nimetus ja versioon (juhul, kui üle antav rakendus paigaldatakse Kubernetes klastrisse) 11. JIRAsse loodud arenduspiletid peavad olema sellise detailsusastmega, et nende alusel saavad arendajad teostada arendustööd ning testijad saavad läbi viia vastuvõtu testimise. 12. Arendustöödes tuvastatud vigade lahendamiseks koostab MKM Helpdesk JIRA-sse lisatud veapiletite alusel kord kuus arendajale kriitiliste vigade sprindi, mille arendaja tarnib järgmisel kuul MKM-le testimiseks. 13. JIRA piletite lahendamise protsessi üldine kirjeldus on järgmine: 13.1. Töid üle andva arenduspartneri testija testib kõik üle antavad piletid esmalt MKM keskkonnas “test”. Testimisel viib testija piletid oma nimele staatusega „TESTIMISEL“. Peale testimist viib arenduspartneri testija piletid staatusesse „OMANIKU TESTI OOTEL“ ja suunab piletid MKM testijale. Üldpõhimõttena antakse piletid üle “OMANIKU TESTI OOTEL” staatusesse esimesel võimalusel, ehk ei neid ei grupeerita ega anta üle portsude kaupa. 13.2. MKM testijad testivad piletid ning peale testimist suunavad arenduspartneri testijale staatuses „TESTITUD“ või „AVATUD“ vastavalt sellele, kas pilet oli lahendatud või esineb vigu. 13.3. Kui kõik sprindi piletid on peale MKM testimist staatuses „TESTITUD“, siis võib liikuda järgmisesse toodangusse viimise etappi “prelive”. 13.4. Peale “prelive” tarnet testib arenduspartneri testija kõik üle antavad piletid esmalt MKM “prelive” keskkonnas. Testimisel viib testija piletid oma nimele staatusega „TESTIMISEL“. Peale testimist viib arenduspartneri testija piletid staatusesse „OMANIKU TESTI OOTEL“ ja suunab piletid MKM testijale. 13.5. MKM testijad testivad piletid prelive keskkonnas ning peale testimist muudavad pileti staatuseks „LAHENDATUD“, „TARNE OOTEL“ või „AVATUD“ vastavalt sellele, kas pilet oli lahendatud, vajab üle kontrollimist toodangus või esineb vigu. 13.6. Kui kõik prelives oleva tarne piletid on staatuses „LAHENDATUD“, siis võib alustada toodangusse tarnimisega. 13.7. Juhul, kui “prelive” etapis avastati vigu siis alustatakse peale vigade parandamist uuesti “test” etapist. 14. Kõikide osapoolte projektijuhid lisatakse JIRA tarnepiletite kohta info saajateks. 15. Tööde tähtaegade fikseerimisel tuleb arvestada, et töö tähtaeg tähendab kokkulepitud päeva algust kell 00.00. 16. Kõik MKM projektiga seotud meediaga suhtlus tuleb alati kooskõlastada ennetavalt MKMiga; ka MKM peab ennetavalt kooskõlastama partneritega meediasse suunatava informatsiooni. 17. Kõik EHR arenduse projektis läbi viidud koosolekud protokollitakse (fikseeritakse otsused, riskid, probleemid) ja soovi korral helisalvestatakse, selles osas lepitakse rollide täitjad kokku enne koosoleku algust. Üldjuhul koostab protokolli Täitja projektijuht ja salvestab selle koosolekule järgneval tööpäeval SP-sse projekti kausta. 18. Iga sprindi/arendusetapi lõpus viiakse vajadusel läbi üle antava töö ühisläbivaatus, mille käigus Täitja esindajad esitlevad Tellijale üle antava töö tulemit. 19. Täitja projektijuht esitab projekti alguses MS Project formaadis projekti tööde plaani SP- sse projekti kausta (kui MKMiga ei ole eelnevalt kokku lepitud teisiti). Täitja projektijuht uuendab igal projekti töönädala esmaspäeval esialgselt esitatud projektiplaani ning lisab sellesse tööde täitmise informatsiooni. 20. Tööde plaan vaadatakse kõigi osapoolte poolt üle igal projekti koosolekul ja vajadusel viiakse sellesse muudatused. 21. Juhul, kui arendusprojekti käigus on vajalik EHR andmebaasides muudatuste tegemine siis peab järgima: E-ehituse andmebaasid ja nende uuendamine 22. Juhul, kui arendusprotsessi käigus luuakse uus teenuste API või täiendatakse olemasolevaid teenuseid siis arendaja täiendab API kirjeldust Swaggeris vastavalt EHR API teenuste nimetused ja teenuste kirjeldamine  Ehitisregistri (EHR) rakenduse koodi haldamise ja tarnejuhend Dokumendi eesmärk: Juhend on mõeldud EHR arendajale ning juhendis on kirjeldatud reeglid, EHR rakenduste tarnimiseks EHR testi ja toodangu keskkondadesse. EHR rakendused on: • EHR olemas olev Java rakendus • EHR kaardirakendus • EHR VRM e. võrgurajatiste rakendus • EHR React e. uus kasutajaliides • EHR API e. uued teenused ja teenuste seotud rakendused Kubernetes klastris • Andmeait EHR Java rakenduse1 tarneprotsess 1. EHR lähtekood paikneb Git https://git.mkm.ee/ehr/ehr-monolith-pipeline. Uue EHR Java rakenduse versiooni arenduse alustamisel tuleb algkood võtta alati Git ehr/ehr_main ehk peaharust. Iga arendaja vastutab, et kõik peaharusse teiste arendajate poolt tehtud muudatused, mis on tehtud peale koodi arenduseks võtmist, on koodi sisse viidud enne, kui rakendus viiakse testiks prelive keskkonda (test.ehr.ee). 2. EHR koodi versioneeritakse ja algkoodi võtmisel peab arendajal olema teada, et millise versiooni alusel arendustööd teostatakse. Rakenduse tarnimisel ükskõik millisesse testi (test, test2, test3) keskkonda tuleb alati suurendada rakenduse versiooni numbrit ning uus versiooni number peab olema näha rakenduse avalehelt. Versiooni number peab vastama Semver 2.0 standardile. 3. Git peaharusse võib lisada ainult töötavat (kompileeriv, unit testid töötavad ja www.ehr.ee e. toodangukeskkonnas töötavat) koodi. Koodi lisamiseks teeb arendaja Git-s „Merge requesti“ hiljemalt rakenduse toodangusse tarnimise päeval. „Merges“ ei tohi esineda konflikte. Pärast „merge requesti“ tegemist informeeritakse (projekti Skype vestluses) partnereid ja MKM projektijuhti. Kõik andmebaasi muudatustega seotud SQL scriptid peavad olema samuti paigaldatud Git peaharu EHR DB haru alamharusse. Alamharu nimetus peab sisaldama aasta kuu ja päeva ning rakenduse versiooni numbrit. Selgitusse tuleb lisada arendaja firma nime ja rakenduse versiooni numbri. 4. Arendustööde üleandmine algab rakenduse paigaldamisest EHR testikeskkonda (test 2 või 3). Esmalt paigaldatakse andmebaasimuudatused. Selleks koostada andmebaasi muudatuste skriptidest paigalduspakett ja lisada see tarnepakettide FTP-sse (ftp.mkm.ee/tarned). Peale FTP-sse tarnepaketi lisamist koostatakse JIRA keskkonnas (https://jira.mkm.ee/projects/MKMEHR/) tarnepilet (pileti tüüp = „tarne“) ja suunatakse see majutaja esindajale (Eero Tammelaan). Tarnepiletisse lisatakse viide tarnepaketile ja juhend tarnimiseks. Samuti lisatakse piletisse tarnepaketiga tehtavate uuenduste lühikirjeldus ja vajadusel ka parandatud veapiletite loetelu. Juhul, kui tarnepaketis sisaldub rohkem kui üks käivitamist vajav skript siis peab tarnepakett sisaldama nn. masterskripti, mille abil käivitatakse kõik tarneskriptid õiges järjekorras. 1 EHR Java rakendus on olemas olev Tieto majutuses olev monoliitrakendus, mis ei kasuta mikroteenuste arhitektuuri. 5. Rakenduse paigalduseks testikeskkonda toimub automaattarnega. Kood viikse Git harusse, mis vastab testikeskkonnale: test2 või test3. Peale koodi harusse viimist käivitub automaattarne, mis kompileerib koodi, viib läbi esmase testi ning peale seda on rakendus vastavasse testikeskkonda paigaldatud. Automaattarne kirjeldus on toodud: Automaattarne protsessi kirjeldus 6. Peale majutaja poolt tarnepaketi testikeskkonda paigaldust (info selle kohta kajastub tarneks tehtud JIRA piletis, kui tarnija poolt tehakse pileti staatuse muudatus) peab tarnija koheselt kontrollima, et paigaldatud pakett töötab vigadeta ning käivitama Katalon automaattestid (https://git.mkm.ee/EHR-testid/automaattestid). Peale automaattestimise lõppu esitab Täitja üleandmise akti. Tellija poolne test algab kohe peale tarnija poolse üleandmise akti esitamist. 7. Paigalduspaketi koostamisel tuleb kasutada EHR Archiva repositooriumi vastavalt juhendile: EHR Archiva juhend 8. Juhul, kui testkeskkonda paigaldatud pakett sisaldab „kriitilisi“ vigasid ka peale teistkordset testikeskkonda paigaldamist peab Tarnija Tellija projektijuhi nõudmisel tarnepaketi testikeskkonnast eemaldama. Paketi eemaldamine on vajalik, kui mõni teine tarnija soovib vahepeal oma arendused üleandmiseks testikeskkonda tarnida. 9. Arendustööde üleandmine lõppeb peale arenduste paigaldamist rakenduse toodangu keskkonda. Toodangu keskkonda paigaldamist võib alustada peale Tellija projektijuhilt vastava teate saamist. Toodangu keskkonda paigaldus toimub analoogselt testikeskkonda paigaldamisega. Tarnepakett -> FTP -> JIRA pilet - > paigaldus -> arendaja test -> paigalduse aruanne. 10. Kogu loodud või muudetud lähtekood peab olema kommenteeritud, nii et see on kõigile osapooltele arusaadav. Kommentaaridest peab olema tuvastatav, et kes, millal ja mis eesmärgil on koodi muudatused teinud. 11. Kogu loodud või muudetud lähtekood peab olema kaetud moodultestidega (unit test); EHR mikroteenuste paigaldusprotsess 1. EHR mikroteenuste rakenduste lähtekoodid paiknevad Git https://git.mkm.ee/ehr/ehr- k8s-pipeline. Uue EHR mikroteenuste rakenduse arenduse alustamisel tuleb luua uus projekt eelpool mainitud GIT gruppi. 2. Uue projekti loomisel tuleb projekti selgituseks lisada projekti eesmärk 3. Uue projekti loomisel tuleb projekti readme.md failis lisada juhend arendajale: koodi käivitamiseks, testimiseks ja tarnimiseks ning vajadusel koodi teistes projektides kasutamiseks. Readme failis peavad sisalduma viited tarnimiseks vajalikele secretitele ja configmap-le ning Rancheris asua Helm Charti nimetus. 4. EHR mikroteenuste koodi versioneeritakse vastavuses Semver 2.0 standardile. Rakenduse Helm charti2 tarnimisel Kubernetese keskkonda tuleb alati suurendada rakenduse versiooni numbrit vastavuses Semver 2.0 standardiga, kujul “version-x.x.x”. 5. Git peaharusse “Master”, kust toimub automaattarne protsess võib lisada ainult töötavat (kompileeriv, unit testid töötavad, Sonarcube raport vastab nõuetele3) koodi, mida hakatakse toodangusse viimiseks testima. 6. Kasutusel on kaks Kubernetes klastrit: mkm-ehr ja mkm-ehr-tst. Kood tarnitakse esmalt katsetusteks ja arendusteks mkm-ehr-tst klastri “Development” projekti, milles olev andmebaas ja rakendused on seotud EHR Java rakenduse test3.ehr.ee nimelise testikeskkonnaga ja test3 Oracle andmebaasiga. a. Tellija poolseks testiks tarnitakse üle antavad rakendused mkm-ehr-tst klastris “Test” projekti, milles olev andmebaas ja rakendused on seotud EHR Java rakenduse test2.ehr.ee nimelise testikeskkonnaga ja test2 Oracle andmebaasiga. b. Peale Tellijalt kinnituse saamist viiakse üle antavad rakendused mkm-ehr klastris “Prelive” projekti, milles olev andmebaas ja rakendused on seotud EHR Java rakenduse test.ehr.ee nimelise testikeskkonnaga ja test1 Oracle andmebaasiga. Prelive viimise teeb Tellija poolt määratud Majutaja, kes hiljem tarnib rakendused ka toodangusse e. “Toodang” projekti. “Prelive” tarnejuhendid tuleb lisada “Helm Charti” “readme” faili. 7. Iseseisvalt ei tohiks luua uusi Kubernetes namespace ja Rancher projekte. Juhul, kui see on vajalik siis tuleb need Tellija projektijuhiga eelnevalt kooskõlastada. 8. Peale koodi viimist projekti peaharusse tuleb lisada Git Tag kujul “version-x.x.x”. Tagi lisamine käivitab automaattarne protsessi vt. Automaattarne protsessi kirjeldus 9. Juhul, kui koodi muudatused eeldavad andmebaasi muudatusi siis andmebaasi muudatustega seotud SQL scriptid peavad olema viidud Git https://git.mkm.ee/ehr/databases grupis olevasse vastavasse andmebaasi projekti. 10. Arendustööde üleandmine algab rakenduse paigaldamisest EHR testikeskkonda Rancher Test Projekt. Esmalt paigaldatakse andmebaasimuudatused. Selleks 2 Helm chart on rakenduse tarnejuhised, mille alusel käivitatakse Kuberneteses rakendusele vajalikud ressursid 8. 3Koodi Sonarqube raport https://sonarqube.mkm.ee/dashboard?id=<projektinimi> peab olema: a. Reliability Bug = 0 b. Security Vulnerability = 0  koostada andmebaasi muudatuste skriptidest paigalduspakett ja teostada selle alusel paigaldus (vt. E-ehituse andmebaasid ja nende uuendamine). 11. Rakenduse paigaldus testikeskkonda toimub eelnevalt tarnitud ja testitud Helm Chartiga ning järgib juhendit: Automaattarne protsessi kirjeldus 12. Peale rakenduste testikeskkonda paigaldust peab tarnija koheselt kontrollima, et paigaldatud pakett töötab vigadeta ning käivitama Katalon automaattestid (https://git.mkm.ee/EHR-testid/automaattestid). Peale automaattestimise lõppu esitab Täitja üleandmise akti. Tellija poolne test algab kohe peale tarnija poolse üleandmise akti esitamist. 13. Juhul, kui testkeskkonda paigaldatud pakett sisaldab „kriitilisi“ vigasid ka peale teistkordset testikeskkonda paigaldamist peab Tarnija Tellija projektijuhi nõudmisel tarnepaketi testikeskkonnast eemaldama. 14. Arendustööde üleandmine lõppeb peale arenduste paigaldamist rakenduse toodangu keskkonda. Toodangu keskkonda paigaldamist võib alustada peale Tellija projektijuhilt vastava teate saamist. Toodangu keskkonda paigalduseks koostab Tarnija JIRA pileti, milles on toodud Helm Charti nimetus ja juhend selle käivitamiseks. 15. Kogu loodud või muudetud lähtekood peab olema kommenteeritud, nii et see on kõigile osapooltele arusaadav. Kommentaaridest peab olema tuvastatav, et kes, millal ja mis eesmärgil on koodi muudatused teinud. 16. Kogu loodud või muudetud lähtekood peab olema kaetud moodultestidega (unit test), mis peavad olema arendaja poolt käivitatud enne rakenduse uue versiooni paigaldamist Git koodihoidlasse;  EEHITUS API teenuste nimetused ja teenuste kirjeldamine V6 – 05.03.2021 Ülo Puskar Eesmärk: Dokument kirjeldab “eehitus” API teenuste ja kasutajaliidese URL-de (sisendpunkt) kokkuleppeid Sissejuhatus API kirjeldamise reeglid on vajalik kokku leppida, et tagada ühtne API sisendpunkt nii, et teenuse kasutajad ei peaks teadma, et millises EHR infrastruktuuri serveris teenust käitatakse ja teenuste nimetused ei korduks. Lisaks API sisendpunktidele on kasutusel sisendpunktid andmebaasi põhiobjektide EEHITUS kasutajaliideses avamiseks Reeglid 1. API teenused ei tohi korduda. Uute teenuste loomisel tuleb esmalt veenduda, et olemas olevas API-s juba pole sarnast teenust. Kui on siis tuleb olemas olevat teenust edasi arendada, mitte luua uut teenust 2. API rakenduses olemasolevate teenuste kirjeldused tuleb enne teenuse loomist lisada EHR API teenuste kirjelduste andmebaasi: https://git.mkm.ee/ehr/ehr-k8s-pipeline/swaggerui 3. Teenuse kirjeldused tuleb lisada “yaml” failina. Failinimi peab olema sama, mis Java (või NodeJS või Python) paketi nimi, näiteks Java paketinimi “ee.ehr.document_api” siis teenuse yaml faili nimi: “document_api.yaml”. 4. Teenuste URL nimetamisel tuleb järgida <domain>/api/nimetus/vN/… a. <domain> tuleneb API rakenduse Rancher projektist. Igale Rancher projektile vastab domain näiteks “devkluster.ehr.ee” b. /api/ - kõigil API-del sarnane tähistus c. Nimetus on APIt iseloomustava rakenduse nimetus, näiteks: arhiiv, andmeait, statistikaportaal, kaardirakendus vms. d. vN on API versiooni number, näiteks v1 v2 jne. e. peale versiooninumbrit tuleb API teenust e. endpointi iseloomustav nimetus, mis ei tohiks kattuda API-s juba kirjeldatud teenuse nimedega. 5. API teenuste uued versioonid peavad olema ühilduvad vähemalt kaks versiooni tagasi ehk uue versiooni API “route” e. “url” peab toetama kahe eelneva versiooni “route” sisendeid ja väljundeid. 6. API-l peab olema “route” /version, mis väljastab API kehtiva versiooni numbri kujul: “version- x.x.x”. 7. API-l peab olema K8s “liveness probe” 8. API URL peab olema inglise keeles 9. API uuendamisel tuleb järgida põhimõtet, et kui muudetakse API-t sellises ulatuses, et olemas olevates API-t kasutavates rakendustes tuleb teha API uuema versiooni kasutamiseks muudatusi: (näiteks muudetakse API olemasolevate parameetrite nimetusi või lisatakse uusi “kohustuslikke” parameetreid) siis tuleb muuta API URL-s versiooninumbrit ja tagada, et API uus ja vana versioon töötaksid samaaegselt. 10. Uue API versiooni lisamisel tuleb Swaggeris olemasolev API responses: objekt tähistada prefiksiga deprecated näiteks: kui responses: "Media type” on “application/json” siis uue api  "Media type” on “application/json” ja vana API "Media type” saab olema “deprecated- application/json”. Analoogselt tuleks tähistada API parameetrid. Kui prameetreid muudetakse siis kasutuselt maha võetavad parameetrid tuleks tähistada parameters: description väljal “deprecated” märgendiga. “Deprecated” märgendiga objektid tuleks kustutada Swagger kirjeldustest peale API aegunud versiooni kasutuselt eemaldamist. 11. Kasutajaliideses sisendpunkte omavad objektid on ehitis ja dokument. Objekti identifitseerimiseks kasutame query stringi. a. Ehitis sisendpunkt avab ehitise andmete vormi: <domeen>/ui/ehr/v1/building?ehrkood= b. Dokument sisendpunkt avab dokumendi andmete vormi: <domeen>/ui/ehr/v1/document?doknr= Teenustele Liveness probe lisamine 1. Liveness probe abil tuvastab Kubernetes perioodiliselt konteinerrakenduse töötamist ja juhul kui probe ei anna http päringu vastuse staatuseks 20* -30* siis teostab konteineri restardi. Koos liveness probega tuleks konfigureerida ka readiness probe, kuna ilma selleta võib juhtuda, et aeglaselt käivituvale konteinerile tehakse enne restart, kui ta pole veel jõudnud tööle hakata. Readiness probe kutsutakse välja kogu konteineri elutsükli jooksul (vt. Võimalikud karid). 2. API-s peab olema endpoint, mille alusel saab teostada päringu API töösoleku kontrollimiseks perioodiliselt päringuid näiteks timestamp küsimine andmebaasit vms. Endpoint peaks olema mõni tegevus, mis võtab vähe ressurssi (aeg, maht). 3. Liveness probe lisamiseks deploymentile tuleb Helm chartis Kubernetese deploymentis (deployment.yaml) kirjeldada konteinerile kaks probet: readiness, liveness näiteks: spec: containers: readinessProbe: failureThreshold: 10 httpGet: path: /health port: 3000 scheme: HTTP # kuna probe töötab ilma Ingressita siis peaks kasutama http initialDelaySeconds: 10 periodSeconds: 30 successThreshold: 1 timeoutSeconds: 3 livenessProbe: failureThreshold: 10 httpGet: path: /health port: 3000 scheme: HTTP initialDelaySeconds: 10 periodSeconds: 30 successThreshold: 1 timeoutSeconds: 3 4. Peale App deploy tegemist kontrollida Rancheris workload>pod>container ja vaadata Event alamosast, kas probe töötamise eventid on näha. Samuti on võimalik kontrollida konteineri enda logist, kas health päringud on logist näha (juhul kui rakenduse logisse on health endpointi logimine arendaja poolt lisatud). 5. Täiendav info Kubernetes juhend  Ehitisregistri andmebaasid ja nende uuendamise juhend V2.1 23.03.2020 Dokumendi eesmärk on kirjelda Ehitisregistri (EHR) ja e-ehituse infrastruktuuris olevad andmebaasid ning nende uuendamise protsess, et tagada andmebaasides andmete kooskõla ning andmebaaside vaheliste konfliktide vältimine. EHR arhitektuur baseerub mikroteenuste kontseptsioonil vt. Ehitisregistri arhitektuur. Tänane EHR on liikumas monoliitselt arhitektuurilt mikroteenuste arhitektuurile, kasutades järkjärgulisel ümberkujundamisel baseeruvat metoodikat („Brownfield development“). Esialgne EHR Oracle andmebaas - edaspidi EHR monoliit sisaldas kogu EHR andmestikku. Lisaks monoliidile on kasutuses EHR „andmeaida“ Postgre andmebaas, kuhu kogutakse kõik EHR baasis toimuvad sündmused ning EHR VRM Oracle andmebaas, kus hoitakse võrgurajatiste mooduliga seotud andmeid. EHR monoliitbaasis hoiti 2019 aasta lõpuni lisaks eraldi skeemidena Hooneregistri ja EHR 1 andmeid. Vastavuses mikroteenuste kontseptsioonile võetakse EHR infrastruktuuris kasutusele uute teenustega seotud andmebaasid ning seetõttu on oluline tagada uute ja olemasolevate andmebaaside omavaheline kooskõla. Selle saavutamiseks rakendatakse uus roll EHR „Data steward“, kelle vastutusel on EHR andmebaaside kooskõlas hoidmine. EHR andmebaasi loogiline kirjeldamine ning edasiarendamine toimub Enterprise Architect tööriista kasutades. EHR andmebaasi analüüs ja arendamine 1. Analüüsi lähteandmeteks on SP-s paiknev EA fail EHR andmemudelid ja selles olevad andmebaaside skeemid: a. <Datamodel>Oracle – EHR Java rakenduse andmebaasi skeemi EHR andmetabelid, vaated (Oracle andmebaas) i. <Datamodel> YHR – hooneregistri andmebaasi skeem (Oracle andmebaas) ii. <Datamodel>SHR – ehr1 rakenduse andmebaasi skeem (Oracle andmebaas) iii. <Datamodel> YHR – hooneregistri andmebaasi skeem (Oracle andmebaas) iv. <Datamodel>VRM – VRM e. võrgurajatiste andmebaasi skeem (Oracle andmebaas) v. <Datamodel> EHRGIS – EHR GIS rakenduse skeem (Oracle andmebaas), rakendus pole enam kasutusel vi. <Datamodel>DOGISCONTEXT – EHR kaardirakenduse (XGIS) skeem (Oracle andmebaas) b. Andmebaasi Andmeait (Postgre) skeemid: i. DW - core data (tabelid) ii. DM - datamardid andemekaevurile (materialiseeritud vaated) iii. RVA - väljundvaated erinevatele rakendustele (tabelid, materialiseeritud vaated) iv. RVA_VIEW - vaated kasutajatele (andmekaevur, aruande koostaja)  v. KOV - statistika portaali andmed (tabelid, funktsioonid ) vi. PPA- politsei ja piirivalve (tabelid, funktsioonid) vii. PSA - laadimisteks staging area (tabelid ja funktsioonid) viii. SB - andmekaevuri sandbox (kasutaja poolt loodud abitabelid) c. Andmebaasi Xtee (Postgre) skeem “xtee” x-tee teenuste andmetabelid ja funktsioonid d. Mikroteenuste andmebaas “ehrdb” (Postgre). Andmebaasis on iga mikroteenuse API jaoks oma skeem. i. Geo – ehitiste ja KÜ aadressid, ruumikujud ii. Eehitus – dokumendid, ehitised, menetlused, failid iii. Kasutaja – isikud, kasutajad, rollid, õigused iv. Koodid - kooditabelid 2. Füüsiliselt andmebaasis olemas olevad tabelid/veerud/vaated jm. objektid peavad olema tähistatud EA staatusega „Implemented“. 3. EHRi andmebaasides muudatuste tegemiseks koostab arendaja/analüütik esmalt muudatuse EA mudeli ja kooskõlastab selle EHR "Data stewardiga". Kooskõlastuse palvele lisab ta lühida põhjenduse ja – juhul kui see on konkreetsel juhul mõistlik – viite(d) arenduse JIRA piletile/piletitele. "Mudeli koostamisel tuleb kasutada uutel või muudetavatel elementidel EA staatust „Proposed“, et eristada plaanitavaid muudatusi juba kasutusel olevatest objektidest. Mudeli kohta peab olema koostatud ERD joonis, millel on kujutatud kõiki tabeleid ja view-sid, mis on seotud käesoleva arendusega. 4. EHR „Data steward“ tellib vajalike muudatuste sisseviimise ka teistesse EHR andmebaasidesse nagu „andmeait“ jm. koostades selleks JIRA arenduspiletid ja suunates need hooldajatele. 5. Peale kooskõlastuse saamist tuleb koostada andmebaasi muutmiseks SQL-d ja esitada need vastavuses EHR koodi haldamise ja tarnimise juhendile 6. Peale andmebaasi uuendamist tuleb uuendada SP-s paiknev EA faili EHR andmemudelid ning viia muudatused staatusesse „Implemented“. 7. EA mudelit võivad samaaegselt muuta mitmed isikud ja seetõttu peab viimasena muudatusi teinud isik ühildama oma muudatused EA faili kõige viimasesse versiooni. Selleks, et muudatusi oleks lihtsam ühildada tuleb enne muutmist EHR „data stewardiga“ kooskõlastada muudatuste ulatus. Andmetabelite ja atribuutide nimetamise reeglid 1. Tabelid ja atribuudid on eesti keeles v.a. : created_by, date_created, updated_by, date_updated, deleted_by, date_deleted 2. Kõik tabelid ja atribuudid peavad olema kommenteeritud ning kommentaarid peavad andma ülevaate tabeli ja atribuudi eesmärgist ning vajadusel ka kasutamise reeglitest 3. Tabelite nimedes tuleb kasutada prefiksit, mis tähistab objekti, mida tabel kirjeldab näiteks: do – dokument, eh – ehitis, ad – aadress, ak – kasutaja, kl – klassifikaator. 4. Tabeli nimetamisel tuleb lähtuda tabeli eesmärgist ja üldjuhul peaks tabeli nimi olema: objekt_alamobjekt_seos_seose_liik. Näiteks do_doku on dokumendi objekti tabel, do_ehitis on dokumendil olevate ehitiste tabel, do_doku_ehitis_rel on dokumendi ja dokumendi ehitiste omavaheliste seoste tabel. 5. Juhul, kui tabel on koopia (link) mõnest teisest andmebaasist siis lisatakse tabeli nimetuse ette r_. Näiteks r_ad_aadressid on aadressi tabeli koopia geo andmebaasist ehk originaal tabel asub geo skeemis, kus toimub selle kirjete create, update, delete ning JOIN tegemise eesmärgil on tabeli lingitud mõne teise andmebaasiga ja seetõttu on nimes r_. w EHR andmebaasi hooldusprotsessis tehtavad muudatused 1. EHR andmebaasi pisimuudatused, mis tehakse hooldusprotsessi käigus vigade paranduse või pisiarenduse eesmärgil nagu välja pikkuse muudatus, uus indeks vms. tuleb kooskõlastada EHR „Data stewardiga“. Kooskõlastamiseks saadab hooldustöö tegija (arendaja) plaanitavate muudatuste SQL skripti, viite JIRA veapiletile, mida lisatud skript parandab, JIRA paigalduspiletile ja vajadusel põhjenduse ning saadab selle „Data stewardile“. 2. EHR „Data steward“ kooskõlastab muudatuse ning suunab pileti arendajale tagasi. Arendaja esitab pileti vastavuses EHR koodi haldamise ja tarnimise juhendile. 3. „Data steward“ uuendab vastavalt SQL-le SP-s paiknev EA faili EHR andmemudelid ning vajadusel loob JIRA arenduspiletid hooldajatele muudatusega seotud ülejäänud andmebaaside kooskõlla viimiseks. Andmetabelitest kirjete kustutamine 1. EHRi andmetabelitest kirjete füüsiline kustutamine on üldjuhul keelatud. Erandiks on ajutised või tehnilised andmetabelid, mille kirjed ei ole EHRi tavakasutajatele näha ja ei või mõjutada nende tööd. 2. Andmevigade parandamine toimub üldjuhul koos dokumendi (registri paranduskanne, AET) loomisega, parandatava kirje kehtivuse peatamise ja uue kirje loomisega. 3. Teatud olukordades võib olla mõistlik kirjeid siiski kustutada – näiteks dokumendid, mida kasutaja on alustanud, kuid ei ole kunagi esitanud ja mille puhul ei ole tõenäoline, et kasutaja seda kunagi esitaks (mitme kuu jooksul ei ole infot uuendatud) või programmkoodi poolt loodud sisutud topeltkirjed. Sellisel juhul peab kirje kustutamise soovija vastava plaani „Data stewardiga“ kooskõlastama, tuues välja põhjuse, miks andmeid kustutatakse, näidates ära võimalikud kustutatavate andmete seosed ja nende haldamise viisi ning – kui otstarbekas ja kooskõlas isikuandmete ja riigikaitseliste asutuste andmete käitlemise regulatsioonidega – saatma talle kustutatavad andmed tabelina. „Data stewardi“ ülesanne on ennekõike hinnata ega see tegevus ei too kaasa kasutajatele komplikatsioone, ei riku potentsiaalselt seotud osapoolte (kasutajad, arendajad, vastutav töötleja) õigusi, ei riku andmebaasi konsistentsust ega too kaasa tõrkeid EHRi töös ja määrata tingimused, kas, kuidas ja millal vastava operatsiooni läbi viimine lubada. Dokumendi muudatused V2.1 23.03.2020 Taavi Jakobson Lisatud osa „Andmetabelitest kirjete kustutamine“ V2 06.11.2019 Ülo Puskar  KÄSKKIRI 22.08.2022 nr 71 Lihthanke "Võrgurajatiste andmebaasi ja selle kasutajaliidese viimine Ehitisregistri (EHR) arenduskeskkonnast EHR toodangukeskkonda" korraldamine, komisjoni ja vastutava isiku nimetamine Riigihangete seaduse § 14 lõike 1 punkti 1, §-de 101 ja § 125 alusel ning kooskõlas ettevõtlus- ja infotehnoloogiaministri ning majandus- ja taristuministri 09.10.2017. a käskkirjaga (registreeritud dokumendihaldussüsteemis 03.10.2017. a) nr 1.1-1/17-199 kinnitatud „Majandus- ja Kommunikatsiooniministeeriumi hankekorraga“: 1. Korraldada lihthange (CPV kood 72200000-7, nimetus „Tarkvara programmeerimis- ja nõustamisteenused“) „Võrgurajatiste andmebaasi ja selle kasutajaliidese viimine Ehitisregistri (EHR) arenduskeskkonnast EHR toodangukeskkonda“ (edaspidi Töö) tellimiseks. 2. Kinnitan käskkirja punktis 1 nimetatud Töö tellimiseks riigihanke alusdokumendid (lisatud). 3. Tellitava töö eeldatav maksumus on 59 999 eurot (lisandub käibemaks). Töö teostamise tähtaeg on maksimaalset neli kuud arvates lepingu sõlmimisest. 4. Määran käskkirja punktis 1 nimetatud riigihanke korraldamise eest vastutavaks isikuks Majandus- ja Kommunikatsiooniministeeriumi ehitus- ja elamuosakonna (EEO) ehitisregistri talituse võrgurajatiste projektijuhi Meelis Raidmaa. 5. Moodustan hankekomisjoni punktis 1 nimetatud riigihanke korraldamiseks, sh pakkumuste vastavaks tunnistamiseks ja eduka pakkumuse väljaselgitamiseks ning edukal pakkujal kõrvaldamise aluste ja kvalifitseerimise tingimustele vastavuse kontrollimiseks hankepassis esitatud kinnitustele vastavate dokumentide alusel järgmises koosseisus: Komisjoni esimees: Meelis Raidmaa, EEO ehitisregistri talituse võrgurajatiste projektijuht; Komisjoni liikmed: Taavi Jakobson, EEO ehitisregistri talituse juhataja; Krista Hinno, EEO Ehitisregistri talituse analüütik.  2 6. Valitud hankemenetluse liigi ja käskkirja punktis 2 nimetatud riigihanke alusdokumentide peale võib esitada vaidlustuse Rahandusministeeriumi juures asuvale riigihangete vaidlustuskomisjonile riigihangete seaduses sätestatud korras ja tähtajal. (allkirjastatud digitaalselt) Ahti Kuningas transpordi asekantsler kantsleri ülesannetes  KÄSKKIRJA LISA 1 Majandus- ja Kommunikatsiooniministeerium „Võrgurajatiste andmebaasi ja selle kasutajaliidese viimine Ehitisregistri (EHR) arenduskeskkonnast EHR toodangukeskkonda“ Hankedokument Lihthange Tarkvara programmeerimis- ja nõustamisteenused CPV kood 72200000-7 Tallinn 2022 SISUKORD 1. Üldandmed 2. Hankelepingu ese 3. Pakkumuse jõusoleku tähtaeg 4. Pakkumuse ettevalmistamise juhend ja pakkumuse esitamine 5. Pakkumuse koosseis 6. Pakkumuse maksumus 7. Kõikide pakkumuste tagasilükkamine 8. Nõuded pakkuja meeskonnale 9. Pakkumuste vastavuse kontrollimine 10. Pakkumuste hindamine ja hindamiskriteeriumid 11. Hankelepingu tingimused Lisad 1. ÜLDANDMED 1.1. Hankija: Majandus- ja Kommunikatsiooniministeerium, registrikood 70003158, asukoht Suur–Ameerika 1, Tallinn 10122, e-mail: [email protected], tel. +372 625 6342 (edaspidi hankija). 1.2. Hankemenetluse liik: lihthange. 1.3. Hankemenetluse teostamise viis: riigihangete registris. 1.4. Riigihanke läbiviimise eest vastutav ametiisik: Majandus- ja Kommunikatsiooniministeeriumi ehitus- ja elamuosakonna ehitisregistri talituse võrgurajatiste projektijuht Meelis Raidmaa, tel: +372 625 6365, e-post: [email protected]. 1.5. Hankija jätab endale võimaluse pöördmenetluse läbiviimise otsustamiseks pärast pakkumuste esitamist. 2. HANKELEPINGU ESE 2.1. Hankija kutsub esitama pakkumust töö „Võrgurajatiste andmebaasi ja selle kasutajaliidese viimine Ehitisregistri (EHR) arenduskeskkonnast EHR toodangukeskkonda“ (hankelepingu ese) teostamiseks riigihanke alusdokumentides ja nende lisades sätestatud tingimustel. 2.2. Hankelepingu eseme täpsem kirjeldus on toodud riigihanke alusdokumendi „Hankedokument“ (edaspidi HD) Lisas 1 - „Lähteülesanne“ (edaspidi LÜ). 2.3. Töö teostamise tähtaeg on maksimaalselt neli kuud arvates lepingu sõlmimisest. 2.4. Pakkumuse esitamine tähendab pakkuja nõustumist kõikides riigihanke alusdokumentides kehtestatud hanketingimuste ja reeglitega. 2.5. Pakkumus peab vastama riigihanke alusdokumentides esitatud tingimustele ja tuleb esitada kogu riigihanke alusdokumentides nõutud mahus. 2.6. Alternatiivsete ja/või osaliste pakkumuste esitamine ei ole lubatud. 2.7. Hankija ei kompenseeri pakkujatele pakkumuse ettevalmistamisega seotud mistahes kulusid, sh turu-uuringu läbiviimise ettevalmistamisega seotud kulusid. 3. PAKKUMUSE JÕUSOLEKU TÄHTAEG 3.1. Pakkumus peab olema jõus vähemalt 90 kalendripäeva. Pakkumuse jõusoleku tähtaeg algab pakkumuse esitamise tähtpäevast. 3.2. Pakkuja esitab pakkumuses kinnituse pakkumuse jõusoleku kohta nimetatud tähtaja jooksul. 3.3. Hankija pikendab vajadusel pakkumuste jõusoleku tähtaega kooskõlas RHS §-s 112 sätestatud reeglitega. 4. PAKKUMUSE ETTEVALMISTAMISE JUHEND JA PAK KUMUSE ESITAMINE 4.1. Hankemenetluses teavituste saamiseks peavad hankest huvitatud isikud hankijale avaldama riigihangete registris oma kontaktandmed, registreerudes hanke juurde  „Hankes osalejad“ lehel. Hanke juurde registreerunud isikud saavad automaatteavitusi riigihanke alusdokumendi tühistamise või muutmise kohta, samuti toimub selgituste küsimine ja nendele vastamine e-riigihangete keskkonna kaudu. 4.2. Pakkumuse esitamisega kinnitab Pakkuja kõigi riigihanke alusdokumentides esitatud tingimuste ülevõtmist. 4.3. Pakkumus peab vastama riigihanke alusdokumentides esitatud tingimustele ja tuleb esitada kogu riigihanke alusdokumentides nõutud mahus. 4.4. Pakkumus ja kõik pakkumuse juurde kuuluvad dokumendid peavad olema vormistatud eesti keeles. Kõik muukeelsed dokumendid, kui neid on, peavad olema tõlgitud eesti keelde, kusjuures tõlge peab vahetult järgnema originaalile. Erandiks on ingliskeelsed reklaamialased trükised, mis võivad olla esitatud inglise keeles. 4.5. Pakkumus peab olema esitatud .pdf formaadis digitaalselt allkirjastatuna pakkuja seadusjärgse või volitatud esindaja poolt. 4.6. Pakkuja võtab enda kanda pakkumuse ja pakkumuse tagasivõtmise teate hankijale edastamise kogu riski, kaasa arvatud vääramatu jõu toime võimalus. 4.7. Pakkumused tuleb esitada hanketeates märgitud tähtpäeval ja kellaajal elektroonselt riigihangete registri vahendusel: https://riigihanked.riik.ee. Pakkumuse esitamise tähtpäev ja kellaaeg märgitakse e-riigihangete keskkonnas hanke üldandmete lehele. 4.8. Juhul kui pakkumuse digiallkirjastamine ei ole võimalik (nt piiriülesed pakkujad) või pakkumuse koosseisus on originaaldokumente, mida ei ole võimalik esitada elektroonilisel kujul, esitatakse käsitsi allkirjastatud dokumendid skaneeritud koopiatena e-riigihangete keskkonnas. 4.9. Pakkuja võib pakkumuse tagasi võtta enne pakkumuste esitamise tähtpäeva, esitades hankijale pakkumusega samas vormis sellekohase teate läbi e-riigihangete keskkonna. 4.10. Küsimused riigihanke alusdokumentide kohta tuleb esitada riigihangete registri kaudu. Küsimuste esitamiseks peab pakkuja end riigihanke juurde registreerima. Hankija ei vastuta nimetatud riigihangete registri ja sidevahendite tehnilise toimimise eest. 4.11. Hankija vastab riigihanke alusdokumentidega seotud selgitustaotlustele kolme tööpäeva jooksul asjakohase selgitustaotluse saamisest arvates. Hankija ei ole kohustatud riigihanke alusdokumentidega seotud selgitustaotlusele vastama, kui selgitustaotluse hankijale laekumise ja pakkumuse esitamise tähtaja vahele jääb vähem kui kaks tööpäeva (RHS § 46 lg 2). 4.12. Pakkuja märgib pakkumuses selgelt eristataval viisil, milline teave on Pakkuja ärisaladus ning põhjendab ärisaladuseks määramist. Ärisaladusena ei ole lubatud märkida pakkumuse maksumust, osamaksumusi ega muid pakkumuste hindamiskriteeriumidele vastavaid pakkumust iseloomustavaid numbrilisi näitajaid (RHS § 461). Hankija juhib tähelepanu, et eduka Pakkuja pakkumus on avalik lähtuvalt RHS § 110 lg 5, välja arvatud Pakkuja poolt õigustatult ärisaladuseks määratletud osas. Juhul, kui Pakkuja ei määratle pakkumuses arusaadavalt ärisaladust või ei põhjenda asjakohaselt, miks on tegemist ärisaladusega, on Hankijal kohustus teabenõude laekudes pakkumus täies ulatuses avalikustada. 5. PAKKUMUSE KOOSSEIS 5.1. Pakkuja esitab koos pakkumusega ajakohastatud kinnitusi sisaldava hankepassi esialgse tõendina pakkuja suhtes kõrvaldamise aluste puudumise ning tema kvalifitseerimise tingimustele vastamise kohta. Pakkumuses tuleb esitada: 5.2. Pakkumuse maksumus, mis esitatakse riigihangete registri maksumuse vormil; 5.3. Töö teostamise kestus kalendripäevades, mis esitatakse riigihangete registri maksumuse vormil ; 5.4. Vajadusel volikirjad, sh: 5.4.1. Juhul kui käesoleva dokumendi allkirjastab isik, kes tegutseb volikirja alusel, tuleb lisada pakkumusele ka vastav seadusliku esindaja poolt allkirjastatud volikiri; 5.4.2. Ühispakkujad peavad esitama volikirja, kus nimetavad riigihankega ning hankelepingu sõlmimise ja täitmisega seotud toimingute tegemiseks endi seast volitatud esindaja; 5.5. Ühispakkumuse korral esitavad ühispakkujad kinnituse, et vastutavad Hankija ees hankelepingu täitmise eest solidaarselt; 5.6. Kui pakkumus sisaldab ärisaladust, tuleb pakkumusele lisada ärisaladuse teave (HD Lisas 3 esitatud vormil); 5.7. Muud kinnitused ja materjalid (vajadusel tõlked), mida pakkuja soovib pakkumusele lisada. 6. PAKKUMUSE MAKSUMUS 6.1. Pakkumuse maksumus peab olema esitatud eurodes ilma käibemaksuta. 6.2. Pakkumuse eeldatav maksumus ilma käibemaksuta ei ületa 59 999 eurot. 6.3. Pakkumuse maksumus peab sisaldama kõiki töö läbiviimiseks, esitlemiseks ja üle andmiseks (sh ettevalmistamine, läbiviimine, analüüs, intervjuud, töötoad, tõlkimine, lähetused, tulemuste üleandmine ja esitlemine, kasutatava tarkvara litsentsid jms) vajalikke kulusid, maksusid ja makseid. Hankija maksab hankelepingu täitmise käigus Töö teostajale vastavalt riigihanke alusdokumentides määratud etappidele (pärast vastavas etapis teostatud töö vastuvõtmist) ning täiendavaid makseid ei tee. 7. KÕIKIDE PAKKUMUSTE T AGASILÜKKAMINE 7.1. Hankija võib teha põhjendatud kirjaliku otsuse kõigi pakkumuste tagasilükkamise kohta, kui: 7.1.1. kõigi vastavaks tunnistatud pakkumuste maksumused ületavad punktis 6.2 nimetatud eeldatavat maksumust;  7.1.2. hankemenetluse läbiviimise ajal on hankijale saanud teatavaks uued asjaolud, mis välistavad või muudavad hankijale ebaotstarbekaks hankemenetluse lõpule viimise riigihanke alusdokumentides sätestatud tingimustel. 7.2. Hankija ei kanna vastutust pakkuja ees, kui kõigi pakkumuste tagasilükkamine on toimunud käesolevas dokumendis sätestatud tingimustel. 8. PAKKUMUSTE VASTAVUSE KONTROLLIMINE 8.1. Hankija kontrollib pakkumuse vastavust RHS §-s 114 sätestatud korras. 8.2. Pakkumus peab vastama kõikidele riigihanke alusdokumentides esitatud tingimustele ja sisaldama käesoleva dokumendi punktides 5 ja 6 nõutud informatsiooni. 8.3. Hankija lükkab pakkumuse tagasi, kui see ei vasta riigihanke alusdokumentides esitatud tingimustele. 8.4. Hankija võib tunnistada pakkumuse vastavaks, kui selles ei esine sisulisi kõrvalekaldeid riigihanke alusdokumentides esitatud tingimustest. 8.5. Hankija teeb otsuse Pakkuja kõrvaldamise või kõrvaldamata jätmise, ja kvalifitseerimise või kvalifitseerimata jätmise kohta hankepassis esitatud teabe alusel. 8.6. Enne hankelepingu sõlmimist nõuab Hankija edukalt pakkujalt kõikide asjakohaste hankepassis esitatud kinnitustele vastavate dokumentide esitamist. Pärast pakkumuse edukaks tunnistamise otsuse tegemist kontrollib Hankija edukal pakkujal kõrvaldamise aluste puudumist ja esitatud kvalifitseerimise tingimustele vastamist ning teeb otsuse eduka pakkuja kõrvaldamise või kõrvaldamata jätmise, ja kvalifitseerimise või kvalifitseerimata jätmise kohta. 9. PAKKUMUSTE HINDAMINE JA HINDAMISKRITEERIU MID 9.1. Majanduslikult soodsaima pakkumuse väljaselgitamisel ei arvestata olelusringi kulusid, sest hanke objektiks olevad tööd ei tekita kulusid kolmandatele isikutele, kasutamisjärgseid kulusid ega keskkonnaalaste välismõjudega seonduvaid kindlaksmääratavaid ja rahaliselt mõõdetavaid kulusid. 9.2. Pakkumuste hindamisel selgitatakse majanduslikult soodsaim pakkumus välja hindamiskriteeriumite alusel: 9.2.1. I hindamiskriteerium - Pakkumuse maksumus käibemaksuta (osakaal 60%). Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal". 9.2.2. II hindamiskriteerium - Töö teostamise kestus kalendripäevades (osakaal 40%). Lühima töö teostamise kestusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "lühim töö teostamise kestus" / "töö teostamise kestus pakkumuses" * "osakaal". 9.3. Pakkumuse kriteeriumite (9.2.1 ja 9.2.2.) eest saadud punktid summeeritakse. 10. HANKELEPINGU TINGIMU SED 10.1. Pakkujaga sõlmitava lepingu projekt on HD Lisa 2; 10.2. Pakkumises esitatud töö teostamise kestus kalendripäevades on aluseks sõlmitava lepingu lõpptähtajale alates lepingu allkirjastamisest. LISAD HD Lisa 1 – Lähteülesanne HD Lisa 2 – Hankelepingu eritingimuste projekt HD Lisa 3 – Ärisaladuse teabe esitamise vorm HD Lisa 4 – Töö üleandmise ja vastuvõtmise akti vorm  HD Lisa 2 TÖÖVÕTULEPING nr {regNumber} ERITINGIMUSED Tallinn {regDateTime} Majandus- ja Kommunikatsiooniministeerium, registrikood 70003158, asukoht Suur-Ameerika 1, Tallinn 10122, mida esindab põhimääruse alusel kantsleri ülesannetes XXX (edaspidi tellija), ja XXX, registrikood XXX, asukoht XXX, mida esindab põhikirja alusel juhatuse liige XXX (edaspidi täitja), keda edaspidi nimetatakse üheskoos ka pooled ja eraldi pool, sõlmivad käesoleva töö teostamise lepingu (edaspidi leping) alljärgnevas: 1. Üldsätted 1.1. Lepingu moodustavad eri- ja üldtingimused koos lisadega kui konkreetsest lepingu sättest ei tulene teisiti. Eritingimused sisaldavad üldtingimuste täiendusi ja parandusi. 1.2. Lepingu dokumentide prioriteetsus on järgmine: eritingimused (I), lepingu lisad (II) ja üldtingimused (III). Vastuolude korral lepingu dokumentide vahel prevaleerib prioriteetsem dokument. 2. Lepingu ese, alus ja tähtaeg 2.1. Lepingu esemeks on tarkvara arendustöö vastavalt lisas 2 kirjeldatud nõuetele (edaspidi töö). Täitja kohustub töö teostama lepingus ja lepingu lisades 1 ning 2 sätestatud tingimustel. 2.2. Leping sõlmitakse Tellija korraldatud lihthanke „Võrgurajatiste andmebaasi ja selle kasutajaliidese viimine Ehitisregistri (EHR) arenduskeskkonnast EHR toodangukeskkonda“ (viitenr XXX) tulemusena ning vastavalt riigihanke alusdokumentidele ning täitja edukaks tunnistatud pakkumusele. 2.3. Töövõtja teostab punktis 2.1 nimetatud töö ja annab selle tulemused tellijale üle hiljemalt XXX. 3. Tasu suurus, väljamaksmise tähtaeg ja kord 3.1. Tellija tasub töövõtjale lepingus sätestatud töö teostamise eest tasu summas XXX eurot, summale lisandub käibemaks. Töö eest tasutakse ühes osas pärast poolte poolt töö üleandmise-vastuvõtmise akti allkirjastamist ja selle alusel esitatud arve saamist. 4. Garantiitingimused 4.1. Täitja garanteerib töö tulemuse vastavuse lepinguga sätestatud tingimustele 24 (kahekümne nelja) kuu jooksul pärast töö vastuvõtmist tellija poolt (edaspidi Garantiiperiood). Garantii kehtib ainult töö tulemusele ning ei laiene koos sellega kasutatavatele toodetele ja kolmanda isiku poolt tehtud töötlustele. 5. Poolte volitatud esindajad 5.1. Tellija volitatud esindaja lepingu tingimuste täitmisel, täitmise kontrollimisel ja töö tulemuste vastuvõtmisel on Meelis Raidmaa, telefon 625 6365, meelis.raidmaa @mkm.ee.  5.2. Täitja volitatud esindaja lepingu tingimuste täitmisel ja töö tulemuste üleandmisel on XXX, telefon XXX, XXX. 6. Lepingu lisad 6.1. Lepingu allakirjutamisel on lepingule lisatud: 6.1.1. Lisa 1 – Riigihanke alusdokumendid (leitavad riigihangete registris); 6.1.2. Lisa 2 – Lähteülesanne 6.1.3. Lisa 3 – Pakkumus 6.1.4. Lisa 4 – Töö üleandmise-vastuvõtmise akti vorm 7. Muud sätted 7.1. Täitja kinnitab, et on töövõtulepingu üldtingimustega tutvunud elektroonselt riigihangete registris või Majandus- ja Kommunikatsiooniministeeriumi veebis aadressil: https://www.mkm.ee/ministeerium-uudised-ja-kontakt/ministeerium-ja-ministrid/hanketeated 7.2. Täitja on teadlik, et leping on avalik, välja arvatud osades, mis on märgitud avaliku teabe seadusest tulenevatel alustel asutusesiseseks kasutamiseks. 7.3. Leping allkirjastatakse digitaalselt. Tellija: Täitja: Majandus- ja Kommunikatsiooniministeerium XXX XXX kantsleri ülesannetes juhatuse liige  HD Lisa 3 Ärisaladuse teabe esitamise vorm Avaldame, et riigihankele viitenumbriga XXX meie esitatud pakkumusest on ärisaladusega kaitstud järgmised dokumendid või teave: Jrk Dokumendi nimetus Põhjendus teabe (terviktekst või viide ärisaladuseks dokumendis sisalduvale määramisest teksti osale) 1. 2. 3. … … (vajadusel lisada ridasid) Oleme teadlikud, et: riigihangete seaduse § 461 lõige 1 kohaselt ei või pakkuja ärisaladusena märkida:  pakkumuse maksumust ega osamaksumusi;  teenuste hankelepingute puhul lisaks pakkumuse maksumusele ja osamaksumustele muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid numbrilisi näitajaid;  asjade hankelepingute puhul lisaks pakkumuse maksumusele ja osamaksumustele muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid näitajaid.  HD Lisa 4 Lepingu Lisa 4 „Töö üleandmise-vastuvõtmise akt“ (vorm) Majandus- ja Kommunikatsiooniministeeriumi ja XXX vahel sõlmitud Lepingu nr XXX juurde Töö üleandmise-vastuvõtmise akt Käesolev Töö üleandmise-vastuvõtmise akt (edaspidi akt) on koostatud XXX (edaspidi: Täitja) … poolt ja esitatud Majandus- ja Kommunikatsiooniministeeriumi Ehitisregistri talituse võrgurajatiste projektijuhile Meelis Raidmaa (edaspidi: Tellija), tõendamaks, et Täitja andis üle Poolte vahel XXX sõlmitud Lepingu „Võrgurajatiste andmebaasi ja selle kasutajaliidese viimine Ehitisregistri (EHR) arenduskeskkonnast EHR toodangukeskkond“ nr XXX alusel osutatud Töö alljärgnevalt: 1. … (üleantava Töö nimetus, detailne kirjeldus, mida üleantav Töö hõlmab, ajavahemik, maht, täidetud tingimused, vajadusel viited Lepingu punktidele vms). 2. Tellija on Töö osutamise tulemustega tutvunud ning kiidab Töö osutamise tulemused heaks, millega ühtlasi loetakse Täitja poolt üle antud Töö vastuvõetuks. Akt on aluseks Täitja poolt Tellijale kooskõlas Lepingu eritingimuste punktiga 3. ja üldtingimuste punktiga 2.4 ja 2.5. arve esitamiseks summas … (summa sõnades) eurot. Akt omab digitaalselt allkirjastatuna juriidilist jõudu ning edastatakse elektrooniliselt mõlemale Poolele. Täitja Tellija /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/  Käskkirja lisa 2 Pakkuja kõrvaldamise alused ja kvalifitseerimise tingimused 1. Kõrvaldamise alused 1.1. Hankija ei sõlmi hankelepingut ja kõrvaldab hankemenetlusest Pakkuja, kellel esineb RHS § 95 lõikes 1 nimetatud kõrvaldamise alus. 2. Tehniline ja kutsealane pädevus 2.1. Pakkuja peab olema riigihanke algamisele eelneva 36 kuu jooksul nõuetekohaselt täitnud vähemalt ühe Eesti Vabariigi ID kaardi põhise sisselogimise lahenduse, vähemalt ühe lahenduse, mis kasutab X-tee liidest, vähemalt ühe lahenduse, mis kasutab digitaalallkirjastamise funktsionaalsust ja vähemalt ühe riigi autentimisteenuse TARA põhise lahenduse või autentimisteenuse lahenduse Mobiil-ID-ga või Smart ID-ga. Täidetuks loetakse lepingud, mille täitmise tähtaeg on saabunud ning mille kohaselt teostatud tööd on tellijale üle antud ja tellija poolt vastu võetud. Pakkuja esitab teabe eelnimetatud lepingute maksumuse, kuupäevade ja teiste lepingupoolte kohta, samuti riigihanke viitenumbri juhul, kui on tegemist täidetud riigihanke lepinguga. Arvesse lähevad tellija poolt vastu võetud projektid, mille puhul ei tohi lepingu täitjale olla tellija poolt esitatud vaidlustamata leppetrahvi nõuet 2.2. Pakkuja esitab hankepassis teabe eelnimetatud lepingu(te) maksumuse, kuupäevade, töö nimetuse või sisu ja teiste lepingupoolte kohta, samuti riigihanke viitenumbri juhul, kui on tegemist täidetud riigihanke lepinguga. 3. Hankepass peab sisaldama 3.1 Pakkuja kinnitust, et ta ei vasta ühelegi RHS § 95 lõikes 1 sätestatud tingimusele. 3.2 Pakkuja kinnitust, et ta vastab Pakkuja kvalifitseerimiseks esitatud tingimusele, ja Hankija nõutud andmeid esitatud tingimusele vastamise kohta. 3.3 Märget selle kohta, milline ametiasutus või kolmas isik väljastab vajaduse korral Pakkuja kinnitustele vastavad andmed või dokumendid, ja Pakkuja kinnitust, et tal on võimalik vajaduse korral viivitamata need dokumendid Hankijale esitada. 3.4 Märget selle kohta, kas Pakkuja kinnitustele vastavad andmed või dokumendid on Hankijale elektroonilises andmekogus olevate avalike andmete põhjal tasuta kättesaadavad koos vastava veebilehe aadressi, identifitseerimisandmete ja vajaduse korral Pakkuja kinnitusega, et ta on nõus oma andmete väljastamisega. 3.5 Kui Pakkuja soovib tõendada enda vastavust tehnilisele ja kutsealasele pädevusele esitatud nõuetele teiste ettevõtjate vahendite alusel, peab Pakkuja esitama hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. 3.6 Hankepass peab sisaldama kinnitust, et ettevõtjal, kelle vahenditele Pakkuja tugineb, ei esine ühtegi RHS § 95 lõikes 1 sätestatud kõrvaldamise alust ja ta vastab sellele kvalifitseerimiseks esitatud tingimusele, mille osas Pakkuja teise ettevõtja vahenditele tugineb, ning hankija nõutud andmeid esitatud tingimusele vastamise kohta. 3.7 Pakkuja (sh iga ühispakkumuses osaleja), kes on registreeritud väljaspool Eesti Vabariiki, esitab hankepassis kinnituse punktis 1 nimetatud asjaolude puudumise kohta. Edukas Pakkuja, kes on registreeritud väljaspool Eesti Vabariiki, esitab karistusregistri teate või eduka Pakkuja asukohariigi kohtu- või haldusorgani väljastatud samaväärse dokumendi. Edukas pakkuja esitab asukohariigi pädeva ametiasutuse tõendi RHS § 95 lõige 1 punktis 4 nimetatud asjaolu kohta. Kui eduka Pakkuja asukohariik ei väljasta nimetatud dokumente, võib edukas Pakkuja need asendada eduka Pakkuja või tema esindaja vande all antud tunnistuse või pädeva justiits- või haldusasutuse või notari või kutseala- või ametiliidu ees eduka Pakkuja asukohariigi õigusaktide kohaselt antud tunnistusega.