Väljaminev kiri

Lisa 1. HANKELEPINGU projekt

Poolte andmed

Tellija Siseministeeriumi infotehnoloogia- ja arenduskeskus

Registrikood 70008440

Aadress Mäealuse 2/2, 12618 Tallinn, Eesti Vabariik

Tellija esindaja

Esinduse alus Põhimäärus/volikiri

Kontaktisikud 1. Kata-Liina Normak, tiimijuht, e-post [email protected],

telefon 552 5441 või tema asendaja;

2. Kaija Kirch, juhataja, e-post [email protected], telefon 523 5457

või tema asendaja

Maksja Politsei- ja piirivalveamet

Registrikood 70008747

Aadress Pärnu mnt 139, 15060, Tallinn, Eesti Vabariik

Täitja esindaja

Esinduse alus Põhimäärus/volikiri

Kontaktisikud 1. Nimi, ametinimetus, e-post, telefon.

2.

Täitja OÜ/AS

Registrikood

Aadress

Täitja esindaja

Esinduse alus Põhikiri/volikiri

Kontaktisikud 1. Nimi, ametinimetus, e-post, telefon.

2. …

1. Lepingu sõlmimise alus 12.10.2023. a sõlmitud raamleping nr .3-3/3330 (riigihanke

viitenumber 264288) alusdokumendid, tellija … minikonkurss

(viitenumber 284780) ja täitja … pakkumus

2. Lepingu ese Rändeinfosüsteemi MTA ja TI liidestuse arendustööd.

3. Rahastamisallikas Kaasrahastanud Euroopa Liit, projekti „Siseministeeriumi

valdkondlik digipööre“ nr 2021-2027.1.02.23-0012 algatus:

RIS II etapp 2. osa RIS liidestus MTA ja Tiga (PPA poolne

osa)

4 Lepingu eseme täitmine 4.1 Hankelepinguga ostab tellija arendus- ja analüüsitöö tulemit, mis on kirjeldatud käesoleva

lepingu lisas 2.

4.2 Hankelepingu täitmise tähtaeg on 12 kuud alates töödega alustamisest. Kõigi etappide

(tehniline kirjeldus p. 2.1) täitmise tähtaeg on 12 kuud alates töödega alustamisest.

4.3 Hankelepingus kokku leppimata küsimustes lähtutakse raamlepingus ja SMIT

töövõtulepingu üldtingimustes sätestatust, vastuolude korral lähtutakse esmalt

hankelepingus sätestatust, siis raamlepingus sätestatust ning viimaks SMIT töövõtulepingu

üldtingimustes sätestatust.

4.4 Töid teostatakse täitja asukohas. Juhul, kui töid teostatakse täitja juures, kuid hankelepingu

täitmisel esinevad raskused, on tellijal õigus nõuda, et töid tehakse tellija asukohas.

4.5 Välisvahenditest rahastatava hankelepingu täitmisel alltöövõtulepinguga, mille summa

ületab 50 000 eurot, esitab täitja tellijale viivitamata iga oma alltöövõtja nime,

registrikoodi, alltöövõtulepingu nimetuse, kuupäeva, numbri ja summa.

5. Garantiitingimused

5.1.Garantiiaeg on üks aasta alates hetkest, mil tulem või töö on tellija poolt lepingu kohaselt

vastu võetud;

5.2.Täitja on kohustatud tagama garantiiajal tulemil või tööl ilmnenud puuduste tasuta

kõrvaldamise vastavalt vea prioriteetsusele järgnevalt:

5.2.1. Kui süsteem on töökeskkonnas kasutusel siis peab kriitilise vea parandama 1 tööpäeva

jooksul peale sellekohase teate edastamist tellija poolt täitjale. Kriitiliseks veaks

loetakse tarkvara arendusega seotud viga, mille tõttu: tarkvara tervikuna ei ole

võimalik kasutada; tarkvara põhifunktsionaalsus ei tööta või on oluliselt häiritud;

tarkvara lubab/teostab mitteautoriseeritud operatsioone; kahjustatud on süsteemis

olevad andmed; kasutajale või seotud infosüsteemidele/andmebaasidele väljastatakse

ebaõigeid andmeid/tulemusi. Kriitiliseks veaks loetakse sealhulgas ebamõistliku

sagedusega esinevad sarnased mittekriitilised vead;

5.2.2. Mittekriitilised vead 5 tööpäeva jooksul peale sellekohase teate edastamist tellija poolt

täitjale. Mittekriitiliseks veaks loetakse infosüsteemi toimehäiret, mis ei ole

põhjustatud riistvarast või muust tarkvarast või muust arendustööst ja mida ei saa

käsitleda kriitilise veana;

5.2.3. Veateade loetakse esitatuks, kui see on registreeritud tellija veahalduskeskkonnas ning

veahalduskeskkond on selle edastanud täitjale.

5.3.Täitja teostab garantiiaja vältel vajalikud tööd kasutades lepingukohast meeskonda.

5.4.Muud garantiikohased tingimused on sätestatud SMIT-i töövõtulepingu üldtingimustes.

6. Välisvahendite kasutamisest tulenevad nõuded

6.1.Välisvahendite kasutamise lõpptähtpäev on 31.08.2029.

6.2.Lähtuvalt rahastusallikast (välisvahendid) ning sellele kohalduvatest kohustuslikest

nõuetest, kohustuvad pooled tagama alljärgnevat:

6.2.1 Pooled on kohustatud järgima Vabariigi Valitsuse 12.05.2022 määruses nr 54

„Perioodi 2021–2027 ühtekuuluvus- ja siseturvalisuspoliitika fondide vahendite

andmisest avalikkuse teavitamine“ (https://www.riigiteataja.ee/akt/117052022012)

sätestatud teavitusreegleid ning esemete märgistamise ja dokumentide tähistamise

nõudeid ning kasutama selleks ettenähtud sümboolikat (vt määruse lisa 2).

6.2.2 Üleantav lepingu ese peab olema märgistatud ja tähistatud vastavalt Vabariigi

Valitsuse 12.05.2022 määruses nr 54 „Perioodi 2021–2027 ühtekuuluvus- ja

siseturvalisuspoliitika fondide vahendite andmisest avalikkuse teavitamine”

(https://www.riigiteataja.ee/akt/117052022012) toodud nõuetele kasutades selleks

ettenähtud sümboolikat (vt määruse lisa 2).

6.2.3 Majandus- ja kommunikatsiooni ministri 25.08.2023 nr 135 „Toetuse andmise

tingimused valdkondlike digipöörete toetamiseks“ punktis „10.1.4.. lisab võimalusel

töö teostaja logo või viite töö teostajale, kui töö tulemus on kasutajale nähtav“

7. Hankelepingu maksumus ja arveldamise kord

7.1.Hankelepingu kogumaksumus on … eurot, millele lisandub käibemaks.

7.2.Tööd antakse üle etappides, mis on toodud tehnilise kirjelduse punktis 2.1. Etappide 1, 2, 6,

7, 8 ja 9 üle andmisel makstakse iga etapi eest 5% lepingu summast, summas … eurot.

Etappide 3 ja 4 üle andmisel makstakse iga etapi eest 20% lepingu summast, summas …

eurot. Etapi 5 üle andmisel makstakse 30% lepingu summast, summas … eurot.

7.3.Täitja võib korraga üle anda ühe või mitu etappi. Üleandmise- vastuvõtmise aktis

fikseeritakse täitja poolt teostatud etapi või etappide tööd.

7.4.Tellijal on õigus esitada täitjale täiendavaid arupärimisi ning selgitusi kajastatud tööde

kohta. Peale üleandmis-vastuvõtmisakti allkirjastamist, esitab täitja maksjale lepingukohase

arve. Üleandmis-vastuvõtmis akti allkirjastamise õigus on hankelepingu kontaktisikul.

7.5.Arved tuleb edastada maksjale vastavalt Eesti e-arve standardile. E-arves peab lisaks

standardis nimetatud andmetele olema toodud tellija ja maksja kontaktisiku perekonnanimi,

raamhanke riigihangete registri viitenumber, raamlepingu number, minikonkursi

riigihangete registri viitenumber, hankelepingu number, hankelepingu riigihangete registri

15-kohaline viitenumber ja välisvahendite projekti toetuse kood 1S70-RF21-01212-RIS2

välisprojekti kood nr 2021-2027.1.02.23-0012. E- arve tuleb saata e-arvete operaatori

kaudu. E-arve loetakse laekunuks selle e-arvete operaatorile laekumise kuupäevast.

7.6.Arve maksetähtaeg 21 kalendripäeva.

8. Hankelepingu kehtivus

8.1. Hankeleping jõustub alates hetkest, kui pooled on hankelepingu allkirjastanud.

8.2. Hankeleping kehtib Poolte lepinguliste kohustuste täitmiseni.

9. Lepingu lisad

9.1.Lisa 1 – täitja pakkumus;

9.2.Lisa 2 – tehniline kirjeldus, sh lisad 2.1-2.5;

9.3.Lisa 3 – ….

Lepingu juurde kuuluvateks lahutamatuteks osadeks loetakse kõik lisad ja minikonkursi

alusdokumendid ning täitja riigihankes esitatud pakkumus ja pooltevahelised kirjalikud teated,

mida lisadena eraldi ei allkirjastata.

Leping on koostatud ja allkirjastatud digitaalselt.

Üleandmise-vastuvõtmise akti vorm

Alus (täida need read, mis kohalduvad):

Riigihanke viitenumber: …..

Raamleping nr…., sõlmitud …. a.,

Minikonkursi/tellimuse viitenumber:….,

Hankeleping nr …., sõlmitud …. a.,

Hankelepingu osa viitenumber (riigihangete registri 15-kohaline number) …..

Välisvahenditest rahastatud projekti nr ja nimetus: ….ja „….“

Käesolevaga annab ………….. (täitja ettevõtte nimi) üle ning ……… (tellija asutuse nimi)

võtab vastu (edaspidi lepingu ese):

1. …….. (täida lepingu esemest tulenev võimalikult detailne sisu: tulemi maksumus;

arendus- või hooldusteenuste teostamise periood; arendus- või hooldustööde töötundide

maht ja maksumus; tootekood, selle kirjeldus, kogus, seerianumber, ühik- ja

kogumaksumus);

(ressursi tellimisel):

Etapp periood Vastuvõetud töö hind km-ta töö hind kokku km-ta

KOKKU km-ta: KOKKU km-ga:

2. ………(dokumentide loetelu).

Üleantava lepingu eseme maksumus on ………………. eurot (lisandub käibemaks).

Lepingu jääk … (tuua välja siis, kui töid antakse üle etapiti/kuude kaupa).

………………. (täitja lepingujärgse kontaktisiku nimi) kinnitab, et lepingu ese on üle antud

tähtaegselt, vastavalt lepingus sätestatud tingimustele.

…………….. (tellija lepingujärgse kontaktisiku nimi) kinnitab, et vastuvõetud lepingu ese

vastab lepingus sätestatud tingimustele ning lepingu ese on üle antud ja vastuvõetud vastavalt

lepingus sätestatud tähtajale ja tingimustele.

Käesolev üleandmise-vastuvõtmise akt on allkirjastatud digitaalselt.

Täitja: Tellija:

………………… …………………..

/asutuse nimi/ /asutuse nimi/

………………….. …………………..

/allkirjastaja nimi/ /allkirjastaja nimi/

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

Siseministeeriumi infotehnoloogia- ja arenduskeskuse

TÖÖVÕTULEPINGUTE ÜLDTINGIMUSED

1. Üldsätted

1.1. Leping koosneb käesolevatest üldtingimustest (edaspidi üldtingimused) ja

eritingimustest (edaspidi eritingimused) ning nende lisadest.

1.2. Lepingu eesmärgiks on reguleerida tellija ja töövõtja (täitja) vahel lepingu alusel

tekkivaid õigussuhteid.

1.3. Lepingu täitmise keel on eesti keel, kui lepingus pole sätestatud teisiti.

1.4. Pooled on oma tegevuses iseseisvad ja kumbki pool ei vastuta teise poole poolt endale

kolmandate isikute ees võetud kohustuste täitmise eest.

1.5. Poolte õiguste ja kohustuste aluseks on Eesti Vabariigis kehtivad õigusaktid ja leping

koos selle juurde kuuluvate dokumentidega.

1.6. Pooled tagavad ja avaldavad, et lepingu sõlmimisega ei ole nad rikkunud ühegi enda

suhtes kehtiva seaduse, põhikirja või muu õigusakti sätet ega ühtki endale varem

sõlmitud lepingute ja kokkulepetega võetud kohustust.

1.7. Pooled kinnitavad ja tõendavad, et:

1.7.1. neil on seaduses ettenähtud piisav õigus- ja teovõime (füüsilisest isikust poole puhul)

lepingu sõlmimiseks ning lepingust tulenevate kohustuste täitmiseks ja õiguste

realiseerimiseks;

1.7.2. nende poolt lepingule ja selle lisadele allakirjutanud isikutele on antud piisavad

volitused selle lepingu sõlmimiseks kooskõlas põhikirjade, õigusaktide ja muude

asjakohaste dokumentidega.

1.8. Lepingu sõlmimisega kaotavad kehtivuse kõik pooltevahelised varasemad lepingud ja

muud kokkulepped niivõrd, kuivõrd need on vastuolus lepinguga.

2. Lepingu ese

Töövõtja poolt tehtavad tööd on määratletud lepinguga ja selle juurde kuuluvate

dokumentidega. Töövõtjale laieneb ka nende tööde ja toimingute, sh kõrvalkohustuste,

teostamise ning teenuste osutamise kohustus, mis ei ole lepingus sätestatud, kuid mis

oma olemusest lähtuvalt kuuluvad lepinguga seotud tööde hulka. Nimetatu ei kuulu

teistsuguse kokkuleppe puudumisel eraldi tasustamisele ning töövõtja teostab need

tööd, toimingud ja teenused lepingus fikseeritud tähtaja raames ja tasu eest.

3. Töövõtja kohustused

Töövõtja on kohustatud:

3.1. teostama töid omal kulul ja vastutusel hoolikalt, kvaliteetselt, tähtaegselt ning

professionaalsel tasemel kooskõlas lepingu, õigusaktide, oma tegevus- või kutsealal

kehtivate standardite ja heade kommetega ning andma need tellijale või tema poolt

osutatud isikutele üle kokkulepitud ajal ja korras. Juhul kui füüsilisest isikust

töövõtjaga sõlmitud lepingu esemeks olevaks tööks on teose loomine, eeldatakse, et

töövõtja loob selle isiklikult, välja arvatud juhul, kui pooled lepivad kokku teisiti.

Eelkirjeldatud juhul toimub kolmandate isikute kaasamine tööde teostamisele (teose

loomine) tellija eelneval kirjalikku taasesitamist võimaldavas vormis antud nõusolekul

ning tingimusel, et kaasatud isikutega sõlmitud kokkulepped ei lähe vastuollu

lepingutingimustega;

3.2. andma tellijale viimase poolt nõutavas vormis tööde teostamise kohta informatsiooni

ja arvestama tellija poolt tehtud ettepanekuid ning tegema koostööd tellija poolt

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

osutatavate isikutega;

3.3. viivitamatult, kuid mitte hiljem kui 2 (kahe) tööpäeva jooksul alates vastavate asjaolude

ilmnemisest, teatama tellijale kirjalikku taasesitamist võimaldavas vormis selliste

asjaolude ilmnemisest, millised takistavad töövõtja kohustuste kohast täitmist,

muuhulgas mõjutavad kvaliteedi saavutamist, maksumust või omavad lepingu

täitmisele muud ebasoodsat mõju. Seejuures ei anna eelnimetatud juhtumeil

informeerimiskohustuse täitmine töövõtjale ilma tellija vastavasisulise lepinguga

samas vormis antud nõusolekuta automaatselt õigust ületada tööde kogumaksumust,

teostamise tähtaegu, mitte kinni pidada lepinguga tööde suhtes kehtestatud

kvaliteedinõuetest vms;

3.4. tasuma omal kulul kõik lepingu täitmisega seotud autori- ja mistahes iseloomuga muud

tasud kolmandatele isikutele;

3.5. andma valminud tööd ja nendega seotud õigused ning koostatud dokumentatsiooni

tellijale üle. Samuti kohustub töövõtja andma tellijale üle andmed kolmandate isikute

intellektuaalse omandi õiguste kohta seoses töödega (nimi, funktsioon tööde

teostamisel, õiguste maht jms) ning koostama lepingu täitmisega seotud

dokumentatsiooni eesti keeles, kui tellija ei ole nõustunud muus keeles

dokumentatsiooni esitamisega. Tellija nõudmisel tagab töövõtja tõlke omal kulul;

3.6. järgima tellija juhiseid ning tellija asukoha ruumide kasutamise korda ja teisi

turvalisusega või ohutusega seotud nõudeid ja piiranguid, mida tellija on töövõtjale

tutvustanud enne lepingu täitmisele asumist või lepingu täitmise ajal;

3.7. tagama, et tema poolt kaasatud meeskonnaliige kasutab talle eraldatud elektroonilist

läbipääsukaarti isiklikult ning registreerib sellega oma liikumist tellija ruumides, kui

tellija on võimaldanud meeskonnaliikmele juurdepääsu tellija ruumidesse;

3.8. tagama, et töövõtja poolt kaasatud meeskonnaliige kasutab tellija poolt talle

kasutamiseks antud vara, seadmeid ja ligipääse infosüsteemidele üksnes isiklikult,

otstarbekohaselt ja heaperemehelikult, üksnes lepinguliste kohustuste kohaseks

täitmiseks ning tagama talle usaldatud vara kaitstuse ja säilimise. Töövõtja kannab

varalist vastutust tema meeskonnaliikme tahtliku või hooletu käitumise tõttu tellijale

tekitatud kahju eest;

3.9. Tellija poolt meeskonnaliikmele antud seamete ja ligipääsude kasutamisel ei ole

töövõtja poolt kaasatud meeskonnaliikmel õiguspärast ootust privaatsusele ning tellija

logib nende tegevusi seadmetes ja süsteemides;

3.10. täitma muid tööde teostamisega kaasnevaid ning lepingus ja õigusaktides sätestatud

kohustusi;

3.11. lepingu alusel ja selles sätestatud maksumuse eest teostama ka nn sidustöid, mis ei ole

lepingus sõnaselgelt sätestatud, kuid mille teostamine on headest tavadest ja töövõtja

ametialasest professionaalsusest lähtudes nõutavad ja/või vajalikud lepingust tuleneva

eesmärgi saavutamiseks. Käesolevas punktis kirjeldatud sidustööde all ei peeta silmas

tellijast tulenevat lähteülesande või töömahu muudatust.

4. Töövõtja õigused

Töövõtjal on õigus:

4.1. nõuda tellijalt lepingutingimustest kinnipidamist;

4.2. saada tellijalt tööde teostamise eest tasu lepingus sätestatud tingimustel ja korras;

4.3. teha tellijale ettepanekuid tööde teostamise osas, esitades selle kohta omapoolsed

põhjendused kirjalikku taasesitamist võimaldavas vormis, mille tellija vaatab läbi ja

teatab töövõtjale otsustusest ettepaneku arvestamise või arvestamata jätmise kohta;

4.4. nõuda tellijast sõltuvate õigusvastaste takistuste kõrvaldamist tööde teostamisel;

4.5. nõuda tööde teostamisega seotud koosolekute korraldamist, kui see on vältimatu tööde

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

normaalseks teostamiseks, tähtaegadest kinnipidamiseks ja kvaliteedi tagamiseks.

Tellija korraldab töövõtja eelkirjeldatud nõudmisel koosoleku 2 (kahe) tööpäeva

jooksul alates töövõtja vastavast kirjalikku taasesitamist võimaldavas vormis edastatud

nõudmisest.

4.6. teostada muid lepingus ja õigusaktides sätestatud õigusi.

5. Tellija kohustused

Tellija on kohustatud:

5.1. maksma töövõtjale tööde eest tasu lepingus sätestatud tingimustel ja korras;

5.2. looma töövõtjale tööde teostamiseks vajalikud tingimused vastavalt eritingimustes

sätestatule;

5.3. mitte tegema töövõtjale põhjendamatult takistusi tööde teostamisel;

5.4. vastu võtma töövõtja poolt nõuetekohaselt teostatud lepingujärgsed tööd;

5.5. osalema töödega seotud korralistel koosolekutel;

5.6. täitma muid lepingus ja õigusaktides sätestatud kohustusi.

6. Tellija õigused

Tellijal on õigus:

6.1. nõuda töövõtjalt lepingutingimustest kinnipidamist;

6.2. põhjendatult keelduda kooskõlastamast töövõtja poolt kooskõlastamiseks

esitatud ettepanekuid;

6.3. kutsuda kokku poolte koosolek, sellest töövõtjale võimalusel 2 (kaks) tööpäeva

kirjalikku taasesitamist võimaldavas vormis ette teatades;

6.4. lisaks seaduses sätestatud juhtudele pikendada poolte kokkuleppel lepingu täitmise või

kehtivuse tähtaega kuni kuue kuu võrra;

6.5. kaasata lepingu täitmisse tellija poolele (eelkõige maksja rollis) teisi riigiasutusi;

6.6. igal ajal kontrollida lepingu eseme vastavust lepingule ja nõuda töövõtjalt

informatsiooni lepingu täitmise kohta.

7. Lepingu maksumus

7.1. Lepingu maksumus sisaldab endas muuhulgas töövõtja poolt lepingu raames tehtavaid

kõiki kulutusi ja tasu lepingus sätestatud autoriõiguste eest (autori varaliste õiguste

loovutamine ja isiklike õiguste osas kasutusõiguse ehk litsentsi andmine), samuti kõiki

muid tööde teostamiseks tehtud kulutusi.

7.2. Tellija tasub töövõtjale nõuetekohaselt teostatud tööde eest vastavalt eritingimustes

sätestatule, kas peale poolte poolt tööde üleandmise-vastuvõtmise akti allkirjastamist

ning selle alusel esitatud arve saamist ja selle heakskiitmist või peale tööde teostamist

esitatud arve saamist või füüsilisest isikust töövõtja korral peale poolte poolt tööde

üleandmise- vastuvõtmise akti allkirjastamist.

7.3. Arve maksetähtaeg peab olema vähemalt 21 (kakskümmend üks) kalendripäeva arvates

selle kättesaamisest. Juhul kui lepingu maksumus tasutakse füüsilisest isikust

töövõtjale, makstakse lepingu täitmise eest hiljemalt 14. (neljateistkümnendal)

kalendripäeval pärast tööde üleandmise-vastuvõtmise akti allkirjastamist.

7.4. Kui töövõtja on Eestis registreeritud ettevõte, saadab töövõtja tellijale Eesti e-arve

standardile vastava e-arve e-arvete operaatori Fitek AS kaudu (täpsem info

http://www.fitek.ee/). Kui töövõtja ei ole Eestis registreeritud ettevõte saadab töövõtja

tellijale pdf formaadis e-posti aadressil [email protected]. E-arve loetakse laekunuks selle

Fitek AS-le laekumise kuupäevast.

7.5. Arvel peab lisaks standardis nimetatud andmetele olema toodud tellija kontaktisiku

perekonnanimi, riigihanke viitenumber (kui on asjakohane), hanke- ja raamlepingu

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

number (kui on asjakohane) ja tellimuse viitenumber (kui on asjakohane) ning

välisvahendite projekti tunnus (kui on tegemist välisvahenditest rahastatava

lepinguga).

7.6. Töövõtja poolt esitatav arve peab selgelt ja üheselt viitama lepingule. Käesolevas

punktis ja punktis 7.5 esitatud tingimustele mittevastav arve ei kuulu tasumisele. Arve

maksetähtaeg on kakskümmend üks kalendripäeva, v.a juhul, kui kohalduvate

välisvahendite tingimustest tuleneb ja on konkreetses lepingus sätestatud teisiti.

7.7. Juhul kui pooled on lepingus sätestanud lepingu maksimaalse maksumuse, käsitlevad

pooled nimetatud summat indikatiivsena, s.t. kui leping öeldakse kooskõlas lepingu

tingimustega üles või on tellija esitanud lepingu alusel tellimusi lepingu lõppemise

hetkeks väiksemas mahus kui on lepingu maksimaalne maksumus, ei kuulu

maksimaalse maksumuse ja tegeliku maksumuse vahe töövõtjale välja maksmisele ega

muul moel hüvitamisele.

7.8. Juhul kui tellijal on alus nõuda töövõtjalt leppetrahvi ja/või kahju hüvitamist, on tellijal

õigus leppetrahv ja/või kahjutasu maha arvata lepingu alusel töövõtjale tasumisele

kuuluvast summast.

7.9. Juhul kui tööd ei vasta lepingus toodud nõuetele, võib tellija lepingu maksumust

ühepoolselt alandada, teavitades sellest töövõtjat kirjalikku taasesitamist võimaldavas

vormis.

8. Tööde kvaliteet. Üleandmine ja vastuvõtt

8.1. Tehtud tööde kvaliteet peab vastama vähemalt lepingus toodud nõuetele ja antud

töödele tavapäraselt esitatavatele nõuetele. Nimetatud nõuetele peavad vastama ka

tööde juurde kuuluvad dokumendid jms.

8.2. Lepingu ese antakse töövõtja poolt tellijale üle tellija asukohas kooskõlas lepingu

tingimustega.

8.3. Tellijal on kümme tööpäeva aega kontrollida vastuvõtmiseks esitatud tööde

lepingutingimustele vastavust ning üleandmise-vastuvõtmise akti allkirjastamiseks.

Tellija võib nimetatud tähtaega pikendada, kui pikendamine on põhjendatud.

8.4. Kui lepingu eseme vastuvõtmine toimub arve heakskiitmise teel, tuleb see sätestada

lepingu eritingimustes, tellimuses või pakkumise esitamise ettepanekus.

8.5. Juhul kui tellija ei ole punktis 8.3 nimetatud tähtaja jooksul üleandmise-vastuvõtmise

akti allkirjastanud ega teatanud tähtaja pikendamisest, loetakse lepingu ese

vastuvõetuks ning vastuvõtmise hetkeks punktis 8.3 sätestatud tähtaja möödumisele

järgnevat kalendripäeva. Käesolevas punktis sätestatu ei kuulu kohaldamisele juhul,

kui leping ei ole täielikult rahastatud riigieelarvest (välisvahendite kasutamisel).

8.6. Juhul kui tellija avastab vastuvõtmiseks esitatud lepingu esemes vigu, puudusi või muu

lepingutingimustele mittevastavuse, on töövõtja lepingu rikkumises ning rikkumise

kõrvaldamine toimub tellija sellekohaste juhiste alusel.

8.7. Tellijal on õigus puudustega lepingu eseme vastuvõtmisest keelduda näidates ära

keeldumise põhjused või võtta puudustega lepingu ese vastu, lisades puuduste või

vaegtööde nimekirja koos puuduste kõrvaldamise tähtajaga üleandmise-vastuvõtmise

akti. Akti allkirjastamisega kinnitab töövõtja, et on teadlik aktis märgitud puuduste

kõrvaldamise ja vaegtööde teostamise tähtaegadest ning võtab kohustuse nendest

tähtaegadest kinni pidada. Kõrvaldatud puuduste kohta vormistatakse eraldi

üleandmis-vastuvõtmise akt.

8.8. Kui tellijal puuduvad lepingu eseme osas pretensioonid, allkirjastavad pooled lepingu

eseme üleandmise-vastuvõtmise akti.

8.9. Töövõtja annab tellijale koos üleandmise-vastuvõtmise aktiga üle lepingu eseme juurde

kuuluva tehnilise ja muu lepingu eseme kasutamiseks ja haldamiseks vajaliku

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

dokumentatsiooni tellija soovi kohaselt kas paberil ja/või elektroonilisel andmekandjal

(CD/DVD vms) ja/või e-posti teel või paigaldab selle tellija näidatud keskkonda.

8.10. Juhul kui lepingu esemeks on arendustööde tulem ning arendustööde üleandmiseks ei

ole üleandmise-vastuvõtmise akti allkirjastatud ja ei kohaldu punkt 8.5, loetakse

arendustööde vastuvõtmise ajaks päeva, mil tellija on töö tulemi tervikuna

toodangukeskkonnas (live) kasutusele võtnud. Käesolevas punktis sätestatu ei kuulu

kohaldamisele juhul, kui leping ei ole täielikult rahastatud riigieelarvest (välisvahendite

kasutamisel).

8.11. Tellija poolt lepingu eseme vastuvõtmine ei vabasta töövõtjat vastutusest lepingu

eseme üleandmisel-vastuvõtmisel avastamata jäänud vigade või nende

mittenõuetekohasuse eest ning töövõtja kohustub lepingu eseme üleandmise hetkel

esinenud vastavad vead või puudused kõrvaldama omal kulul mõistliku aja jooksul.

8.12. Kui töövõtja ei nõustu tellija poolt lepingu eseme vastuvõtmisest keeldumisel või

puudustega või vigadega vastuvõtmisel tuvastatud vigade või puuduste olemasoluga,

on töövõtjal õigus nõuda ekspertiisi teostamist. Sel juhul tellib töövõtja tellija poolt

osundatud lepingu eseme puuduste või vigade tuvastamiseks tellijaga kokku lepitud

isikult ekspertiisi. Kui ekspertiisi tulemusel ilmneb, et tööde vastuvõtmisest

keeldumine on olnud põhjendamatu, hüvitab tellija töövõtjale ekspertiisikulud, vastasel

korral kannab ekspertiisikulud töövõtja. Kui ekspertiisi tulemusel ilmneb, et tellija

osundatud lepingu eseme puudused või vead olid osaliselt põhjendatud, hüvitab tellija

töövõtjale ekspertiisikulud proportsionaalselt üksnes nende puuduste või vigade osas

ekspertiisi kogukuludest, mille puudumist ekspertiis on tuvastanud.

9. Poolte vastutus. Vääramatu jõud

9.1. Töövõtja vastutus:

9.1.1. Töövõtja vastutab igasuguse lepingurikkumise eest, eelkõige kui tööd ei vasta

lepingus ja selle lisades kokkulepitud nõuetele. Tööd loetakse muuhulgas

mittevastavaks juhul, kui töövõtja ei esita tööde üleandmisel-vastuvõtmisel tööde

kohta nõuetekohast dokumentatsiooni, ei anna töid tähtaegselt üle, ei teosta töid

nõuetekohaselt, jätab tellijale lepingu täitmise kohta informatsiooni esitamata vms.

9.1.2. Juhul kui töövõtja rikub lepingust tulenevat kohustust, mille heastamine ei ole

võimalik, on tellijal õigus nõuda töövõtjalt leppetrahvi 5% (viis protsenti) lepingu

maksumusest iga rikkumise eest. Juhul kui tegemist on olulise lepingurikkumisega,

on tellijal lisaks leppetrahvinõudele õigus ka leping erakorraliselt ühepoolselt

lõpetada.

9.1.3. Juhul kui töövõtja rikub lepingust tulenevat kohustust, mille heastamine on võimalik,

on tellijal õigus esitada töövõtjale nõue rikkumiste kõrvaldamiseks (edaspidi ka

„ettekirjutus“), andes töövõtjale rikkumise kõrvaldamiseks mõistliku tähtaja

(sõltuvalt tööde iseloomust, rikkumise asjaoludest jms, kuid üldjuhul mitte rohkem

kui 5 (viis) tööpäeva). Kui töövõtja ei täida ettekirjutust selleks antud tähtaja jooksul,

peab töövõtja maksma tellijale leppetrahvi 0,5% (null koma viis protsenti) lepingu

maksumusest iga rikkumise kõrvaldamisega viivitatud päeva eest, välja arvatud

punktis 9.1.4 sätestatud juhtudel, mil kohaldatakse nimetatud punktis sätestatud

leppetrahvimäära. Samuti annab töövõtja poolt rikkumise kõrvaldamisega

viivitamine vaatamata tellija poolt ettekirjutuse tegemisele tellijale õiguse leping

erakorraliselt ühepoolselt lõpetada. Juhul kui tegemist on olulise rikkumisega, ei pea

tellija töövõtjale rikkumise kõrvaldamiseks täiendavat tähtaega andma ning võib

lepingu olulise rikkumise esinemisel erakorraliselt ühepoolselt lõpetada.

9.1.4. Juhul kui töövõtja viivitab tööde teostamise või üleandmisega üle lepingus kokku

lepitud tähtpäevade, on tellijal õigus nõuda töövõtjalt leppetrahvi, mille suuruseks on

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

1% (üks protsent) teostamata või üle andmata töö maksumusest iga viivitatud päeva

eest.

9.1.5. Töövõtja kohustub hüvitama kõik kulud ja kahjud, mis tekivad tellijale seoses

töövõtja poolt teostatud töödes esinevate puudustega.

9.1.6. Punktist 12 tulenevate kohustuste mittejärgimise korral on tegemist olulise

lepingurikkumisega ning tellijal on õigus leping erakorraliselt ühepoolselt lõpetada

ja/või nõuda leppetrahvi 5% (viis protsenti) lepingu maksumusest iga rikkumise eest.

Antud punkti alusel lepingu lõpetamisel tasub tellija töövõtjale tehtud tööde eest

üksnes juhul, kui tellijal on huvi lepingu osalise täitmise vastu.

9.1.7. Lepingu erakorraline ühepoolne lõpetamine ei võta tellijalt õigust nõuda töövõtjalt

leppetrahvi ja kahju hüvitamist. Juhul kui ühe ja sama rikkumise eest võimaldab

leping nõuda leppetrahvi mitme sätte alusel, on tellijal õigus otsustada, millise sätte

alusel ta leppetrahvi nõuab.

9.1.8. Tellijal on õigus tööde eest tasumisel vähendada lepingu maksumust leppetrahvi

summa võrra. Lepingus sätestatud leppetrahvid on kokku lepitud kohustuste

täitmisele sundimiseks ning leppetrahvi nõudmine ei mõjuta tellija õigust nõuda

töövõtjalt täiendavalt ka kohustuse täitmist ja kahju hüvitamist.

9.2. Tellija vastutus:

9.2.1. juhul kui tellija viivitab lepingus sätestatud rahaliste kohustuste täitmisega, on

töövõtjal õigus nõuda tellijalt viivist 0,05% (null koma null viis protsenti) päevas

tähtaegselt tasumata summalt, kuid mitte rohkem kui 5% (viis protsenti) lepingu

maksumusest.

9.3. Lepingust tulenevate kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta

lepingu rikkumiseks, kui selle põhjuseks oli vääramatu jõud.

9.4. Poolte koguvastutus lepingu täitmisel on piiratud lepingu kogumaksumusega, v.a

konfidentsiaalsuskohustuse rikkumisel tahtlikult või raskest hooletusest.

10. Teadete edastamine ja kontaktisikud

10.1. Teadete edastamine toimub üldjuhul telefoni, e-posti või posti teel. Juhul kui teate

edastamisel on olulised õiguslikud tagajärjed, peavad teisele poolele edastatavad teated

olema edastatud kirjalikus vormis, muuhulgas näiteks poolte lepingu lõpetamise

avaldused, samuti poole nõue teisele poolele, mis esitatakse tulenevalt lepingu

rikkumisest jms.

10.2. Lepinguga seotud teated edastatakse teisele poolele lepingus märgitud

kontaktandmetel. Kontaktandmete muutusest on pool kohustatud koheselt

informeerima teist poolt. Juhul kui pool on lepingu kehtivuse aja jooksul muutnud oma

kontaktandmeid ning ei ole sellest teist poolt kirjalikku taasesitamist võimaldavas

vormis informeerinud, loetakse teade poole poolt kättesaaduks, kui see on saadetud

kõige viimastel poole poolt teatatud kontaktandmetel.

10.3. Kirjalik teade loetakse poole poolt kättesaaduks, kui see on üle antud allkirja vastu või

kui teade on saadetud postiasutuse poolt tähitud kirjaga poole poolt teatatud aadressil

ja postitamisest on möödunud 5 (viis) kalendripäeva. E-posti teel, sh digitaalselt

allkirjastatud dokumentide, saatmise korral loetakse teade kättesaaduks kohale

jõudmise teates märgitud kellaajal või e-kirjas näidatud saatmise kellaajal.

10.4. Poolte kontaktisikud on määratud lepingu eritingimustes. Tellija kontaktisikul on õigus

esindada tellijat kõikides lepingu täitmisega seotud küsimustes, v.a lepingu muutmine

(sh lepingu mahu suurendamine, lepingu eseme või tähtaja oluline muutmine jms),

lepingu ühepoolne erakorraline lõpetamine ning leppetrahvi, viivise või kahjude

hüvitamise nõude esitamine.

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

11. Omandiõigus. Autoriõigused. Dokumentide ja informatsiooni säilitamine

11.1. Lepingu alusel töövõtja poolt loodud või tema poolt kolmandatelt isikutelt omandatud

ja lepingu alusel tellija poolt vastuvõetud ning tasutud lepingu ese ja sellega seotud

võõrandatavad intellektuaalse omandi õigused, sh autori kõik varalised õigused

(edaspidi „õigused“) lähevad lepingu eseme vastuvõtmisega lepingus sätestatud tasu

eest täies mahus üle tellijale. Lepingu eseme suhtes kehtivate intellektuaalse omandi

õiguste osas, mis oma olemuselt üleantavad ei ole, sh autori isiklikud õigused, annab

töövõtja tellijale arvates materjalide üleandmisest tagasivõtmatu kogu autoriõiguste

kehtivuse aja kehtiva ainulitsentsi. Tellijal on pärast lepingu eseme vastuvõtmist

muuhulgas õigus omal äranägemisel otsustada lepingu eseme kasutamisega seonduvad

asjaolud, sh otsustada lepingu eseme avaldamise viis, lepingu eseme kasutamise

algusaeg ja tingimused, teha muudatusi, täiendusi ja parandusi lepingu esemes või

lepingu esemeks olevas teoses, selle pealkirjades või autorinime tähistuses, lisada

lepingu esemele teiste isikute teoseid ja õigus vaidlustada lepingu eseme või lepingu

esemeks oleva teose, nende pealkirjades ja autorinime tähistuses tehtavaid moonutusi

ning nende kohta antud kahjustavaid hinnanguid, ning nõuda lepingu eseme kasutamise

lõpetamist (ainulitsents koos all-litsentseerimisõigusega). Töövõtja kohustub tagama,

et tal on kõik õigused eelpool nimetatud viisil varalised õigused loovutada ja isiklike

õiguste osas ainulitsents anda.

11.2. Lepingu eseme või lepingu esemeks oleva teose kasutamise viis ega territoorium ei ole

piiratud, st neid võib kasutada mistahes viisil (sh internetikeskkonnas) ja kogu

maailmas.

11.3. Töövõtjal ei ole ilma tellija eelneva kirjaliku nõusolekuta õigust kasutada lepingu eset

või nende iseseisva tähendusega osasid või õigusi.

11.4. Töövõtja poolt lepingu alusel kogutud informatsioon või selle töötlused loetakse tellija

omandiks ja lepingu lõppemise korral või tellija nõudmisel on töövõtja kohustatud

viivitamatult omal kulul üle andma tellijale kogu tema valduses oleva sellise

informatsiooni. Samuti kuulub tellijale andmekandja, mille vahendusel lepingu ese,

lepingu esemeks olev teos või lepingu esemega seotud dokumendid reprodutseeritakse,

omandiõigus.

11.5. Kõik lepingu alusel loodud mistahes vormis ja sisuga projektid, plaanid, joonised,

spetsifikatsioonid ja muud dokumendid, mis on loodud töövõtja poolt või sattunud

töövõtja valdusesse või kontrolli alla lepingu alusel tööde teostamisel, loetakse tellija

omandiks. Kui pooled ei lepi kokku teisiti, on töövõtja lepingu lõppemise korral või

tellija nõudmisel kohustatud oma kulul viivitamatult tagastama tellijale kõik tema

valduses olevad ja eespool viidatud dokumendid, muud infokandjad ja tehnilised

vahendid.

11.6. Kui kolmas isik takistab tellijat tema lepingust tulenevate intellektuaalse omandi

õiguste kasutamisel või rikub neid õigusi, teatab tellija sellest töövõtjale, kes peab

viivitamata võtma tarvitusele kõik vajalikud abinõud, et võimaldada lepingust

tulenevate õiguste kasutamist ja lõpetada tellija õiguste rikkumine. Kui töövõtja võtab

sellised abinõud tarvitusele, teeb tellija temaga vajalikul määral koostööd.

11.7. Juhul kui tellija vastu esitatakse nõue tööde tegemisel toimunud autoriõiguste

rikkumise tõttu, vastutab tellijale tekkinud kahju eest töövõtja.

12. Konfidentsiaalsus

12.1. Töövõtja kohustub lepingu kehtivuse ajal ning pärast lepingu lõppemist määramata

tähtaja jooksul hoidma konfidentsiaalsena kõiki talle seoses lepingu täitmisega

teatavaks saanud asutusesiseseks kasutamiseks mõeldud teavet kuni teabepiirangu

tähtaja lõpuni. Eelkõige, kuid mitte ainult, kohustub töövõtja hoidma

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

konfidentsiaalsena andmeid, mis sisalduvad lepingus, lepingu täitmiseks üleantud

dokumentides ja muudes dokumentides, mille sisuga on töövõtjal olnud võimalus

seoses lepingu täitmisega tutvuda, lisaks eeltoodule mistahes muid andmeid.

12.2. Konfidentsiaalse informatsiooni avaldamine kolmandatele isikutele on lubatud vaid

tellija eelneval kirjalikku taasesitamist võimaldavas vormis antud nõusolekul.

Lepingus sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni avaldamisele

poolte audiitoritele, advokaatidele, pankadele ning juhtudel, kui pool on õigusaktidest

tulenevalt kohustatud informatsiooni avaldama. Töövõtja on teadlik, et leping on

avaliku teabe seaduses sätestatud ulatuses avalik.

12.3. Töövõtja kohustub täitma organisatsioonilisi, füüsilisi ja infotehnoloogilisi

turvameetmeid konfidentsiaalsete andmete kaitseks juhusliku või tahtliku volitamata

muutmise, juhusliku hävimise, tahtliku hävitamise, avalikustamise jms eest.

12.4. Töövõtja kohustub mitte kasutama konfidentsiaalset teavet mitte ühelgi viisil isikliku

kasu saamise eesmärgil ega kolmandate isikute huvides.

12.5. Muuhulgas kohustub töövõtja tagama, et tema esindaja(d), töötajad, lepingupartnerid

ning muud isikud, keda ta oma kohustuste täitmisel kasutab, oleksid käesolevas

lepingus sätestatud konfidentsiaalsuse kohustusest teadlikud ning nõudma nimetatud

isikutelt selle kohustuse täitmist samadel tingimustel.

13. Garantii

13.1. Garantiiaja alguseks loetakse lepingu eseme vastuvõtmise hetke. Kui lepingu ese

antakse üle osade kaupa, loetakse garantiiaja alguseks viimase osa üleandmise aega,

kui lepingu eritingimustes ei ole sätestatud teisiti.

13.2. Garantiiperioodi kestus 12 (kaksteist) kuud kui eritingimustes ei ole teisiti kokku

lepitud ja puudused tuleb kõrvaldada mõistliku aja jooksul.

13.3. Garantiiga ei ole hõlmatud puudused, mis on tekkinud tellija hooletuse või tahtliku

tegevuse või tegevusetuse tagajärjel.

13.4. Töövõtja kohustub asuma omal kulul kõrvaldama garantiiaja kestel lepingu esemel

ilmnevad puudused alates tellija poolt töövõtjale esitatava vastavasisulise nõude

hetkest ja kooskõlas lepinguga ning mitte lõpetama vajalikke tegevusi enne, kui

puudused on kõrvaldatud.

13.5. Kõik kulud, mis kaasnevad garantiiperioodil ilmnenud garantii alla kuuluva puuduse

kõrvaldamisega, sh veo-, posti- jm kaasnevad kulud, kannab töövõtja.

13.6. Juhul kui töövõtja ei käsitle puudust garantii alla kuuluva puudusena, teavitab ta sellest

tellijat viivitamatult koos asjakohaste põhjendustega enne vea parandamist. Kui tellija

töövõtjaga ei nõustu, on tellijal õigus tellida kolmandalt osapoolelt enne asja

parandamist asja defekteerimine. Kui defekteerimise tulemusel ilmneb, et puudus või

viga kuulub garantii alla, kohustub töövõtja kandma defekteerimise ja vea parandamise

kulud, muul juhul kannab defekteerimise kulud tellija. Kui asja puudus või viga ei

kuulu garantii alla on töövõtjal õigus vastavalt lepingule dokumenteerida vea

kõrvaldamisele kulunud aeg ning nõuda selle hüvitamist kooskõlas lepinguga või kui

lepinguga ei ole kokku lepitud töö teostamise tunni- vm kohalduvat tasu, lepivad

pooled kulude hüvitamises eraldi kokku, kokkuleppe aluseks on töövõtja poolt

tavapäraselt taoliste tööde eest esitatav hinnakiri või vastava töö tavapärane maksumus.

13.7. Arendustööde puhul loetakse veateade esitatuks, kui see on registreeritud tellija

veahalduskeskkonnas (ServiceDesk) ning veahalduskeskkond on selle edastanud

töövõtja poolt määratud kontaktisikule.

13.8. Tellija nõudmisel kohustub töövõtja kõrvaldama garantiiperioodil ilmnenud vead ja

puudused lepingu esemel tellija asukohas, kui kohapealne vea ja/või puuduse

kõrvaldamine on tulenevalt lepingu eseme olemusest võimalik.

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

13.9. Kui töövõtja ei asu puudust kõrvaldama kooskõlas lepinguga, on tellijal õigus

kõrvaldada see ise või kasutada kolmanda isiku abi ning nõuda töövõtjalt lisaks

leppetrahvile kõrvaldamisega seotud kulude hüvitamist.

13.10. Kui lepingu esemeks on asi ning selle või mõne selle komponendi tootjapoolne

garantiiaeg on pikem lepinguga kokku lepitud garantiiajast, ei katkesta lepingukohase

garantiiaja lõppemine tootjapoolse garantii kehtivust. Käesolevas punktis toodud

tootjapoolse garantiiga seonduva dokumentatsiooni on töövõtja kohustatud andma

tellijale eraldi üle, kuid garantiidokumentide üleandmise kohustuse täitmata jätmine ei

mõjuta garantii kehtivust.

13.11. Juhul kui lepingu esemeks on asi ja töövõtja kõrvaldab lepingu esemel ilmnenud

lepingutingimustele mittevastavuse parandamise teel, pikeneb garantiiperiood eseme

parandamise aja kestuse võrra. Kui töövõtja kõrvaldab lepingu esemel või selle

komponendil ilmnenud lepingutingimustele mittevastavuse eseme või komponendi

asendamise teel, algab vastava eseme või komponendi garantiiaja kulgemine algusest

alates ümbervahetamise kuupäevast.

14. Nõuete ja kohustuste üleandmine ja lepingu ülesütlemine

14.1. Tellijal on õigus sõltumata põhjusest leping igal ajal üles öelda, teatades töövõtjale

vähemalt kuuskümmend kalendripäeva ette. Nimetatud õigus on tellijal ka juhul, kui

pooled on kokku leppinud tähtajalises lepingus. Käesoleva punkti alusel lepingu

ülesütlemisel kohustub tellija tasuma töövõtjale ülesütlemise hetkeks faktiliselt üle

antud esemete või osutatud teenuste eest, muud summad hüvitamisele ei kuulu.

14.2. Poolel on õigus leping ennetähtaegselt ühepoolselt üles öelda, teatades sellest ette, kui:

14.2.1. teine pool on rikkunud lepingut ning pole rikkumist kõrvaldanud poole poolt

määratud mõistliku tähtaja jooksul; või

14.2.2. tegemist on olulise lepingu rikkumisega; või

14.2.3. rikkumine on korduv.

14.3. Lepingu ülesütlemisel töövõtja süü tõttu, on töövõtja õigus nõuda tasu vaid lepingu

lõppemisehetkeks faktiliselt üle antud esemete või osutatud teenuste eest, mida tellijal

on tegelikkuses võimalik kasutada.

14.4. Lisaks mujal sätestatule, on poolel õigus igal ajal leping üles öelda juhul, kui:

14.4.1. lepingu täitmine on takistatud vääramatu jõu tõttu ning nimetatud mõju on peatanud

lepingu täitmist kauem kui kolm kuud; või

14.4.2. teise poole suhtes on alustatud pankrotimenetlust, pankrot on välja kuulutatud või

tema varad on arestitud või tema finantsseisund on teise poole põhjendatud hinnangul

oluliselt halvenenud ja see halvenemine muudab vähetõenäoliseks lepingu

nõuetekohase täitmise.

14.5. Lepingu lõppemise kohase arvelduse kohustub tellija teostama kahe kuu jooksul

lepingu lõppemise hetkest.

14.6. Õigused ja kohustused, mis oma olemusest tulenevalt ei sõltu lepingu kehtivusest,

jäävad kehtima peale lepingu lõppemist.

15. Lõppsätted

15.1. Leping jõustub allakirjutamisest poolte poolt ja kehtib kuni lepingust tulenevate õiguste

realiseerimise ja kohustuste täitmiseni. Lepingu tingimusi võib muuta ainult

pooltevahelise kirjaliku või digitaalselt allkirjastatud kokkuleppega.

15.2. Pooled võivad lepingu erakorraliselt ühepoolselt lõpetada ja kasutada muid

õiguskaitsevahendeid jms lisaks lepingus sätestatule seaduses sätestatud juhtudel ja

korras.

15.3. Lepingu lõppemine ei mõjuta selliste kohustuste täitmist, mis oma olemuse tõttu

Kehtestatud

Peadirektori 12.02.2021 käskkirjaga nr 3-1/16

Kehtiv alates 12.02.2021

kehtivad ka pärast lepingu lõppemist (nt konfidentsiaalsuskohustus, kokkulepped

materjalide suhtes kehtivate intellektuaalse omandi õiguste osas jms).

15.4. Pooled on kokku leppinud, et pooltel on õigus loovutada lepingust tulenevaid ja sellega

seotud õigusi ja kohustusi kolmandatele isikutele ainult teise poole eelneval kirjalikku

taasesitamist võimaldavas vormis antud nõusolekul. Kolmandale isikule õiguste ja

kohustuste loovutamiseks käesoleva sätte tähenduses ei ole tellija poolt lepingust

tulenevate ja sellega seotud õiguste ja kohustuste loovutamine teisele riigiasutusele või

riigi äriühingule.

15.5. Lepingule kohaldatakse Eesti Vabariigis kehtivat õigust. Juhul kui lepingu mõni säte

osutub vastuolus olevaks Eesti Vabariigis kehtivate õigusaktidega, ei mõjuta see

ülejäänud sätete kehtivust. Kui kirjeldatud juhul on tegemist imperatiivsete sätetega,

millest erinevalt ei saa kokku leppida, viiakse seadusega vastuolus olevad sätted

esimesel võimalusel kehtiva regulatsiooniga kooskõlla.

15.6. Juhul, kui lepingu dokumendid on omavahel vastuolus, lähtutakse järgmisest

prioriteetsuse järjekorrast: 1) leping; 2) üldtingimused; 3) muud lepingu dokumendid.

Juhul kui vastuolus on hankeleping ja raamleping, lähtutakse hankelepingus sätestatust.

15.7. Lepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada,

antakse lahendamiseks Harju maakohtule.

15.8. Üldtingimused on koostatud 10 (kümnel) lehel.

1

PPA LTR liidestamine MTA ja TI-ga: tehniline kirjeldus

Sisukord 1. Projekti taustinformatsioon ............................................................................................. 2

1.1 Mõisted ja lühendid ....................................................................................................... 2

1.2 Probleem ja vajadus ..................................................................................................... 3

2. Projekti sisu....................................................................................................................... 3

2.1 Etapid .............................................................................................................................. 3

2.2 Tehnilised nõuded ......................................................................................................... 4

2.2.1 LTR ITK uued arendused Vue peale .................................................................. 6

2.2.2 Testimine ................................................................................................................. 6

2.2.3 Muud mittefunktsionaalsed nõuded .................................................................... 6

2.3 Mitmekeelsuse tugi LTR ITK-sse........................................................................... 6

2.4 Teenuste vaba liikumise alusel LTR taotluste esitamise võimekus LTR ITK-

sse 7

2.5 LTR liidestus MTA-ga .............................................................................................. 7

2.6 LTR ITK-sse emailiga sisselogimist toetavad arendused .................................. 8

2.7 LTR liidestus TI-ga ................................................................................................... 8

2.8 Arhitektuuri pilt.......................................................................................................... 9

3. Projekti tulem .....................................................................................................................12

2

1. Projekti taustinformatsioon

1.1 Mõisted ja lühendid

LTR - Välismaalase lühiajalise Eestis töötamise registreerimise andmekogu. Tegemist on PPA-le

kuuluva andmekoguga, mille eesmärk on arvestuse pidamine välismaalaste lühiajalise

töötamise taotluste ning nende suhtes tehtud registreerimiste, registreerimisest

keeldumiste, taotluste läbi vaatamata jätmiste ning lühiajalise töötamise

registreerimise kehtetuks tunnistamise üle

(https://www.riha.ee/Infos%C3%BCsteemid/Vaata/ltr). Sama lühendit kasutatakse ka

lühiajalise töötamise registreerimise taotluste, toimingute jms andmekoguga seotud

tegevuste juures.

LTR ITK – Lühiajalise töötamise registreerimise iseteeninduskeskkond, kus tööandja

saab registreerida välismaalase lühiajalist töötamist Eestis ning oma taotlusi hallata

(https://etaotlus.politsei.ee/ltr/#!/login).

LTR menetluskeskkond – Lühiajalise töötamise registreerimise menetluskeskkond,

mille kaudu PPA ametnikud menetlevad ja haldavad lühiajalise töötamise

registreerimise taotlusi, teevad isikutuvastust jms tegevusi.

MTA – Maksu- ja Tolliamet

PPA – Politsei- ja Piirivalveamet

TI – Tööinspektsioon

TEIS – Tööelu infosüsteem, mille iseteeninduskeskkonna kaudu Tööinspektsioon

hetkel muuhulgas ka lähetatud töötajate andmeid kogub

(https://iseteenindus.ti.ee/login).

Töökeskkonna andmekogu – Tegemist on TI-le kuuluva andmekoguga, mille

eesmärk on tagada Tööinspektsiooni ülesannete ja kohustuste täitmiseks vajalike

andmete kättesaadavus järelevalvealase töö planeerimiseks, töövaidluste

menetlemiseks, töökeskkonna olukorra hindamiseks ning tööohutus- ja

töötervishoiualase ennetustöö kavandamiseks

(https://www.riha.ee/Infos%C3%BCsteemid/Vaata/tookeskk).

TÖR – Töötamise register, mida peab Maksu- ja Tolliamet ja mis koondab töötamisega

seotud infot (https://www.emta.ee/ariklient/registreerimine-ettevotlus/tootamise-

register).

VMS – Välismaalaste seadus

(https://www.riigiteataja.ee/akt/108072021017?leiaKehtiv)

X-tee – Eesti riigi põhilisi andmebaase ühendav keskkond, mis korraldab

internetipõhist andmevahetust riigiasutuste vahel ja erasektoriga.

3

1.2 Probleem ja vajadus

Välismaalaste seaduse (VMS) kohaselt on tööandjad kohustatud registreerima kõikide

kolmandate riikide kodanike töötamised Eestis. Hetkel on välismaalaste töötamise

registreerimise protsess tööandjate jaoks tülikas, sest protsess ja registreerimiseks

kasutatavad keskkonnad on erinevad olenevalt sellest, kas tegemist on:

 EL või kolmandate riikide kodanikuga;

 lähetatud töötajaga või mitte.

Lisaks peavad tööandjad osasid andmeid topelt esitama erinevatele ametitele.

Olenevalt töötaja kodakondsusest ja sellest, kas tegu on lähetatud töötajaga või mitte,

peab tööandja praegu:

 taotlema PPA-lt välismaalasele lühiajalise töötamise luba ehk esitama LTR

taotluse LTR ITK-s või PPA esinduses kohapeal (kolmandate riikide kodanikud);

 registreerima välismaalase töötamise MTA TÖR-is (kolmandate riikide

kodanikud positiivse LTR otsuse korral; EL kodanikud);

 lähetatud töötajad registreerima TI-s (nii EL kui kolmandate riikide kodanikud).

Samu andmeid esitatakse erinevatele ametitele topelt, sest PPA ja MTA ning TI

andmekogude vahel ei toimu hetkel automaatset andmevahetust. Hanke eesmärk on

muuta välismaalaste töötamisega seotud andmete edastamise protsess kiiremaks ja

lihtsamaks ning kaotada vajadus samu andmeid mitmekordselt erinevatesse

keskkondadesse sisestada.

Selleks luuakse hanke tulemusena nö „ühe akna“ süsteem välismaalaste lühiajalise

töötamisega seotud toiminguteks. Selleks „aknaks“ saab praegune LTR ITK, mille

kaudu tööandjad saavad hanke tulemusena taotleda ja registreerida nii EL kui

kolmandate riikide kodanike töötamist. Vajalikud andmed saadetakse LTR-ist hanke

tulemusena loodavate liidestuste kaudu edasi MTA ja TI vastavatesse

andmekogudesse.

2. Projekti sisu

2.1 Etapid

Tööd viiakse läbi ja arveldatakse etapiviisiliselt. Etappide läbiviimise ajaline järjekord

selgub koostöös tellija ja tööde teostaja vahel.

4

1. LTR ITK-sse on lisatud mitmekeelsuse tugi.

2. LTR ITK-s on loodud võimekus võtta vastu taotlusi teenuste vaba liikumise alusel.

3. On teostatud LTR ITK-sse e-mailiga sisselogimise ja kasutajakonto halduse

võimekuse loomiseks kasutatava karbitoote Keycloak kasutuselevõtmise jaoks

vajalikud toetavad arendused. Paigalduse ja majutamise eest vastutab tellija, antud

projekti raames on vaja teostada toetavaid arendustöid.

4. On arendatud võimekus LTR ITK kaudu EL kodanikest lähetatud töötajate andmete

kogumiseks ja TI-le edastamiseks neid andmeid PPA LTR andmekogusse

salvestamata selliselt, et LTR ITK kaudu on võimalik edastatud andmeid hiljem ka

vaadata ja muuta. (See eeldab, et LTR ITK-s on olemas emailiga sisselogimise

võimekus.)

5. On arendatud liidestus TI X-tee teenusega juba LTR-s kogutavate kolmandate

riikide kodanikest lähetatud töötajate andmete edastamiseks LTR-st TI-le.

6. On arendatud liidestus TI X-tee teenusega, mis võimaldab LTR

menetluskeskkonnast teha päringuid konkreetsetele ettevõtetele tehtud TI

ettekirjutuste ja trahvide kohta.

7. On arendatud liidestus MTA X-tee teenusega, mille kaudu PPA saadab positiivse

LTR otsuse korral vajalikud andmed MTA-le. Nende andmete alusel tehakse MTA

poolel TÖR kanne.

8. On arendatud liidestus MTA X-tee teenusega, mis võimaldab PPA-l MTA-lt pärida

infot lõpetatud TÖR kannete kohta vastavate LTR otsuste kehtetuks muutmiseks.

9. On arendatud liidestus MTA loodava X-tee teenusega (REST), mille kaudu PPA

saadab seadistatud intervalliga kokkulepitud LTR andmekogu andmete muudatusi

MTA-le.

5

Joonis 1 – Etapid

6

2.2 Tehnilised nõuded

2.2.1 LTR ITK uued arendused Vue peale

Hetkel on LTR ITK front-end (https://etaotlus.politsei.ee/ltr/#!/login) ehitatud AngularJS

peale, kuid uued arendused on vaja arendada VueJS peale, versioon 3 või uuem

(eraldi frontend). Kogu olemasolev funktsionaalsus peab tööle jääma rakendades

micro-frontendi’de arhitektuurset mustrit kasutades single-spa raamistikku

(https://single-spa.js.org/).

Praegune UI stack: AngularJS, Jquery, Rxjs, datatables.net, Bootstrap

Koodibaasi suurus:

JS: 99 faili, ~10 000 koodirida

HTML: 77 faili, ~4000 koodirida

Less/CSS: 85 faili, ~17 000 koodirida

2.2.2 Testimine

Pakkuja peab omalt poolt korraldama kõikide projekti skoobis olevate arenduste

testimise tellija dev keskkondades. Tellija poolt on arenduspiletites toodud vastuvõtu

kriteeriumid, mille põhjal pakkuja koostab testimisplaani, teststsenaariumid, teostab

vastuvõtu testimise dev keskkondades ja esitab testraporti. Täpsemad testimise

nõuded koos automaattestimise nõuetega on kirjeldatud Tehniliste nõuete

dokumendis, mis on lisatud eraldi.

2.2.3 Muud mittefunktsionaalsed nõuded

Koodi tarnitakse iteratiivselt ning tellija teostab omalt poolt koodi ülevaatuse. Tehnilised

nõuded tarkvaralahendustele, rakenduste vahelised integratsiooninõuded, lähtekoodi

halduse ja ehitamise nõuded, logimise nõuded ja tehnoloogilise võla mõõtmise

põhimõtted on lisatud eraldi dokumentidena.

2.3 Mitmekeelsuse tugi LTR ITK-sse

Hetkel kuvatakse LTR ITK-s sisu ainult eesti keeles. Seoses projekti raames

lisanduvate võimekustega on vaja hakata kuvama sisu nii eesti kui inglise keeles.

Antud projekti raames tuleb lisata LTR ITK-sse mitmekeelsuse tugi, et kasutaja saaks

valida, kas kasutada keskkonda eesti või inglise keeles.

7

2.4 Teenuste vaba liikumise alusel LTR taotluste esitamise

võimekus LTR ITK-sse

Hetkel on LTR ITK kaudu võimalik taotlusi esitada ainult selliste ettevõtete esindajatel,

mis on kantud kas Äriregistrisse või MTA mitteresidendist tööandja registrisse. Paljud

teenuste vaba liikumise alusel oma töötajaid Eestisse lähetavad EL ettevõtted pole aga

nendesse registritesse kantud. Hetkel kontrollitakse nii ettevõtte registrikoodi vastavust

antud registrite koodide formaadile kui ka tehakse päringud vastavatesse registritesse.

Antud hanke tulemusena peab tekkima LTR ITK-sse võimalus esitada LTR taotlusi ka

sellistel EL ettevõtetel, mis pole antud registritesse kantud. See tähendab muudatusi

praegu kasutuselolevas isikukoodipõhises TARA sisselogimisega taotlusvoos.

Teenuste vaba liikumise alusel Eestisse tulevate EL kodanike lühiajalise töötamise

infot käsitletakse selle projekti raames sarnaselt nagu lähetatud EL kodanike andmete

kogumist, mida käsitletakse punkti 2.7 alampunktis 2.

2.5 LTR liidestus MTA-ga

LTR-i liidestamiseks MTA-ga tuleb teostada järgmised arendused:

1. Liidestus MTA vastava teenusega, mis saadab positiivse LTR otsuse korral MTA-le

vajalikud andmed TÖR kande tegemiseks. See tähendab:

a. Liidestuse loomist MTA vastava X-tee teenusega mainitud andmete

edastamiseks.

b. Muudatusi LTR ITK-s, mis küsivad tööandja kinnitust andmete saatmiseks TÖR-

i. Osade töötamise aluste korral on kinnitus vabatahtlik, osade aluste korral

kohustuslik.

c. Positiivse otsuse korral MTA-sse päringu teostamine TÖR kande tegemiseks,

liidestus sobiliku MTA x-tee teenusega.

d. Muudatusi nii LTR menetluskeskkonnas, kui ka iseteeninduskeskkonnas, mis

võimaldavad koos LTR otsusega saata tööandjale lisaks otsuse kirjale ka teate

TÖR kande tegemise kohta koos info ja linkidega, kus ja kuidas tööandja saab

tehtud TÖR kannet muuta (sõnumivahetuse funktsionaalsus kahe keskkonna

vahel olemas, muuta/lisada tuleb malle).

2. Liidestus MTA vastava teenusega, mille kaudu PPA saab infot lõpetatud TÖR

kannete kohta. See tähendab:

a. Liidestuse loomist MTA X-tee teenusega mainitud andmete saamiseks.

b. Muudatusi LTR menetluskeskkonnas vastava info kuvamiseks

menetlejale ja vastavate LTR kannete automaatseks kehtetuks

tunnistamiseks ning tööandja sellest informeerimiseks.

3. Liidestus MTA poolt loodava uue X-tee REST teenusega, mis saadab perioodilise

tööna MTA-le kõik kokkulepitud LTR andmete muudatused koos ajalooga. See

tähendab:

a. Liidestuse loomist MTA X-tee teenusega mainitud andmete saatmiseks.

b. Tehnilise lahenduse loomist LTR poolele töökindlaks andmete edastamiseks.

8

c. MTA-sse andmete edastamise fakti kuvamist LTR taotluse logis (taotluse logi

on olemas, lisandub logi kirje).

d. Vajalike andmete migratsiooni kokkulepitud 0-seisuga LTR andmete peegli

algseisu loomiseks MTA poolele. Projekti skoopi kuulub vajaliku migratsiooni

skripti loomine ja selle toimivuse valideerimine arendus- ja testkeskkondades.

2.6 LTR ITK-sse emailiga sisselogimist toetavad arendused

Täna toimib LTR ITK sisselogimine TARA kaudu isikukoodide põhiselt. Projektiga

paralleelselt võetakse LTR ITK-s emailiga sisselogimiseks ja kasutajakontode

halduseks kasutusele Keycloak karbitoode. Antud projekti raames on vaja teha LTRi

poolel toetavaid arendusi selle toote kasutusele võtmiseks. See tähendab:

 Vajalike kasutajaliideste (nt sisselogimise akna jms) disainimist ja

lokaliseerimist vastavalt stiiliraamatule;

 Client-account-mgr mikroteenuse arendamist, mis vahetab andmeid Keycloaki

ja teiste LTR süsteemi osade vahel;

 TARA liidestamist Keycloakiga;

 Nii uute kui olemasolevate kasutajaliideste liidestamist Keycloakiga.

Olemasolev isikukoodipõhine TARA sisselogimisega loogika peab jääma paralleelselt

alles. Emailiga sisselogimist peab olema võimalik kasutada EL kodanikest lähetatud

töötajate andmete edastamiseks TI-le (mida on täpsemalt kirjeldatud järgmises

punktis).

2.7 LTR liidestus TI-ga

LTR-i liidestamiseks TI-ga tuleb teostada järgmised arendused:

1. Kolmandate riikide kodanikest lähetatud töötajate andmete edastamine TI-le. See

tähendab:

a. Taotluse esitamisel, otsuse tegemisel ning kokkulepitud muudatuste korral TI-

le X-tee vahendusel LTR andmete edastamist.

b. Muudatusi LTR ITK-s (olemasolevale taotlusele täiendavate

andmete/informatsiooni lisamine).

e. LTR taotluse logis TI-le andmete edastamise fakti kuvamist (taotluse logi on

olemas, lisandub logi kirje).

f. Andmestikus kasutuses olevate klassifikaatorite (nt välismaalase ametikoha ja

ettevõtte tegevusala klassifikaatorid) ühtlustamist LTR ja TI poole vahel,

vajadusel uue klassifikaatori kasutuselevõttu LTR poolel.

2. LTR ITK-sse EL kodanikest lähetatud töötajate andmete kogumise, edastamise,

vaatamise ja muutmise võimekuse lisamine. Seda on võimalik teha peale emailiga

sisselogimise ja kasutajakonto halduse loomist. Lisaks tähendab see:

9

a. Muudatusi LTR ITK-s EL kodanikest lähetatud töötajate andmete kogumiseks

(ühe ankeediga peab olema võimalik esitada mitme välismaalase andmeid).

Täna kogutakse EL kodanikest lähetatud töötajate andmeid TI poolel, kuid

projekti tulemusena lõpetatakse seal andmete kogumine ära ning hakatakse

seda tegema LTR ITK-s.

b. LTR ITK kasutajale enda poolt TI-le saadetud andmete ajaloo näitamist, milleks

tuleb üle X-tee TI-lt andmeid küsima hakata.

c. LTR ITK kaudu esitatud andmete edastamist X-tee vahendusel TI-le.

d. LTR ITK kaudu esitatud ja TI-le edastatud andmete muutmist X-tee kaudu.

e. Andmestikus kasutuses olevate klassifikaatorite (nt välismaalase ametikoha ja

ettevõtte tegevusala klassifikaatorid) ühtlustamist LTR ja TI poole vahel,

vajadusel uue klassifikaatori kasutuselevõttu.

3. Liidestus TI teenusega, mis võimaldab LTR taotlusel teostada päringuid

konkreetsetele ettevõtetele tehtud TI ettekirjutuste ja trahvide kohta. See tähendab:

a. Sobiliku TI päringu lisamist LTR taotlusele (päringute teostamine erinevatesse

andmekogudesse on LTR menetlussüsteemis juba täna realiseeritud, kuid

puudub liidestus TI-ga).

Lisandunud päringu kasutajale kuvamiseks vajalike muudatuste teostamist LTR

menetlussüsteemis.

2.8 Arhitektuuri pilt

Indikatiivne arhitektuuri pilt pärast tulemi teostamist.

10

Joonis 2 – kontseptuaalne joonis

11

Joonis 3 – Integratsiooni joonis

12

3. Projekti tulem 1. LTR ITK-le on nõuetekohaselt arendatud ja testitud mitmekeelsuse tugi.

2. LTR ITK-le on nõuetekohaselt arendatud ja testitud võimekus esitada taotlusi

teenuste vaba liikumise alusel.

3. LTR poolel on nõuetekohaselt tehtud ja testitud vajalikud toetavad arendused e-

mailiga sisselogimise ja kasutajakonto halduse võimekuse loomiseks kasutatava

karbitoote Keycloak kasutuselevõtmise jaoks.

4. LTR ITK-le on nõuetekohaselt arendatud ja testitud võimekus EL kodanikest

lähetatud töötajate andmete kogumiseks, nende edastamiseks TI-le, TI-lt ajaloo

küsimiseks ja andmete muutmiseks X-tee vahendusel.

5. On nõuetekohaselt loodud ja testitud X-tee liidestus kolmandate riikide kodanikest

lähetatud töötajate LTR andmete edastamiseks TI-le koos vajalike muudatustega

LTR ITK-s ja menetluskeskkonnas.

6. On nõuetekohaselt loodud ja testitud X-tee liidestus TI teenusega, mis võimaldab

LTR menetluskeskkonnast teostada päringuid ja näha andmeid konkreetsetele

ettevõtetele tehtud TI ettekirjutuste ja trahvide kohta.

7. On nõuetekohaselt loodud ja testitud X-tee liidestus MTA vastava teenusega

positiivsete LTR otsuste alusel TÖR kannete tegemiseks koos vajalike

muudatustega LTR ITK-s ja menetluskeskkonnas.

8. On nõuetekohaselt loodud ja testitud X-tee liidestus MTA teenusega lõppenud

TÖR kannete info saamiseks ning võimekus selle info alusel LTR otsuste

automaatseks kehtetuks tegemiseks.

9. On nõuetekohaselt loodud ja testitud X-tee liidestus MTA teenusega, mis edastab

perioodilise tööna MTA-le kõik kokkulepitud LTR andmete muudatused koos

ajalooga ning teostatud sellega seotud vajalikud muudatused LTR

menetluskeskkonnas. Lisaks on nõuetekohaselt loodud ja testitud skript, mis

võimaldab nende andmete algseisu migratsiooni LTR-st MTA-sse kokkulepitud

null-punkti seisuga.

Logimise nõuded Nõuded logimisele, arendus-tiimidele ning välistele partneritele (täitmist kontrollib meeskond, kes välist teenust tellib):

1.    Logimiseks tuleb kasutada alus süsteemi võimalusi ja standardseid teeke. 2.    Logi peab olema loetav tekstilisel kujul UTF-8 kodeeringus.  3.    Süsteemispetsiifilised andmed logikirjes peab võimaluse korral koostama JSON-formaadis.  4.    Logitavates andmetes tuleb enne logifaili kirjutamist kodeerida kõik mittekuvatavad ( ) sümbolid, süsteemispetsiifilised andmed, logides non-printable sisalduvad kasutaja sisestatud väärtused ning välja- ja reaeraldajad (st kogu kasutaja sisendit peab olema võimalik taastada, va punktis 8 toodud andmed), välistamaks logisüste ja sellega seonduvaid ründeid. Logitavad andmeväljad eraldatakse tabulatsiooniga. 5.    Juhul kui ühe päringu kohta tekib kirjeid mitmesse logisse, siis peab olema võimalik neid kirjeid ühise välja abil siduda. Selleks ei sobi kellaaeg, aga sobib näiteks unikaalne päringu ID. 6.    Kõik väljanimede kirjeldused, parameetrite nimetused ja muu informatsioon peab olema võimalusel inglise keeles. 7.    Logitud peavad olema kõik tegevused andmetega, sh:        7.1.    kõik autentimise katsed (hoolimata tulemusest);        7.2.    kõik kasutajate poolt algatatud tegevused;        7.3.    kõik taustaprotsesside tegevused;        7.4.    nii õnnestunud kui ka ebaõnnestunud tegevused. 8.    Andmed, mida on keelatud logida:        8.1.    kasutajate autentimisega seotud saladust või salasõna teksti või räsi kujul;        8.2.    privaatvõtmed;        8.3.    seansivõtme väärtus (nt seansi tokenid või -küpsised) –  logida võib ainult seansivõtmest tuletatud räsi või muud pöördumatut tuletist;        8.4.    andmebaasidest tagastatud päringute täisvastused tekstilisel kujul – logida võib andmete tagastamise fakti või vastuse pikkust;        8.5.    biomeetriliste andmete väärtust taasesitamist võimaldaval kujul;        8.6.    andmed, mille logimise keeld tuleneb õigusaktidest (nt krediitkaardiandmed). 9.    Sisendandmed peavad olema eristatavad rakenduselt endalt pärinevatest andmetest, kuid olema arusaadavad ilma rakenduse andmebaasita. 10.    Logikirjed jaotatakse võimalusel järgnevalt (eraldi konfigureeritavatesse failidesse):       10.1.    Seansilogi - info kasutajate tuvastamise, rakendusse või kõrgema turvalisusega rakenduse osasse sisenemiste, väljumiste, seansi aegumise, tühistamiste jmt kohta.       10.2.    Tegevuslogi - kogu informatsioon kasutajate ja taustaprotsesside tegevuste kohta koos sisendparameetritega (sh väliste ressursside kasutamise kohta). Tegevuse- ja seansilogi kirjes peab olema vähemalt:            10.2.1.    Silumislogi - arendajate jaoks vajalik debug info, toodangukeskkonnas peaks debug vaikimisi välja olema lülitatud;            10.2.2.    Turvalogi/auditlogi - turvalisusega seotud eeldefineeritud sündmused, mis võimaldavad tuvastada, mis tegevusi mis järjestuses tehti ning leida viiteid võimalikele turvaprobleemidele (SQL injection, IP muutus seansi keskel kui see pole lubatud, kasutaja käivitas käsu, mida tal ei ole lubatud käivitada jms). Sinna kuuluvad turvalisuse seisukohalt kriitilised sündmused (sisenemine, väljumine, kasutaja loomine, rolli muut(u)mine, seadistuste muut (u)mine) ning tegevused, mis toovad kaasa rahalisi või juriidilisi tagajärgi.       10.3.    Vealogi - erinevate veaolukordade info, mida võimalusel jaotada kaheks:            10.3.1.    tehniline vealogi - erinevad süsteemsed veateated (probleemid liidestega, süsteemsete taustatööde veateated, vead, mida ei ole püütud (unhandled exceptions));            10.3.2.    kasutajate vealogi - kasutajate tegevuse tõttu esile kutsutud vead mis on käsitletud (handled exceptions). 11.    Logide spetsiifika (mida logitakse, kuidas sündmused logifailidesse on jagatud, rakendusspetsiifiliste logide struktuur ja detailid) peavad olema kirjeldatud teenuse dokumentatsioonis. 12.    Logimine peab olema optimeeritud, st et peab vältima liigsete logiandmete edastamist  logihaldussüsteemi ning välistama informatsiooni dubleerimist logides, juhul kui seda ei ole eraldi nõutud. Vajaduse korral filtreeritakse logid teenuses. 13.    Logimisvahendid ja informatsioon logi kohta peab olema kaitstud volitamata muudatuste, hävitamise ja juurdepääsu eest. 14.    Logisid peab logi edastav teenus saatma reaalajas SMIT’i kesksesse logihaldussüsteemi. Kasutusel peab olema ühtne NTP (Network Time Protocol) ajateenus. 15.    Logide keskne kogumine sisaldab:        15.1.    reaalajas saadetavate logivoogude vastuvõtmist ja salvestamist;       15.2.    salvestatud logivoogude arhiveerimist olenevalt saadetavate logide tüübist ja neile kehtestatud säilitustähtaegadest.  16.    Salvestatavad logiandmed signeeritakse digitaalselt.  17.    Logiandmete turvaliseks edastamiseks SMITi kesksesse logihaldussüsteemi väljapoolt SMITi hallatavat taristut peab kasutama VPNi või mTLS-i ühendust. 18.    Arhiiviväärtusega logide terviklus peab olema tagatud kolmanda poole usaldusteenuse (nt. TrueTrail) abil. 19.    Tõestusväärtusega logisid ei tohi hoiustada ega töödelda rakenduse serveris või andmebaasis. Selline kirje on vaid informatiivse väärtusega ning seda logikirjena ei käsitata.

20.    Ligipääs logiandmetele      20.1.    Logikeskkondadele ligipääs peab olema kitsendatud ja piiratud, logides sisalduvaid andmeid tohib töödelda vaid kasutaja, kellel on selleks õigus ja teadmusvajadus.      20.2.    Logisid on keelatud töödelda väljaspool lubatud keskkondi (kaasarvatud kopeerida). Arhiveeritud ja väljaspool logitaristut hoitavad või edastatavad logiandmed on alati krüpteeritud.      20.3.    Logisid ei tohi avalikustada ega jagada teistele osapooltele, kui selleks ei ole põhjendatud vajadust.      20.4.    Logide töötlemisel peab järgima andmete töötlemisel kehtivaid isikuandmete ning avaliku teabe töötlemist reguleerivaid õigusakte, sh täitma konfidentsiaalsuse kohustust nii töö- või teenistussuhte ajal kui ka pärast selle lõppemist. 21.    Logide säilitustähtaegade määramine ja kustutamine peab vastama andmekogu põhimääruses või teenuse kokkuleppes sätestatud tingimustele. 22.    Säilitustähtaja määramisel peab silmas pidama, et ressursikasutus oleks proportsionaalne ja mõistlik. 23.    Kui logide säilitusaega ei ole teenuse dokumentatsioonis täpsustatud, peab logisid hoidma käesoleva aasta kohta ning säilitama neid kuni ühe aasta. 24.    Logimise puhul kehtivad vähemalt sama taseme turvanõuded, mida on rakendatud logitavale teenusele. 25.    Kui rakenduse äriloogika ei vasta kehtestatud nõuetele tuleb tehnoloogilist lahendust eelnevalt infoturbeosakonnaga kooskõlastama.

Logikirjes peab sisalduma vähemalt teave, et vastata küsimustele: kes, millal, mida, kus ja kust süsteemis tegi ning mis oli tegevuse tulemus.

Logikirje miinimumnõuded on

1.    Logikirjes (minimaalselt tegevus- ja seansilogi) peab sisalduma vähemalt teave, et vastata järgmistele küsimustele:       1.1.     on tegevuse teostaja, sealjuures:KES             1.1.1.    peab ta olema unikaalne vähemalt teenuse piires;            1.1.2.    peab ta olema seostatav füüsilise isikuga, kui see on võimalik;            1.1.3.    tema automaatprotsessid peavad olema selgelt tuvastatavad.       1.2.   on ajamärgistus, mis sisaldab täpset sündmuse kuupäeva ning kellaaega, sealjuures peab aeg olema:  MILLAL             1.2.1.    vähemalt sekundi täpsusega;            1.2.2.    UTC ajavööndis;            1.2.3.    ajaformaadis ISO8601 koos ajavööndi infoga, näiteks formaat YYYY-MM-DDTHH:mm:ss.SSSZ.       1.3.     on logitava tegevuse või sündmuse liik või klass, näiteks kasutaja tuvastamine, administreerimine, operatsioon ja kasutus, ning liigi või MIDA  klassi tegevuse detailid. Märgitakse:            1.3.1.    üheselt tuvastatav viide objektile või selle komponendile, mida kasutati;            1.3.2.    tegevuse tüüp, näiteks , või kasutatud meetod ja nende sisendandmed; login, timeout, search, request, query            1.3.3.    tegevusega seotud muud andmed ja sisendväärtused, mida tegevuse käigus töödeldi või mis on olulised, näiteks failide nimed, päringu objektid, autentimismeetod.       1.4.     on süsteemi identifikaator, mille abil on võimalik teha kindlaks täpne rakendus ja selle instants, mille suhtes tegevus tehti.KUS        1.5.     on seadme unikaalne identifikaator, näiteks nimi, IP-aadress või seadme sertifikaat, kust tegevus toime pandi, sealjuures peab:KUST             1.5.1.    identifikaatori abil olema võimalik üheselt tuvastada seade, kust sündmus toime pandi;            1.5.2.    IP-aadressi puhul olema tuvastatav lõppseadme IP-aadress.       1.6.     – kui ei ole kokku lepitud teisiti, siis päringute vastuseid täies mahus ei salvestata. Logisse peab kirjutama tulemust kirjeldavad TULEMUS  andmed, näiteks tulemuse tüüp (success, attempt, failure, error), vastuse suurus (nii baitides kui ka ridade arvuna).

Logikirje elementide soovituslik järjestus:

{when}\t{where}\t{what}\t{whence}\t{who}\t{procid?}\t{result}\t{msg-payload?}

a. b. c. d. e.

Lähtekoodi halduse ja ehitamise nõuded Versioonihalduse kasutamine

Tarkvara lähtekoodi halduseks tuleb kasutada   aadressil asuvad GIT repositooriumi (ligipääs antakse projekti põhiselt).https://source.smit.sise Tarkvara versioonihalduses jälgitakse üldises mõistes  protsessi ( ) või Git-flow http://nvie.com/posts/a-successful-git-branching-model/ Feature-

 ( ) protsessi.branche-workflow https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow Git-flow lähenemist on sobilikum kasutada siis, kui tarkvara versioonide väljastamine on aeglasem ja harvem ning versioonides toimuvad stabiliseerimisperioodid, samuti kui on vaja mitut erineva funktsionaalsusega versiooni pikaajaliselt toetada. Teine mudel sobib neile kes on rohkem automatiseerinud oma paigaldus ja tarneprotsessid ning kasutavad kas või  töövooge.Continuous Delivery Continuous Deployment

Iga  JIRA pileti realiseerimise alguses loob arendaja JIRA abil (kasutades JIRA sees pileti juures käsku create branche) nimelisest "develop" harust endale vastava konvensiooni (vt. joonis) põhiselt nimelise haru, kus arendust tehakse."feature/xxx" Konfliktide vältimiseks peab kesksest harust järjepidevalt enda harusse muudatused mestima. Piletis realiseeritud lähtekoodi üleandmiseks SMIT-ile tuleb minna versioonihaldus keskkonna (  vastava tarkvara ruumi https://source.smit.sise) ning valida sealt tab ning luua uus , kus tuleb määrata lähteharuks enda tehtud arendusharu ning lõppharuks keskne pull-requests pull-request haru. Ülevaatajaks tuleb valida SMIT poolne kontakt ning sisuks täiendavad kommentaarid, mida silmas pidada antud tarnes (näiteks et muutus konfiguratsioon või baas vms). Kui meeskond on kasutusele võtnud koodi ülevaatustes, AI assistendi siis tuleks esimesena tähelepanu pöörata automaatsest tagasisidest, mis peaks tekkima 30s jooksul peale pull-requesti tegemist.

Tarne üleandmise eelduseks on, et üleantav kood vastab kõikidele kokkulepitud nõuetele, mis arenduse alguses on fikseeritud või on konkreetsed puudused toodud välja kirjelduses;pull-requesti  Tarne loetakse vastuvõetuks, kui on toimunud vastavad tegevused:

Bamboo ehitusserver on edukalt üleantava haru ära ehitanud SonarQube analüsaator näitab, et SMIT poolt kasutatav   on läbitudQuality Gate SMITi poolne vastuvõtja on tarnele  teinud koodi analüüsi ja need heaks kiitnud Kood on ilma konfliktideta süsteemi poolt mestitud harusse ( on täidetud)"develop" pull-request Kõik tarnes sisalduvad on seotud konkreetsete JIRA piletinumbritega kujul XXXX-YYYcommitid

-i Pull-request kinnitamisel automaatselt kustutatakse vastav arendaja poolt tehtud haru ära, kui mestimine on olnud edukas; Pull-request-i võib SMIT tagasi lükata, kui seal esineb puudusi või alustada seal sees dialoogi puuduste kõrvaldamiseks (koodi ülevaatuse tegemisel lisatakse kommentaarid otse koodi ridade vahele); 

-Pull-request i kirjeldus peaks kokkuvõtlikult selgitama üleantava tarne sisu (AI olemasolul saab kasutada vajadusel tarne sisu genereerimiseks)

Bamboo (CI/CD) kasutamine

Igal tarkvaral on bamboos defineeritud  1 ehitusplaan, mis ehitab ennast " " või " " haru pealt automaatselt (haru valik sõltub, develop master|main kumba protsessi kasutatakse koodi halduseks). Arendajad peaksid oma arendusi tegema " harudes, mida automaatselt Bamboo on võimeline ehitama. Samuti saab vajadusel feature" seadistada Bambood ehitama kõik harusid, mida git-ist leitakse (https://docs.atlassian.com/bamboo-specs-docs/9.4.1/specs.html?yaml#plan-

)branches Bamboo ehitusplaan ehitab  koodi, teeb koodile staatilist analüüsi, võimalusel turvaanalüüsi, jooksutab testid ning olenevalt harust siis paigaldusplaan paigaldab lõpuks rakenduse määratud keskkonda (feature harude puhul paigaldusi ei toimu). Git-flow puhul on reeglina ehitusplaan liidestatud " haruga ning paigaldatakse tulem arenduskeskkonda, testi ja toodangu jaoks develop" versioonid tekivad harude pealt (" " harud reeglina), mida paigaldatakse Bamboo kaudu käsitsi.release

Feature-branche-workflow protsessi puhul on ehitusplaan liidestatud " haruga, mille tulemus paigaldatakse automaatselt master|main" testkeskkonda. Võimalus on selle kõrvale luua ka täiendavaid harusid ja siduda neid konkreetse keskkonnaga - näiteks paigaldatakse " "develop automaatselt arenduskeskkonda.  Toodangu keskkonda paigaldus tehakse käsitsi Bamboo sees  ning sinna paigaldatakse sama tulem, mis läks testi. Bamboo paigaldusprojekt luuakse eraldi git-i spec repona (nimekuju xxx-deploy) ning Bamboo paigaldusprojekti sees on iga keskkond defineeritud eraldi Bamboo "env"-ina ( ).https://docs.atlassian.com/bamboo-specs-docs/9.3.0/specs.html?yaml#environments

1. 2. 3. 4. 5. 6. 7. 8.

1. 2. 3. 4.

1.

2.

3.

4. 5. 6.

Rakendustevahelised integratsioonipõhimõtted

Sünkroonne ja asünkroonne suhtlusviis Integratsioon süsteemide vahel (nii välised kui sisemised)

Sõnumivahetuse nõuded (MQ) Sõnumivahetuse mudelid Sõnumid Sõnumiserveri kanalid Sõnumi edastamine Ühenduskiht

REST API ja HTTP/JSON API rakenduste teenuste arendamise nõuded Kontekst Üldised nõuded API-le

Ressurside URL-i kujud Ressursside nimetamine Toimingud ressurssidega Otsingu tugi API ressurssides API ressursside/teenuste versioneerimine API veahaldus API rakenduse kättesaadavus Tuvastamine

SOAP teenuste arendamise nõuded SOAP teenuste tarbimise head tavad

Sünkroonne ja asünkroonne suhtlusviis Rakendused saavad omavahel suhelda s või :ünkroonselt asünkroonselt

S – teenuskutse tegija ootab seni kuni teenusepakkuja poolt on vastus saadaval. Samaaegselt võib toimuda üks toiming:ünkroonne suhtlemine

Üks laialdasemalt kasutatud suhtlusstiile; Kontseptuaalne lihtsus võimaldab hõlpsalt rakendada; Enamikes olukordades sobiv suhtlusstiil; Tihedalt seotud HTTP protokolliga, kuid on ka teisi protokolle, nt RPC; Sünkroonse integratsiooni puhul on eelistatud protokolliks HTTP ning andmeformaadiks JSON; SOAP/XML lahendusi kasutada ainult nö olemasolevate süsteemidega liidestamisel, kus muid võimalusi ei ole; Kasutada saab nii X-tee integratsiooni kui ka otse tehtavaid HTTP teenuseid; Kõige levinum stiil HTTP teenuse loomisel on , kuid on võimalus ka kasutada -i(ainult läbi eelneva kooskõlastuse) REST GraphQL

As – teenuskutse tegija ei oota teenusepakkuja poolt vastust. Samaaegselt võib toimuda mitu toimingut:ünkroonne suhtlemine ehk sõnumivahetus

Sobib hästi hajussüsteemi, -arhitektuuri jaoks; Teenused ei ole omavahel seotud, sest suhtlemiseks kasutatakse sõnumisiini, mis võimaldab rakenduste vahel sõnumeid vahetada. Andmevahetusformaadiks võib tekstiliste andmete puhul samuti eelistada JSON-it Andmevahetuseprotokollina on soovituslik kasutada AMQP protokolli

Allikas: Gupta, P. (05.06.2018). Patterns for Microservices – Sync vs. Async. DZone. https://dzone.com/articles/patterns-for-microservices-sync-vs-async

Integratsioon süsteemide vahel (nii välised kui sisemised)

Rakendusi omavahel integreerides peame peamiselt arvestama kolme aspekti. Kas kaks omavahel liidestavat komponenti on määratletud sama andmekogu alla, ehk toimub andmekogu sisene integratsioon või toimub andmekogu ülene integratsioon ning kas üks liidestavatest komponentidest asub välisperimeetris/õues (taotluskeskkonnad).

Andmekogu on see süsteem, mis on määrusega registreeritud, kui on segadus, konsulteeri oma tooteomanikuga.

Andmekogusiseseid integratsioone või liidestus lahendusega, mis ei kuulu ühegi andmekogu alla, võib teha nii sünkroonselt kui asünkroonselt ning ei pea kasutama X-TEEd; Andmekogude vahelisi integratsioone tohib teha ainult üle X-TEE ning tulenevalt X-TEE piirangutest, siis täna ainult sünkroonselt (lähtuda tuleb X-

;TEE dokumentatsioonist) Komponendid, mis asuvad välisperimeetris/õues (igasugu veebid, taotluskeskkonad jms), ei ole lubatud otse liidestuda sisemiste süsteemidega sh. X-TEE-ga (neil tuleb sisevõrku teha vaheadapter, mis päringud edastab); Kui andmekogu soovib andmeid pärida lahenduselt, mis ei kuulu andmekogusse, võib seda teha ilma X-TEEd kasutamata. Kui sisemine süsteem pärib andmekogu käest andmeid, tuleb kasutada X-TEEd. Välist rakendust disainides, tuleks pöörata tähelepanu, et selle mõju sisemistele komponentidele oleks minimaalne (turva, käideldavus, terviklikkus). Eriti arvesse võtta olukordi, kus väline rakendus võib rünnaku alla sattuda.

1. 2. 3.

Sõnumivahetuse nõuded (MQ)

Võimalusel kasutada AsyncAPI spetsifikatsiooni( ) andmevahetuse dokumenteerimiseks.https://www.asyncapi.com/en

Sõnumivahetuse mudelid

Lubatud on kasutada vastavalt vajadusele nii publish/subscribe (queue - järjekorrad), kui point-2-point (topic - teemad) mudelit.

Sõnumid

Kui ei ole määratud teisiti, on nõutud tekst tüüpi sõnumite kasutamine Kui sõnumi sisu on JSON dokument, tuleb seda valideerida kasutades json-schema validaatorit (https://github.com/fge/json-schema-validator) või sellega samaväärset lahendust Binaarkujul failide edastamiseks läbi sõnumite tuleb kasutada tekst tüüpi sõnumit, ning faili sisu lisada Base64 kodeeritud kujul Küsimus-vastus (request-response) tüüpi sõnumivahetuses tuleb küsimuse vastust identifitseerida korrelatsiooni identifikaatoriga (correlation-id)

Sõnumiserveri kanalid

Juhul kui kanalite nimetused ning nende sisu ei ole eelnevalt kokku lepitud, tuleb kasutatavate kanalite arv ning nimetused kooskõlastada SMIT- iga Juhul kui sõnumite sisu on XML dokument, tuleb kanalite nimed koos tema sisuga defineerida XML-i kirjeldavas dokumendis (XSD-s)

Sõnumi edastamine

Kanalite nimetuste nimekonventsioonina järgida üldjoontes malli: "[andmete omanik].[sõnumis olevad andmed]" näiteks: "amr.ametijuhend"

Küsimus-vastus (request-response) tüüpi sõnumivahetuse puhul lisada suffiksina kanalinimele vastavalt Request või Response - näide manuses näiteks "amr.ametijuhendRequest" ja "amr.ametijuhendResponse"

Sõnumiedastuse ühelt-mitmele (topic) puhul lisada suffiksina kanalinimele vastavalt Topic - näide manuses.  näiteks "amr.ametijuhendTopic"

Sõnumiedastuse ühelt-ühele, ilma vastust ootamata (queue) tüüpi sõnumivahetuse puhul lisada suffiksina kanalinimele vastavalt Queue - näide manuses

näiteks "amr.ametijuhendQueue"

Ühenduskiht

Juhul kui ole määratud teisiti, käib suhtlus sõnumiserveriga TCP tasemel (vm tase oleks kiire aga mõistlik on sõnumiserver hoida rakendusest väljaspool, et tagada käideldavus)

REST API ja HTTP/JSON API rakenduste teenuste arendamise nõuded

Kontekst

REST on arhiekturistiil, mis kirjeldab nõuded/piirangud rakenduste loomiseks, võttes aluseks veebiarhitektuuri (world-wide-web ehk www)

REST puhul on peamine informatsiooni abstraktsioon ressurss (ingl resource). Mistahes teave, mida saab nimetada, võib olla ressurss. (Fielding, 2000)

Ressurss varieerub ajas ning tähistab konkreetsel ajahetkel olemite kogumit või väärtusi (Fielding, 2000). Väärtused võivad olla ressursi esitused (ingl resource representation) ja/või ressursi identifikaatorid (ingl resource identifier). REST-komponendid, teisisõnu omavahel suhtlevad rakendused, teevad toiminguid ressurssidega, kasutades ressursi esitust praeguse või kavandatud oleku fikseerimiseks ja selle esituse ülekandmiseks rakenduste vahel. (Fielding, 2000)

Allikas: Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. University of California, Irvine. https://www.ics. uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Üldised nõuded API-le

1. a.

2. a.

3. a.

4. a.

5. a.

1. a.

2. 3.

a.

1. a. b. c.

i. 1.

d. e.

1. a.

2. a. b.

1. 2. 3.

a.

1. a.

API-del peaks olema loodud dokumentatsioon, mis sisaldab detailset api kirjeldust. Soovituslik on läheneda API-FIRST, ehk api kirjeldatakse ära ja siis luuakse implementatsioon.

Võib kasutada näiteks: https://swagger.io/

API-i juures kasutatavatel andmekomplektidel (eeldatavasti siis JSON dokumendid) peaksid eksisteerima "schema" kirjeldused. Soovituslik on see teha API enda kirjelduse juures, kus saab API väljakutsed lihtsasti siduda "schema" objektidega.

Schemad on vajalikud nii kommunikeerimisel teiste osapooltega, kes API-t kasutavad, kui ka võimaldab luua paremini valideerimisloogikat lähtekoodis.

Ressurside URL-i kujud

/X - tagastab ressursi X massiivi. /persons

/X/{id} - tagastab konkreetse X ressursi id järgi /persons/1 - tagastab isiku 1

/X/Y - tagastab X listi, mida on filtreeritud Y järgi /persons/applications - üldiselt ei kasutata aga võiks tähendada: anna kõik isikud, kus on mõni taotlus küljes

/X/{id}/Y - tagastab ressursi Y listi, mis on X id-ga seotud /persons/1/applications - tagastab kõik isiku 1 taotlused 

/X/Y/{id} - tagastab X ressursi listi, mida on filtreeritud Y id järgi /applications/persons/1 - anna kõik isiku 1 taotlused

{id} ehk id kui path variable-ga identifitseeritakse ressursi

Ressursside nimetamine

Lihtsad ja arusaadavad ressursid vastavalt äriloogikale ja seostele Nt /persons/1/applications

Ressursi nimetus mitmuses väljendab, et ressurss on mitmuses Ressursside nimetamisel ei kasutata käske (nt )/getPersons või /createPerson ei ole õige

Ressursi nimetamise asemel väljendavad HTTP käsud/meetodid ressurssidega tehtavaid toiminguid (vt  )Toimingud ressurssidega

Toimingud ressurssidega

Ressursidega toiminguteks tuleb kasutada HTTP käske. Nt /persons puhul GET /persons - tagastab massiivi kõikidest isikutest POST /persons - loob uue isiku DELETE /persons - antud kontekstis vähetõenäoline kasutus, aga kustutab olemasolevad isikud ja nende seosed 

Sõltub ärivajadusest, kas rakenduses on otsustatud, et tegemist on loogilise või füüsilise kustutamisega Mitte kasutada DELETE-i loogiliseks JA füüsiliseks kustutamiseks ilma, et API ressurss väljendaks, millega täpselt tegemist

PUT /persons - antud kontekstis vähetõenäoline kasutus, aga asendab kõik olemasolevad kirjed PUT teenuskutse sisendiga täies mahus PATCH /persons - antud kontekstis vähetõenäoline kasutus, aga asendab kõikidel olemasolevatel kirjetel PATCH teenuskutse sisendiga antud konkreetsete väljade väärtused

Otsingu tugi API ressurssides

Kui tahta sorteerida, filtreerida, otsida, siis kasutada query parameetrit ehk päringu keerukus viia ‘?’ taha Nt GET /persons?name=X&age=Y

Kui API võib tagastada pikki nimekirku, siis tuleb kindlasti kasutada osade kaupa küsimist (ingl )pagination/paging Nt /persons?limit=25&offset=50 vaikimisi limit=10 ja offset=0

API ressursside/teenuste versioneerimine

API versioonimine on loomulik API muutuste juhtimise osa

Iga kasutuses oleva API muudatus peab olema tagasiühilduv Uus versioon tuleb luua nt kui muudetakse API sisendi/väljundi struktuuri; eemaldatakse mõni väli Uue versiooni loomisel peab eelmine versioon toetatud olema

Vanade versioonide eemaldamine eeldab tarbijatega kokkulepet ja vastavat protsessi/reeglistikku

Näide -

Versiooninimes kasutada v eesliidet ning väikeste versioonide asemel kasutada suuri versiooni numbreid, nt v1, v2, v3 Versiooninumber tuleb hoida URL-i sees kõige vasakul pool: /v1/persons

: Kõige lihtsam versioonimine, aga Märkus ei ole REST arhitektuuristiiliga kooskõlas

API veahaldus

1.

1. a.

API rakenduses peab olema lahendatud, kuidas vigu hallatakse ning neid tarbijatele väljastatakse

Luua korrektne veahaldus HTTP koodide põhiselt (seda mõistavad hästi ka teised süsteemid)                 200 - OK                 400 - Bad Request from client                 500 - Internal Server Error                 304 - Not Modified                 404 – Not Found                 401 - Unauthorized                 403 - Forbidden                 Lisaks veakoodile lisada ka detailsem veateade                 {"status" : "401", "message":"Authentication Required","code": 20003}

API rakenduse kättesaadavus

Kogu rakenduse API võiks kättesaadav olla eraldi domeeninime või kausta alt Nt api.rakendus.smit või rakendus.smit/api/

Tuvastamine Tuvastamist või isikustatud päringute tegemisel, peab identifitseerimist määratleb token (JWT) või vastav räsi minema HTTP päringu päisess (headers).

SOAP teenuste arendamise nõuded  Liidesed luuakse   põhimõttel kasutades SOAP Document Literal sõnumivahetuse põhimõtet;Contract-First XSD-sse peab saama sisse viia uuendusi, ilma et olemasolevate kasutamine oleks häiritud;

Nõuded XML schemale:

Complex Type definitsioonid:

tohivad sisaldada ainult   tüüpi   komponenti kordsustega minOccurs="1" ja maxOccurs="1".sequence model group ei tohi sisaldada atribuutide deklaratsioone. liik ( ) peab olema  .variety element-only

Sequence peab koosnema kas:

ühest   deklaratsioonist kordsustega   ja element minOccurs="0" maxOccurs="unbounded" nullist või rohkemast   deklaratsioonist minimaalse kordsusega   või  , maksimaalse kordusega element minOccurs="0" minOccurs="1" maxOccurs="

 ning lõppema   deklaratsiooniga atribuutidega processContents="lax" minOccurs="0" maxOccurs="unbounded" namespace="##any".1" any

Näide

<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://ametnik.smit/services" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormD efault="qualified" xmlns:veeb="http://ametnik.smit/services" xmlns:smit="http://ametnik.smit/smit">

<xs:annotation> <xs:documentation xml:lang="et"> Näitedokumendi dokumentatsioon (seletav ja kirjeldav tekst) </xs:documentation> </xs:annotation>

<xs:complexType name="Ametijuhend"> <xs:sequence> <xs:element name="isikukood" type=" "xs:string /> <xs:element name="failiNimi" type=" "xs:string /> <xs:element name="failiSuurus" type=" "xs:int /> <xs:element name="failiLaiend" type=" "xs:string />

Struktuur kus viimane element on kordsusega ei ole XML Schema 1.0 nõuete alusel deklaratsioon lubatud minOccurs="0" any Unique Particle reegli tõttu. Vastavat reeglit on korrigeeritud XML Schema 1.1 versioonis. Juhul kui tööriistad ei toeta vastavat deklaratsiooni võib Attribution

selle ära jätta eeldusel et on tagatud selle eesmärk - vastuvõtjale tundmatute elementide lisamine struktuuri lõppu ei põhjusta vastuvõtjas valideerimisviga.

<xs:element name="fail" type=" "xs:base64Binary /> </xs:sequence> </xs:complexType>

<xs:element name="AmetijuhendRequest"> <xs:annotation> <xs:documentation xml:lang="et"> Ametijuhendi(te) pärimiseks vajaliku sõnumi element. </xs:documentation> <xs:appinfo> <smit:queue>amr.ametijuhendRequest</smit:queue> </xs:appinfo> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="asutusId" type=" "xs:integer /> <xs:element name="aktiivsedOnly" type=" "xs:boolean /> <xs:element name="isikukood" type=" "xs:string minOccurs="0" /> <xs:element name="yksusId" type=" "xs:integer minOccurs="0" /> <xs:element name="muudetudAlates" type=" "xs:date minOccurs="0" /> <xs:element name="muudetudKuni" type=" "xs:date minOccurs="0" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="AmetijuhendResponse"> <xs:annotation> <xs:documentation xml:lang="et"> Ametijuhendi(te) päringu vastusena tagstatav sõnumi element. </xs:documentation> <xs:appinfo> <smit:queue>amr.ametijuhendResponse</smit:queue> </xs:appinfo> </xs:annotation>

<xs:complexType> <xs:sequence> <xs:element name="Ametijuhend" type="veeb:Ametijuhend" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element>

<xs:element name="AmetijuhendTopic"> <xs:annotation> <xs:appinfo> <smit:topic>amr.ametijuhendTopic</smit:topic> </xs:appinfo> <xs:documentation xml:lang="et"> Ametijuhendi(te) uuenemisel publitseeritava sõnumi sisu </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Ametijuhend" type="veeb:Ametijuhend" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element>

<xs:element name="AmetijuhendQueue"> <xs:annotation> <xs:appinfo> <smit:queue>amr.ametijuhendQueue</smit:queue> </xs:appinfo> <xs:documentation xml:lang="et"> Ametijuhendi(te) uuenemisel publitseeritava sõnumi sisu </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Ametijuhend" type="veeb:Ametijuhend" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element>

</xs:schema>  

1.

2. 3.

SOAP teenuste tarbimise head tavad

Nt Java puhul dünaamilise keele (nt Groovy) kasutamine SOAP päringute/vastuste konverteerimiseks selle asemel, et WSDL-ist klasse genereerida ning tekitada töömahtu ja pallastkoodi. Näidis SOAP-ist andmete kättesaamiseks: https://stackoverflow.com/questions/39526932/groovy-parse-soap-response-xml-to-get-data Näidis SOAP päringute koostamiseks: https://stackoverflow.com/questions/42290675/groovy-markupbuilder-how-to-create-markup-and-append- string

Tehnilised nõuded

Nõue Täiendav selgitus

Rakendused luuakse põhimõttel, kus ühte paigaldatavasse komponenti ei panda kokku sisult väga erinevat funktsionaalsust, vaid pigem jaotatakse vajadusel erinevate komponentide vahel. Komponentideks jaotamine toimub sisulistest, mitte tehnilistest funktsionaalsustest lähtudes v.a kasutajaliideste eraldamine eraldi rakendusteks. (vt. Bounded Context)

Komponentideks jaotamisel mitte lähtuda tehnilistest mõõdikutest nagu koodiridade arv või et tõstame näiteks tehnilise funktsionaalsuse nagu logimise eraldi komponendiks. Kui üks komponent on jäigas sõltuvuses teisest ( ei saa tööprotsessi lõpuni viia või ei saa paigaldada, kui teine ei vasta samal ajal), siis on tegemist hajusa monoliidiga ja tuleks need komponendid kokku tõsta koodi tasemel.

Komponent peab jooksma vähemalt 2 instantsi peal, et vältida platvormi muudatuste käigus tekkida võivaid katkestusi.

Konteinerplatvormile paigaldatud rakenduste puhul peaks vähemalt toodangu keskkonnas minimaalselt 2 instantsi jooksma, et vältida katkestusi. Eelistada ka jõudluse vaates komponentide hulga tõstmist, mitte tõsta olemasolevate komponente ressursikasutust. Näiteks mitte teha VM-e suuremaks (mälu/CPU vaates).

Rakendust ehitatakse ja pakendatakse SMIT CI/CD lahendusega (Bamboo) ning komponendile kohandatakse automaatset staatilise koodi analüüsi vastavalt SonarQube profiilile, mille tulemused on kättesaadavad SMIT SonarQube keskkonnast. Lähtekood ei tohi sisaldada vigu mis on analüsaatori poolt leitud.

Kehtib nii loogika kui kasutajaliidese komponendi puhul. Minimaalne on vaikeprofiil, kui arendajad ei lepi kokku täiendavates nõuetes. Lisainfo on dokumendis Tehnoloogilise võla mõõtmine (SonarQube).

Rakenduse lähtekood on kirjutatud selgusega, mis võimaldab erialast ettevalmistust omaval tarkvaraarendajal süsteemi edasi arendada.

Rakenduse lähtekood ja kommentaarid peavad olema inglise keeles. Rakenduse ärilised muutujad aga eesti keeles, kui neile pole mõlemapoolset loogilist vastet.

Rakenduse lähtekoodi haldus toimib SMITi kesksete versioonihalduspõhimõtete järgi ja SMIT-i GIT-is.

Kehtib nii loogika kui kasutajaliidese komponendi puhul. Lisainfo on dokumendis Lähtekoodi halduse ja ehitamise nõuded.

Keskkondadesse rakenduste paigaldamine on automatiseeritud SMIT CI/CD mehhanismidega.

Kasutatakse Bamboo paigaldusplaane: https://confluence.atlassi an.com/bamboo/deployment-projects- 338363438.html

Kokku ehitatatud rakendust peab saama paigaldada erinevatesse keskkondadesse, ilma et seda peaks uuesti kokku ehitama.

Konfiguratsioon määratakse keskkonna muutujatena või konfiguratsioonifailidena või kombinatsioonis, kusjuures infot hoitakse Kubernetes objektis „ConfigMap“.

Auditlogi väljastamiseks tuleb kasutada SMIT poolt pakutavat JAVA teeki.

Rakendustel puudub ligipääs avalikku internetti (sh klientidel). Kui on vajalik

ligipääs äriandmetele väljaspool SMIT võrku, tuleb tellida webproxy ligipääs.

Rakenduste sõltuvuste (maven,npm jne) allikana tuleb kasutada SMIT sisest keskset repositooriumi (Artifactory) .

Kõik välised sõltvused peavad olema sealt kättesaadavad. Komponentide piketeerimiseks ja ehitamiseks CICD/-ga Bamboos saab sõltuvusi kätte ainult SMIT repositooriumist.

Kõik välised sõltuvused tuleb rakenduse ehitamisprotsessikäigus läbi skaneerida Artifactory Xray töövahendiga ja mitte kasutada kõrge kriitilisusega turvanõrkuseid sisaldavaid teeke/komponente.

Kasutajaliidese sõltuvused/osad nagu JS,CSS,FONTS,GIF jms, mida kasutatakse kasutajaliidese kuvamisel, peavad rakenduse käivitusel tulema samast allikast.

Väliste sõltuvuste ja repode kasutamine ei ole lubatud (nagu välised cdn-id, google fonts, github jne). Arendamisel tuleb kontrollida browseri võrguliikluse lehelt, et välisperimeetrisse ei mindaks päringuid tegema.

Väliste teenuste nagu ReCaptcha, Google Analytics jms kasutamine ei ole lubatud.

Tuleb kasutada SMIT siseseseid lahendusi.

Testimine

Komponendil on olemas minimaalne genereeritav testandmete komplekt.

Peamiselt koormustestide või suitsutestide läbiviimise keskkonna jaoks.

Test- ja toodangukeskkonnad peavad olema üksteisest lahus ning testandmed ei tohi olla toodanguandmed (v.a juhul kui tegemist ei ole avalike andmetega - näiteks aadressid).

Loogikakomponendil on olemas integratsioonitestid veebiteenuste või sõnumivahetusteenuste jaoks ning vajadusel täiendavad ühiktestid spetsiiflise äriloogika valideerimiseks.

Peab olema tarnitud end-to-end testid kasutades Playwright raamistikku.

End-to-end testid peavad olema vastuvõtutestide väärilised ja võtma arvesse vastuvõtukriteeriume.

Rakenduse automaattestide mahtu tuleb analüüsida CI/CD mehhanismide abil ning tulemused peab publitseerima SMIT SonarQube keskkonnas.

Testide mahu miinimum määratakse Sonari kvaliteediväravaga (reeglina 80% kogu koodist).

Kasutajaliides

Kasutajaliides tuleb täielikult eraldi arendada loogikakomponendist ning ei eelda selle implementatsiooni olemasolu.

Kasutajaliides ja loogikakomponent suhtelvad omavahel üle HTTP protokolli ning ainult läbi eeldefineeritud liidestuse (vahetatakse ainult andmeid).

Kasutajaliides vahetab loogikakomponendiga ainult andmeid JSON vormignus, visuaalset sisu (nn. html-i javascripti) sellest komponendist ei laeta.

Kasutajaliides suhtleb loogikakomponentidega üle SSL kanali (SSL termineeritakse koormusjaoturis, kust kõik kasutaja päringud läbi lastakse).

Kasutajaliidese arendamisel tuleb rakendada micro-frontends arhitektuurimustrit, kasutades single-spa raamistikku.

Kasutajaliides peab jälgima SMIT stiiliraamatus sätestatut.

Andmebaas

Andmebaaside vahelised integratsioonid ei ole lubatud.

Andmebaase komponentide integratsioonivahendina ei tohi kasutada (mitu erinevat komponenti ühe andmebaasi poole pöörduda ei ole lubatud).

See põhimõte ei tähenda et ühte sama loogika komponenti jõudluse mõistes skaleerides ei tohiks kasutada sama andmebaasi.

Andmeobjektide muutmisel tuleb luua ka migratsiooniskriptid mis teisendavad automaatselt olemasolevad andmed uuele kujule. Migratsiooniskripte on soovitav käivitada paigaldusprotsessi ühe osana ja mitte määrata neid käivitatavaks iga rakenduse restardiga (see võib tekitada ebavajalikke lukke rakenduste restartimisel, kui neid on mitu instantsi).

Kõige lihtsam variant on määrata CI/CD keskkonna muutujaga, kas migratsioon käivitada. Mõistlik on migratsiooni teha ühe intsantsiga, kui see tehtud, siis teha vajadusel uuesti paigaldus mitme instantsiga. Alternatiiv on kasutada "job/task" tüüpi paigaldusmehhanisme tavalise rakenduse paigaldamise asemel.

Logimine

Logimisel tuleb arvesse võtta Infoturbeosakonna poolt kehtestatud logimise nõudeid.

Lisainfot leiab dokumendist Logimise nõuded.

Rakenduse tehnilised komponendid logivad korrelatsiooni ID'd või genereerivad selle ise. Korrelatsiooni ID'd saadetakse iga edasise päringuga kaasa.

Logi väljund peab olema JSON formaadis.

Java puhul võib kasutada näiteks: net.logstash.logback.encoder.LogstashEncoder

Tehnoloogilise võla mõõtmine (SonarQube) Tarkvaralahenduste tehnoloogilise võla mõõtmiseks kasutame täna ja edaspidi Sonar tarkvara  konfiguratsioonis määratletud mõõdikuid. Quality gate  Kasutada tuleb mõõdikut, mis on ka vaikimisi versioon ( ). Projektid mis on rohelised, läbivad edukalt SMIT SonarQube Quality Gate Sonar way arendusvaldkonna poolt kehtestatud alampiire. Kvaliteedimõõdikut mitteläbivad lahendused  tuleks üle vaadata ja teha vastavates kohtades parandusi, kas sonari raportite alusel parandada koodi või kirjutada täiendvaid teste. Allpool on lahti kirjutatud kõik erinevad mõõdikud, millest SMIT-i kvaliteedimõõdik koosneb ning millistel kuidas rakendus nendele vastama peab.

Teenuse kasutusjuhend: SonarQube kasutamine

SonarQube roadmap: https://portal.productboard.com/sonarsource/3-sonarqube/tabs/12-planned-for-10-6

Kõikide sonaris analüüsitavate tarkvarade ülevaade, kuidas nad vastavad kvaliteedimõõdikule, on leitav siit: ttps://sonar.smit.siseh

Coverage

Sonaris kasutame projekti KEY nimekujuna "ee.smit.<mskxx>.<toode>.<komponent/rakendus>". Mskxx on konkreetse meeskonna servicedeski MSK projekti key, aga sidekriipsuta ja väikeste tähtedega.

Alates 2024 kasutame uut põhimõtet Sonari analüüsides. Lühidalt paneme fookuse uue ja muudetava koodi kvaliteedi Clean as You Code mõõtmisele, mitte sellele mis on juba kunagi kirjutatud. Täpsemalt saab selle kohta lugeda: https://docs.sonarsource.com/sonarqube/10.6/user-

. Uus mõõdik analüüsib loodud või muudetud koodi viimase ajaaknas . Uue projekti lisamisel tuleb esmane guide/clean-as-you-code/ 90 päeva skaneerimine teha võimalikult minimaalse koodi pealt, muidu see ei rakendu kui uus kood kvaliteedimõõdiku all ja läheb koheselt "Overall" koodi alla. Suurim muudatus on 80% automaattestide kattuvuse nõue.

NB! Sonar ei analüüsi kas teie lahenduse Java/PostgreSQl/Spring Boot/Hibernate/Grails või mõni muu tehniline komponent/raamisitk on aegunud ja nö "võlas". Seda peaksite jälgima ise vastava komponendi lehelt, kus arendus toimub. Tulevikus võtame selle paremaks haldusesk kasutusele eraldi tarkvara.

Mõõdik määrab, mitu protsenti kogu lahenduse lähtekoodist on kaetud automaattestidega. Meil on määratud kriitiliseks alampiiriks Selleks et 80%.  efektiivselt tõsta kaetud koodi mahtu tasub kirjutada rohkem kõrgema taseme teste (integratsioonitestd ja funktsionaaltestid) ja lasta Sonar analüsaatoril koguda tulemusi kaetud ridade osas. Siin aitab kaasa näiteks Jacoco plugina kasutamine, mis antud info Sonarile edasi annab. Kuna pull-requestide üleandmisel on vajali kontrollida Sonari kvaliteedimõõdikut, tuleb testida käivitada iga ehituse käigus.

Duplicated Lines (%)

Mõõdik määrab mitu protsenti lähtekoodi koodist võib olla dubleeritud. Kvaliteedivärava läbimiseks on uus ülempiir 3%-i. Dubleeritud kood tekitab täiendavat ja põhjendamatut halduskoormust ning näitab, et koodis on palju refaktooringut tegemata sisulise funktsionaalsuse kasvades.

Maintainability Rating

Mõõdik määrab mitu protsentsi kogu rakendusele kulunud ajast on tekitanud tehnilist võlga  ) koodi stiili ja standarditele vastavuse osas. (Code Smell Lubatud maht on alla 5%-i ( ). Mõõdik annab välja ka info, mitu päeva kuluks koodi muutmiseks, eeldusel, et tegemist on 8 tunnise tööpäevaga.tase A

Reliability Rating

Mõõdik näitab palju on koodis erinevaid vigu. Kuna mõõdame nüüd ainult uut ja refaktooritud koodi ja mitte olemasolevat, siis ühtegi viga koodis ei tohi olla ( ). Täpsema ülevaate saab dokumentatsioonist, mille leiate, kui klikkate pealkirjas olevale lingile. Kood tuleb hoida  veavaba, mida Sonar veaks tase A defineeerib. Näiteks kui mõnel meetodil on ABC skoor liiga kõrge, tuleks see koheselt ringi kirjutada, ennem kui sinna tulevikus uut loogikat hakatakse lisama, sest see võib tekitada kas uusi vigu või on konkeetne meetod järgmisele arendajale loetamatu. Mõõdik annab välja ka info mitu päeva kuluks vigade parandamiseks, eeldusel, et tegemist on 8 tunnise tööpäevaga.

Security Rating

Mõõdik näitab palju on turvanõrkuseid rakenduses, mis on Sonari poolt tuvastatud (see ei tähenda et see kataks kõik turvatestide osa ära, aga teatud hulk owasp, cwe jms on välja toodud).  Kuna turvanõrkused on oma olemuselt kõrge riskiga vead, ei ole lubatud ühtegi turvanõrkust ( ). Mõõdik annab tase A välja ka info mitu päeva kuluks turvanõrkuste parandamiseks, eeldusel, et tegemist on 8 tunnise tööpäevaga.

Näidiskonfiguratsioon

# Execute SonarQube code analysis.

sonar.properties Java

# Required metadata =ee.smit.mskXX.applicationsonar.projectKey =Appsonar.projectName

# SonarQube server URL =https://sonar.smit.sisesonar.host.url

# Path to the source code =src/main/java,src/main/resourcessonar.sources

# Path to the test code =src/test/javasonar.tests

# Language and encoding =javasonar.language

=UTF-8sonar.sourceEncoding

# Java binaries and libraries =build/classes/java/mainsonar.java.binaries =build/libssonar.java.libraries

# Test report paths =build/test-results/test,build/test-results/integrationTestsonar.junit.reportPaths

=build/reports/jacoco/test/jacocoTestReport.xml,build/reports/jacocosonar.coverage.jacoco.xmlReportPaths /integrationTest/jacocoIntegrationTestReport.xml

# Java version =21sonar.java.source =21sonar.java.target

# Exclusions =**/generated/**, **/third-party/**sonar.exclusions

# Additional analyzers =.yaml,.ymlsonar.yaml.file.suffixes =.jsonsonar.json.file.suffixes

sonar.properties Vue

# Required metadata =your_project_keysonar.projectKey =Appsonar.projectName

# Path to the source code =srcsonar.sources

# Language and file inclusions =jssonar.language =**/*.js, **/*.vuesonar.inclusions

# Encoding of the source code =UTF-8sonar.sourceEncoding

# Exclude test files if needed =**/node_modules/**, **/*.spec.js, **/*.test.jssonar.exclusions

# Additional settings for JavaScript/TypeScript =coverage/lcov.infosonar.javascript.lcov.reportPaths

# Treat .vue files as JavaScript files =.js,.jsx,.vuesonar.javascript.file.suffixes

# Include CSS/SCSS analysis =.css,.scss,.vuesonar.css.file.suffixes

# Include HTML analysis =.html,.vuesonar.html.file.suffixes

if [[ "${bamboo_planRepository_branch}" == "develop" || "${bamboo_planRepository_branch}" == "main" ]]; then sonar-scanner -Dsonar.login="${bamboo_sonarTokenSecret}" -Dsonar.branch.name="${bamboo_planRepository_branch}" -Dsonar.projectVersion="${bamboo_planRepository_branch}" else sonar-scanner -Dsonar.login="${bamboo_sonarTokenSecret}" -Dsonar.pullrequest.key="${bamboo_repository_pr_key}" -Dsonar.pullrequest.branch= "${bamboo_repository_pr_sourceBranch}" -Dsonar.pullrequest.base= "${bamboo_repository_pr_targetBranch}" fi

Sobiliku image millega Sonarit käivitada leiab siit: https://source.smit.sise/projects/DOCKERHUB

Näiteks: docker.artifacts.smit.sise/dockerhub/eclipse-temurin-ci:21-jdk-alpine-latest

Lisa 2.2. CV vorm – Python arendaja (full-stack)

Hankija nimi: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440)

Riigihanke nimetus: Rändeinfosüsteemi MTA ja TI liidestuse arendustööd Riigihanke viitenumber: 284780

Ees- ja perenimi: ____________

Vastavustingimused rollile ja selle tõendamiseks esitatavad kohased andmed (kohustuslikud):

1. Isik on omandanud vähemalt keskhariduse

Haridustase,

haridusasutus

Õppimisaeg

(alates - kuni kuu/aasta)

Lõpetatud

(jah / ei)

Omandatud

haridus

(keskharidus, bakalaureus, magister vmt)

Põhieriala Välisriigis omandatud hariduse korral lisada

tõend/ lõputunnistuse koopia

2. Kogemused:

Nõue Nõude täpsustus Pakkuja kirjeldab nõuete täitmist. Andmete esitamisel

tuleb lähtuda RHR-i vastavustingimustes ja käesolevas

dokumendis toodud nõuetest.

Vajadusel lisada ridu

Spetsialisti rollile vastav

tööstaaž

kuudes

2.1. omab programmeerimise kogemust Python arendajana kokku vähemalt 36 kuud

1. Ettevõte/asutus, kus on töötanud/projekt, kus

kogemus on omandatud (riigihanke projekti

korral lisada selle number)

Kontaktisiku nimi ja kontaktid

(võib tõendada ka projektidega, sel

juhul tuua projektides välja kogemus

kuudes)

Kogemuse algus- ja lõppaeg kuu täpsusega

Kogemuse/projekti kirjeldus

/vajadusel lisada ridu/

2.2. omab programmeerimise kogemust front-end arendajana kokku vähemalt 18 kuud (võib tõendada ka projektidega, sel

juhul tuua projektides välja kogemus

kuudes)

1. Ettevõte/asutus, kus on töötanud/projekt, kus

kogemus on omandatud (riigihanke projekti

korral lisada selle number)

Kontaktisiku nimi ja kontaktid

Kogemuse algus- ja lõppaeg kuu täpsusega

Kogemuse/projekti kirjeldus

2. Ettevõte/asutus, kus on töötanud/projekt, kus

kogemus on omandatud (riigihanke projekti

korral lisada selle number)

Kontaktisiku nimi ja kontaktid

Kogemuse algus- lõppaeg kuu täpsusega

Kogemuse/projekti kirjeldus

/vajadusel lisada ridu/

3. Meeskonnaliikmete CV vormi esitamise nõuded minikonkursil

Pakkuja esitab meeskonnaliikmete andmed minikonkursil, täites iga nõutud meeskonnaliikme kohta minikonkursil etteantud CV vormi. Esitatud andmed peavad võimaldama hankijal kontrollida meeskonnaliikmete vastavust esitatud nõuetele ja hankija kontrollib tingimuste täitmist eelkõige

esitatud andmete alusel. Hankija määrab vajaliku meeskonna täpse koosseisu minikonkursil.

3.1. Kui hankija on selle minikonkursil lubanud, siis üks meeskonnaliige võib täita rohkem kui üht rolli, kui tal on vastavad kompetentsid ning

minikonkursil tellitav tööde maht ning tähtaeg on võimalik saavutada täites rohkem kui üle ühe rolli.

3.2. Kui minikonkursil tuleb välja tuua rolli tunnihind, siis tuleb arvestada, et täites samaaegselt rohkem kui ühte rolli, peab vastavate rollide

tunnihind olema sama.

3.3. Kui tingimuses on nõutud (kõrg)haridus, peab see olema lõpetatud.

3.4. Kui tingimuses ei ole nõutud töökogemust projektis, võib viidata ka töösuhtele. Projektiks ei loeta (varasemat) töösuhet.

3.5. Töökogemuse nõude täitmisena ei arvestata vabakutselisena tegutsemist, v.a kui selle perioodi osas on viidatud konkreetsetele

projektidele, millel on tellijaks kolmas isik.

3.6. Töökogemuse nõude täitmisena ei arvestata täiendkoolitust või koolitööd.

3.7. Kui tingimuses on nõutud konkreetse kestusega töökogemust, siis (ka osaliselt) kattuvaid perioode või samaaegsete projektide kattuvaid

aegu mitmekordselt ei arvestata. St sama ajaperioodi eest ei ole võimalik omandada mitmekordset kogemust.

3.8. Projektide andmete esitamisel tuleb iga projekti kohta esitada vähemalt: projekti nimi ja lühikirjeldus, projekti algus- ja lõppaeg

kalendrikuu täpsusega, projekti tellinud asutus ja tellija kontaktisik ning riigihanke korral märkida riigihanke number.

3.9. Viidatud projektid peavad olema pakkumuse esitamise ajaks nõutud mahus/ kompetentsi osas täidetud ja tellija poolt vastu võetud.

3.10. Projekti tellija peab olema kolmas isik, st projekti tellijaks ei saa olla (ühis)pakkuja ise või pakkumusse hõlmatud alltöövõtja või

(varasemas) töösuhtes tööandjale endale teostatud töö. Selliseid projekte on lubatud esitada üldise töökogemuse nõude täitmis eks

või näitlikustamiseks.

3.11. Hankijal on õigus pöörduda projekti/töö tellija poole esitatud andmete kontrollimiseks.

3.12. Kui mõne nõutud kompetentsi/kogemuse osas on andmed esitamata või viitab nende andmete mitteesitamise põhjenduseks

konfidentsiaalsusele ja/või nende alusel ei ole võimalik järeldada, kas nõue on täidetud, on hankijal õigus tunnistada pakkumus

mittevastavaks. Hankija ei avalda pakkumuses esitatud andmeid.

3.13. Juhul, kui lepingu täitmise käigus meeskonnas liikmeid asendatakse või täiendatakse, siis peab isik nõutud tingimustele vastama sellise

taotluse esitamise ajaks.

3.14. Kui see on objektiivselt võimalik, tuleb lugeda tingimusi täiendatuks märkega "või samaväärne". Samaväärsuse tõendamise kohus tus

lasub pakkujal, kes sellele tugineda soovib. Tõendid samaväärsuse kohta peavad olema esitatud pakkumuse koosseisus.

3.15. Tellijal on õigus CV-s esitatud informatsiooni kontrollida ja täpsustada, kuid juhul, kui mõnd nõutud kogemust ei ole CV-s esitatud, lähtub

hankija seisukohast, et pakkuja on vastava kogemuse kohta esitanud ammendavad andmed, st vastav kogemus meeskonnaliikmel puudub.

Koostatud 04.12.2024 12:46:01 1 / 1 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7849324/general-info

HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD

Viitenumber: 284780 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Rändeinfosüsteemi MTA ja TI liidestuse arendustööd

Pakkumuse maksumust hinnatakse - Ilma maksudeta Kriteeriumi kaalumise meetod - Osakaaludega Elektroonilist oksjoni kasutatakse: ei

Jrk nr

Nimetus Kirjeldus Tüüp / hindamismeetod

Osakaal Kogus Ühik Pakkuja täidetav

1 Pakkumuse kogumaksumus Pakkumuse kogumaksumus peab sisaldama kõiki tulemi saavutamiseks vajalikke kulusid

Maksumus - vähim on parim

100 jah

Kokku: 100

Hindamismetoodika kirjeldus 1.   Pakkumuse kogumaksumus

Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" * "osakaal".

1 / 1

Koostatud 04.12.2024 12:03:00 https://riigihanked.riik.ee/rhr-web/#/procurement/7849324/general-info

KÕRVALDAMISE ALUSED JA KVALIFITSEERIMISTINGIMUSED Viitenumber: 284780 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Rändeinfosüsteemi MTA ja TI liidestuse arendustööd

KÕRVALDAMISE ALUSED

KÕRVALDAMISE ALUSED

Hankija kontrollib edukal pakkujal vastavalt RHS § 30 toodule RHS § 95 lg 1 ja 4 kõrvaldamise aluseid enne lepingu sõlmimist. RHS § 95 lg 1 nimetatud kõrvaldamise aluste kontroll toimub riigihangete registri liidese ja EU Sanctions Map abil. Kui andmed ei ole hankijale päringute kaudu kättesaadavad, siis nõuab hankija edukalt pakkujalt enne hankelepingu sõlmimist kõikide asjakohaste andmete või dokumentide esitamist.

Kehtib: Kõik osad

Küsimused ettevõtjale: 1) Kinnitame, et meil puuduvad riigihangete seaduse § 95 lõikes 1 kirjeldatud kõrvaldamise alused ning saame aru, et kõrvaldamise aluse esinemisel kõrvaldatakse meid minikonkursilt riigihangete seaduse §-s 95 sätestatud korras. (Raadionupp valikutega "Jah/Ei") 2) Kinnitame, et meil puuduvad riigihangete seaduse § 95 lõikes 4 kirjeldatud kõrvaldamise alused ning saame aru, et kõrvaldamise aluse esinemisel kõrvaldatakse meid minikonkursilt riigihangete seaduse §-s 95 sätestatud korras. (Raadionupp valikutega "Jah/Ei")

Siseministeeriumi infotehnoloogia- ja arenduskeskus

Mäealuse 2/2, Tallinn 12618

Telefon 612 6200

E-post [email protected]

Reg. kood 70008440

www.smit.ee

27.12.2024 nr 3-17/666

Pakkumuse esitamise ettepanek minikonkursil raamlepingu nr 3-3/3330 alusel "Rändeinfosüsteemi MTA ja TI liidestuse arendustööd" (viitenumber 284780)

1. Üldteave

1.1. Raamleping: reg nr 3-3/3330.

1.2. Hanke eest vastutav isik: Paavo Kirsi ([email protected]).

1.3. Hanke liik: minikonkurss raamlepingu alusel, minikonkursi viitenumber 284780.

1.4. Eeldatav maksumus: 542 000 eurot km-ta.

1.5. CPV kood: 72200000-7.

1.6. Menetluse teostamise viis: e-menetlus eRHR vahendusel.

1.7. Hankelepingu kestus: lepinguliste kohuste täitumiseni (sh ka arve maksmise aeg)

1.8. Finantseerimisallikas: välisvahendid, Digipööre, RIS II etapp 2.osa RIS liidestus MTA

ja Tiga (PPA poolne osa), 1S70-RF21-01212-RIS2.

1.9. Pakkumuse esitamise tähtaeg: Pakkumuse esitamise täpne kuupäev ja kellaaeg

sätestatakse hankemenetluse eest vastutava isiku poolt eRHR-s. Hanke eest vastutaval isikul on

õigus muuta pakkumuste esitamise tähtaega ning teha alusdokumentides menetluse käigus

avastatud vajalikke mittesisulisi muudatusi ning parandusi. Pakkujal on õigus vajadusel teha

ettepanek pakkumuse esitamise tähtaja pikendamiseks.

1.10. Pakkumuse jõusoleku tähtaeg: vähemalt 3 kuud alates pakkumuse esitamise

tähtpäevast.

1.11. Hankija ootus huvitatud isikutele on, et pakkujad teavitaks hankijat aegsasti RHR kaudu

riigihanke alusdokumentides avastatud vigade, ebatäpsuste ja ebaselguste parandamiseks ja/või

teeks ettepaneku pakkujate hinnangul riigihanke eseme hankimiseks seatud

ebaproportsionaalsete või põhjendamatute piirangute leevendamiseks.

1.12. RHR üldandmetesse/hanketeate lahtris "lepingu täitmise tähtaeg" määratud kuupäev

tähendab lepingu kehtivust, mitte üksnes täitja kohustuste täitmise tähtaega ning lähtub seetõttu

nii täitja kui hankija/maksja kohustuste nõuetekohase täitmise tähtaegadest, sh hõlmatud on ka

hankija arve tasumiseks kuluv aeg. Pakkujal tuleb lepingu sõlmimise korral lähtuda enda

kohustuste tähtaegsel täitmisel lepingu projektis või tehnilises kirjelduses määratud

täitmise/lepingu eseme tarnimise tähtajast.

2(4)

1.13. Pärast hankelepingu sõlmimist esitab täitja iga oma alltöövõtja nime ja registrikood i

ning alltöövõtulepingu nimetuse, kuupäeva, numbri ja summa.

2. Minikonkursi dokumendid koosnevad käesolevast dokumendist ning järgmistest

lisadest:

2.1. Lisa 1- Hankelepingu projekt;

2.2. Lisa 1.1- SMIT TVL üldtingimused;

2.3. Lisa 2- Tehniline kirjeldus;

2.4. Lisa 2.1 - Logimise nõuded;

2.5. Lisa 2.2 - Lähtekoodi halduse ja ehitamise nõuded;

2.6. Lisa 2.3 - Rakenduste vahelised integratsiooninõuded ;

2.7. Lisa 2.4 - Tehnilised nõuded;

2.8. Lisa 2.5 - Tehnoloogilise võla mõõtmine;

2.9. Lisa 3 – Vastavustingimused (eRHR vorm);

2.10. Lisa 3.1. CV vorm - Python full-stack arendaja

2.11. Lisa 4 - Hindamiskriteeriumid ja hinnatavad näitajad (eRHR vorm);

2.12. Lisa 5 - Kõrvaldamise alused (eRHR vorm).

3. Olelusringi kulude arvestamine

3.1. Tegemist on hankijal juba olemas ja kasutuses oleva infosüsteemi arendustöödega.

Lepingu täitmise tulemusel ei teki uut iseseisvat infosüsteemi terviklahendust, mille

käitamine eeldaks märkimisväärsete täiendavate kulutuste tekkimist nt riistvarale või

erinevatele kaudsetele kuludele vmt ning mida saaks arvesse võtta ja lahendada käesoleva

minikonkursi raames. Infosüsteemi käitamisega seotud kulutuste määr on praktikas

üldjoontes välja kujunenud (lähtuvalt sihtotstarbest, kasutusintensiivsusest jpm) ning

tulenevalt hankija asutuse struktuurist ja eelarvestamise süsteemist on infosüsteemide

ülalpidamiskulude katmine lahendatud erinevate kombineeritavate tark- ja riistvaraliste

lahendustega, mida hangitakse teiste hangete kaudu. Lisaks on planeeritud katta suur osa

võimalikest tekkivatest olelusringikuludest hankija oma ressursiga.

4. Minikonkursil osalemise tingimused

4.1. Minikonkursi dokumendid moodustavad ühtse terviku. Dokumendid tehakse täitjatele

tasuta kättesaadavaks eRHR-i keskkonna vahendusel.

4.2. Minikonkursi dokumentide sisu kohta saab hankijalt selgitusi küsida kirjalikul

pöördumisel läbi eRHR-i keskkonna teabevahetuse töölehe. Hankija vastab esitatud

küsimustele esimesel võimalusel, võttes arvesse RHS § 46 lg 1 ja konkreetse

minikonkursi pakkumuste esitamise tähtaega.

5. Pakkumuse vormistamine, esitamine ja muutmine

5.1. Pakkumus tuleb esitada elektrooniliselt eRHR-i kaudu aadressil

https://riigihanked.riik.ee.

5.2. Dokumendid vormistada PDF-vormingus või mõnes muus üldlevinud vormingus.

3(4)

5.3. Kui esitatavate dokumentide koosseisus on kolmanda osapoole poolt kirjalikult

allkirjastatud dokumente, esitada dokument skaneeritud kujul ning originaaldokument

esitada ainult juhul, kui hankijal on tekkinud kahtlus dokumendi osas.

5.4. Samaväärsuse pakkumisel peab pakutav lahendus ühtima hankija olemasolevate

süsteemidega ning toote ja/või teenuse hind peab sisaldama kõiki migreerimisega seotud

lisatasusid. Pakkumus peab vastama esitatud nõuetele või olema sellega vähemalt

samaväärne, kuid ühilduma olemasoleva lahendusega. Samaväärsust tõendavad andmed

ja dokumendid esitab pakkuja koos pakkumusega. Pakkumuse samaväärsust kontrollivad

ja hindavad hankija vastavate erialateadmistega töötajad.

6. Pakkumuste vastavuse kontrollimine

6.1. Pakkumus tunnistatakse vastavaks, kui see vastab kõikidele minikonkursi tingimuste le

ning selles ei esine sisulisi kõrvalekaldumisi esitatud tingimustest. 6.2. Pakkumuses esitatud andmed peavad olema tõesed, esitatud viisil ja piisava detailsusega,

mis võimaldavad hankijal kontrollida nende vastavust riigihanke alusdokumentides toodud tingimustele.

6.3. Hankija nõudel peab täitja pakkumuses esitatud teavet selgitama, piiritlema või

täpsustama.

6.4. Hankijal on õigus lükata pakkumus tagasi, kui see ei vasta minikonkursis esitatud

tingimustele ning juhul, kui täitja on esitanud lisatingimusi, mis ei ole kooskõlas

minikonkursi tingimustega.

6.5. Hankija lükkab pakkumuse tagasi, kui hankelepingu sõlmimine selle pakkumuse alusel

rikuks rahvusvahelist sanktsiooni rahvusvahelise sanktsiooni seaduse tähenduses

(RSansS).

6.6. Hankija võib minikonkursi käigus esitatud pakkumusi hinnata enne pakkumuste vastavuse või pakkujate suhtes kõrvaldamise aluste puudumise kontrollimist. Sellise l

juhul kontrollib hankija pakkumuse vastavust ja kõrvaldamise aluste puudumist vaid pakkujal, kellega ta kavatseb hankelepingu sõlmida. Kui selle pakkuja pakkumus osutub kontrollimise tulemusena mittevastavaks või pakkuja kõrvaldatakse minikonkursilt, on

hankijal õigus teostada kirjeldatud kontrollid hindamise tulemusena paremusjärjestuses järgmise pakkuja osas.

7. Pakkumuste hindamine, edukaks tunnistamine või tagasi lükkamine

7.1. Hankijal on õigus pakkumus tagasi lükata ja otsustada hankelepingut mitte sõlmida või

vastavalt raamlepingule minikonkurss kehtetuks tunnistada, kui:

7.1.1. pakkumus(ed) ei vasta tingimustele;

7.1.2. pakkumus(ed) ületavad eeldatavat maksumust;

7.1.3. tellija ei saa projektile rahastust.

7.2. Hankijal on õigus enne hankelepingu sõlmimist tunnistada minikonkurss omal algatuse l

põhjendatud vajadusel kehtetuks, teavitades sellest pakkujaid.

7.3. Raamlepingu punktis 4.16.2 toodud hindamiskriteeriumide alusel tunnistab hankija

edukaks madalaima kogumaksumusega pakkumuse. Tulemi kogumaksumus peab

sisaldama kõiki tulemi saavutamiseks vajalikke kulusid.

8. Kõrvaldamise aluste kontrollimine, eduka pakkuja äralangemine

4(4)

8.1. Hankija kontrollib pakkujal, kellega ta kavatseb hankelepingu sõlmida RHS § 95 lõikes

1 ja 4 sätestatud kõrvaldamise aluseid. Hankija ei sõlmi hankelepingut pakkujaga, kellel

esineb mõni § 95 lõikes 1 nimetatud kõrvaldamise alus ning hankija võib kõrvaldada

minikonkursilt pakkuja, kellega ta kavatseb hankelepingu sõlmida, kui sellel pakkujal

esineb mõni RHS § 95 lõikes 4 nimetatud kõrvaldamise alus.

8.2. Kui pakkuja, kellega hankija kavatseb hankelepingu sõlmida, kõrvaldatakse minikonkursilt,

nimetatud pakkuja võtab hankijast mitteolenevatel põhjustel oma pakkumuse tagasi või ei

allkirjasta hankelepingut 5 tööpäeva jooksul, mida käsitletakse kui pakkumuse tagasi võtmist

RHS § 119 tähenduses, hindab hankija kõiki ülejäänud minikonkursi pakkumusi uuesti ja

tunnistab soodsaimaks pakkumuse, mis on pakkumustest majanduslikult soodsaim. Hankija

ei ole kohustatud pakkumusi uuesti hindama ja võib tunnistada soodsaimaks esialgsel

hindamisel edukuselt järgmiseks osutunud pakkumuse juhul, kui soodsaimaks tunnistatud

pakkumuse äralangemine ei saa mõjutada ülejäänud pakkumuste omavahelist järjestust.

8.3. Hankija rakendab RHS § 97 ja pakkuja võib esitada koos pakkumusega või hankija nõudmisel

tõendeid heastamismeetmete kohta.

Lugupidamisega

(allkirjastatud digitaalselt)

Mart Nielsen

peadirektor

Lisa: Loetletud punktis 2

Paavo Kirsi, [email protected]

1 / 2

Koostatud 04.12.2024 12:45:01 https://riigihanked.riik.ee/rhr-web/#/procurement/7849324/general-info

VASTAVUSTINGIMUSED Viitenumber: 284780 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Rändeinfosüsteemi MTA ja TI liidestuse arendustööd

PAKKUMUSE ESITAMINE Pakkumuse esitamisega kinnitab pakkuja kõigi riigihanke alusdokumentides esitatud tingimuste ülevõtmist.

Tingimusliku pakkumuse esitamine ei ole lubatud.

Küsimused ettevõtjale: 1. Kas ettevõtja saab kinnitada, et pakkumus vastab hanke alusdokumentides sätestatud tingimustele? (Raadionupp valikutega "Jah/Ei")

2. Kinnitame, et käesolev pakkumus on jõus 3 kuud ja on esitatud tingimustel pakkujale siduv, alates pakkumuste esitamise tähtpäevast (Raadionupp valikutega "Jah/Ei")

3. Andmed lepingusse, mida kasutatakse juhul, kui pakkumus tunnistatakse edukaks. Pakkuja esitab andmetena: 1. ettevõtte Nimi, reg.kood, aadress; 2. lepingu allkirjastaja nimi; 3. alus lepingu allkirjastamiseks (juhatuse liige, volikiri vm); 4. lepingu allkirjastaja ametinimetus; 5. pakkuja kontaktisik lepingu täitmisel (nimi, ametinimetus, telefoni number ja e-posti aadress) (Suur sisestusala (max pikkus 4000 tähemärki))

4. Kas pakkujal on isikuid, kellel on volitus ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, ning kelle olemasolu ei kajastu äriregistris? Kui jah, esitab pakkuja eelpool nimetatud isikute ees- ja perekonnanime, isikukoodi ning esinduse aluse, et hankija saaks nende puhul viia läbi kõrvaldamise aluste kontrolli vastavalt RHS § 95 lg 1 p 1- 3 ja 5. (Suur sisestusala (max pikkus 4000 tähemärki))

5. Pakkuja kinnitab, et on teadlik, et ta peab esitama hankelepingu täitmise alustamise ajaks iga oma alltöövõtja nime, registrikoodi, kontaktandmed, teabe nende seaduslike esindajate kohta ning alltöövõtulepingu nimetuse, kuupäeva, numbri ja summa. Samad andmed esitab täitja iga hankelepingu täitmisel lisanduva alltöövõtja kohta (Raadionupp valikutega "Jah/Ei")

ÄRISALADUS Pakkuja märgib pakkumuses, milline teave on pakkuja ärisaladus ning põhjendab teabe määramist ärisaladuseks.

Teabe ärisaladuseks määramisel lähtutakse ebaausa konkurentsi takistamise ja ärisaladuse kaitse seaduse § 5 lõikes 2 sätestatust. Pakkuja ei või ärisaladusena märkida: 1) pakkumuse maksumust ega osamaksumusi; 2) teenuste hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid numbrilisi näitajaid; 3) asjade ja ehitustööde hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid näitajaid (RHS § 46 (1)).

Küsimused ettevõtjale: 1. Kirjeldage lühidalt pakkumuses sisalduvat ärisaladust ja lisage selle määramise põhjendus või märkige, et pakkumus ei sisalda ärisaladust. (Suur sisestusala (max pikkus 4000 tähemärki))

3. Kas ärisaladus ning selle määramise põhjendus on pakkumuses märgitud? (Raadionupp valikutega "Jah/Ei")

EL NÕUKOGU SANKTSIOON. ALLTÖÖVÕTJAD JA TARNIJAD. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid ega tarnijaid, kes on: 1. Vene Föderatsiooni kodanik, resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis;

2 / 2

Koostatud 04.12.2024 12:45:01 https://riigihanked.riik.ee/rhr-web/#/procurement/7849324/general-info

3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku juhiste alusel. Hankija lükkab tagasi pakkumuse, mille alusel sõlmitav hankeleping oleks RSanS § 7 lg 1 alusel tühine.

Määrust kohaldatakse riigihangetele alates rahvusvahelisest piirmäärast. NÕUKOGU MÄÄRUS (EL) 2022/576, 8. aprill 2022, millega muudetakse määrust (EL) nr 833/2014, mis käsitleb piiravaid meetmeid seoses Venemaa tegevusega, mis destabiliseerib olukorda Ukrainas.

Küsimused ettevõtjale: 1. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid ega tarnijaid, kes on: 1. Vene Föderatsiooni kodanik, resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis; 3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku juhiste alusel. (Raadionupp valikutega "Jah/Ei")

SAMAVÄÄRSUS Pakkuja kinnitab, et pakkumus vastab hanke alusdokumentides nõutule ja vajadusel on samaväärsus selgitatud ja tõendid samaväärsuse kohta lisatud.

Iga viidet, mille hankija teeb riigihanke alusdokumentides mõnele RHS-i § 88 lõikes 2 nimetatud alusele (standardile, tehnilisele tunnustusele, tehnilisele kontrollisüsteemile vms), tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“. Iga viidet, mille hankija teeb riigihanke alusdokumentides ostuallikale, protsessile, kaubamärgile, patendile, tüübile, päritolule, tootmisviisile, märgisele või vastavushindamisasutuse väljastatud katsearuandele või tõendile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“ (RHS § 88 lg-d 5-6, § 89 lg 2, 114 lg-d 5-7). Hankija aktsepteerib objektiivsetel põhjustel muid asjakohaseid tõendeid, kui pakkuja tõendab hankijale vastuvõetaval viisil, et pakutav asi, teenus või ehitustöö vastab konkreetse märgise või hankija esitatud nõuetele, välja arvatud juhul, kui hankija nõutud märgis, samaväärne märgis või konkreetse või samaväärse vastavushindamisasutuse väljastatud katsearuanne või muu tõend on seaduse alusel eelduseks asja, teenuse või ehitustöö pakkumiseks turul (RHS § 114 lg 7).

Küsimused ettevõtjale: 1. Pakkuja kinnitab, et pakkumus vastab hanke alusdokumentides nõutule ja vajadusel on samaväärsus selgitatud ja tõendid samaväärsuse kohta lisatud. (Raadionupp valikutega "Jah/Ei")

VÕTMEROLLIS PYTHON ARENDAJA (FULL STACK) ARENDAJA

Pakkuja esitab võtmerolli täitja CV, kes peab vastama kõigile Python arendaja (full stack) CV vormil toodud nõuetele. Esitatud andmed peavad võimaldama hankijal kontrollida meeskonnaliikme vastavust esitatud nõuetele ja hankija kontrollib tingimuste täitmist eelkõige esitatud andmete alusel. Rolli on lubatud täita ühel isikul. Hankija eelduslik koormus rollile on täistööaeg.

Küsimused ettevõtjale: 1. Pakkuja esitab Python arendaja (full stack) CV (Vabas vormis dokument)