dokumendiregister.ee
OtsingAsutusedMCP
Otsing›Rahandusministeerium
Sissetulev kiriAvalik

Hankija täiendav seisukoht ja menetluskulude nimekiri

Rahandusministeerium · 30. juuni 2026
Viit
12.2-10/26-130/172-12
Registreeritud
30. juuni 2026
Dokumendi liik
Sissetulev kiri
Adressaat
Tallinna Linnateater
Saabumis/saatmisviis
DVK/e-post
Funktsioon
12.2 RIIGIHANGETEALANE TEGEVUS
Sari
12.2-10 Riigihangete vaidlustusmenetluse toimikud
Toimik
12.2-10/26-130
Vastutaja
Angelika Timusk (Rahandusministeerium, Riigihangete vaidlustuskomisjon)

Failid

  • 📎Andres Käver eksperdiarvamus.bdoc92 KB
  • 📎seisukoht-kulud.Linnateater-Delfi.2026-06-29.final.asice312 KB

Sisu (failidest)

Eksperdi arvamus Koostatud: Riigihangete vaidlustuskomisjonile (VAKO) seoses vaidlustusasjadega nr 128-26/- ja nr 129-26/- - Piletilevi ja Delfi Meedia vaidlustused Tallinna Linnateatri ostumenetluse „Piletimüügiplatvormi ja kliendihalduse teenus" alusdokumentide peale. Arvamuse koostaja: Andres Käver, TalTech lektor, [email protected] 10+ aastat õppejõud ainetes: - Platvormipõhised mobiilirakendused (iOS, Android) - Hübriidmobiilirakendused (Flutter/Dart, React Native, Xamarin, PWA, jne) - Javascript Lähtekohad Käesolev arvamus käsitleb tehnoloogilisi ja kasutajamugavusest lähtuvaid erinevusi platvormipõhise mobiilirakenduse (native app) ja progressiivse veebirakenduse (PWA - progressive web app) vahel. Olen vastanud küsimustele üksnes tehnilistest asjaoludest ja oma erialasest hinnangust lähtuvalt, sõltumata menetlusosaliste positsioonidest. Kuna erinevused sõltuvad oluliselt mobiiliplatvormist, olen platvormispetsiifilised väited sidunud konkreetselt Apple iOS-i ja Google Androidiga. Eristan järjekindlalt kaht asja: (a) kas funktsioon on üldse võimalik (võimekus) ja (b) kui usaldusväärselt, mugavalt ja millise vaevaga see toimib (aste). Mitmes punktis on tegu just astme-, mitte võimekuse-erinevusega. Kõige vaieldavamate väidete juurde olen lisanud viited (dokumendi lõpus). Küsimus 1 Lihtsustatult, õieti mida kujutavad endast mobiilirakendus (native app) ja mobiilisõbralik veebirakendus (progressive web app) ning mis on nende peamised erinevused? Mobiilirakendus (native app) on konkreetsele platvormile (Apple iOS või Google Android) ehitatud programm täieliku juurdepääsuga platformile, mida levitatakse rakendustepoodide (App Store, Google Play) kaudu ja mis paigaldatakse seadmesse. Progressiivne veebirakendus (PWA) on veebileht, mida on täiendatud taustal töötava skripti (service worker) ja seadistusfailiga (manifest); seda saab samuti „paigaldada" seadme avakuvale, see töötab osaliselt võrguühenduseta ja võib toetada push- teavitusi. PWA töötab brauseri mootoris (iOS-il alati Apple WebKit / Safari mootor). Oluline täpsustus: ka PWA on teatud mõttes „paigaldatav" - selle saab avakuvale lisada. Seetõttu ei erista mõisted „native" ja „PWA" mitte „paigaldatav vs paigaldamatu", vaid erinevad on paigaldamise viis, sügavus ja usaldusväärsus. Peamised erinevused: Mobiilirakendus (native) PWA Levitamine / paigaldus App Store / Google Play, üks veebilingilt „lisa tuttav samm avakuvale"; iOS-il käsitsi ja vähem avastatav Seadme funktsioonid täielik ligipääs enamik levinud funktsioone; osa puudub (platvormiti erinev) Võrguühenduseta töö jah jah (service worker + Cache API) Push-teavitused jah, küps jah; iOS-il alates v16.4, piiratum Uuendamine rakendustepoe kaudu kohe, serverist Leitavus ja usaldus poe otsing, edetabelid, poe- veebiotsing ja lingid usaldus Küsimus 2 Kas on alust väita, et progressive web app on tehnoloogiliselt või kasutajamugavuse poolest samaväärne native app'iga? Mitte täielikult - kuid erinevused on pigem astme, usaldusväärsuse ja platvormi (eelkõige iOS) küsimus kui võimekuse küsimus. Google Androidil on hästi ehitatud PWA tüüpilise piletimüügi kasutuse jaoks native-rakendusele suuresti samaväärne. Apple iOS-il jäävad reaalsed erinevused: paigaldamise avastatavus ja mugavus (vt küsimus 4), push-teavituste töökindlus (küsimus 6), lokaalselt salvestatud andmete ja sisselogimise püsivus (küsimus 4) ning kasutajakogemuse järjepidevus. Samas - milliseid funktsioone üldse täita saab - suudab korralik PWA/mobiiliveeb täita sisuliselt kõik piletimüügi põhifunktsioonid (sirvimine, ost, pileti kuvamine ja haldamine, võrguühenduseta kuvamine, kasutajakontod, analüütika, teavitused). Seega: „samaväärne" on absoluudina liiga tugev väide (erinevused on olemas, eriti iOS-il), kuid sama ebatäpne oleks väita, et tegu on põhimõtteliselt erineva võimekusega. Küsimus 3 Kas teie hinnangul esineb põhjusi, miks üks rohkearvuliselt külastatav teater võiks soovida, et nende piletite müük toimuks mobiilis native app'i, mitte progressive web app'i kaudu? Jah, selliseid põhjuseid on - kuid need on usaldusväärsuse ja kasutajakogemuse, mitte ainulaadse võimekuse põhjused ning avalduvad eelkõige iOS-il: 1. iOS-il on poest paigaldatav native-rakendus oluliselt lihtsamini avastatav, paigaldatav ja taasleitav kui PWA, millel puudub automaatne paigaldusviip ja App Store'i kohalolu (küsimus 4) - see on oluline, kui eesmärk on korduvalt kasutatav, paigaldatud rakendus pikaajalise suhte jaoks; 2. töökindlam push-taaskaasamine (küsimus 6); 3. lokaalse salvestuse ja sisselogimise suurem püsivus iOS-il (küsimus 4); 4. järjepidevam ja kontrollitavam kasutajakogemus ning avakuva-kohalolu; 5. rakendustepoe usaldus ja leitavus. Kuna hanke üks rõhuasetus on kliendihaldus ja pikaajaline kliendisuhe (mitte üksnes ühekordne müük), on neil teguritel reaalne kaal. Aus täpsustus: ühekordse, veebist algava pileti­ostu puhul on need eelised väiksemad ning sama eesmärki saab suures osas täita ka korraliku PWA/veebilahenduse ja Apple/Google Wallet'i piletitega; tegu on kaalumisotsusega, kui suur kaal anda usaldusväärsusele, kasutajakogemusele ja korduvkaasatusele. Küsimus 4 Kas faktina on õige väide, et PWA võimaldab „püsivat sisselogimist", „avakuvale paigaldamist", „push-teavitusi", „lojaalsusprogramme" ja „kasutajate taasaktiveerimist"? Kui vastus on jah, st see väide on faktina õige, siis kas ikkagi ja kuidas täpsemalt on PWA puhul need võimekused piiratumad, tehnoloogiliselt mahajäänumad või tarbija vaatest ebamugavamad kui native app'i puhul? Jah, faktina on kõik need võimekused kaasaegses PWA-s tehniliselt olemas - püsiv sisselogimine, avakuvale paigaldamine, push-teavitused (iOS-il alates versioonist 16.4, märts 2023), lojaalsusprogrammid ja kasutajate taasaktiveerimine. Erinevused on astme ja usaldusväärsuse erinevused, mis koonduvad iOS-ile: - Avakuvale paigaldamine: iOS-il puudub automaatne paigaldusviip (Safari ei toeta beforeinstallprompt-mehhanismi); kasutaja peab leidma käsu „Jaga → Lisa avakuvale" mitme sammuga ning PWA-d ei ole App Store'is, mistõttu paigaldusmäär ja avastatavus on madalamad [2]. Native-rakenduse paigaldab kasutaja poest ühe tuttava sammuga. - Push-teavitused: iOS-il toimivad ainult avakuvale lisatud PWA puhul ja on vähem töökindlad kui native (vt küsimus 5) [1]. - Püsiv sisselogimine: iOS-il võib Safari kustutada (ja PWA rakendus on reaalsuses Safari kaudu töötav veebileht) skriptiga kirjutatava salvestuse (sh sisselogimise tunnused) pärast 7 päeva kasutamata jätmist [3]; sageli avatava rakenduse puhul on mõju väike, pikkade pauside korral võib kasutaja end välja logituna leida. Native salvestab tunnused püsivalt. - Lojaalsus ja taasaktiveerimine: sõltuvad push'ist ja püsivast salvestusest, mis iOS-il on mõlemad nõrgemad - funktsioon on olemas, kuid vähem usaldusväärne. Küsimus 5 Kas ja millised on native app'ide ja PWA-de tehnoloogilised ja kasutajamugavusest lähtuvad erinevused seoses push-teavitustega, seda iseäranis Apple'i iOS-i peal? Erinevused on olemas ja kõige selgemad iOS-il, kuid need on töökindluse ja mugavuse, mitte „ainult native" erinevused. Veebipõhised push-teavitused on iOS-il olemas alates versioonist 16.4. Native push (Apple APNs) on küpsem ja võimekam: rikkalikum sisu (tegevusnupud, pildid, ikoonimärgid), ei eelda PWA eelnevat avakuvale lisamist ning on operatiivselt töökindlam. PWA push iOS-il eeldab rakenduse avakuvale lisamist, kasutaja otsest luba/kinnitust ning praktikas on teatatud usaldusväärsuse tõrgetest (nt tellimuse katkemine) [1]. Androidil on vahe väike. Teatri jaoks, kus teavitus on oluline kanal, on native iOS-il töökindlam valik - reaalne, kuid piiritletud eelis, mitte „PWA ei võimalda push'i". Küsimus 6 Kas Teie hinnangul on alust väita, et native app võimaldab ehitada paremat kliendisuhet ja -lojaalsust kui PWA? Kui jah, siis miks? Teatav alus on, kuid see on astme küsimus, mitte PWA-l puuduv võimekus. Kliendisuhte ja lojaalsuse vahendid - püsikliendikonto, ostuajalugu, personaalsed pakkumised, uudiskirjad, teavitused, segmenteerimine - toimivad ka veebipõhise konto ja mobiilivaate kaudu. Native reaalne, piiritletud eelis on töökindlam taaskaasamise kanal (push, küsimus 5), püsiv avakuva-kohalolu ja vastupidavam sisselogimine, eriti iOS-il, mis võivad muuta paigaldatud rakenduse tugevamaks kordussuhte puutepunktiks - kui kasutajad selle ka paigaldavad ja alles hoiavad. Lojaalsus ei „eelda" siiski native't; otsekontakti kanalid (sh push, e-post) eeldavad GDPR-nõusolekut tehnoloogiast sõltumata. Vt ka küsimused 4 ja 5. Kokkuvõte: native'il on iOS-il mõõdukas kaasatuse- ja töökindluseelis, mitte ainulaadne lojaalsusvõimekus. --- Kokkuvõte Platvormipõhine native-rakendus ja PWA ei ole täielikult samaväärsed, kuid reaalsed erinevused on valdavalt astme, usaldusväärsuse ja kasutajakogemuse erinevused, mis koonduvad Apple iOS-ile (paigalduse avastatavus, push'i töökindlus, lokaalse salvestuse ja sisselogimise püsivus, kasutajakogemuse järjepidevus) ning on kõige asjakohasemad pikaajalise, paigaldatud rakenduse kliendisuhte jaoks. Samal ajal suudab korralik PWA/mobiiliveebilahendus võimekuse tasandil täita piletimüügi põhifunktsioonid Viited Viited on illustratiivsed; tehnoloogiliste põhiväidete aluseks on platvormide (Apple, Google) dokumentatsioon ja avalikud veebistandardite allikad. 1. PWA push-teavituste tugi ja piirangud iOS-il (16.4+, avakuvale, töökindlus): MDN Web Docs, *Push API*; ülevaade magicbell.com/blog/pwa-ios-limitations-safari- support-complete-guide 2. iOS paigaldushõõre, *beforeinstallprompt* puudub Safaris: MDN Web Docs, *Making PWAs installable* 3. Safari 7-päevane piirang skriptiga kirjutatavale salvestusele (WebKit ITP): Search Engine Land, *What Safari's 7-day cap on script-writeable storage means* Riigihangete vaidlustuskomisjon Tallinn Advokaadibüroo NOVE OÜ 29.06.2026 Registrikood 12984303 Kentmanni tn 4, 10116 Tallinn Tel: +372 610 8010 [email protected] www.nove.ee Andrus Kattel Heili Püümann Allkirjastatud digitaalselt Arsi Pavelts, PhD Laura Raadik Kristjan Tamm Kristiina Koll Veikko Puolakainen Madis Abel ESITATUD E-POSTI TEEL Mari Past Indrek Niklus Andra Olm Liis Kikas [email protected] Sten Tikerpe Kaisa Poller Mart Parind Karolyn Krillo Marika Mugur Krete Hänman Maris Vutt, PhD Rainis Loit HANKIJA TÄIENDAVAD SEISUKOHAD // MENETLUSKULUDE NIMEKIRI Vaidlustusasja nr: 129-26/- Riigihange: „Piletimüügiplatvormi ja kliendihalduse teenus“ Vaidlustaja: Delfi Meedia AS Registrikood 10586863 Vaidlustaja esindajad: Vandeadvokaat Erki Fels Advokaat Gregor Saluveer Advokaadibüroo TEGOS e-post [email protected] Hankija: Tallinna Linnateater Registrikood 75016094 Hankija esindaja: Vandeadvokaat Mart Parind Advokaadibüroo NOVE e-post [email protected] NOVE - 2/6 - I MENETLUSE SENINE KÄIK 1. Riigihangete vaidlustuskomisjoni („VAKO“) menetluses on Delfi Meedia AS („Vaidlustaja“) vaidlustus Tallinna Linnateatri („Hankija“) riigihanke „Piletimüügiplatvormi ja kliendihalduse teenus“ alusdokumentide peale. 2. Pärast Hankija 17.06.2026 vastust vaidlustusele esitas Vaidlustaja 22.06.2026 VAKO-le oma täiendavad seisukohad. 3. VAKO 17.06.2026 kirjaliku menetluse teate kohaselt on Hankijal võimalik kuni 29.06.2026 Vaidlustaja täiendavatele seisukohtadele vastata. 4. Käesolevaga esitab Hankija Vaidlustaja täiendavatele seisukohtadele omapoolse vastuse. Ühtlasi sisaldab siinne menetlusdokument Hankija täiendavat menetluskulude nimekirja. II VASTUVÄITED VAIDLUSTAJA SEISUKOHTADELE 5. Alustuseks saab Hankija avaldada rahulolu, et Vaidlustaja tegelikult nõustub, et Eesti kohtupraktika on küsimuses, kui laiaulatuslik on hankija otsustusvabadus hanke eseme ja sellele esitatavate nõuete määratlemisel, kujunenud just selliseks nagu Hankija vastuse p-des 15–19 välja toodud.1 Selle kohtupraktika resümee on: hankija otsustusruum on väga lai ning hankija ei pea konkurentsi kunstlikult juurde tekitama, rahuldudes halvemaga kui tema soovid ja vajadused eeldavad. Nõutav on, et hankija suudaks vaidlustamise korral esitada tema seatud nõuete kohta mõistlikud ja veenvad põhjendused. 6. Ka on selgunud, et Vaidlustaja tegelikult nõustub, et vaidlusalusele hankele kohaldub üksnes RHS § 3.2 Täiendavate seisukohtade lõpuosas Vaidlustaja siiski irdub sellest, viidates RHS §-le 88 ja väites, et sealsed reeglid kehtivad ka RHS § 3 kaudu.3 See ei pea paika. RHS 2. ptk sätteid, mis seadusest endast tulenevalt konkreetsele riigihankele ei kohaldu, ei ole võimalik selliselt § 3 kaudu kohalduvaks muuta. Liiatigi näib Vaidlustaja unustavat, et vastavalt Riigikohtu praktikale tuleb alla lihthanke piirmäära jäävates hangetes RHS §-s 3 sätestatud üldpõhimõtteid kohaldada leebemalt.4 Olles öelnud eelnevat, ei soovi Hankija siiski mõista anda ega annagi mõista, et ta on kuidagigi tehnilise kirjelduse koostamisel konkurentsi kunstlikult kitsendanud. Olgu ka märgitud, et isegi kui rääkida RHS § 88 lg-st 6, siis selle sätte järgi ei tohi tehnilises kirjelduses nimetada kindlat „ostuallikat, protsessi, kaubamärki, patenti, tüüpi, päritolu ega tootmisviisi“. Mobiilirakenduse nõue ei ole ükski neist, tegu on funktsionaalsusega – vt rohkem all p 12 ja 13. 7. Vaidlustaja seisukohad satuvad laiemalt eksiteele sealtmaalt, kus ta väidab mobiilirakenduse nõude „riigihanke eesmärgi suhtes“ ebaproportsionaalse ja põhjendamatu olevat.5 Sellise väite vältimatu eeldus on, et on teada ja defineeritud, mis on riigihanke eesmärk. Hankijale arusaadavalt ei ole Vaidlustaja hanke eesmärki üheselt defineerinud, vaid opereerib mingi selgelt välja hääldamata omapoolse arusaamaga sellest, mida Hankija soovib hankega saavutada. Olgu sellega kuidas on – peamine on, et pakkuja ei saa hanke eesmärki sisustada hankija eest.6 Riigihanget korraldab, s.o toodet või teenust soetab hankija ning seega on üksnes hankija määrata, milleks ja täpsemalt milliseid omadusi omavana ta hanke eset vajab. Nõnda on ka VAKO praktikas leidnud kinnitust, et hanke eesmärgi määrab ära just hankija tahe.7 8. Hankija ei ole riigihanke eesmärki lühidal valmiskujul hanke alusdokumentides defineerinud. See ei ole ka ühegi õigusaktiga nõutav. Ostumenetluse kutse ptk 2 (tehniline kirjeldus) sisse- juhatuses on öeldud, et „Hankija eesmärgiks on leida teenusepakkuja, kes võimaldaks hankijale ligipääsu teenusepakkuja platvormile /---/, mis peab vastama vähemalt alljärgnevatele nõuetele.“ 1 Vaidlustaja täiendavate seisukohtade p 4. 2 Samas. 3 Samas, p 21. 4 Vt Hankija vastuse p 9. 5 Vaidlustaja täiendavate seisukohtade p 5. 6 Seda on Vaidlustaja teinud nt oma täiendavate seisukohtade p-s 14. 7 Nt VAKOo 16-22/244231, p 13. NOVE - 3/6 - Seeläbi on Hankija oma eesmärgi defineerinud ristviiteliselt, öeldes, et ta soovib reale konkreet- setele nõuetele vastavat tervikteenust. Tehnilise kirjelduse nõudeid siin kordamata võib lühidalt kokku võtta, et Hankija seatud nõuetest lähtuvalt on tema eesmärk saavutada olukord, kus tema etenduste piletite müük ja haldus toimub nii piletiostja kui Hankija vaatest tehnoloogiliselt kõige arenenumal moel ning seades esikohale parima kasutusmugavuse. Sellest tuleb lähtuda ka käesoleva vaidluse lahendamisel. 9. Hankija ei nõustu, et mobiilirakenduse nõue on eelmises punktis defineeritud hanke eesmärki silmas pidades ebaproportsionaalselt range. Hankija on seda selgitanud juba vastuses vaidlustu- sele ning siin, kummutamaks Vaidlustaja väiteid ja andmaks enda 17.06.2026 vastusele autoriteetset ja erapooletut toetust, esitab Hankija Tallinna Tehnikaülikooli IT-kolledži lektori, 30+ aasta pikkuse tarkvara arendamise kogemusega ja 10+ aastat ülikoolis platvormipõhistest mobiilirakendustest (Android, iOS), hübriidmobiilirakendustest (Flutter/Dart, React Native, Xamarin, PWA jne) ning Javascriptist loenguid andva Andres Käveri eksperdiarvamuse (vt lisa). Siin seda arvamust tarbetult kordamata võib kokku võtta, et ka valdkonna tunnustatud ekspert kinnitab, et native rakendusel on PWA ees mitmeid eeliseid, nii infotehnoloogilisi kui kasutajamugavusega seotuid. Ekspert sõnaselgelt tunnistab, et native rakendus ja PWA ei ole samaväärsed. Järelikult ei ole Hankijast meelevaldne nõuda native rakenduse põhist piletimüüki ja -haldust. 10. Esitatud eksperdiarvamus on Hankija hinnangul piisav, et kõrvaldada Vaidlustaja välja toodud kahtlused. Hankija ei pea vajalikuks Vaidlustaja etteheiteid allpool veel täiendavalt kummutama hakata. Sellegipoolest peab Hankija oma õiguste igakülgseks kaitseks vajalikuks märkida järgmist. 11. Kõigepealt ja üldkohalduvana, Vaidlustaja kõik tehnoloogilised väited on jätkuvalt palja- sõnalised. Vaidlustaja ei ole enda väidete toetuseks esitanud ainsatki tõendit, olgugi et ka riigihanke vaidlustusmenetluses kehtib põhimõte, et iga menetlusosaline peab tõendama enda esitatud väiteid.8 Vaidlustaja tehniline argumentatsioon on esitatud ausõna peale, ilma et seda toetaks ükski dokumentaalne tõend, allikmaterjal vmt. Sellest tõukuvalt esitab Hankija Vaidlustaja seisukohtadele universaalse tõendamatuse vastuväite, ilma et ta peaks seda igas üksikus episoodis eraldi rõhutama.9 12. Minnes konkreetsemaks, siis Vaidlustaja on jäänud selle juurde, et Hankija peab oma vajadusi kirjeldama funktsionaalselt ning et mobiilirakenduse nõude puhul ei ole Hankija seda teinud.10 Hankija ei nõustu sellega. Õieti, abstraktsel ja fundamentaalsel tasemel Hankija mõistagi ei vaidlusta seda, et riigihankeõigus nõuab, et hankija hangiks teatavat funktsionaalsust, mitte konkreetse ettevõtja konkreetset toodet. Antud juhul aga Hankija ei olegi viimati öeldu vastu eksinud. Esiteks, ostumenetluse kutse ptk-s 2 (tehniline kirjeldus) on mahukas ja kohati võrdlemisi detailne loetelu funktsionaalsusi. Teiseks, ka mobiilirakenduse nõue ise (nt kutse p-d 2.4.3 ja 2.6.1) on funktsionaalsus, sest mobiilirakendust – nn native app’i – iseloomustavadki teatud kindlad tehnoloogilised ja kasutajakogemuslikud karakteristikud, mis mh erinevad vis-a-vis PWA, mille poolt argumenteerib Vaidlustaja. 13. Võrdluseks: kui hankija soovib hankida sõiduautot, siis paneb ta tehnilisse kirjeldusse kirja, kas ta eelistab automaat- või manuaalkäigukasti. Sellisel juhul ei saa ilmselt olla mõistlikult vaieldav, et üks või teine valik ongi funktsionaalsus, sest üks töötab ühtedel põhimõtetel, teine teistel. Vaevalt leiaks Vaidlustaja siis põhjust polemiseerida, et kuna hankija on lühidalt öelnud vaid, et nõutav on automaatkäigukast (ilma kõiki selle tööpõhimõtteid ja erinevusi manuaalkäigukastist lahti kirjutamata), siis hankija on konkurentsi kahjustavalt sätestanud „tehnoloogilise vorminõude“. Ka ei täiks Vaidlustaja ilmselt tõsimeelselt väita – jättes kõrvale kasutajamugavuse jm olulised 8 I. Pilving, M. Parind. RHS § 190 komm. 17. – M. A. Simovart, M. Parind, E. Fels (koost.). Riigihangete seadus. Kommenteeritud väljaanne. Juura 2025. 9 Näiteks on Vaidlustaja p-s 13 rääkinud mingitest täpsustamata Kiidjärve etendustest, toomata tõendeid ja isegi selgitamata, õieti millest käib jutt, kust pärinevad sellised numbrid jne. 10 Vaidlustaja täiendavate seisukohtade p 7. NOVE - 4/6 - asjaolud –, et hankija peab tingimata aktsepteerima ka manuaalkäigukasti, kuna see võimaldab samuti käike vahetada. 14. Vaidlustaja argumentatsioon funktsionaalsuse teemal jätab Hankija segadusse, sest ei ole aru saada, õieti mis Vaidlustajat häirib või mis on tema püüe. Hetkel näib, et Vaidlustaja nõuab lihtsalt – Hankija arvates põhjendamatult –, et mobiilirakenduse nõue saaks veel kuidagi täpsemalt lahti kirjutatud. Teoreetiliselt: isegi kui seda teha ja panna kohustuslike nõuetena kirja mh olulised asjaolud, mis eristavad native rakendust PWA-st, siis õiguslik olukord Vaidlustaja jaoks ju ei muutuks. PWA-põhine lahendus oleks jätkuvalt mittevastav. 15. Apple’i operatsioonisüsteemist (iOS) rääkides teeb Vaidlustaja liigse lihtsustuse ja vea, andes mõista, et kõik tehnoloogilised lahendused on eriliselt riskantsena Apple’i meelevallas. See ei ole nii. Hankija on viitega allikmaterjalile selgitanud, et teatud ärilistel põhjustel rakendab Apple n-ö tehnoloogilist diskrimineerimist just PWA-de suhtes.11 See ei ole antud hanke kontekstis vähetähtis, kuna mistahes lahendus peab hästi töötama ka laialt levinud Apple’i nutitelefonides. 16. Kasutajamugavuse küsimusi käsitledes on Vaidlustaja väitnud, et Hankija võiks lihtsalt seada mingid kindlad mugavusnõuded ja (Vaidlustaja arvates eksisteeriv) probleem olekski lahendatud.12 Vaidlustaja jätab paraku tähelepanuta, et Hankija võib küll riigihanke alusdokumente sõnastada nii ja naa, põhjalikumalt ja vähem põhjalikult, aga Hankija ei saa pakkujatelt nõuda võimatut.13 Kui nt Apple iOS-il ei ole võimalik PWA-d nutiseadme avakuvale paigaldada teisiti ja lihtsamini kui mitmete tavakasutajale pigem keerukate klikkide tegemise kaudu (vt ses osas eksperdiarvamus), siis ei saa Hankija seda pakkujatelt ka nõuda. Kui Hankija midagi sellist – s.o tehnoloogiliselt võimatut – nõuaks, siis käituks Hankija õigusvastaselt. 17. Vaidlustaja maalib osati eksitava pildi, argumenteerides, et „teatripileti ost /---/ algab praktikas teatri kodulehelt“.14 Jah, nii mõnigi kord võib inimene, kes soovib soetada piletit Tallinna Linnateatri etendusele, suunduda esimese asjana teatri kodulehele. Sugugi harvad pole aga ka olukorrad, kus inimene – kas sihiteadlikult või (pool)juhuslikult muude e-ostlemiste või sirvimiste käigus – alustab Linnateatri piletivalikuga tutvumist ja ostu sooritamist otse piletimüügikeskkonnas. Näiteks: inimene läheb piletimüügikeskkonda uurima, kuhu tal oleks võimalik teatud kuupäeval oma abikaasaga kontserdile minna, ning selle raames näeb ta ka teda huvitavat pakkumist Linnateatri etendusele. Muu hulgas selliseid praktikas igati võimalikke ja piisavalt sagedasi olukordi silmas pidades soovibki Hankija, et tema piletid oleksid müügil tarbijale võimalikult käepärases keskkonnas, sest see suurendab tõenäosust, et Hankija juurde jõuavad ka n-ö juhuostjad ning need, kes ei taipaks piletiostu teekonda alustada Hankija enda kodulehelt. 18. Peale sõnastusliku apsu (teatrietendused ei „linastu“, vaid lavastuvad15) leiab Vaidlustaja seisukoha p-st 18 veel ka tubli annuse demagoogiat. Mõistagi ei soovi inimene nutitelefoniga teatripileti ostmiseks iga kord äppi alla laadida. See aga polegi vajalik. Üldjuhul laadib inimene endale piletimüüja äpi alla ühe korra, jätab selle oma nutiseadmesse alles ning jääbki seda kasutama. Inimesed ei laadi endale äppi alla vaid selleks, et teha sellega ühekordne toiming ja seejärel äpp kustutada. Võrdluseks: mõistlik inimene ei talita nii, et kui ta tahab Delfi mobiilirakendusest uudiseid lugeda, siis ta laadib rakenduse alla, loeb kaks-kolm uudist ära ja seejärel jälle kustutab Delfi rakenduse telefonist ära. Seda vaid selleks, et sama ringi paari tunni pärast või järgmisel päeval jälle korrata. 19. Niisamuti on sisutühi Vaidlustaja jutt sellest, et „kõigil inimestel ei ole nutitelefoni ning nutitelefoni ja mobiilirakenduste kasutamine ei ole kõigile võrdselt võimalik või ligipääsetav.“16 Täiesti õige, kõigil inimestel tõesti ei ole nutitelefoni. Hankija ei saa ega tahagi kõiki inimesi hõlmata mobiilirakenduse nõudega. Hankija soovib tema piletite soetamise ja haldamise teha võimalikult 11 Hankija vastuse p 25. 12 Vaidlustaja täiendavate seisukohtade p 16. 13 Vrd VAKOo 187-17/192426, p 13 ja 14. 14 Vaidlustaja täiendavate seisukohtade p 17. 15 Asjad „linastuvad“, nagu nimigi viitab, kinos kinolinal. 16 Vaidlustaja täiendavate seisukohtade p 18. NOVE - 5/6 - lihtsaks nendele paljudele, kel on nutitelefon ja kes on suutelised selle pakutavaid võimalusi kasutama. Lisaks, kui Vaidlustaja räägib osade inimeste „piiratud digioskustest“, siis see paradoksaalselt ainult toetab Hankija eesmärki ja nõudeid. Nimelt, mida lihtsam on hanke tulemusel kasutusse võetavat tehnoloogilist lahendust kasutada, seda rohkemad inimesed saavad sellest osa. Nagu juba öeldud ja nagu kinnitab ka eksperdiarvamus, native rakendus on inimesele lihtsam ja mugavam installeerida ja kasutada kui PWA. III VASTUVÄITED VAIDLUSTAJA MENETLUSKULUDELE 20. Juhuks kui VAKO peaks tegema otsuse, mille korral on ette nähtud vaidlustaja menetluskulude väljamõistmine hankijalt, juhib Hankija tähelepanu järgmisele. Vaidlustaja on lisaks oma kahe lepingulise esindaja tööga seotud kulude väljamõistmisele taotlenud ka advokaadibüroo haldustasu väljamõistmist. Kohtupraktika on selles küsimuses ühene: advokaadibüroo üldkulu (teise nimega „haldustasu“) ei ole menetluskuluna väljamõistetav.17 Lisaks palub Hankija VAKO-l kriitiliselt hinnata, kas põhjendatud on 7+ h ulatuses tööd, et koostada lühike vaidlustus, mille sisu (s.o tiitelleht ja menetluslikud avaldused välja arvata) on napid 1,5 lk. IV TÄIENDAV MENETLUSKULUDE NIMEKIRI 21. 22.06.2026 esitas Hankija VAKO-le oma selleks päevaks tekkinud menetluskulude nimekirja summas 1931,25 eurot (km-ta). Seoses Vaidlustaja poolt 22.06.2026 täiendavate seisukohtade esitamisega on Hankijale tekkinud uusi menetluskulusid, mis on loetletud alljärgnevalt. 22. Hankija täiendavad menetluskulud koosnevad lepingulise esindaja kuludest summas 1687,50 eurot (km-ta). Hankijale on alates 22.06.2026 osutatud õigusabi 7 h 30 min tunnihinnaga 225 eurot (km-ta). Esindajakulude täpsem spetsifikatsioon nähtub alltoodud tabelist (kõik summad km-ta). 23. Koondades kõik oma menetluskulud, taotleb Hankija, et VAKO mõistaks Vaidlustajalt Hankija kasuks välja viimase lepingulise esindaja kulud summas 3619 eurot (km-ta). Hankija taotleb enda esindajakulude väljamõistmist käibemaksuta, kuna ta on käibemaksukohustuslane.18 Lugupidamisega Mart Parind Vandeadvokaat 17 Nt RKHKo 3-3-1-28-14, p 20.3; 3-3-1-61-14, p 25; TlnRnKo 3-15-77, p 24; 3-13-1397, p 15. 18 RKHKm 11.05.2022, 3-20-663, p 23. NOVE - 6/6 - Lisa: Andres Käveri eksperdiarvamus.
Allikas: Rahandusministeerium dokumendiregister →
dokumendiregister.eeAsutusedEesti avalike dokumendiregistrite otsing · nimistu.ee andmetel