← Slovensko

Univerzita Komenského v Bratislave — Automatizovaný systém elektronickej správy registratúry a obehu dokumentov pre Univerzitu Komenského v Bratislave

Obsah (14)§ 140§ 147§ 170§ 175§ 2§ 172§ 10§ 171§ 173§ 5§ 34§ 42§ 43§ 44

ÚRAD PRE VEREJNÉ OBSTARÁVANIE Sekcia dohľadu Ružová dolina 10, 821 09 Bratislava Bratislava Číslo: 11. 02. 2026 15309-6000/2025 Úrad pre verejné obstarávanie ako ústredný orgán štátnej správy pre vere

§ 140

a orgán príslušný

§ 147písm.

c), § 167 ods. 2 písm. b), § 169 ods. 1 písm. b) zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov vo veci námietok uchádzača AA (ďalej len „navrhovateľ“),

označenia smerujúcich

§ 170ods.

3 písm. f) zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov proti vyhodnoteniu ponúk vo verejnej súťaži na predmet nadlimitnej zákazky „Automatizovaný systém elektronickej správy registratúry a obehu dokumentov pre Univerzitu Komenského v Bratislave“, vyhlásenej verejným obstarávateľom Univerzita Komenského v Bratislave, Šafárikovo námestie 6, 814 99 Bratislava, IČO: 00 397 865 (ďalej len „kontrolovaný“), v Úradnom vestníku Európskej únie pod značkou 504368-2025 dňa 01. 08. 2025 a vo Vestníku verejného obstarávania č. 156/2025 dňa 04. 08. 2025 pod značkou 12717 – MST (ďalej len „verejná súťaž“), vydáva toto rozhodnutie: Úrad pre verejné obstarávanie

§ 175ods.

4 zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov námietky navrhovateľa zamieta. Odôvodnenie:

  1. Navrhovateľ doručil Úradu pre verejné obstarávanie (ďalej len „úrad“) dňa
  2. 2025 námietky v listinnej podobe, ktoré označil ako smerujúce

§ 170ods.

3 písm. f) zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej len „zákon o verejnom obstarávaní“) proti vyhodnoteniu ponúk. Kontrolovanému boli námietky navrhovateľa doručené taktiež dňa

  1. 2025 v elektronickej podobe funkcionalitou informačného systému, prostredníctvom ktorého sa predmetná verejná súťaž realizuje, t. j. cez informačný systém JOSEPHINE (ďalej len „IS JOSEPHINE“).
  2. Úrad na úvod konštatuje, že v rámci námietkového konania úrad posudzuje námietky

ich obsahu, a to aj v prípade, ak je samotné smerovanie podaných námietok nesprávne označené. Úrad v rámci námietkového konania zohľadňuje obsah podaných námietok, a teda jej vnútornú skladbu a nadväznosť tvrdení navrhovateľa, ale taktiež aj zvolenú argumentáciu v nadväznosti na celkový význam napádaných skutočností. Ak nastane situácia, pri ktorej je potrebné skúmať otázku, či existuje rozpor medzi obsahom napádaných skutočností v podanej námietke a formálnym označením smerovania podanej námietky v zmysle § 170 ods. 3 zákona o verejnom obstarávaní, v tom prípade je potrebné akcentovať objektívne hľadisko. Úrad poukazuje na skutočnosť, že v danom prípade navrhovateľ označil predmetné námietky ako námietky smerujúce

§ 170ods.

3 písm. f) zákona o verejnom obstarávaní proti vyhodnoteniu ponúk. Vychádzajúc z obsahu podaných námietok a skutočností, voči ktorým Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 1 navrhovateľ podal námietky úrad konštatuje, že predmetné námietky smerujú

§ 170ods.

3 písm.

  1. g)zákona o verejnom obstarávaní proti úkonu kontrolovaného inému ako uvedenému v písmenách
  2. a)
  3. f)tohto ustanovenia. Úrad má za to, že namietané vyhodnotenie Kritéria č. 2 - Technické riešenie systému (ďalej len „kritérium č. 2“) v tomto prípade nie je možné vnímať ako vyhodnotenie ponúk, ale ako úkon kontrolovaného, nakoľko v danom prípade ešte nedošlo k úplnému vyhodnoteniu ponúk, ale len k vyhodnoteniu jednej z častí ponuky, ktorou je kritérium č. 2. Námietky proti vyhodnoteniu ponúk je v zmysle § 170 ods. 4 písm.
  4. f)zákona o verejnom obstarávaní možné podať do 10 dní od doručenia oznámenia o výsledku vyhodnotenia ponúk, čo v danom prípade ešte nenastalo. Navrhovateľovi bolo doručené „len“ oznámenie o vyhodnotení kritérií na vyhodnotenie ponúk, teda nie vyhodnotenie celkovej ponuky. Na základe uvedených skutočností úrad konštatuje, že námietky navrhovateľa smerujú

§ 170ods.

3 písm.

  1. g)zákona o verejnom obstarávaní proti úkonu kontrolovaného inému ako uvedenému v písmenách
  2. a)
  3. f)tohto ustanovenia. 3. Námietky navrhovateľa boli doručené úradu a kontrolovanému v lehote a podobe

§ 170ods.

4 a ods. 9 zákona o verejnom obstarávaní a obsahujú všetky náležitosti

§ 170ods.

5 tohto zákona. Navrhovateľ doručil úradu námietky v zmysle § 170 ods. 1 písm. a) zákona o verejnom obstarávaní ako uchádzač, pričom

§ 2ods.

5 písm. c) tohto zákona sa na účely tohto zákona rozumie uchádzačom hospodársky subjekt, ktorý predložil ponuku. Úrad má na základe sprístupnenej elektronickej dokumentácie za preukázané, že navrhovateľ ako uchádzač predložil ponuku dňa aa xy hod. 4.

§ 172ods.

1 zákona o verejnom obstarávaní s podaním námietok je navrhovateľ povinný zložiť na účet úradu kauciu. Kaucia musí byť pripísaná na účet úradu najneskôr na druhý pracovný deň nasledujúci po doručení námietok v lehote

§ 170ods.

4. Za každú skutočnosť, proti ktorej námietky

§ 170ods.

3 smerujú, sa skladá samostatná kaucia. 5. Z ustanovenia § 172 ods. 2 zákona o verejnom obstarávaní vyplýva, že výška kaucie pri podaní námietok je 0,1 % z predpokladanej hodnoty zákazky alebo koncesie, najmenej však 2 000 EUR a najviac a) 10 000 EUR, ak ide o námietky

§ 170ods.

3 písm.

  1. a)a b),
  2. b)50 000 EUR, ak ide o iné námietky, ako uvedené v písmene a). 6. Nakoľko predpokladaná hodnota predmetu zákazky predstavuje sumu 1 735 147,00 EUR bez DPH, tak v zmysle vyššie uvedeného platí, že 0,1 % z predpokladanej hodnoty zákazky predstavuje sumu 1 735,14 EUR. Nakoľko uvedená suma nepresahuje zákonom stanovenú minimálnu hodnotu kaucie, navrhovateľ bol v danom prípade povinný s podaním námietok zložiť na účet úradu kauciu vo výške 2 000,00 EUR. 7. Úrad lustráciou účtu úradu zistil, že navrhovateľ s podaním námietok zložil na účet úradu dňa 04. 12. 2025 kauciu v celkovej výške 2000,00 EUR a teda pri určovaní výšky kaucie a pri jej zložení na účet úradu postupoval v súlade s § 172 ods. 1 až ods. 2 zákona o verejnom obstarávaní. 8. Na základe vyššie uvedených skutočností má úrad za to, že s podaním námietok navrhovateľa boli splnené procesné podmienky pre vydanie meritórneho rozhodnutia v tejto veci. Námietky navrhovateľa Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 2 9. Navrhovateľ namieta vyhodnotenie kritéria č. 2 v rámci jeho ponuky, pričom postup kontrolovaného považuje pri znížení bodového hodnotenia za neopodstatnený, v rozpore s princípmi transparentnosti, proporcionality a nediskriminácie. Navrhovateľ konkrétne namieta nepridelenie bodov pri piatich položkách. Položka č. 1 - Elektronické záznamy (skenovanie dokumentov) 10. Navrhovateľ v prvej časti námietok poukazuje na položku zadefinovanú v prílohe č. 2 súťažných podkladov, ktorou je návrh na plnenie kritérií v predmetnej verejnej súťaži a rekapituluje postup kontrolovaného v súvislosti s priebežným vyhodnotením kritérií č. 2 – Technické riešenie systému, ktoré v zmysle Prílohy č. 1b Opisu predmetu zákazky k zmluve o dielo predstavujú tzv. „nice to have“ požiadavky na obstarávaný systém. Navrhovateľ uvádza, že za túto položku mu kontrolovaný v rámci vyhodnocovania kritéria č. 2 nepridelil žiadne body z dôvodu nepreukázania požadovanej funkcionality navrhovateľom ponúknutého systému. 11. Navrhovateľ ďalej uvádza, že v súťažných podkladoch, konkrétne v dokumente „Návrh na plnenie kritéria - Kritérium č. 2“ a v opise predmetu zákazky, je požiadavka k Položke č. 1 formulovaná tak, že systém má umožňovať skenovanie dokumentov priamo počas evidencie elektronického registratúrneho záznamu prostredníctvom klientskej skenovacej aplikácie. Z tejto formulácie

navrhovateľa vyplýva, že kontrolovaný sám predpokladal architektúru typu klient - server, pri ktorej sa skenovanie realizuje cez osobitnú klientsku aplikáciu nainštalovanú na pracovnej stanici používateľa a registratúrny systém na strane servera túto aplikáciu vyvoláva a prijíma od nej výsledok v podobe elektronického dokumentu. Požiadavka

navrhovateľa nevyžaduje, aby systém dokázal skenovať bez inštalácie klientskej aplikácie a príslušných ovládačov na strane kontrolovaného. 12. Navrhovateľ poukazuje na to, že v predložených dokumentoch „xxx“ jednoznačne deklaroval a zdokumentoval, že navrhovateľom ponúkaný systém xx implementuje požadovanú funkcionalitu skenovania prostredníctvom klientskej aplikácie xy a integračného konektora, konkrétne komponenty xa a xb. Z dokumentácie

navrhovateľa ďalej vyplýva, že serverová časť xx obsahuje webovú službu na prijatie skenovaného dokumentu a jeho priradenie k registratúrnemu záznamu a že klientsky komponent zabezpečuje obsluhu skenera a odovzdanie výsledného súboru do systému v rámci procesu evidencie záznamu. Už na úrovni dokumentácie je

navrhovateľa preukázané, že ponúkol riešenie plne zodpovedajúce požiadavke kontrolovaného. 13. Navrhovateľ ďalej uvádza, že súčasťou súťažných podkladov je „Príloha č. 7 - Metodika vyhodnocovania vzorky“, ktorá upravovala spôsob testovania predloženej vzorky systému. Metodika vyhodnocovania vzorky

navrhovateľa výslovne počíta s tým, že testovanie môže prebiehať na technickej infraštruktúre kontrolovaného ako aj na infraštruktúre uchádzača, pričom predpokladá, že počas testovania bude k dispozícii inštalovaná aplikácia na notebooku uchádzača, prípadne bude systém sprístupnený formou cloudového riešenia.

  1. Navrhovateľ uvádza, že dňa
  2. 2025 prebehlo dopoludňajšie testovanie vzorky v priestoroch kontrolovaného. Navrhovateľ poukazuje na to, že na testovacej pracovnej stanici chýbali tri základné prerekvizity, a to nasledovné: o nebola nainštalovaná klientska aplikácia xy, o nebol nainštalovaný a nakonfigurovaný integračný konektor pre vyťažovanie a prenos dokumentu o skenovacie zariadenie nebolo riadne pripojené a vybavené ovládačmi. Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 3
  3. V nadväznosti na uvedené v predchádzajúcom bode navrhovateľ uvádza, že pri pokuse o použitie funkcie skenovania v systéme xx sa preto zobrazilo chybové hlásenie, cit.: „Neobsahuje Vaša licencia“, ktoré odkazuje na absenciu licencovaného alebo nainštalovaného klientskeho komponentu na konkrétnej stanici, nie na absenciu funkcionality v systéme ako takom. Z hľadiska architektúry riešenia ide

navrhovateľa o typický prejav neúplnej inštalácie na strane klienta, pričom poukazuje na to, že už počas dopoludňajšieho testovania upozorňoval komisiu kontrolovaného, že problém nespočíva v neexistencii funkcie skenovania v systéme xx, ale v nepripravenosti testovacieho prostredia na strane kontrolovaného. V súlade s metodikou vyhodnocovania vzorky mal

navrhovateľa kontrolovaný zabezpečiť, aby testovacie prostredie umožňovalo inštaláciu a chod klientskej aplikácie navrhovateľa. Napriek tomu kontrolovaný úplnú nápravu tohto stavu v rámci dopoludňajšieho testovania nezabezpečil a rozhodol sa poskytnúť navrhovateľovi dodatočnú možnosť do 14:00 hod. toho istého dňa, aby dodal inštalačný balík a umožnil tak dodatočnú konfiguráciu notebooku kontrolovaného. 16. Navrhovateľ ďalej uvádza, že v popoludňajších hodinách prebehla približne o 13:00 hod. online konzultácia prostredníctvom MS Teams, ktorej sa zúčastnil zástupca navrhovateľa a člen komisie. Navrhovateľ uvádza, že sa pokúsil zaslať inštalačný balík aplikácie xy, avšak vzhľadom na veľkosť súboru a limity prenosu sa tento balík v krátkom čase nepodarilo doručiť. Člen komisie

slov navrhovateľa navrhol využitie platformy SharePoint kontrolovaného, čo by si však

navrhovateľa vyžadovalo sprístupnenie internej infraštruktúry univerzity, nahratie veľkého inštalačného balíka, jeho inštaláciu, licencovanie a kompletnú konfiguráciu, pričom na tieto úkony nebola k dispozícii primeraná časová rezerva. Navrhovateľ uvádza, že z toho dôvodu poukázal na to, že takýto postup je v zadanom časovom horizonte nerealistický a neumožní objektívne overiť funkčnosť riešenia, preto ponúkol a zrealizoval online demonštráciu funkcionality skenovania z vlastnej technickej infraštruktúry, kde boli všetky prerekvizity riadne nainštalované a nakonfigurované. Navrhovateľ tvrdí, že počas tejto demonštrácie zástupca navrhovateľa na obrazovke preukázal štandardný scenár použitia, ktorý mal predstavovať: o otvorenie klientskej aplikácie xy, o načítanie dokumentu prostredníctvom skenera, o vyťaženie údajov (vrátane čiarového kódu), o použitie integračného konektora na odovzdanie dokumentu do systému xx a následné zobrazenie skenovaného dokumentu ako súčasti elektronického registratúrneho záznamu. Čas a konanie online testovania

navrhovateľa potvrdzuje Príloha č. 4, ktorou je záznam o online testovaní a samotný priebeh procesu skenovania a importu dokumentuje

navrhovateľa najmä Príloha č. 5 – Printscreen testovania skenovania (pozn. úradu: predmetné prílohy boli súčasťou odpovede na žiadosť o vysvetlenie zo dňa

  1. 2025, pozri bod 78-83 tohto rozhodnutia). Navrhovateľ zároveň poukazuje na to, že kontrolovaný o priebehu testovania vyhotovoval vlastný záznam, ktorý je v dispozícii kontrolovaného. Navrhovateľ uvádza, že nemá tento záznam k dispozícii, avšak navrhuje, aby si ho úrad pre účely tohto námietkového konania vyžiadal a vykonal jeho vyhodnotenie ako dôkaz o tom, že funkcionalita skenovania bola v online režime demonštrovaná a že zlyhanie dopoludňajšej ukážky bolo spôsobené výlučne nepripravenosťou testovacieho pracoviska kontrolovaného.
  2. Navrhovateľ uvádza, že vo vysvetlení jeho ponuky zo dňa
  3. 2025 podrobne a systematicky zrekonštruoval priebeh dopoludňajšieho aj popoludňajšieho testovania, vysvetlil technickú povahu hlášky chyby „Neobsahuje Vaša licencia“, opísal architektúru riešenia xxxy, a poukázal na to, že dopoludňajšie zlyhanie bolo spôsobené chýbajúcimi prerekvizitami na notebooku kontrolovaného. Súčasne zdokumentoval, že počas online demonštrácie bola Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 4 požadovaná funkcionalita skenovania riadne preukázaná, v plnom súlade s metodikou vyhodnocovania vzorky. Navrhovateľ tiež odkázal na technickú a používateľskú dokumentáciu systému xx, ktorá obsahuje popis príslušných komponentov a procesov skenovania. Navrhovateľ tvrdí, že kontrolovaný sa v rámci vyhodnotenia kritéria č. 2 obmedzil na stručné konštatovanie, že v predloženej testovacej verzii systému nebolo možné parameter overiť a že počas testovania nebola preukázaná požadovaná funkcionalita skenovania. V hodnotení absentuje akékoľvek vecné vysporiadanie sa s kľúčovým tvrdením navrhovateľa, že dopoludňajšie zlyhanie bolo spôsobené chýbajúcou inštaláciou klientskej aplikácie na strane kontrolovaného, ako aj so skutočnosťou, že pri online demonštrácii bola funkcionalita systému preukázaná. Vyhodnotenie kritérií na vyhodnotenie ponúk

navrhovateľa neobsahuje vysvetlenie, prečo kontrolovaný nepovažuje demonštrovaný proces xx-xy za naplnenie požiadavky definovanej v súťažných podkladoch. Navrhovateľ dodáva, že kontrolovaný navyše vo svojich zisteniach spochybnil online demonštráciu argumentom, že pri nej bol použitý dokument vo formáte pdf. a nie je známe, či tento dokument vznikol skenovaním. Takáto výhrada je

navrhovateľa technicky irelevantná, nakoľko z hľadiska splnenia požiadavky je rozhodujúce, že systém umožňuje prijať dokument prostredníctvom klientskej skenovacej aplikácie a priradiť ho k evidovanému záznamu. Skutočnosť, či bol konkrétny dokument pri testovaní vytvorený skenovaním v danom okamihu, alebo bol načítaný ako už existujúci obrazový súbor, nemá vplyv na schopnosť systému spracovať výsledok zo skenovacej aplikácie. Ak mal kontrolovaný pochybnosť o pôvode dokumentu, mohol

názoru navrhovateľa požiadať o okamžité nasnímanie iného dokumentu počas online prezentácie, avšak tak neurobil a napriek preukázanej funkčnosti odmietol výsledok testu akceptovať, čím konal v rozpore so zásadou transparentnosti a proporcionality

§ 10zákona o verejnom obstarávaní.

18. V nadväznosti na vyššie uvedené má navrhovateľ za to, že kontrolovaný zamenil absenciu konfigurácie testovacieho prostredia za absenciu samotnej funkcionality systému. Chýbajúca inštalácia xy, konektora a ovládačov na notebooku kontrolovaného predstavuje

navrhovateľa odstrániteľný problém na úrovni prostredia, obdobný situácii, keď pri testovacej jazde nie je v automobile natankované palivo, hoci motor je technicky v poriadku. Z uvedeného však kontrolovaný napriek tomu vyvodil záver, že systém xx požadovanú funkcionalitu neobsahuje, a to napriek tomu, že online demonštrácia preukázala opak. Takýto postup je

navrhovateľa v rozpore so zásadou proporcionality

§ 10

zákona o verejnom obstarávaní, pretože navrhovateľ bol sankcionovaný nepriznaním bodov za funkcionalitu, ktorú jeho systém objektívne má, a ktorú

jeho názoru riadne preukázal. 19. Navrhovateľ má za to, že postup kontrolovaného vykazuje aj znaky neprípustného extenzívneho výkladu súťažných podkladov v neprospech navrhovateľa.

výkladu navrhovateľa bola požiadavka formulovaná tak, že systém má umožňovať skenovanie prostredníctvom klientskej aplikácie. Navrhovateľ túto požiadavku naplnil architektúrou, ktorá predpokladá inštaláciu klientskej aplikácie na pracovnej stanici.

navrhovateľa kontrolovaný dodatočne, až pri testovaní vyložil požiadavku tak, že systém mal byť funkčný bez akejkoľvek inštalácie alebo konfigurácie na strane klienta a skenovanie malo byť preukázateľné výlučne na zariadení kontrolovaného, bez využitia infraštruktúry uchádzača.

navrhovateľa takýto výklad nevyplýva zo súťažných podkladov a nebol objektívne predvídateľný zo strany uchádzačov. Obdobný typ extenzívneho výkladu, ktorý vedie k neodôvodnenému znevýhodneniu uchádzača bol už

navrhovateľa predmetom súdneho konania, v rámci ktorého súd konštatoval, že súťažné podklady nemôžu byť vykladané nad rámec svojho textu, na ťarchu uchádzača a že nejasnosti alebo skryté preferencie kontrolovaného nemožno prenášať na uchádzača.

názoru navrhovateľa kontrolovaný k výkladu predmetnej požiadavky pristúpil tak, akoby išlo o kvalifikačnú alebo vylučovaciu Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 5 podmienku, pričom neexistenciu alebo nepreukázanie tejto funkcionality interpretoval spôsobom, ktorý znevýhodnil navrhovateľa v celkovom poradí. Takýto prístup je

navrhovateľa v rozpore so zásadou proporcionality a rovnakého zaobchádzania. 20. Navrhovateľ navrhuje, aby si úrad vyžiadal a vyhodnotil záznam z testovania vyhotovený kontrolovaným, ktorý zachytáva priebeh testovania. Z uvedených listín a záznamu v ich vzájomnej súvislosti

navrhovateľa jednoznačne vyplýva, že ponúkaný systém xx kritérium č. 2 v položke č. 1 spĺňa. Položka č. 2 - Elektronické záznamy (používateľsky definovateľné metadáta)

  1. Navrhovateľ v tejto časti námietok poukazuje na dokument „Vyhodnotenie kritérií na vyhodnotenie ponúk“ zo dňa
  2. 2025 (ďalej len „vyhodnotenie kritérií“), v ktorom komisia kontrolovaného uviedla, že počas testovania dovysvetlila pojem „používateľsky definované metadáta“ ako metadáta s možnosťou ich navrhovania a zmeny, pričom konštatovala, že takto chápanú funkcionalitu nie je v predloženej testovacej verzii systému možné vytvárať. Navrhovateľ namieta, že uvedené skutkové závery nezodpovedajú technickej realite systému xx, ani priebehu testovania. Mechanizmus používateľsky definovateľných metadát je v systéme implementovaný prostredníctvom voliteľných polí, ktoré je možné konfigurovať na úrovni jednotlivých evidencií, ako napríklad: spis, registratúrny záznam, príloha - v administrácii systému. Takto definované polia sú následne k dispozícii pri evidencii záznamu ako atribúty, ktoré vypĺňa bežný používateľ, a zároveň sú využiteľné ako vyhľadávacie kritériá. Táto architektúra zodpovedá

navrhovateľa štandardnému modelu enterprise systémov, v ktorých sa rozlišuje, cit.: o „bežný používateľ (referent) - vypĺňanie hodnôt do už existujúcich polí, o správa/metadátový administrátor - definícia a zmena dátového modelu (atribútov, typov, dĺžok), o dodávateľ/vývojár - zásah do zdrojového kódu.“ K uvedenému navrhovateľ dodáva, že požiadavku „používateľsky definovateľné metadáta“ je potrebné vykladať tak, že zákazník ako používateľ systému je schopný meniť dátový model vlastnými silami na úrovni konfigurácie, bez programátorského zásahu dodávateľa. Tento model

navrhovateľa systém xx spĺňa. 22. Navrhovateľ uvádza, že počas testovania bolo najskôr prezentované používanie už nakonfigurovaných voliteľných polí ako metadát záznamu, napríklad, cit.: „Naša značka, Vaša značka, Čiarový kód, Agendové číslo, Identifikácia pôvodcu, Lehota vybavenia a ďalšie“, ktoré sa vypĺňajú pri evidencii registratúrneho záznamu a následne sú dostupné pri triedení a vyhľadávaní.

slov navrhovateľa bola potom komisii prezentovaná obrazovka vyhľadávania, v ktorej bolo možné filtrovať záznamy práve

týchto metadát, čo

neho preukazuje splnenie druhej časti parametra „vyhľadávanie na základe týchto metadát“. Tým bolo

navrhovateľa zrejmé, že ním ponúknutý systém pracuje s rozšírenými atribútmi záznamu, ktoré nie sú „natvrdo“ definované zákonom a umožňuje ich používanie pri vyhľadávaní. 23. Navrhovateľ ďalej uvádza že po tom, ako komisia kontrolovaného prejavila záujem vidieť aj samotný proces tvorby nového metadáta vo vlastnej réžii, navrhovateľ

jeho slov uskutočnil administrátorskú ukážku konfigurácie nového voliteľného poľa. V rámci modulu administrácie boli

navrhovateľa demonštrované nasledujúce funkcionality systému: výber evidencie, zadanie názvu poľa, technické označenie - systémový názov, voľba dátového typu, dĺžky poľa, nastavenie povinnosti vyplnenia a použiteľnosti pri vyhľadávaní. Po uložení konfigurácie sa nové pole stalo súčasťou formulára registratúrneho záznamu a zároveň bolo k Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 6 dispozícii ako filter pri vyhľadávaní. Táto ukážka

navrhovateľa jednoznačne preukazuje, že systém xx umožňuje používateľsky definovať metadáta pre jednotlivé evidencie a následne

nich vyhľadávať, presne v intenciách zadanej požiadavky. 24.

navrhovateľa vzniklo kľúčové nedorozumenie pri výklade pojmu „používateľsky definovateľné“. Komisia kontrolovaného

navrhovateľa tento pojem spätne zúžila na predstavu, že možnosť definovať metadáta musí mat každý bežný koncový používateľ priamo v používateľskom formulári, bez vstupu do administrácie. Takýto výklad nevyplýva zo súťažných podkladov a nezodpovedá štandardom bezpečnej správy;

výkladu navrhovateľa je v prostredí informačných systémov používateľom softvéru organizácia ako celok a definovanie metadát je typicky právomocou špecializovanej roly, ako napríklad administrátora, správcu registratúry, nie každého jednotlivého referenta. Požiadavka, aby si každý bežný používateľ mohol pridávať vlastné polia do databázy, by bola v rozpore s princípmi integrity údajov, riadenej registratúry a zodpovedného výkonu verejnej správy. Skutočnosť, že funkciu definovania metadát vykonáva administrátor preto

navrhovateľa neznamená, že metadáta nie sú používateľsky definovateľné - znamená, že sú definované používateľom v roli správcu, nie dodávateľom prostredníctvom zásahu do zdrojového kódu. Záver komisie,

ktorého sa zástupcovia navrhovateľa zhodli s komisiou kontrolovaného, že takúto možnosť má mať len správca systému, je vytrhnutý z kontextu a nesprávne interpretovaný. Zástupcovia navrhovateľa mali tiež upozorniť na riziko tzv. „anarchie metadát“, ak by tvorba polí bola otvorená neobmedzenému počtu rolí, čo by viedlo k duplicite, chaotickým názvom a strate prehľadnosti a tiež mali vysvetliť, že z hľadiska metodiky správy registratúry a konzistencie údajov je žiadúce, aby návrh a úpravu metadát vykonával administrátor v súlade s internými pravidlami organizácie. Navrhovateľ tvrdí, že išlo o odborné odporúčanie, nie o priznanie technickej nemožnosti systému. 25. K argumentu kontrolovaného ohľadom konštatovania komisie, že v používateľskej dokumentácii sa nenachádza časť, ktorá by upravovala nastavenie a používanie tejto funkcionality navrhovateľ namieta, že ide o nesprávny záver; konfigurácia metadát je

navrhovateľa svojou povahou administrátorskou činnosťou a je popísaná v administrátorskej dokumentácii systému xx, v časti týkajúcej sa typov záznamov, registratúrnych plánov a globálnych nastavení. Používateľská príručka sa

navrhovateľa oprávnene zameriava na prácu bežného používateľa - vypĺňanie už definovaných voliteľných polí a vyhľadávanie

nich, vrátane uvedenia, že v zázname je možné pridať voliteľné polia prostredníctvom špecifickej akcie v používateľskom rozhraní. Zo skutočnosti, že detailný postup konfigurácie nie je súčasťou používateľskej príručky nemožno

navrhovateľa automaticky vyvodzovať neexistenciu funkcionality, najmä ak je zdokumentovaná v administrátorskej príručke a bola predvedená pri testovaní. Záver komisie o neexistencii tejto informácie v dokumentácii je

navrhovateľa založený na neúplnom a formalistickom posúdení predloženej dokumentácie. Kontrolovaný

navrhovateľa pri hodnotení predmetného kritéria č. 2 extenzívne a reštriktívne vykladá pojem používateľsky definovateľné metadáta spôsobom, ktorý nevyplýva zo súťažných podkladov, nebol pre uchádzačov predvídateľný, ignoroval preukázanú existenciu a demonštráciu funkcionality počas testovania, nesprávne interpretoval odborné odporúčanie navrhovateľa a udelil nulové bodové hodnotenie napriek tomu, že systém napĺňa materiálny účel požiadavky, ktorou sú konfigurovateľné metadáta na strane používateľa a vyhľadávanie

nich.

  1. Navrhovateľ má za to, že pri hodnotení tohto kritéria komisia kontrolovaného postupovala v rozpore s princípom proporcionality a navrhuje, aby úrad uložil kontrolovanému povinnosť predmetnú položku znovu vyhodnotiť, a to pri plnom zohľadnení skutočného fungovania mechanizmu voliteľných polí v systéme xx, pričom pri riadnom a úplnom vyhodnotení Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 7 predložených dôkazov musí byt predmetná položka hodnotená ako splnená a navrhovateľovi priznaný má byť pridelený plný počet bodov. Položka č. 6 – Zastupovanie
  2. Navrhovateľ v úvode tejto časti námietok uvádza, že z priebehu testovania, súťažných podkladov, ponuky navrhovateľa a technickej dokumentácie systému xx jednoznačne vyplýva, že mechanizmus zastupovania v systéme existuje, je funkčný a z pohľadu účelu zadania zabezpečuje trvalú, viditeľnú a spätne preukázateľnú informáciu o výkone úkonov v režime zastupovania.

navrhovateľa pritom ide o kľúčovú funkcionalitu registratúrneho systému, ktorá súvisí s požiadavkou zabezpečenia zastupiteľnosti a preukázateľného priradenia zodpovednosti za úkony

vyhlášky MV SR č. 410/2015 Z. z. o výkone správy registratúry a Výnosu MV SR č. 525/2011 Z. z. o štandardoch pre IS na správu registratúry. 28. Navrhovateľ poukazuje na prílohu č. 1b súťažných podkladov, v ktorej je parameter položky č. 6 formulovaný tak, že zastupovanie bude vždy viditeľné na zázname značkou napr. „v. z.“. Vo vyhodnotení kritérií na vyhodnotenie ponúk kontrolovaný

navrhovateľa spresnil, že funkcionalita „vždy viditeľný na zázname“ má byť

jeho predstavy zabezpečená zobrazením tejto značky priamo v prehľade registratúrnych záznamov. Navrhovateľ uvádza, že z jazykového a vecného výkladu tejto požiadavky vyplýva, že kontrolovaný stanovil tri prvky: • zastupovanie musí byt vždy viditeľné, t. j. používateľ aj kontrolný orgán musia mať k dispozícii jasnú informáciu, že konkrétny úkon bol vykonaný v režime zastupovania; • informácia má byť viazaná na konkrétny registratúrny záznam, • informácia má byť označená značkou, pričom uvedenie skratky „v. z.“ je výslovne uvedené len ako príklad, nie ako jediná prípustná forma vizuálneho označenia. V nadväznosti na uvedené navrhovateľ konštatuje, že súťažné podklady teda definujú funkčný výsledok, nie konkrétny technický spôsob implementácie. 29. Navrhovateľ ďalej argumentuje, že počas testovania vzorky systému xx a v písomnej odpovedi na žiadosť o vysvetlenie ponuky podrobne vysvetlil, ako je požadovaná funkcionalita zastupovania v systéme implementovaná a dodáva, že mechanizmus zastupovania pozostáva z nasledujúcich prvkov: používateľ si môže nastaviť koho zastupuje, kým bude zastúpený, na aké obdobie; navrhovateľ poukazuje na to, že pri aktívnom zastupovaní systém v hlavičke aplikácie jednoznačne zobrazuje, že používateľ koná v zastúpení inej osoby a informácia je viditeľná počas celej práce so systémom. Ďalej poukazuje na to, že systém obsahuje samostatný prehľad zastupovaní, v ktorom je zrejmé, kto koho zastupuje a v akom časovom intervale; v histórii každého registratúrneho záznamu systém eviduje údaje označené ako „Vykonal“ a „Spracovateľ“, pričom rozdiel medzi týmito údajmi signalizuje, že konkrétny úkon, ako napríklad vytvorenie, schválenie alebo spracovanie záznamu bol technicky vykonaný v zastúpení. Tieto informácie sú súčasťou metadát záznamu a umožňujú nielen priebežnú prácu so záznamom v režime zastupovania, ale aj následnú kontrolu toho kto a v akom postavení konkrétny úkon vykonal. Z technického hľadiska je riešenie xx

slov navrhovateľa koncipované ako model delegovania a zdieľania agendy: zástupca pracuje v rámci vlastného používateľského kontextu, pričom systém transparentne označuje, že koná v zastúpení inej osoby; zároveň sú všetky úkony v metadátach jednoznačne priradené osobe, ktorá je formálne zodpovedná za agendu, ako aj osobe, ktorá úkon technicky vykonala. Takýto model

navrhovateľa jednoznačne spĺňa požiadavky na kontinuitu správy registratúry, časové ohraničenie zastupovania, auditnú stopu a preukázateľnosť zodpovednosti. Skutočnosť, že systém nepracuje s prepínaním identity v zmysle úplného prehlásenia sa do roly zastupovaného používateľa, ale so zdieľanou Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 8 pracovnou plochou s jednoznačným označením úkonov v zastúpení

navrhovateľa nijako neznižuje mieru právnej istoty - práve naopak, z pohľadu auditu ide o modernejší a transparentnejší prístup. 30. Navrhovateľ poukazuje na to, že už samotná formulácia vo vyhodnotení kritérií na vyhodnotenie ponúk ukazuje vnútorný rozpor medzi skutkovým stavom a závermi komisie kontrolovaného, kedy na jednej strane kontrolovaný výslovne pripúšťa, že systém xx zobrazuje aktívny režim zastupovania v hlavičke aplikácie, poskytuje prehľad zastupovaní a obsahuje údaje o tom, kto vykonal a spracoval „akciu“ v histórii záznamu. Na druhej strane, bez bližšieho vecného odôvodnenia tvrdí, že pri zobrazení registratúrnych záznamov sa nenachádza informácia o zastupovaní a že uvedené informácie nie sú dostatočné na splnenie požiadavky. Vyhodnotenie kritérií na vyhodnotenie ponúk tak

navrhovateľa neobsahuje jasné vysvetlenie prečo tieto systémové prvky kontrolovaný nepovažuje za viditeľné označenie zastupovania na zázname v zmysle súťažných podkladov. Navrhovateľ dôvodí, že v kontexte štandardov pre informačné systémy na správu registratúry je pritom rozhodujúce, aby systém umožňoval delegovanie práv na zástupcu, časové ohraničenie zastupovania, automatizáciu aktivácie a deaktivácie zastupovania, vedenie úplnej auditnej stopy a následnú preukázateľnosť pri kontrole. Navrhovateľ tvrdí, že tieto funkčné požiadavky môže systém naplniť rôznymi technickými modelmi, a to buď modelom prepínania identity alebo modelom zdieľania agendy s jasným označením úkonov v zastúpení. Navrhovateľ má za to, že ak kontrolovaný v súťažných podkladoch nevymedzil, že jediným prípustným riešením je spôsob vizualizácie v jednom prehľade záznamov, ako napríklad konkrétna ikona, či presné textové označenie, nemôže kontrolovaný spätne vylúčiť iný, funkčne rovnocenný model, ktorý rovnako zabezpečuje viditeľnosť a preukázateľnosť zastupovania. 31. Navrhovateľ má za to, že kontrolovaný formalisticky zúžil požiadavku na jedinú prípustnú formu, a to osobitnú značku v jednom konkrétnom prehľade registratúrnych záznamov, hoci znenie požiadavky v súťažných podkladoch takýto výlučný výklad neobsahuje a použitie slova „napr.“ jasne signalizuje, že ide o príklad možného označenia. Ďalej navrhovateľ poukazuje na to, že kontrolovaný vo vyhodnotení kritérií na vyhodnotenie ponúk neuviedol prečo považuje kombináciu hlavičky aplikácie, prehľadu zastupovaní a histórie záznamu s údajmi označené ako „Vykonal“ a „Spracovateľ“ za nedostatočnú z hľadiska účelu požiadavky, a teda komisia kontrolovaného sa

navrhovateľa s existujúcou funkcionalitou zastupovania v systéme xx vecne nevysporiadala.

navrhovateľa je vyhodnotenie komisie v tejto časti nepreskúmateľné pre nedostatok dôvodov, keďže absentuje argumentácia, ktorá by odôvodnila prečo konkrétny spôsob implementácie nespĺňa funkčné zadanie. Navrhovateľ ďalej konštatuje, že ak komisia kontrolovaného uprednostnila vizuálny model zastupovania, na ktorý je zvyknutá z iného systému a riešenie xx postavené na modely delegovania a zdieľania agendy penalizovala, hoci z funkčného hľadiska zabezpečuje rovnaký výsledok, ide o neprípustné skryté sub-kritérium a faktickú diskrimináciu odlišnej architektúry. Požiadavky na predmet zákazky majú byť definované funkčne. Navrhovateľ má za to, že ak kontrolovaný v súťažných podkladoch nešpecifikoval, že trvá na konkrétnom UX/UI modeli zastupovania, musí akceptovať všetky technicky ekvivalentné riešenia, ktoré napĺňajú požadovaný účel. 32. Navrhovateľ konštatuje, že kontrolovaný nenašiel žiadnu skutočnosť, ktorá by nasvedčovala tomu, že systém xx zastupovanie neeviduje, alebo že by nebolo možné dodatočne preukázať výkon úkonu v režime zastupovania.

názoru navrhovateľa jedinou vytýkanou skutočnosťou je, že informácia o zastupovaní nie je v systéme zobrazená formou osobitnej značky priamo v prehľade registratúrnych záznamov

preferencie komisie. Navrhovateľ Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 9 tvrdí, že nedostatok sa týka výlučne formy prezentácie údajov, nie samotnej existencie a spoľahlivosti mechanizmu zastupovania. Napriek tomu komisia položku č. 6 vyhodnotila ako nesplnenú a nepridelila navrhovateľovi body, čím ho z hľadiska následkov postavila na jednu rovinu riešenia, ktoré zastupovanie vôbec neobsahujú a riešenie navrhovateľa, ktoré zastupovanie eviduje a viditeľne zobrazuje, hoci inou,

súťažných podkladov prípustnou formou. Takýto prístup predstavuje neprimerane tvrdý a formalistický výklad súťažných podkladov v neprospech navrhovateľa, čo je

jeho názoru v rozpore nielen so zákonom o verejnom obstarávaní, ale aj s rozhodovacou praxou súdov. 33.

navrhovateľa je okrem písomných podkladov potrebné prihliadnuť aj na skutočnosť, že z testovania systému x bol vyhotovený audiovizuálny záznam, ktorý navrhovateľ nemá k dispozícii, ale ktorý môže objektívne preukázať, akým spôsobom systém počas testovania zobrazoval aktívne zastupovanie v hlavičke aplikácie, v prehľade zastupovaní, aj v histórii záznamu. Navrhovateľ apeluje na to, že tento záznam je spôsobilý potvrdiť alebo vyvrátiť tvrdenia kontrolovaného o údajnej neviditeľnosti zastupovania pri práci so záznamom. Navrhovateľ preto navrhuje, aby si úrad vyžiadal záznam z testovania a vyhodnotil ho v spojení s obsahom súťažných podkladov, ponuky a technickej dokumentácie systému xx. Položka č. 8 - používatelia a procesy (evidencia majetku) 34. Navrhovateľ poukazuje na to, že z vyhodnotenia kritérií vyplýva, že počas osobného stretnutia za účelom testovania zástupcovia navrhovateľa upozornili komisiu na skutočnosť, že komplexná evidencia majetku v zmysle inventarizácie, odpisových skupín, či účtovných zostatkov nie je štandardnou funkciou informačného systému správy registratúry, ale doménou ekonomických a majetkových systémov. Zároveň však jednoznačne uviedli, že systém xx umožňuje evidenciu majetku a jeho preraďovanie prostredníctvom vlastných procesov viazaných na registratúrne záznamy. Komisia kontrolovaného to

navrhovateľa vo svojom texte interpretovala tak, že navrhovateľ mal argumentovať, že funkcionalitu nemôže kontrolovaný požadovať, preto ju nepredložil; následne poukazuje na screenshot testovacej verzie systému z 15. 10. 2025, kde záložka „Evidencia majetku“ ešte nebola zobrazená. Tá istá komisia však v ďalšom texte

navrhovateľa výslovne pripúšťa, že po ukončení osobného stretnutia navrhovateľ počas videokonferencie o 14:15 hod. dodatočne odprezentoval vytvorenú editovateľnú záložku „evidencia majetku“, v detaile už existujúcich záznamov. Tým kontrolovaný

navrhovateľa fakticky potvrdzuje, že systém xx predmetnú funkcionalitu má a vie ju v rámci svojich procesov poskytovať, avšak napriek tomu položku č. 8 vyhodnotil ako nesplnenú. 35. Navrhovateľ poukazuje na vysvetlenie ponuky, v ktorom mal kontrolovanému objasniť fungovanie predmetnej položky v systéme xx a zdôrazňuje, že zo súťažných podkladov pri predmetnej položke nevyplýva, že kontrolovaný požaduje, aby v testovacom prostredí existovala už vopred naplnená databáza reálnych majetkových položiek, ani aby bol modul evidencie majetku detailne opísaný v základnej používateľskej príručke určenej pre bežné funkcie registratúry.

navrhovateľa je podstatné, že architektúra a funkcionalita systému umožňujú evidenciu a preraďovanie majetku v rámci procesov registratúry, t. j. že systém vie viazať údaje o majetku na konkrétny záznam alebo spis a spracovať ich v rámci schvaľovacích a preraďovacích workflow. Toto bolo

navrhovateľa počas testovania preukázané existenciou a demonštráciou záložky „Evidencia majetku“ v detaile registratúrneho záznamu, vrátane možnosti evidovať typ majetku, stav, základné údaje, dátumy, ceny a dôvody vyradenia, ako aj väzbu na konkrétny záznam alebo spis a naviazanie na workflow. To, či sa táto záložka zobrazuje vo všetkých záznamoch alebo len pri vybraných Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 10 typoch záznamov je

slov navrhovateľa konfiguračná otázka, nie dôkaz absencie funkcionality. 36. Navrhovateľ má za to, že kontrolovaný sa s vysvetlením navrhovateľa vo vyhodnotení vecne nevysporiadal, iba zopakoval pôvodné tvrdenie, že v systéme neboli nájdené údaje o evidencii majetku, a že táto funkcionalita nebola dohľadateľná v užívateľskej príručke, pričom kontrolovaný už

navrhovateľa nereflektoval na to, že parametrom je umožnenie evidencie majetku a preraďovania, nie existencia konkrétnych testovacích dát alebo opis v určitej časti dokumentácie.

navrhovateľa zásadný posun oproti pôvodnému stavu vytvorenie a demonštrácia záložky „Evidencia majetku“ sa v odôvodnení premietol len konštatovaním o nelogickom zobrazení, a to bez analýzy, prečo má takto nastavená konfigurácia vylučovať splnenie samotného parametra. Takýto postup je

navrhovateľa v rozpore so zásadou transparentnosti

§ 10

zákona o verejnom obstarávaní, keďže rozhodnutie neobsahuje presvedčivé a materiálne odôvodnenie, prečo kontrolovaný neakceptoval technické a vecné vysvetlenie navrhovateľa a prečo napriek preukázanej existencii záložky „Evidencia majetku“ a jej väzieb na procesy konštatuje nesplnenie parametra. Navrhovateľ opäť tvrdí, že kontrolovaný implicitne zaviedol nové, v súťažných podkladoch neuvedené podmienky, no napriek tomu komisia založila časť svojho negatívneho záveru práve na absencii týchto prvkov.

navrhovateľa ide o extenzívny a formalistický výklad požiadavky, ktorý dodatočne sprísňuje podmienky po predložení ponúk a ktorý je v rozpore s požiadavkou predvídateľnosti postupu kontrolovaného s ustálenou rozhodovacou praxou úradu.

  1. Navrhovateľ opäť poukazuje na záznam z testovania a žiada úrad, aby zrušil napadnuté vyhodnotenie tejto položky a uložil kontrolovanému povinnosť opätovne vyhodnotiť položku č. 8 so zohľadnením skutočného fungovania modulu evidencie majetku v systéme xx, vrátane dôkazov predložených uchádzačom, záznamu z testovania a prideliť navrhovateľovi plný počet bodov za uvedený parameter. Položka č. 10 - Bezpečnostné požiadavky
  2. Navrhovateľ ďalej uvádza, že registratúra systému xx je navrhnutá ako tenký klient, teda webová aplikácia, ktorá pri nahrávaní príloh odovzdáva súbor na server. Navrhovateľ tiež poukazuje na to, že antivírusová a antimalvérová kontrola prebieha na serverovej a infraštruktúrnej vrstve, nie v používateľskom rozhraní a je súčasťou bezpečnostných mechanizmov prostredia, v ktorom je systém prevádzkovaný. Navrhovateľ ďalej uvádza, že technická dokumentácia systému potvrdzuje, že ide o tenko klientsku webovú aplikáciu, ktorá sa používa prostredníctvom internetového prehliadača bez potreby lokálnej inštalácie, pričom nahrávanie príloh prebieha formou výberu súboru alebo technikou „drag and drop“ s ich odoslaním na server, kde sa uskutočňuje spracovanie vrátane kontrol formátu a ďalších validácií. V písomnom vysvetlení navrhovateľ

jeho názoru výslovne uviedol, že antivírusové a antimalvérové mechanizmy sú súčasťou infraštruktúry, pričom pri nahrávaní prílohy serverový komponent zabezpečí kontrolu súboru a

výsledku nahranie súboru povolí alebo zablokuje; týmto je z technického hľadiska naplnené znenie predmetného kritéria. 39. Podstatou „sporu“ pri tejto položke

navrhovateľa teda nie je neexistencia antivírusovej kontroly, ale skutočnosť, že v krátkom časovom rámci osobného stretnutia a v obmedzenom prístupe k infraštruktúre nebolo možné túto kontrolu vizuálne demonštrovať v používateľskom rozhraní testovacej verzie. Navrhovateľ dôvodí tým, že pri server-side riešeniach je takýto „neviditeľný“ spôsob fungovania štandardný, kedy používateľ vidí iba Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 11 výsledok - úspešné alebo zablokované nahratie dokumentu - nie samotný proces skenovania. Ak kontrolovaný počas testovania nepracoval so súborom simulujúcim škodlivý kód, napr. testovací súbor typu EICAR, ani nepožiadal o doloženie logu z infraštruktúry po takomto pokuse, nemožno zo samotnej nemožnosti pozorovať proces vyvodzovať záver, že antivírusová kontrola neexistuje. 40. Z hľadiska skutkového stavu tak

navrhovateľa existuje pri položke č. 10 rozpor medzi zistením kontrolovaného v žiadosti o vysvetlenie, podrobným technickým vysvetlením uchádzača, že antivírusová kontrola prebieha na serverovej a infraštruktúrnej vrstve ako súčasť architektúry riešenia a je systémom podporovaná a konečným vyhodnotením, v ktorom komisia bez odbornej polemiky s uvedeným vysvetlením uzatvára, že funkcionalita nebola preukázaná a že v testovacej verzii nebola vytvorená integrácia s antivírusovým programom. 41. Navrhovateľ ďalej konštatuje, že vo vyhodnotení kritérií absentuje vysvetlenie, prečo má byť server-side antivírusová kontrola - ako priemyselný štandard pri cloudových riešeniach považovaná za nevyhovujúcu z pohľadu súťažného parametra. Kontrolovaný iba mechanicky zopakoval tvrdenie, že funkcionalitu nebolo možné overiť v testovacom prostredí a toto skutkové zistenie aplikoval do roviny údajnej absencie funkcionality; nerozlíšil pritom zásadný rozdiel medzi situáciou kedy funkcionalitu v danom scenári nie je možné otestovať a stavom, kedy systém túto funkcionalitu neumožňuje. Bez podrobného odôvodnenia je toto konanie kontrolovaného v rozpore s požiadavkou preskúmateľnosti rozhodnutia a princípom materiálnej pravdy. 42.

navrhovateľa bola porušená zásada proporcionality tým, že kontrolovaný z nemožnosti vizuálneho testovania v konkrétnom cloudovom prostredí vyvodil najprísnejší možný dôsledok, a to konštatovanie nesplnenia parametra a nepriznanie akýchkoľvek bodov navrhovateľovi za predmetnú položku. Predmetná požiadavka

navrhovateľa nevyžaduje, aby mal kontrolovaný počas stretnutia priamy prístup k bezpečnostným konzolám infraštruktúry navrhovateľa, ani aby bol proces skenovania zobrazovaný v „GUI“. Ak samotný kontrolovaný v žiadosti o vysvetlenie priznal, že dôvodom neotestovania je forma nasadenia cloudového prostredia uchádzača, bolo

navrhovateľa primerané hľadať alternatívny spôsob preukázania, nie automaticky sankcionovať navrhovateľa nulovým hodnotením. 43. Z obsahu vyhodnotenia kritérií

navrhovateľa tiež vyplýva, že kontrolovaný vyložil predmetnú požiadavku extenzívne, nad rámec jeho textu, keď de facto zaviedol nové podmienky, ako napríklad, že antivírusový mechanizmus musí byť priamo preukázateľný v predloženej testovacej verzii systému tak, aby komisia mala počas stretnutia možnosť nahliadnuť do logov alebo vizuálne pozorovať proces skenovania a že riešenie nesmie predpokladať súbežnú existenciu štandardnej ochrany koncových staníc na kontrolovaného. Žiadna z týchto podmienok nie je

navrhovateľa uvedená v súťažných podkladoch. Navrhovateľ vykladá predmetnú položku tak, že je potrebné výlučné umožnenie antivírusovej kontroly nahrávaných dokumentov a ich príloh, pričom navrhovateľ má za to, že v písomnom vysvetlení jednoznačne deklaroval, že ochrana koncových staníc je zodpovednosťou kontrolovaného a že ponúkané riešenie poskytuje antivírusovú kontrolu na serverovej a infraštruktúrnej úrovni. Formulácia kontrolovaného ohľadom toho, že uvedenú funkcionalitu nebolo možné otestovať, nakoľko systém sa nachádza v cloudovom prostredí uchádzača, svedčí

navrhovateľa o tom, že problém spočíval v zvolenom testovacom scenári a prístupe k infraštruktúre, nie v neexistencii funkcionality. Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 12 44. Z hľadiska účelu predmetnej požiadavky je

navrhovateľa rozhodujúce, že architektúra xx umožňuje integrovať antivírusovú kontrolu nahrávaných súborov na serverovej a infraštruktúrnej vrstve a že takáto kontrola je súčasťou procesu nahrávania, pričom pri zistení hrozby umožňuje nahratie dokumentu zablokovať. Tento stav je

navrhovateľa v priamom súlade so znením predmetnej požiadavky kontrolovaného. Záver kontrolovaného o tom, že predmetná funkcionalita nebola preukázaná je

navrhovateľa v rozpore so skutkovým stavom, ako aj so zákonom o verejnom obstarávaní. 45. Navrhovateľ opäť poukazuje na záznam z testovania a žiada úrad, aby zrušil napadnuté vyhodnotenie tejto položky a uložil kontrolovanému povinnosť opätovne vyhodnotiť položku č. 10 so zohľadnením skutočného technického riešenia antivírusovej kontroly v systéme xx, vrátane dôkazov predložených uchádzačom a záznamu z testovania a prideliť navrhovateľovi plný počet bodov za uvedenú položku. Začiatok preskúmania úkonov kontrolovaného 46.

§ 171ods.

1 zákona o verejnom obstarávaní sa námietkové konanie začína dňom doručenia námietok úradu. Na základe uvedeného úrad konštatuje, že predmetné námietkové konanie sa začalo dňa 04. 12. 2025. 47.

§ 173ods.

1 písm. a) zákona o verejnom obstarávaní je kontrolovaný povinný doručiť úradu písomné vyjadrenie k podaným námietkam a kompletnú dokumentáciu potrebnú na posúdenie namietaných skutočností, a to do piatich pracovných dní odo dňa doručenia námietok kontrolovanému, ak ide o námietkové konanie; úrad neprihliada na písomné vyjadrenie k podaným námietkam a dôkazy doručené kontrolovaným po uplynutí tejto lehoty. 48.

§ 173ods.

2 zákona o verejnom obstarávaní ak ide o elektronickú komunikáciu, dokumentácia sa úradu doručuje sprístupnením elektronickej podoby dokumentácie zriadením prístupu do elektronického prostriedku použitého na elektronickú komunikáciu v lehote

odseku 1, pričom súčasťou elektronickej podoby dokumentácie sú aj auditné záznamy o všetkých úkonoch vykonaných v použitom elektronickom prostriedku. Ak kontrolovaný predkladá dokumentáciu alebo jej časť v listinnej podobe, môže úradu doručiť aj fotokópiu tejto dokumentácie, ak zároveň písomne potvrdí, že táto dokumentácia súhlasí s originálnym vyhotovením dokumentácie. Kontrolovaný môže nahliadať do dokumentácie ním doručenej úradu. Ak sa preskúmanie úkonov kontrolovaného nezačne, úrad bez zbytočného odkladu poskytnutú dokumentáciu vráti.

  1. Kontrolovaný dňa
  2. 2025 doručil úradu vyjadrenie k podaným námietkam označené ako „Vyjadrenie k podaným námietkam“ (ďalej len „vyjadrenie“). Kontrolovaný dňa
  3. 2025 poskytol úradu prístupové údaje do elektronického prostriedku použitého na elektronickú komunikáciu, t. j. IS JOSEPHINE, čím kontrolovaný sprístupnil úradu elektronickú podobu dokumentácie v súlade s § 173 ods. 2 zákona o verejnom obstarávaní. Úrad po preskúmaní dokumentácie kontrolovaného dňa
  4. 2025 vydal v zmysle § 173 ods. 4 zákona o verejnom obstarávaní Rozhodnutie o prerušení konania č. 15309-6000/2025-P zo dňa
  5. 2025 (ďalej len „rozhodnutie o prerušení konania“), ktorým kontrolovanému nariadil doručiť úradu kompletnú dokumentáciu, a to do 15 pracovných dní od dňa doručenia rozhodnutia o prerušení konania. Kontrolovaný doručil úradu požadovanú dokumentáciu dňa
  6. Úrad konštatuje, že kontrolovaný doručil úradu kompletnú dokumentáciu k predmetnej verejnej súťaži dňa
  7. Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 13
  8. Navrhovateľ dňa
  9. 2026 doručil úradu dokument s názvom „Žiadosť o sprístupnenie spisu – poskytnutie výpisu „OBSAH SPISU“ a zaslanie kópie „Vyjadrenia kontrolovaného k podaným námietkam“ zo dňa
  10. 2026 (ďalej len „žiadosť navrhovateľa“), na základe ktorej úrad dňa
  11. 2026 doručil navrhovateľovi obsah spisu k predmetnému námietkovému konaniu a kópiu vyjadrenia kontrolovaného k podaným námietkam. Navrhovateľ dňa
  12. 2026 doručil úradu dokument s názvom „Automatizovaný systém elektronickej správy registratúry a obehu dokumentov pre Univerzitu Komenského v Bratislave“ - Stanovisko uchádzača k Vyjadreniu kontrolovaného k podaným námietkam“ z toho istého dňa (ďalej len „stanovisko navrhovateľa“).

§ 170ods.

11 zákona o verejnom obstarávaní navrhovateľ môže predložiť dôkazy a opis rozhodujúcich skutočností, ktoré neboli obsahom námietok, v lehote na doručenie námietok

odseku 4. Na dôkazy a opis rozhodujúcich skutočností predložených po uplynutí lehoty na doručenie námietok

odseku 4 úrad neprihliada. V tomto prípade námietky navrhovateľa smerujú proti postupu kontrolovaného pri čiastkovom vyhodnotení ponuky uchádzača, ktorý je spojený s doručením dokumentu „Vyhodnotenie kritérií na vyhodnotenie ponúk“ zo dňa

  1. 2025, ktorý kontrolovaný dňa
  2. 2025 doručil navrhovateľovi. Z uvedeného vyplýva, že posledným dňom na doručenie námietok bol deň
  3. Vzhľadom na skutočnosť, že navrhovateľ doručil predmetný dokument úradu dňa
  4. 2026, t. j. po lehote na doručenie námietok, úrad na stanovisko navrhovateľa v súlade s § 170 ods. 11 zákona o verejnom obstarávaní neprihliada. Písomné vyjadrenie kontrolovaného k námietkam navrhovateľa
  5. V úvode vyjadrenia kontrolovaný uvádza, že vo zverejnených súťažných podkladoch, konkrétne v dokumente „Príloha č. 2 - Návrh na plnenie kritéria - Kritérium č. 2“, uviedol tabuľku s desiatimi funkcionalitami informačného systému. Súčasťou súťažných podkladov bol aj dokument Príloha č. 7 - Metodika vyhodnocovania vzorky, v ktorom boli uvedené podmienky hodnotenia testovacej verzie systému s informáciou, že navrhovateľ nemá právo predložiť na testovanie opravenú verziu systému. Kontrolovaný poukazuje na to, že navrhovateľ si z navrhovaných verzií predloženia testovacieho systému zvolil cloudovú verziu systému s poskytnutým prístupom navrhovateľa. Položka č. 1
  6. Kontrolovaný uvádza, že v rámci funkcionality č. 1 požadoval, aby systém umožňoval skenovanie priamo počas evidencie elektronického registratúrneho záznamu prostredníctvom klientskej skenovacej aplikácie. Kontrolovaný konštatuje, že dňa
  7. 2025 prebiehalo testovanie systému v priestoroch kontrolovaného za účasti komisie na vyhodnotenie ponúk (ďalej len „komisia“) a dvoch zástupcov navrhovateľa, pričom funkcionalitu č. 1 nebolo možné otestovať, keďže testovacia verzia systému neobsahovala klientsku aplikáciu xy, prostredníctvom ktorej mala byť funkcionalita skenovania dostupná. Uvedenú skutočnosť

slov kontrolovaného potvrdzuje aj vyjadrenie navrhovateľa v texte námietky, ako aj priebeh testovania systému, viď video „Technicka kontrola podmienok sutaze20251027_090118-Nahrávanie schôdze.mp4“, napríklad čas 0:11:12 – „Neobsahuje Vaša licencia“ a poukazuje na priložený printscreen z testovacieho systému (pozri bod 91. tohto rozhodnutia). 53. Kontrolovaný ďalej uvádza, že v súťažných podkladoch požadoval preukázanie funkčnosti v predloženej vzorke systému počas testovania. Navrhovateľ však

názoru kontrolovaného nepreukázal funkčnosť skenovania v prostredí kontrolovaného, čo je rozhodujúce pre objektívne porovnanie ponúk. Online demonštrácia z infraštruktúry Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 14 navrhovateľa

názoru kontrolovaného nenahrádza riadne testovanie vzorky

metodiky, ktorá predpokladá overenie funkčnosti v prostredí kontrolovaného v predloženej testovacej verzii systému. Komisia kontrolovaného nemohla potvrdiť splnenie funkcionality, keďže v testovanej verzii nebola funkcionalita dostupná bez dodatočných zásahov. Kontrolovaný má za to, že akýkoľvek iný spôsob preukázania funkcionality, či už v inom systéme, ako v predloženej testovacej verzii alebo zmena/doplnenie funkcionality v testovacej verzii systému, by bol v rozpore so zákonom o verejnom obstarávaní, preto komisia kontrolovaného nemohla konštatovať, že systém obsahuje požadovanú funkcionalitu. Kontrolovaný má za to, že komisia poskytla navrhovateľovi primeranú súčinnosť na preukázanie funkcie skenovania v prostredí kontrolovaného a v predloženej testovacej verzii. Zdieľaná demonštrácia mimo testovacej verzie

kontrolovaného nespĺňa požiadavku verifikácie funkcionality

podmienok metodiky vyhodnocovania vzorky. Položka č. 2

  1. Kontrolovaný uvádza, že v rámci funkcionality č. 2 požadoval, aby systém obsahoval možnosť používateľsky definovateľných metadát pre jednotlivé evidencie, ako aj vyhľadávanie na základe týchto metadát. Kontrolovaný ďalej uvádza, že komisia testovala existenciu uvedenej funkcionality na všetkých roliach užívateľov, avšak bez pozitívneho výsledku. Pre odstránenie všetkých pochybností komisia dňa
  2. 2025 počas procesu testovania informovala navrhovateľa, že pod uvedeným pojmom požadovala metadáta s možnosťou ich navrhovania a zmeny, čo je bez ďalšieho poľa kontrolovaného zrejmé aj z jazykového výkladu formulácie tejto funkcionality. Požiadavka na funkcionalitu systému bola

názoru kontrolovaného interpretovaná v súlade s princípom predvídateľnosti, ako cit.: „používateľsky definovateľné“, čo

vyjadrenia kontrolovaného znamená možnosť definovať metadáta priamo používateľom, bez zásahu administrátora. 55. Kontrolovaný má ďalej za to, že hodnotenie komisie vychádzalo z reálneho stavu testovanej verzie a z dokumentácie, ktorá neobsahovala postup pre bežného používateľa. Kontrolovaný uvádza, že spornou nie je otázka ktorí zamestnanci kontrolovaného majú mať oprávnenie definovať metadáta. Kontrolovaný ďalej poukazuje na to, že nikde v dokumentácii nepožaduje, aby túto možnosť mal každý bežný koncový používateľ a rovnako ako uvádza navrhovateľ, požaduje toto oprávnenie len pre správcu, resp. administrátora systému. Určenie konkrétnych zamestnancov oprávnených na definovanie metadát je však pri tejto otázke

kontrolovaného irelevantné, lebo takto podrobne to nepožadoval určiť ani v opise tejto funkcionality, ani počas priebehu testovania systému.

slov kontrolovaného, podstatným záverom pri tejto funkcionalite je fakt, že počas testovania nebola preukázaná možnosť používateľsky definovať metadáta. Kontrolovaný zároveň vyslovuje domnienku, že predmetná funkcionalita bola do testovacieho systému doplnená až následne. Ako podklad k tejto domnienke kontrolovaný prikladá printscreen administrátorského prostredia z testovacej verzie systému zo dňa 27. 10. 2025 v momente testovania systému za prítomnosti zástupcov navrhovateľa a printscreen administrátorského prostredia z testovacej verzie systému zo dňa 27. 10. 2025 v čase o 14:19 hod., kde je

jeho slov viditeľne doplnené pole „Voliteľné polia“. 56. Kontrolovaný konštatuje, že navrhovateľ v tomto prípade postupoval v rozpore s Prílohou č. 7 - Metodika vyhodnocovania vzorky,

ktorej uchádzač nemá právo predložiť na testovanie opravenú verziu systému, a z toho dôvodu komisia nemohla za túto funkcionalitu prideliť navrhovateľovi bodové ohodnotenie. Položka č. 6 Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 15 57. Kontrolovaný uvádza, že v opise predmetného parametra uviedol, že funkcionalita systému „Zastupovanie“ má byť vždy viditeľná na zázname, napr. označením „v. z.“. Navrhovateľ počas testovania predviedol spôsob fungovania tejto funkcionality.

vyjadrenia kontrolovaného sa však v systéme pri zobrazení záznamov nenachádza viditeľná informácia o zastupovaní a či bol daný záznam vytvorený/schválený/spracovaný v režime zastupovania, a to ani počas jeho trvania, ani po jeho ukončení, na účely spätnej kontroly. Kontrolovaný tvrdí, že navrhovateľ v testovanej verzii nepreukázal zobrazenie informácie o zastupovaní priamo v prehľade registratúrnych záznamov, čo je kľúčové pre okamžitú identifikáciu režimu zastupovania; kontrolovaný má za to, že týmto spôsobom bola funkcionalita požadovaná v zmysle súťažných podkladov, pričom poukazuje na formuláciu „viditeľná na zázname“. 58. Kontrolovaný konštatuje, že riešenie navrhovateľa, ktoré využíva údaje v histórii záznamu alebo v hlavičke aplikácie nezodpovedá požiadavke kontrolovaného na trvalé vizuálne označenie na zázname. Zobrazovanie aktívneho režimu zastupovania v hlavičke aplikácie navrhovateľa, prehľad zastupovania, možnosť nastaviť zastupovanie, či termín zastupovania, nie je to isté, ako značka na zázname, ktorá má byť viditeľná aj inými používateľmi zahrnutými do procesu – „workflow“, a to aj po termíne zastupovania. Údaje v histórii záznamu ako „Vykonal“ a „Spracovateľ“

vyjadrenia kontrolovaného nehovoria o režime zastupovania a nepreukazujú, prečo vykonal akciu v systéme iný používateľ ako používateľ zodpovedný za agendu. Viditeľná značka pre zastupovanie na zázname je požadovaná spôsobom, aby bola konštantne viditeľná už pri náhľade v zozname záznamov, nie až po dohľadávaní v histórii záznamu, kde nie je jednoznačne uvedené, že išlo o vykonanie úkonu v zastúpení. Kontrolovaný dôvodí tým, že požiadavka smerovala na trvalú a jednoznačnú identifikáciu zastupovania priamo na úrovni záznamu, pričom testovací systém navrhovateľa poskytol iba indikáciu v hlavičke a nejednoznačné údaje v histórii; značka na zázname v zozname/detaile, ani vyhľadávacie kritérium zastupovania neboli

slov kontrolovaného preukázané. Z uvedeného dôvodu komisia nepridelila navrhovateľovi za túto funkcionalitu body. Kontrolovaný dodáva, že akceptovanie takéhoto nedostatočného spôsobu splnenia požadovanej funkcionality by bolo v rozpore s princípmi verejného obstarávania, najmä s princípom rovnakého zaobchádzania a princípom nediskriminácie hospodárskych subjektov. Položka č. 8 59. Kontrolovaný uvádza, že jeho požiadavka smerovala na preukázanie funkcionality v testovanej verzii. Kontrolovaný ďalej poukazuje na to, že zástupca navrhovateľa sa počas testovania vyjadril, že evidencia majetku nie je súčasťou ponúkaného systému, pričom poukazuje na video „Technicka kontrola podmienok sutaze-20251027_090118-Nahrávanie schôdze.mp4“, čas 02:02:00.

vyjadrenia kontrolovaného navrhovateľ prezentoval záložku „Evidencia majetku“ až dodatočne, mimo riadneho testovania, pričom jej implementácia nebola súčasťou pôvodne predloženej testovacej verzie systému. Komisia konštatovala, že v čase testovania nebola táto funkcionalita dostupná, ani zdokumentovaná v používateľskej príručke a zároveň nebola počas testovania a ani počas ukážky za prítomnosti zástupcov navrhovateľa splnená. 60. Ako dôkaz kontrolovaný prikladá screenshot z 15. 10. 2025, na ktorom

jeho názoru v detaile záznamu nie je zobrazená záložka pre evidenciu majetku a dodáva, že navrhovateľ až po ukončení testovania, za účasti komisie, na vlastnú žiadosť, bez bližšej špecifikácie, dodatočne online prezentoval novo vytvorenú, editovateľnú záložku „Evidencia majetku“, v detaile už existujúcich záznamov. Kontrolovaný konštatuje, že navrhovateľ aj v tomto Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 16 prípade postupoval v rozpore s Prílohou č. 7 súťažných podkladov,

ktorej uchádzač nemá právo predložiť na testovanie opravenú verziu systému, a z toho dôvodu komisia nemohla za túto funkcionalitu prideliť navrhovateľovi bodové ohodnotenie. Položka č. 10 61. Kontrolovaný uvádza, že stanovil požiadavku na preukázanie funkčnosti antivírusovej kontroly v testovanej verzii systému, pričom hodnotenie bolo založené na reálnom overení.

vyjadrenia kontrolovaného navrhovateľ nepredložil žiadny dôkaz o funkčnosti antivírusovej kontroly počas testovania a ani nezabezpečil spôsob jej preukázania v súlade s metodikou, pričom poukazuje na video „Technicka kontrola podmienok sutaze20251027_090118-Nahrávanie schôdze.mp4“, čas od 02:05:00. Kontrolovaný poukazuje na vyjadrenie navrhovateľa o tom, že cloudová verzia robí antivírusovú kontrolu neviditeľne a danú funkcionalitu možno vidieť v log súboroch; kontrolovaný však poukazuje na to, že tieto logy neboli navrhovateľom prezentované ani počas stretnutia a neboli mu ani dodatočne poslané. Samotná deklarácia navrhovateľa, že kontrola prebieha na infraštruktúrnej vrstve

kontrolovaného nepostačuje na preukázanie splnenia predmetnej funkcionality, keďže komisia nemala možnosť overiť funkčnosť

stanovenej metodiky v zmysle súťažných podkladov. 62. Na margo vyššie uvedených skutočností kontrolovaný konštatuje, že postup komisie bol transparentný, nediskriminačný, v súlade so zákonom o verejnom obstarávaní a so súťažnými podkladmi a z toho dôvodu považuje námietky navrhovateľa za neopodstatnené. Právny rámec 63.

§ 10ods.

1 zákona o verejnom obstarávaní sú verejný obstarávateľ a obstarávateľ povinní pri zadávaní zákaziek, koncesií a pri súťaži návrhov postupovať

tohto zákona. 64.

§ 10ods.

2 zákona o verejnom obstarávaní verejný obstarávateľ a obstarávateľ musia dodržať princíp rovnakého zaobchádzania, princíp nediskriminácie hospodárskych subjektov, princíp transparentnosti, princíp proporcionality a princíp hospodárnosti a efektívnosti. 65.

§ 10ods.

3 zákona o verejnom obstarávaní príprava a zadávanie zákaziek, koncesií a súťaže návrhov vrátane ich klasifikácie

§ 5ods.

1 sa nesmú realizovať so zámerom nedovoleného uplatnenia výnimky z tohto zákona alebo narušenia hospodárskej súťaže bezdôvodným zvýhodnením alebo znevýhodnením určitých hospodárskych subjektov. Verejní obstarávatelia a obstarávatelia sú povinní prijať potrebné opatrenia na zabezpečenie primeraného a včasného plnenia svojich úloh, ktoré vyplývajú z osobitných predpisov a ktoré sú zároveň v súlade s pravidlami verejného obstarávania. 66.

§ 34ods.

ods. 1 zákona o verejnom obstarávaní technická spôsobilosť alebo odborná spôsobilosť sa preukazuje

druhu, množstva, dôležitosti alebo využitia dodávky tovaru, stavebných prác alebo služieb doloženým jedným alebo niekoľkými z týchto dokladov: m) ak ide o tovar, ktorý sa má dodať,

  1. vzorkami, opismi alebo fotografiami, ktorých pravosť musí byť overená, ak to verejný obstarávateľ alebo obstarávateľ vyžaduje alebo
  2. certifikátmi alebo potvrdeniami s jasne identifikovanými odkazmi na technické špecifikácie alebo technické normy vzťahujúce sa na tovar, vydanými orgánmi kontroly kvality alebo určenými orgánmi s právomocou posudzovať zhodu. Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 17 67.

§ 42ods.

1 zákona o verejnom obstarávaní súťažné podklady sú písomné, grafické alebo iné podklady obsahujúce podrobné vymedzenie predmetu zákazky. V súťažných podkladoch verejný obstarávateľ a obstarávateľ uvedú všetky okolnosti, ktoré budú dôležité na plnenie zmluvy a na vypracovanie ponuky. Opis predmetu zákazky môže odkazovať aj na osobitný postup alebo metódu výroby alebo poskytovania požadovaných tovarov, stavebných prác alebo služieb, ako aj na osobitný postup inej fázy ich životného cyklu, a to aj vtedy, ak tieto faktory netvoria súčasť ich hmotnej podstaty, musia však súvisieť s predmetom zákazky a byť primerané jej hodnote a cieľom. Predmet zákazky musí verejný obstarávateľ a obstarávateľ opísať jednoznačne, úplne a nestranne na základe technických požiadaviek

prílohy č. 3. Verejný obstarávateľ a obstarávateľ zodpovedá za správnosť a úplnosť súťažných podkladov. 68.

§ 43ods.

1 zákona o verejnom obstarávaní verejný obstarávateľ a obstarávateľ uverejňujú dokumenty potrebné na vypracovanie ponuky, návrhu a na preukázanie splnenia podmienok účasti v profile a poskytujú k nim bezodplatne neobmedzený, úplný a priamy prístup prostredníctvom elektronických prostriedkov odo dňa uverejnenia oznámenia o vyhlásení verejného obstarávania, oznámenia použitého ako výzva na súťaž, oznámenia o vyhlásení súťaže návrhov alebo oznámenia o koncesii v európskom vestníku. V oznámení o vyhlásení verejného obstarávania, v oznámení použitom ako výzva na súťaž, v oznámení o vyhlásení súťaže návrhov a v oznámení o koncesii verejný obstarávateľ a obstarávateľ uvedú internetovú adresu, na ktorej sú dokumenty a informácie

prvej vety prístupné. 69.

§ 44ods.

1 zákona o verejnom obstarávaní verejný obstarávateľ a obstarávateľ vyhodnocujú ponuky na základe objektívnych kritérií na vyhodnotenie ponúk, ktoré súvisia s predmetom zákazky, s cieľom určiť pre neho ekonomicky najvýhodnejšiu ponuku. Verejným obstarávateľom a obstarávateľom určené kritériá musia byť nediskriminačné a musia podporovať hospodársku súťaž ods. 1 zákona o verejnom obstarávaní. 70.

§ 44ods.

2 zákona o verejnom obstarávaní kritérium na vyhodnotenie ponúk sa považuje za súvisiace s predmetom zákazky, ak sa z akéhokoľvek hľadiska a v ktorejkoľvek fáze životného cyklu výrobku, stavby alebo služby vzťahuje k požadovanému tovaru, stavebným prácam alebo službe, a to vrátane faktorov, ktoré sa týkajú konkrétneho procesu výroby, dodania tovaru, uskutočnenia stavebných prác alebo poskytnutia služby alebo obchodovania s nimi alebo konkrétneho procesu inej fázy životného cyklu výrobku, stavby alebo služby; to platí aj vtedy, ak tieto faktory nie sú súčasťou ich materiálnej podstaty. 71.

§ 44ods.

3 písm.

  1. a)zákona o verejnom obstarávaní ponuky sa vyhodnocujú na základe najlepšieho pomeru ceny a kvality. Právne posúdenie námietok navrhovateľa úradom Úrad preskúmal postup kontrolovaného v predmetnej verejnej súťaži v rozsahu namietaných skutočností a po zhodnotení všetkých podkladov, najmä dokumentácie predloženej kontrolovaným a navrhovateľom namietaných skutočností konštatuje nasledovné: 72. V závislosti od predmetu zákazky, typu kontrolovaného a predpokladanej hodnoty zákazky v celkovej výške 1 735 147,00 EUR bez DPH, ide o nadlimitnú zmiešanú zákazku na dodanie tovarov a poskytnutie služieb, zadávanú postupom verejnej súťaže v zmysle § 66 ods. 7 písm.
  2. b)zákona o verejnom obstarávaní, tzv. superreverzným postupom. Zákazka sa nedelí na časti. Zákazka nie je financovaná z fondov EÚ. V lehote na predkladanie ponúk, ktorá bola kontrolovaným stanovená v zmysle Oznámenia o vyhlásení verejného obstarávania na deň Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 18 01. 09. 2025 do 10:00 hod. ponuku do predmetnej verejnej súťaže predložili traja uchádzači (vrátane navrhovateľa). Otváranie ponúk sa uskutočnilo dňa 01. 09. 2025 o 10:05 hod. 73. Úrad zistil, že kontrolovaný v časti V. „KRITÉRIA NA VYHODNOTENIE PONÚK A PRAVIDLÁ ICH UPLATNENIA“ bodoch 24.1 – 24.3 súťažných podkladov stanovil kritériá na vyhodnotenie ponúk nasledovne, cit: „24.1 Verejný obstarávateľ zvolil pre vyhodnotenie ponúk v súlade s § 44 ods. 3 písm.
  3. a)zákona kritérium, ktorým je najlepší pomer ceny a kvality. 24. 2 Určenie kritérií, pravidlá ich výpočtu a ich relatívna váha: Kritérium č. 1 - Celková cena v Eur bez DPH Kritérium č. 2 - Technické riešenie systému Kritérium č. 3 – Počet poskytnutých naviac rokov technickej podpory a údržby prevádzky systému (...) Kritérium č. 2 (K2): Technické riešenie systému – max. 20 bodov (váhovosť 20%) Za toto kritérium môže uchádzač získať maximálne 20 bodov. Verejný obstarávateľ, v Prílohe č. 2 týchto súťažných podkladov, pri kritériu č.2 (K2) určil desať „nice to have“ funkcionalít systému. Uchádzač v prípade, že ním ponúkaný systém tieto funkcionality obsahuje, vyplní v tabuľke hodnotu „2“, ak nie, tak vyplní hodnotu „0“. Verejný obstarávateľ si vyhradzuje právo overiť reálnosť informácií uvedených uchádzačom v Prílohe č. 2 týchto súťažných podkladov pri kritériu č. K2, a to predloženou vzorkou demo verzie systému (§ 34 ods. 1 písm.
  4. m)zákona), teda uchádzačom deklarovaný počet bodov za toto kritérium nemusí byť konečný a môže sa v priebehu hodnotenia ponúk zmeniť. Funkcionality „nice to have“ sú bližšie popísané v Prílohe č. 1b) týchto súťažných podkladov, pričom táto príloha bude k podpisu zmluvy o dielo upravená tak, aby obsahovala len tie „nice to have“ funkcionality, ktoré úspešný uchádzač ponúkne v rámci tohto kritéria. (...) 24.3 Pravidlá uplatnenia kritérií: Ponuky budú hodnotené

súčtu bodov za všetky tri kritéria, na základe ktorého bude zostavené zostupné poradie všetkých hodnotených ponúk. Ponuka s najvyšším počtom získaných bodov bude zaradená na prvé miesto poradia, ďalšie ponuky budú zoradené v zostupnom poradí, pričom ponuka s najnižším počtom bodov bude zaradená na posledné miesto. Ponuku uchádzača, ktorú členovia komisie s právom vyhodnocovať ponuky označia za prvú (úspešná ponuka) a bude zároveň spĺňať všetky požiadavky verejného obstarávateľa na predmet zákazky a zároveň splní stanovené podmienky účasti, odporučí komisia verejnému obstarávateľovi prijať. V prípade rovnosti počtu bodov za všetky tri kritériá u viacerých uchádzačov rozhoduje o poradí najnižšia cena celkom za predmet zákazky v Eur bez DPH – hodnota kritéria K

  1. (...)
  2. Kontrolovaný v Prílohe č. 2 „Návrh na plnenie kritérií“ (ďalej len „Príloha č. 2 alebo aj návrh na plnenie kritérií“) kontrolovaný stanovil, cit.: „ (...) Kritérium č. 2 (K2) - Technické riešenie systému (váha 20%) - maximálny počet bodov 20 P.č Názov položky ("nice to have" funkcionality) Počet bodov* Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 19 1 2 3 4 5 6 7 8 9 10 Elektronické záznamy systém umožňuje skenovanie dokumentov priamo počas evidencie elektronického registratúrneho záznamu prostredníctvom klientskej skenovacej aplikácie Elektronické záznamy systém umožňuje možnosť používateľsky definovateľných metadát pre jednotlivé evidencie, vyhľadávanie na základe týchto metadát Spisy systém umožňuje vytvorenie reportu na kontrolné účely pre nadriadených (napr. nedodržanie termínov vybavenia spisov a záznamov) Spisy systém umožňuje vytvorenie a tlač e-podacieho hárku pre automatické odoslanie vybavenia poštou a viesť ich evidenciu, resp. vie komunikovať so Slovenskou poštou prostredníctvom jej API služby Spisy systém umožňuje tlač preberacích protokolov pri odovzdávaní „pošty“ v papierovej podobe používateľovi Zastupovanie zastupovanie bude vždy viditeľné na zázname značkou napr. “v. z.” Notifikácie systém umožňuje využívať funkcie pre kontrolu spracovania elektronických registratúrnych záznamov formou farebného odlíšenia tesne pred a po uplynutí termínu Používatelia a procesy systém umožňuje evidenciu majetku a preraďovanie majetku UK vo svojich procesoch Používatelia a procesy systém umožňuje používateľské nastavenia vzhľadu systému, výber viditeľných stĺpcov a ich poradia Bezpečnostné požiadavky systém umožňuje antivírusovú kontrolu nahrávaných dokumentov a ich príloh Celkový počet bodov 0 *ak uchádzačom ponúkaný systém umožňuje/obsahuje danú položku (funkcionalitu "nice to have"), uchádzač uvedie v stĺpci Počet bodov hodnotu "2", v opačnom prípade uvedie hodnotu "0" .“
  3. Úrad ďalej zistil, že kontrolovaný v časti
  4. „PODMIENKY ÚČASTI VO VEREJNOM OBSTARÁVANÍ“ bode 21.2 „Technická spôsobilosť alebo odborná spôsobilosť“, podbode 21.2.4 „§ 34 ods.
  5. písm. m) - predloženie vzorky – testovacia verzia systému“ súťažných podkladov stanovil, cit.: „Minimálna požadovaná úroveň štandardov: Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 20 Verejný obstarávateľ požaduje predloženie testovacej verzie systému (funkčného, integračného, záťažového testovania a testovania dostupnosti systému vrátane zaškolenia zamestnancov verejného obstarávateľa na vykonanie testovania). Súčasťou etapy bude vytvorenie testovacej dokumentácie a používateľskej dokumentácie pre účely testovania. Bližší opis metodiky vyhodnocovania vzorky – testovania demo verzie systému – je uvedený v Prílohe č. 7 týchto súťažných podkladov.
  6. Kontrolovaný ďalej v Prílohe č. 7 súťažných podkladov s názvom „Metodika vyhodnocovania vzorky“ (ďalej len „Príloha č. 7“ alebo aj „metodika vyhodnocovania vzorky“) (odkaz na súťažné podklady pozri bod
  7. tohto rozhodnutia) stanovil, cit.: „
  8. Požiadavky na testovaciu verziu systému Účel požiadavky: požiadavka na testovaciu verziu systému je potrebná na overenie, či systém spĺňa požiadavky na funkcionalitu, kompatibilitu a použiteľnosť v reálnych podmienkach. Formát testovacej verzie systému: ✓ testovacia verzia systému bude poskytnutá ako inštalovateľná verzia systému a následne bude uchádzačom nainštalovaná na laptope verejného obstarávateľa, alebo ✓ bude k dispozícii počas testovania inštalovaná aplikácia na laptope uchádzača, alebo ✓ bude dostupná ako cloudová verzia softvéru s poskytnutým prístupom uchádzačom. (...)
  9. Časový rámec na predloženie testovacej verzie systému Uchádzač je povinný v lehote do 5 pracovných dní odo dňa odoslania výzvy na predloženie testovacej verzie systému poskytnúť testovaciu verziu systému v jednom z formátov uvedených v bode 1 tohto dokumentu. Verejný obstarávateľ zašle výzvu na predloženie testovacej verzie systému uchádzačovi prostredníctvom komunikačného rozhrania systému Josephine. Testovanie bude realizované v priestoroch verejného obstarávateľa na adrese Žižkova 10, Bratislava, a to v pracovných dňoch medzi 9:00 hod. a 16:00 hod. Pre testovanie uchádzač vyčlení minimálne jedného zamestnanca na obdobie 1 až 2 pracovné dni, ktorý bude k dispozícii verejnému obstarávateľovi a bude viesť jednotlivé vybrané testovacie prípady. Uchádzač sprístupní testovaciu verziu systému a svojho zamestnanca na uvedené testovacie účely bez nároku na akékoľvek náhrady, a to aj v prípade, ak následne nebude uchádzač vybraný ako víťaz.
  10. Podmienky hodnotenia testovacej verzie systému Posúdenie funkcionalít bude vykonané vymenovanou hodnotiacou komisiou zostavenou zo zamestnancov verejného obstarávateľa. Z výsledku posudzovania bude vyhotovený písomný záznam, ktorý bude súčasťou dokumentácie vyhodnotenia ponúk. V prípade, ak pri hodnotení testovacej verzie systému budú zistené, že systém nespĺňa požiadavky na predmet zákazky, uchádzač nemá právo predložiť na testovanie opravenú verziu.
  11. Technické aspekty Testovacia verzia systému bude uchádzačom naplnená testovacími údajmi pred testovaním tak, aby tieto údaje zohľadňovali špecifiká verejného obstarávateľa, a čo najvernejšie simulovali reálnu prevádzku verejného obstarávateľa. V prípade nutnosti použitia citlivých alebo osobných údajov, zabezpečí uchádzač, že tieto informácie budú anonymizované alebo bude požitá vhodná náhrada.“
  12. Úrad zistil, že navrhovateľ vo svojej ponuke v Prílohe č. 2 súťažných podkladov uviedol, že v rámci kritéria č. 2 - tzv. „nice to have“ funkcionality, spĺňa navrhovateľom predložený systém všetky požadované funkcionality, na základe čoho bolo navrhovateľovi v priebežnom Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 21 hodnotení za predmetné funkcionality pridelených 20 bodov. Kontrolovaný v súlade so súťažnými podkladmi, dňa
  13. 2025 doručil navrhovateľovi „Výzvu na predloženie testovacej verzie systému“ zo dňa
  14. 2025 (ďalej len „výzva kontrolovaného“), ktorou ho vyzval na predloženie testovacej verzie systému; navrhovateľ bol v závere výzvy kontrolovaného zároveň upovedomený o tom, že predložená testovacia verzia systému musí byť úplná, bez možnosti opravy. Dňa
  15. 2025 bola kontrolovanému doručená odpoveď na výzvu kontrolovaného. V odpovedi na výzvu kontrolovaného navrhovateľ oznámil, že testovaciu verziu predloženého systému predkladá ako cloudovú verziu systému, spolu s poskytnutím prístupu. Odpoveď na výzvu kontrolovaného obsahovala okrem samotnej odpovede niekoľko dokumentov: administrátorskú príručku IS xx, používateľskú príručku IS xx, integračné služby IS xx a prístupové/prihlasovacie údaje do IS xx. Dňa
  16. 2025 sa uskutočnilo testovanie predloženej verzie systému. Po realizovaní testovania bola dňa
  17. 2025 navrhovateľovi doručená „Žiadosť o vysvetlenie“ zo dňa
  18. 2025 (ďalej len „žiadosť o vysvetlenie“), v ktorej kontrolovaný žiadal vysvetliť nasledujúce skutočnosti, cit: „(...) Položka č. 1 Elektronické záznamy (...) Zistenie - pri testovaní funkcionality systém zobrazoval hlásenie: „Neobsahuje Vaša licencia“ pri štyroch aplikáciách Outlook, RK BcPrint, RK xy, Podpisuj. Uchádzač nepreukázal, že systém obsahuje softvér na skenovanie dokumentov. Položka č. 2 Elektronické záznamy (...) Zistenie - systém pri testovaní neumožnil definovať metadáta resp. táto funkcionalita nie je ani uvedená v užívateľskej dokumentácii k systému. Položka č. 6 Zastupovanie (...) Zistenie - pri testovaní systému bolo zistené, že uvedené označenie v systéme nie je implementované a uvedenú funkcionalitu systému je možné rozpoznať len

autora zmeny. Položka č. 8 Používatelia a procesy (...) Zistenie - v systéme pri testovaní neboli nájdené údaje o evidencii majetku, ktoré neboli ani dohľadateľné v užívateľskej príručke k systému. Položka č. 10 Bezpečnostné požiadavky (...) Zistenie - uvedenú funkcionalita systému nebolo možné otestovať, nakoľko systém sa nachádza v cloudovom prostredí uchádzača. V sprístupnenom testovacom systéme xx komisia identifikovala vyššie uvedené nezrovnalosti s funkcionalitami systému špecifikované v Návrhu na plnenie kritéria č. 2, Kritérium č. 2 Technické riešenie systému, ktoré boli Vami uvedené ako implementované v systéme. Na základe uvedených skutočností Vás komisia žiada o vysvetlenie uvedených nezrovnalostí v testovacom systéme. (...)

  1. Navrhovateľ dňa
  2. 2025 doručil kontrolovanému odpoveď „Žiadosť o vysvetlenie – odpoveď AA“ z toho istého dňa (ďalej len „vysvetlenie“), v ktorej z väčšiny časti uviedol skutočnosti, ktoré následne uviedol aj v námietkach ku každej položke samostatne (pozri body 9-45 tohto rozhodnutia). Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 22
  3. Vo vzťahu k položke č. 1 navrhovateľ vo vysvetlení okrem iného1 objasnil princíp fungovania funkcionality skenovania dokumentov, resp. funkčný princíp riešenia, cit.: „(...) 3) Funkčný princíp riešenia • Digitalizácia a indexácia prebieha na klientskej stanici (xy + konektor). • Prenos a evidencia skenu sú realizované do registratúry xx, kde sa sken javí ako príloha k záznamu a vstupuje do ďalších procesov. • Takto navrhnutá architektúra je štandardom pre DMS/registratúrne systémy (oddelenie skenovacej vrstvy od aplikačnej logiky) a je popísaná v technických a užívateľských príručkách xx). (...)“ (...) Nejde teda o požiadavku, aby samotná aplikácia registratúry obsahovala interný skenovací modul, ale o požiadavku, aby riešenie ako celok – systém registratúry spolu s klientskym skenovacím pracoviskom – umožňovalo vykonávať skenovanie počas evidencie elektronického registratúrneho záznamu. xx je presne takto navrhnutý: aplikačná časť zabezpečuje registratúru a procesy, zatiaľ čo klientsku časť tvorí skenovacie pracovisko s xy a príslušným konektorom. (...) (...) Logicky teda platí: • Ak riešenie pri splnených technických prerekvizitách preukázateľne skenuje, indexuje a zapisuje skeny do registratúry, • a ak požiadavka znie iba na to, aby „systém umožňoval“ skenovanie prostredníctvom klientskej aplikácie, • potom je parameter naplnený bez ohľadu na to, že v dopoludňajšej časti v priestoroch verejného obstarávateľa nebolo možné skenovanie spustiť z dôvodu chýbajúcej inštalácie skenera na strane verejného obstarávateľa. (...)“
  4. K položke č. 2 navrhovateľ vo vysvetlení okrem iného2 uviedol, cit.: „(...) Predmetný parameter je systémom xx splnený. Mechanizmus používateľsky definovateľných metadát je v riešení realizovaný prostredníctvom voliteľných polí, ktoré je možné: • konfigurovať na úrovni jednotlivých evidencií (spis, záznam, príloha) v administrácii systému, • využívať pri evidencii elektronických záznamov, • a používať pri vyhľadávaní ako vyhľadávacie kritériá. Počas testovania boli najprv prezentované už nakonfigurované voliteľné polia na zázname a súvisiace možnosti vyhľadávania. Následne – po spresnení očakávania verejného obstarávateľa, že chce mať metadáta „vo vlastnej réžii“ – sme vykonali administrátorskú ukážku konfigurácie týchto polí vrátane názvu, systémového názvu, dátového typu, dĺžky poľa a vlastností vyhľadávania. (...)“ Navrhovateľ vo vysvetlení ďalej uviedol, cit.: „(...) počas diskusie pracovnou skupinou verejného obstarávateľa sa ukázalo, že verejný obstarávateľ mal pod pojmom „používateľsky definovateľné metadáta“ predstavu, že tieto polia bude vedieť sám v plnom rozsahu navrhovať a meniť, a to priamo v bežnom používateľskom rozhraní – bez vstupu administrátora. (...)“ 1 Celý rozsah namietaných skutočností vo vzťahu k predmetnej položke pozri body 9-20 tohto rozhodnutia. Celý rozsah namietaných skutočností vo vzťahu k predmetnej položke pozri body 21-26 tohto rozhodnutia Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 2 23
  5. V súvislosti s položkou č. 6 navrhovateľ vo vysvetlení uviedol rovnaké skutočnosti ako uviedol v námietkach, kde podrobne zhrnul, ako je požadovaná funkcionalita implementovaná (pozri body 27-33 tohto rozhodnutia).
  6. K položke č. 8 navrhovateľ, okrem iného3, vo vysvetlení uviedol, cit: „(...) • aktuálna podoba záložky „Evidencia majetku“ je generickým riešením, • špecifikácia požiadavky verejného obstarávateľa (napr. presný zoznam typov majetku, záväzné polia, väzby na ekonomický systém) nie sú v súťažných podkladoch detailne rozpracované, • po doručení presnej špecifikácie (napr. typ, názov, cena, inventárne číslo, účtová skupina...) je možné modul evidencie majetku jednoducho rozšíriť a nakonfigurovať tak, aby plne zodpovedal potrebám verejného obstarávateľa. (...)“
  7. Vo vzťahu k položke č. 10 navrhovateľ okrem iného4 vo vysvetlení priblížil architektúru ním ponúkaného riešenia a kontrolu na strane servera nasledovne, cit.: „(...) Pri nahrávaní prílohy systém postupuje takto:
  8. používateľ vyberie súbor (alebo ho pretiahne do aplikácie),
  9. klient odošle súbor na server
  10. serverový komponent registratúry zabezpečí kontrolu súboru – vrátane antivírusovej kontroly,
  11. ak je súbor v poriadku, uloží sa do úložiska a stane sa prílohou záznamu,
  12. ak kontrola zlyhá, nahratie je zablokované. Z hľadiska požiadavky „systém umožňuje antivírusovú kontrolu“ je teda podstatné, že: • architektúra počíta s integráciou antivírusu na strane servera, • antivírusová kontrola je súčasťou procesu nahrávania, • systém vie pri detekcii hrozby nahratie dokumentu zamietnuť. (...) Počas prezentácie sa využívalo demo prostredie v cloudovej inštalácii uchádzača. v tomto prostredí: • nebolo možné sprístupniť verejnému obstarávateľovi samotnú serverovú konzolu ani logy antivírusu, • webový klient xx nijako „neodhaľuje“ interné mechanizmy antivírusovej kontroly – používateľ vidí len výsledok (úspešné/neúspešné nahratie), nie proces na pozadí. Zistenie verejného obstarávateľa správne konštatuje, že „funkcionalitu nebolo možné otestovať“ – teda nie, že neexistuje alebo že ju systém neumožňuje, ale že v zvolenom demo scenári nebolo možné nahliadnuť do infraštruktúry, kde táto kontrola prebieha. (...) Počas diskusie k tejto požiadavke sme vysvetlili, že: • registratúra nezabezpečuje antivírusovú kontrolu pracovnej stanice – zodpovednosť za ochranu koncových staníc je na strane verejného obstarávateľa, • ak verejný obstarávateľ požaduje, aby sa antivírusová kontrola vykonávala už v momente výberu súboru na pracovnej stanici, je potrebné splniť prerekvizitu: o mať na pracovnej stanici korektne nainštalovaný antivírus, o mať zakúpenú napr. licenciu ESET- Anti-Malware SDK alebo obdobné rozhranie, ktoré umožňuje, aby aplikácia xx „vyvolala“ lokálnu antivírusovú kontrolu ešte pred odoslaním súboru na server. 3 Celý rozsah namietaných skutočností vo vzťahu k predmetnej položke pozri body 34-37 tohto rozhodnutia Celý rozsah namietaných skutočností vo vzťahu k predmetnej položke pozri body 38-45 tohto rozhodnutia Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 4 24 Systém xx je pripravený takúto integráciu využiť – je možné upraviť služby tak, aby sa pri nahrávaní súboru najprv zavolala antivírusová kontrola (serverová alebo klientska) a až následne došlo k samotnému uloženiu. Ide však o rozšírenie pôvodnej požiadavky smerom ku klientskej stanici a jej licencovaniu, nie o základný parameter registratúrneho systému. (...)“
  13. Dňa
  14. 2025 bol navrhovateľovi doručený dokument „Vyhodnotenie kritérií na vyhodnotenie ponúk“ z toho istého dňa (ďalej len „vyhodnotenie kritérií“)5, v ktorom mu bolo oznámené, že kontrolovaný vykonal prepočet bodov za funkcionality systému, ktoré počas procesu testovania nebolo možné overiť. Na základe toho došlo k zmene bodového ohodnotenia. Úrad zistil, že z návrhu na plnenie kritéria za kritérium č. 2 predloženého v ponuke z celkových pôvodne 20 pridelených bodov kontrolovaný pridelil navrhovateľovi 10 bodov za kritérium č. 2, čím sa ponuka navrhovateľa posunula z prvého miesta v poradí a je komisiou vyhodnotená ako priebežne druhá v poradí. Následne dňa
  15. 2025 doručil navrhovateľ námietky úradu aj kontrolovanému.
  16. Úrad uvádza, že navrhovateľ namieta nesprávne a netransparentné vyhodnotenie technických parametrov svojej ponuky v rámci kritéria č.
  17. Kontrolovanému vyčíta, že mu nepridelil body za päť funkčných oblastí (skenovanie, metadáta, zastupovanie, evidencia majetku a antivírusová kontrola), hoci navrhovateľ deklaruje ich existenciu v systéme aj v sprievodnej dokumentácii.

navrhovateľa kontrolovaný pri testovaní zamenil nedostatky vlastnej infraštruktúry za chyby systému navrhovateľa a uplatnil subjektívne, vopred nedefinované požiadavky na spôsob zobrazenia a ovládania funkcií. Navrhovateľ tvrdí, že kontrolovaný ignoroval materiálnu podstatu ponúkaného riešenia a uprednostnil formálne alebo technicky nesprávne závery z testovania, čím neoprávnene znížil bodové hodnotenie navrhovateľa a ovplyvnil priebežné poradie uchádzačov. 86. Kontrolovaný sa bráni tým, že navrhovateľ nepreukázal požadované funkcionality priamo v predloženej testovacej vzorke počas riadneho testovania v súlade so záväznou metodikou vyhodnocovania vzorky. Kontrolovaný zdôrazňuje, že online ukážka z vlastného prostredia uchádzača nie je prípustnou náhradou testu a že

pravidiel súťaže uchádzač nemal právo na predloženie opravenej verzie vzorky po zistení nedostatkov. Kontrolovaný trvá na tom, že funkcionality museli byť dostupné pre bežných koncových používateľov a viditeľné bez hĺbkového skúmania histórie záznamov, čo v predloženej testovacej verzii nebolo splnené.

  1. Úlohou úradu v tomto námietkovom konaní bolo posúdiť, či kontrolovaný pri vyhodnocovaní kritéria č. 2 postupoval v súlade so zákonom o verejnom obstarávaní, najmä s princípmi transparentnosti, nediskriminácie a proporcionality, ako aj v súlade s metodikou vyhodnocovania vzorky zadefinovanej v súťažných podkladoch.
  2. Úrad vo všeobecnosti uvádza, že vyhodnocovanie ponúk, vrátane vyhodnocovania kritérií na vyhodnotenie ponúk, je výlučne v diskrečnej právomoci kontrolovaného. Zároveň však platí, že proces vyhodnocovania ponúk, teda aj kritérií na vyhodnotenie ponúk môže byť v rámci námietkového konania preskúmavaný zo strany úradu. Úlohou úradu je preto v tomto prípade posúdiť, či kontrolovaný pri vyhodnocovaní kritéria č. 2 u navrhovateľa postupoval 5 Úrad uvádza, že argumentácia a odôvodnenie kontrolovaného vo vyhodnotení kritérií je totožná s argumentáciou a odôvodnením kontrolovaného v jeho vyjadrení k námietkam, preto obsah dokumentu vyhodnotenie kritérií do rozhodnutia neuvádza. Obsah vyjadrenia kontrolovaného pozri body 51-62 tohto rozhodnutia. Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 25 v súlade so zákonom o verejnom obstarávaní a či kontrolovaný neopomenul vykonať úkony, ktoré mu vyplývajú z tohto zákona. K položke č. 1 (skenovanie dokumentov)
  3. Preskúmaním dokumentácie kontrolovaného úrad dospel k zisteniu, že ústredným problémom pri testovaní položky č. 1 bola skutočnosť, že na notebooku kontrolovaného nebola nainštalovaná klientska aplikácia xy a integračný konektor, ktoré predstavujú nevyhnutnú súčasť systému xx na to, aby systém vedel realizovať skenovanie dokumentov v zmysle požiadavky zadefinovanej v súťažných podkladoch.
  4. Z námietok navrhovateľa vyplýva, že zlyhanie testovania bolo spôsobené výlučne nepripravenosťou testovacieho pracoviska, a teda zlyhanie testovania položky č. 1 kladie na ťarchu kontrolovanému, ktorý mal mať nainštalovanú klientsku aplikáciu xy, aby testovanie mohlo bezproblémovo prebehnúť. Z dokumentácie kontrolovaného ďalej vyplýva, že po prvom neúspešnom pokuse testovať položku č. 1, resp. po zistení skutočnosti, že k testovaniu chýba zásadná prerekvizita – aplikácia xy, dal kontrolovaný zástupcom navrhovateľa priestor na inštaláciu klientskej aplikácie, a to na notebook kontrolovaného, prípadne na zariadenia zástupcov navrhovateľa.
  5. Preskúmaním dokumentácie kontrolovaného úrad zo záznamu z priebehu testovania s názvom „Technicka kontrola podmienok sutaze-20251027_090118-Nahrávanie schôdze“ (ďalej len „záznam č. 1“) čas od 0:11:00 zistil, že zariadenie, na ktorom prebiehalo testovanie, vykazovalo pri aplikácii Rk xy konektor hlášku „Neobsahuje Vaša licencia“, pozri obrázok nižšie: xxxx
  6. Zo záznamu z priebehu testovania s názvom „testovanie registratúry scanovanie20251027_130918-Nahrávanie schôdze“ (ďalej len záznam č. 2“) vyplýva, že zástupca navrhovateľa sa po neúspešnom prvom pokuse o testovanie položky č. 1 snažil prostredníctvom MS Teams zaslať kontrolovanému inštalačný balíček absentujúcej aplikácie, čo ale z dôvodu veľkosti objemu dát nebolo možné. Zástupca navrhovateľa navrhol, že najlepším riešením bude funkcionalitu demonštrovať prostredníctvom zdieľanej obrazovky na vlastnom zariadení, na ktorom má aplikáciu xy nainštalovanú. Zástupca navrhovateľa zároveň konštatoval, že pokiaľ nemá správu nad počítačom kontrolovaného, nevedel by nakonfigurovať inštaláciu aplikácie cez MS Teams a asi by testovanie funkcionality ani nevedel odprezentovať bez inštalácie; členka komisie kontrolovaného teda pristúpila na testovanie položky č. 1 prostredníctvom zdieľanej obrazovky, ktoré prebiehalo „online“, na zariadení zástupcu navrhovateľa. K navrhovanej forme testovania členka komisie kontrolovaného skonštatovala, že môže prebehnúť, ale dodala, že sa opýta riaditeľa, či táto forma testovania postačuje. Testovanie položky č. 1 teda prebehlo dodatočne, formou zdieľanej obrazovky - „online“ - v prostredí navrhovateľa, na zariadení zástupcu navrhovateľa. Vo vyhodnotení kritérií kontrolovaný skonštatoval, že funkcionalita testovania nebola preukázaná, nakoľko v predloženej testovacej verzii systému nebolo možné tento parameter overiť.
  7. V nadväznosti na uvedené úrad poukazuje na navrhovateľovu odpoveď na výzvu kontrolovaného, v ktorej si zvolil ako formu testovacej verzie systému cloudovú verziu softvéru; navrhovateľ si teda dobrovoľne zvolil uvedený testovací scenár. Úrad ďalej poukazuje na to, že v odpovedi na výzvu kontrolovaného navrhovateľ neuviedol žiadne Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 26 informácie alebo inštrukcie o potrebe súčinnosti k priebehu a potrebám navrhovateľa nevyhnutných na účely testovania, žiadne špecifické inštrukcie či požiadavky, ktoré od kontrolovaného potrebuje ako nevyhnutnú súčinnosť na účely testovania; napriek tomu však zlyhanie testovania dáva navrhovateľ za vinu kontrolovanému, ktorý aplikáciu xy nemal nainštalovanú. Úradu z námietok navrhovateľa vyplýva, že jeho argumentácia smeruje primárne k tomu, že hlavný problém pri pokuse o testovanie položky č. 1 spočíval v nepripravenosti kontrolovaného, ktorý navrhovateľovi neposkytol riadnu súčinnosť, čím mu de facto znemožnil odprezentovať testovanie funkcionality položky č.
  8. Úrad v tomto bode poukazuje na to, že riadna príprava testovacej verzie systému, príprava na testovanie a prezentácia ponuky bola výlučne úlohou navrhovateľa, nakoľko celý tento proces tvorí súčasť jeho ponuky. Úrad zdôrazňuje, že príprava ponuky je výlučne v kompetencii záujemcov, resp. uchádzačov a v prípade, ak v procese prípravy ponuky súťažné podklady nie sú zrozumiteľné, či jednotlivé inštrukcie v súťažných podkladoch, každý záujemca má právo na vysvetlenie súťažných podkladov, ktoré je možné realizovať do uplynutia lehoty na predkladanie ponúk. Navrhovateľ však túto možnosť nevyužil, z čoho možno usúdiť, že znenie súťažných podkladov mu bolo zrejmé.
  9. Úrad ďalej poukazuje na to, že navrhovateľ v rámci komunikácie s kontrolovaným nedal na vedomie, že aby mohlo prebehnúť testovanie položky č. 1, bude nevyhnutné, aby si kontrolovaný vopred nainštaloval aplikáciu xy. Úradu zároveň nie je známe, či kontrolovaný pred začiatkom testovania vôbec mal od navrhovateľa k dispozícii inštalačný balíček predmetnej aplikácie. Úrad zároveň zistil, že predmetnú aplikáciu nemali nainštalovanú ani len zástupcovia navrhovateľa prítomní na testovaní a nemali ju k dispozícii ani napr. na externom zariadení na účely toho, aby aplikáciu pred začiatkom testovania na notebook kontrolovaného nainštalovali, prípadne aby mohli uskutočniť potrebné konfigurácie na to, aby testovanie položky č. 1 mohlo prebehnúť. Úrad prístup navrhovateľa v predmetnej situácii považuje za jeho pochybenie, a to v podobe nedostatočnej prípravy na testovanie, keď opomenul inštaláciu nevyhnutných prerekvizít na zariadeniach navrhovateľa, pričom v snahe nepripustiť si svoje pochybenie kladie vinu na kontrolovaného. Úrad je toho názoru, že nakoľko si navrhovateľ sám zvolil typ testovacieho scenáru, vedel, resp. mal a mohol predpokladať, čo všetko bude potrebovať na úspešnú prezentáciu funkčnosti jednotlivých funkcionalít, vrátane položky č. 1 týkajúcej sa skenovania dokumentov. Úrad má za to, že navrhovateľ sa neprimerane „spoliehal“ na kontrolovaného, resp. od neho očakával, že si nainštaluje klientsku aplikáciu bez toho, aby ho pred začiatkom testovania upovedomil o nevyhnutnosti jej inštalácie na notebooku kontrolovaného. Úrad má za to, že navrhovateľ takýmto nedovoleným spôsobom prenáša bremeno plnenia svojich povinností na kontrolovaného.
  10. Úrad ďalej konštatuje, že kontrolovaný dal navrhovateľovi dostatočný priestor na vyriešenie vzniknutej situácie, nakoľko mu dal možnosť inštalácie chýbajúcej aplikácie na notebooku kontrolovaného, no navrhovateľ na mieste nemal k dispozícii inštalačný balíček aplikácie. Kontrolovaný tiež súhlasil, aby zástupca navrhovateľa poslal inštalačný balíček aplikácie elektronicky prostredníctvom platformy Sharepoint, to však nebolo možné zrealizovať z dôvodu veľkosti objemu dát inštalačného balíčka. Ako už úrad uviedol, ani zástupcovia navrhovateľa nemali aplikáciu xy nainštalovanú na notebookoch, ktoré mali k dispozícii v čase testovania. V tomto bode teda nemožno konštatovať, ani kontrolovanému vytknúť, že navrhovateľovi neposkytol dostatočný priestor, či možnosť vzniknutú situáciu vyriešiť, práve naopak, kontrolovaný v rámci možností, ktoré povoľovali súťažné podklady, umožnil navrhovateľovi vzniknutú situáciu „ad hoc“ vyriešiť. To, že navrhovateľ nebol na takúto situáciu pripravený, nemožno dávať za vinu kontrolovanému. Na základe uvedeného má úrad Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 27 za to, že navrhovateľ je subjektom, ktorý si sám zavinil problémy, ktoré sa vyskytli pri testovaní položky č.
  11. Druhá rovina argumentácie navrhovateľa spočíva v tom, že podstatou testovania malo byť preukázanie, že systém umožňuje skenovanie prostredníctvom klientskej aplikácie, a teda stačí preukázať, že funkcionalita ako taká je v systéme prítomná, teda existuje. Navrhovateľ týmto výkladom predmetného kritéria

názoru úradu mení stanovenú požiadavku a účel samotného testovania. Cieľom testovania bolo overenie, či systém spĺňa požiadavky na funkcionalitu, kompatibilitu a použiteľnosť v reálnych podmienkach, z čoho vyplýva, že prostredníctvom testovania mala byť preukázaná funkčnosť skenovania v predloženej vzorke systému v reálnom čase, teda počas testovania. V predmetnom prípade je teda rozhodujúcou skutočnosťou to, či navrhovateľ preukázal funkčnosť skenovania v predloženej testovacej vzorke systému, v čase testovania.

  1. Úrad poukazuje na to, že navrhovateľ síce dodatočne prezentoval existenciu, resp. funkčnosť funkcionality skenovania formou zdieľanej obrazovky, „online“ v prostredí zástupcu navrhovateľa, no takýto spôsob demonštrácie funkcionality nie je v zmysle Prílohy č. 7 akceptovateľným testovacím scenárom, nakoľko jasne hovorí, že testovanie musí prebiehať na vzorke systému, ktorá bola predložená na základe výzvy kontrolovaného, čo navrhovateľ nesplnil. Dodatočná online demonštrácia funkcionality skenovania totiž nebola realizovaná na predloženej testovacej verzii systému, ale inej verzii a zároveň v prostredí navrhovateľa.
  2. Úrad ďalej poukazuje na to, že akceptovanie online demonštrácie funkcionality skenovania v prostredí navrhovateľa by bolo v rozpore so súťažnými podkladmi, konkrétne s metodikou vyhodnocovania vzorky uvedenou v spomenutej Prílohe č.
  3. Úrad má za to, že akceptovaním dodatočne prezentovanej funkcionality formou zdieľanej obrazovky by kontrolovaný postupoval v rozpore so súťažnými podkladmi, a teda v rozpore so zákonom o verejnom obstarávaní. Úrad na dôvažok dodáva, že v zmysle súťažných podkladov kontrolovaný nemal dať navrhovateľovi ani len priestor na demonštráciu preukazovania predmetnej funkcionality v online prostredí formou zdieľanej obrazovky v prostredí navrhovateľa, mimo predloženej testovacej verzie systému.
  4. Na základe uvedeného úrad konštatuje, že nepridelenie dvoch bodov za predmetné kritérium č. 2 z dôvodu, že v predloženej testovacej verzii systému nebolo možné v reálnom čase a zároveň v súlade so súťažnými podkladmi funkcionalitu skenovania dokumentov objektívne overiť, bolo zo strany kontrolovaného opodstatnené. Úrad má za to, že navrhovateľ v čase testovania nepreukázal funkčnosť skenovania v predloženej testovacej vzorke systému.
  5. Na základe vyššie uvedených skutočností úrad uvádza, že námietky navrhovateľa vo vzťahu k položke č. 1 sú neopodstatnené. K položke č. 2 (používateľsky definovateľné metadáta)
  6. Navrhovateľ vo vzťahu k predmetnej položke v námietkach tvrdí, že kľúčové nedorozumenie vzniklo pri výklade pojmu „používateľsky definovateľné“ a má za to, že komisia kontrolovaného v rámci diskusie zúžila výklad tohto pojmu tak, že možnosť definovať metadáta musí mať každý bežný koncový užívateľ priamo v používateľskom formulári, bez vstupu do administrácie.

navrhovateľa bolo jediným nedostatkom to, že komisia kontrolovaného spätne zúžila model oprávnení, resp. presadila odlišný model oprávnení, ktoré nevyplýva zo súťažných podkladov. Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 28 102. Preskúmaním dokumentácie kontrolovaného úrad zistil, že z vysvetlenia navrhovateľa a zároveň aj zo záznamu č. 1 vyplýva, že počas testovania boli najprv prezentované už vopred nakonfigurované polia na zázname a súvisiace možnosti vyhľadávania. Následne, po diskusii medzi zástupcami navrhovateľa a komisiou kontrolovaného navrhovateľ zistil, čo kontrolovaný v rámci tohto kritéria požadoval a čo pod pojmom „používateľsky definovateľné“ kontrolovaný mienil. V čase od cca 2:23:50 záznamu č. 1 člen komisie kontrolovaného skonštatoval, že metadáta mohol navrhovateľ ukázať, keď ich už tam má, „aby uzavreli aspoň ten druhý bod“. Na to mu zástupca navrhovateľa odpovedal, že pri testovaní chýbala funkcionalita „odfajknutie voliteľné“, na čo druhý zástupca navrhovateľa dodal, že „to tam potrebuje upgrade“, lebo nevedel, aké polia tam kontrolovaný požaduje a tiež dodal, že to môžu ukázať „na druhej“. Z uvedeného je

názoru úradu zrejmé, že sa jednalo o diskusiu zástupcov navrhovateľa o tom, že predložená testovacia verzia systému nedisponuje funkcionalitou „voliteľné“ polia a teda v čase testovania testovacej verzie systému táto nedisponovala funkcionalitou používateľsky definovateľných metadát, resp. voliteľných polí tak, ako to bolo zadefinované v súťažných podkladoch.

  1. Úrad zároveň zistil, že funkcionalita možnosti definovať metadáta, teda existencia možnosti voliteľných polí bola demonštrovaná v zázname „AA - testovanie registratúry20251027_141940-Nahrávanie schôdze“ (ďalej len „záznam č. 3“), ktorý bol vyhotovený dodatočne, a to z testovania, ktoré sa uskutočnilo až po ukončení oficiálneho testovania. Úradu zároveň nie je zrejmé, či uskutočnená prezentácia predmetnej funkcionality v zázname č. 3 bola realizovateľná vďaka doplneniu funkcionality, resp. uskutočnením spomínaného nutného „upgrade“ predloženej testovacej verzie systému, alebo bola demonštrovaná na „tej druhej“ verzii systému.
  2. V nadväznosti na uvedené však úrad opäť poukazuje na to, že v predmetnom prípade nebol spor o tom, či systém xx disponuje predmetnou funkcionalitou, resp. či je možné upraviť ho tak, aby bolo možné definovať metadáta. Problém nastal v bode, kedy v navrhovateľom predloženej testovacej verzii systému a v čase hlavného testovania nebolo možné definovať metadáta, resp. táto funkcionalita nebola odprezentovaná a preukázaná. Ako už vyplýva z vyššie uvedeného a z vysvetlenia, navrhovateľ v rámci „
  3. kola testovania“ demonštroval už vopred nakonfigurované polia záznamu. To znamená, že navrhovateľom predložená testovacia verzia nedisponovala funkcionalitou „voliteľných polí“, ergo používateľsky definovateľných metadát. Táto skutočnosť vyplýva aj z vyhodnotenia kritérií a vyjadrenia kontrolovaného, ktorý dôvodí nepridelenie bodov za predmetné kritérium práve tým, že počas testovania nebola preukázaná možnosť používateľsky definovať metadáta. Úrad poukazuje na to, že v zmysle bodu
  4. Prílohy č. 7 uchádzač nemá právo predložiť na testovanie opravenú verziu systému, a teda kontrolovaný v súlade so súťažnými podkladmi navrhovateľovi nemohol prideliť body za položku č.
  5. Z uvedených skutočností

názoru úradu vyplýva, že počas testovania v navrhovateľom predloženej testovacej verzii systému navrhovateľ nepreukázal možnosť definovať metadáta. 105. Argumentáciu navrhovateľa ohľadom „kľúčového nedorozumenia“, ktoré

jeho názoru spočívalo v reštriktívnom výklade pojmu používateľsky definovateľné zo strany kontrolovaného úrad považuje za bezpredmetnú, nakoľko uvedená skutočnosť nemala nijaký vplyv na výsledné vyhodnotenie, teda (ne)pridelenie bodov za túto funkcionalitu. Kontrolovaný vo vyhodnotení kritérií skonštatoval, že sa so zástupcami navrhovateľa zhodli, že možnosť definovať metadáta by mal mať len správca systému. Táto skutočnosť však nijakým spôsobom nevstúpila do vyhodnotenia predmetného kritéria. Kontrolovaný vo svojom vyjadrení zároveň uviedol, že nikde v dokumentácii nepožaduje, aby možnosť Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 29 definovať metadáta mal každý bežný koncový užívateľ, pričom určenie konkrétnych zamestnancov oprávnených na definovanie metadát je pri tejto otázke irelevantné. Podstatným záverom pri tejto funkcionalite bol fakt, že počas testovania nebola preukázaná možnosť používateľsky definovať metadáta v navrhovateľom predloženej testovacej verzii systému. Z uvedeného vyplýva, že nepridelenie dvoch bodov za predmetné kritérium nespočíva v tom, že ponuka navrhovateľa nesplnila predmetný parameter, resp. že metadáta nemôže definovať každý jeden používateľ, ale že počas testovania v predloženej testovacej verzii systému nebola v súlade so súťažnými podkladmi vôbec preukázaná možnosť definovať metadáta. Úrad má za preukázané, že navrhovateľ počas testovania odprezentoval metadáta v ním predloženej testovacej verzii systému, ktoré ako sám vo vysvetlení uvádza, boli najprv prezentované ako už vopred nakonfigurované polia na zázname. Úrad má za to, že z vyjadrení zástupcov navrhovateľa zachytených v zázname č. 1 je zrejmé, že funkcionalita definovateľných metadát v čase testovania nebola dostupná. Z Prílohy č. 7

úradu jasne vyplýva, že testovanie má prebehnúť v testovacej verzii predloženej navrhovateľom ešte pred realizáciou testovania a zároveň, že na testovanie nie je možné predložiť opravenú verziu systému. V neposlednom rade je v bode

  1. Prílohy č. 7 ustanovené, že testovacia verzia systému má byť uchádzačom naplnená testovacími údajmi pred testovaním tak, aby tieto údaje zohľadňovali špecifiká verejného obstarávateľa a čo najvernejšie simulovali reálnu prevádzku verejného obstarávateľa, čo v predmetnom prípade vo vzťahu k priebehu testovania nie je možné konštatovať.
  2. Na základe vyššie uvedených skutočností úrad uvádza, že námietky navrhovateľa vo vzťahu k položke č. 2 sú neopodstatnené. K položke č. 6 (zastupovanie)
  3. Navrhovateľ v námietkach poukazuje na to, že z jazykového a vecného výkladu predmetnej požiadavky vyplýva, že kontrolovaný stanovil tri prvky: Ad 1.) zastupovanie musí byť vždy viditeľné, Ad 2.) informácia má byť viazaná na konkrétny registratúrny záznam, Ad 3.) zastupovanie má byť označené značkou; súťažné podklady teda

navrhovateľa definujú funkčný výsledok, nie konkrétny technický spôsob implementácie. K uvedenému úrad uvádza, že navrhovateľ účelovo obracia argumentáciu a výklad predmetnej požiadavky, nakoľko v Prílohe č. 2 je jasne vymedzené, že zastupovanie má byť vždy viditeľné na zázname značkou napr. „v. z.“. Argumentácia navrhovateľa smerom k tomu, že sa má jednať o funkčný výsledok, nie konkrétny spôsob implementácie je síce pravdivá, no úradu sa javí, že navrhovateľ nepochopil podstatu tejto požiadavky. 108.

názoru úradu, navrhovateľ počas testovania demonštroval zobrazenie zastupovania, ktoré funkčný výsledok neobsahovalo, nakoľko údaje o zastupovaní bolo možné dohľadať iba v histórii záznamu, a to tiež iba s označením „vykonal“ a „spracovateľ“ čo znamená, že navrhovateľ nepoužil parameter viditeľnosti zastupovania pomocou špecifickej značky priamo na zázname, ktorý by bol jednoznačne, trvalo a preukázateľne zobrazovaný. Problém teda nie je v samotnej implementácii riešenia zastupovania ako takého, ale v tom, že v navrhovateľom prezentovanom riešení, resp. z navrhovateľom demonštrovaného označenia zastupovania nie je explicitne zrejmé, že ten-ktorý úkon bol vykonaný v zastúpení.

názoru úradu zároveň z tohto typu označenia zastupovania nie je možné jednoznačne identifikovať, kto za koho daný úkon vykonal, nakoľko nemusí byť zrejmé, kto je „riadny“ spracovateľ agendy. Z navrhovateľovho riešenia

úradu nie je jednoznačne identifikovateľné, kto v čase zastupovania zverenú agendu vykonával/vykonal. V navrhovateľovom riešení zároveň nie je nikde na zázname explicitné označenie, že úkon Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 30 bol vykonaný v zastúpení a

názoru úradu značka „vykonal“ a „spracovateľ“ to explicitne nedokazuje a teda nenapĺňa podstatu/účel kontrolovaným požadovaného kritéria.

  1. Úrad má ďalej za to, že z predmetnej požiadavky jasne vyplýva, že kontrolovaný požaduje, aby pri vykonaní úkonu v zastúpení bola pri/na danom zázname trvalo umiestnená značka, ktorá jednoznačne deklaruje, že úkon bol vykonaný v zastúpení, a to bez toho, aby bolo potrebné uvedené informácie hľadať v histórii záznamu. Úrad zároveň poukazuje na to, že nikde v súťažných podkladoch nie je explicitne uvedené, že označenie zastupovania na zázname má byť výlučne značka „v.z.“. V tomto prípade sa jednalo len o nesprávnu/účelovú interpretáciu navrhovateľa, ktorou bez akéhokoľvek logického odôvodnenia zúžil výklad predmetného kritéria, pričom následne tento výklad obrátil v neprospech kontrolovaného.
  2. Kontrolovaný v súťažných podkladoch príkladmo uviedol značku ako môže, ale nemusí byť zastupovanie označené na zázname; nie je teda výlučne vymedzené, že zastupovanie má obsahovať práve a len označenie „v.z.“, mohla to byť teda aj iná značka. Podstata „problému“

názoru úradu spočíva v tom, že v navrhovateľovom riešení nebola priamo na zázname trvalo umiestnená žiadna značka, resp. informácia o tom, že úkon bol uskutočnený v zastúpení. Tvrdenie navrhovateľa, že kontrolovaný zúžil výklad predmetného kritéria a vylúčil akékoľvek iné riešenie zastupovania okrem osobitnej značky v jedom konkrétnom prehľade registratúrnych záznamov formou značky „v.z.“ je irelevantné a bezpredmetné, nakoľko táto skutočnosť ani nie je meritom problému. Úradu sa javí, že navrhovateľ si svojím výkladom predmetného kritéria účelovo prispôsobuje argumentáciu tak, aby napravil vzniknutú situáciu a nemusel tak priznať svoje nepochopenie, či nesprávnu interpretáciu súťažných podkladov. Úrad zároveň dodáva, že ak navrhovateľovi nebolo zrejmé znenie predmetného kritéria, mal pred uplynutím lehoty na predkladanie ponúk požiadať kontrolovaného o vysvetlenie súťažných podkladov, čo však neurobil.

  1. Úrad ďalej konštatuje, že v zázname č. 1, v čase 1:48:40 zástupca navrhovateľa skonštatoval a potvrdil, že „na zázname chýba značka „v.z.“ a je to najmenej to doplniť“, čo opäť len potvrdzuje, že navrhovateľom predložený systém v čase testovania neobsahoval funkcionalitu, ktorá obsahuje riešenie vždy viditeľného označenia zastupovania na zázname, pričom problémom nie je vizuál/gramatické označenie zastupovania, ale skutočnosť, že trvalé označenie priamo na zázname absentovalo. Navrhovateľ argumentuje tým, že jeho systém iba iným spôsobom eviduje zastupovanie, pričom poukazuje na to, že jeho systém režim zastupovania umožňuje; to však kontrolovaný nijako nerozporuje. Rovnako ako vyplýva zo záverov v prípade testovania predchádzajúcich položiek, dôvodom nepridelenia bodov za predmetnú funkcionalitu nie je skutočnosť, že by navrhovateľom ponúknutý systém neumožňoval funkcionalitu zastupovania, ale že počas testovania nebola preukázaná funkcionalita viditeľnosti zastupovania na zázname značkou. Ak by navrhovateľ nepreukázal existenciu samotného systému zastupovania, viedlo by to nie k neprideleniu bodov, ale k vylúčeniu ponuky pre nesplnenie požiadaviek na predmet zákazky. Úrad sa stotožňuje s argumentáciou kontrolovaného, že testovací systém navrhovateľa poskytol iba indikáciu v hlavičke, ktorá je viditeľná len pre používateľa, ktorý zastupuje, teda nie pre všetkých používateľov a nejednoznačné údaje v histórii. Úrad má za to, že kontrolovaný teda mohol dospieť k záveru, že navrhovateľ v testovacej verzii počas testovania nepreukázal parameter viditeľnosti zastupovania pomocou špecifickej značky priamo na zázname, ktorý by bol jednoznačne, trvalo a preukázateľne zobrazovaný.
  2. V nadväznosti na vyššie uvedené skutočnosti úrad konštatuje, že predmetné kritérium nebolo počas testovania v testovacej verzii systému preukázané, a preto považuje námietky navrhovateľa vo vzťahu k položke č. 6 za neopodstatnené. Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 31 K položke č. 8 (evidencia majetku)
  3. Úrad zistil, že z námietok v predmetnej časti vyplýva, že navrhovateľ apeloval na to, že podstatnou skutočnosťou pri testovaní predmetnej položky je, že architektúra a funkcionalita systému umožňujú evidenciu a preraďovanie majetku v rámci procesov registratúry, t. j. že systém vie viazať údaje o majetku na konkrétny záznam alebo spis a spracovať ich v rámci schvaľovacích a priraďovacích workflow, čo

neho počas testovania bolo preukázané. Zároveň navrhovateľ argumentoval, že to, či sa záložka „voliteľné“ zobrazuje vo všetkých záznamoch alebo len pri vybraných typoch záznamov je konfiguračná otázka, nie dôkaz absencie funkcionality.

  1. Úrad ďalej zistil, že po začatí testovania predmetnej funkcionality zástupcovia navrhovateľa „narazili“ na problém, resp. si kontrolovaný so zástupcom navrhovateľa ozrejmili, čo presne kontrolovaný vo vzťahu k evidencii majetku v rámci tohto kritéria požadoval. Zo záznamu č. 1, v čase cca od 2:00:00 úrad zistil, že zástupca navrhovateľa začal s testovaním predmetnej funkcionality. Komisia kontrolovaného pomerne rýchlo po začiatku prezentácie tejto funkcionality zástupcu navrhovateľa zastavila s tým, že im neukazuje to, čo bolo napísané v súťažných podkladoch ako kritérium, teda že obsah prezentácie testovania sa nezhoduje s popisom požiadavky na predmetnú funkcionalitu. Člen komisie kontrolovaného objasnil situáciu a skonštatoval, že ho rovno zastavuje z dôvodu, že im zástupca navrhovateľa prezentuje to, že systém vie evidovať majetok, prípadne preradenie majetku, ale takto nie je požiadavka zadefinovaná v súťažných podkladoch a vysvetlil, čo má táto funkcionalita obsahovať. Po vysvetlení člena komisie sa zástupca navrhovateľa opýtal, či majú na mysli evidenčnú kartu majetku, na čo mu člen komisie odpovedal potvrdením, že presne toto požadujú, cit: „vyslovene evidencia majetku a preraďovanie majetku“. Zástupca navrhovateľa na to reagoval cit.: „registratúra nie je SAP ani SPIN na evidenciu majetku, to sú dve galaxie, ktoré nikdy nie je dobré spájať. (...) vy si môžete spraviť nejakú evidenciu, registratúra je evidenčný systém, ale nejakú kartu zamestnanca, že mám dve myši, šesť stoličiek a tri vešiaky, to do registratúry prosím vás ani nikdy nepovedzte, že to chcete“. Ďalej zástupca navrhovateľa konštatoval, že v systéme xx je proces na to, že je možné si interným záznamom spustiť proces vyradenia a je podporovaný, ale opäť dôrazne odporúčal kontrolovanému, aby si registratúru nespájal s evidenciou a preraďovaním majetku.
  2. Zo záznamu č. 3, v čase cca od 0:07:00 je zaznamenané, že zástupca navrhovateľa dodatočne demonštroval možnosť evidencie majetku, resp. možnosť vytvorenia evidenčnej karty majetku v systéme xx, pričom konštatoval, že samotná evidencia v registratúre je k dispozícii. Následne na to komisia kontrolovaného vo vyhodnotení kritérií skonštatovala, že funkcionalita evidencie majetku nebola preukázaná, nakoľko v predloženej testovacej verzii systému táto funkcionalita chýbala.
  3. Na základe zistených skutočností úrad konštatuje, že v predmetnom prípade sa opäť nejedná o otázku, či navrhovateľom predložený systém umožňuje evidenciu majetku, ale o to, či navrhovateľom predložená testovacia verzia systému disponovala v čase testovania, bez akýchkoľvek zásahov, funkcionalitou evidencie a preraďovania majetku. Úrad v tejto súvislosti opäť poukazuje na Prílohu č. 7, v zmysle ktorej bol kontrolovaný povinný postupovať pri vyhodnocovaní navrhovateľom predloženej vzorky, a teda nemohol akceptovať akékoľvek dodatočné úpravy či upgrade navrhovateľom predloženej vzorky, či predloženie opravenej verzie systému.
  4. V nadväznosti na všetky vyššie uvedené skutočnosti má úrad za preukázané, že v navrhovateľom predloženej testovacej vzorke systému v čase testovania nebola Tento dokument má iba informatívny charakter. Nie je použiteľný pre právne účely. Dokument je vytlačený z portálu Úradu pre verejné obstarávanie 32 preukázaná funkcionalita evidencie majetku a preraďovania majetku. Uvedenú skutočnosť

názoru úradu dokazuje aj samotná reakcia zástupcov navrhovateľa, ktorí boli po objasnení požiadavky kontrolovaného evidentne zaskočení, že kontrolovaný chce spájať registratúru s evidenciou majetku a tiež, že zástupcovia navrhovateľa preukazovali funkcionalitu systému dodatočne, čo vyplýva zo záznamu č.

  1. V nadväznosti na vyššie uvedené skutočnosti úrad konštatuje, že predmetné kritérium nebolo počas testovania v testovacej verzii systému preukázané, a preto považuje námietky navrhovateľa vo vzťahu k položke č. 8 za neopodstatnené. K položke č. 10 (bezpečnostné požiadavky)
  2. Úrad uvádza, že predmetná časť námietok pojednáva o testovaní funkcionality antivírusovej kontroly nahrávaných dokumentov a ich príloh. Navrhovateľ v tejto časti námietok opäť apeloval na to, že je podstatné, že architektúra navrhovateľom ponúkaného systému počíta s integráciou antivírusu na strane servera, že je súčasťou procesu nahrávania a systém vie pri detekcii hrozby nahranie dokumentu zamietnuť, čím je

navrhovateľa predmetný parameter splnený. Navrhovateľ vo vysvetlení aj v námietkach skonštatoval a priznal, že funkcionalitu nebolo možné otestovať z dôvodu zvoleného testovacieho scenáru, nakoľko v zvolenom demo scenári nebolo možné nahliadnuť do infraštruktúry, kde kontrola prebieha. Navrhovateľ zároveň poukazoval na to, že ak sám kontrolovaný priznal, že dôvodom, nemožnosti

🔗 Na úradný zdroj

AI výklad z oficiálneho znenia zákona. Orientačný, nenahrádza právne poradenstvo.