Pöördumine

Lisa 1 Tehniline kirjeldus 1. Mõisted ja lühendid Mõiste / Lühend Kirjeldus ADR Arhitektuuriline otsus (Architecture Decision Record) HashiCorp Consul – teenuste registri ja teenuse avastamise tarkvara; käesolevas Consul töös hinnatav alternatiiv Istiole Valmisoleku kriteeriumid (ingl k Definition of Done) – Tellija ja Täitja vahel kokku DoD lepitud tingimuste kogum, mille täitmisel loetakse töö edukalt lõpetatuks ja vastuvõetuks EBS Majandustarkvara Oracle E-Business Suite Ingl k Go/No-Go decision – projekti vaheetapi lõpus tehtav otsus, kas projekt on Edasimineku või järgmise etapi käivitamiseks valmis (edasi minna) või vajab parandusi enne peatamise otsus edasiliikumist (peatada) Lahknevusanalüüs, milles võrreldakse olemasolevat SKA infosüsteemi arhitektuuri GAP-analüüs tulevikuvisiooniga (TO-BE), et selgitada välja ja prioriseerida lahknevuste (GAP) likvideerimiseks vajalikud tööd Avatud lähtekoodiga (Apache License 2.0) teenuse võrgu ja teenuse avastamise Istio platvorm; käesolevas töös eelistatud tehnoloogiavalik Koormuse jaotamine Päringute jaotamine teenuse mitme eksemplari vahel (load balancing) Kubernetes (K8s) Konteineritöökoormuste orkestreerimise platvorm Vastastikune TLS (mutual TLS) – kahepoolne krüptograafiline autentimine mTLS teenuste vahel, mis annab igale teenusele tagatud identiteedi Valitud teenuste piiratud ulatusega kasutuselevõtt, mis valideerib pakutud Pilootkasutuselevõtt lähenemist praktikas enne täismahulist kasutuselevõttu SKA Sotsiaalkindlustusamet SKAIS1 Sotsiaalkaitse infosüsteem (vananenud platvormil) Sotsiaalkaitse infosüsteem uus rakendus (hõlmab Ametnikurakendust ja SKAIS2 Iseteenindust) Spring-põhiste rakenduste hajussüsteemi mustreid (sh teenuse avastamine ja Spring Cloud konfiguratsioon) toetav teek Muster ja mehhanism, mille abil teenused leiavad üksteise otspunktid keskse Teenuse avastamine registri kaudu, ilma et otspunkte tuleks igasse sõltuvasse teenusesse käsitsi (Service Discovery) konfigureerida Teenustevahelise suhtluse haldamise infrastruktuurikiht (turvalisus, Teenuse võrk marsruutimine, töökindlus ja jälgitavus), mis on teenuse avastamise loomulik (Service Mesh) edasiarendus 2. Ülevaade Sotsiaalkindlustusamet (SKA) kasutab ülesannete täitmiseks sotsiaalkaitse infosüsteemi, mis koosneb SKAIS1, EBS ja SKAIS2 rakendustest. Tegemist on infosüsteemiga, mida on arendatud hulk aastaid nii, et uute funktsionaalsuste loomise kõrval ei ole jätkunud ressurssi tehnoloogilise ajakohasuse tagamiseks. Süsteemis tekkinud oluliste kitsaskohtade leevendamiseks käivitati 2025. aastal SKA infosüsteemi arhitektuuri tulevikuvisiooni (TO-BE lahenduse) väljatöötamise projekt, mille käigus loodi arhitektuuri reeglistik, millele peavad vastama teostatavad arendused ning migreerimisplaan. Ühtlasi kaardistati probleemid ja eesmärgid, teostati GAP-analüüs, st võrreldi olemasolevat lahendust TO-BE arhitektuuriga, et selgitada välja ja prioriseerida GAP likvideerimiseks vajalikud tööd. Lisaks oli juba varasemast teada kitsaskohti (nt seotud teenustevahelise suhtlusega), mis vajavad lahendamist. Käesolev leping koondab SKAIS2 teenustevahelise suhtluse arhitektuuriliste tööde eeltööd, et tagada süsteemi operatiivne töökindlus ja skaleeritavus teenuste arvu kasvades. Selle lepingu tööde tulem võimaldab edasi minna laiaulatuslikuma teenuse avastamise kasutuselevõtu ja teenuse võrgu töödega. Käesoleva lepingu skoobis on teenuse avastamise arhitektuuri ja tehnoloogiavaliku kirjeldus (ADR-ide kujul) ning valitud teenustega pilootkasutuselevõtt, mis valideerib pakutud lähenemist praktikas (nii Kubernetese kui virtuaalmasinate keskkonnas) ja kalibreerib edasiste etappide töömahuhinnangud. 2.1. GAP 2.2. Teenuse avastamine (Service Discovery) SKAIS on välja arenenud monoliitsest infosüsteemist, kus teenustevahelist suhtlust praktiliselt ei olnud. Eraldiseisvate teenuste arvu kasvades hakati igale teenusele käsitsi sõltuvate teenuste otspunkte konfigureerima ja tänaseks on dubleeritud otspunktide konfiguratsioon kasvanud suureks. GAP 2.2 töö eesmärk on võtta kasutusele keskne teenuste register, mis võimaldab teenustel üksteist leida ilma otspunkte igasse teenusesse käsitsi konfigureerimata ja toimib nii Kuberneteses kui virtuaalmasinates, säilitades samal ajal selge arengutee kõikehõlmava teenuse võrgu suunas. GAP-analüüsi raames on koostatud teenuse avastamise arhitektuuriettepanek (vt lisainfo allpool), mis annab tervikpildi probleemist, peamistest riskidest, soovituslikust tehnoloogiavalikust ja edasisest arengusuunast. Ettepaneku peamised järeldused: 1. Dubleeritud ja käsitsi hooldatav otspunktide konfiguratsioon muudab süsteemi operatiivselt hapraks: see soodustab süsteemi tööd häirivaid inimlikke vigu, ei võimalda teenuseid skaleerida nii, et lisatud eksemplarid muutuksid sõltuvatele teenustele kättesaadavaks, ega paku keskset koormuse jaotamise võimalust. 2. Lahenduseks on keskne teenuste register, mis peab olema piisavalt paindlik, et pakkuda teenuse avastamise võimekust nii virtuaalmasinates kui Kuberneteses käivitatavatele teenustele. 3. Tehnoloogiavaliku puhul on praegu parim valik Istio, võimaliku alternatiivina HashiCorp Consul. Istio kasuks räägivad avatud ja tingimusteta litsents (Apache License 2.0), de facto standardi seisund teenuse avastamise ja teenuse võrgu pakkujana, tugi Spring-põhistele rakendustele väheste koodimuudatustega, iga teenuse krüptograafiliselt tagatud identiteet (mTLS ja asukohast sõltumatu adresseerimine) ning selge arengutee kõikehõlmava teenuse võrgu suunas. 4. Peamised puudused on oma olemuselt ajutised ja seotud Kubernetese ja virtuaalmasinate keskkondade ühildamisega: esialgne ülesseadmise keerukus, suurem esialgne õppimisvajadus, hilisema tehnoloogiavahetuse kulukus ja vajadus eraldi lahenduse järele kohalikus arenduskeskkonnas. Mida suuremas ulatuses SKAIS Kubernetese platvormile üle läheb, seda väiksemat mõju need puudused avaldavad. 5. Teenuse avastamise kasutuselevõtul peab säilima võimalus käivitada rakendusi ka ilma teenuse avastamise funktsionaalsuseta (oluline nii kohaliku arenduskeskkonna kui tagasiühilduvuse seisukohast). Teenuse registreerimist saab juhtida Spring Cloud parameetritega  (spring.cloud.discovery.enabled) ja klientide puhul saab kasutada varulahendust, mis pöördub otspunkti URL-i poole teenuse registrinime asemel. Käesoleva lepingu skoobist jäävad välja teenuse avastamise täismahuline kasutuselevõtt kõikidele SKAIS2 teenustele, täieliku teenuse võrgu funktsionaalsuse realiseerimine (täpsem marsruutimine, töökindlusmustrid ja kõikehõlmav teenustevaheliste päringute turvapoliitika) ning SKAIS2 üleminek Kubernetese platvormile. Need kuuluvad GAP 3.3 (Teenuse võrk) ja GAP 3.1 (Kubernetes) skoopi ning tellitakse eraldi lepingutega käesoleva lepingu väljundite alusel. 2.2. Sõltuvus paralleelsete GAP-töödega GAP 2.2 on eeltingimuseks GAP 3.3 (Teenuse võrk / Service Mesh) tööde sisukokkuleppele: SKAIS Arhitektuur TO-BE lehel on GAP 3.3 sõnastatud nii, et see tugineb GAP 2.2 raames loodud teenuse avastamise võimekusele ja laiendab Istio kasutust kõikehõlmava teenuse võrgu mustriks. Käesoleva lepingu väljundid (kinnitatud ADR- id, pilootkasutuselevõtu tulemid ja edasimineku või peatamise otsus) on sisendiks GAP 3.3 ja teenuse avastamise täismahulise kasutuselevõtu kava koostamisele.  SKAIS Arhitektuur TO-BE, GAP 2.2 Teenuse avastamine (Service Discovery) arhitektuuriettepanek: o SKAIS2 wiki (https://wiki.sm.ee/spaces/SKAIS2/) → SKAIS Arhitektuur TO-BE → GAP analüüsist tulenevad tööd → GAP projektid → 2.2. Teenuse avastamine (Service Discovery)  Seotud GAP-projektid SKAIS Arhitektuur TO-BE lehel: o 3.3 Teenuse võrk (Service Mesh) (tugineb GAP 2.2 tulemitele) o 3.1 Kubernetes (Istio on Kubernetese-põhine tehnoloogia; teenuse avastamine peab toimima ka virtuaalmasinates) o 2.1 API lüüsi loomine (väline liiklus, erinevalt sisemisest teenustevahelisest avastamisest) o 3.2 Tarneprotsessi moderniseerimine (paigaldus ja konfiguratsioonihaldus) o 2.3 Jälgitavus (teenustevaheliste päringute seire) 3. Töö eesmärk Töö eesmärk on luua SKAIS2 teenuse avastamise kasutamise põhimõtted ja neid toetavad arhitektuurilised otsused (ADR-id), sh kinnitada keskse teenuste registri tehnoloogiavalik. Lähtudes GAP-analüüsi raames koostatud teenuse avastamise arhitektuuriettepanekust, valideeritakse loodud põhimõtteid valitud teenuste pilootkasutuselevõtu kaudu nii Kubernetese kui virtuaalmasinate keskkonnas. Töö tulemina esitatakse järgmiste tööde (GAP 3.3 ja teenuse avastamise täismahuline kasutuselevõtt) skoop ja sellest tulenev mahuhinnang. Pilootkasutuselevõtu lähtekood ja konfiguratsioon loovutatakse Tellijale tootmiskvaliteediga kujul. Tellija (TEHIK või Tellija valitud kolmanda osapoole partner) paigaldab need toodangusse omal valitud ajal ja viisil. 4. Tellitavad tööd Lepinguga tellitakse SKAIS2 teenuse avastamise kasutuselevõtu põhimõtted ja nende valideerimine valitud mikroteenustega vähemalt järgmises ulatuses:  Teenuse avastamise arhitektuuri ja tehnoloogiavaliku otsuste lukustamine ADR-idena, sh näiteks:  o keskse teenuste registri tehnoloogiavalik (Istio eelistatud, HashiCorp Consul alternatiivina) koos valiku põhjenduse ja hindamiskriteeriumidega; o teenuse avastamise toimimine hübriidkeskkonnas (Kubernetes ja virtuaalmasinad) ning sellega seotud halduslahendus; o teenuste krüptograafilise identiteedi (mTLS) ning teenusepõhise, asukohast sõltumatu adresseerimise mudel; o klientide adresseerimismudel ja varulahendus (teenuse registrinimi või otspunkti URL); o kohaliku arenduskeskkonna ja tagasiühilduvuse mudel (teenuse avastamise väljalülitatavus, spring.cloud.discovery.enabled); o koormuse jaotamise ning teenuse mitme eksemplari adresseerimise põhimõtted.  Keskse teenuste registri pilootkeskkonna ülesseadmine ja valitud SKAIS2 mikroteenuste liidestamine teenuse avastamisega. Teenused valitakse Tellija ja arhitektuuripartnerite ühisarutelu tulemusena selliselt, et kaetud oleks nii Kuberneteses kui virtuaalmasinas käivitatav teenus ja vähemalt üks tegelik teenustevaheline päring (kliendi ja teenuse vahel).  Olemasolevate teenuste väheste koodimuudatustega liidestamise valideerimine ning dubleeritud otspunktide konfiguratsiooni asendamine teenuse avastamisega piloodi ulatuses.  Kohaliku arenduskeskkonna lahendus, mis võimaldab rakendusi käivitada ka ilma teenuse avastamise funktsionaalsuseta (varulahendus), ning tagasipööramise strateegia teenuse avastamiselt senisele konfiguratsioonipõhisele adresseerimisele.  Taaskasutatav teenuse avastamisega liidestamise muster ja juhend (sh konfiguratsioon ja Helm- chartide muudatused), mis on aluseks järgnevatele teenuste liidestamise lainetele ja GAP 3.3 (Teenuse võrk) tööle.  Testimisstrateegia ja valmisoleku kriteeriumid (DoD) iga pilootteenuse jaoks, sh vastutuste jaotus testimisel, nõutavate automaattestide minimaalne kogum ja kvaliteedikriteeriumid piloodi vastuvõtuks.  Pilootkasutuselevõtu tulemuste tagastusring koos töömahu kalibreerimisega ning edasimineku või peatamise otsus järgmise faasi (täismahuline kasutuselevõtt ja GAP 3.3) käivitamiseks.  Muud arendusvajadused, mis selguvad analüüsi käigus ja on olulised realiseerida käesoleva lepingu skoobis.  Tööde loetelu tekib eelnevalt kokkulepitud backlogi alusel ja hallatakse Jiras. 5. Tööprotsess ja tulemid Järgnevalt täpsustatakse Täitjaga sõlmitud lepingus kirjeldatud tingimusi tööprotsessi, dokumenteerimise, töökorralduse, testimise ja mittefunktsionaalsete nõuete osas. 5.1. Tööprotsess  Tööraamistik peab tuginema etapiviisilisele planeerimisele, võimaldades arendusmeeskonna prioriteete jooksvalt muuta;  Tööraamistik peab võimaldama süsteemset ülevaadet iga kokkulepitud töö saavutustest;  Tööraamistik peab võimaldama arendusmeeskonna tulemuslikkuse (kasvu) jälgimist ajas;   Tööraamistik peab tagama, et arendusmeeskond tegeleb omal initsiatiivil enda tulemuslikkuse parandamisega ja parendusettepanekute esitamisega.  Täpsem protsess lepitakse kokku tööde käigus. 5.2. Dokumentatsioon Vastavalt tehnilise kirjelduse punktis 4 (tellitavad tööd) tuleb töö käigus luua ja täiendada SKAIS2 dokumentatsiooni, milleks on minimaalselt:  Funktsionaalsuse ja äriprotsesside kirjeldused kokkulepitud kujul (nt BPMN standard, diagrammid ja kirjeldused Confluence’is) koos ärireeglitega, mida peab olema hiljem võimalik täiendada järgnevates etappides lisanduva funktsionaalsuse alusel ning siduda tervikliku protsessi- ja ärireeglite kirjeldusega.  Tehniline dokumentatsioon (nt paigaldusjuhendid, Confluence keskkonnas).  Andmemudel.  Kasutusjuhendid.  Dokumentatsiooni täpsed liigid ja sisu formaat lepitakse kokku tööde käigus, kuid see peab vastama minimaalselt järgnevatele nõuetele: Nõuded arendusprojektide dokumentatsioonile SKAISi näitel - SKAIS2 - Sotsiaalministeeriumi wiki 5.3. Töökorraldus Projekti töökorraldus toetub raamlepingu kodukorrale (lisa 5) ja töökorralduslikele kokkulepetele. Täitja peab tagama piisava kaasamise ja ülevaadete andmise Tellijale. 5.4. Tööde üleandmine Arendustööde lähtekoodi tarne toimub pideva integreerimise (continuous integration) teel. Tööde järjekord, üleandmise aeg ja UAT tagasiside andmise aeg lepitakse kokku tööde käigus taasesitamist võimaldavas vormis (tellija ja täitja poolt). Töö üleandmisel kontrollib tellija üle töö nõuetekohasuse ning annab vajadusel tähtaja töö parandamiseks. Täitja teab, et tellija võib igat üle antud funktsionaalsust paigaldada toodangusse ning täitja peab tagama, et lõplikult valmimata funktsiooni protsessid on võimalik toodangust välja lülitada (feature flags). Funktsioonide sisse-välja lülitamise võimekus lepitakse tellija ja täitja vahel kokku tööde käigus. 5.5. Nõuded automaattestimisele Automaattestimise nõuete täitmisel tuleb lähtuda nõuetest, mis on leitavad siit: Automaattestide nõuded. Testidega kaetakse serveripoolne ja kasutajaliidese kood. Kaetavuse kontrolliks ja raporteerimiseks seatakse tellija koodihoidla keskkonnas (Gitlab) üles pideva integratsiooni töövoog, mis seadistatakse koostoimima SonarQube koodi ja testide kaetavuse analüsaatoriga. Automaattestid peavad üle antavas lähtekoodis continuous-integration’i töövoo edukalt läbima. Samuti peab täitja hoolt kandma, et varasemalt loodud testid jäävad töö lõpetamisel edukalt läbitavaks. Nõuete muutumisel peab täitja viima testid vastavusse uute nõuetega või neid eemaldama, kui selliseid nõudeid enam ei eksisteeri. Teenuse avastamisega liidestatud pilootteenus peab edukalt läbima ka olemasolevad süsteemiülesed regressiooni- ja suitsutestid, tõendamaks, et üleminek teenuse avastamisele ei ole rikkunud teenuse väliseid API-lepinguid ega teenuste vahelist suhtlust. 5.6. Koormustestimised Iseteenindus peab toetama paralleelset minimaalselt 200 päringut (siinkohal on oodatav arendajapoolne hinnang, kas see on piisav päringute maht, vajadusel tõsta arvu). API teenustele ning keskmine päringu teenindamise aeg ei tohi olla suurem kui 2 sekundit. Nõude täitmise kontrolliks tuleb luua koormustestid. Koormustestide tegemine lepitakse tellija ja täitja poolt kokku tööde käigus. Nõudest eraldi tuleb vaadelda staatiliste failide allalaadimist – need tuleb http serveris puhverdada. 5.7. Mittefunktsionaalsed nõuded Mittefunktsionaalsete nõuete täitmisel tuleb lähtuda järgnevast:  Uue funktsionaalsuse loomisel tuleb lähtuda raamlepingu (nr 3-9/3443-1) ja selle lisades kirjeldatud nõuetest  Täpsemad mittefunktsionaalsed nõuded, millest lähtuda on leitavad siit: Mittefunktsionaalsed nõuded 5.8. Tulemid Valminud ja üleantavate tööde tulemid peavad sisaldama:  Teenuse avastamise arhitektuuri ja tehnoloogiavaliku ADR-e (sh Istio ja Consuli vahelise valiku põhjendus);  Pilootkasutuselevõtu käigus tuvastatud täiendavate otsustuskohtade kaardistust;  Keskse teenuste registri pilootkeskkonna konfiguratsiooni ning pilootteenuste teenuse avastamisega liidestatud tootmiskvaliteediga lähtekoodi ja konfiguratsiooni (sh Helm-chartide muudatused);  Taaskasutatavat teenuse avastamisega liidestamise mustrit ja juhendit (sh kohalik arenduskeskkond ja varulahendus);  Töömahu kalibratsioonidokumenti ja tagastusringi protokolli koos edasimineku või peatamise otsusega;  Viiteid dokumentatsioonile Confluence’is;  Viiteid tehtud töödele (Jira piletitena);  Viiteid koodile GitLabis; 5.9. Tööde teostamise tähtaeg Tööde üleandmise (so Jira piletid "Ready for AT" ja toodangu keskkonda paigaldatav kvaliteetne lähtekood) tähtaeg on 30.09.2026. Tööde üleandmisele järgneb tellija poolne tööde testimine mõistliku aja jooksul ja vajadusel täitja poolne paranduste või täienduste tegemine, kui tööd ei ole tähtajaks teostatud nõuetekohaselt või tellijal tekib vajadus väiksemamahuliste täienduste koheseks realiseerimiseks. Tööd loetakse teostatuks tööde üleandmise-vastuvõtmise akti tellija poolt allkirjastamise hetkest. Tellijal on õigus pikendada tööde üleandmise tähtaega, kui ilmneb tööde ajakavas täitjast sõltumatuid olulisi viivitusi. HANKIJA NIMI: Tervise ja Heaolu Infosüsteemide Keskus Pakkumusettepaneku nimetus: „SKAIS2 GAP 2.2 Teenuse avastamine“ Käesolevaga teeb Tervise ja Heaolu Infosüsteemide Keskus (Hankija) Teile ettepaneku esitada pakkumus „SKAIS2 GAP 2.2 Teenuse avastamine“ teostamiseks raamlepingu nr 3-9/4283-1 alusel. Hankija soovib hankelepingu sõlmida ühe partneriga. Pakkumuse esitamise tähtaeg on 26.06.2026 kell 12:00. Pakkumus saata e-posti aadressile [email protected]. Pakkumus tuleb esitada eesti keeles ja digitaalselt allkirjastatuna. Pakkumus esitatakse Hankelepingu tehnilises kirjelduses (lisa 1) toodud tööde teostamiseks. Alternatiivsete pakkumuste esitamine ei ole lubatav. Pakkumus peab olema jõus minimaalselt 30 päeva. Pakkumusena tuleb esitada: - Tööde teostamiseks planeeritud meeskonnaliikmed isikuliselt, tuues välja ka meeskonnaliikmete roll; - Tööde teostamise ühe töötunni hind (ilma käibemaksuta). Töid teostatakse jooksva tunnihinna arvestuse põhiselt. Tööde ajaaruandes tuuakse välja tööde teostamiseks kulunud töötunnid isikute lõikes, seostades nimetatud isikud Jiras logitud tööülesannete ja kirjeldatud tegevustega. Töid tellitakse mahus kuni 110 000 (sadakümme tuhat) eurot (ilma km-ta). Pakkumuse esitamisega kinnitab pakkuja, et lepingu tähtaja saabumiseks on teostatud Hankelepingu eseme tehnilises kirjelduse (lisas 1) punktis 4 kirjeldatud tööd. Pakkujal ei ole õigust tööde teostamiseks nõuda ajapikendust, täiendavat tasu või väljamakseid. Küsimuste tekkimise korral palun võtke ühendust enne pakkumuse esitamise tähtaega aadressil [email protected]. Pakkumusettepanekuga koos edastatavad dokumendid: Lisa 1. Hankelepingu eseme tehniline kirjeldus; Lisa 2. Hankelepingu projekt. Hankelepingu projekt Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija), registrikood 70009770, aadress Pärnu mnt 132, 11317 Tallinn, keda esindab põhimääruse alusel direktor Margus Arm ja _____ (edaspidi täitja), registrikood_______., aadress ________, keda esindab põhikirja alusel _____, edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr ____ alusel käesoleva hankelepingu (edaspidi leping) alljärgnevas: 1. Lepingu ese 1.1. Lepingu esemeks „SKAIS2 GAP 2.2 Teenuse avastamine“ on tehnilises kirjelduses nimetatud tööd (edaspidi tööd). 1.2. Lepingu tööde maht on kuni 110 000 (sadakümme tuhat) eurot ilma käibemaksuta. 2. Töö üleandmise ja vastuvõtmise tingimused 2.1. Täitja annab töö üle 30.09.2026. 2.2. Töötunni põhise lepingu korral esitab täitja eelmise kuu töötundide ajaaruande, mis sisaldab teostatud töötunde ja nende jooksul teostatud töid. Ajaaruanne esitatakse allkirjastatult hiljemalt järgmise kalendrikuu 5. tööpäeval. Viimane ajaaruanne esitatakse koos aktiga. 2.3. Tellitavad tööd antakse vastuvõtutestimiseks üle vastavalt lepingu tehnilises kirjelduses kokkulepitud tingimustele. 2.4. Tellija vaatab töö üle vastavalt raamlepingu tingimustele. 2.5. Koos üle antava tööga annab täitja tellijale üle kõik tööde intellektuaalse omandi õigused vastavalt raamlepingus kirjeldatule. 3. Lepingu hind Kui tegemist on töötunnipõhise lepinguga: 3.1. Lepingu täitmine toimub töötunnipõhisel arvestusel, tellija tasub üksnes lepingu alusel tellitud ja teostatud töötundide eest. 3.2. Ühe töötunni maksumuseks lepingu täitmisel on ____ (maksumus sõnadega) eurot käibemaksuta. 4. Poolte vahelised teated ja kontaktisikud 4.1. Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist. 4.2. Tellija kontaktisikuks lepingu täitmisel on Ranel Tasane tel 56252707, e-post [email protected] või tema asendaja. 4.3. Täitja kontaktisikuks lepingu täitmisel on ________, tel ________, e-post ______ või tema asendaja. 5. Lõppsätted 5.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja kehtib kuni poolte poolt oma lepinguliste kohustuste täitmiseni. 5.2. Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu muudatustest ja pakkumusest. 5.3. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid, mida ei allkirjastata koos lepinguga: 5.3.1. Lisa 1 - Tehniline kirjeldus; 5.3.2. Lisa 2 – Pakkumus; 6. Poolte allkirjad Tellija: Täitja: