Na vsebino
EN
  • O DKOM
  • REVIZIJSKE ZADEVE
  • PREKRŠKOVNE ZADEVE
  • JAVNOST IN MEDIJI

    • 018-050/03

    Številka: 018-50/03-21-538
    Datum sprejema: 15. 4. 2003

    Sklep

    Državna revizijska komisija za revizijo postopkov oddaje javnih naročil (v nadaljevanju: Državna revizijska komisija) je na podlagi 23. člena Zakona o reviziji postopkov javnega naročanja (Uradni list RS, št. 78/99, 90/99, 110/02; v nadaljevanju: ZRPJN) v senatu â??, v postopku nadzora nad zakonitostjo postopka oddaje javnega naročila za postavitev sistema za elektronsko davčno poslovanje za potrebe â?? in na podlagi zahtevka za revizijo, ki ga je vložilo podjetje â?? (v nadaljevanju: vlagatelj) zoper ravnanje naročnika â?? (v nadaljevanju: naročnik),

    odločila:

    1. Zahtevek za revizijo se zavrne kot neutemeljen.
    2. Strokovnjaku/izvedencu informacijske stroke se za pripravo strokovnega/izvedenskega mnenja izplača znesek v višini 298.000,00 SIT. Del vplačanega predujma v višini 2.000,00 SIT se vrne vlagatelju na transakcijski račun â?? d.o.o., št. â??.

    Obrazložitev:

    Naročnik je, dne 07.06.2002, sprejel sklep, št. 060-18-2002-01-070, o začetku postopka oddaje javnega naročila po odprtem postopku za postavitev sistema za elektronsko davčno poslovanje za potrebe â??. Naročnik je v Uradnem listu RS, št. â??, z dne â??, pod številko objave Ob-â?? objavil javni razpis za predmetno javno naročilo. Iz zapisnika o javnem odpiranju ponudb, št. 060-18-2002-01-070, z dne 24.07.2002, je razvidno, da je naročnik prejel 5 pravočasnih ponudb.
    Naročnik je dne, 13.08.2002, kot najugodnejšega ponudnika izbral podjetje â?? (obvestilo o oddaji naročila, št. 060-18-2002-01-070). Vlagatelj je z dopisom, z dne 16.08.2002, zahteval od naročnika obrazloženo obvestilo o oddaji javnega naročila. Naročnik je, dne 22.08.2002, poslal vlagatelju zahtevano obrazloženo obvestilo, ki ga je vlagatelj prejel dne 26.08.2002.
    Zoper odločitev o izbiri najugodnejšega ponudnika je vlagatelj, dne 30.08.2002, vložil zahtevek za revizijo, v katerem je navedel, da je naročnik neupravičeno izločil njegovo ponudbo kot nepravilno iz razloga, da iz potrdila davčnega organa za podizvajalca vlagatelja â?? izhaja, da ima ta kot davčni zavezanec evidentirane neporavnane zapadle obveznosti iz naslova davka na dodano vrednost.
    Naročnik je s sklepom, št. 060-18/2002-01-843, z dne 17.09.2002, vlagateljev zahtevek za revizijo zavrnil kot neutemeljen. Naročnik je v obrazložitvi navedel, da iz potrdila izpostave davčnega urada Ljubljana, št. 47050-2941/2002-2-0892-063-113, z dne 10.07.2002, izhaja, da je imel vlagateljev podizvajalec na dan 10.07.2002 evidentirane zapadle obveznosti iz naslova davka na dodano vrednost.
    Vlagatelj je z dopisom, št. IPS 210-18-4/2, z dne 20.09.2002, obvestil naročnika, da na podlagi 17. člena ZRPJN nadaljuje postopek pred Državno revizijsko komisijo.

    Po proučitvi utemeljenosti navedb vlagatelja in naročnika ter po pregledu dokumentacije iz spisa je Državna revizijska komisija s sklepom, št. 018-212/02-24-1831, z dne 14.10.2002, odločila, da je zahtevek za revizijo utemeljen, zato je razveljavila naročnikovo odločitev o oddaji javnega naročila ter le-tega napotila naj ponovno opravi pregled in ocenjevanje ponudb, ob upoštevanju ugotovitev iz navedenega sklepa skladno z drugim odstavkom 23. člena ZRPJN.

    Naročnik je po ponovnem pregledu in ocenjevanju ponudb, kot najugodnejšega ponudnika ponovno izbral podjetje â?? (v nadaljevanju: izbrani ponudnik), kar je razvidno iz obvestila o oddaji naročila, št. 060-18/2002-1-070, z dne 24.01.2003. Naročnik je v istem obvestilu med drugim tudi navedel, da je vlagateljeva ponudba nepravilna.

    Vlagatelj je na podlagi 79. člena Zakona o javnih naročilih (Uradni list RS, št. 39/00 in 102/00; v nadaljnjem besedilu: ZJN-1) z dopisom, z dne 31.03.2003, zahteval od naročnika obrazloženo obvestilo o oddaji javnega naročila.
    Naročnik je dne 07.02.2003 vlagatelju posredoval zahtevano obrazloženo obvestilo v katerem navaja, da vlagateljeva ponudba ne izpolnjuje zahtev navedenih v razpisni dokumentaciji. Naročnik glede zahtev razpisne dokumentacije, ki se nanašajo na "potrdilo o uspešno prejetem obrazcu" navaja, da je v zahtevi EDP-Z-3 nedvoumno zahtevano, da so vsi statusi sprejemanja in obdelovanja dokumentov dosegljivi v EDP aplikaciji v brskalniku in da je pošiljanje elektronske pošte kot obvestila naročnika uporabniku, da je dokument uspešno prejet, lahko le opcija. Sistem "FormPipe Technical Description Ver. 2.2", ki je sestavni del vlagateljeve rešitve, omogoča dva načina obveščanja pošiljatelja obrazca po prejemu le-tega s strani "FormPipe" notarskega strežnika:
    - takoj po sprejemu dokumenta pred kakršnemkoli preverjanjem, se na zaslon uporabnika (pošiljatelja) postavi obvestilo o prejemu dokumenta,
    - po izvedenem preverjanju, verifikaciji in žigosanju "FormPipe" notarski strežnik lahko pošlje sporočilo po elektronski pošti brez ali s pripeto digitalno podpisano identično kopijo prejetega dokumenta.

    Naročnik zaključuje, da noben izmed navedenih načinov obveščanja ne izpolnjuje zahteve EDP-Z-3, ker:
    - je prikaz obvestila na zaslonu sporočilo in ne potrdilo, ker ne vsebuje vseh potrebnih elementov potrdila (to obvestilo ni digitalno podpisan dokument, ampak sporočilo, ki je na zaslonu toliko časa, dokler uporabnik ne potrdi opcije "OK"),
    - pošiljanje obvestil po elektronski pošti (z ali brez pripetih dokumentov) ni izpolnitev primarne zahteve definirane v EDP-Z-3, da morajo vsi statusi vključno z potrdilom o uspešnem prejemu biti vidni in dosegljivi skozi EDP aplikacijo v brskalniku in da je pošiljanje obvestil po elektronski pošti lahko le opcija.

    Naročnik še dodaja, da zaradi tega, ker ni izpolnjena zahteva EDP-Z-3, posledično tudi ni izpolnjena zahteva EDP-Z-122.

    Naročnik nadalje glede "uporabe odjemalcev" navaja, da je vlagatelj v ponudbi navedel, da sistem "FormPipe" lahko deluje:
    - s spletnim odjemalcem,
    - z aplikacijami kot so "MS Word" in "MS Excel" kot odjemalci,
    - s "FormPipe" odjemalcem (ločen odjemalec) s katerim lahko uporabnik dela brez povezave z EDP aplikacijo.

    Vlagatelj nadalje v EDP-Z-121 navaja, da ima "FormPipe" odjemalec izdelano funkcionalnost tiskanja obrazca, ki se lahko uporabi kadarkoli, ker se obrazci hranijo na uporabnikovem računalniku. V EDP-Z-132 pa vlagatelj navaja, da je z ločenim odjemalcem možno tudi interaktivno pripraviti sveženj obrazcev, pri čemer je tudi princip validacije isti, kot pri vnosu posameznega obrazca.

    Naročnik tako ugotavlja, da je pri navedenih funkcionalnostih:
    - tiskanje obrazcev na lokalnem tiskalniku,
    - interaktivni vnos podatkov v svežnje,
    - delno pripravljanje obrazcev,

    v opisih rešitev zahtev naveden samo "FormPipe" (ločeni) odjemalec, ki pa je namenjen delu brez povezave z EDP aplikacijo (opis rešitve zahteve EDP-Z-35) in ni odjemalec skozi brskalnik, kar je v nasprotju z izrecno naročnikovo zahtevo navedeno v EDP-Z-3, da mora vsa specificirana funkcionalnost odjemalca biti na razpolago in izvedljiva skozi EDP aplikacijo v brskalniku na postaji odjemalca.
    Zahteva EDP-Z-3 ni izpolnjena in posledično tudi ne zahtevi EDP-Z-121 in EDP-Z-132.

    Naročnik nadaljuje, da je glede "nalaganja ločenega odjemalca" vlagatelj v svoji ponudbi v opisu rešitve EDP-Z-35 navedel, da se vsa dodatna programska oprema, ki je potrebna za uporabo EDP sistema samodejno naloži preko spletnih strani uporabniku na računalnik. Morebitna dodatna oprema, ki se bo samodejno naložila uporabniku, je programska oprema za podporo uporabe pametnih kartic ter programska oprema za podporo delovanja ločenega odjemalca, ki omogoča uporabo EDP sistema brez povezave.
    V konceptualnem opisu (str. 90) je nadalje navedeno, da lahko uporabnik ločen odjemalec brez dodatnih stroškov naloži preko spleta v okviru spletnega portala EDP sistema.
    V dokumentaciji sistema "FormPipe", ki je priložena vlagateljevi ponudbi (Form Userâ??s Guide) pa je v angleškem jeziku navedeno (poglavje 4.1.2 na str. 7): "The FormPipe installer is a standard installation program with a step by step guide to help you trough installation process. A few aspects of the installation involve choices that are unique to FormPipe in terms of internet communication and potential security functions."

    Na podlagi navedenega naročnik ugotavlja, da so zgornje navedbe v medsebojnem nasprotju, saj je iz opisa v "konceptualnem opisu" razvidno, da uporabnik odloča o tem kdaj bo naložil ločeni odjemalec (â?? uporabnik lahko â??), medtem ko je v opisu rešitve zahteve EDP-Z-35 navedeno, da se nalaganje opravi samodejno (brez uporabnikovega sodelovanja). Iz uporabniškega priročnika (Form Userâ??s Guide) pa je razvidno, da se nalaganje izvede po korakih z vmesnimi odločitvami uporabnika. Na podlagi vsega navedenega naročnik ugotavlja, da zahteva EDP-Z-35 ni izpolnjena.

    Naročnik nadalje meni, da bi vlagatelj moral za vse dodatne funkcionalnosti in/ali dodatne programe smiselno slediti zahtevam v razpisni dokumentaciji in v ponudbi jasneje in bolj podrobno predstaviti uporabo različnih odjemalcev, predvsem na način:
    - da se jasno pokaže, da so vse zahtevane funkcionalnosti primarno izvedljive skladno zahtevam v razpisni dokumentaciji, predvsem skladno zahtevi EDP-Z-3 v spletnem odjemalcu;
    - da se jasno pokaže, kako dodatne funkcionalnosti in/ali dodatni programi (kot ločeni odjemalec) izvajajo zahtevane funkcionalnosti;
    - da je pri vsakem omenjanju odjemalca jasno na kateri odjemalec se opis nanaša. Vlagatelj včasih uporablja samo pojem "odjemalec", ne da bi iz tega bilo jasno ali se to nanaša na vse odjemalce ali na ločeni odjemalec ali pa na spletni odjemalec. Na primer v opisih rešitev zahtev EDP-Z-119 in EDP-Z-120 se omenja pojem "odjemalec" brez navedbe kateri, v opisu rešitve zahteve EDP-Z-121 pa "FormPipe" odjemalec. Vse tri omenjene zahteve se nanašajo na isto problematiko in sicer postopek vlaganja obrazca;
    - da bolj podrobno opiše uporabo odjemalcev. Vlagatelj navaja, da se obrazci lahko oddajo prek spletnega ali prek ločenega odjemalca, lahko lokalno shranjujejo preko spletnega ali preko ločenega odjemalca in podobno, ne opisuje pa, kako v primeru, ko končni uporabnik lahko uporabi le en ali drugi odjemalec, sistem skrbi za nadzor in evidenco nad lokalno shranjenimi obrazci, delno izpolnjenimi obrazci, ki se enkrat lahko shranijo lokalno, drugič pa na uporabnikovem delu notarskega strežnika in podobno ter kako sistem skrbi za nadzor in evidenco nad enim samim obrazcem, ki ga uporabnik lahko večkrat zaporedoma delno izpolnjuje z različnimi odjemalci shrani enkrat lokalno, drugič pa na notarskem strežniku in podobno.

    Naročnik zaključuje, da glede na vse navedeno ni izpolnjena splošna zahteva iz RD3 (tehnične zahteve na str. 19), da mora biti v ponudbi za vsako izmed zahtev konceptualno opisano, kako je zahteva izpolnjena. Ti konceptualni opisi morajo biti tako podrobni, da v njih ne bodo obstajale nejasnosti. V vsakem od teh opisov se besedilo lahko sklicuje na del ponudbe, kjer je potreben konceptualen opis, sklicevanje pa mora biti natančno (na primer z navedbo poglavja oziroma odstavka).

    Glede "časovnega žigosanja" naročnik navaja, da je v opisu zahteve EDP-Z-101 navedel zahtevo, da se oddani obrazci označijo s "časovnim žigom". Naročnik zahteva, da rešitev lahko izvaja žigosanje sama ali pa tako žigosanje prepusti pooblaščeni "TSA agenciji".
    Vlagatelj pa je v opisu rešitve zahteve EDP-Z-101 med drugim navedel, da notarski strežnik vsako sprejeto ovojnico (elektronski obrazec) ožigosa s časovnim žigom in shrani v bazo. Notarski strežnik omogoča žigosanje tudi v povezavi z zunanjo "TSA agencijo" na različne načine. Naročnik nadaljuje, da primarno predvideva in načrtuje uporabo bodoče "TSA agencije" za časovno žigosanje obrazcev, ko bo ta na razpolago. Ker pa ni mogoče z gotovostjo trditi, kdaj bodo storitve "TSA agencije" na voljo, se je naročnik odločil zahtevati tudi funkcionalnost "časovno žigosanje", ki ga bo izvajala rešitev sama. Naročnik dodaja, da bi bil tak način "časovnega žigosanja" predvidoma v uporabi do uvedbe "časovnega žigosanja" s strani "TSA agencije". Iz opisa vlagateljeve rešitve naročnik sklepa, da bo le-ta izvedel "časovno žigosanje" (z uporabo storitev "TSA agencije") s funkcionalnostmi, ki so že sestavni del notarskega strežnika. Po naročnikovem mnenju bi zato vlagatelj za izpolnitev te zahteve moral vsaj navesti kje v tehnični specifikaciji "FormPipe" notarskega strežnika je specificirana zahtevana funkcionalnost.
    Naročnik dodaja, da je pregledal priloženo tehnično dokumentacijo in ugotovil:
    - da je v priloženi dokumentaciji "Form Userâ??s Guide" na strani 6 omenjena funkcionalnost "Time stamping and registration". Iz slike je razvidno, da sistem predvideva le interno časovno označevanje (žigosanje) in se ne povezuje na morebitno TSA agencijo;
    - da tudi v dokumentaciji "FormPipe", ki je na razpolago na spletnih straneh, ki jih vlagatelj navaja v uvodu dokumenta "konceptualni opis", naročnik ni našel dokumentirane morebitne funkcionalnosti oziroma zmožnost povezovanja "FormPipe" notarskega strežnika na "TSA agencijo".

    Naročnik na podlagi navedenega zaključuje, da zahteva EDP-Z-101 ni izpolnjena, ker vlagatelj v opisu rešitve zahteve ni opisal kako bo izvedeno "časovno žigosanje" v povezavi z zunanjo "TSA agencijo" niti ni navedel drug vir podatkov, kjer bi to bilo opisano. Naročnik ob tem dodaja, da ni dvoma o tem, da sta v razpisni dokumentaciji zahtevana oba načina "časovnega žigosanja" in sicer, da ponujena rešitev lahko izvaja "časovno žigosanje" sama ali pa da le-to prepusti pooblaščeni "TSA agenciji". Nedvoumnost zahteve izhaja iz znanih objektivnih okoliščin, ki so:
    - namen "časovnega žigosanja" je generiranje pravno veljavnega digitalnega potrdila o uradnem času digitalnega podpisa dokumenta oziroma o tem, da je v času žigosanja digitalno potrdilo bilo veljavno (ni bilo preklicano s strani certifikacijske agencije),
    - "časovni žig" je pravno veljaven le, če ga je izdala pooblaščena TSA agencija,
    - SIGEN-CA načrtuje uvedbo TSA agencije.

    Glede uporabe "SOAP in XML" protokola v ponujeni rešitvi naročnik navaja, da je v zahtevi EDP-Z-27 med drugim navedena zahteva, da ponudnik zgradi ponujeno rešitev kot spletne storitve, z uporabo protokola "SOAP 1.1. in XML 1.0.". Navedeno zahtevo je naročnik v odgovoru, št. 0307-1, na zastavljeno vprašanje enega izmed ponudnikov, dodatno pojasnil z navedbo, da zahteva, da je protokol "SOAP 1.1." edini način izmenjave sporočil (tudi dokumentov in svežnjev) z odjemalci "zunanjih" uporabnikov. Izjema so na primer dokumenti, ki so namenjeni vsem uporabnikom ali vsem obiskovalcem naročnikovega spletnega portala (razna navodila, informacije, pomoč â??), ali pa tisti dokumenti določenega uporabnika, ki so uporabniku na razpolago za "download" kot del portala.

    Naročnik ugotavlja, da vlagatelj ni upošteval zahteve razpisne dokumentacije po uporabi standarda "XML 1.0." kot primarnega standarda, ampak primarno ponuja koncept "FormPipe" ovojnice v "MIME" formatu. Osnovno zahtevo naročnika, to je uporabo "XML 1.0." formata pa vlagatelj le omenja v smislu, da lahko uporabi tudi "XML" format.

    Naročnik glede na vse navedeno zaključuje, da vlagateljeva ponudba ne izpolnjuje zahteve razpisne dokumentacije EDP-Z-27.

    Glede "razširljivosti rešitve" na uporabo elektronske pošte naročnik navaja, da je v opisu zahteve EDP-Z-27 med drugim navedel, da naj bo ponujena rešitev koncipirana tako, da bi bila enostavno razširljiva tudi na uporabo elektronske pošte. Pri tem pod terminom "enostavno" naročnik upošteva tako koncipirano rešitev, ki bo v obe smeri komunicirala s sistemom elektronske pošte, s sporočili enake oblike, kakor jih bo uporabljal sinhroni oziroma spletni del rešitve. Pri tem naročnik zahteva, da ponudnik tudi opiše, kako bo rešil problem avtorizacije in digitalnega podpisovanja sporočil preko elektronske pošte. Navedeno zahtevo je naročnik v odgovoru, št. 0307-1, na zastavljeno vprašanje enega izmed ponudnikov, dodatno pojasnil z navedbo, da mora biti ponujena rešitev koncipirana tako, da bi bilo mogoče podobna sporočila v "SOAP" obliki izmenjevati tudi s sistemom elektronske pošte.

    Vlagatelj pa je v opisu svoje rešitve zahteve EDP-Z-27 navedel, da ker spletni nivo omogoča standardni vhod podatkov ne glede na izvor podatkov, je možno razširiti rešitev tudi na uporabo elektronske pošte. Pri tem je potrebno samo izluščiti iz elektronskega sporočila elektronski obrazec in ga poslati v obdelavo spletni storitvi. V obratni smeri pa je potrebno sestaviti elektronsko sporočilo ponovno po odprtem standardu "MIME" in ga poslati ustreznemu uporabniku. Elektronski obrazec mora biti vedno podpisan s strani uporabnika, kar nam omogoča avtorizacijo uporabnika. Uporabnik lahko obrazec, preden ga pošlje, podpiše s katerim koli programom za podpisovanje datotek (Vlagatelj je za te namene izdelal "HalSigner"). Pri podpisovanju elektronskih sporočil v obliki "MIME", pa se lahko podpiše tudi celo sporočilo.
    Naročnik ugotavlja, da pri zahtevanem opisu "razširitve rešitve" na uporabo elektronske pošte vlagatelj ni obravnaval šifriranja sporočil. To pa je potrebno glede na:
    - zahtevo EDP-Z-124, da mora biti prenos zaupnih podatkov iz obrazca na poti do uporabnika v EDP sistem maksimalno varovan z uporabo metod šifriranja ali z drugimi primernimi metodami, ki zagotavljajo popolno varnost prenosa zaupnih podatkov in glede na
    - zahtevo v razpisni dokumentaciji na strani 19, da je rešitev koncipirana tako, da bo razširljiva tudi na uporabo elektronske pošte na tak način, da bo aplikativni modul za EDP zmožen obdelovati podpisane in šifrirane dokumente, ki bodo prispeli preko elektronske pošte in bo prav tako zmožen preko elektronske pošte vračati ustrezna podpisana potrdila o prejetju oziroma prevzemu.

    Naročnik dodaja, da varna povezava s šifriranjem preko "SSL", ki je predvidena le za sinhroni (interaktivni) del rešitve, ni namenjena izmenjavi elektronske pošte.

    Naročnik na podlagi navedenega zaključuje, da vlagateljeva rešitev ne izpolnjuje zahteve EDP-Z-27 v povezavi z zahtevo EDP-Z-124.

    Naročnik nadaljuje, da je v EDP-Z-63 podal zahtevo, da morajo biti napake ugotovljene pri vnosih javljene takoj ob pojavu ali takoj, ko jih je možno zaznati in s sporočili, ki povedo, kateri podatki so ugotovljeni kot napačni in zakaj. Ob poskusu popravljanja je potrebno uporabnika voditi po logičnem vrstnem redu od polja od polja, ki vsebuje napako.

    Vlagatelj pa v opisu rešitve EDP-Z-63 navaja, da se v primeru napake znotraj EDP sistema uporabniku prikaže v naprej določena stran za prikaz napak. To stran v okviru tehnologije "jsp" generira vsaka izjema (značilnost tehnologije "2JEE") v delovanju posameznega procesa. Stran nosi opravičilo, hkrati pa se generira elektronsko sporočilo, ki obvesti administratorja o izjemi v sistemu.

    Naročnik na podlagi navedenega zaključuje, da je predmet zahteve možnost za ugotavljanje napak, ki jih naredi uporabnik pri vnosu podatkov v obrazec in ne napake v delovanju sistema, zaradi česar ni izpolnjena zahteva EDP-Z-63.

    Naročnik glede "prekinitve postopka" navaja, da je v zahtevi EDP-Z-123 opredeljeno, da mora biti uporabniku na razpolago možnost "prekinitve postopka", ponovitve delov prejšnjih postopkov zaradi popravkov in možnost potrditve prikazanih podatkov, s katero se potem sproži prenos vsebine obrazca v EDP sistem.

    Vlagatelj pa v opisu rešitve zahteve EDP-Z-123 navaja, da uporabnik lahko prekine postopek prenosa. Če je uporabnik prekinil postopek prenosa pred končanjem prenosa, torej preden je dobil povratno informacijo o uspešnosti prenosa, se vzpostavi stanje, ki je bilo pred poskusom prenosa.

    Na podlagi navedenega naročnik ugotavlja, da je v razpisni dokumentaciji zahteval možnost prekinitve, ponovitve in potrditve postopka vnosa podatkov, vlagatelj pa opisuje prekinitev prenosa podatkov, zaradi česar ni izpolnjena zahteva EDP-Z-123.

    Glede varnosti pri začasnem shranjevanju na lokalnem računalniku naročnik navaja, da je v EDP-Z-4 zahtevano, da mora rešitev zagotoviti vzpostavitev varnega "on-line" uporabniškega vmesnika za vse storitve, ki so predmet tega javnega naročila. V ponudbi mora biti opisano, kako bo zagotovljena varnost na strani "on-line" uporabniškega vmesnika s posebnim poudarkom na interaktivnem načinu priprave podatkov in pripravi podatkov za paketni prenos. Naročnik zahteva, da uporabniški vmesnik v vseh primerih, kjer začasno lokalno (interno) shrani delno pripravljene podatke obrazca, te podatke shrani šifrirano in podpisano s ključem uporabnika.

    Vlagatelj pa je v opisu rešitve zahteve EDP-Z-4 navedel, da predlagana rešitev zagotavlja avtentifikacijo uporabnika in vzpostavljanje varnih "SSL (https)" povezav povsod tam, kjer obravnava zaupne podatke. Pri prenosu so vsi podatki zaupne narave (poročila, vloženi obrazci, svežnji podatkov) digitalno podpisani in kriptirani po "PKI" standardih. Torej je varnost zagotovljena tako pri interaktivnem izpolnjevanju obrazcev kot tudi pri paketnem prenosu. Del sistema "FormPipe" je tudi komponenta "ActiveX", ki omogoča digitalno podpisovanje in kriptiranje obrazcev na odjemalčevem računalniku. To velja tako za spletne odjemalce kot tudi druge odjemalce, ki jih podpira sistem "FormPipe".

    Naročnik ugotavlja, da ponujena rešitev ne predvideva nadzora oziroma evidence nad lokalno shranjenimi obrazci. Ne predvideva tudi dešifriranja takega shranjenega obrazca in preverjanja njegovega digitalnega podpisa, ko se ga uporabnik odloči ponovno uporabiti. Ti funkcionalnosti pogojujeta smiselnost zahtevane funkcionalnosti po začasnem shranjevanju delno izpolnjenih obrazcev, zaradi česar zahteva EDP-Z-4 ni izpolnjena.

    Naročnik zaključuje, da vlagatelj v konceptualnem opisu (stran 8) navaja, da ponuja rešitev, ki je boljša od zahtevane. Ob tem naročnik poudarja, da morebitne dodatne funkcionalnosti in/ali dodatni programi, ki niso zahtevani v razpisni dokumentaciji in zaradi tega niso zajeti v kriterijih za ocenjevanje ponudb tudi ne morejo biti ocenjevanji po teh kriterijih.

    Po prejemu obrazloženega obvestila je vlagatelj zoper odločitev o izbiri najugodnejšega ponudnika, dne 17.02.2003, vložil zahtevek za revizijo, v katerem predlaga, da se razveljavi odločitev o izbiri najugodnejšega ponudnika in da naročnik izvede ponovno ocenjevanje ponudb z upoštevanjem njegove ponudbe kot pravilne. Podrejeno pa vlagatelj predlaga, da se postopek oddaje javnega naročila razveljavi v celoti.
    Vlagatelj tudi predlaga Državni revizijski komisiji, da v predmetni zadevi po potrebi pridobi strokovno/izvedensko mnenje.

    Vlagatelj v obrazložitvi zahtevka za revizijo navaja, da je iz naročnikovega obvestila o oddaji javnega naročila, z dne 24.01.2003, razvidno, da je naročnik njegovo ponudbo označil za nepravilno, ni pa navedel razlogov za nepravilnost, kar bi moral storiti glede na določbo 78. člena ZJN-1.

    Vlagatelj nadaljuje, da je naročnik v obvestilu o oddaji javnega naročila, z dne 24.01.2003, navedel, da je na podlagi sklepa Državne revizijske komisije, št. 018-212/02-24-1831, z dne 14.10.2002, začel s ponovnim postopkom ocenjevanja ponudb, pri čemer je ugotavljal tudi pravilnost ponudb ponudnikov â?? d.o.o. in â?? d.o.o., čeprav je bilo že prej nedvoumno ugotovljeno in znano, da sta njuni ponudbi nepravilni. Navedeni ponudbi sta bili že dokončno zavrnjeni kot nepravilni v prvem postopku pregleda in ocenjevanja ponudb, zato je naročnik nedopustno in nepotrebno le-ti ponovno ocenjeval. Vlagatelj nadaljuje, da je naročnik pravilnost njegove ponudbe priznal že z deklaratorno izjavo o spoštovanju sklepa Državne revizijske komisije, v obvestilu o oddaji naročila (tretji odstavek obvestila), z dne 24.01.2003, in s pozivom k podaljšanju veljavnosti ponudbe in predložitvijo ustrezne bančne garancije. Vlagatelj dodaja, da je naročnik v obvestilu o oddaji javnega naročila izrecno navedel, da je začel s ponovnim postopkom ocenjevanja in da je po ponovnem ocenjevanju ponudb zavrnil njegovo ponudbo kot nepravilno, kar nedvoumno pomeni, da ponovnega pregleda ponudb ni opravil. Drugače si tudi ni mogoče razlagati dejstva, da je naročnik pozval vlagatelja k predložitvi izjave o podaljšanju veljavnosti ponudbe in ustrezne bančne garancije. Naročnik bi se tudi moral zavedati, da se v nasprotnem primeru (nepravilna ponudba) vlagatelju še dodatno povečujejo stroški udeležbe pri predmetnem javnem naročilu, ne da bi sploh imel pravno in dejansko možnost, da je njegova ponudba ocenjena.

    Vlagatelj nadaljuje, da naročnik šele v obrazloženem obvestilu o oddaji javnega naročila, z dne 07.02.2003, navaja razloge za zavrnitev njegove ponudbe. V navedenem obvestilu naročnik poudarja, da je izpolnjevanje zahtev obravnaval glede na navodila iz razpisne dokumentacije (RD3 tehnične zahteve, str. 19): "â?? V nadaljevanju tega dokumenta so zahteve naročnika o rešitvi zapisane tudi v obliki oštevilčenih zahtev (EDP-Z-xy). Naročnik zahteva, da je v ponudbi za vsako od teh zahtev konceptualno zapisano, kako je zahteva izpolnjena. Ti konceptualni opisi morajo biti tako podrobni, da v njih ne bodo ostale nejasnosti. V vsakem od teh opisov se besedilo lahko sklicuje na del ponudbe, kjer je potreben konceptualen opis, sklicevanje pa naj bo natančno: npr. z navedbo poglavja in odstavka â??"
    Vlagatelj nadaljuje, da naročnik v 11. točkah, v katerih zatrjuje neizpolnjevanje zahtev razpisne dokumentacije, navaja izključno izjemno ozke tehnične zahteve (tretji del razpisne dokumentacije). Kakor je razbrati iz obrazloženega obvestila o oddaji javnega naročila, je naročnik neizpolnjevanje zahtev razpisne dokumentacije obravnaval le skozi prizmo ozkih tehničnih zahtev, ki ne vplivajo na projektno rešitev, zato vlagatelj meni, da bi naročnik le te moral ocenjevati, ne pa obravnavati s stališča pravilnosti ponudbe. Celotna razpisna dokumentacija za predmetni javni razpis je bila sestavljena iz štirih delov. Glede izpolnjevanja tehničnih zahtev je poleg tretjega dela (tehnične zahteve), izredno pomemben tudi prvi del (povabilo k oddaji ponudbe). Iz tega dela razpisne dokumentacije je jasno razbrati, da je predmet javnega naročila projektna rešitev, ki mora biti pripravljena v skladu z zahtevami v povabilu k oddaji ponudbe in v RD3 tehnične zahteve. Posebej je izraženo stališče, da mora ponudnik predstaviti lastno videnje bodočega ponujenega informacijskega sistema, ki bo v vseh svojih lastnostih in v največji meri izpolnjeval pričakovanja in možnosti naročnika. Glede konkretnih očitkov o nepravilnosti ponudbe vlagatelj opozarja na določilo sedmega odstavka točke 5.4. (ocenjevanje ponudb) povabila k oddaji ponudbe, kjer je navedeno: "Naročnik opozarja, da je za pravilno ponudbo potrebno opisati vse zahteve EDP-Z-X. Navedba vpisana v polje 5 Tabele rešitev zahtev, da bo zahteva rešena, ne bo sprejeta kot opis rešitve. V obeh dokumentih (v opisu zahtev in v Tabeli rešitev zahtev) je poleg opisa potrebno navesti oznako zahteve iz razpisne dokumentacije." Vlagatelj dodaja, da je v svoji ponudbi izpolnil vse zahteve EDP-Z-X, tako da jih je opisal in nikjer ni navajal, da bo zahteva rešena vse v skladu in smislu zahtev razpisne dokumentacije. Vlagatelj zaključuje, da niti ena od očitanih nepravilnosti ni nepravilnost glede zahtev po EDP-Z-X.
    Dodatno nesprejemljivost načina ugotavljanja nepravilnosti vlagateljeve ponudbe je mogoče najti tudi v tretjem delu razpisne dokumentacije (tehnične zahteve). Tako je naročnik v poglavju 1.2.1. (prilagodljivost in prenos tehnologije) zapisal naslednje: "Naročnik pričakuje ponudbe za rešitve, ki so zasnovane na najsodobnejši tehnologiji in IT standardih, vendar takšne, ki so sistemsko načrtovane tako, da jih bo v prihodnosti možno dograjevati in ki v največji možni meri omogočajo potrebne in zahtevane prilagoditve naročnikovemu obstoječemu izredno homogenemu tehničnemu okolju.

    Pomembno je, da EDP razvoj dopolnjuje in razširja obstoječo informacijsko in komunikacijsko tehnologijo. Zato je pričakovati, da bo EDP rešitev uporabna tudi za druge namene znotraj â??.

    Naročnik ocenjuje, da bi bilo rešitev smiselno postaviti enotno, kot spletne storitve, z uporabo protokola SOAP 1.1 (http://www.w3.org/TR/SOAP) in XML 1.0. Naročnikova zahteva je tudi, da je rešitev koncipirana tako, da bi bila enostavno razširljiva tudi na uporabo elektronske pošte. Naročnik pričakuje, da se bodo v času izvedbe, v dogovoru z naročnikom, točneje opredelili elementi protokola, ki bodo uporabljeni. Stvar dogovora z izvajalcem ostaja morebitna uporaba elementov SOAP in višjih verzij (SOAP 1.2 in višje) in razširitev protokola SOAP na uporabo digitalnega podpisovanja in šifriranja posameznih vej drevesa XML oz. SOAP sporočila (http://www.w3.org/Signature).

    Naročnik v zvezi s pričakovanji, navedenimi v prejšnjem stavku zahteva le, da je koncept rešitve tak, da je le ta razširljiva tudi v omenjenem smislu. Dodatno so zahteve naročnika o odprti arhitekturi zapisane v EDP-Z-27."

    Na podlagi navedenega je vlagatelj prepričan, da so generalne zahteve iz razpisne dokumentacije bistvo predmetnega javnega naročila in prevladujejo nad podrobnimi zahtevami konceptualnih opisov, za katere naročnik meni, da niso izpolnjeni, zaradi česar naj bi bila njegova ponudba nepravilna, čeprav le-teh naročnik nikjer ne navaja kot pogoj za pravilnost ponudbe.

    Ob navedenem vlagatelj še dodaja, da je pri presoji pravilnosti ponudbe potrebno upoštevati načelno stališče Državne revizijske komisije iz sklepa, št. 018-212/02-24-1831, z dne 14.10.2002, ki je naslednje: "â?? Državna revizijska komisija dodaja, da kot to velja za preostale pogoje, gre tudi v okviru obravnave pogojev iz 41. člena ZJN-1 izhajati iz ugotovitve, da je potrebno zaradi izključujoče narave pogojev (nepravilnost ponudbe), neizpolnjevanje pogojev tolmačiti in uporabljati restriktivno, kot izjemo, ki je neugodna za ponudnika in jo je potrebno (zato) razlagati ozko, v skladu z načelom exceptiones non sunt extendae."

    Vlagatelj na podlagi vsega navedenega zaključuje, da tudi utemeljeno dvomi, da bi katerikoli izmed ponudnikov lahko izpolnjeval zahteve iz tega javnega naročila, če bi bili upoštevani enaki pogoji in kriteriji pravilnosti ponudb, kot so bili za ugotavljanje nepravilnosti njegove ponudbe, zato podrejeno predlaga, da se postopek oddaje javnega naročila razveljavi v celoti.
    Vlagatelj je zahtevku za revizijo tudi priložil potrdilo o plačilu takse v višini 100.000,00 SIT.

    Naročnik je na podlagi 16. člena ZRPJN odločal o zahtevku za revizijo ter ga s sklepom, št. 060-1/2002-01-070, z dne 27.02.2003, kot neutemeljenega zavrnil. Naročnik v obrazložitvi sklepa navaja, da se v obvestilu o oddaji naročila razlogov za nepravilnost ponudb ne navaja. Po določbi 79. člena ZJN-1 vsebuje razloge za zavrnitev ponudb obrazloženo obvestilo, ki jih je v konkretnem primeru tudi vsebovalo.

    Naročnik dodaja, da ker ZJN-1 ne pozna posebnega sklepa o zavrnitvi ponudbe, ampak se o le-tej naročnik opredeli v poročilu in obvestilu o oddaji naročila, zato tudi ni mogel priznati pravilnosti vlagateljeve ponudbe z izjavo o spoštovanju sklepa Državne revizijske komisije ali s pozivom k podaljšanju ponudbe. Naročnik si je s pozivom k podaljšanju ponudbe le zagotovil, da bo izbrani ponudnik po končanem postopku tudi dolžan podpisati pogodbo.
    Prav tako so neutemeljene tudi vlagateljeve navedbe, da naročnik ne bi smel ponovno ugotavljati pravilnosti ponudb. Državna revizijska komisija je namreč razveljavila odločitev naročnika o oddaji naročila, zaradi česar je naročnik ob upoštevanju napotkov Državne revizijske komisije iz sklepa. št. 018-212/02-24-1831, z dne 14.10.2002, ponovno presojal pravilnost vseh ponudb.
    Naročnik nadaljuje, da je vlagatelj sam privolil v stroške povezane s podaljšanjem veljavnosti ponudb. Takšna navedba pa tudi glede na določbo petega odstavka 12. člena ZRPJN ne more biti predmet zahtevka za revizijo, saj bi vlagatelj zatrjevano kršitev moral uveljavljati najkasneje do prejema odločitve naročnika o dodelitvi naročila.
    Neutemeljene so tudi vlagateljeve trditve, da so očitane nepravilnosti ozke, da niso pomembne, da so v nasprotju z nekaterimi drugimi zahtevami in zato nejasne. Opredelitev predmeta javnega naročila in morebitnih pogojev je stvar naročnika. Pri tem mora paziti le, da ne pride do neenakopravnosti in diskriminiranja ponudnikov. Prav tako lahko le naročnik določi, kaj so bistveni elementi pogodbe in jih določi v razpisni dokumentaciji. V nadaljnjem postopku pa so zahteve razpisne dokumentacije zavezujoče tako za ponudnike kot tudi za naročnika. Ponudniki morajo v ponudbi izpolniti vse zahteve iz razpisne dokumentacije, da bi se njihova ponudba štela za pravilno. Naročnik pa je dolžan ponudbo, ki ne izpolnjuje vseh zahtev razpisne dokumentacije zavrniti kot nepravilno.
    Naročnik dodaja, da glede očitanega neizpolnjevanja zahtev EDP-Z-X, vlagatelj zgolj navaja, da meni, da niti ena izmed očitanih nepravilnosti ni nepravilnost glede zahtev po EDP-Z-X, ne navaja pa na kakšen način jih izpolnjuje.

    Vlagatelj je z dopisom, z dne 03.03.2003, skladno s prvim odstavkom 17. člena ZRPJN, naročnika obvestil, da nadaljuje postopek pred Državno revizijsko komisijo.

    Naročnik je na podlagi drugega odstavka 17. člena ZRPJN z dopisom, z dne 06.03.2003, odstopil Državni revizijski komisiji zahtevek za revizijo predmetnega javnega naročila skupaj z dokumentacijo.

    Državna revizijska komisija je z dopisom, št. 018-50/03-21-358, z dne 13.03.2003, v skladu s petim odstavkom 3. člena ZRPJN, ki določa subsidiarno uporabo določb Zakona o pravdnem postopku (Uradni list RS, št.26/99, 12/03; v nadaljevanju: ZPP), vlagatelja na podlagi 153. člena ZPP pozvala, da predloži predujem za izvedbo dokaza s strokovnjakom/izvedencem informacijske stroke, v višini 300.000,00 SIT. V skladu s prvim odstavkom 153. člena ZPP, mora namreč stranka, ki predlaga izvedbo dokaza, po nalogu sodišča založiti znesek, ki je potreben za stroške, ki bodo nastali z izvedbo dokaza.

    Vlagatelj je z dopisom, z dne 17.03.2003, Državni revizijski komisiji posredoval kopijo potrdila iz katerega je razvidno, da je v predpisanem roku in zahtevani višini vplačal predujem za izvedbo dokaza s strokovnjakom/izvedencem informacijske stroke.

    Državna revizijska komisija je z dopisom, št. 018-50/03-21-408, z dne 18.03.2003, v skladu s petim odstavkom 3. člena ZRPJN, ki določa subsidiarno uporabo določb ZPP, na podlagi 245. člena ZPP strokovnjaka/izvedenca informacijske stroke dr. Mira Kranjca, Ponova vas 5, Grosuplje, zaprosila za strokovno/izvedensko mnenje o tem, ali vlagateljeva ponudba izpolnjuje sporne tehnične zahteve razpisne dokumentacije, zaradi katerih je bila le-ta izločena kot nepravilna.

    Strokovnjak/izvedenec informacijske stroke je, dne 02.04.2003, Državni revizijski komisiji posredoval zahtevano strokovno/izvedensko mnenje.

    Državna revizijska komisija je z dopisom, št. 018-50/03-21-471, z dne 03.04.2003, vlagatelju v skladu z drugim odstavkom 7. člena ZPP posredovala pridobljeno strokovno/izvedensko mnenje glede izpolnjevanja spornih tehničnih zahtev razpisne dokumentacije v njegovi ponudbi ter ga obvestila, da bo skladno z drugim odstavkom 20. člena ZRPJN o zahtevku za revizijo odločila v roku 15 dni od prejema strokovnega/izvedenskega mnenja.

    Po pregledu celotne dokumentacije o vodenju postopka oddaje javnega naročila in proučitvi utemeljenosti navedb vlagatelja in naročnika ter strokovnega/izvedenskega mnenja, Državna revizijska komisija ugotavlja, da zahtevek za revizijo ni utemeljen iz razlogov, ki so navedeni v nadaljevanju.

    Državna revizijska komisija je v postopku oddaje javnega naročila preverila, ali je zahtevek za revizijo dopusten in ali je vlagatelj aktivno legitimiran za vložitev zahtevka. Vlagatelj ima kot ponudnik, ki je oddal ponudbo, v skladu z 9. členom ZRPJN interes za dodelitev naročila in bi mu lahko bila povzročena škoda zaradi ravnanj naročnika, ki se v zahtevku za revizijo navajajo kot kršitve naročnika v postopku oddaje javnega naročila, zato je aktivno legitimiran kot stranka v postopku in upravičen do vložitve revizijskega zahtevka.

    Državna revizijska komisija je pri presoji zahtevka za revizijo upoštevala določili 2. in 3. odstavka 19. člena ZRPJN, ki določata: "Državna revizijska komisija odloča v mejah zahtevka za revizijo. Državna revizijska komisija odloča, ob upoštevanju meja zahtevka za revizijo, tudi o kršitvah, za katere vlagatelj ni vedel ali ni mogel vedeti, pa so vplivale na odločitev naročnika o dodelitvi naročila.
    V primeru kršitev temeljnih načel javnega naročanja izvede vse dokaze, za katere meni, da bodo prispevali k razjasnitvi zadeve in k zakoniti in pravilni odločitvi."

    Glede vlagateljevih navedb, ki se nanašajo na zatrjevano kršitev 78. člena ZJN-1 pri sestavi obvestila o oddaji javnega naročila, Državna revizijska komisija najprej ugotavlja, da je naročnik v obvestilu o oddaji naročila, št. 060-18/2002-1-070, z dne 24.01.2003, navedel naslednje podatke:
    - ime in naslov naročnika,
    - predmet naročila,
    - imena ponudnikov, ki so pravočasno predložili ponudbe,
    - imena ponudnikov, ki so predložili pravilne ponudbe in imena ponudnikov, ki so predložili nepravilne ponudbe in
    - ime izbranega ponudnika.

    Državna revizijska komisija nadalje ugotavlja, da ZJN-1 v prvem odstavku 78. člena določa: "Naročnik mora sestaviti pisno poročilo o vsakem oddanem naročilu. Pisno poročilo mora vsebovati najmanj naslednje podatke:
    1. ime in naslov naročnika,
    2. predmet in vrednost naročila,
    3. imena zavrnjenih ponudnikov in razloge za njihovo zavrnitev,
    4. ime uspešnega ponudnika in razloge za izbiro njegove ponudbe, če je ponudnik navedel, da bo naročilo izvedel s pomočjo podizvajalcev, tudi vsak del izvedbe naročila, ki ga bo izvedel podizvajalec,
    5. pri postopkih izbire izvajalca s pogajanji okoliščine, ki opravičujejo uporabo postopka s pogajanji."

    V drugem odstavku 78. člena ZJN-1 pa je nadalje določeno: "Na podlagi poročila iz prvega odstavka tega člena mora naročnik nemudoma posredovati ponudnikom obvestilo o oddaji naročila". Glede na drugi odstavek 78. člena ZJN-1 posreduje naročnik ponudnikom le obvestilo o izbiri najugodnejšega ponudnika. Ob tem Državna revizijska komisija izpostavlja, da vsebine in oblike obvestila o oddaji javnega naročila ZJN-1 ne predpisuje, zaradi česar je določitev le-te torej prepuščena presoji naročnika. Zaradi navedenega ni mogoče slediti vlagatelju, da gre v obravnavanem primeru za kršitev določb ZJN-1. Ob tem pa je potrebno dodati, da je bil vlagatelj podrobno seznanjen z očitanimi nepravilnostmi njegove ponudbe z obrazloženim obvestilom o oddaji javnega naročila, ki je naročnik na podlagi 79. člena ZJN-1 vlagatelju na njegovo zahtevo posredoval dne 07.02.2003. Zaradi navedenega je potrebno ugotoviti, da je vlagateljev zahtevek za revizijo v tem delu neutemeljen.

    Glede vlagateljeve navedbe, da je naročnik priznal pravilnost njegove ponudbe s tem, ko je v obvestilu o oddaji naročila, št. 060-18/2002-1-070, z dne 24.01.2003, zapisal, da je pri ponovnem pregledu in ocenjevanju ponudb upošteval napotila Državne revizijske komisije iz njenega sklepa, št. 018-212/02-24-1831, z dne 14.10.2002, ter nadalje s tem, ko je vlagatelja pozval k podaljšanju veljavnosti ponudbe in predložitvi ustrezne bančne garancije, Državna revizijska komisija najprej ugotavlja, da je s sklepom, št. 018-212/02-24-1831, z dne 14.10.2002, odločala v mejah vloženega zahtevka za revizijo, torej o pravilnosti vlagateljeve ponudbe v delu, ki se nanaša na izpolnjevanje zahteve razpisne dokumentacije iz točk 5.2.4.2, 5.3.2 in 6.2.1.1 navodil ponudnikom (poravnanost davkov, prispevkov in drugih obveznih dajatev â??). Z navedenim sklepom je bila razveljavljena naročnikova odločitev o izbiri najugodnejšega ponudnika in naročniku je v skladu z določbo 23. člena ZRPJN bilo tudi naloženo, da ponovno opravi pregled in ocenjevanje ponudb, ob upoštevanju ugotovitev Državne revizijske komisije iz njenega sklepa. Postopek oddaje predmetnega javnega naročila je bil vrnjen v fazo pred odločitvijo naročnika o oddaji javnega naročila, torej v fazo pregleda in ocenjevanja ponudb, pri čemer pa tudi naročnikova zahteva po podaljšanju veljavnosti ponudb in predložitvi ustreznih bančnih garancij, sama po sebi, glede na določbe ZJN-1, ki opredeljujejo pravilnost ponudbe, še ne more pomeniti naročnikovega sprejetja ponudbe kot pravilne (argument 18. točke prvega odstavka 3. člena in drugega odstavka 76. člena ZJN-1). Ob tem pa ne gre pa izključiti možnosti, da bi lahko naročnik ob izvedbi pregleda in ocenjevanja ponudb, na podlagi česar je sprejel prvotno odločitev o oddaji javnega naročila (obvestilo, z dne 13.08.2002), kot nepravilno izločil katero izmed ponudb, z uporabo smiselno istega pristopa pri presoji vsebinske ne/ustreznosti v ponudbi predloženih dokumentov, kot pri izločitvi vlagateljeve ponudbe, pa zoper to ravnanje ne bi bil vložen zahtevek za revizijo. Prav tako pa ne gre izključiti tudi možnosti, da bi lahko bila vlagateljeva ponudba morebiti nepravilna, zaradi neizpolnjevanja kakšnih drugih zahtev razpisne dokumentacije, po katerih pa naročnik pri prvotnem pregledu in ocenjevanju ponudb le-te mogoče ni presojal, ker je že bila izločena kot nepravilna, zaradi neizpolnjevanja drugih zahtev razpisne dokumentacije. Zaradi navedenega je bil naročnik dolžan pri ponovnem pregledu pravilnosti ponudb ponovno presojati pravilnost vseh ponudb. S tem je bilo naročniku omogočeno, da ob ponovnem pregledu pravilnosti (vseh) ponudb popravi morebitne napake iz predhodne faze pregleda in ocenjevanja ponudb, ki pa niso bile zatrjevane v zahtevku za revizijo, z dne 30.08.2002.
    Državna revizijska komisija namreč ugotavlja, da gre v civilnem in upravnem pravu tudi po praksi Ustavnega sodišča pravilo prepovedi "reformatio in peius" pojmovati drugače kot v kazenskem pravu. V tej zvezi je potrebno presojati to pravilo skozi morebitno poslabšanje pravnega položaja, ki pa v predmetnem primeru po svoji naravi ni spremenjen.

    Glede vlagateljevih očitkov, ki pa se nanašajo na naročnikovo zahtevo po podaljšanju veljavnosti ponudb in predložitvi ustreznih bančnih garancij, kot tako (per se), pa je potrebno pritrditi naročniku, da so navedeni vlagateljevi očitki v smislu določil ZRPJN formalno prepozni in jih iz tega razloga vsebinsko ni več mogoče obravnavati. V skladu z določilom petega odstavka 12. člena ZRPJN namreč ponudnik po odločitvi o dodelitvi naročila ne more vložiti zahtevka za revizijo iz razloga, ki mu je mogel ali bi mu moral biti znan pred to odločitvijo naročnika, pa ga kljub temu ni vložil že pred odločitvijo naročnika o dodelitvi naročila. Navedeno zakonsko pravilo uveljavlja načelo hitrosti revizijskega postopka ter upravičencu do vložitve zahtevka za revizijo nalaga, da mora zoper morebitno kršitev reagirati takoj, ko se z njo seznani, kar naj omogoči sprotno odpravljanje nepravilnosti v postopku oddaje javnega naročila. Kot je razvidno iz dokumentacije o oddaji javnega naročila, je naročnik pozval vlagatelja k podaljšanju veljavnosti ponudbe in predložitvi bančne garancije za resnost ponudbe z dopisom, z dne 24.12.2002, ki ga je vlagatelj prejel dne 30.12.2002. Vlagatelj pa je svoje očitke v zvezi z navedenim ravnanjem naročnika izrazil šele po odločitvi naročnika o dodelitvi naročila (naročnik je to odločitev sprejel dne 24.01.2003). Ob opisanem dejanskem stanju je potrebno pritrditi naročniku v tem, da je bil razlog, zaradi katerega je bil vložen zahtevek za revizijo v tem delu, vlagatelju nedvomno znan že pred odločitvijo o dodelitvi naročila in ga je zato uveljavljal prepozno.

    Zaradi navedenih razlogov je Državna revizijska komisija v nadaljevanju presojala pravilnost vlagateljeve ponudbe v tistem delu, ki je predmet spora med naročnikom in vlagateljem. Pri tem Državna revizijska komisija najprej navaja, da se strinja z vlagateljem, da je potrebno zaradi izključujoče narave pogojev (nepravilnost ponudbe), neizpolnjevanje le-teh tolmačiti in uporabljati restriktivno, kot izjemo, ki je neugodna za ponudnika in jo je potrebno (zato) razlagati ozko, v skladu z načelom exceptiones non sunt extendae. Ob tem pa je potrebno dodati, da je Državna revizijska komisija s sklepom, št. 018-212/02-24-1831, z dne 14.10.2002, na katerega se sklicuje vlagatelj za razliko od spora, ki je predmet tega revizijskega postopka, presojala izpolnjevanje pogoja, ki ga niti ZJN-1 (41. člen), niti naročnikova razpisna dokumentacija podrobneje ne določata (ali gre navedbo "poravnane davke, prispevke in druge obvezne dajatve ali poslovne obveznosti" interpretirati kot dokončne ali pravnomočne ali izvršljive obveznosti). Izpolnjevanje navedenega pogoja (poravnanost davkov) je zato bilo potrebno presojati glede na namen zakonskega normiranja javnega naročanja (ratio legis).
    Državna revizijska komisija zato nadaljuje, da morajo tako naročniki kot ponudniki pri oddaji javnih naročil postopati v skladu s pravili, ki jih določa ZJN-1 in na njegovi podlagi sprejeti podzakonski predpisi ter v skladu z (avtonomnimi) pravili, ki jih za oddajo konkretnega javnega naročila postavi naročnik v razpisni dokumentaciji, če le-ta niso v nasprotju s prisilnimi predpisi. Naročnikova navodila iz razpisne dokumentacije vežejo tako ponudnike pri pripravi ponudb, kot tudi naročnika tekom celotnega postopka oddaje javnega naročila. Pri oddaji javnih naročil je namreč potrebno upoštevati, da so postopki izredno formalni in strogi, vztrajanje pri strogih pravilih postopka pa ima vsekakor določen pomen in tehtne razloge. Predvsem se želi na ta način vsem zainteresiranim ponudnikom zagotoviti v postopku enakopraven položaj in preprečiti možnost diskrecijskega odločanja naročnika in tako vnaprej preprečiti možne zlorabe.
    Naročnik na več mestih v razpisni dokumentaciji določa katere zahteve mora izpolnjevati ponudba, da se bo štela za pravilno. Naročnik je tako že v Navodilih ponudnikom, ki so sestavni del razpisne dokumentacije, v točki 3.15 "Ocenjevanje ponudb" med drugim določil, da bo ocenjeval ponudbe, ki ne bodo imele glede na ta navodila nobenih pomanjkljivosti in ki bodo izkazovale izpolnjevanje vseh zahtevanih pogojev. V točki 5.2.5.3.2 Navodil ponudnikom, ki se nanaša na splošne zahteve glede projektne rešitve pa je med drugim določeno: "Projektna rešitev mora biti narejena po zahtevah, ki so podane v razpisni dokumentaciji. Ponudnik mora pripraviti projektno rešitev v skladu z zahtevami v tem dokumentu in v dokumentu RD3 Tehnične zahteve. Projektna rešitev mora biti pripravljena skladno s ponudnikovo metodologijo za projekte razvoja in vpeljave obsežnih informacijskih sistemov; torej mora biti predstavljena metodologija, ki je osnova za sestavo dokumentov." V isti točki Navodil ponudnikom je v nadaljevanju tudi opredeljeno: "Ponudnik naj predlaga in opiše koncept in potrebne podrobnosti celotne rešitve. Zahtevajo se ponudbe, ki bodo jasno in konsistentno izkazovale globino poznavanja problematike in predlagale učinkovitejše rešitve."
    Naročnik je nadalje v točki 5.2.5.3.5 "Opis rešitve" Navodil ponudnikom določil: "Naročnik zahteva da ponudnik v naslednjih sklopih konkretno obdela vsako izmed zahtev iz dokumenta RD3 Tehnične zahteve, s tem da naredi dva dokumenta:
    â"˘ Konceptualni opis rešitve v katerem celovito prikaže rešitev in
    â"˘ Tabela rešitev zahtev, kjer za vsako zahtevo navede opis rešitve."

    Glede zahtevanega izpolnjevanja tehničnih zahtev, da bi se ponudba štela za pravilno, je naročnik v nadaljevanju v 3. delu razpisne dokumentacije - Tehnične zahteve v točki 4 "Tehnološke in funkcionalne zahteve" v podtočki 4.1 "Tehnološka platforma in arhitektura sistema" med drugim določil: "V nadaljevanju tega dokumenta so zahteve naročnika o rešitvi zapisane tudi v obliki oštevilčenih zahtev (EDP-Z-). Naročnik zahteva, da je v ponudbi za vsako od teh zahtev konceptualno opisano, kako je zahteva izpolnjena. Ti konceptualni opisi morajo biti tako podrobni, da v njih ne bodo obstajale nejasnosti. V vsakem od teh opisov se besedilo lahko sklicuje na del ponudbe, kjer je potreben konceptualni opis, sklicevanje pa naj bo natančno: npr. z navedba poglavja in odstavka."

    Iz povzetih določil razpisne dokumentacije izhaja, da je naročnik od ponudnikov zahteval, da v ponudbi ponudijo svojo projektno rešitev, ki mora izpolnjevati vse zahteve iz dokumenta RD3 Tehnične zahteve in mora biti opisana tako, da je konkretno in podrobno predstavljena vsaka izmed zahtev iz dokumenta RD3 Tehnične zahteve. Zaradi navedenega ni mogoče slediti vlagateljevi navedbi, da je naročnik pri presoji pravilnosti njegove ponudbe izhajal zgolj iz ozkih tehničnih zahtev, ki nimajo vpliva na sam koncept rešitve in s tem na pravilnost ponudbe. Ob upoštevanju do sedaj ugotovljenih dejstev, je Državna revizijska komisija v nadaljevanju presojala izpolnjevanje tehničnih zahtev razpisne dokumentacije, ki so predmet spora med naročnikom in vlagateljem.

    Za razrešitev vprašanj glede izpolnjevanja spornih tehničnih zahtev razpisne dokumentacije v vlagateljevi ponudbi je Državna revizijska komisija pridobila tudi izvedensko/strokovno mnenje. Po mnenju strokovnjaka/izvedenca informacijske stroke se je naročnik odločil pravilno, ko je vlagateljevo ponudbo označil kot nepravilno in sicer iz razlogov, ki so obrazloženi v nadaljevanju:

    "OBRAZLOŽITEV MNENJA

    Naročnik je v razpisni dokumentaciji podrobno predstavil svoje videnje izvedbe sistema za elektronsko davčno poslovanje. Za to, da bi v čim večji meri zagotovil doseganje svoje vizije tehnološke izvedbe sistema je že v razpisni dokumentaciji postavil celo vrsto zahtev (označene z oznakami EDP-Z-XYZ, kjer je XYZ zaporedna oznaka med 1 in 203), ki jih ponudniki v svojih rešitvah v večjem delu morajo upoštevati. Zahteve EDP-Z-XYZ, katerih izpolnjevanje je bilo zahtevano, so bile označene z oznako "obvezno" druge pa z oznako "željeno".
    Ponudba vlagatelja je, po mnenju naročnika, neustrezna ali nepopolna v izpolnjevanju vsaj desetih od obveznih zahtev. Neizpolnjevanje teh zahtev pa se smiselno navezuje, oziroma izhaja iz tehnoloških lastnosti ponujene rešitve. Te bodo pojasnjene v nadaljevanju.


    1. Striktna raba spletnega odjemalca

    Naročnik si je rešitev delovanja sistema elektronskega davčnega poslovanja na strani zunanjih uporabnikov sistema zamislil tako, da le-ti za uporabo storitev sistema ne potrebujejo posebnega, ločenega odjemalca in da so jim torej vse vsebine in storitve dostopne neposredno iz spletnega pregledovalnika. Tako predvsem odpade potreba po tem, da bi zunanji uporabniki morali nameščati posebno programsko opremo na svoje delovne postaje (oz. računalnik preko katerega dostopajo do sistema EDP).

    Ta zahteva in želja naročnika je dokaj smiselna saj prinaša vrsto prednosti:
    - uporabniku ni potrebno nameščati posebne programske opreme (od uporabnika zahteva le minimalna znanja za uporabo spletnega pregledovalnika),
    - s tem se zmanjša število napak, ki bi lahko izhajale iz nepravilne namestitve odjemalca, temu pa ustreza tudi manjša potreba po podpori uporabnikom s strani centra za pomoč uporabnikom, ki ga je naročnik predvidel,
    - poenostavljen je nadzor in izvedba nadgradenj odjemalca, saj se ta samodejno in brez intervencije uporabnika namesti s spletnega strežnika ob dostopu do spletnih strani sistema EDP.

    Slabosti t.im. tankih odjemalcev pa so predvsem v tem, da je delo brez povezave s spletnim strežnikom (off-line način) funkcionalno bolj omejeno.

    Naj poudarim, da je bila raba tankega odjemalca (spletnega pregledovalnika) tehnična odločitev naročnika, ki ima tehtno tehnološko podlago, da je bila ta zahteva jasno izražena in vsebovana v vrsti zahtev EDP-Z-XYZ in tudi večkrat jasno obrazložena v odgovorih na vprašanja prijaviteljev. Naročnik bi se sicer lahko odločil, da dopušča tudi drugačne rešitve (rabo debelega odjemalca nameščenega na uporabnikovem računalniku), vendar tega ni storil.

    Vlagatelj zahtevka za revizijo, je kot temelj svoje rešitve ponudil rešitev švedskega podjetja SignOn FormPipe. V svoji ponudbi je poleg Konceptualnega opisa rešitve (37. točka ponudbe) v delu 39 (Vse specifikacije) priložil še nekaj dokumentov, ki pa se nanašajo na različne verzije produkta FormPipe in sicer:
    - Proposal to Halcom for project "postavitev sistema za Elektronsko Davčno Poslovanje" by use of FormPipe 3.x and SignOn project services ver. 1.0, z dne 17.03.2002,
    - Form User's Guide, Version 2.1, z nejasnim datumom nastanka (verjetno leto 2000) in ki, kolikor je sklepati iz zaslonskih slik in besedila opisuje odjemalca FormPipe verzije 2.0 in
    - FormPipe - Technical Description Ver. 2.2, z dne 19.03.2002.

    Na svetovnem spletu pa je mogoče sedaj (konec marca 2003) najti na spletnih straneh podjetja SignOn naslednjo tehnično dokumentacijo o produktu FormPipe 3.0:

    - FormPipe 3.0 - Technical Description ver. 1.3, z dne 29.11.2002 (http://www.signon.se/signatures/docs/tech_desc.pdf),
    - Form User's Guide, ver. 3.0, pdf dokument ustvarjen 07.01.2003 (datum dokumenta ni jasno naveden) (http://www.signon.se/signatures/docs/UserGuide.book.pdf),
    - Administrator's Guide, ver. 3.0, pdf dokument ustvarjen 07.01.2003 (datum dokumenta ni jasno naveden) (http://www.signon.se/signatures/docs/AdminGuide.book.pdf),
    - Installation Guide, ver. 3.0, pdf dokument ustvarjen 07.01.2003 (datum dokumenta ni jasno naveden) (http://www.signon.se/signatures/docs/InstallationGuide.book.pdf).

    Na strani http://www.signon.se/signatures/en_formpipe30.asp proizvajalec nadalje na kratko povzema bistvene novosti v produktu FormPipe 3.0 in sicer (besedilo v angleškem jeziku je neposredno povzeto zaradi citiranja strokovnega/izvedenskega mnenja):

    From FormPipe 2.1 to FormPipe 3.0!
    FormPipe 3.0 includes extensive changes to both the client and server applications making it easier, faster and more secure to use. Here are a few examples:

    1. COM/ActiveX - Component - Easier to install
    The software can now be downloaded and installed automatically from a web site, which means complete functionality even in web forms. The new COM/ActiveX-component also makes it easier to customize forms.

    2. The FormPipe Envelope is smaller and re-designed - Faster to send
    The Envelope that holds signed documents and data is now significantly smaller. It has also been intelligently re-designed and is now based on XML.

    3. XML, SOAP, Web Services - Support for industry standards
    The FormPipe Envelope is now in XML, the protocol between the client and server is based on SOAP and the server applications expose Web Services. Support for industry standards makes it easier to integrate FormPipe 3.0 with existing applications.

    4. The Server can sign email receipts - More secure information flow
    Users can now be certain that their transactions have been completed. Security in the information flow has been increased!

    5. FormPipe 3.0 supports external authentication and authorization - Eases integration
    This new feature supports users/customers that have a central authentication system.

    6. Online applications for user accounts - Easier user administration
    FormPipe 3.0 can now automatically read certificate information needed to create user accounts via the web. This makes it possible for users to apply for accounts themselves at this same web site.

    Spremembe med produktom FormPipe verzije 2.1 in 3.0, ki jih na svojih spletnih straneh navaja proizvajalec sam, pa so bistvene za boljše izpolnjevanje zahtev naročnika.

    Iz navedenega in iz primerjave tehnične dokumentacije sedaj dostopne na svetovnem spletu in tiste, ki je bila predložena v ponudbi vlagatelja zahtevka je mogoče ugotoviti:

    - da je vlagatelj zahtevka v ponudbi priložil tehnično dokumentacijo za produkt FormPipe starejši od verzije 3.0 (delno za ver. 2.0 deloma pa za ver. 2.1 iz let 2000 in 2001);
    - da je vlagatelj zahtevka v ponudbi sicer že navajal produkt FormPipe verzije 3.0, vendar v prijavi ni priložil druge tehnične dokumentacije, ki bi podrobneje opisovala to novejšo verzijo produkta;
    - da vlagatelj zahtevka v prijavi ni jasno navajal na katero različico produkta FormPipe se posamezne navedbe nanašajo.

    Iz do sedaj navedenega je mogoče ugotoviti in sklepati:
    - da je vlagatelj zahtevka v času oddaje Ponudbe verjetno že razpolagal z delujočo rešitvijo odjemalca FormPipe verzije 3.0, ki bistveno bolje izpolnjuje zahteve naročnika, kakor prejšnje verzije odjemalca podjetja SignOn, vendar razen ponudbe podjetja SignOn ni predložil (ali vsaj jasno nakazal podatkov) o obstoju novejše rešitve;
    - da je komisija naročnika, izhajajoč iz v ponudbi predložene dokumentacije in javno dostopnih virov v času ocenjevanja lahko pridobila podrobnejše podatke le o starejših verzijah (2.1 in 2.0) tega istega odjemalca;
    - da se je komisija naročnika na podlagi njej dostopnih virov odločila pravilno, ko je ponudbo vlagatelja zavrnila kot neustrezno, saj so tehnične lastnosti odjemalcev verzije 2.X bistveno drugačne od novejših verzije 3.X (to ugotavlja tudi proizvajalec SignOn, ko navaja novosti v novem odjemalcu). Pri tem so bistvene razlike (glede rabe odjemalca) ravno v tem, da novega ni potrebno več posebej nameščati in da vsebuje tudi druge nove in izboljšane funkcionalnosti, ki jih starejše verzije niso.


    2. Opredelitev do navedb naročnika glede nepravilnosti v ponudbi vlagatelja

    V nadaljevanju se podrobneje opredeljujem do ugotovitev komisije naročnika navedenih v obrazloženem obvestilu o oddaji javnega naročila, z dne 07.02.2003, povezanih z (ne)izpolnjevanjem zahtev razpisne dokumentacije.

    Vsebinske zahteve naročnika (navedene kot vsebinski sklopi podpoglavij) lahko pregledno predstavimo s tabelo križanj med vsebinskimi sklopi in posameznimi zahtevami po EDP-Z-XYZ.

    se nanaša na se navezuje še na
    1 Potrdilo o uspešno prejetem obrazcu EDP-Z-3 EDP-Z-122
    2 Uporaba odjemalcev EDP-Z-3 EDP-Z-121, EDP-Z-132
    3 Nalaganje ločenega odjemalca EDP-Z-35
    4 Časovno žigosanje EDP-Z-101
    5 Uporaba SOAP in XML EDP-Z-27
    6 Razširljivost rabe XML na elektronsko pošto EDP-Z-27 EDP-Z-124
    7 Obravnava napak EDP-Z-63
    8 Prekinitve postopka EDP-Z-123
    9 Varnost pri začasnem shranjevanju na lokalnem računalniku EDP-Z-4

    Pomanjkljivosti št. 1., 2., 3. in 9. so medsebojno povezane in izhajajo iz predlagane rabe lokalno nameščenega odjemalca FormPipe. Ta v verziji 2.X še ni bil izveden kot COM/ActiveX komponenta (glej novosti pri prehodu iz 2.1 na verzijo 3.0 objavljenih na spletnih straneh podjetja SignOn in pripadajočo tehnično dokumentacijo).


    2.1. Zahtevi EDP-Z-3 in EDP-Z-35

    Ker vlagatelj ni eksplicitno navajal na katero verzijo odjemalca se nanaša njegov opis rešitve (iz opisa in priložene tehnične dokumentacije je sklepati na verzije 2.X) njegova ponudba prav gotovo ne izpolnjuje vsaj zahteve EDP-Z-35 (dodatna programska oprema). Ta navaja: "Vsa morebitna dodatno potrebna programska oprema, mora biti dostopna preko spletnega brskalnika in se mora uporabniku v računalnik naložiti z nalaganjem spletnih strani samodejno."
    Vlagatelj pritožbe je v svoji ponudbi (4. del ponudbene dokumentacije - projektna rešitev) v delu (Form User's Guide, Version 2.1) na nekaj straneh obširno prikazal nameščanje odjemalca FormPipe in odločitve, ki jih mora uporabnik sprejeti, da lahko program namesti. Ta del ponudbe je vsekakor v diametralnem nasprotju z zahtevo naročnika EDP-Z-35, ki se je želel, s postavitvijo te zahteve, tovrstnim posegom na strani zunanjih uporabnikov sistema izogniti.
    Druge zahtevane funkcionalnosti (1., 2. in 9.), ki jih opisani odjemalec ne izpolnjuje, komisija naročnika podrobno opisuje v obrazloženem obvestilu o oddaji javnega naročila. Pri tem se sklicuje na vrsto mest v ponudbi, kjer vlagatelj ne dovolj jasno prikazuje izpolnjevanje zahtev navedenih v razpisni dokumentaciji. Pri tem precej izstopa dejstvo, da je vlagatelj nejasno prikazal:
    - kakšne vrste obvestil se uporabniku posredujejo na zaslon po uspešni oddaji obrazcev,
    - na kakšen način lahko do teh uporabnik kasneje dostopa (torej ali obstaja arhiv teh obvestil in ali so ta obvestila skladna z zahtevami o varnem elektronskem podpisu),
    - ko govori o obvestilih je pogosto nejasno ali je mišljeno le sporočilo o oddaji (oz. sprejetju v obdelavo) s pripadajočo referenčno številko ali gre za digitalno podpisano potrdilo, ki je skladno z zahtevo EDP-Z-122.

    Glede ne/izpolnjevanja zahteve EDP-Z-3 je bilo že do sedaj v tem mnenju pojasnjeno, da je ponudnik večkrat predvidel rabo debelega odjemalca in da torej zahteva EDP-Z-3 (da mora biti vsa zahtevana funkcionalnost dostopna skozi spletni pregledovalnik na strani uporabnika) ne more biti izpolnjena.


    2.2. Zahteva EDP-Z-122

    Nejasnost izpolnjevanja zahteve EDP-Z-122 (zaključek postopka - podpis in potrditev) še dodatno zapleta shema 2.1.1 na strani 13/130 - Koncept SignOn FormPipe, ki prikazuje le pošiljanje elektronskega sporočila (elektronske pošte) uporabniku. Tudi v tekstualni razlagi načina delovanja sistema na straneh 14 in 15/130 vlagatelj ni najbolje predstavil, saj govori le o pošiljanju "ustreznega sporočila". Dvom v resnično zmožnost vlagatelja, da lahko izpolni zahtevo EDP-Z-122 dodatno krepi navedba proizvajalca programske opreme FormPipe, ki med novostmi pri prehodu iz produkta verzije 2.1 na verzijo 3.X navaja:
    4. The Server can sign email receipts - More secure information flow
    Users can now be certain that their transactions have been completed. Security in the information flow has been increased!
    Sklepati je torej, da strežniki verzije starejše od 3.0 možnosti digitalnega podpisovanja potrdil o prejemu obrazcev niso omogočali iz tega pa sledi, da zahteva EDP-Z-122 ni izpolnjena.
    Naj poudarim, da je ta zahteva s stališča davčnega postopka zelo pomembna, saj predstavlja za uporabnika digitalno podpisano potrdilo o prejemu obrazca edino pravo možnost dokazovanja, da je podatke resnično oddal in da jih je Davčna uprava Republike Slovenije resnično prejela.


    2.3. Zahteva EDP-Z-101

    Naročnik je v zahtevi EDP-Z-101 (časovni žig) zahteval, da se oddani obrazci označijo s časovnim žigom naročnika samega ali zunanje TSA agencije.
    V tabeli rešitev zahtev je vlagatelj le na kratko navedel, da notarski strežnik prejeti obrazec ožigosa s časovnim žigom in shrani v zbirko podatkov. Na več mestih v ponudbi (Form User's Guide, Version 2.1, str. 6; 4. del ponudbene dokumentacije - projektna rešitev, str. 15, 66 in 67/130) tudi nekoliko podrobneje opisuje postopke, ki jih sistem EDP izvede ob prejemu obrazca (ali svežnja obrazcev), vendar samega postopka bistveno ne razjasni. Vendar, ker na strani 67/130 vlagatelj jasno navede protokole, s pomočjo katerih se lahko Notarski strežnik FormPipe povezuje z zunanjimi PKI storitvami, lahko sklepamo, da je vlagatelj zahtevka sposoben izvesti oba načina časovnega žigosanja prispelih ovojnic, da pa tega ni podprl z obširnejšo in jasno dokumentacijo.

    2.4. Zahteva EDP-Z-27

    Naročnik je v zahtevi EDP-Z-27 (odprta arhitektura) zahteval striktno rabo odprtih standardov (to je posebej poudaril tudi v odgovoru na vprašanje vlagatelja). Zahteval je rešitev, ki bo oblikovana kot spletna storitev in bo uporabljala XML 1.0 kot obliko zapisa podatkov in SOAP 1.1 kot sredstvo za izmenjavo/dostop do le-teh. Po navodilih naročnika, pa bi morala biti rešitev razširljiva tudi na rabo elektronske pošte kot sredstva za prenos podatkov zapisanih v XML obliki. V tem primeru naročnik pričakuje od ponudnika rešitve, da bo natančno razjasnil kako namerava rešiti probleme avtorizacije in digitalnega podpisovanja oddanih podatkov.
    Vlagatelj zahtevka je v opisu načina reševanja te zahteve kot primaren način oblike zapisa podatkov navajal FormPipe ovojnico v MIME obliki zapisa, XML 1.0 obliko zapisa pa navajal v smislu "lahko pa uporabimo XML" (4. del ponudbene dokumentacije - projektna rešitev, str. 99/130).
    Dejstvo je, da proizvajalec produkta FormPipe med novostmi pri prehodu iz odjemalca verzije 2.1 na verzijo 3.X navaja:
    3. XML, SOAP, Web Services - Support for industry standards
    The FormPipe Envelope is now in XML, the protocol between the client and server is based on SOAP and the server applications expose Web Services. Support for industry standards makes it easier to integrate FormPipe 3.0 with existing applications.
    Iz navedenega nedvoumno izhaja, da je XML uporabljen kot oblika zapisa podatkov v ovojnici šele z odjemalcem verzija 3.X in da torej v ponudbi največkrat naveden odjemalec verzij 2.X zahteve EDP-Z-27 ne izpolnjuje. Naročnik je s tem da je zahteval, da sistem EDP del svojih funkcionalnosti kaže navzven v obliki spletnih storitev (web services) izkazal sodobnost, odprtost in zavezanost k rabi odprtih standardov, kar je bilo v času priprave specifikacij naročnika za javni razpis vsekakor zelo odprto in tehnično modro dejanje.

    2.5. Zahteva EDP-Z-63

    Naročnik je v zahtevi EDP-Z-63 (javljanje napak) zahteval, da predlagana rešitev čim prej zazna napake pri vnosih v polja obrazcev in da s sporočili pomaga uporabniku pri razumevanju in odpravi napake.
    Vlagatelj zahtevka je pri tem odgovoru očitno napačno razumel zahtevo naročnika in je v opisu rešitve navajal možnosti sistema za odpravo napak v delovanju sistema. Opis rešitve zahteve EDP-Z-63 nima neposredne povezave s to zahtevo.
    Vendar pa je vlagatelj v 4. del ponudbene dokumentacije - projektna rešitev, vsaj na strani 49/130 navedel predvidevanje o napakah tako na strani uporabnika (napačni vnosi) kot na strani strežnika (napake v delovanju EDP), čeprav je v Opisu rešitev navedel le slednje. Vlagatelj na tem mestu na kratko zagotavlja, da "v primeru napačne uporabe storitev portala EDP, sama storitev zagotavlja ustrezna sporočila o napačnih korakih uporabnika, ki preprečijo nadaljnjo napačno uporabo storitve. V primeru, da storitev zahteva vnos podatkov, sistem pri potrditvi storitve preveri vnesene podatke in postavi kurzor na polje, ki je nepravilno vneseno, na vrh obrazca se izpiše tudi komentar o napačno vnesenih podatkih". Iz navedenega je mogoče ugotoviti, da je vlagatelj predvidel vsaj osnovno ugotavljanje napak pri vnosih na strani uporabnika in torej zahtevo EDP-Z-63 izpolnjuje.

    2.6. Zahteva EDP-Z-123

    Zahteva EDP-Z-123 (prekinitev postopka) zahteva od ponudnikov jasno opredelitev kako bo uporabniku omogočeno, da prekine postopek, ponovi dele poprej že izvedenih korakov in mu ponudi možnost pregleda pred odobritvijo vnosa podatkov v sistem EDP. Ta zahteva je posebej smiselna in potrebna zaradi zahtevane rešitve v obliki spletnega odjemalca, kjer lahko pogosto pride do napak pri povezavah (nenačrtovanih prekinitev postopka) in kjer uporabniki nimajo možnosti preklapljanja med posameznimi pogledi postopka, ampak se morajo vračati na prejšnje zaslone z uporabo gumba nazaj v spletnem pregledovalniku. Vlagatelj je v opisu rešitve navedel le postopek ob prekinitvi postopka na željo uporabnika, ni pa navajal postopkov za pregled prejšnjih akcij in možnosti za predogled pred vnosom v sistem EDP. V opisu rešitve je vlagatelj rešitev zahteve EDP-Z-123 opisal le delno. Res pa je, da je zaradi narave lokalno nameščenega debelega odjemalca potreba po ponavljanju in predogledu podatkov bistveno manj pomembna, saj uporabnik na zaslonu že zaradi narave tega odjemalca vidi vse potrebne podatke, prav tako pa se mu ni potrebno vračati na prejšnje zaslone, manjša pa je tudi občutljivost na izpade internetnih povezav.

    2.7. Zahteva EDP-Z-4

    Z zahtevo EDP-Z-4 (vmesniki na strani odjemalca - varnost) naročnik zahteva varno on-line povezavo za vse storitve. Pri lokalnem shranjevanju obrazcev pa tudi, da morajo biti vsi podatki na uporabnikovem računalniku podpisani in šifrirani. To zahtevo vlagatelj v opisu rešitve izpolnjuje, vendar mu naročnik v obrazloženem obvestilu o oddaji javnega naročila, z dne 07.02.2003, očita nadaljnje pomanjkljivosti, ki pa niso bile navedene v EDP-Z-4 (nadzor nad lokalno shranjenimi obrazci, dešifriranje lokalno shranjenih obrazcev in preverjanje digitalnega podpisa le-teh). Smiselnost teh zahtev je sicer očitna, vendar se pri tej točki ne morem strinjati z ugotovitvijo naročnika, saj ta funkcionalnost ni bila navedena v zahtevi EDP-Z-4 in je zato vlagatelj zahtevka tudi ni mogel obrazložiti.

    2.8. Zahteva EDP-Z-121

    Zahteva EDP-Z-121 (lokalno hranjenje in tiskanje obrazcev) je v tem mnenju od obravnavanih zahtev primer, kjer je vlagatelj zelo jasno nakazal kako si predstavlja rešitev zadanega tehničnega problema tiskanja in shranjevanja pripravljenih obrazcev na uporabnikovem računalniku. Jasno je navedel, da ima FormPipe odjemalec izdelano funkcionalnost, ki je uporabniku dostopna kadarkoli, in ki omogoča uporabniku lokalno hranjenje in tiskanje obrazcev. Na straneh 95 in 96/130 večkrat ponovi sintagmo "FormPipe odjemalec" navedeno v Opisu rešitve zahteve EDP-Z-121 brez da bi jo podrobno pojasnil.
    Ker v tem kontekstu uporablja tudi besedno zvezo "ločen odjemalec", ki da je najbolj smiseln za pripravo svežnjev, je sklepati, da gre za debelega odjemalca, kar pa postavlja reševanje zahteve EDP-Z-121 v nasprotju z zahtevo EDP-Z-3.

    2.9. Zahteva EDP-Z-132

    Za izpolnjevanje zahteve EDP-Z-132 (interaktivna priprava svežnjev) vlagatelj kot najbolj primerno ponuja možnost rabe debelega (ločenega) odjemalca FormPipe, kar pa je v nasprotju z zahtevami po dosegljivosti vseh funkcionalnosti sistema EDP skozi spletni pregledovalnik (EDP-Z-3) oz. zahtevo da se na uporabnikov računalnik ne namešča nobene dodatne programske opreme (EDP-Z-35).

    3. Sklepne misli o ponudbi vlagatelja

    Glede na to, da je naročnik v razpisni dokumentaciji in odgovorih na vprašanja ponudnikov zelo jasno navedel svoja pričakovanja in videnje tehnične rešitve izvedbe sistema EDP, je pravzaprav presenetljivo, da se je vlagatelj v tem pogledu tako nekonsistentno in pogosto pomanjkljivo izražal predvsem pri razjasnitvah rabe posameznih odjemalcev. Tudi odsotnost podrobnega dokumentiranja sistema FormPipe verzije 3.0 in dejstvo, da je vlagatelj v ponudbi priložil dokumentacijo za starejšo verzijo odjemalca, je prav gotovo v nasprotju z eksplicitno zahtevo naročnika po izpolnjevanju vseh zahtev EDP-Z-XYZ in podrobnem opisovanju konceptov delovanja predlaganega sistema.
    Po mojem mnenju očitki vlagatelja, da "gre izključno za izjemno ozko očitanje nepravilnosti ponudbe glede tehničnih zahtev" ne zdržijo širše strokovne utemeljitve, ki je vlagatelj hkrati tudi sploh ne podaja.
    Mnenje vlagatelja, da ne/izpolnjevanje vsebinskih zahtev ne vpliva na projektno rešitev prav tako ni utemeljeno, saj gre posebej pri izpolnjevanju naročnikovih zahtev glede vrste odjemalcev in zmožnostih za oddajo digitalno podpisanih potrdil o prejemu za bistvene vsebinsko/tehnološke pomanjkljivosti vlagateljeve, sicer zelo strokovne ponudbe."

    Državna revizijska komisija je glede na izvedene dokaze v celoti sledila strokovnemu/izvedenskemu mnenju v katerem strokovnjak/izvedenec informacijske stroke pritrjuje naročniku, da je ravnal pravilno, ko je vlagateljevo ponudbo označil za nepravilno zaradi neizpolnjevanja vseh zahtev iz razpisne dokumentacije. Iz strokovnega/izvedenskega mnenja namreč izhaja, da vlagateljeva ponudba na več mestih ne izpolnjuje tehničnih zahtev določenih v razpisni dokumentaciji (EDP-Z-XYZ iz dokumenta RD3 - Tehnične zahteve).

    Ob zgoraj opisanem dejanskem stanju je torej potrebno pritrditi naročniku v tem, da vlagateljeva ponudba ne izpolnjuje vseh zahtev iz razpisne dokumentacije. ZJN-1 izrecno določa, da je pravilna tista ponudba, ki je pravočasna in za katero se po odpiranju ponudb, na podlagi pregleda in ocenjevanja ugotovi, da v celoti izpolnjuje vse zahteve iz razpisne dokumentacije (18. točka prvega odstavka 3. člena ZJN-1). Vlagateljeva ponudba ne izpolnjuje v celoti vseh zahtev iz razpisne dokumentacije, zato jo je bil naročnik dolžan zavrniti že na podlagi določil zakona. ZJN-1 v drugem odstavku 76. člena namreč določa, da mora naročnik po opravljenem pregledu in ocenjevanju ponudb vse nepravilne ponudbe zavrniti. Naročnik pa je (kot že navedeno) v obravnavanem primeru tudi v razpisni dokumentaciji na več mestih opozoril ponudnike, da bo kot nepravilne zavrnil vse ponudbe, pri katerih bo na podlagi pregleda in ocenjevanja ugotovil, da ne izpolnjujejo vseh zahtev iz razpisne dokumentacije, pri čemer je v razpisni dokumentaciji celo opisal pomanjkljivosti, zaradi katerih bodo ponudbe izločene kot nepravilne.
    Državna revizijska komisija zato na podlagi vsega navedenega ugotavlja, da je naročnik s tem, ko je vlagateljevo ponudbo v fazi pregleda in ocenjevanja ponudb zavrnil kot nepravilno, ravnal v skladu s 76. členom ZJN-1.

    Glede izraženega dvoma s strani vlagatelja, da če bi bili upoštevani enaki pogoji za presojo pravilnosti ponudb, kot so bili za njegovo ponudbo, potem nobena izmed ponudb ne bi bila pravilna, pa je potrebno ugotoviti, da vlagatelj za to svojo trditev v revizijskem postopku ni podal nobenih dokazov, zato je Državna revizijska komisija na podlagi povezave trditvenega in dokaznega bremena vlagateljev zahtevek tudi v tem delu zavrnila kot neutemeljen. Glede na načelo dispozitivnosti je Državna revizijska komisija pri odločanju vezana na vsebino zahtevka za revizijo. Glede na to ni mogoče na podlagi pravil o trditvenem in dokaznem bremenu (ki izhajajo iz subsidiarne uporabe določb ZPP, 7., 212. člen in nasl., v zvezi s petim odstavkom 3. člena ZRPJN), ki so na strani vlagatelja, zaključiti, da je naročnik glede zatrjevane kršitve ravnal v nasprotju z določbami ZJN-1.

    Državna revizijska komisija je pri presoji utemeljenosti zahtevka za revizijo ugotovila, da naročnik v postopku oddaje javnega naročila ni kršil določil ZJN-1, zato je skladno z drugo alineo prvega odstavka 23. člena ZRPJN odločila, kot izhaja iz izreka tega sklepa.

    S tem je utemeljena odločitev Državne revizijske komisije iz točke 1. izreka tega sklepa.

    Vlagatelj je v skladu s prvim odstavkom 153. člena ZPP (v skladu s petim odstavkom 3. člena ZRPJN, ki določa subsidiarno uporabo določb ZPP predložil predujem za izvedbo dokaza s strokovnjakom/izvedencem informacijske stroke, v višini 300.000,00 SIT. Glede na predujem stroškov izvedenstva v višini 298.000,00 SIT se del neporabljenega predujma v višini 2.000,00 SIT vrne vlagatelju na transakcijski račun â??d.o.o., št. â??. Navedena odločitev Državne revizijske komisije izhaja iz določb 22. člena ZRPJN.

    S tem je utemeljena odločitev Državne revizijske komisije iz točke 2. izreka tega sklepa.

    POUK O PRAVNEM SREDSTVU: Po končanem postopku pred Državno revizijsko komisijo je sodno varstvo zagotovljeno v postopku povračila škode pred sodiščem splošne pristojnosti (člen 23/5 ZRPJN).

    V Ljubljani, dne

    Natisni stran