Odpov di na dotazy uchaze e k ve ejné zakázce . 29/2014-53-28 SSZ – Datový katalog“
1. Up es ující dotaz k odpov di Zadavatele k d íve položenému dotazu: V rámci kap. 2.2.8 Požadované sou innosti Zadávací dokumentace je uvedeno: „B hem dodávky aplika ního programového vybavení musí Zhotovitel na m sí ní bázi reportovat využití interních zdroj Objednatele (a vypo ítávat již použité a ješt dostupné interní kapacity Objednatele pro dodávku aplika ního programového vybavení).“ edchozí dotaz: Prosíme o up esn ní p edstavy Zadavatele, zda budou tyto reporty podléhat schválení ze strany zástupc SSZ a jak budou p ípadn ešeny rozpory v po tech „spot ebovaných“ D? Jaký bude další postup v okamžiku, kdy bude po et p edjednaných interních kapacit SSZ vy erpán? Odpov SSZ: Na základ uzavíraných díl ích smluv je pevn definováno množství kapacit D). Po et interních kapacit Zhotovitele je pevn dán Díl í smlouvou. Up es ující dotaz: Odpov SSZ sm uje k definici (evidenci) kapacit Zhotovitele, zde je nám to jasné. Dle výše citovaného požadavku v Zadávací dokumentu to však vnímáme jako evidenci poskytnutých kapacit v rámci sou innosti ze strany SSZ – takže náš dotaz se týká ešení p ípadných rozpor v evidenci t chto lov kodn – nap . zhotovitel v reportu uvede, že za daný m síc bylo dle jeho názoru poskytnuto 5 D sou innosti ze strany pracovník SSZ, garant projektu ze strany SSZ bude tento po et rozporovat s tím, že dle evidence SSZ byla poskytnuta sou innost ve v tším rozsahu. Jak bude tento rozpor ešen? Jak se bude postupovat v p ípad , že po et p edjednaných D na poskytnutou sou innost ze strany SSZ bude vy erpán? Odpov : V p ípad , že dojde k rozporu po tu D – interních zdroj objednatele z pohledu Zhotovitele a Objednatele, bude tento rozpor ešen prost ednictvím jednání zú astn ných stran. Zhotovitel musí respektovat interní kapacity Objednatele, Objednatelem schválené, vycházející z definovaných požadavk na sou innost Objednatele. 2. Up es ující dotaz k odpov di Zadavatele k d íve položenému dotazu: V rámci kap. 3.1 Požadavky na aplika ní podporu Zadávací dokumentace je uvedeno: „Zhotovitel zodpovídá za aktualizaci automatizovaných test “ edchozí dotaz : Požaduje SSZ v rámci VZ dodání nástroje, v n mž by si mohla provád t v p ípad pot eby nezávisle tyto automatizované testy? Pokud ano, je ze strany SSZ n jaký nástroj preferován? Odpov SSZ: SSZ požaduje dodání nástroje, ale konkrétní nástroj není preferován. Up es ující dotaz: Je ze strany SSZ požadováno dodání licence tohoto nástroje (tzn. SSZ se stane vlastníkem tohoto nástroje) nebo je p ípustná varianta ešení, kdy Zhotovitel zajistí SSZ p ístup do svého prost edí, v n mž bude zajiš ovat provoz a údržbu nástroje pro automatizované testování a SSZ si bude moci tímto zp sobem spoušt t p íslušné testy vzdálen ? Odpov : Požadavkem Objednatele je dodání nástroje pro automatizované testování tak, aby SSZ byla jeho vlastníkem a mohla jej provozovat bez omezení v prost edí SSZ.
3. dotaz: Je požadován export dat z Datového katalogu ve strukturované form definované vyhláškou . 469/2006 Sb.? Odpov : VYHLÁŠKA .469/2006 Sb. o form a technických náležitostech p edávání údaj do informa ního systému o datových prvcích a o postupech Ministerstva informatiky a jiných orgán ve ejné správy p i vedení, zápisu a vyhlašování datových prvk v informa ním systému o datových prvcích (vyhláška o informa ním systému o datových prvcích) ur uje formu podn tu na zápis nebo zm nu datového prvku a údaj o íselnících p i p edávání do informa ního systému o datových prvcích a postupy orgán ve ejné správy p i zápisu datových prvk do informa ního systému o datových prvcích. Neur uje strukturu datových katalog vedených orgány ve ejné správy. Zadavatel proto požaduje možnost exportovat data na základ uživatelem zadaného rozsahu datových prvk a jejich atribut . 4. dotaz: Dle bodu 6.2. Zadávací dokumentace (ZD) má být sou ástí závazného azení dokument nabídky i Krycí list nabídky. Vzor Krycího listu však není sou ástí ZD. Má uchaze použít n jaký vlastní vzor Krycího listu nebo bude vydán dodatek ZD se závazným vzorem Krycího listu? Odpov : Závazný vzor krycího listu zadavatelem nestanoví. Uchaze tedy zpracuje krycí list sám s tím, že krycí list musí obsahovat minimáln údaje uvedené v l. 6.1.3 zadávací dokumentace. 5. dotaz: V rámci P ílohy . 1 k Rámcové smlouv , kap. 2.2.4 Vývoj, implementace a testování požaduje Zadavatel v rámci testovací fáze zajistit mimo jiné Technické testy (penetra ní/výkonnostní). Dotaz: Prosíme o up esn ní p edstavy Zadavatele o zp sobu provedení pr kazných penetra ních test u aplikace, která je provozována pouze uvnit IIS SSZ. Odpov : Hlavním cílem penetra ních test je vyhodnocení front-endové aplikace z pohledu spolehlivosti, zajišt ní integrity, jednozna né autentizace a autorizace prost ednictvím systému AAA Portál a rnosti dat. Penetra ní testy aplikace p edstavují nástroj na ov ení míry odolnosti v i napadení ze strany uživatel (z lokální sít SSZ). Penetra ní testy budou vycházet z relevantních ástí uznávaných metodik (nap . OWASP, OSSTMM apod.) a z relevantních ástí uznávaných norem nap . Common Criteria ( SN ISO/IEC 15408-1 až 3). Výstupem z penetra ních test bude protokol s vyhodnocením míry rizika u zjišt ných zranitelností, nejlépe za použití koeficientu DREAD (DAMAGE + REPRODUCABILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY), kdy koeficient je vy íslen jako pr r z p ti kritérií hodnocených na stupnici od 0 do 10, vyšší hodnocení znamená vyšší riziko. 6. dotaz: Disponuje zadavatel pro pot eby školení vhodnou školící místností, kterou bude možno pro školení uživatel využít? Pokud ano jaká je kapacita využitelné školící místnosti?
Odpov : SSZ disponuje školícími místnostmi, kapacita je až 120 míst. 7. dotaz: Je možné pro vývoj aplikace použít na aplika ních serverech verzi .Net Framewoku 4.5.2? Odpov : Pro vývoj je nutno dodržet platné standardy SSZ. 8. dotaz: Datový katalog – P íloha .1 k Rámcové smlouv , Specifikace p edm tu pln ní a technické požadavky, kap. 2.2.6 Školení „Zhotovitel musí v rámci školení pro nov zavád nou aplikaci zabezpe it vyškolení všech pracovník , kte í budou pracovat s nov dodávanou aplikací.“ Dotaz: Na základ p edchozího dodate ného dotazu Objednatel up esnil, že p edpokládá 300 uživatel , kte í budou pracovat s nov dodávanou aplikací. Prosíme o up esn ní, jakou formu školení Zadavatel o ekává (prezen ní, u pracovních stanic), zda p edpokládá školení v prostorách SSZ (pokud ano, prosíme o sd lení kapacitních možností daných prostor pro odhad po tu pot ebných školení), pokud SSZ o ekává zajišt ní prostor ze strany Zhotovitele, prosíme o up esn ní, zda je požadováno i zajišt ní ob erstvení pro ú astníky školení. Odpov : Navržení formy školení je v režii Zhotovitele. Je možné využít i prostory SSZ, které mají kapacity až 120 míst. 9. dotaz: Datový katalog – P íloha .1 k Rámcové smlouv , Specifikace p edm tu pln ní a technické požadavky, kap. 2.2.5 Migrace dat, kap. 2.2.8 Požadované sou innosti Dotaz: Jelikož data evidovaná prost ednictvím stávajícího nástroje nepat í do kategorie osobních ani citlivých dat, prosíme o up esn ní, s ohledem na požadovaný Podrobný návrh migra ní strategie a definování požadovaných sou inností, jestli SSZ p edpokládá, že všechny kroky spojené s migrací/konsolidací dat prob hnou v prost edí SSZ nebo jestli je možné navrhnout i postup vedoucí k pot eb nižší pot ebné sou innosti ze strany SSZ, kdy bude proveden export dat ze stávajícího nástroje, konsolidaci a išt ní dat provede Dodavatel ve svém prost edí a p ipraví je tak až pro finální migraci do cílové aplikace, která pak op t prob hne v prost edí SSZ. Celý postup mimo prost edí SSZ by byl ze strany Zhotovitele zdokumentován a p íslušn odreportován. Odpov : Ano, ur ité kroky je možné provést v prost edí dodavatele. 10. dotaz: Datový katalog – Funk ní specifikace, kap. 3.2 „Z d vodu automatizování inností a vytvo ení reálného obrazu stavu položek v systémech SSZ v Datovém katalogu bude vytvo en pravidelný kontrolní mechanismus pro sledování zm n ve strukturách databází, které probíhají v souvisejících systémech SSZ (postupn u t ch systém , u kterých jsou evidovány položky v Datovém katalogu).“ Dotaz: Prosíme o potvrzení, zda v rámci dodání nového aplika ního vybavení Datový katalog edpokládá SSZ vytvo ení pravidelného kontrolního mechanismu pro sledování zm n ve strukturách databází u systém , které jsou již nyní v Datovém katalogu evidovány (KE, VZT, Info DB) a pro další
systémy pak bude ešeno následn po jejich zmapování a zavedení do Datového katalogu v rámci následného rozvoje systému? Odpov : Požadujeme navržení obecného kontrolního mechanismu, který bude moci SSZ po zmapování dalších systém intern používat. Kontrolní mechanismus na KE, VZT a InfoDB vytvo í dodavatel již v rámci projektu. 11. dotaz: V zadávací dokumentaci v dokumentu „29 ZD.docx“ je v kapitole 9.4.5 uvedeno: „Získané body u p íslušného subkritéria budou porovnány s bodovým hodnocením ostatních uchaze jejichž nabídka bude hodnocena, a to podle vzorce:
,
V p edchozí kapitole 9.4.4 je uvedeno, jak bude komise p azovat body jednotlivým nabídkám. Hodnocení je obodováno adou 0, 1, 2, 3, 5. Teoreticky se tedy m že stát, že p i vyhodnocení vzorcem m že dojít k d lení nulou, jestliže žádná nabídka nezíská u n kterého subkritéria žádný bod. Opravdu zadavatel chce použít íselnou adu hodnocení 0, 1, 2, 3, 5 a zmín ný vzorec (bez n jaké podmínky zabra ující d lení nulou)? Odpov : Zadavatel up es uje, že v p ípad , kdy všechny nabídky v rámci konkrétního subkritéria získají 0 bod , pak bude všem nabídkám v p íslušném subkritériu p id leno shodn 0 bod . 12. dotaz: V dokumentu „Ramcova_smlouva_Datovy_katalog.docx“ je v odstavci 10.6 napsáno: „Sou ástí pln ní Zhotovitele dle Díl ích smluv/Díl ích objednávek je p edání školící uživatelské, instala ní, administrátorské a vývojové dokumentace (v etn p edání zdrojových kód ) k výsledk m edm tu pln ní Objednateli.“ Nemá být správn "…školící, uživatelské,…"? Je poptávaná školící uživatelská dokumentace (jedna zahrnující oba ú ely), nebo mají být výrazy „školící“ a „uživatelská“ odd leny árkou a dokumentace pro školení m že být odlišná od uživatelské p íru ky? Odpov : Ano, jedná se skute o školící a uživatelkou p íru ku.
Úvod k dotaz m . 13 až . 16 V dokumentu „Datovy_katalog_funkcni_specifikace.doc“ je v kapitole 3.1 na stran 7 uvedeno: „Atribut TypVazbyNaEtalon vyjad uje, zda reálná datová položka subsystém IIS SSZ odpovídá položce subsystému Etalon. Pro vyjád ení jejich shody je definováno p t r zných druh vazeb: • Ideální – obsah i definice položky se pln shodují. • Hybridní – obsah položky se neshoduje, více položek se obsahov rovná jedné položce. • Systémová – systémové položky, kde se obsahy ani definice neshodují. • Specifická – obsah se shoduje, ale definice položky je výrazn odlišná. • Fiktivní – obsah nebo definice položky se tém shodují s rozdílem.“
Odpov : Sou asný datový katalog umož uje uživateli vybrat konkrétní typ vazby na etalon z d vodu možnosti hodnocení významové stránky datové položky. Vazby slouží pro uživatele jako indikace k další analýze, zda není vhodné u init zm ny. Podotýkáme, že z popisu vyplývá že se jedná o sledovanou vlastnost údaje, kterou uživatel na základ svého rozhodnutí podle stanovené metodiky zadává ru výb rem z íselníku. 13. dotaz: Vazba „Hybridní – obsah položky se neshoduje, více položek se obsahov rovná jedné položce.“ První ást v ty je jasná, obsah položky se neshoduje s etalonem. Druhá ást v ty není jasná – „více položek se obsahov rovná jedné položce“. Mohl by zadavatel up esnit, jaké položky jsou ozna eny jako hybridní? Odpov : Jedná se o položky, které po významové stránce obsahují ást z položky, se kterou jsou provázány. Nap íklad se m že jednat o reálnou položku, která obsahuje íslo domu (tedy íslo orienta ní a íslo popisné) v jednom údaji. Opa je možné, že etalonová položka významov obsahuje více položek ze systém . 14. dotaz: Vazba „Systémová - systémové položky, kde se obsahy ani definice neshodují.“ Jde o systémové položky tabulek? Je v po ádku, že se neshodují ani obsah ani definice? Mají být evidovány datovým katalogem? Odpov : Nejedná se o systémové položky tabulek. Vazba se využívá pro prvky, které využívá pouze n který ze subsystém (uživatel s nimi v t chto subsystémech m že pracovat), a p esto není žádoucí, aby tvo ily novou položku Etalonu. Typickým p íkladem jsou ID záznam , podle kterých se vyhledává. 15. dotaz: Vazba „Specifická – obsah se shoduje, ale definice položky je výrazn odlišná.“ Myslí se tím, že business význam položky se shoduje, ale položka se od etalonu liší (typem, délkou atd.)? Odpov : Ano. Definice se liší v p evážné ásti atribut 16. dotaz: Vazba „Fiktivní - obsah nebo definice položky se tém shodují s rozdílem.“ Obsah nebo definice položky se tém shodují s rozdílem - rozdílem eho, jakým rozdílem? A pro "tém "? Mohl by zadavatel up esnit, jaké položky jsou ozna eny jako fiktivní? Odpov : Položky se od sebe liší jedním nebo dv ma vybranými atributy. 17. dotaz: V dokumentu „Datovy_katalog_funkcni_specifikace.doc“ je v kapitole 3.1 na stran 6 uvedeno: „P i p echodu ze stavu Produk ní do stavu Ukon ená se m ní verze zp t na stejnou verzi, ze které byla položka p epnuta do stavu Produk ní.“ Pro se vrací verze položky p i p echodu ze stavu "Produk ní" do "Ukon ená"? Má uchaze i kv li této „vlastnosti“ navrhnout jiný zp sob verzování položek – viz „Je nutné vyhodnotit a p ípadn navrhnout korekce sou asného verzování datových položek, které se odvíjí od jejich stav .“?
Odpov : Ano, p edpokládáme vyhodnocení a p ípadné navržení korekce sou asného verzování datových položek. Sou asné dvouúrov ové verzování takto umož ovalo na první pohled pomocí verze odlišit položky v produkci, které jako jediné kon ily 0.
18. dotaz: že zadavatel potvrdit záv r, vyplývající z popisu v kapitole 3.1 dokumentu „Datovy_katalog_funkcni_specifikace.doc“, že položky je možno m nit (editovat) pouze ve stavu Koncept, pokud je pot ebná zm na položky v jiném stavu, je nutné založit nový koncept se stejnými atributy IDPolozky, Subsystem a DruhPolozky, ale s další verzí, v n mž se zm ny provedou a projdou schvalováním? Odpov : Ano 19. dotaz: V dokumentu „Datovy_katalog_funkcni_specifikace.doc“ je v kapitole 3.7.2 napsáno: "Kontrola vypln ní všech povinných atribut a zárove kontrola vypln ní nepovinných atribut , pokud byly uživatelem vybrány k jednotlivým položkám" Jsou atributy povinné, které musí být vypln ny, a atributy nepovinné, které být vypln ny mohou, ale nemusí. Nechápeme, co se myslí kontrolou „vypln ní nepovinných atribut , pokud byly uživatelem vybrány k jednotlivým položkám“. Myslí se tím, že když uživatel vyplní nepovinný atribut, zkontroluje se jeho typ a další vlastnosti (aby vkládané datum bylo opravdu datum aj.)? Pokud to není takto myšleno, prosíme o up esn ní, co bylo touto v tou mín no. Odpov : Ano, p íslušné ustanovení zadávací dokumentace je mín no tak, jak tazatel uvedl v p edposlední v svého dotazu. 20. dotaz: V dokumentu „Datovy_katalog_funkcni_specifikace.doc“ je v kapitole 3.8 napsáno: „Po et veškerých zm n položek v Datovém katalogu v etn procentuálního vyjád ení a možnosti omezení metriky na subsystém v rozd lení na: • Po et nov zavedených položek • Po et zm ných položek s vytvo ením nové verze konceptu • Po et zrušených položek ze stavu Koncept“ Položky ze stavu Koncept se mažou, nadále v databázi neexistují (alespo podle funk ní specifikace). esto je po et zrušených položek ze stavu koncept požadován v metrice. Mají se tyto údaje získávat z logu? Odpov : Ano, informace lze získávat z logu.
21. dotaz: V dokumentu „Priloha c 1 k RS_Specifikace_predmetu_plneni_technicke_pozadavky.docx“ je kapitola 2.2.1 Popis návrhu ešení. Ve všech ostatních kapitolách, které budou hodnoceny (2.2.2, 2.2.3 až 2.2.8 a 3.1.3 a 3.2.2), je uveden ráme ek s popisem, co Zhotovitel v rámci dané kapitoly popíše i s ur ením, kde tak má u init „(doplní Zhotovitel)“. V kapitola 2.2.1 tento ráme ek a toto vymezení CHYBÍ. Kam má zhotovitel zapsat popis návrhu ešení, když byl odpov dích na dotazy uchaze e v souboru „259312121_0_29 Odpov di na dotazy 8.pdf“ v odpov di na dotaz íslo 2 instruován takto: „Zhotovitel dopl uje v míst , kde je k tomu vyzván nebo tam, kde je to graficky znázorn no. Formát dopln ní je v plné diskreci zhotovitele.“ Sporujeme, že v kapitole 2.2.1 takové místo není ani graficky znázorn no, ani v ní není výzva na dopln ní. P itom je kapitola 2.2.1 jedna z hodnocených kapitol pro posouzení úrovn a kvality nabízeného pln ní dle požadavk zadavatele a bez této kapitoly nebude nabídka úplná. Doplní / opraví zadavatel kapitolu 2.2.1 v p íloze . 1, aby bylo možno splnit jeho požadavky tak, jak požaduje? Odpov : K dotazu uchaze e zadavatel uvádí, že návrh ešení dle kapitoly 2.2.1. P ílohy . 1 zadávací dokumentace umístí za text v kapitole 2.2.1 P ílohy . 1 zadávací dokumentace (resp. p ílohy . 1 návrhu Rámcové smlouvy). 22. dotaz: Uchaze i z poskytnuté Zadávací dokumentaci není z ejmý rozdíl mezi Obecným datovým typem, Jednoduchou položkou, Složenou položkou a íselníkem. Žádáme tedy o vysv tlení rozdíl ideáln na konkrétním p ípad . Odpov : Popis je uveden ve viz Funk ní specifikaci. Pro vysv tlení uvádíme i p íklady : Obecný datový typ – nenese žádný v cný význam, ale nese pouze základní informace o vlastnostech (typ, délka, kontrolní test, kontrola na íselník, povolené znaky, zp sob zobrazení …(nap . dt_TextCZ) Jednoduchá položka – odpovídá datovému prvku daného subsystému, jedná se o konkrétní datový prvek jehož vlastnosti jsou odvozeny od p azeného ODT s možností jejich úpravy nebo dopln ní (nap . íslo popisné trvalé adresy žadatele) Složená položka – datový prvek tvo ený nejmén dv ma položkami, nap . Celé jméno (skládá se z titul ed, jméno, p íjmení, titul za ) nebo Adresa (skládá se z n kolika položek v etn ísla domu dále složeného z ísla orienta ního a ísla popisného) íselník – slouží ke standardní kontrole údaje proti vý tu hodnot (nap . íselník stát ). Každý záznam hodnoty íselník m že obsahovat více sloupc (nejen kód a význam ale nap . ZkratkaStátuNa2Znaky, ZkratkaStátuNa3Znaky, eský název, anglický název, plný název, zkrácený název apod.) 23. dotaz: V odpov dích na Dotaz . 5 Dodate ných informací . 7 Zadavatel uvedl, že po et uživatel nep esáhne 300. Chápe Uchaze správn , že je t eba licen pokrýt všech 300 uživatel ? Pokud ne, žádáme o up esn ní po tu uživatel , kte í mají být licen pokryti. Odpov : Zp sob licencování navrhne uchaze v nabídce p i zohledn ní p edpokládaného po tu uživatel 24. dotaz: Žádáme Zadavatele o uvedení po uživatel dle jednotlivých rolí, které jsou uvedeny v kapitole 3.4 Funk ní specifikace ( tená , P isp vovatel, Správce, Audit, Administrátor).
Odpov : Po et uživatel v jednotlivých rolích se bude m nit v pr hu provozování systému a v souvislosti s množstvím evidovaných údaj . V sou asné dob nelze odhadnout jejich po ty v jednotlivých rolích. 25. dotaz: Je sou ástí dodávky Datového katalogu, pokrytí integrace všech aktuálních 21 subsystém ? Odpov : Ne, požadujeme navržení obecného kontrolního mechanismu, který bude moci SSZ po zmapování dalších systém intern používat. Kontrolní mechanismus na KE, VZT a InfoDB vytvo í dodavatel již v rámci projektu. 26. dotaz: Chápe Uchaze správn , že Zadavatel p edpokládá, že komunikace/integrace Datového katalogu a subsystém bude provedena na úrovni databáze nebo formou webových služeb nebo bude provedena integrace p es stávající integra ní platformu MS BizTalk? Pokud ano, která z t chto integrací je požadována? Pokud ne, žádáme o up esn ní, jak je požadováno provedení komunikace/integrace? Odpov : V této fázi Zadavatel nepreferuje žádné z uvedených ešení. Povinností uchaze e je ídit se platnými standardy SSZ. 27 dotaz: Je sou ástí p edm tu pln ní této ve ejné zakázky i dodávka nového systému Etalon? Pokud ne, žádáme o up esn ní, jakým zp sobem je možné provést integraci na existující systém Etalon – databázová úrove , webová služba, integrace prost ednictvím BizTalk nebo jiný zp sob. Odpov : NE, Etalon je pouze ozna ení skupiny vzor pro navrhování údaj datové základny, který bude vytvá en p ímo v aplikaci. 28 dotaz: Uchaze se domnívá vzhledem k odpov di na Dotaz . 1 Dodate ných informací . 7, že verze a typy databází uvedené v poskytnutých standardech neodpovídají aktuálnímu stavu a sou asn tak soudí i vzhledem k tomu, že samotný aktuální Datový katalog je ešen prost ednictvím MS Excel/Access, což vede k úvaze, že existuje další neprázdná množina systém , které nemají datový základ dle poskytnutých standard . Je úvaha Uchaze e správná? Pokud ano, žádáme o up esn ní jednotlivých typ využívaných datových úložiš v etn jejich verzí pro všechny subsystémy, se kterými bude Datový katalog integrován (viz požadavky v kapitole 3.2 Funk ní specifikace). Odpov : Nyní je aktuální verze Oracle Database 10g Enterprise Edition 10.2.0. 64bit, Oracle 11 Oracle Database 11g Enterprise Edition 11.2.0. 64bit. Do budoucna je po ítáno s Oracle 12c
Vzhledem k tomu, že Zadavatel provedl úpravu v p íloze . 1 k rámcové smlouv a to v bod 2.2.8, zasílá upravený dokument uchaze m a posunuje lh ty takto: Lh ta pro podání nabídek: 13. 4. 2015 do 12:00 hodin Otevírání obálek s nabídkami: 13. 4. 2015 od 12:00 hodin
Bc. Ludmila Hnutová odd lení centrálního zadávání ve ejných zakázek SSZ
6. 3. 2015 Digitally signed by Ludmila Hnutová DN: cn=Ludmila Hnutová, c=CZ, o=Česká správa sociálního zabezpečení, ou=Odbor právní,
[email protected] Date: 2015.03.06 13:51:28 +01'00'
