GENERÁLNÍ ŘEDITELSTVÍ CEL Praha 4, Budějovická 7

Transkript

1 GENERÁLNÍ ŘEDITELSTVÍ CEL Praha 4, Budějovická 7 Všem uchazečům VÁŠ DOPIS ZNAČKY NAŠE ZNAČKA VYŘIZUJE / LINKA DATUM 20009/ Kovářová/ odpověď na dotaz k zadávací dokumentaci Veřejná zakázka na služby zadaná v otevřeném řízení podle zákona č. 137/2006 Sb., o veřejných zakázkách, v platném znění (dále jen zákon ), Vývoj národní části SEAP, vyhlášená ve Věstníku veřejných zakázek dne pod evidenčním č Předkládáme Vám doplňující informace k zadávací dokumentaci na základě zaslaného dotazu: Dotaz : Uchazeč směřuje svou žádost o poskytnutí dodatečných informací k zadávacím podmínkám, v souvislosti definicí předmětu plnění uvedené v kapitole 2.2, resp. odkazovaném dokumentu SEAP technická specifikace a ke kapitole 2.3 Zachování investic zadavatele. Úvodem upozorňujeme na chybný výčet příloh zadávací dokumentace, ve které není v předchozím odstavci odkazovaný dokument uveden a dovolujeme si tedy položit otázku, zda je skutečně součástí zadávací dokumentace a navrhnout úpravu znění zadávací dokumentace v tomto duchu. Zadavatel v rámci odkazovaného dokumentu odkazuje (kapitola 3, část Rozhraní vně celní správy ) na popis neveřejného rozhraní se zde citovanými webovými aplikacemi, které bude poskytnuto vítěznému uchazeči a shodně odkazuje v části kapitoly 3 Rozhraní dovnitř IS celní správy na tzv. dostupnou technickou dokumentaci ECR brány, která má dokumentovat interní rozhraní a definice služeb využívaných interními IS zadavateli pro komunikaci s a prostřednictvím ECR brány. Dovolujeme si upozornit, že uvedená definice potenciálních zdrojů informací negarantuje ze strany zadavatele jejich úplnost a dále je jejich absence v přímém rozporu s požadavkem zadavatele uvedeným v kapitole 4 Věcné požadavky na nové řešení, kde je ze strany uchazeče vyžadováno zajištění 100% kompatibility s uvedenými interními i externími rozhraními. Otázkou tedy zůstává, zda je zadavatel schopen garantovat úplnost této dokumentace a zda je možné její technickou část (především definice rozhraní) zařadit do odkazovaného dokumentu nebo jeho příloh. Pokud by uvedené rozšíření zadávací dokumentace nebylo možné došlo by k faktickému omezení možnosti uchazeče provést kalkulaci nabídkové ceny, především pak vzhledem ke garancím zadavatele požadovaným v rámci kapitoly 4 Věcné

2 požadavky na nové řešení na zahrnutí nákladů vyvolaných implementací stávající funkcionality na straně zúčastněných (v minulosti integrovaných) systémů. Z důvodu absence uvedené dokumentace by totiž nebylo možné garantovat onu zmíněnou 100% kompatibilitu. V souvislosti s požadavkem zadavatele v předchozím odstavci je také otázkou jaké jsou parametry dodávky služeb v rámci vynucených úprav rozhraní třetími stranami, zda se tedy jedná o jednotnou sazbu za člověkoden, případně pool kapacit, které jsou zadavateli k dispozici v rámci uzavřených servisních smluv, protože bez alespoň rámcové znalosti cenových a kapacitních limitů nelze uvedené riziko kalkulovat do nabídkové ceny. Shodně lze vyjádřit otázku na výčet, popis a parametrizovanou definici tzv. nadstavbových zakázkově vyvinutých rozšíření a zakázkově vyvinutých komponent pro integraci brány se ZPJ/ASEO na něž zadavatel odkazuje v kapitole 1 bod 2 Rekonstrukce jádra ECR brány a kapitole 4 rekonstrukce jádra ECR brány. Jejich funkce je vzhledem k chybějícím údajům nejasná a rovněž nejasné je tak zajištění jejich funkcionalit vzhledem k výše citovanému požadavku zadavatele na 100% kompatibilitu. Obdobně jako v rámci chybějící dokumentace ECR brány a jejích rozhraní je v rámci odkazovaného dokumentu využíván termín standardní funkcionalita SEAP Hub. Vzhledem k tomu, že se dle kontextu jedná o garantovanou funkci systému a navíc na ní navazuje tzv. nadstandardní funkcionalita (kapitola 1 bod 1), základní funkcionalita, minimální potřebná funkcionalita a základní podpora (kapitola 4 SEAP Hub ), je otázkou, zda je možné v rámci kapitoly provést definici, sjednocení, nebo alespoň zpřesnění uvedených pojmů. Samostatný soubor otázek generuje problematika snahy zadavatele eliminovat nedostatky stávajícího stavu. Z pohledu potenciální dodavatele nelze než předpokládat, že uvedené nedostatky stávající dodavatel neodstranil, protože mu nebyly známy důvody jejich vzniku. Vzhledem k velmi vágní definici lze za potenciální problém označit všechny vrstvy OSI modelu od fyzické až po aplikační a zároveň tak přenést míru zavinění na dodavatele systémů třetích stran, nebo jejich kombinaci. Je tedy možné doložit vybrané případy nedostatků systémovými logy, nebo podrobným popisem události? Je možné kvantifikovat neurčité pojmy jako např.: zpomalení, dočasné zastavení, určité případy, zasekávání apod.? Nebo je alespoň možné poskytnout popis opatření, která zadavatel ve snaze těmto problémům předejít provedl a jejich vyhodnocení? Dovolujeme si zároveň vyjádřit otázku, zda zadavatel v rámci snahy zajistit minimalizaci rizik projektu nepřekračuje svými požadavky rámec zadávací dokumentace a nedochází tak ke zvýhodňování uchazečů se znalostmi interních systémů (tj. především stávající dodavatelé a jejich partneři). Při současném rozsahu technické specifikace totiž není možné odpovědně kalkulovat cenu plnění a reálně tak dochází k porušování ustanovení 6 zákona č. 167/2006 Sb., o veřejných zakázkách ve smyslu nedodržení zásady rovného zacházení s uchazeči ze strany zadavatele. Dále klademe otázku, zda je možné doplnit definici tzv. potřeby a potřebnosti zadavatele v souvislosti s migrací potřebných dat ze starého řešení do nového jak je uvedeno v kapitole 4 část Návrh metodiky testování a uvedení do provozu. Dle našeho názoru není možné tento požadavek řešit v rámci analýzy v průběhu realizace zakázky, protože je v přímém rozporu s požadavkem zadavatele uvedeném v tomtéž oddíle nasazení rekonstruované ECR brány musí být provedeno jen s minimálním výpadkem dostupnosti max. několik hodin během noci, nebo víkendu a potenciální ex post rozhodnutí provést migraci bude znamenat navýšení nabídkové ceny. Stejný problém je otázka požadované integrace do dohledového prostředí celní správy kapitola 5 Technické požadavky na nové řešení. Uvedené lze vnímat jako integraci v rámci níže definovaných platforem se samostatnou aplikační vrstvou, nebo jako službu poskytující data pro stávající aplikační IS Helpdesku CS. Lze tedy doplnit zadávací dokumentaci o určení rozsahu integrace, definici rozhraní a definici minimálně požadovaných incidentů, které mají být tímto způsobem řešeny? Poslední otázkou zůstává doplnění popisu zadavatelem garantované dostupnosti celého spektra licencí k zadavatelem uvedeným platformám uvedeným v kapitole 5

3 Technické požadavky na nové řešení a především pak definice omezení (např. formou platné interní směrnice, nebo metodického dokumentu) pro provozní začlenění do existující vizualizované infrastruktury informačního centra zadavatele. Vzhledem k rozsahu potenciálních materiálů a informací doplněných v rámci reakci zadavatele na uvedené otázky prosíme o zvážení relevantního prodloužení lhůty pro podání nabídek, případně o kvalitní zdůvodnění proč nebudou uvedené informace poskytnuty, abychom předešli případným komplikacím v rámci realizace veřejné zakázky. Odpověď č. 1 Chybný výčet příloh ZD Technická specifikace byla a je nedílnou součástí ZD, ta se na ni odkazuje a byla i přiložena k ZD. Její neuvedení v seznamu příloh je jen nedopatřením. Odpověď č. 2 Garance úplnosti technické dokumentace, zařazení do ZD Zadavatel vítěznému uchazeči poskytne dostupnou technickou dokumentaci, jak je uvedeno v textu technické specifikace a bude připraven poskytnout potřebnou součinnost. Vzhledem k tomu, že uchazeč přesně nedefinuje, co považuje za úplnou technickou dokumentaci, nelze požadovanou garanci poskytnout. Odkazovaná dokumentace na webu celní správy dokládá, že funkce ECR brány jsou nezávislé na věcném obsahu komunikace, kterou sama integrovaným interním systémům zprostředkovává stejným způsobem pro všechny integrované interní systémy. Požadavkem na nové řešení je zachování stejné flexibility řešení stávajícího, kdy přidání další komunikační domény (tedy integrované aplikace) bude pouze konfigurační záležitostí. Pro účely odhadu rozsahu pracnosti jednotlivými uchazeči a možnosti lepší kalkulace nabídkové ceny zadavatel upřesňuje technické informace o způsobu komunikace ECR brány s interními systémy v příloze č. 1 této odpovědi. Tento způsob je společný pro všechny integrované interní aplikace. Odpověď č. 3 Parametry dodávky služeb Ve smyslu položené otázky zadavatel konstatuje, že smlouvy o údržbě a podpoře aplikací, které budou integrovány s předmětem této zadávací dokumentace, jsou uzavřeny v souladu se zákonem o veřejných zakázkách a jejich cenové parametry odpovídají běžným cenám na trhu. Zadavatel předpokládá dostatečnou odbornou znalost uchazečů umožňující provést kvalifikovaný odhad pracnosti v rámci jimi nabízeného řešení. Odpověď č. 4 Definice komponent pro integraci se ZJP/ASEO Aplikace ZJP/ASEO poskytuje ECR bráně datový zdroj, obsahující potřebné informace pro autentizaci a autorizaci přijatých zpráv. S odkazem na poskytnutou dokumentaci ECR obálky lze doplnit, že k danému identifikátoru komunikačních povolení lze v uvedeném datovém zdroji dohledat komunikační doménu, již se povolení týká, daného ekonomického operátora a seznam pověřených osob s jejich registrovanými veřejnými (kvalifikovanými) certifikáty. Pro případ odesílání zpráv s požadavkem na jejich zašifrování obsahuje uvedený datový zdroj i veřejný certifikát pro šifrování. Popis komponent, pomocí kterých stávající řešení ECR brány zpracovává uvedené informace, je, vzhledem k požadavku rekonstrukce ECR brány a požadavku na inovaci stávajících služeb v oblasti elektronických podpisů, irelevantní komponenty nebudou dále použity.

4 Odpověď č. 5 Zpřesnění pojmů funkcionality Zadavatel uznává, že zmíněné pojmy nejsou v rámci technické specifikace používány konzistentně. Tento nedostatek by mělo odstranit následující vysvětlení: SEAP Hub bude sloužit deklarantům, kteří nepožadují nadstandardní funkcionalitu za standardní funkcionalitu je třeba považovat funkcionalitu požadovanou v kapitole 4 technické specifikace pro SEAP Hub. V kontextu odstavce 1 kapitoly 1 technické specifikace jde především o obousměrný přenos zpráv v rámci Externí Domény. Nadstandardní funkcionalitou byly míněny případné služby s přidanou hodnotou, které mohou být či budou moci být poskytovány VAN operátory na komerční bázi. SEAP Hub Musí poskytnout základní funkcionalitu pro stávající komunikační domény v rozsahu stávajícího řešení a rozšíření funkcionality požadované tímto zadáním základní funkcionalitou jsou míněny požadavky na SEAP Hub, uvedené pod citovaným textem. Rozšířenou funkcionalitou jsou míněny nové požadavky z kapitoly Realizace nových funkcí ECR brány. Předpokladem je, že SEAP Hub poskytne minimální potřebnou funkcionalitu (spolu se základní podporou) nutnou pro komunikaci SW deklarantů a daňových subjektů na rozhraní využívající stávající mechanismy a ECR obálku minimální potřebnou funkcionalitou je opět míněna funkcionalita dle požadavků na SEAP Hub uvedených v Příloze č. 3 Technická specifikace zadávací dokumentace v kapitole 4. Věcné požadavky na nové řešení v odstavci nazvaném SEAP Hub. Základní podporou je míněna podpora této funkcionality na úrovni navrženého komunikačního protokolu SEAP Hubu. Odpověď č. 6 doložení uvedených nedostatků Technická specifikace v kapitole č. 2 požaduje eliminaci nedostatků současného stavu. Ty se všechny týkají stávajícího řešení ECR brány implementovaného nad technologií MS BizTalk Server. Jsou ostatně jedním z důvodů, proč je požadována její rekonstrukce. Poskytnutí požadované dokumentace zadavatel považuje za nesouvisející s předmětem zadání. Zadavatel nepožaduje po uchazečích řešení problémů stávajícího řešení, ale dodání řešení nového. Odpověď č. 7 zvýhodnění uchazečů Snahu o eliminaci projektových rizik zadavatel považuje za svoji povinnost při přípravě jakéhokoliv projektu. Tato snaha není v rozporu se zákonem o veřejných zakázkách. Odpověď č. 8 Migrace Požadovaná metodika testování a uvedení do provozu, která bude uchazečem vytvořena jako součást realizace projektu, bude vycházet jednak z jeho analýzy stávajícího řešení a zároveň z návrhu řešení nového a mimo jiné velmi podrobně navrhne způsob migrace ze stávajícího řešení na nové. Zadavatel bude vyžadovat otestování celého migračního procesu předem a v žádném případě nepřipustí situaci, kdy by migrace dat byla řešena až po (zřejmě neúspěšném) uvedení do provozu. Podmínky výběrového řízení dále nepřipouští žádné navyšování ceny. Rozhodnutí, zda bude migrace dat potřeba, či zda nové řešení naváže na datovou základnu řešení stávajícího, bude určeno návrhem nového řešení a zadavatel je tak v tuto chvíli není schopen predikovat.

5 Odpověď č. 9 Dohledové prostředí Stávající funkcionalita dohledového prostředí je upřesněna v příloze č. 2 této odpovědi. Zadavatel předpokládá, že uchazeč ve své nabídce popíše způsob, jakým zajistí požadovaný dohled a v projektu tento způsob následně zrealizuje. Odpověď č. 10 Licenční omezení pro existující stav Technická specifikace v kapitole 5 Technické požadavky na nové řešení v posledním bodu uvádí licenční požadavky na produkty třetích stran, které budou pro provoz řešení potřeba. Poslední odstavec těchto požadavků specifikuje ty SW produkty třetích stran, které zadavatel v současnosti používá a jejichž licence vlastní, respektive bude vlastnit v době realizace a provozu řešení (jako jeho provozovatel) a které tudíž nemusí být součástí nabídkové ceny. Uvedené licence produktů VMWare vsphere a OS MS Windows Server jsou vázány výhradně na provoz řešení formou virtuálních strojů v rámci existující virtualizované infrastruktury a v tomto rámci nejsou nijak omezeny (řešení může být provozováno na tolika virtuálních serverech, kolik bude potřeba). Licenčně pokryt je i provozní databázový cluster MS SQL Server 2005, který může být pro databáze řešení použit též. Požadované webové rozhraní SEAP Hub pro deklaranty respektive daňové subjekty může být začleněno do stávajícího clusteru internetového portálu Celní správy založeného na produktu MS SharePoint Portal Server 2007 a databázi MS SQL Server 2008 a též již licenčně pokrytého. Poskytnuté odpovědi na otázky č. 1 až 10 včetně příloh tohoto dokumentu nejsou změnou podmínek zadávací dokumentace ani jejím rozšířením a z tohoto důvodu zadavatel neprodlouží lhůtu pro podání nabídek. S pozdravem Ing. Jiří Hammer Zadavatel a ředitel Sekce ekonomiky a informatiky Přílohy: Příloha č. 1 upřesnění informací o způsobu komunikace stávající ECR brány s integrovanými interními systémy Příloha č. 2 stávající funkcionalita dohledového prostředí ECR brány

6 Příloha č. 1 upřesnění informací o způsobu komunikace stávající ECR brány s integrovanými interními systémy Technická specifikace v kapitole č. 3 Technický popis stávajícího stavu popisuje Rozhraní dovnitř IS celní správy. Jako upřesnění tohoto popisu a uvedeného schématu uvádíme popis datové struktury MsgInfo a rozhraní front typu AQMQ. MSGINFO je XML dokument obsahující klíčové údaje o přenášené datové zprávě. ECR brána ho vygeneruje na základě údajů z EcrObalka (tj. ne z datové zprávy). Kořenový element MSGINFO má podelementy H (hlavička) a ECRGATE (korelační údaje pro ECR bránu). Do elementu H se plní tyto podelementy z EcrObalka: MSGID hodnota atributu GuidObalky elementu Hlavicka MSGTYPE hodnota atributu Typ elementu Zprava EDIPARTNERID kdo zprávu přijímá (u příchozích zpráv je to vždy hodnota GRC.IC, u odchozích je to ID komunikačního povolení deklaranta) EDISENDERID kdo zprávu odesílá (u příchozích zpráv je to vždy ID komunikačního povolení deklaranta, u odchozích je to hodnota GRC.IC) Pozn.: vždy jeden z elementů EDIPARTNERID/EDISENDERID je roven hodnotě GRC.IC a druhý hodnotě Ucastnici/Ucastnik[@Role= deklarant ]/@Identifikator. Nepovinné elementy: MRN/LRN/CRN pokud je známo, že v dané komunikační doméně se komunikuje jen za pomocí atributu HlavniID elementu Zprava (tedy identifikace obchodního případu přidělená celní správou), plní se jeho hodnota do elementu CRN. Pokud komunikační doména používá atributy HlavniID i VedlejsiID, pak se HlavniID (od chvíle, kdy v rámci komunikace začne existovat tedy při první odpovědi na podání) plní do elementu MRN a VedlejsiID (identifikace obchodního případu přidělená deklarantem od počátku komunikace) do elementu LRN. Pokud element v příchozí zprávě neexistuje, element MRN/LRN se vůbec negeneruje (neexistuje tedy MSGINFO s prázdnými MRN/LRN elementy). VANID plní se hodnotou Ucastnici/Ucastnik[@Role= operator ]/@Identifikator (tj. NWK, CNS, NZSERVIS,.) a používá jej jen komunikační doména NCTS. Element ECRGATE je interní element pro ECR bránu sloužící ke korelaci zpráv. Konvence je taková, že ECR brána posílá centru integrované interní aplikace tento element, to obsah ECRGATE uloží do DB a pokud centrum odpovídá zprávou, která jde přes ECR bránu, vyplní do odchozího MSGINFO to, co bylo v příchozí zprávě. Aplikační centra nijak tento element nepoužívají. Z pohledu tohoto zadání vyplývá, že navrhované řešení uchazeče bude moci do elementu ECRGATE uvést vlastní potřebné korelační údaje a má garantováno jejich navrácení. Popis obsahu tohoto elementu je tak pro účely tohoto zadání irelevantní nicméně v následujícím příkladu v zásadě srozumitelný pro toho, kdo nastudoval odkazovanou dokumentaci EcrObalka. Příklad: <MSGINFO>

7 <H> <MSGID>a36d4b ae8-90a8-a38aaa88fd9e</MSGID> <MSGTYPE>CZ015A</MSGTYPE> <EDIPARTNERID>GRC.IC</EDIPARTNERID> <EDISENDERID>06CZ176100JS00020</EDISENDERID> <LRN> XC6IYCUDL</LRN> <VANID>NWK</VANID> </H> <ECRGATE> <DOMAIN>NCTS</DOMAIN> <TARGET>NWK</TARGET> <CHANNEL>BasicHttpRLConfig</CHANNEL> <CONTENT>XML</CONTENT> <ENVELOPEVERSION>2.0</ENVELOPEVERSION> <SUPERENVELOPE>none</SUPERENVELOPE> <SIGNATURETYPE>EnvelopedInOnDocument</SIGNATURETYPE> <DIGESTTYPE>SHA512</DIGESTTYPE> <PARTICIPANTS> <ROLE>deklarant</ROLE> <GUID> a9-b4f9-b8d3c3f15a2d</GUID> <ID>06CZ176100JS00020</ID> </PARTICIPANTS> <PARTICIPANTS> <ROLE>operator</ROLE> <GUID>59f5a951-aa2c-4e9d-914e </GUID> <ID>NWK</ID> </PARTICIPANTS> <PARTICIPANTS> <ROLE>grc</ROLE> <GUID>5EB E-49D2-B214-D4C5CD32FA3C</GUID> </PARTICIPANTS> </ECRGATE> </MSGINFO> Některé z integrovaných aplikací používají pro komunikaci s ECR bránou zakázkově vyvinutou frontu AQMQ. Jde o realizaci fronty zpráv nad tabulkou v MS SQL Serveru. Pro účely správného užití funkcionality této fronty zadavatel poskytne.net assembly MQSQL.dll s programátorskou dokumentací. Zmíněná Assembly obsahuje metody pro uložení a výběr zpráv, které implementují korektně zamykání nad SQL tabulkou. Parametry uvedených metod odpovídají následujícímu popisu struktury AQMQ fronty: [localid] [varchar](50) NOT NULL [h] [nvarchar](max) NOT NULL [bsize] [int] NOT NULL [inserted] [datetime] NOT NULL [b] [image] NULL

8 kde: [localid] je jedinečné ID zprávy (GUID), do [h] se plní MSGINFO, [bsize] je velikost [b] v bytech ([bsize] = DATALENGTH([b])), [inserted] je datum a čas vložení zprávy (většinou se nevyplňuje a default SQL constraint zajistí, že se tam dostane GETDATE()), [b] je přenášená zpráva. [b] nemusí obsahovat XML, ale klidně XML zkomprimované pomocí gzip, nebo PDF (dle potřeb dané komunikační domény).

9 Příloha č. 2 stávající funkcionalita dohledového prostředí ECR brány Nové řešení musí poskytovat obdobné funkcionality jako stávající prostředí. Dohledované části ECR brány: Kontrola zpracovávaných zpráv - dohled databáze ECRGateTracking: 1x za 3 minuty se provedou 2 kontroly (obě dohromady trvají dohromady řádově desetiny vteřiny): zjistí se, kolik je v Biztalku aktivně zpracovávaných instancí zpráv, toto číslo nesmí být vyšší než 400 sečte se počet zpráv, které jsou ve stavu probíhající nebo čeká na receipt déle než 3 minuty a počet všech chyb za poslední hodinu - toto číslo nesmí být vyšší než 20 pokud alespoň jedna z předchozích kontrol neprojde, je odeslán dohled s následujícím obsahem (dohled je odeslán na stejné adresáty jako dohled Biztalk Clusteru): počet všech aktivních instancí v Biztalku + počty dle typu (Active, Ready to Run, ) počet zpráv, průměrný počet pokusů o odeslání 1 zprávy a průměrná doba obdržení receiptu na zprávu za posledních 60 minut; vše seskupené dle VAN operátora to samé, co předchozí, ale za posledních 5 minut počet chybových, nepřijatých a pomalých (zpracování trvá déle než 3 minuty) zpráv za poslední hodinu - vše seskupené dle VAN operátora Dohledy clusteru (každých 150 sekund): Dohled skupiny Biztalk Group (1) clusteru G860000CL220 Dohled skupiny Msdtc Group (1) clusteru G860000CL220 Dohled skupiny 'Sql Server Group (2) clusteru G860000CL220 Dohled databázových front (každých 5 minut): Dohled starých záznamů ve frontách ECR brány - mqecrnta, mqntaecr, mqntazjp, mqzjpnta