SMLOUVA O DÍLO Č. CTU/2021_097
SMLOUVA O DÍLO Č. CTU/2021_097
A. Česká republika – Český telekomunikační úřad
se sídlem: Xxxxxxxxxx 00/000, Xxxxx 0 – Xxxxxxxx doručovací adresa: pošt. přihrádka 02, 225 02 Praha 025
IČO: 701 06 975
DIČ: CZ70106975 (osoba identifikovaná k dani)
zastoupený: Mgr. Xxx. Xxxxx Xxxxxxxxxx
předsedkyní Rady Českého telekomunikačního úřadu Bankovní spojení: Česká národní banka, pobočka Praha
Číslo účtu: 725001/0710 (dále také „Objednatel“)
a
B. TECHNISERV, spol. s r.o.
se sídlem: Praha 4, Baarova 231/36, PSČ 14000
IČO: 44264020
DIČ: CZ44264020
zapsaná v obchodním rejstříku vedeném Městským soudem v Praze, oddíl C, vložka 5239 zastoupená: Ing. Xxxxxxxxxx Xxxxxxxxx, Ph.D., jednatelem
Bankovní spojení: Komerční banka, a.s. Číslo účtu: 435742011/0100 (dále také „Zhotovitel“)
(Objednatel a Zhotovitel dále také společně „Strany“ nebo jednotlivě „Strana“), uzavřely tuto smlouvu o dílo (dále také „Smlouva“):
PREAMBULE
Na základě výběrového řízení a smluv uzavřených mezi Objednatelem a společností ROHDE & XXXXXXX - Praha, s.r.o., se sídlem Praha 6 - Hadovka Office Park, Xxxxxxxx 0000/00x, PSČ 160 00, IČO: 62906127, zapsanou v obchodním rejstříku vedeném Městským soudem v Praze, oddíl C, vložka 34376 (dále také „Předchozí smluvní dokumentace“), byl dodán, rozvíjen a udržován „Nový jednotný programový systém pro podporu správy kmitočtového spektra“ složený ze softwarových komponent společnosti LS telcom AG pod obchodním označením SPECTRAplus ve verzi Professional (tento systém dále také „SPECTRAplus“). Účelem této Smlouvy je zajištění modernizace SPECTRAplus implementací nového softwaru s obchodním označením mySPECTRA včetně zákaznických specifických úprav a konfigurací standardního softwaru (dále také „mySPECTRA“) a dalších modulů vyvinutých na míru pro Objednatele (dále takto modernizovaný a na míru upravený systém také
„Systém“) v rámci projektu „Generační inovace SW nástroje pro správu kmitočtového spektra ČR“ tak,
aby byla uživatelská data Objednatele z tohoto Systému zároveň snadno a beznákladově exportovatelná k dalšímu využití Objednatelem nebo třetí stranou určenou Objednatelem.
1. PŘEDMĚT SMLOUVY
1.1. Zhotovitel se zavazuje provést pro Objednatele na svůj náklad a nebezpečí Dílo a převést na Objednatele práva k němu v ujednaném rozsahu a Objednatel se zavazuje provedené Xxxx převzít a zaplatit za něj Zhotoviteli dohodnutou cenu.
1.2. Veškeré práce na Díle (tj. Upgrade, Analýza, Plán, Návrh, Implementace) budou vycházet z Jednotného katalogu požadavků (dále také „Katalog“), přičemž rozšíření požadavků Objednatele nad rámec Katalogu nebo skutečností, které při tvorbě Katalogu Zhotoviteli měly nebo musely být známy, bude podléhat změnovému řízení dle této Smlouvy.
1.3. Dílo bude spočívat v:
a) upgrade SPECTRAplus na mySPECTRA a jeho integraci se stávajícími systémy Objednatele (GINIS, LJIP, SKS, účetní systém, APV ASMK a webový portál) při zachování kompatibility se stávajícími moduly SPECTRA_EMC, SPECTRA_PLAN, MONITOR_PLUS, CHIRplus_BC (dále také „Upgrade“);
b) provedení detailní analýzy požadavků (dále také „Analýza“) uvedených v jednotném katalogu požadavků, který tvoří Přílohu č. 1 této Smlouvy, dodání Implementačního, integračního a migračního plánu (dále také „Plán“) a dodání návrhové dokumentace v návaznosti na provedenou Analýzu (dále také „Návrh“);
c) v návaznosti na závěry provedené Analýzy a odsouhlasené výstupy Návrhu:
i dodávka a úprava stávajících standardních softwarových modulů mySPECTRA; jejich konfigurace a instalace ve virtuálním prostředí Objednatele;
ii vytvoření univerzálního komunikačního rozhraní (dále také „Mediátor“) pro výměnu dat mezi Systémem a stávajícími systémy Objednatele (GINIS, LJIP, SKS, účetní systém, APV ASMKS a webový portál); Mediátor musí v budoucnu umožnit Objednateli též napojení budoucích systémů Objednatele a softwarů třetích stran. Napojení budoucích systémů a SW třetích stran není předmětem Smlouvy.
iii migrace testovacích a ostrých dat do mySPECTRA;
iv vytvoření testovacího a produkčního prostředí, testování Systému a rozhraní na jiné informační systémy Objednatele (tj. GINIS, LJIP, SKS, účetní systém, APV ASMK a webový portál) a jejich výkonnosti;
v provedení Závěrečného ověření funkčnosti Systému;
vi vytvoření dokumentace k Systému a provedené konfiguraci a dodání uživatelských manuálů, provedení školení správců a koncových uživatelů dodaného software a dodávka školicích materiálů;
vii poskytnutí všech dalších prací nezbytných pro plnohodnotné zprovoznění Systému v prostředí Objednatele, které bezprostředně souvisí s předmětem díla tak, jak jej definuje tento odstavec 1.3 (dále také „Implementace“). Přípravu kompletního HW a virtuálního běhového prostředí zajistí Objednatel;
(Upgrade, Analýza, Plán, Návrh a Implementace dále společně také „Dílo“).
1.4. Předmět a rozsah Analýzy, Plánu a Návrhu je upřesněn v Příloze č. 6 této Smlouvy. Podrobná specifikace Díla a jeho jednotlivých částí je dále definována v Katalogu a bude dále upřesněna na základě akceptované Analýzy a akceptovaného Návrhu.
1.5. Předmětem této Smlouvy je dále závazek Xxxxxxxxxxx uzavřít s Objednatelem smlouvu o podpoře, údržbě a vývoji dle článku 7 této Smlouvy.
1.6. Zhotovitel je dále povinen poskytnout Objednateli na jeho žádost neprodlenou součinnost k zajištění převodu provozu Systému na Objednatele či jím pověřenou osobu, to vše v souladu s článkem 14 této Smlouvy (dále také „Exit“). Objednatel není povinen žádost o provedení Exitu učinit.
2. OBECNÁ USTANOVENÍ O PROVÁDĚNÍ DÍLA
2.1. Místem dodání Díla je sídlo Objednatele.
2.2. Zhotovitel zahájí provádění Díla bezprostředně po uzavření Smlouvy a dokončí ho nejpozději v termínu dle časového harmonogramu uvedeného v Příloze č. 3 této Smlouvy (dále také
„Harmonogram“). Za den dokončení Díla se považuje den ukončení Závěrečného ověření funkčnosti Díla dle Přílohy č. 2 této Smlouvy, tj. podepsání Závěrečného akceptačního protokolu (dále také „Den dokončení“).
2.3. Dílo bude prováděno po částech a v termínech dle Harmonogramu za využití milníků, definujících nejdůležitější termíny provádění Díla (dále také „Milníky“). Změny a upřesnění časového Harmonogramu jsou možné pouze postupem podle této Smlouvy.
2.4. Objednatel je povinen poskytnout veškerou součinnost, která je pro Zhotovitele a poddodavatele přiměřeně nezbytná k provedení Díla. Časová lhůta pro poskytnutí součinnosti Objednatele činí:
a) 2 pracovní dny u požadavků Zhotovitele na součinnost, které na straně Objednatele nevyvolají potřebu součinnosti třetí strany a které jsou splnitelné v rozsahu do 8 hodin práce jednoho člověka,
b) 5 pracovních dnů u ostatních požadavků na součinnost,
pokud není v Harmonogramu stanoveno jinak. Připadá-li jakýkoliv termín Zahájení nebo Dokončení uvedený v Harmonogramu pro součinnost Objednatele na den pracovního klidu, posouvá se na nejbližší pracovní den. V případě, že celková doba neposkytnutí součinnosti ze strany Objednatele činí v kumulativním součtu více jak 20 pracovních dní v jednom kalendářním roce, je Zhotovitel počínaje 21. pracovním dnem oprávněn požadovat po Objednateli navýšení ceny díla odpovídající poměru mezi prodlouženou dobou a původní dobou realizace díla ve vztahu k poměru budoucí a sjednané ceně díla, jakož i prodloužení doby plnění, které je delší než samotné prodlení způsobené Objednatelem. Každá doba neposkytnutí součinnosti ze strany Objednatele musí být Zhotovitelem nejpozději do 3 pracovních dnů od jejího započetí i od jejího ukončení oznámena Objednateli s uvedením počtu pracovních dnů, po které, dle názoru Zhotovitele měla trvat, jinak ji nelze započítat ani použít k tíži Objednatele. Ustanovení článku
10.1 této Smlouvy není tímto ustanovením dotčeno.
2.5. Dílo bude prováděno v souladu s principy standardů PRINCE2 a IPMA.
2.6. Postup testování Díla a jeho jednotlivých částí, včetně akceptačních kritérií a předání je podrobně upraven v Příloze č. 2 této Smlouvy.
2.7. Shledá-li Zhotovitel, že Den dokončení Díla tak, jak je uveden v Harmonogramu, nebo kterýkoliv Milník uvedený v Harmonogramu nebude dodržen, je povinen o tomto hrozícím prodlení včetně všech podrobností včas informovat Objednatele, a to (i) nejpozději 45 dní před Dnem dokončení Díla, týká-li se prodlení dokončení Díla, nebo před termínem Milníku, kterého se prodlení týká nebo (ii) bezodkladně, nebylo-li možné prodlení předvídat ani při vynaložení odborné péče. Uvedené nemá vliv na odpovědnost Zhotovitele za včasné dokončení a předání Díla (toto neplatí v případě, že Xxxxxxxxxx prokáže, že vina za vzniklé prodlení neleží na jeho straně).
2.8. Vlastnictví k výsledkům Díla, umožňuje-li u nich zákon převod vlastnického práva, a jeho částí přechází na Objednatele vždy jejich předáním Objednateli, a to v souladu s licenčními podmínkami uvedenými v článku 5 a v Příloze č. 4 této Smlouvy.
2.9. Objednatel je oprávněn požadovat změnu poddodavatele, (i) nebyla-li mu udělena či mu byla odebrána potřebná povolení či oprávnění k činnosti nebo (ii) bylo vůči poddodavateli vydáno pravomocné rozhodnutí o úpadku nebo bylo zahájeno insolvenční řízení proti poddodavateli na jeho návrh, nebo v případě, že soud pravomocně rozhodl o zrušení poddodavatele a nařídil jeho likvidaci, nebo poddodavatel přijal rozhodnutí o vstupu do likvidace. Objednatel je oprávněn požadovat změnu poddodavatele v souladu s tímto odstavcem Smlouvy kdykoliv v průběhu trvání Smlouvy a Zhotovitel je povinen takový požadavek Objednatele akceptovat.
2.10. Zhotovitel nese odpovědnost za řádné plnění Smlouvy nezávisle na tom, jestli ji plní osobně nebo prostřednictvím poddodavatelů. Poddodavatele neuvedeného v Příloze č. 5 této Smlouvy nesmí Zhotovitel pověřit prováděním Díla bez předchozího souhlasu Objednatele, a to zejména z důvodu:
a) zajištění ochrany osobních údajů podle článku 8 této Smlouvy;
b) zajištění povinnosti mlčenlivosti;
c) možnosti posouzení, zda potencionální poddodavatel není ve střetu zájmů (tj. nepodniká v elektronických komunikacích ve smyslu § 8 zákona č. 127/2005 Sb., o elektronických komunikacích a o změně některých souvisejících zákonů (zákon o elektronických komunikacích), ve znění pozdějších předpisů).
2.11. Zhotovitel se zavazuje plnit řádně a včas své závazky vůči poddodavatelům. Zjistí-li Objednatel, že Zhotovitel neuhradil splatné pohledávky poddodavatelů, je dle svého uvážení oprávněn, nikoli však povinen, uhradit dlužné částky přímo poddodavatelům namísto Zhotovitele. Náhradu částek uhrazených přímo poddodavatelům Zhotovitele je Objednatel oprávněn započíst proti pohledávkám Zhotovitele z vystavených faktur či jiným pohledávkám Zhotovitele v souvislosti s touto Smlouvou. Jestliže Zhotovitel bude v prodlení s úhradou splatných závazků vůči kterémukoli z poddodavatelů po dobu delší =30 dnů a/nebo odmítne uzavřít odpovídající smluvní dokumenty za účelem vyřešení pohledávek poddodavatelů či započtení pohledávek dle předcházející věty, je Objednatel oprávněn pozastavit platby faktur oprávněně vystavených Zhotovitelem dle této Smlouvy v odpovídající výši až do vyřešení pohledávek poddodavatelů. Na takto pozastavené úhrady nelze pohlížet jako na prodlení Objednatele s úhradou faktur. Na výzvu Objednatele je Zhotovitel povinen předložit dokumenty prokazující, že řádně a včas hradí pohledávky poddodavatelů.
2.12. Xxxxxxxxxx se dále zavazuje, že:
a) Dílo, jakožto významný informační systém státní správy, bude ke dni jeho provedení splňovat všechny aplikovatelné požadavky stanovené pro provozování takového systému právními předpisy týkajícími se kybernetické bezpečnosti, zejména zákonem č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů, a vyhláškou č. 82/2018 Sb., o bezpečnostních
opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška
o kybernetické bezpečnosti), přičemž Zhotovitel prohlašuje že je držitelem certifikace ISO 27001 a takové požadavky jsou mu známy;
b) bude vše řádně dokumentovat v souladu s Přílohou č. 6 této Smlouvy;
c) provede analýzu rizik provádění Díla včetně jejich vyhodnocení;
d) přijme adekvátní opatření na případná neakceptovatelná rizika za účelem snížení nepříznivých dopadů;
e) zajistí možnost uvedení Systému do původního stavu;
f) provede penetrační testování a testování zranitelnosti Systému v souladu s Přílohou č. 6
této Smlouvy.
2.13. Na žádost Xxxxxxxxxxx může Objednatel umožnit jeho pracovníkovi, aby po dobu 10 dní v průběhu Závěrečného ověření funkčnosti Díla dle Přílohy č. 2 této Smlouvy pracoval ze sídla Objednatele.
2.14. V průběhu provádění Díla se rozlišují dva typy změn:
a) nepodstatná – tj. změna v souladu s kontextem dodávky/závazku daného projektu, nemá podstatný vliv (malá závažnost dopadů) na tzv. trojimperativ (rozsah, harmonogram, rozpočet projektu), resp. Smlouvu;
b) podstatná – tj. podstatná odchylka od dohodnuté specifikace definované Smlouvou, zejména jde o dopad na smluvní rozsah, termín plnění a cenu.
2.15. Za účelem navrhování a projednávání změn si každá Strana zvolí svého projektového manažera. O svém projektovém manažerovi a jeho kontaktních údajích následně informuje druhou Stranu. Změna projektového manažera je účinná od jejího potvrzení druhou Stranou.
2.16. Kterákoliv Strana může v průběhu provádění Díla navrhnout změnu specifikace Díla nebo podmínek, za kterých bude provedeno, a to zasláním návrhu na změnu projektovému manažerovi druhé Strany. Projektový manažer druhé Strany následně posoudí, jestli se jedná o změnu podstatnou nebo nepodstatnou. Projektový manažer Xxxxxxxxxxx bude informovat projektového manažera Objednatele o odhadu nákladů, a pokud se ukáže, že analýza a návrh změny, která odpovídá Změnovému požadavku Objednatele, bude vyžadovat ze strany Zhotovitele výraznou práci navíc (tj. více jak 5 člověko-dnů), která musí být účtována zvlášť, může se projektový manažer Objednatele svobodně rozhodnout, zda na základě uvedeného pokračovat ve Změnovému požadavku, nebo zda jej stáhne.
2.17. Nepodstatnou změnu jsou projektoví manažeři Xxxxx oprávněni samostatně schválit. O schválení nepodstatné změny vyhotoví strany písemný zápis, který za každou stranu projektový manažer podepíše a ve kterém všechny navrhované změny popíšou a zhodnotí jejich vliv na Smlouvu.
2.18. Podstatnou změnu je za Objednatele oprávněn schválit pouze předseda/předsedkyně Českého telekomunikačního úřadu a za Zhotovitele jeho statutární orgán. Schválený návrh na podstatnou změnu musí mít náležitosti písemného změnového listu a upravovat alespoň následující náležitosti: a) Číslo změnového listu; b) Datum nahlášení; c) Garant požadavku; d) Název změny;
e) Stručný popis změny; f) Důvod/přínosy úpravy; g) Důsledky nerealizování úpravy; h) Detailní popis změny a očekávaný výstup; i) Pracnost realizace změny v člověko-hodinách; j) Datum schválení k realizaci; k) Jméno a podpis za Objednatele; l) Jméno a podpis za Zhotovitele;
m) Datum a verze nasazení úpravy na testovací prostředí; n) Datum a verze nasazení na provozní prostředí; o) Jméno a podpis předávajícího – za Zhotovitele; p) Jméno a podpis
přejímajícího – za Objednatele; a q) Jméno a podpis akceptujícího – pokud není totožný s přejímajícím.
3. CENA
3.1. Cena za provedení Díla včetně Exitu je 75 000 000 Kč.
3.2. Cena za jeden člověko-den práce (tj. 8 člověko-hodin) v rámci víceprací je:
a) v případě práce poddodavatele LS telcom AG maximálně částka ve výši 32 000 Kč, přičemž Zhotovitel prohlašuje, že tato částka bude vždy odpovídat jeho nákladům spojeným s prací tohoto poddodavatele, a že se tyto zavazuje Objednateli účtovat bez jakékoliv cenové přirážky, což je povinen Objednateli doložit současně, a to zejména předložením příslušného vyúčtování LS telcom AG. V případě, že je práce poddodavatele LS telcom AG poskytnuta prostřednictvím jiného poddodavatele, například ROHDE & XXXXXXX – Praha, s.r.o., vztahují se ustanovení tohoto písm. a) pouze na práci, která byla skutečně provedena poddodavatelem LS telcom AG, Zhotovitel v takovém případě doloží vyúčtování LS telcom AG i jiného poddodavatele, jehož prostřednictvím byla práce LS telcom AG poskytnuta (došlo-li by ke zvýšení nákladů s prací tohoto poddodavatele, ponese tyto zvýšené náklady Zhotovitel),
b) v případě práce Zhotovitele nebo jiných poddodavatelů 12 000 Kč.
Zhotovitel se rovněž zavazuje provádět Dílo v maximální možné míře osobně, a to i v případě víceprací. Zadat provádění části Díla poddodavatelům může Zhotovitel pouze za předpokladu, že osobní výkon jeho povinností nebude z objektivních důvodů možný (zejména pak pro nedostatek autorských práv či přístupových oprávnění ke zdrojovým kódům).
3.3. Cena může být změněna v rozsahu Stranami odsouhlasených změn postupem podle této Smlouvy.
3.4. Ceny jsou uvedeny bez daně z přidané hodnoty, která bude Zhotovitelem účtována podle příslušných právních předpisů. Zhotovitel odpovídá za to, že sazba daně z přidané hodnoty bude stanovena v souladu s příslušnými právními předpisy.
3.5. Zhotovitel prohlašuje, že se plně seznámil se Smluvní dokumentací, Předchozí smluvní dokumentací a s rozsahem a povahou Díla a Exitu a správně vyhodnotil a ocenil veškeré práce trvalého i dočasného charakteru a veškeré dodávky, které jsou nezbytné pro řádné splnění této Smlouvy. Cena obsahuje veškeré Zhotovitelovy náklady, výdaje, rizika, odpovědnosti a závazky vyplývající ze Smlouvy či z příslušných právních předpisů (bez zřetele na to, zda je v této Smlouvě uvedeno, že Zhotovitel splní tu kterou povinnost na své vlastní náklady, či nikoliv), které jsou potřebné pro řádné provádění, dokončení a předání Díla a odstranění veškerých jeho případných vad a které bylo možné v době uzavření Smlouvy rozumně předpokládat, a které vychází z Katalogu, včetně:
a) veškerých nákladů, poplatků, výdajů atd. spojených s Dílem, jako jsou pracovní síly, zařízení a materiál, organizace, náklady na zajištění kvality a technické kontroly, příprava dokumentace, přeprava, cestovní náklady, náklady na ubytování a zkoušky;
b) veškerých správních, celních a licenčních poplatků, daní, opatření a požadavků správních orgánů, s výjimkou těch, za které je dle této Smlouvy výslovně odpovědný Objednatel;
c) jakýchkoli dalších prací, činností a dodávek, které nejsou v této Smlouvě výslovně uvedeny, ale jsou nebo se v průběhu provádění Díla ukážou jako nezbytné pro řádné provedení a užívání Díla v souladu s jeho určením.
3.6. Strany tímto sjednávají slevu z ceny za provedení Díla, přičemž toto ujednání nabývá účinnosti splněním odkládací podmínky, kterou je pravomocné rozhodnutí soudu o úpadku Zhotovitele, a to kdykoli v průběhu trvání této Smlouvy a dále záruční lhůty uvedené v odstavci 6.1 této Smlouvy. Nabytím účinnosti tohoto ujednání vzniká nárok Objednatele na zaplacení slevy z ceny díla ve výši Zádržného, které bude Objednatel v souladu s podmínkami této Smlouvy zadržovat v okamžiku splnění odkládací podmínky (dále také „Pohledávka Objednatele“). Strany se dohodly, že nabytím účinnosti tohoto ujednání se zároveň započítává Pohledávka Objednatele vůči pohledávce Xxxxxxxxxxx na vrácení Zádržného v plné výši, čímž obě tyto pohledávky zanikají v celém svém rozsahu.
4. PLATEBNÍ PODMÍNKY
4.1. Cena Díla bude zaplacena na základě faktur vystavených Zhotovitelem dle následujících fakturačních milníků:
a) =15 % z ceny Díla po provedení a akceptaci Analýzy, se zádržným ve výši 20 %, které bude uvolněno po odstranění nedostatků zjištěných při předání této části díla;
b) =15 % z ceny Díla po provedení a akceptaci Návrhu, se zádržným ve výši 20 %, které bude uvolněno po odstranění nedostatků zjištěných při předání této části díla;
c) =20 % z ceny díla po úspěšném ukončení FAT, se zádržným ve výši 10 %, které bude uvolněno společně se zádržným dle písmene e) níže;
d) =30 % z ceny Díla po úspěšném ukončení SAT, se zádržným ve výši 10 %, které bude uvolněno společně se zádržným dle písmene e) níže;
e) =20 % z ceny Díla po podepsání Závěrečného akceptačního protokolu po ukončení Závěrečného ověření funkčnosti, se zádržným ve výši 10 %, které bude uvolněno po skončení záruční doby a poté, co všechny záruční vady budou řádně odstraněny.
4.2. Objednatel si může ponechat a nezaplatit z každé jednotlivé platby uvedené v odstavci 4.1 této Smlouvy částky ve výši uvedené u jednotlivých plateb (dále také „Zádržné“), které budou uvolněny po splnění rovněž v odstavci 4.1 této Smlouvy uvedených podmínek.
4.3. Po provedení Díla je Zhotovitel oprávněn nahradit Zádržné bankovní zárukou vydanou renomovanou bankou se sídlem v České republice, a to (i) neodvolatelnou, bezpodmínečnou, splatnou na první výzvu, (ii) ve stejné výši, v jaké byla sjednána výše Zádržného a (iii) se lhůtou platnosti do konce záruční doby. Konkrétní forma bankovní záruky musí být předem písemně odsouhlasena Objednatelem. Náklady na zřízení bankovní záruky nese Zhotovitel.
4.4. Zhotovitel zašle vystavené faktury doporučeným dopisem na adresu Objednatele nebo elektronicky do datové schránky Objednatele. Faktura musí splňovat náležitosti daňového dokladu dle zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů, a obsahovat údaje dle § 435 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů, a dále identifikaci projektu mySPECTRA, rozpis jednotlivých fakturovaných položek v dostatečném rozsahu a evidenční číslo této Smlouvy. Přílohou každé faktury bude akceptační protokol vztahující se k danému fakturačnímu milníku podepsaný oběma Stranami. Xxxxxxxxxx je povinen povolit a přijímat prostřednictvím své datové schránky poštovní datové zprávy.
4.5. Faktura je splatná do =21 dnů ode dne jejího doručení Objednateli, nestanoví-li konkrétní faktura splatnost delší. Faktura doručená Objednateli mezi 15. prosincem až 20. lednem následujícího roku se stane splatnou nejdříve nejbližšího 1. února.
4.6. Nebude-li faktura obsahovat některou povinnou nebo dohodnutou náležitost nebo bude jinak chybná, může Objednatel fakturu vrátit Zhotoviteli k provedení opravy. V takovém případě běží celá lhůta splatnosti znovu ode dne doručení nové, bezvadné faktury Objednateli.
4.7. Objednatel zaplatí cenu převodem na účet Zhotovitele označený ve faktuře. Povinnost Objednatele zaplatit Zhotoviteli jakoukoliv částku je splněna dnem odeslání příslušné částky na bankovní účet Zhotovitele.
5.2. V případě plnění Zhotovitele dle této Smlouvy, které nespadá pod plnění dle odstavce 5.1 této Smlouvy a současně je autorským dílem či naplňuje znaky autorského díla (dále také „autorské dílo“) dle zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů ve znění pozdějších předpisů (dále také „autorský zákon“), postupuje Zhotovitel na Objednatele k okamžiku vytvoření takového autorského díla všechna majetková práva k takovému autorskému dílu v celém rozsahu, včetně dřívějších verzí. Takové postoupení práv umožní Objednateli zejména vykonávat všechna majetková práva k takovým autorským dílům jménem Objednatele a na jeho účet, postoupit právo výkonu těchto práv na třetí osobu, dokončit nehotové autorské dílo, a to i za účasti třetí osoby, a dále autorské dílo zveřejnit, zpracovávat, upravovat, překládat, spojovat s jinými díly, zařazovat do děl souborných, uvádět na veřejnosti pod svým jménem, a to vše i za účasti třetí osoby. Postoupení majetkových práv k autorským dílům podle předchozí věty tohoto ustanovení nenastane u autorských děl uvedených v seznamu, který bude součástí předávacího protokolu a u kterých Xxxxxxxxxx prokáže, že tato autorská díla byla vyvinuta nezávisle na plnění této smlouvy. K těmto autorským dílům poskytne Zhotovitel Objednateli časově neomezenou nevýhradní licenci k jejich užívání, a to ke všem způsobům užití a v rozsahu nezbytném k tomu, aby Objednatel mohl Dílo dle této Smlouvy užívat za účelem a způsobem uvedeným této Smlouvě.
5.3. V případě plnění Zhotovitele dle této Smlouvy, které nespadá pod plnění dle odstavce 5.1 této Smlouvy, které je autorským dílem dle autorského zákona a u kterého současně Zhotovitel nedisponuje právy umožňujícími postoupení práv dle odstavce 5.2 této Smlouvy, uděluje Zhotovitel Objednateli k okamžiku vytvoření příslušného plnění nevýhradní a nevypověditelnou licenci k užití takového autorského díla, a to za následujících podmínek:
a) Autorské dílo je možno užívat k libovolnému účelu, v množstevně neomezeném rozsahu, libovolným způsobem, po dobu trvání majetkových práv k autorskému dílu. Objednatel není povinen licenci využít. U počítačových programů se licence vztahuje na autorské dílo ve strojovém i zdrojovém kódu, a to včetně jeho dřívějších verzí a přípravných materiálů.
b) Autorské dílo lze upravovat, zapracovávat do dalších autorských děl, děl souborných a databází, a to i prostřednictvím třetích osob.
c) Součástí licence je právo licenci postoupit či udělit podlicenci.
Zhotovitel je oprávněn použít pouze takový software třetích stran, který je uveden v seznamu použitých SW knihoven v softwarových produktech Zhotovitele dle Přílohy č. 4 této Smlouvy.
5.4. Ke dni akceptace softwarového plnění (s výjimkou softwaru společnosti LS telcom AG) dle této Smlouvy je Zhotovitel povinen předat Objednateli úplné a komentované zdrojové kódy takového plnění; nepředání těchto zdrojových kódů vylučuje možnost akceptace takového plnění. Spolu se
zdrojovým kódem musí být předána podrobná dokumentace v souladu s Přílohou č. 6 této Smlouvy. Objednatel si je vědom toho, že mu budou předány i zdrojové kódy k softwarovému plnění Zhotovitele, příp. jeho poddodavatelů, kdy tyto byly vyvinuty nezávisle na plnění této Smlouvy, a tedy k nim Objednateli náleží pouze licence v souladu s odstavcem 5.2 této Smlouvy. Objednateli tyto kódy budou předány, ale zasahovat do nich, měnit je, upravovat či jinak s nimi nakládat může pouze za předpokladu, že se v části Díla tvořené těmito kódy vyskytne chyba nebo vada, a Zhotovitel ani jeho poddodavatel tuto chybu nebo vadu neodstraní nejpozději do 2 pracovních dnů od jejího nahlášení Zhotoviteli.
5.5. Strany se dále dohodly, že po dobu provádění Díla a dále po dobu záruční doby se Zhotovitel zavazuje předat Objednateli veškeré zdrojové kódy tak, jak definuje Příloha č. 8 této Smlouvy.
5.6. V případě, kdy při poskytování plnění podle této Smlouvy vznikne společnou činností Stran autorské dílo spoluautorů, postupuje Xxxxxxxxxx Objednateli k okamžiku vzniku takového autorského díla právo vykonávat majetková autorská práva k takovému autorskému dílu a uděluje mu souhlas ke změně nebo zásahu do takového autorského díla, a to bez nároku na jakoukoli dodatečnou odměnu na straně Zhotovitele. Pokud jde o systém mySPECTRA, nesmí docházet k žádným společným činnostem, které by vedly ke vzniku společných autorských práv smluvních stran a každá strana si ponechá práva duševního vlastnictví podle vlastního příspěvku; viz také Příloha č. 4 této Smlouvy.
6.2. V rámci záruky se Zhotovitel zavazuje zajistit, že Dílo a všechny jeho části jsou bez vad, zejména že odpovídají Smlouvě, výstupům Analýzy a Návrhu, že jsou vhodné pro použití za sjednaným účelem, mají sjednanou jakost a provedení a že nemají žádné právní vady.
6.3. Pokud se v záruční době projeví jakákoliv záruční vada Díla, Zhotovitel se ji zavazuje bezplatně opravit. Odstraňování vad se, v případě že mezi stranami existuje platná a účinná smlouva
o podpoře a údržbě, bude řídit takovou smlouvou. V případě, že však taková smlouva nebude vůbec uzavřena nebo pokud z důvodů na straně Zhotovitele Objednatel takovou smlouvu
o podpoře a údržbě ukončí (odstoupí od takové smlouvy), nahlašování a způsob opravování záručních vad včetně dob pro jejich vyřešení je upraven v Příloze č. 9 této Smlouvy.
7.1. Současně s touto Smlouvou Zhotovitel s Objednatelem uzavírá smlouvu o podpoře, údržbě a vývoji (dále také „Smlouva o podpoře a údržbě“).
7.2. Nejpozději do =30 dnů od zahájení Závěrečného ověření funkčnosti dle harmonogramu, Strany přehodnotí, jestli uzavřená Smlouva o podpoře a údržbě vyhovuje novým či upraveným vlastnostem Díla. Pokud dle názoru Objednatele došlo k takovým změnám Díla, které nebyly v době uzavření této Smlouvy známé či předvídatelné a tyto změny působily zvýšené nároky na podporu nebo údržbu Díla se Smluvní strany setkají a v dobré víře se dohodnou na úpravách Smlouvy o podpoře a údržbě tak, aby přiměřeně vyhovovala oprávněným potřebám Objednatele, za předpokladu že jsou strany schopné takto dohodnout bez nutnosti zásahu třetího subjektu. Pokud by taková změna zároveň způsobila zvýšené nároky na plnění Zhotovitele, je Zhotovitel oprávněn navrhnout přiměřenou úpravu ceny za poskytování služeb podpory a údržby.
8. ZPRACOVÁNÍ OSOBNÍCH ÚDAJŮ
8.1. Zpracování osobních údajů se řídí samostatnou smlouvou o zpracování osobních údajů.
9.1. Chráněné informace jsou veškeré neveřejné informace obchodní či technologické povahy včetně obchodního tajemství, které jsou jako důvěrné označeny a se kterými se Strany seznámily či seznámí, přímo či nepřímo, prostřednictvím písemného, či elektronického dokumentu. Chráněnými informacemi jsou mimo jiné obchodní tajemství, know-how, počítačové programy a principy jejich fungování, zdrojové a strojové kódy počítačových programů, datové soubory, algoritmy, návrhy architektury, Analýza, Návrh, jiné přípravné a koncepční materiály k Dílu, specifikace a popis Díla, pokyny a zadání k vývoji Díla atd. Důvěrné informace dále zahrnují informace sdílené mezi Stranami před datem účinnosti této Smlouvy, pokud by byly jinak považovány za důvěrné informace v souladu s touto definicí.
9.2. Každá ze Stran se zavazuje zachovávat mlčenlivost o všech chráněných informacích druhé Strany a používat je výlučně za účelem naplnění Smlouvy. Každá ze Stran vyvine největší možné úsilí, jaké po ní lze spravedlivě požadovat, aby nedošlo k úniku či zneužití chráněných informací (mimo jiné například dostatečným zabezpečením svých elektronických zařízení a komunikačních kanálů).
9.3. Povinnost mlčenlivosti se nevztahuje na případy, kdy Objednatel bude v souvislosti s provozem Díla projednávat související problematiku s příslušnými odbornými orgány či institucemi (např. Rada vlády pro informační společnost, resp. její orgány, Odbor hlavního architekta Ministerstva vnitra ČR, Národní úřad pro kybernetickou a informační bezpečnost). Objednatel je oprávněn poskytnout chráněné informace třetím stranám (s výjimkou státních dozorových institucí) pouze za předpokladu, že tyto byly dodány jako součást Exit plánu nebo jsou nezbytné pro zajištění Exitu. V takovém případě je Objednatel povinen předem písemně informovat o svém záměru poskytnout chráněné informace třetí straně Zhotovitele a poskytnout je třetí straně je oprávněn pouze v případě, že mu Zhotovitel ve lhůtě do =10 pracovních dnů od obdržení vyrozumění nenavrhne způsob, kterým lze Exit zajistit bez jejich poskytnutí a který zároveň pro Objednatele není časově nebo finančně náročnější. Tímto není dotčena úprava v odstavci 14.5 této Smlouvy. V ostatních případech je vždy třeba k předání chráněných informací předchozího písemného souhlasu Zhotovitele.
9.4. Povinnosti podle tohoto článku trvají po dobu trvání Smlouvy a dále =5 let ode dne jejího ukončení (není-li konkrétní chráněná informace týkající se Objednatele zveřejněna Objednatelem dříve).
10. SMLUVNÍ SANKCE
10.1. Veškeré doby a lhůty pro plnění jedné Strany se prodlužují o dobu, po kterou je druhá Strana v prodlení s poskytnutím předem písemně vyžádané součinnosti. Smluvní strany jsou však vždy povinny vynaložit veškeré úsilí k tomu, aby plnily v termínech předpokládaných Harmonogramem a touto Smlouvou. Pro vyloučení pochybností se sjednává, že za doby a lhůty pro poskytnutí součinnosti se považují, kromě předem písemně vyžádané součinnosti, též doby uvedené v odstavci 2.4 této Smlouvy a v Harmonogramu.
10.2. V případě prodlení Objednatele s úhradou ceny má Zhotovitel právo na sankční úrok z prodlení ve výši =0,05 % z nezaplacené splatné částky (bez DPH) za každý, byť jen započatý den prodlení, maximálně však do =10 % z nezaplacené splatné částky.
10.3. V případě prodlení Zhotovitele s provedením Díla má Objednatel právo na slevu z ceny Díla ve výši =0,05 % z ceny Díla (bez DPH), za každý, byť jen započatý den prodlení, maximálně však do =10 % z ceny Díla (bez DPH). Toto neplatí v případě, že Xxxxxxxxxx prokáže, že vina za vzniklé prodlení neleží na jeho straně. V případě odstoupení Objednatele od Smlouvy z důvodu prodlení Zhotovitele s provedením Díla náleží Objednateli namísto slevy z ceny Díla dle tohoto odstavce smluvní pokuta ve stejné výši za každý, byť jen započatý den prodlení, až do dne ukončení
Smlouvy, maximálně však do =10 % z ceny Díla (bez DPH). Toto neplatí v případě, že Xxxxxxxxxx prokáže, že vina za vzniklé prodlení neleží na jeho straně.
10.4. Zhotovitel je povinen zaplatit Objednateli smluvní pokutu ve výši:
a) =20 % z ceny Díla (bez DPH) za porušení kteréhokoliv ustanovení licenčních podmínek dle článku 5 či Přílohy č. 4 této Smlouvy, kdy toto porušení samostatně, nebo ve spojení s jinými znemožní Objednateli užívat Dílo (to znamená, že způsobí některý ze stavů blokující nebo kritické chyby dle Přílohy č. 9 této Smlouvy) a nebude možné tento stav jakkoliv napravit, a to výlučně bez vynaložení jakýchkoliv nákladů na straně Objednatele;
b) =0,0001 % z ceny Díla (bez DPH) za každý jednotlivý případ porušení Přílohy č. 2 této Smlouvy;
c) =0,001 % z ceny Díla (bez DPH) za každý jednotlivý případ porušení článku 6 této Smlouvy (záruční podmínky);
d) =5 % z ceny Díla (bez DPH), pokud poruší povinnost mlčenlivosti dle článku 9 této Smlouvy;
e) =0,001 % z ceny Díla (bez DPH) za každý jednotlivý den, po který porušuje povinnost mít sjednané a udržované vhodné pojištění dle článku 11 této Smlouvy;
f) =10 % z ceny Díla (bez DPH), pokud nesplní svůj závazek definovaný v Příloze č. 8 této Smlouvy;
g) =0,003 % z ceny Díla (bez DPH) za každý jednotlivý den ve kterém je Zhotovitel v prodlení s dodáním Exitového plánu nebo po který Objednatel nemá k dispozici funkcionalitu, která mu exporty dat uvedené v článku 14 této Smlouvy vytvoří;
h) =0,001 % z ceny Díla (bez DPH) za každý jednotlivý den, po který je v prodlení s plněním Milníků přesahujícím 20. pracovní den dle Harmonogramu s výjimkou prodlení se Dnem dokončení Díla;
i) =0,005 % z ceny Díla (bez DPH) za každý den prodlení se Dnem dokončení Díla přesahujícím 20. pracovní den;
j) 0,001 % z ceny Díla (bez DPH) za každý jednotlivý případ porušení povinnosti v oblasti ochrany osobních údajů a/nebo kybernetické bezpečnosti, přičemž pokud bude v oblasti ochrany osobních údajů či kyberbezpečnosti mezi stranami uzavřena smlouva, která bude stejné povinnosti krýt rovněž smluvními pokutami, bude sankce Zhotoviteli udělena jen podle jedné z těchto smluv (tzn. strany se dohodly, že je v takovém případě vyloučena dvojí sankce téhož porušení).
10.5. Objednatel je povinen zaplatit Zhotoviteli smluvní pokutu ve výši:
a) =5 % z ceny Díla (bez DPH) pokud poruší povinnost mlčenlivosti dle článku 9 této Smlouvy, maximálně však do =10 % z celkové ceny Díla (bez DPH);
b) =5 % z ceny Díla (bez DPH) za každý jednotlivý případ porušení kteréhokoliv ustanovení článku 5 této Smlouvy nebo Přílohy č. 4 této Smlouvy, které bude v rozporu s touto Smlouvou představovat podstatný zásah do autorských práv Xxxxxxxxxxx nebo jeho poddodavatelů, jejichž licenční podmínky jsou Objednateli ke dni uzavření této Smlouvy známy a byly přiloženy jako Příloha č. 4 této Smlouvy, maximálně však do =10 % z celkové ceny Díla (bez DPH).
10.6. Veškeré smluvní pokuty jsou splatné okamžikem porušení příslušné povinnosti. Uhrazení smluvní pokuty nevylučuje nárok na náhradu škody ve výši převyšující částku zaplacené smluvní pokuty.
10.7. Celková odpovědnost každé Strany za škodu způsobenou druhé Straně bez ohledu na její právní podstatu je omezena na náhradu částky, která v součtu všech takových škod včetně započtení smluvních pokut činí maximálně =100 % z celkové ceny Díla (bez DPH). Povinnost k náhradě majetkové újmy (škody) je rovněž vyloučena v případech nutné obrany, krajní nouze, liberačních důvodů (vyvinění) a vyšší moci, pokud nebylo možno vzniku takové újmy zabránit. Toto omezení se nevztahuje na případy úmrtní nebo zranění osob, jakož i na škody způsobené úmyslně nebo podvodem, nebo v případě odškodnění a náhrady škody, které nelze vyloučit na základě platných zákonů České republiky, které jsou pro plnění podle této Smlouvy závazné. Nelze uplatňovat náhradu majetkové újmy (škody) za to, co mohlo být uspokojeno v rámci nároků z odpovědnosti za vady.
10.8. Omezení odpovědnosti za škodu podle předchozího odstavce 10.7 této Smlouvy se neuplatní v případech, kdy je škoda způsobena přímo nebo v souvislosti s takovým výpadkem Systému (stavem blokující nebo kritické chyby podle kategorizace uvedené v Příloze č. 2 této Smlouvy), který trvá nepřetržitě po dobu delší než =72 hodin nebo v souhrnu více než =96 hodin v průběhu
=5 po sobě jdoucích pracovních dní.
11.2. Zhotovitel se zavazuje po celou dobu trvání Smlouvy nepožadovat žádné změny pojistných podmínek či jakkoliv zabránit v jakýchkoliv změnách pojistných podmínek (s výjimkou nezbytných změn, které musí být provedeny v důsledku změny právních předpisů), a to v obou případech k horšímu oproti stavu, který existuje ke dni uzavření této smlouvy. Zhotovitel se zavazuje informovat Objednatele o jakékoli změně v pojistných podmínkách a vztahu s pojistitelem nejpozději do 15 pracovních dnů.
11.3. Celková částka pojistného krytí Zhotovitele a jeho poddodavatele bude činit nejméně =100 % z celkové ceny Díla (bez DPH) při spoluúčasti nepřevyšující =2 %. Zhotovitel nesmí činit nic, co by zneplatnilo jakékoliv pojištění, nebo čím by bylo znemožněno, omezeno nebo zatíženo právem třetí osoby čerpání pojistného plnění v celku nebo po částech.
11.4. Ustanovení předcházejících odstavců 11.1 - 11.3 této Smlouvy neomezují závazky, odpovědnost nebo povinnosti Zhotovitele, které vznikly z jiných ustanovení Smlouvy.
12. VYŠŠÍ MOC
12.1. Strana, která způsobila škodu porušením splnění povinnosti ze Xxxxxxx, se zprostí odpovědnosti, prokáže-li, že jí ve splnění zabránila dočasně nebo trvale okolnost vyšší moci, jako mimořádná nepředvídatelná a neodvratitelná překážka, vzniklá nezávisle na její vůli, včetně jednání třetích osob, jako stávka, občanské nepokoje, válečná událost, teroristický útok, požár, výpadek komunikačních sítí, výpadek dodávky energií, nedostatek surovin nebo pracovních sil, přírodní katastrofa, rozhodnutí orgánů státní moci a správy, odlišných od Objednatele. Zproštění z důvodu nepředvídatelné a neodvratitelné překážky se použije i u mimosmluvní odpovědnosti v případech uvedených v zákoně.
12.2. Aby se předešlo pochybnostem, smluvní strany z opatrnosti tímto prohlašují – pro případ, že vzniklá epidemie COVID-19 (krize korony) a její vývoj budou mít do budoucna nepříznivý vliv na možnost řádného plnění smluvních závazků – že takový stav budou posuzovat a společně řešit. Strany se mohou v konkrétním případě dohodnout na odpovídajícím posunu všech dotčených Milníků uvedených v Harmonogramu včetně Dne dokončení Díla, a vyloučení nároku na úhradu vzniklých škod a smluvních pokut, a to bez zbytečného odkladu poté, kdy nastane, nebo kdy bude možné důvodně očekávat, že nastane.
13. UKONČENÍ SMLOUVY
13.1. Od Smlouvy lze odstoupit pro její podstatné porušení způsobené druhou Stranou.
13.2. Podstatným porušením Smlouvy na straně Zhotovitele se rozumí zejména:
a) pokud je Zhotovitel v prodlení s provedením Díla nebo jeho části ve sjednaném termínu, přestože jej na to Objednatel opakovaně (nejméně 2x) písemně upozornil a poskytl mu v součtu alespoň =90 dní ke zjednání nápravy (alespoň 20 dní v rámci každého upozornění);
b) opakované porušení závazku mlčenlivosti dle článku 9 této Smlouvy Zhotovitelem; nebo
c) porušení kteréhokoliv ustanovení článku 5 či Přílohy č. 4 této Smlouvy, jehož porušení samostatně, nebo ve spojení s jinými znemožní Objednateli užívat Dílo, Dílo upravovat, opravovat, měnit, spojovat s jiným, nebo ho jinak omezí ve způsobu užívání či nakládání s Dílem (v rozsahu článku 5 a Přílohy č. 4 této Smlouvy) a nebude možné tento stav jakkoliv napravit bez vynaložení jakýchkoliv nákladů na straně Objednatele.
13.3. Objednatel je dále oprávněn odstoupit od Smlouvy, pokud:
a) bylo vydáno pravomocné rozhodnutí o úpadku Xxxxxxxxxxx nebo bylo zahájeno insolvenční řízení proti Xxxxxxxxxxx na jeho návrh, nebo v případě, že soud pravomocně rozhodl o zrušení Zhotovitele a nařídil jeho likvidaci, nebo Xxxxxxxxxx přijme rozhodnutí o vstupu do likvidace; nebo
b) dojde k významné změně kontroly nad Zhotovitelem, přičemž kontrolou se rozumí vliv, ovládání či řízení dle zákona č. 90/2012 Sb., o obchodních korporacích, ve znění pozdějších předpisů, či ekvivalentní postavení.
13.4. V případě odstoupení Objednatele je Objednatel oprávněn odstoupit od Xxxxxxx podle svého uvážení buď v celém jejím rozsahu nebo pouze v části týkající se plnění, které nebylo k datu odstoupení od Xxxxxxx dokončeno nebo předáno, nebo u kterého nebyly odstraněny všechny vady bránící užívání Díla a má právo na náhradu škody tím vzniklé.
13.5. Podstatným porušením na straně Objednatele na základě, kterého je Zhotovitel oprávněn odstoupit od Smlouvy se rozumí:
a) prodlení s úhradou oprávněně vyúčtované ceny nebo její části ve sjednaném termínu, přestože jej na to Zhotovitel opakovaně (nejméně 2x) písemně upozornil a poskytl mu v součtu alespoň =90 dní ke zjednání nápravy (alespoň 20 dní v rámci každého upozornění); nebo
b) opakované porušení závazku mlčenlivosti dle článku 9 této Smlouvy Objednatelem; nebo
c) prodlení Objednatele v poskytování součinnosti ve sjednaném termínu, přestože jej na to Objednatel písemně opakovaně upozornil a celková doba kumulativního prodlení činí více jak =90 pracovních dní za dobu trvání smlouvy;
d) opakované porušování kteréhokoliv ustanovení článku 5 této Smlouvy nebo Přílohy č. 4 této Smlouvy (licenční podmínky), které bude představovat podstatný zásah do autorských práv Zhotovitele nebo jeho poddodavatelů, jejichž licenční podmínky jsou Objednateli ke dni uzavření této Smlouvy známy a byly přiloženy jako Příloha č. 4 této Smlouvy za předpokladu, že ani po písemném specifickém upozornění ze strany Zhotovitele nebude ze strany Objednatele ve lhůtě 90 dnů od doručení specifického upozornění sjednána náprava a nebude od takového porušování upuštěno.
13.6. Namísto odstoupení od Xxxxxxx může Objednatel dočasně přerušit plnění svých povinností dle Xxxxxxx do doby, než dojde k nápravě u Zhotovitele, aniž by to pro Objednatele mělo jakékoliv nepříznivé dopady, a aniž by mu tím vznikla povinnost hradit Zhotoviteli jakoukoliv škodu.
13.7. Objednatel má kdykoliv po dobu trvání této Smlouvy právo požádat Zhotovitele o přerušení prací na Díle z důvodu, kdy k takovému přerušení dostane pokyn nadřízeného orgánu státní správy, soudu nebo kdy dojde ke změně zákonů, které budou mít na Dílo vliv. V takovém případě se veškeré lhůty pro Objednatele i pro Zhotovitele staví a Strany vstoupí v jednání o změně ceny a harmonogramu Díla.
13.8. V případě odstoupení Objednatele od Smlouvy nemá Zhotovitel nárok na cenu, která se váže k dosud nedokončeným částem Díla dle této Smlouvy nebo takovým plněním, které jsou důvodem odstoupení Objednatele od Smlouvy. V případě, že k odstoupení Objednatele dojde po zaplacení ceny, je Zhotovitel povinen vrátit Objednateli její část, která se váže k části Díla, která je důvodem odstoupení. Objednatel je povinen vrátit Zhotoviteli část Díla, která nebyla zaplacena.
13.9. Objednatel je dále oprávněn písemně vypovědět tuto Smlouvu s okamžitou účinností (bez výpovědní doby), lze-li ze všech skutečností zjištěných v rámci řádné péče Objednatele o plnění podmínek této Smlouvy důvodně usuzovat, že hrozí riziko prodlení Zhotovitele s plněním jeho závazků dle této Smlouvy, přičemž toto prodlení může představovat z hlediska významu pro Objednatele a/nebo významu pro provádění Díla dle této Smlouvy (na základě uvážení, které přísluší výlučně Objednateli) významnou okolnost. Za významnou okolnost se považuje zejména prodlení se splněním označených Milníků dle Harmonogramu o více než 90 pracovních dnů a Zhotovitel přitom nebude schopen prokázat, že se jedná o důsledek objektivních okolností nebo se jedná o záměr Zhotovitele z důvodu volby vhodnějšího pořadí jednotlivých činností a dále dlužnický insolvenční návrh či pravomocné rozhodnutí o úpadku Zhotovitele. Při posuzování míry závažnosti těchto skutečností vezme Objednatel v úvahu zejména, nikoli však výlučně, riziko, jež případné prodlení při provádění Díla může znamenat pro termín dokončení Díla, rychlost a kvalitu provádění Díla při průměrných cenách vývojářských a jiných souvisejících prací zohledňujících relevantní trh, běžnou pracovní dobu a Zhotovitelem užívaný software.
13.10.Zánik Smlouvy nemá vliv na trvání následujících práv a povinností Stran ze Smlouvy: nároky na náhradu škody, zaplacení úroků z prodlení a smluvních pokut sjednaných pro případ porušení smluvních povinností, ujednání o zajištění závazků, mlčenlivost, licenční ujednání a ty závazky Stran, které podle Smlouvy nebo vzhledem ke své povaze mají trvat i nadále nebo u kterých tak stanoví zákon (jako např. ustanovení Smlouvy týkající se Zádržného a bankovní záruky nebo odstraňování vad).
13.11.Dojde-li k odstoupení od této Smlouvy ze strany Objednatele v souladu s tímto článkem Smlouvy, je Zhotovitel povinen uhradit nad rámec smluvních pokut uvedených v článku 10 této Smlouvy také jednorázovou smluvní pokutu ve výši 20.000.000 Kč. Pro vyloučení pochybností, Zhotovitel není povinen uhradit tuto smluvní pokutu v případě, že Objednatel odstoupí od Zpracovatelské smlouvy.
14. EXIT
14.1. Na žádost Objednatele učiněnou nejpozději do =6 měsíců ode dne skončení této Smlouvy poskytne Zhotovitel Objednateli veškerou nezbytnou součinnost, informace, dokumentaci a data ze Systému a bude se účastnit všech jednání s Objednatelem a třetími osobami určenými Objednatelem, to vše za účelem hladkého převodu všech činností Zhotovitele spojených poskytováním Služeb na Objednatele či třetí osobu určenou Objednatelem, a takový převod zajistí (dále jen „Exit“), a to způsobem a v rozsahu dle Exitového plánu definovaného v odstavcích 14.2 a 14.3 této Smlouvy.
14.2. Za účelem umožnění realizace Exitu připraví Zhotovitel jako součást Návrhu plán popisující postup provedení Exitu (dále také „Exitový plán“). Strany předpokládají, že Exitový plán bude zpřesňován následnou dohodou Stran a aktualizován v průběhu provádění Díla. Exitový plán a jeho další verze budou akceptovány za přiměřeného užití Přílohy č. 2 této Smlouvy. Cena za vytvoření a další aktualizace Exitového plánu je zahrnuta v ceně Díla.
14.3. Veškeré činnosti, které bude Zhotovitel provádět a Objednatel bude požadovat po Zhotoviteli v rámci povinností definovaných článkem 14 této Smlouvy budou v souladu s ustanoveními článku 5 této Smlouvy a Přílohy č. 4 této Smlouvy. Objednatel bere na vědomí a souhlasí s tím, že nebude po Zhotoviteli i požadovat plnění, které by bylo v rozporu s ustanoveními Přílohy č. 4 této Smlouvy.
14.4. Součástí Exitu bude:
a) poskytnutí odborného školení osobám určeným Objednatelem v rozsahu 20 hodin, na kterém Zhotovitel určeným osobám zejména (i) předá přístup k infrastruktuře, na které je Systém provozován, včetně všech přístupových údajů, hesel a kódů, (ii) předá přístup do všech administrátorských rozhraní Systému a vysvětlí, k čemu slouží a jaké mají funkce, (iii) popíše obsah veškeré písemné dokumentace, vzniklé v souvislosti s poskytováním Služeb která byla nebo má být předána Objednateli a vysvětlí, k čemu slouží a jak s ní dále pracovat, (iv) popíše architekturu počítačových programů vytvořených na základě této Smlouvy a vysvětlí vazby mezi jejich částmi, (v) pomůže navázat na jakoukoliv nedokončenou Službu (nebyla-li provedena) tím, že zdokumentuje její aktuální stav. V případě, že rozsah uvedený v tomto odstavci překročí 20 hodin, bude každá následující hodina účtována cenou dle odstavce 3.2 této Smlouvy.
b) poskytnutí podmínek pro:
⮚ možnost migrace dat z mySPECTRA do otevřeného XML formátu navrženého Zhotovitelem nebo kontinuálně dostupných databázových pohledů navržených Zhotovitelem včetně vazeb mezi daty,
⮚ možnost zajištění podpory té části díla, která bude vyvinuta pro potřeby Objednatele v souladu s licenčními podmínkami, které jsou uvedeny v Příloze č. 4 této Smlouvy (Licenční podmínky), jiným poskytovatelem (třetí osobou).
Součástí zpracovaného Exit plánu bude dokumentace obsahující:
⮚ dokumentace struktury dat otevřeného XML formátu nebo kontinuálně dostupných databázových pohledů, včetně významu jednotlivých atributů a zachování vazeb,
⮚ popis aplikační logiky nad daty, která jsou v otevřeném XML formátu nebo kontinuálně dostupných databázových pohledech kódována a vyžadují programový kód pro správnou interpretaci.
Zpracovaný Exit plán musí zajišťovat přístup ke kompletnímu aktuálnímu exportu dat Systému, a to následujícími dvěma způsoby:
⮚ přes kontinuálně dostupné databázové pohledy zpřístupňující veškerá data vložená zaměstnanci Objednatele a výsledky výpočtů provedených Systémem, zejména data o vydaných oprávněních k užívání rádiových kmitočtů, jejich držitelích, data vysílacích stanovišť a zařízení. Tyto pohledy budou plně zdokumentovány tak, aby byla všechna data správně identifikována;
⮚ export dat Systému vložených zaměstnanci Objednatele a výsledky výpočtů provedených Systémem, zejména data o vydaných oprávněních k užívání rádiových kmitočtů, jejich držitelích, data vysílacích stanovišť a zařízení v otevřeném XML formátu s popisem jeho struktury a vazeb;
⮚ Objednatel bude mít k dispozici funkcionalitu, která mu výše uvedené exporty dat vytvoří, tato funkcionalita bude Zhotovitelem Objednateli dána k dispozici nejpozději od okamžiku provádění FAT, bez této funkcionality nemůže dojít k akceptaci Díla ve FAT.
14.5. Pokud v rámci Exit plánu nebo vlastního Exitu budou použity za účelem pochopení formátu extrahovaných/exportovaných dat jakékoli podrobné informace o interní databázové struktuře systému mySPECTRA, pak tyto informace jsou a zůstávají duševním vlastnictvím společnosti LS telcom AG. Tyto informace smí být použity pouze za účelem pochopení formátu extrahovaných/exportovaných dat a Objednatel s nimi musí striktně nakládat jako s důvěrnými. Objednatel je také povinen smluvně zavázat nového poskytovatele služeb ke stejným povinnostem týkajícím se povoleného použití a důvěrnosti těchto informací.
15. KOMUNIKACE
15.1. Jakékoliv oznámení Stran podle této Smlouvy bude mít právní účinky, pokud je druhé Straně doručeno v písemné formě doporučeným dopisem na adresu jejího sídla nebo elektronicky do její datové schránky.
16. ZÁVĚREČNÁ UJEDNÁNÍ
16.1. Všechny právní vztahy mezi Stranami související se Smlouvou se řídí českým právem.
16.2. V případě rozporu mezi jednotlivými Smluvními dokumenty se uplatní v následujícím pořadí (přičemž a) má nejvyšší prioritu a e) se použije jako poslední):
a) Smlouva
b) přílohy Smlouvy
c) akceptovaná Analýza
d) akceptovaný Návrh.
16.3. Smlouva nahrazuje veškerá předchozí ústní nebo písemná ujednání stran vztahující se k předmětu Xxxxxxx. V případě rozporu mezi tělem Xxxxxxx a jejími přílohami má přednost tělo Xxxxxxx.
16.4. Strany vylučují použití obchodních zvyklostí podle § 558 odst. 2 zákona č. 89/2012 Sb., občanského zákoníku, ve znění pozdějších předpisů, s výjimkou těch, které si výslovně dohodly ve smlouvě. Strany na sebe přebírají nebezpečí změny okolností ve smyslu § 1765 odst. 2 občanského zákoníku, zavazují se však, pokud to alespoň jedna z nich bude považovat za nutné, jednat v dobré víře za účelem nalezení řešení změny okolností.
16.5. Zhotovitel není oprávněn započíst vůči Objednateli žádný nárok, právo či pohledávku vyplývající ze Smlouvy ani postoupit Smlouvu nebo jakoukoliv její část bez předchozího písemného souhlasu Objednatele.
16.6. Objednatel není oprávněn započíst vůči Zhotoviteli žádný nárok, právo či pohledávku vyplývající ze Smlouvy ani postoupit Smlouvu nebo jakoukoliv její část bez předchozího písemného souhlasu Zhotovitele. Objednatel je však oprávněn započíst svůj nárok na zaplacení smluvní pokuty na platbu ceny podle této Smlouvy bez předchozího souhlasu Zhotovitele.
16.7. Neplatnost, neúčinnost, zdánlivost či nevymahatelnost jakékoliv části Smlouvy nemá vliv na zbývající části smlouvy. Strany se zavazují nahradit jakoukoliv neplatnou, neúčinnou, zdánlivou či nevymahatelnou část smlouvy částí platnou, účinnou, nikoliv zdánlivou a vymahatelnou se stejným obchodním a právním významem do 14 dnů ode dne, kdy obdrží žádost od druhé Strany.
16.8. Selhání nebo opomenutí kterékoliv Xxxxxx vymáhat jakákoliv svá práva ze Smlouvy nebude považováno za vzdání se těchto práv do budoucna a nezakládá zavedenou praxi mezi stranami.
16.9. Veškeré změny a doplňky Smlouvy musí být provedeny v písemné formě a podepsány oběma Stranami.
16.10.Xxxxxxx je vyhotovena ve 3 stejnopisech – dva pro Objednatele, jeden pro Zhotovitele. Současně bude vytvořena elektronická podoba smlouvy s elektronickými podpisy. Tato smlouva vzniká dnem podpisu oprávněnými zástupci obou smluvních stran a nabývá účinnosti uveřejněním této smlouvy podle zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv), ve znění pozdějších předpisů. Uveřejnění zajistí Objednatel.
16.11.Seznam Příloh:
• Příloha č. 1 - Jednotný katalog požadavků (Katalog)
• Příloha č. 2 - Akceptační řízení
• Příloha č. 3 - Časový harmonogram plnění
• Příloha č. 4 - Licenční podmínky:
- LS telcom AG, Německo – Licenční ujednání s koncovým uživatelem systému mySPECTRA pro regulační orgány (EULA)
- mySPECTRA – Knihovny třetích stran v systému mySPECTRA – LS telcom AG
- TECHNISERV, spol. s r.o. - Seznam SW licencí třetích stran
• Příloha č. 5 - Seznam poddodavatelů
• Příloha č. 6 - Definice výstupů a akceptačních kritérií
• Příloha č. 7 - Pojistný certifikát
• Příloha č. 8 - Závazek Zhotovitele k poskytnutí zdrojových kódů
• Příloha č. 9 - Kategorizace incidentů a lhůty pro reakci a vyřešení.
NÁSLEDUJE PODPISOVÁ STRANA
V Praze dne
23.08.2021
V Praze dne
25.08.2021
……………………………....................……… ……………………………....................……… Xxx. Xxx. Xxxx Xxxxxxxxx Xxx. Xxxxxxxx Xxxxxxxx, Ph.D.
předsedkyně Rady jednatel
Českého telekomunikačního úřadu
Jednotný katalog požadavků na inovaci systému SPECTRA v prostředí Objednatele
Verze 9.7
Datum: 16. 8. 2021
Historie verzí
Verze Datum Autor Popis | |||||||||
1.0 | 14. 9. 2020 | Iniciální vytvoření dokumentu | |||||||
1.1 | 16. 9. 2020 | Tabulka požadavků – Požadavky – „Tabulka verze 7“ doplněna o sledování průběhu jednání (po konzultaci s ), upraveny strojové překlady z angličtiny | |||||||
1.2 | 21. 9. 2020 | Komentáře ČTÚ | |||||||
2.0 | 28. 9. 2020 | Vypořádání komentářů ČTÚ, doplnění akčních bodů k jednotlivým požadavkům | |||||||
3.0 | 6. 10. 2020 | Aktualizace požadavků dle akčních bodů od ČTÚ | |||||||
3.1 | 7.10.2020 | Doplněny komentáře ČTÚ k pre-final verzi | |||||||
4.0 | 7.10.2020 | Pre-final verze dokumentu JKP | |||||||
5.0 | 8.10.2020 | Drobné úpravy, FINAL CZ verze | |||||||
5.1 | 12.10.2020 | Drobné opravy, opravy překlepů | |||||||
6.0 | 18.11.2020 | Zapracování odpovědí LST dodaných v rámci Akčních bodů, rozdělení požadavků na část „Znění požadavku“ a „Vyjádření Zhotovitele“ | |||||||
7.0 | 19.11.2020 | Zapracování odpovědí LST jako „Vyjádření Zhotovitele“. Kde je shoda, uvedeno „Potvrzení Zhotovitele“. | |||||||
7.1 | 20.11.2020 | Revize zapracování revizí | |||||||
7.2 | 23.11.2020 | Revize | zapracování revizí | ||||||
8.0 | 23.11.2020 | Uzavření všech otevřených požadavků. Převedeno do podoby smluvní dokumentace. | |||||||
9.0 | 24.2.2021 | Přesun kapitol Vyjádření Zhotovitele do podoby předpokládaného způsobu realizace v rámci znění požadavku. | |||||||
9.1 | 24.2.2021 | Průběžné přijímání změn z verze 9.0 a stylistické úpravy. | |||||||
9.2 | 25.2.2021 | Přesun kapitol Vyjádření Zhotovitele do podoby předpokládaného způsobu realizace v rámci znění požadavku. | |||||||
9.3 | 25.2.2021 | Průběžné přijímání změn z verze 9.0 a stylistické úpravy. | |||||||
9.4 | 11.3.2021 | Přesun kapitol Vyjádření Zhotovitele do podoby předpokládaného způsobu realizace v rámci znění požadavku. Přijetí změn. | |||
9.5 | 12.3.2021 | Čištění dokumentu vč. navrácení a úpravy části týkající se integrace s webovým portálem. | |||
9.6 | 26.7.2021 | Revize a doplnění požadavku na Účetní systém. | |||
9.7 | 16.8.2021 | ČTÚ | Revize | ||
Obsah
1. Modernizace stávajícího systému SPECTRAplus 8
2. Modernizace stávajícího systému SPECTRAplus – GUI 11
4. Provedení detailní analýzy požadavků objednavatele 12
5. Vytvoření analytické a návrhové dokumentace 12
6. Oprava datových struktur pro všechny radiokomunikační služby 13
7. Implementace a konfigurace systému 13
8. SPECTRAemc a CHIRplus_BC 13
10. Ginis, LJIP, Základní registry (SKS), účetní systém, rozhraní na budoucí webový portál 14
12. SPECTRAexchange essential 21
Požadavky související s IO či správním rozhodnutím obecně 21
13. Rozlišení verze správního rozhodnutí 21
14. Evidovat osobu držitele IO včetně kompletní historie 23
15. Evidovat datum nabytí právní moci u IO 23
Tisky/export IO či správního rozhodnutí 24
16. Inovovat funkcionality tisku IO 24
17. Zlepšit UI pro tisk oprávnění 24
18. Zrušit omezení na počet znaků 25
19. Umožnit vyhledávání a kategorizace textů v tiskových sestavách 26
20. Zachovat vazbu tisku na IO 26
21. Správa tiskových sestavy 26
23. Umožnit digitální podpis a časové razítko 27
24. Odeslání prostřednictvím GINIS 27
25. Zachovat kartotéku textů tisku IO 28
Open data/zveřejnění údajů na webu Objednatele 28
26. Umožnit export do CSV a XLSX 28
27. Umožnit označení dat jako neveřejné 29
28. Umožnit zveřejnění dat na webu Objednatele 29
Implementace workflow správního řízení u žádosti 30
29. Implementovat workflow u procesů správy rádiového spektra 30
30. Umožnit administrátorům Objednatele provádět změny workflow při výjimkách 30
31. Umožnit uložení rozpracované žádosti 31
33. Validovat zadávané údaje 32
34. Integrovat odesílací funkcionalitu s elektronickým vzorem 32
35. Validovat žádost dle SPECTRAplan 33
36. Validovat přidělování volacích značek 33
37. Validovat platnosti IO – dobu platnosti, držitele, žadatele a licence RRTV 34
38. Umožnit opravy po výpočtu ročního poplatku 34
39. Umožnit propojení se správním poplatkem 35
40. Uživatelská přívětivost rozhraní a workflow 36
41. Umožnit přidání Ad-hoc rozhodnutí k IO 36
42. Zajistit ošetření záznamů mezinárodní koordinace 36
43. V modulu SPECTRAemc umožnit automatizaci provedení wizardů 37
44. Umožnit UNDO a doplnění poznámky u archivovaných IO 37
Implementace algoritmu pro výpočet ročního poplatku a správního poplatku 37
45. Zajistit soulad s nařízením vlády č. 154/2005 Sb 37
46. Ve workflow zadefinovat pozici výpočtu ročního poplatku 38
47. Umožnit konfiguraci výpočtu ročního poplatku administrátorským zásahem 38
48. Umožnit uživateli přístup k vypočtenému ročnímu poplatku 38
49. Zajistit vyhodnocení a propojení správního poplatku s IO systémem 38
Podpora číselníků volacích značek 39
50. Vytvořit číselníky přidělených volacích značek 39
51. Automaticky generovat ATIS a MMSI kódy 39
Zachování číselníků a kartoték 40
52. Zachovat stávající číselníky a kartotéky (Rádiová zařízení, Antény, Stanoviště, Adresy) 40
53. Umožnit evidenci nájemce IO 40
54. Zajistit školení uživatelů 40
Dokumentace inovovaného systému 41
55. Dodat dokumentaci inovovaného systému 41
56. Umožnit uložit více druhů vysílání u rádiového zařízení 41
57. Plnohodnotně nahradit stávající nástroj Vykuk 41
58. Umožnit správu rádiových kmitočtů pro vojenské účely 41
59. Zajistit evidenci přídělů rádiových kmitočtů 42
60. Zajistit evidenci a vystavování souhlasů zahraničních ambasád 43
61. Logovat změny existujících záznamů v databázi 43
62. Zajistit Early Life Support / On-site Support 43
64. Výběr kmitočtů mimo rastr 44
65. Import/Export v ostatních službách 44
66. Řešení problematiky průkazů odborné způsobilosti pro amatérskou službu 44
67. Zpracování žádostí RRTV pomocí workflow 45
Příloha 1 – Statistika spouštění činností/akcí ve SPECTRAplus za posledních 20 let užívání 46
Úvod
Účel dokumentu
Tento dokument vznikl za účelem sjednocení požadavků Objednatele na inovaci systému SPECTRA na inovovaný systém a zároveň jejich provázání s nabízeným řešením spol. LS telcom a subdodavatelů Zhotovitele. Naplnění uvedených požadavků je očekávaným výstupem projektu inovace systému SPECTRA v prostředí Objednatele.
Dále se očekává, že žádná operace v inovovaném systému nebude složitější nebo časově náročnější než ve stávajícím systému SPECTRAplus.
Tento dokument také popisuje požadavky na různých úrovních detailu s důrazem na detailnější popis složitějších požadavků a dále diferenční popis požadavků nad rámec současného řešení v systému SPECTRAplus. Jinými slovy: obecně je požadováno, aby nový systém umožňoval funkce, které Objednatel využívá v současném systému SPECTRAplus. Dokument se tímto obecným požadavkem zaobírá pouze v odůvodněných případech. Hlavním účelem dokumentu je definovat požadavky na nové funkce a definovat požadavky na úpravy existujících funkcí.
Každý požadavek je členěn na část Znění požadavku a Předpokládaný způsob realizace. V části
Předpokládaný způsob realizace je pak požadavek, příp. jeho část blíže rozpracován. Části požadavků, které nejsou blíže rozpracovány v části Předpokládaný způsob realizace, budou rozpracovány až
během tvorby analytických dokumentů.
Členění uvedené v předchozím odstavci se nevztahuje na požadavek č. 10 Ginis, LJIP, Základní registry (SKS), účetní systém, rozhraní na budoucí webový portál, část webový portál, kde je požadavek popsán v širším kontextu budoucího webového portálu. Předmětem realizace bude
seznam funkcionalit uvedený v části Předpokládaný způsob realizace rozhraní na budoucí webový portál.
Ke zpřesnění níže uvedených požadavků dojde během tvorby analytických dokumentů.
Pozn.: přesto, že se v textu objevují kromě pojmu „inovovaný systém“ dále pojmy „mySPECTRA, mySPECTRoffice“, je možné tyto SW části považovat za součást inovovaného systému.
Zdroje informací
Zdrojem jsou tyto dokumenty:
1. Studie proveditelnosti inovace SW nástroje SPECTRA.pdf ve verzi Final ze 14. prosince 2015 (česká verze). Vzhledem k časovému odstupu a změně finančního rámce vůči vzniku tohoto dokumentu do současnosti, slouží tento dokument pouze jako ideový základ generační obměny systému SPECTRA.
2. Annex 3. Studie proveditelnosti inovace SW nástroje SPECTRA_2.0 (verze z 14.12)_EN.doc
(anglická verze). Shodný dokument s bodem 1) jen v anglické jazykové mutaci.
3. Seznam_verze7 [2].xlsx (česká verze), aktualizovaný seznam požadavků ČTÚ na inovaci systému SPECTRA, vyčleněny pouze povinné požadavky typu „must have“.
4. 20200616_Seznam_ver8A_r1.xlsx (anglická verze), shodný dokument s bodem 3)jen
v anglické jazykové mutaci
5. Annex III. CTO_mySPECTRA_system_specification.xlsx (anglická verze), reakce spol. LS telcom na dokument 20200616_Seznam_ver8A_r1.xlsx (viz bod 4)). Dále používáno:
„Annex III. CTO mySPECTRA system specification“.
6. Odpovědi na seznam akčních bodů spol. LS telcom – MySPECTRA – Requirements Catalogue - Action points_LST_v0.4.docx
Požadavky
1. Modernizace stávajícího systému SPECTRAplus
Znění požadavku
Nahradit stávající způsob zadávání údajů žádosti do databáze SPECTRAplus novým moderním,
responzivním, uživatelsky přívětivým přístupem, kdy vzhled, obsah, výčet polí a závislost mezi těmito poli pro jednotlivé radiokomunikační služby bude definován Objednatelem. Cílem je redukce stávajícího systému na funkce/vstupní pole používané Objednatelem. Pro upřesnění, záměrem
realizace není úplné přepracování prostředí mySPECTRA GUI (UI & UX). Přesná podoba, obsah, výčet polí a závislost polí bude upřesněna v rámci detailní analýzy požadavků. Cílem je také formálně
rozlišit zadávání údajů na administrativní (držitel IO, číslo jednací, poznámka apod.) a technickou část (vysílací rádiové zařízení, volací značka, kmitočty a další).
Vytvořit nové formuláře pro zadávání / editaci dat a řízení workflow v těchto službách a jejich
podslužbách:
• Ama – jednotlivci
• Ama – klubové stanice
• Ama – neobsluhované stanice
• Družicová – SNG, VSAT, Pozemské stanice
• Letecká pohyblivá – pozemní stanice
• Letecká pohyblivá – letadlová stanice
• Námořní – pobřežní stanice
• Námořní – lodní stanice
• Rozhlasová – AM
• Rozhlasová – FM
• Rozhlasová – DAB
• Rozhlasová – DVB-T, DVB-T2
• Jiné služby – Radiolokace
• Pevná služba – PP
• Pevná služba – PMP
• Pozemní pohyblivá služba (PPS)
• Kombinované krátkodobé oprávnění, které mohou kombinovat frekvence určené pro PPS a PS
Pro kombinované krátkodobé oprávnění platí:
• Počet případů ročně < 50
• Technická analýza frekvencí PS nebude provedena v systému SPECTRA / SPECTRAemc ->
nutnost ručního zadání frekvence do workflow oprávnění. Toto téma se týká také tématu
„dynamického rastru“. Frekvence jsou uloženy v PPS – Land Mobile Station
• Tisk PPS bude zachován
Uživatel musí mít přehled, jaká IO byla udělena a to s možností filtrovat a vyhledávat pomocí definovaných polí (např. číslo jednací, držitel, typ oprávnění (NOVÉ, PRODLOUŽENÍ apod., doba platnosti, roční poplatek apod.).
Kromě formulářů pro zadávání nebo opravu dat je třeba, aby nový systém umožňoval akce, které Objednatel využívá v současné SPECTRAplus. V tuto chvíli nedochází k definici, které akce se stanou součástí nějakého workflow. Jde pouze o informaci, jaké akce jsou reálně využívány, a je velmi
pravděpodobné, že v nějaké podobě budou potřeba i nadále.
Inovovaný systém, z pohledu žadatele/držitele IO zachová možnost importu ze ZFO formulářů (náhrada ZFO Migration tool) a stávajícího XML.
Statistika spuštěných akcí v systému SPECTRAplus za celou dobu používání u Objednatele je uvedena v Příloze 1 – Statistika spouštění činností/akcí ve SPECTRAplus za posledních 20 let užívání.
(Viz kapitola Přílohy.)
Inovovaný systém bude lokalizovaný do češtiny. Na straně Objednatele bude umožněna správa vytvořené české lokalizace. Administrátor může upravovat české překlady, provádět překlad zatím nepřeložených textů (např. nové texty po upgrade).
Předpokládaný způsob realizace
Existující GUI SPECTRAplus bude nahrazeno moderním a uživatelsky přívětivým GUI
mySPECTRAoffice, který je vytvořen jako nativní webová aplikace. Tato aplikace je vyvinuta
s použitím nejnovějších webových technologií (např. HTML 5), které nabízejí vysokou použitelnost
a nezávislost na použitém operačním systému. Za pomocí responzivního webového designu je GUI přizpůspobeno pro použití v moderních webových prohlížečích – budou použity Mozilla Firefox nebo Google Chrome – a to na různých typech zařízeních – v desktopových sestavách, noteboocích,
tabletech či mobilních telefonech.
Vzhled GUI bude založen na standardních datových položkách mySPECTRAoffice, ať už se bude jednat o obsah, seznam polí datových položek nebo o závislosti datových položek, a to pro každou rádiovou službu. Formuláře pro vstupní datové položky budou upraveny dle aktuálních datových položek
užívaných Objednatele. Obsah, seznam datových polí a jejich závislostí bude specifikován v detailní analýze požadavků. Datové vstupy budou formálně rozděleny mezi administrativní část (držitel
licence / žadatel, číslo jednací, poznámka, atd.) a mezi část technickou (data vysílacího zařízení, volací značky, frekvence, atd.).
Pro datové vstupy, editaci dat a kontrolu workflow budou poskytnuty následující služby a jejich
podslužby:
• Ama – jednotlivci
• Ama – klubové stanice
• Ama – neobsluhované stanice
• Družicová – SNG, VSAT, Pozemské stanice
• Letecká pohyblivá – pozemní stanice
• Letecká pohyblivá – letadlová stanice
• Námořní – pobřežní stanice
• Námořní – lodní stanice
• Rozhlasová – AM
• Rozhlasová – FM
• Rozhlasová – DAB
• Rozhlasová – DVB-T, DVB-T2
• Jiné služby – Radiolokace
• Pevná služba – PP
• Pevná služba – PMP
• Pozemní pohyblivá služba (PPS)
• Kombinované krátkodobé oprávnění, které mohou kombinovat frekvence určené pro PPS a
PS
Pro kombinované krátkodobé oprávnění platí:
• Počet případů ročně < 50
• Technická analýza frekvencí PS nebude provedena v systému SPECTRA / SPECTRAemc ->
nutnost ručního zadání frekvence do workflow oprávnění. Toto téma se týká také tématu
„dynamického rastru“. Frekvence jsou uloženy v PPS – Land Mobile Station
• Tisk PPS bude zachován
Inovovaný systém (jeho část mySPECTRA) bude umět pracovat s kontejnerovými licencemi, které zahrnují frekvence různých služeb.
V inovovaném systému budou aktuálně používané DET moduly pro LM a FS nahrazeny mySPECTRAoffice. Nesníží se rozsah funkcionalit oproti DET nebo SPECTRAplus, mySPECTRA poskytne vylepšené a více integrované řešení. Konkrétní řešení je ke schválení v rámci fáze detailního návrhu.
mySPECTRAoffice poskytne konfigurovatelný dashboard, který bude prezentovat aktuální informace
v podobě uživatelsky definovatelných widgetů. Obsah katalogu dostupných widgetů závisí
na přístupových právech (rolích) uživatele a lze jej konfigurovat systémovým administrátorem.
Widgety budou obsahovat informace o nadcházející akcích a deadlinech, stejně tak klíčové ukazatele výkonnosti (KPI). Uživatel může např. vidět seznam vydaných faktur nebo licencí s blížícím se datem expirace/obnovy. Tímto způsobem bude mít uživatel rychlejší přístup k informacím a úkolům,
za které je zodpovědný.
Uživatelé mySPECTRAoffice budou moci zobrazit stav všech existujících žádostí a licencí. Inovovaný
systém bude poskytovat přehled pomocí srozumitelných tabulek s funkcionalitou elastického
vyhledávání, díky kterému uživatel může na základě dostupných polí vyhledávat a filtrovat data dle svých potřeb. Workflow engine poskytne funkcionalitu „deadline management“, díky které je možné notifikovat jak interní uživatele, tak držitele IO a žadatele ohledně blížících se termínů (např.
splatnost faktur, data vypršení licencí, termíny pro koordinaci, atd.).
Inovovaný systém bude poskytovat funkce popsané v příloze č. 1 tohoto dokumentu. Jednotlivé funkce mohou být součástí již existujících workflow a proto může být jejich použití v rámci
inovovaného systému odlišné. Nezávisle na jednotlivých aktivitách či akcích nabídne mySPECTRA
podporu uživateli tak, aby mohl své úkoly a zodpověnosti vykonávat efektivněji.
mySPECTRA podporuje a užívá možnosti různých formátů pro import a export dat. Toto zahrnuje výkonné funkce importů z formátu Excel, které umožňují import dat žádostí, adres a vektorů. Spolu s konfiguračními soubory bude moci uživatel definovat např. povinná pole či pravidla pro validaci, která mají být zahrnuta do procesu importu dat. Dále budou moci být technická data importována
v XML formátu, případně jiných formátech standardních pro odvětví (např. anténní data skrze MSI nebo NSMA formát).
Z pohledu žadatele / držitele IO zachová inovovaný systém schopnost importu ze ZFO formulářů (náhrada ZFO Migration tool) a XML. Převody formátů dat (ZFO, Excel a XML) budou realizovány pomocí Mediátoru.
Export dat bude podporovat XLSX, XML a CSV formáty, dle zvoleného datového typu.
2. Modernizace stávajícího systému SPECTRAplus – GUI
Znění požadavku
Vytvoření moderního, přívětivého a intuitivního uživatelského rozhraní s podporou hromadných operací (typicky se jedná o akce nad objekty, které spolu souvisejí či je lze provést hromadně – např. prodloužení doby platnosti IO; odnětí IO; odeslání do archivu IO) a rovněž v maximální možné míře zamezit nutnosti ručnímu přepisu dat a přepínání aplikací při práci uživatele.
Umožnit hromadné akce workflow:
• zpracování žádosti obsahující požadavek na udělení několika IO (generování několika výstupů/IO, které budou odeslány společně)
• prodloužení doby platnosti IO,
• odnětí IO,
• odeslání do archivu IO;
• provedení netechnické změny (např. změna držitele v případě přechodu společnosti) Umožnit hromadné změny parametrů (pro ještě nevydaná IO):
• datum Platnost od,
• datum Platnost do,
• kopírování textových podmínek navázaných na oprávnění Umožnit hromadné změny parametrů (i pro vydaná IO):
• doplnění poznámky, bude možné doplnit poznámku (AP_COMMENT)
Umožnit hromadné tisky včetně exportu podepsaného PDF a XML.
Uvedené požadavky budou rozpracovány během detailní analýzy resp. návrhové dokumentace
(HLDD/LLDD).
Přepínání mezi různými softwarovými aplikacemi bude co nejvíce minimalizováno. Toto se týká
zejména potřeby přepínání s IT systémy, které jsou předmětem integrace (tj. např. správa správních i ročních poplatků je v kompetenci účetního systému a inovovaný systém umožní uživateli náhled na data týkající se poplatků (výše poplatku, uhrazeno/neuhrazeno apod.) přímo z prostředí
inovovaného systému, dále např. integrace se systémem GINIS tak, aby uživatel inovovaného systému nebyl nucen opouštět grafické prostředí inovovaného systému a aktivovat systém GINIS, SKS a další). Realizovatelnost a způsob realizace požadavku závisí na možnostech integrovaných systémů třetích stran. Situace bude posouzena a konkrétní řešení bude navrženo během detailní analýzy, resp. v návrhové dokumentaci (HLDD / LLDD).
U odborných úkonů, jako je správa plánů kmitočtů, detailní technická analýza, technická analýza
během koordinačních procesů budou využívány samostatné moduly jako SPECTRAplan, SPECTRAemc,
CHIRplus_BC nebo MONITORplus.
Předpokládaný způsob realizace
mySPECTRAoffice bude poskytovat funkcionalitu pro hromadné operace (např. zpracování vzájemně provázaných objektů nebo provádění akcí, které mohou být provedeny spolu – prodloužení platnosti licencí, odnětí licencí, archivace…). Tento způsob minimalizuje nutnost manuálního zpracování žádostí, licencí a úprav administrativních dat.
Budou možné tyto hromadné akce workflow:
• zpracování žádosti obsahující požadavek na udělení několika IO (generování několika výstupů/IO, které budou odeslány společně)
• prodloužení doby platnosti IO,
• odnětí IO,
• odeslání do archivu IO;
• provedení netechnické změny (např. změna držitele v případě přechodu společnosti) Budou možné tyto hromadné změny parametrů (pro ještě nevydaná IO):
• datum Platnost od,
• datum Platnost do,
• kopírování textových podmínek navázaných na oprávnění Budou možné tyto hromadné změny parametrů (i pro vydaná IO):
• doplnění poznámky, bude možné doplnit poznámku (AP_COMMENT) Budou možné hromadné tisky včetně exportu podepsaného PDF a XML.
mySPECTRAoffice bude jádrem aplikace pro datové vstupy, zpracování žádostí a management licencí. Nutnost přepínat mezi různými SW aplikace bude minimalizována. Přepínat do expertních modulů, jako je SPECTRAplan S, SPECTRAemc, CHIRplus_BC or MONITORplus bude potřeba pouze pro expertní úkony jako je administrace frekvenčních plánů, detailní technické analýzy, analýzy během
koordinačních procesů či evaluaci monitorovacích dat.
3. Licence
Licence k inovovanému IS (33ks) vč. ponechání rozsahu stávajících licencí modulů SPECTRAplan,
SPECTRAemc, CHIRplus_BC a MONITORplus.
4. Provedení detailní analýzy požadavků objednavatele
Provedení detailní analýzy požadavků objednavatele za účelem detailní specifikace požadavků plnění na inovaci systému pro specifické potřeby České republiky, a to v souladu s aktuálně platnou
legislativou a vnitřními procesy Objednatele. Detaily jsou dále blíže specifikovány ve smluvní
dokumentaci.
5. Vytvoření analytické a návrhové dokumentace
Vytvoření a dodání analytické a návrhové dokumentace. Detaily jsou dále blíže specifikovány
ve smluvní dokumentaci.
6. Oprava datových struktur pro všechny radiokomunikační služby
Znění požadavku
Kontrola/verifikace, analýza kvality dat, čištění dat a oprava datových struktur pro všechny radiokomunikační služby před nasazením inovovaného systému do provozu.
Ověřit kvalitu dat v současné SPplus a napravit systematické chyby (např. přesunout data uložená
v nevhodném poli do pole správného). Součástí je tedy si definovat jaké je správné a vhodné využití existující datové struktury. Bude nezbytné provést analýzu dat průřezově přes všechny služby.
Lze očekávat, že v řadě služeb (pevná, PPS, rozhlasová) je využití existující datové struktury v tomto
ohledu v pořadku, ale např. ve službách amatérská, námořní, letecká pohyblivá a družicová lze
očekávat nutnost nápravy (tedy, přesun stávajících dat ručně/skriptem do odpovídajících polí). Tam, kde to nebude možné, po diskuzi upravit datovou strukturu. V případě, že Objednatel bude
potřebovat realizaci automatizovaných nástrojů pro hromadné přesuny nebo úpravy dat, Zhotovitel tyto nástroje bude realizovat v rámci ceny díla až do výše 20 člověkodní.
Předpokládaný způsob realizace
Zhotovitel poskytne nástroje pro analýzu a normalizaci dat. Projektově-specifická podpora bude
poskytnuta v max. rozsahu 20 MD.
Zhotovitel provede datovou analýzu, korekci a normalizaci v max. rozsahu 20 MD. Jakýkoliv rozsah práce vyžadovaný po zhotoviteli nad tento rámec bude dodán formou změnového požadavku.
Migrace dat z normalizované databáze SPECTRAplus do databáze mySPECTRA bude zahrnuta. Pro vyloučení pochybností uvádíme, že migrace dat z datových zdrojů jiných než je databáze SPECTRAplus nebyla požadována a proto není součástí rozsahu práce. Jakýkoliv rozsah práce vyžadovaný po Zhotoviteli nad tento rámec bude dodán formou změnového požadavku.
7. Implementace a konfigurace systému
Implementace a konfigurace inovovaného systému na základě detailní implementační analýzy
a návrhové dokumentace vytvořené v součinnosti s Objednatelem.
Pro vyloučení pochybností, vytvoření detailní implementační analýzy a návrhové dokumentace proběhne na straně Zhotovitele v nezbytné součinnosti s Objednatelem.
Integrační požadavky
8. SPECTRAemc a CHIRplus_BC
Znění požadavku
Zajistit vzájemnou kompatibilitu mezi inovovaným systémem a stávajícími technickými moduly SPECTRAemc pro pevnou a pozemní pohyblivou službu a CHIRplus_BC.
V novém prostředí inovovaného systému je pro rozhlasovou službu požadována funkce exportu a importu do/z XML formátu obdobného, jako je využíván v DET pro pevnou službu včetně jeho
plnohodnotné alternativy (MS Excel). Funkce export/import bude dostupná jak z úrovně workflow, tak i mimo něj. Struktura exportu/importu bude předmětem detailní analýzy, ale primárně se
očekává výměna technických údajů a základních administrativních údajů.
Předpokládaný způsob realizace
mySPECTRAoffice bude kompatibilní se současnými moduly SPECTRAemc (pro LM a FS), CHIRplus_BC, SPECTRAplan S a MONITORplus.
Funkce Export / Import ve standardním formátu mySPECTRAoffice budou dostupné pro rozhlasové služby. Funkce Export / Import budou dostupné dvěma způsoby – pomocí workflow (aplikace NEW) a přímo (bez workflow, pouze pro export). V novém prostředí inovovaného systému bude pro
rozhlasovou službu k dispozici funkce exportu a importu do/z XML formátu obdobného, jako je využíván v DET pro pevnou službu včetně jeho plnohodnotné alternativy (MS Excel).
SPECTRAemc a CHIRplus_BC jsou integrálními součástmi mySPECTRA systému a jeho procesů,
a mohou běžet i zcela automatizovaně a bez dozoru. Průvodci (wizards) a makra dříve vyvinutá pro Objednatele budou nadále fungovat v mySPECTRA systému.
Co se týče importu a exportu technických dat, nejsou v novém systému očekávány žádné změny.
Aplikační data, vektorové informace nebo adresní data budou moci být importována do či exportována z mySPECTRA pomocí výkonných Excel funkcí pro import/export.
9. SPECTRAplan
Znění požadavku
Zajistit vzájemnou kompatibilitu se systémem SPECTRAplan.
Předpokládaný způsob realizace
mySPECTRAoffice bude kompatibilní se současnými moduly SPECTRAemc (pro PPS a PS), CHIRplus_BC, SPECTRAplan S a MONITORplus.
10. Ginis, LJIP, Základní registry (SKS), účetní systém, rozhraní na budoucí webový portál
Znění požadavku
Zajistit návaznost a propojitelnost na ostatní systémy IT státní správy a Objednatele, které jsou při správě rádiového spektra využívány, tj. vytvořit otevřené rozhraní pro výměnu dat se SW třetích stran a konfigurace na základě odsouhlasených výstupů uvedených v dokumentech detailní analýzy
a návrhové dokumentace, a to za účelem komunikace jádra inovovaného systému se stávajícími
a budoucími moduly či systémy IT jako je Ginis, LJIP, zákl. reg., účetní systém.
Nedílnou součástí projektu je možnost integrace stávajících i budoucích aplikací a informačních systémů prostřednictvím standardizovaných webových služeb.
Stávající SW určený k integraci:
• SKS (společný katalog subjektů), viz následující kapitola SKS
• GINIS, viz následující kapitola GINIS
• LJIP, viz následující kapitola LJIP
• Účetní systém, viz následující kapitola Účetnictví Budoucí SW určený k integraci
• budoucí Webový Portál
• jiné (nyní neznámé) aplikace - Zhotovitel v rámci tohoto projektu pouze deklaruje možnost budoucí tvorby rozhraní nezbytného k propojení systému mySpectra se SW třetích stran
Poznámka: případy užití uvedené níže (Účetnictví, LJIP, SKS, GINIS, budoucí webový portál) jsou pouze ilustrativní. Nejsou přesné a jejich výčet není úplný. Ke zpřesnění dojde až během tvorby analytických dokumentů.
SKS - společný katalog subjektů
SKS je u Objednatele primární zdroj informací o zákaznících, držitelích oprávnění. Obsahuje jejich
identifikaci (např. název, jméno, příjmení, datum narození apod.) a další informace (adresy, kontaktní osoby, telefonní čísla atd.). Informace v SKS jsou průběžně aktualizovány / synchronizovány
s Informačním systémem základních registrů České republiky.
Inovovaný systém bude integrován s již existujícím informačním systémem SKS.
Případy užití:
1. Inovovaný systém musí v definovaných bodech workflow (nebo na vyžádání uživatelem) umět ověřit aktuálnost dat vedených v adresáři pro konkrétní subjekt.
2. Založení nového subjektu v inovovaném systému
3. Založení nového subjektu v inovovaném systému, který nemá vazbu na SKS (cizinec)
4. Reakce na změny informací o subjektu indikovanou systémem SKS
Inovovaný systém si musí umět z SKS převzít aktuální informace o subjektu, nicméně dříve vystavená oprávnění se touto aktualizací adresáře nesmí změnit, ale při jejich zobrazení je
třeba starou adresu v inovovaném sytému označit/zvýraznit. Změna (aktualizace) informací o subjektu se projeví pouze pro nové úkony/akce workflow.
5. Reakce na změnu informací o subjektu indikovanou uživatelem inovovaného systému
Poznámka:
Před zprovozněním této integrace bude potřeba jednorázově vyčistit adresář v současné SPECTRAplus od duplicit a provést iniciační propojení existujících záznamů v adresáři oproti SKS.
Jedná se o mimořádně pracnou, téměř výhradně manuální činnost, kterou budou provádět uživatelé systému SPECTRA. Tam, kde to bude vhodné, budou vytvořeny Zhotovitelem pomocné skripty v
rámci objemu práce 20 člověkodní (do této časové dotace je součástí rozpočtu projektu) z bodu 6
„Oprava datových struktur pro všechny radiokomunikační služby“.
GINIS
Předpokládá se propojení inovovaného systému se spisovou službou GINIS za účelem využití služeb podatelny, výpravny a DMS (systém správy dokumentů).
GINIS poskytne rozhraní pro odesílání a správu dokumentů v rámci inovovaného systému. GINIS bude proto jedním z nejvýrazněji integrovaných systémů vedle integrace s účetním systémem.
Zajištění dostupnosti plné historie vzájemné komunikace žadatele a Objednatele, aby byla využitelná pro opakované použití. Jedná se zejména o dostupnost dokumentů a historie jejich verzí. Toto je zajištěno na základě služeb DMS a spisové služby.
Pro připojení na systém GINIS bude nutné využívat nové rozhraní GINIS, které respektuje Národní standard pro elektronické systémy spisové služby (NSESSS) a to v rozsahu, který bude nezbytně nutný pro zajištění funkcionalit potřebných pro výkon agend mySPECTRA.
Případy užití:
1. GINIS (podatelna, DMS) eviduje přijatou žádost, generuje k ní jedinečné identifikátory a vše předává inovovanému systému
2. GINIS (výpravny, DMS) eviduje a odesílá výstupy z inovovaného systému, které mají být
doručeny mimo Objednatele. Výstupy mohou být v listinné nebo elektronické podobě nebo předány osobně.
To, mimo jiné, znamená:
1. mySPECTRA musí přijímat z GINIS žádosti, včetně žádosti obsahující požadavek na udělení několika IO (žádost na udělení několika IO – viz požadavek 2)
2. mySPECTRA musí přijímat z GINIS přílohy
3. mySPECTRA musí přijímat návrhy na přidání nové položky v číselníku / kartotéce
LJIP – lokální jednotný identitní prostor
Pro inovovaný systém bude LJIP primární zdroj identit uživatelů.
Inovovaný systém bude napojený na LJIP, ze kterého bude přebírat identity uživatelů. Dosavadní SPECTRAplus tuto funkcionalitu nemá.
Autentizace uživatelů bude v realizovaném systému řešena prostřednictvím již existujícího systému
LJIP, stejně jako autorizace. LJIP bude obsahovat agendové role uživatelů a aplikační role
informačního systému SPECTRA. Uživatelé se do systému LJIP budou autentizovat jménem a heslem.
Autorizace uživatelů bude řešena v realizovaném systému ve dvou úrovních. První úroveň
agendových a aplikačních rolí bude vedena v systému LJIP. Druhá úroveň se značně detailnější granularitou (oprávnění na jednotlivé akce v informačním systému, oprávnění na jednotlivá data apod.) bude vedena přímo v inovovaném systému (dosud v SPECTRAplus).
LJIP bude využíván pro správu a ověřování všech interních uživatelů inovovaného systému. Konkrétní způsob integrace a dopad popíše až detailní analýza.
Případy užití:
1. založení nové identity v LJIP – uživatele inovovaného systému
2. změna aplikačních rolí v LJIP u uživatele inovovaného systému
3. v LJIP provedení zablokování / zneplatnění účtu uživatele inovovaného systému
4. změna uživatelského hesla na vyžádání uživatelem
5. chování systému po expiraci hesla uživatele inovovaného systému
Účetnictví
Cílem této integrace je přenesení problematiky účetnictví (fakturace, přijaté platby, bankovní výpisy, saldokonto apod.) z prostředí SPECTRAplus (současný stav) do specializovaného účetního systému (budoucí stav).
Vazba na účetní systém
Inovovaný systém vypočítá výši poplatku (správní poplatek, roční poplatek za využívání kmitočtu)
a tuto informaci předá jako platební výměr (Payment Terms) účetnímu systému.
Účetní systém bude zodpovědný za generování faktur, dobropisů a jejich párování s došlými
platbami.
Případy užití interface:
1. Při vydávání nového oprávnění je možné zjistit, zda daný subjekt není dlužnikem (nemá neuhrazené pohledávky)
2. Předávání informací o předepsané platbě (správní poplatek, poplatek za využívání přiděleného kmitočtu)
3. Předávání informací o provedené úhradě správního poplatku (úhrada je možná i kolkem)
4. Zpracování situace, kdy oprávnění předčasně zaniklo na žádost držitele
5. Zpracování situace, kdy držitel oprávnění neuhradil předepsanou částku
6. Zpracování situace, kdy po odvolání držitele nového oprávnění dojde ke změně předepsaných poplatků
7. Zpracování situace, kdy v důsledku změny právních předpisů dojde k hromadné změně výše již dříve předepsaných poplatků
8. Zpracovat situaci, kdy v účetním systému dojde k nápravě chyby (např. rozpárování dříve chybně spárované platby)
9. Zpracovat situaci, kdy dochází k prodloužení platnosti oprávnění
10. Zpracovat situaci, kdy dochází ke změně oprávnění s důsledkem udělení nového oprávnění
a odejmutím původního
Integrace na Účetní systém bude výhradně založena na principu REST API.
Budoucí webový portál
Na budoucí webový portál lze nahlížet jako na webový formulář pro účely podání žádostí
souvisejících s problematikou individuálního oprávnění k využívání rádiových kmitočtů (nové, odnětí, prodloužení doby platnosti, změna, převod) a dále poskytnout registrovaným uživatelům webového portálu (žadatel / držitel IO) přehled o jejich aktuálních žádostech souvisejících s IO a dále udělených IO, a to včetně možnosti náhledu na takovou žádost či IO a dále včetně doprovodných informací (výše ročního poplatku, stav žádosti, stav uhrazení správního poplatku, stav uhrazení poplatku za využívání rádiových kmitočtů). Tyto informace webový portál získá z inovovaného systému prostřednictvím
Mediátoru (pozn.: informace toho rozsahu a charakteru, které jsou v inovovaném systému k dispozici).
S ohledem na legislativní rámec týkající se podávání žádostí v souladu se správním řádem, jsou uvažovány následující oficiální způsoby podání žádostí bez ohledu na to, jakým způsobem jsou data žádosti připravena (prostřednictvím webového formuláře, papírová žádost, dosavadní ZFO soubory). Jsou uvažovány následující způsoby podání žádosti:
1. prostřednictvím datové schránky (dále DS)
2. podání osobně na podatelnu
3. zaslání poštou
4. e-mailem s uznávaným el. podpisem
5. e-mailem bez uznávaného el. podpisu a s nutností následně doručit žádost formálně
Zásadní informace pro realizaci inovovaného systému je, že jakékoliv podání je nutné učinit
prostřednictvím podatelny Úřadu. Pro evidenci příchozích žádostí (obecně se jedná o systém DMS) se bude využívat systém GINIS, jehož integrace je požadována s inovovaným systémem prostřednictvím Mediátoru (viz požadavek JKP č. 10 v části GINIS).
Pro důsledné pochopení souvislostí, toku úkonů ve webovém portálu a požadavků na inovovaný systém je nutné blíže specifikovat zamýšlenou filozofii realizace webového portálu a až následně uceleně popsat rámcové požadavky na inovovaný systém a Mediátor.
Postup zadání žádosti prostřednictvím webového portálu
1. přihlášení žadatele/držitele IO do webového portálu (webový portál však umožní i práci žadateli/držiteli IO bez registrace)
2. v prostředí webového formuláře volba příslušného elektronického formuláře pro zadávání / editaci dat v odpovídající službě či podslužbě. Validace vstupních polí jako jejich layout
a rozsah bude předmětem realizace webového portálu. Rozsah zadávaných polí bude vždy maximálně v rozsahu zadávaných polí v rámci požadavku JKP č. 1. Prostřednictvím
elektronického formuláře bude možné vkládat přílohy (PDF, Excel). Tyto přílohy musí být následně dostupné i v inovovaném systému prostřednictvím GINIS.
3. vyplnění elektronického formuláře
umožnění listování a výběr položek z číselníků / kartoték inovovaného systému (seznam
číselníku je uveden níže). U položek, které nejsou dohledány v číselníku / kartotékách webový portál umožní zadání kompletních technických parametrů. Příslušné číselníky budou
importovány z inovovaného systému do webového portálu. Při pozdějším zpracování žádosti v inovovaném systému je takový návrh nové položky v číselníku / kartotéce připraven ke schválení uživatelem inovovaného systému a následně připraven k použití.
4. úhrada správního poplatku prostřednictvím platební brány nebo přiložení potvrzení reference či informaci o provedené úhradě
5. podání (zaslání) žádosti jedním z nabídnutých způsobů (viz oficiální způsoby výše).
a. současně s podáním žádosti dojde k zaslání vyplněných údajů elektronického formuláře včetně příloh do inovovaného systému prostřednictvím GINIS.
b. žádost bude mít jednoznačné unikátní ID (či QR kód) přidělený webovým portálem.
c. po vstupu dat obdržené žádosti z GINIS do inovovaného systému dojde ke zpracování žádosti standardní cestou podle reálné integrace GINIS – inovovaný systém. Očekává se, že inovovaný systém tyto žádosti založí do „bufferu“, kde budou čekat na jejich akceptaci uživatelem inovovaného systému a následným finálním přesunem do ostré databáze inovovaného systému
Na základě výše uvedeného tak lze dále definovat rámcové požadavky, které má inovovaný systém vč. Mediátoru splnit, aby Objednateli umožnily pozdější implementaci webového portálu.
1. Z inovovaného systému prostřednictvím Mediátoru budou do webového portálu importována data nutná pro vytvoření a vložení (vyplnění) žádosti (tj. data, která jsou v inovovaném systému k dispozici) o IO (seznamy a číselníky uložené v inovovaném systému, např. seznam držitelů IO, zařízení, IO, antén, kmitočtové plány (SPECTRAplan), volací značky, zda je žadatel držitelem
průkazu odborné způsobilosti amatérské služby, seznam satelitů, apod.). Vytváření, vložení (vyplnění) žádostí o IO bude ve webovém portálu řešeno formou webových elektronických formulářů, které provedou žadatele / držitele IO na webovém portálu celým procesem zadání údajů žádosti o IO.
2. Inovovaný systém prostřednictvím Mediátoru poskytne webovému portálu data k již existujícím IO v případě žádosti o změnu existujícího IO a umožní tak předvyplnění dat (smyslem je provést pouze úpravu existujících dat žadatelem / držitelem IO na webovém portálu).
3. Za účelem umožnění efektivního zadávání / editaci dat žádosti o IO prostřednictvím webového portálu a řízení workflow webového portálu jsou zapotřebí, aby byly ve webovém portálu
k dispozici následující seznamy/číselníky z inovovaného systému:
3.1. katalog antén včetně technických údajů jednotlivých antén,
3.2. katalog rádiových zařízení včetně technických údajů jednotlivých zařízení,
3.3. seznam držitelů IO
3.4. seznam IO
3.5. seznam stanovišť
3.6. číselníky ze SPECTRAplan pro umožnění výběru pásem/kmitočtů a kontroly přístupnosti
v závislosti na datumu
3.7. seznam satelitů
3.8. data, která jsou zapotřebí pro validaci zadávaných dat ve webovém portálu:
3.8.1.seznam přidělených volacích značek a kódů,
3.8.2.informace, zda je žadatel držitelem průkazu odborné způsobilosti v amatérské službě.
4. Z inovovaného systému do webového portálu budou importována data nutná pro vytvoření
a vložení (vyplnění) žádosti (tj. data, která jsou v inovovaném systému k dispozici) - pro
provedení: odnětí, změny, převodu nebo prodloužení doby platnosti existujícího IO (tj. např.
informace o době platnosti IO, číslo IO, držitel IO).
5. Z inovovaného systému do webového portálu budou importována data nutná pro hledání v seznamech a číselnících, včetně hledání v seznamu žadatelů/držitelů IO, žádostí a IO (viz body 2 až 4 výše), podle zadaných parametrů. Hledání v seznamech současně musí umožňovat i rozlišení na úroveň radiokomunikační služby.
6. Inovovaný systém umožní příjem jednotlivých i hromadných žádostí související s IO (k iniciaci workflow zpracování nové/odnětí/prodlužení doby platnosti/změna)
7. Inovovaný systém poskytne webovému portálu data nutná pro indikaci stavu zpracování žádosti, včetně případných detailů a dokumentů (např. informace k úhradě správního poplatku včetně vypočítané výše, případně také usnesení o přerušení řízení, zastavení řízení apod.)
8. Inovovaný systém umožní sdílení dat (využití záznamů z historie) potřebných pro zadání žádostí
o IO, specificky u žádostí o KO, pevné, družicové, amatérské a letecké pohyblivé službě
9. Inovovaný systém poskytne rozhodnutí či usnesení související s IO (nové, změna, prodloužení doby platnosti, odnětí) v datové i grafické formě
10. Inovovaný systém poskytne seznam (z inovovaného systému do webového portálu budou
importována pouze ta data, která jsou v inovovaném systému k dispozici) všech IO vč. jejich el. vzoru a náhledu detailu IO, dále včetně předpisu uhrazených/neuhrazených správních poplatků a předepsaných a uhrazených/neuhrazených ročních poplatků, včetně základních údajů o IO (doba platnosti, datum žádosti, nabytí právní moci, číslo jednací apod.) (pozn.: v případě jejich zobrazení na webovém portálu se musí zobrazit pouze takový rozsah množiny dat, který se týká konkrétního registrovaného uživatele/držitele IO).
11. Inovovaný systém poskytne plný rozsah výše uvedených dat. Vyhledávání, filtrace, řazení apod.
budou funkcionality webového portálu.
Předpokládaný způsob realizace
Inovovaný systém bude integrován s existujícími IT systémy třetích stran pro výměnu dat vztahujících se ke správě kmitočtového spektra. Za účelem integrace se systémy třetích stran bude vytvořena
komponenta Mediátor. Stávající SW určený k integraci:
• SKS (společný katalog subjektů)
• GINIS
• LJIP
• Účetní systém
Předpokládaný způsob realizace rozhraní na budoucí webový portál
Požadavky na interface mySPECTRA / Portál
1. Mediátor poskytne z mySPECTRA směrem do webového portálu tyto seznamy, katalogy, číselníky:
1.1. katalog antén včetně technických údajů jednotlivých antén,
1.2. katalog rádiových zařízení včetně technických údajů jednotlivých zařízení,
1.3. seznam držitelů IO,
1.4. seznam IO,
1.5. seznam stanovišť,
1.6. číselníky ze SPECTRAplan pro umožnění výběru pásem/kmitočtů a kontroly přístupnosti
v závislosti na datumu,
1.7. seznam přidělených volacích značek a kódů,
1.8. seznam držitelů průkazu odborné způsobilosti v amatérské službě,
1.9. seznam satelitů.
2. Mediátor poskytne z mySPECTRA směrem do webového portálu data nutná pro indikaci stavu zpracování žádosti, včetně případných detailů a dokumentů (např. informace nutné k úhradě správního poplatku včetně vypočítané výše a výše ročního poplatku, případně také usnesení
o přerušení řízení, zastavení řízení apod.)
3. Mediátor poskytne z mySPECTRA směrem do webového portálu rozhodnutí či usnesení související s IO (nové, změna, prodloužení doby platnosti, odnětí) v datové i grafické formě
11. APV ASMKS
Znění požadavku
Zachovat otevřené rozhraní pro vyhledávání a zobrazování dat o IO pro APV ASMKS, je požadována srovnatelná rychlost.
Předpokládaný způsob realizace
Otevřený interface k IS APV ASMKS (MONITORplus server interface) pro vyhledávání a zobrazování licečních dat bude zachován a udržován v rámci stávajícího rozhraní MONITORplus pomocí
materializovaných pohledů. Pokud bude, např. z technologických důvodů, nezbytné provést jakékoliv změny na straně mySPECTRA, příp. zajistit technologické zlepšení (např. nahrazení webovými službami), bude nezbytné zajistit, aby jednak nedošlo ke snížení výkonu, a dále aby pro rozhraní byly používány podobné datové sady.
Databázový pohled z produktu Data Warehouse zahrnuje informace (workflows, faktury, IO apod.), které jsou dostupné také v inovovaném Systému jako standardní RESTful služby a v databázovém schématu. Koncept Data Warehouse bude součástí krabicového řešení mySPECTRA. Náhledy tak mohou být aktualizovány nebo nahrazeny jejich ekvivalentem z mySPECTRA. V rámci analytické fáze mohou být přezkoumány požadavky v kontextu aktuálních verzí systému na straně Objednatele, a to za účelem výběru a dodávky přinejmenším ekvivalentního nebo lepšího řešení. Toto by mělo být provedeno s ohledem na koncepty a standardy nových technologií a systémové architektury mySPECTRA.
12. SPECTRAexchange essential
Znění požadavku
Zachovat možnost importu/exportu z inovovaného systému pomocí SPECTRAexhange essential či zajistit jeho plnohodnotnou náhradu.
Zachování nativní podpory Export/Import dat mimo workflow.
Zachování importu technických údajů oprávnění pro pevnou službu a nová implementace exportu pro rozhlasovou službu.
Zachování stávajících exportů implementovaných v tiskovém modulu.
Požadována je konzistence výstupů, které jsou prováděny v různých částech systému. Všechny výstupy musí mít jednotný formát. Konzistence výstupů je požadována napříč exporty v tiskovém
modulu a dalšími částmi systému popisovanými v požadavcích č. 8 SPECTRAemc a CHIRplus_BC, č. 66
Import/Export v ostatních službách, atd.
Předpokládaný způsob realizace
Import z / Export do inovovaného systemu bude pro jednotlivé služby umožněn prostřednictvím konfigurovatelných Excelových souborů. Za SPECTRAexchange bude nabídnuta vhodná alternativa podporující standard mySPECTRA pro export/import. Navrhovaný způsob řešení je popsán v rámci požadavku č. 1 tak, že: „Z pohledu žadatele / držitele IO zachová inovovaný Systém schopnost importu ze ZFO formulářů (náhrada ZFO Migration tool) a XML.“.
Bude umožněn nativní export/import dat mimo workflow.
Stávající exportní funkcionality v tiskovém modulu budou zachovány a udržovány.
Požadavky související s IO či správním rozhodnutím obecně
13. Rozlišení verze správního rozhodnutí
Znění požadavku
Jednoznačně rozlišit a obsahově v inovovaném systému zafixovat tu verzi správního rozhodnutí, která byla odeslána žadateli (ať už elektronickou verzi ve formátu PDF s podpisem a případně časovým
razítkem, tak i případný sken v případě listovního odeslání).
Uživateli musí být dostupné přesně ty výstupy, které byly odeslány žadateli, a to včetně případných příloh (viz hromadná akce udělení nových IO; XML přílohy) a to jednak jako datové sady a jednak jako
elektronická verze ve formátu PDF s podpisem a případně časovým razítkem, tak i případný sken
v případě listovního odeslání. Je nutné rozlišovat případy:
• existuje tisková šablona – výstup je pouze poslán na tiskárnu a následně dojde k osobnímu předání IO žadateli nebo zaslání pozemní poštou. Výstup(y) musí být připojeny k workflow automaticky po jejich vygenerování tiskovým modulem, a to ve formátu, který umožní jejich pozdější otevření. Tento výstup(y) je rovněž uložen v uložišti GINIS.
• existuje tisková šablona – výstup(y) je poslán jak na tiskárnu, tak je dále generován tiskovým
modulem do PDF s el. podpisem (konverze). Výstup(y) musí být připojeny k workflow automaticky, a to jak výstup, který byl odeslán na tiskárnu (a je fyzicky k dispozici), tak i konvertovaný soubor. Odeslání GINIS se však týká pouze konvertovaného výstupu(ů).
• neexistuje tisková šablona – výstup(y) je vytištěn mimo inovovaný systém a bude následně odeslán prostřednictvím datových schránek. V takovém případě inovovaný systém umožní uživateli vybrat ten výstup(y), který bude následně tímto systémem konvertován do PDF s el. podpisem. Konvertovaný výstup(y) bude rovněž připojen k workflow. Odeslání
prostřednictvím GINIS se však týká pouze konvertovaného výstupu(ů)
• neexistuje tisková šablona – výstup(y) je vytištěn mimo inovovaný systém a bude následně odeslán prostřednictvím pozemní pošty či předán osobně. V takovém případě inovovaný systém umožní uživateli ručně vybrat ten výstup(y) a automaticky je přiložit k workflow. Tento výstup(y) je rovněž uložen v uložišti GINIS.
Inovovaný systém umí ukládat generované či ručně připojené výstupy na sdílené uložiště.
U všech výstupů (viz také hromadná akce nového IO) musí být informace, zda a kdy byl výstup odeslán žadateli a jakou formou (osobně, pošta, datová schránka).
Předpokládaný způsob realizace
Správná verze správního rozhodnutí bude systémem jednoznačně identifikována. Inovovaný systém bude zahrnovat správnou verzi buďto jako data uložená v databázové struktuře, nebo jako data v PDF formátu s digitálním podpisem a certifikovaným časovým záznamem (time stamp), nebo jako skenovaný dokument (v případě zpracování dokumentu papírovou formou nebo skrze poštovní službou).
Veškerá rozhodnutí nebo jiné výstupy k odeslání žadateli budou přístupné pro uživatele inovovaného systému, a to včetně existujících příloh (viz. požadavky na hromadné akce – přidělování nových
licencí (přílohy v XML)) a to jednak jako datové sady a jednak jako elektronická verze ve formátu PDF
s podpisem a případně časovým razítkem, tak i případný sken v případě listovního odeslání.
Níže uvedené případy je třeba rozlišovat skrze parametr, který je možné přiřadit systémem
(workflow):
• existuje tisková šablona – výstup je pouze poslán na tiskárnu a následně dojde k osobnímu předání IO žadateli nebo zaslání pozemní poštou. Výstup(y) musí být připojeny k workflow automaticky po jejich vygenerování tiskovým modulem, a to ve formátu, který umožní jejich pozdější otevření. Tento výstup(y) je rovněž uložen v uložišti GINIS.
• existuje tisková šablona – výstup(y) je poslán jak na tiskárnu, tak je dále generován tiskovým
modulem do PDF s el. podpisem (konverze). Výstup(y) musí být připojeny k workflow automaticky, a to jak výstup, který byl odeslán na tiskárnu (a je fyzicky k dispozici), tak i konvertovaný soubor. Odeslání GINIS se však týká pouze konvertovaného výstupu(ů).
• neexistuje tisková šablona – výstup(y) je vytištěn mimo inovovaný systém a bude následně odeslán prostřednictvím datových schránek. V takovém případě inovovaný systém umožní uživateli vybrat ten výstup(y), který bude následně tímto systémem konvertován do PDF s el. podpisem. Konvertovaný výstup(y) bude rovněž připojen k workflow. Odeslání
prostřednictvím GINIS se však týká pouze konvertovaného výstupu(ů)
• neexistuje tisková šablona – výstup(y) je vytištěn mimo inovovaný systém a bude následně odeslán prostřednictvím pozemní pošty či předán osobně. V takovém případě inovovaný systém umožní uživateli ručně vybrat ten výstup(y) a automaticky je přiložit k workflow. Tento výstup(y) je rovněž uložen v uložišti GINIS.
Inovovaný Systém bude umět ukládat generované či ručně připojené výstupy na sdílené uložiště.
U všech výstupů (viz také hromadná akce nového IO) bude informace, zda a kdy byl výstup odeslán žadateli a jakou formou (osobně, pošta, datová schránka).
Rozhraní pro GINIS bude zajištěno Mediátorem. Situace bude posouzena a konkrétní řešení bude navrženo během detailní analýzy, resp. v návrhové dokumentaci (HLDD / LLDD).
14. Evidovat osobu držitele IO včetně kompletní historie
Znění požadavku
Evidovat osobu držitele IO včetně kompletní historie, tj. kdo je aktuální držitel IO, kdo byli předchozí držitelé IO, a to včetně změn v doručovací adrese (např. řízení v zastoupení advokátem apod.).
Požadavek má silnou vazbu na integraci s SKS, nicméně je nutné zohlednit, že informace o držiteli IO fyzicky uvedené na IO jsou v případě požadavku na stejnopis oprávnění vázány stále na původní
informace o držiteli IO, přestože z hlediska např. doručení písemností držiteli apod. je potřebné již evidovat aktuálního držitele.
Požadavek signalizace, že zobrazovaná adresa u IO je již neaktuální (vůči SKS) a mít možnost
si zobrazit aktuální adresu na vyžádání.
Faktická změna adresy u IO může být provedena až v rámci definovaného workflow.
Předpokládaný způsob realizace
Držitel IO bude evidován a bude jasné, kdo je aktuálním držitelem IO. Bude možné sledovat plnou
historii vlastnictní IO, a to včetně úplných detailů jako je doručovací adresa (příp. změny, např. řízení
v zastoupení advokátem), a to po tak dlouhou dobu, po jakou jsou tyto změny přímo přístupné
v SPECTRA databázi. Změny dat v systémech třetích stran pravděpodobně nebude možné sledovat.
Tento požadavek má silnou vazbu na požadavek integrace SKS relací do SKS systému.
Bude zajištěna signalizace, že zobrazovaná adresa u IO je již neaktuální (vůči SKS) a bude možnost
si zobrazit aktuální adresu na vyžádání.
Faktická změna adresy u IO bude moci být provedena až v rámci definovaného workflow.
15. Evidovat datum nabytí právní moci u IO
Znění požadavku
Evidovat datum nabytí právní moci u IO či rozhodnutí v inovovaném systému.
Potřeba evidovat ručně nebo automatickým uložením datumu, kdy zaslaný výstup (IO) nabyl právní
moci.
Ručně zadá uživatel pokud bylo odesláno pozemní poštou (doručenka je dodána uživateli ručně).
V případě odeslání výstupu (IO) pomocí datových schránek je nutné periodicky ověřovat, zda byl výstup doručen na základě elektronické doručenky, která je k dispozici v GINIS a po doručení dopočítat datum nabytí právní moci podle předem stanového kritéria.
Pokud by již pole bylo vyplněno, nepřepisovat údaj při automatickém vyplňování pole. Tiskový modul bude umět pracovat s informací o datu nabytí právní moci.
Předpokládaný způsob realizace
V inovovaném systému bude evidováno datum nabytí právní moci IO.
Datum nabytí právní moci bude možné evidovat ručně nebo automaticky, dle aktuálních možností daného případu, což lze zhodnotit příslušným parametrem workflow inovovaného systému.
Ručně zadá uživatel pokud bylo odesláno pozemní poštou a kde je doručenka o doručení dodána uživateli ručně.
V případě odeslání výstupu (IO) pomocí datových schránek je nutné periodicky ověřovat, zda byl výstup doručen na základě elektronické doručenky, která je k dispozici v GINIS a po doručení
inovovaný systém dopočítá datum nabytí právní moci podle předem stanového kritéria. Pokud by již pole bylo vyplněno, nepřepisovat údaj při automatickém vyplňování pole. Tiskový modul bude umět pracovat s informací o datu nabytí právní moci.
Tisky/export IO či správního rozhodnutí
16. Inovovat funkcionality tisku IO
Znění požadavku
Implementace v roce 2019 inovované tiskové funkcionality IO s tím, že je nutné generovat v případě jednoduchých IO výtisk při zachování minimálně aktuální rychlosti tisku.
Předpokládaný způsob realizace
Tisková funkcionalita dodaná v roce 2019 bude implementována do inovovaného Systému a proces generování dokumentu k tisku v případě jednoduchých IO zachová minimálně aktuální rychlost tisku.
17. Zlepšit UI pro tisk oprávnění
Znění požadavku
Zlepšit stávající uživatelské rozhraní a celkovou uživatelskou zkušenost pro tisk oprávnění, a to včetně způsobu (ruční editace či výběr z kartoték) zadání textů jednotlivých oddílů IO či rozhodnutí –
hlavička, podmínky, odůvodnění.
Volání akce tisk oprávnění musí být dostupné jak z úrovně workflow, tak ale i mimo úroveň workflow (např. pro zpětnou kontrolu, zda byly zadány technické údaje v pořádku). Náhled na IO (byť
bez kompletních údajů) musí být možné provést v inovovaném systému i kdykoliv před jeho vydáním.
Pro efektivní zadávání textů a podmínek IO je nezbytné, aby byla dodržena kategorizace textů na úrovních - SLUŽBA, ÚKON (podkategorie: prodloužení, odnětí, nové, změna IO) a KATEGORIE (podkategorie: hlavička, podmínka, odůvodnění).
• umožnit pomocí např. našeptávače rychle vyhledávat v této kartotéce
• je také možné, že některé texty mohou příslušet do různých kategorií a i několika podkategorií (např. nové, odnětí IO)
Předpokládaný způsob realizace
Uživatelská zkušenost pro tisk oprávnění a relevantní GUI bude zlepšeno, včetně způsobů zadávání textu (ruční editace nebo výběr z textového katalogu - kartotéky), tzn. části textu příslušných polí
licence nebo administrativních rozhodnutí (hlavička, podmínky, odůvodnění), které budou přípustné dle definovaného licenčního stavu (workflow status).
Akce tisku oprávnění bude přístupná přímo z workflow nebo mimo něj, např. pro technickou kontrolu datových údajů.
Náhled tisku bude dostupný kdykoliv, dokonce i před vyplněním všech údajů nebo před samotným udělením licence.
Klasifikace částí textu bude držena na následujících úrovních: SERVICE, ACT (podtřídy: prodloužení, odnětí, nový, změna) a CLASS (podtřídy: hlavička, podmínka, odůvodnění).
Rychlé vyhledávání v kartotéce bude zajištěno skrze funkci elastického vyhledávání.
Některé texty mohou patřit do jiných tříd či podtříd (např. nové, odnětí…). Je plánována obecná
hierarchie konfigurace.
Standardní vlastnosti pro konfiguraci mySPECTRA umožní Objednateli nastavit textové bloky a další relevantní konfigurace tak, aby vyhověly požadavkům Objednatele popsaným v tomto požadavku.
Situace bude posouzena a konkrétní řešení bude navrženo během detailní analýzy, resp. v návrhové
dokumentaci (HLDD / LLDD).
18. Zrušit omezení na počet znaků
Znění požadavku
Zamezit omezení v počtu znaků textů jednotlivých oddílů IO či rozhodnutí. Náhled IO musí být k dispozici i v rámci procesu technické analýzy.
Předpokladem je zachování počtu znaků (možnost zadat alespoň 4000 znaků).
Předpokládaný způsob realizace
Maximální množství zadaných znaků v textech jednotlivých oddílů IO či rozhodnutí bude bez omezení.
19. Umožnit vyhledávání a kategorizace textů v tiskových sestavách
Znění požadavku
Implementovat funkci vyhledávání a kategorizaci textů v tiskových sestavách, a to v závislosti na radiokomunikační službě a typu rozhodnutí (nové IO, prodloužení doby platnosti atd.).
Vyhledávání v katalogu textů - viz Rozpad v požadavku 17.
Předpokládaný způsob realizace
Bude implementována funkce vyhledávání a kategorizaci textů v tiskových sestavách, a to v závislosti na radiokomunikační službě a typu rozhodnutí (nové IO, prodloužení doby platnosti atd.).
Vyhledávání v katalogu textů - viz Rozpad v požadavku 17.
20. Zachovat vazbu tisku na IO
Znění požadavku
Zachovat stávající funkcionalitu, aby podmínky, které se budou tisknout na IO, byly vázané na IO,
a nikoliv na konkrétní tisk IO.
Předpokládaný způsob realizace
Stávající funkcionalita bude zachována a udržována tak, aby podmínky, které se budou tisknout
na IO, byly vázané na IO, a nikoliv na konkrétní tisk IO.
21. Správa tiskových sestavy
Znění požadavku
Zachovat užívání tiskových šablon, které byly vytvořené nebo upravené pro potřeby Objednatele.
Zachovat nebo i rozšířit současné možnosti ohledně tvorby a změn tiskových šablon.
Předpokládaný způsob realizace
Tiskové šablony budou používány a bude umožněna jejich modifkace jakožto definovaný krok
v příslušném workflow, případně definována pouze jako workflow status.
Inovovaný systém bude používat sestavy a šablony dokumentů podobně jako stávající systém SPECTRA. Sady šablonbudou vyplňovány automaticky. Šablony vlastní Objednatel a mohou být modifikovány a udržovány Objednatelem. Pro editaci šablon je však vyžadována licence Crystal Reports Designer.
22. Zajistit verzování dat
Znění požadavku
Zajistit verzování dat v databázi.
Záznam historie změn údajů (jaké pole a kdo a kdy změnil), a to včetně záznamu změn údajů v
číselnících (antény, stanoviště). Ve fázi návrhu projektu bude definován rozsah logovaných údajů a
retence záznamů jako konfigurovatelný soubor pravidel. Tato pravidla bude možné později upravovat formou změny konfigurace. Záměrem je, aby Objednatel nebyl nucen logovat vše a mohl sám
průběžně rozhodovat, které změny v datech se budou logovat.
Souvisí s požadavkem č. 61. Celkovým záměrem je, aby inovovaný systém verzoval a logoval.
Předpokládaný způsob realizace
Inovovaný systém poskytne zaznamenávání historie změn žádostí o IO nebo kontaktních údajů (tzn. jaké pole bylo změněno, kdy a kým). Stejným způsobem je možné sledovat změny dat v kartotékách (antény, stanoviště).
V obecné rovině je sledování změn omezené a není defaultně dostupné pro všechna databázová pole, a to za účelem zajištění výkonnosti systému (velikost DB, DB dotazování).
Úrovně logů a retenční politika bude konfigurována, což bude předmětem detailní analýzy. Tyto parametry mohou být upraveny později jakožto konfigurační parametry. Zamýšlenou logikou je nechat Objednatele definovat, co má být logováno, namísto logování všeho.
Zavedení BPMN workflows umožní high-level sledování historie workflow týkající se zpracování licencí, kontaktních a technických dat.
V obecné rovině mySPECTRA bude moci ukládat log soubory a poskytovat kontrolu verzí pro ta pole, která jsou vyplněna nebo upravována v průběhu vykonávání workflow.
K zajištění separátního a kompletního logování aktivit týkajících se uživatelských práv (např. Systémový administrátor upravující konfiguraci) bude existovat auditní stopa.
23. Umožnit digitální podpis a časové razítko
Znění požadavku
Umožnit digitální podpis a časové orazítkování dokumentu při vyhotovení IO či rozhodnutí, a to ještě před jeho odesláním.
V principu se jedná o využití inovovaného tiskového modulu využívající Crystal Reports. Ponechat možnost generování do PDF s elektronickým zaručeným podpisema časovým razítkem.
Umožnit při generování výstupu (dnešní funkcionalita) export do formátu XML v pevné službě či jeho plnohodnotné alternativy.
Předpokládaný způsob realizace
Inovovaný systém bude obsahovat funkcionalitu pro digitální podepisování a časové orazítkování výstupních dokumentů před jejich odesláním.
24. Odeslání prostřednictvím GINIS
Znění požadavku
Implementace podpory odeslání IO či rozhodnutí různými kanály přímo z prostředí inovovaného systému, a to prostřednictvím GINIS (na pozadí).
Uživatel musí mít přímou možnost odeslání formou datové zprávy (na pozadí prostřednitcvím GINIS). Současně mu musí být umožněno nastavit takový příznak, ze kterého bude zřejmé, že odeslání bude fyzické či bylo vyřízeno e-mailem.
Předpokládaný způsob realizace
Podpora odeslání IO či administrativních rozhodnutí bude umožněna skrze odeslání různými kanály do systému GINIS (na pozadí), a to standardními technologiemi podporovanými a poskytovanými mySPECTRA.
Uživatel bude mít možnost odeslat IO či administrativní rozhodnutí jakožto datovou zprávu (na pozadí prostřednictvím GINIS), a to standardními technologiemi podporovanými a poskytovanými mySPECTRA.
Uživatel bude mít možnost označit výstupní cestu ze systému GINIS (fyzicky, emailem, datovou
schránkou ).
25. Zachovat kartotéku textů tisku IO
Znění požadavku
Zachovat obsah stávajících kartotéky textů tisku IO a nadále zajistit vedení a správu takové kartotéky
v inovovaném systému.
Předpokládaný způsob realizace
V inovovaném systému bude zachován obsah stávajících kartotéky textů tisku IO a nadále bude zajištěno vedení a správu takové kartotéky.
Open data/zveřejnění údajů na webu Objednatele
26. Umožnit export do CSV a XLSX
Znění požadavku
Umožnit export vybraných souborů/množiny dat databáze, a to ve formátech CSV a XLSX
v zadavatelem definovaném čase na definované úložiště. Export předem definovaných datových sad:
• sada Oprávnění (číslo IO, služba, platnost, kmitočet) – vyloučit subjekty označené jako
k nezveřejnění
• sada Kmitočtové příděly (držitel, platnost, rozsah kmitočtů)
• sada Open data (nutné specifikovat rozsah dat)
• sada Kompletní (kompletní seznam všech přidělených IO či souhlasů – ambasády)
k pozdějšímu dalšímu zpracování
Formát a struktura sady bude jednoznačně definována s malými změnami v čase. Častější změny mohou nastat u příznaků v konkrétních IO, zda takové IO může být zahrnuto do exportu či jej
vyloučit. Příznak bude na úrovni IO a bude vycházet z výchozího nastavení. To bude možné v případě potřeby konfigurovat nebo upravit uživatelem, viz také požadavek č. 27.
Předpokládaný způsob realizace
Export vybraných souborů / datových sad z databáze bude možný ve formátech CSV a XLSX
do uživatelem definovaného úložistě a v uživatelem definovaném čase. Export předem definovaných datových sad:
• sada Oprávnění (číslo IO, služba, platnost, kmitočet) – subjekty označené jako neveřejné („non-public“) budou vyloučeny
• sada Kmitočtové příděly (držitel, platnost, rozsah kmitočtů)
• sada Open data (bude specifikováno později)
• sada Kompletní (kompletní seznam všech přidělených IO či souhlasů – ambasády)
k pozdějšímu dalšímu zpracování
Formát a struktura sady bude jednoznačně definována s malými změnami v čase. Příznaky „export / bez exportu“ pro některé licence mohou být předmětem změny a mohou se tedy v čase lišit. Toto bude definováno na úrovni IO a kontrolováno příslušným administrátorem, přičemž bude bráno
v úvahu defaultní nastavení, tj. výchozí nastavení, které může být v případě potřeby upraveno během návrhu, ale i později u inovovaného systému. Viz požadavek 27.
27. Umožnit označení dat jako neveřejné
Znění požadavku
Umožnit označení vybraných dat jako neveřejných, které budou vyloučeny z exportu – viz požadavek č. 26.
Existují držitelé IO, o jejichž IO nesmí být veřejně dostupné informace. Filtrace IO musí umět probíhat na základě úrovně subjektu (tj. všechna IO konkrétního subjektu musí být z exportu vyloučena),
ale také na úrovni označení jednotlivých IO jednoho držitele (tedy, že v rámci jednoho držitele mohou existovat IO, jejichž údaje se zveřejní a také které se nesmí zveřejnit).
Předpokládaný způsob realizace
Inovovaný systém umožní označení vybraných dat jako neveřejných, které budou vyloučeny
z exportu.
Informace týkající se některých IO a jejich držitelů nejsou veřejné. Tato IO budou vyfiltrována
a vyloučena z exportu (např. všechny IO příslušného držitele). Omezení exportu pro zveřejňování bude možné také na úrovni patřičných licencí, tzn. někteří držitelé mohou držet jak veřejné, tak neveřejné IO.
Toto bude definováno na úrovni IO a kontrolováno příslušným administrátorem, přičemž bude bráno v úvahu defaultní nastavení, tj. výchozí nastavení, které může být v případě potřeby upraveno během návrhu, ale i později u nasazeného inovovaného systému.
28. Umožnit zveřejnění dat na webu Objednatele
Znění požadavku
Umožnit opakovaný automatický export dat, a to ve formátech CSV a XLSX v zadavatelem
definovaném čase na definované úložiště. De-facto se jedná o rozšíření požadavku č. 26 Umožnit export do CSV a XLSX. Exportovaná data musí naplňovat požadavky ZEK ohledně uveřejňování dat na webu Objednatele. Definice rozsahu exportovaných dat a struktura výstupního souboru bude
předmětem detailní analýzy. Neočekává se správa webových stránek Úřadu v rámci tohoto bodu. Viz požadavek č. 26 Umožnit export do CSV a XLSX.
Předpokládaný způsob realizace
Zveřejňování dat na webových stránkách Objednatele bude umožněno dle požadavků zákona
o elektronických komunikacích. Parametry datových sad pro zveřejnění bude možné definovat. Viz. požadavek č. 26.
Uvedený požadavek bude rozpracován během detailní analýzy resp. návrhové dokumentace
(HLDD/LLDD).
Implementace workflow správního řízení u žádosti
29. Implementovat workflow u procesů správy rádiového spektra
Znění požadavku
Požadavkem je implementovat workflow u klíčových procesů správy rádiového spektra, a to
v závislosti na příslušné radiokomunikační službě (pevná, pozemní pohyblivá, letecká pohyblivá,
rozhlasová, radioamatérská, družicová, radiolokační, radionavigační, námořní pohyblivá). Základní
procesy pak jsou: nové IO, odnětí IO, prodl. doby platnosti IO, odnětí z důvodu neplatících držitelů IO, technická/netechnická změna IO, změna držitele (převod) IO, zpětvzetí žádosti.
Upozornění: procesy stejného jména mohou v různých službách probíhat různým způsobem.
To znamená, že např. pro zpracování nové žádosti v různých službách existují rozdílná workflow.
Předpokládaný způsob realizace
Workflow pro klíčové procesy správy rádiového spektra bude poskytnuto, a to v závislosti na příslušné radiokomunikační službě (pevná, pozemní pohyblivá, letecká pohyblivá, rozhlasová,
radioamatérská, družicová, radiolokační, radionavigační, námořní pohyblivá). Základní procesy pak jsou: nové IO, odnětí IO, prodl. doby platnosti IO, odnětí z důvodu neplatících držitelů IO,
technická/netechnická změna IO, změna držitele (převod) IO, zpětvzetí žádosti.
Upozornění: procesy stejného jména mohou v různých službách probíhat různým způsobem. To znamená, že např. pro zpracování nové žádosti v různých službách existují rozdílná workflow.
V rámci návrhu bude představen koncept sub-workflows. Některá workflow mohou spadat pod jedno obecnější workflow se specifickými sub-workflows (např. odnětí z důvodů neplatících držitelů a
odnětí přidělení licence jako součást obecného workflow odnětí, aktualizace adresy jako sub- workfow netechnické změny).
Úprava technických parametrů, které se během technické analýzy ukáží jako špatně zadané, může být realizována pomocí wizardu nebo prostřednictvím workflow po přerušení technické analýzy
a před pokračováním ve workflow. Detailní řešení pomocí průvodce nebo pomocí workflow bude
předmětem diskuse a odsouhlasení v rámci detailní analýzy.
30. Umožnit administrátorům Objednatele provádět změny workflow při výjimkách
Znění požadavku
Umožnit administrátorům na straně Objednatele provést změny při výjimkách (většinu řízení lze řídit v rámci jednotného workflow pro danou radiokomunikační službu, existují ale specifické případy žádostí, které nelze zpracovat pomocí jednotného workflow). Inovovaný systém musí umožnit např.
přeskočení určitého stavu nebo prodloužení čekací doby v systému workflow, a to v závislosti na roli uživatele (osoba s příslušnými právy).
Předpokládaný způsob realizace
Systémový administrátor bude mít možnost ručně upravit zpracování workflow za účelem řízení procedurálních výjimek ve workflow systému (Camunda cockpit). Většina žádostí může být
zpracována v rámci standardního workflow pro daný typ služby, nicméně budou zde výjimky, kde standardní workflow nebude možné aplikovat.
Inovovaný systém umožní ve workflow systému (Camunda cockpit) workflow upravit, např. přeskočit určité podmínky nebo prodloužit čekací lhůty, nicméně pouze osobám s příslušným oprávněním.
31. Umožnit uložení rozpracované žádosti
Znění požadavku
Umožnit uložení rozpracované žádosti pro pozdější dopracování.
Umožnit uložení rozpracované činnosti v rámci workflow s tím, že se do úkonu může vrátit pouze dotčený uživatel (workflow bude uzamčeno jen pro něj). Odemknutí bude moc provést osoba
s příslušnými právy (nemusí být pouze administrátor).
Předpokládaný způsob realizace
Rozpracované žádosti bude možné uložit pro pozdější dopracování.
Uložení rozpracované činnosti v rámci workflow bude možné s tím, že se do úkonu může vrátit pouze dotčený uživatel (workflow bude uzamčeno jen pro něj). Odemknutí bude moc provést osoba
s příslušnými právy (nemusí být pouze administrátor).
32. Varovat před dlužníky
Znění požadavku
Implementace varování, že žadatel o udělení IO (či KO) je dlužníkem evidovaným u Objednatele –
komunikace s účetním systémem.
V předem definované části workflow (ale včetně možnosti zavolat ručně tuto kontrolu i mimo
workflow) proběhne komunikace s účetním systémem za účelem zjištění, zda je žadatel (budoucí
držitel IO) dlužníkem. Pokud by byla taková skutečnost identifikována, musí být uživatel informován varovným oknem. Workflow bude přerušeno. Pouze pokud by uživatel uvedl zdůvodnění, že chce pokračovat ve zpracování žádosti (např. varovné okno mu umožní stisknout tlačitko Pokračuj a dokud uživatel nedoplní nějaké znaky do pole pro zdůvodnění, systém by ho dále nepustil), systém by mu práci umožnil.
Současně je nutné, aby měl uživatel aktualizovanou zpětnou vazbu, že žadatel (budoucí držitel) již není dlužníkem a je možné v žádosti (workflow) pokračovat.
Předpokládaný způsob realizace
Bude implementováno varování, že žadatel o udělení IO či KO je dlužníkem u Objednatele. Toto
vyžaduje zajištění komunikace mezi inovovaným systémem a účetním systémem.
V předem definované části workflow (ale včetně možnosti zavolat ručně tuto kontrolu i mimo
workflow) proběhne komunikace s účetním systémem za účelem zjištění, zda je žadatel (budoucí držitel IO) dlužníkem. Pokud ano, musí být uživatel informován varovným oknem. Workflow bude přerušeno. Pouze pokud by uživatel uvedl zdůvodnění, že chce pokračovat ve zpracování žádosti (např. varovné okno mu umožní stisknout tlačitko Pokračuj a dokud uživatel nedoplní nějaké znaky do pole pro zdůvodnění, systém by ho dále nepustil), inovovaný systém by mu práci umožnil.
Současně je nutné, aby měl uživatel aktualizovanou zpětnou vazbu, že žadatel (budoucí držitel) již není dlužníkem a je možné v žádosti pokračovat.
33. Validovat zadávané údaje
Znění požadavku
Implementace validace zadávaných údajů uživatelem podle stanovených kritérií.
Toto souvisí se vstupními formuláři, kdy je nezbytné definovat pro všechny služby včetně podslužeb jaká pole se mají evidovat, v jaké posloupnosti a jaká jsou kritéria validace (jak z hlediska tvrdé, tak
i měkké validace). Výsledkem validace může být buď upozornění, že vložená data se nezdají korektní (a pokud uživatel správnost potvrdí, proces bude pokračovat), nebo že vložená data jsou mimo povolené hodnoty (a proces pokračovat nebude, dokud uživatel vadná data neopraví). Příklady požadované funkcionality validace:
• Validace údajů v rozsahu validace implementované v současném DET pro Pevnou službu
a v DET pro PPS
• Informace o žadateli jsou v souladu s SKS
• Souřadnice stanoviště je na území ČR (musí být však umožněna výjimka při tzv. přeshraničních spojích – již dnes existuje v DET pro pevnou službu)
• Uživatelem vložená nadmořská výška stanoviště odpovídá/neodpovídá nadmořské výšce
pro zadané souřadnice podle DMT (digitální model terénu)
• Souřadnice stanovišť terminálů spadají/nespadají do servisních oblastí
• Atd.
Konečný rozsah validovaných údajů a pravidel validace bude stanoven během detailní analýzy.
Předpokládaný způsob realizace
Bude implementována validace zadávaných údajů uživatelem podle stanovených kritérií.
Zadávané údaje budou ověřeny na základě kritérií stanovených individuálně pro různé služby. V rámci návrhu budou pro každou službu zároveň definována validační kritéria, datová pole k validaci
a sekvence validace. Budou aplikována „měkká“ a „tvrdá“ validační kritéria.
34. Integrovat odesílací funkcionalitu s elektronickým vzorem
Znění požadavku
Integrace odesílací funkcionality (prostřednictvím Ginis), případně napojení kroků workflow na nutnost připojit finální elektronický vzor obecného rozhodnutí či usnesení o zpětvzetí.
V rámci workflow musí být umožněno připojit výstup (např. nové IO), ale i případné další podklady, které nebyly generovány systémem (např. externí soubory, naskenované dokumenty).
Předpokládaný způsob realizace
Bude integrována odesílací funkcionalita (Ginis – viz požadavek č. 10), případně napojení kroků
workflow na nutnost připojit finální elektronický vzor obecného rozhodnutí či usnesení o zpětvzetí.
Výstupní dokumenty (např. IO) stejně tak jako jakékoliv jiné dokumenty relevantní k procesům (externí soubory, naskenované dokumenty) budou moci být připojeny k žádosti příslušnými kroky workflow.
Uvedený požadavek bude rozpracován během detailní analýzy resp. návrhové dokumentace
(HLDD/LLDD).
35. Validovat žádost dle SPECTRAplan
Znění požadavku
Implementace validace, zda je vybraný rádiový kmitočet přidělitelný, a to podle údajů ze SPECTRAplan. Kontrola, zda je kmitočet v rámci rastru. Dále, v rámci worflow po zadání doby
platnosti IO signalizovat, pokud je překročena doba přidělitelnosti podle SPECTRAplan. Pokud je
překročena, umožnit i tak pokračovat uživateli ve zpracování žádosti ovšem pouze za předpokladu, že ručně uvede důvod, proč pokračuje v procesu přidělování.
Validace může také probíhat na základě prostorového omezení (prostor definovaný vektorem –
vektory jsou momentálně rovněž evidovány ve SPECTRAplan.)
Pozn.: požadavky na SPECTRAplan mohou být ovlivněny realizací požadavku č. 59 Zajistit evidenci
přídělů rádiových kmitočtů a č. 65 Výběr kmitočtů mimo rastr, neboť realizace požadavku č. 59 Zajistit
evidenci přídělů rádiových kmitočtů tématicky s problematikou SPECTRAplan souvisí.
Předpokládaný způsob realizace
Validace, zda je vybraný rádiový kmitočet přidělitelný, bude poskytována dle údajů ze SPECTRAplan. Bude prováděna kontrola, zda je kmitočet v rámci rastru.
Dále, v rámci worflow po zadání doby platnosti IO bude signalizace, pokud je překročena doba přidělitelnosti podle SPECTRAplan. Pokud je překročena, umožnit i tak pokračovat uživateli ve
zpracování žádosti ovšem pouze za předpokladu, že ručně uvede důvod, proč pokračuje v procesu přidělování.
Uvedený požadavek bude rozpracován během detailní analýzy resp. návrhové dokumentace
(HLDD/LLDD).
36. Validovat přidělování volacích značek
Znění požadavku
Implementace validace, zda je vybraná volací značka unikátně přidělená v rámci IO či zda byl obdržen souhlas s jejím přidělením jinému držiteli IO. Validace musí proběhnout současně s časovou rezervací značky po vypršení doby platnosti IO, a to včetně implementace výjimek (např. volací značku lze
udělit členům rodiny, příbuzným).
Kromě validace na tvar a formát volací značky je nezbytné evidovat, zda je značka již přidělena
a pokud ne, jaký byl poslední okamžik její platnosti (tj. okamžik odeslání IO do archivu bez navazujícího kroku netechnické změny nebo prodloužení doby platnosti). Existuje totiž ochranná
lhůta po kterou v minulosti použitou volací značku nelze znovu použít. Uživateli však musí být umožněno i přes tuto validaci protlačit přidělení takové značky, a to v odůvodněných případech.
Pokud by taková situace nastala, uživatel musí být v rámci kontroly použití značky informován
a nabídnuta mu možnost pokračovat ve workflow, pokud uveden alespoň nějaký znak v odůvodnění pokračování.
Předpokládaný způsob realizace
Bude implementována validace, zda je vybraná volací značka unikátně přidělená v rámci IO či zda byl obdržen souhlas s jejím přidělením jinému držiteli IO. Validace musí proběhnout současně s časovou rezervací značky po vypršení doby platnosti IO, a to včetně implementace výjimek (např. volací značku lze udělit členům rodiny, příbuzným).
Kromě validace na tvar a formát volací značky se bude evidovat, zda je značka již přidělena a pokud ne, jaký byl poslední okamžik její platnosti (tj. okamžik odeslání IO do archivu bez navazujícího kroku netechnické změny nebo prodloužení doby platnosti). Existuje totiž ochranná lhůta po kterou v
minulosti použitou volací značku nelze znovu použít. Uživatel mySPECTRAoffice však bude moci
v odůvodněných případech takovou volací značku přidělit. Pokud by taková situace nastala, uživatel musí být v rámci kontroly použití značky informován a nabídnuta mu možnost pokračovat ve workflow, pokud uvede nějaké odůvodnění.
37. Validovat platnosti IO – dobu platnosti, držitele, žadatele a licence RRTV
Znění požadavku
Implementovat validaci vložených dat. Výsledkem validace může být buď upozornění, že vložená data se nezdají korektní (a pokud uživatel správnost potvrdí, proces bude pokračovat), nebo že vložená data jsou mimo povolené hodnoty (a proces pokračovat nebude, dokud uživatel vadná data
neopraví).
Příklady požadované funkcionality validace týkající se doby platnosti IO:
• Datum platnosti IO nepřesahuje 5 let (výjimka pro IO o které žádá držitel přídělu v pásmu, kde je tento příděl evidován)
• Datum platnosti KIO nepřesahuje 15 dnů
• Žadatelem je subjekt, který smí zadaný kmitočet požadovat (např. s ohledem na vystavené kmitočtové příděly a možnosti jejich sdílení nebo s ohledem na přidělené licence RRTV) – viz také další detaily v částech popisující evidenci přídělů rádiových kmitočtů
Konečný rozsah validovaných údajů a pravidel validace bude stanoven během detailní analýzy.
Předpokládaný způsob realizace
Proces vkládání dat v mySPECTRA a uvnitř workflow procesů umožní aplikaci validačních pravidel. V obecné rovině jsou workflow a přidružená validační pravidla konfigurovatelná a mohou být odpovídajícím způsobem přizpůsobena.
38. Umožnit opravy po výpočtu ročního poplatku
Znění požadavku
Umožnit opravy vypočteného ročního poplatku za využívání rádiových kmitočtů – komunikace s účetním systémem.
V rámci workflow dojde mj. i k výpočtu ročního poplatku za využívání rádiových kmitočtů. Poplatek musí být možné změnit, pokud uživatel usoudí, že byla vygenerována špatná hodnota. V případě změny musí žadatel uvést důvod. Bez uvedení důvodu jej inovovaný systém nepustí dále.
K přepočtení poplatku musí dojít i po úpravě vložených technických parametrů.
Při změně předpisu pro výpočet poplatku (v důsledku změny nařízení vlády) je třeba hromadně zneplatnit původní platební výměry a vypočítat výměry nové. Pro tyto případy budou předem
definována jasná pravidla (nezbytné ochranné lhůty, způsob vyřizování uhrazených/neuhrazených poplatků v případě, že se výše poplatku mění).
Předpokládaný způsob realizace
Dříve vypočtené roční poplatky za využívání rádiových kmitočtů bude možné upravovat (vyžaduje
komunikaci s účetním systémem).
V rámci workflow dojde mj. i k výpočtu ročního poplatku za využívání rádiových kmitočtů. Poplatek musí být možné změnit, pokud uživatel usoudí, že byla vygenerována špatná hodnota. Toto bude představovat jeden z kroků workflow. V případě změny musí žadatel uvést důvod. Bez uvedení důvodu jej inovovaný systém nepustí dále.
K přepočtení poplatku musí dojít i po úpravě vložených technických parametrů, či jako úprava nebo změna workflow.
Hromadné rekalkulace ročních poplatků (v důsledku změny nařízení vlády) budou možné. Dřívější výměra poplatků bude zneplatněna a pro příslušné licence budou vydány nové výměry.
Pro tyto případy budou během detailní analýzy definována pravidla (např. ochranné lhůty, jak nakládat se zaplacenými či nezaplacenými poplatky, pokud se poplatek zvýší nebo sníží).
39. Umožnit propojení se správním poplatkem
Znění požadavku
Umožnit propojení platby se správním poplatkem.
Jedním z kroků workflow je i kontrola s účetním systémem, zda byl uhrazen správní poplatek. Bude nutné stanovit parametr pro identifikaci platby (např. ID platby - variabilní symbol). Inovovaný
systém musí umět i rozpojit poplatek, pokud byla omylem spárovaná jiná platba. Uhrazení správního poplatku může být provedeno i kolkem.
Předpokládaný způsob realizace
Inovovaný Systém umožní propojení platby se správním poplatkem.
Jedním z kroků workflow bude i kontrola s účetním systémem, zda byl uhrazen správní poplatek.
Bude nutné stanovit parametr pro identifikaci platby (např. ID platby - variabilní symbol). V detailní analýze bude určen způsob jak rozpojit poplatek, pokud byla omylem spárovaná jiná platba. Toto však bude významně závislé na dostupné funkcionalitě rozhraní účetního systému.
Uhrazení správního poplatku může být provedeno i kolkem.
40. Uživatelská přívětivost rozhraní a workflow
Znění požadavku
GUI bude umožňovat:
1. mySPECTRA bude disponovat možnostmi klávesových zkratek – shortcuts (vč. potvrzení tlačítek mezerníkem, vyskakování pomocí klávesy ESC atd.)
2. standardní použití klávesy TAB (Tab sequences) při přecházení mezi jednotlivými zadávanými políčky či logickými / tematickými oddíly
3. v co největší míře eliminovat potřebu klikání myší a přesuny obrazovek kurzorem myši
4. uživatel musí mít stále možnost vrácení rozpracovného workflow nebo wizardu zpět do bodu, kde bude možné upravit vložená data a workflow projít znovu
Předpokládaný způsob realizace
Pro body 1, 2 a 3: cílem bude eliminovat potřebu klikat, scrollovat a pohybovat kurzorem myši. Bude potřeba detailní analýza.
Pro bod 4.: úprava technických parametrů, které se během technické analýzy ukáží jako špatně zadané, může být realizována pomocí wizardu nebo prostřednictvím workflow po přerušení
technické analýzy a před pokračováním ve workflow. Detailní řešení pomocí průvodce nebo pomocí workflow bude předmětem diskuse a odsouhlasení v rámci detailní analýzy.
41. Umožnit přidání Ad-hoc rozhodnutí k IO
Znění požadavku
Možnost přidání rozhodnutí k IO, které není generováno inovovaným systémem podle tiskových šablon.
Viz požadavek č. 13 a č. 34.
Předpokládaný způsob realizace
V inovovaném Systému bude možné přidání rozhodnutí k IO, které není generováno inovovaným
systémem podle tiskových šablon. Viz požadavek č. 13 a č. 34.
42. Zajistit ošetření záznamů mezinárodní koordinace
Znění požadavku
Ošetření záznamů mezinárodní koordinace, a to ve formě možnosti zachovat výsledky mezinárodní koordinace při změně držitele IO nebo jiných změnách, v jejichž důsledku je nutno vydat nové IO, ale podmínky mezinárodní koordinace se nemění. Obdobně zajistit návaznost při prodlužování doby platnosti IO.
Předpokládaný způsob realizace
Bude možné ošetření záznamů mezinárodní koordinace, a to ve formě možnosti zachovat výsledky mezinárodní koordinace při změně držitele IO nebo jiných změnách, v jejichž důsledku je nutno vydat nové IO, ale podmínky mezinárodní koordinace se nemění. Obdobně zajistit návaznost při
prodlužování doby platnosti IO tak, jak je zajištěno v stávajícím systému SPECTRA (stav k září 2020).
43. V modulu SPECTRAemc umožnit automatizaci provedení wizardů
Znění požadavku
V rámci pevné radiokomunikační služby implementovat v modulu SPECTRAemc možnost plné
automatizace provedení wizardů včetně souvisejících úprav v mySPECTRA.
Předpokládaný způsob realizace
V rámci pevné radiokomunikační služby bude v modulu SPECTRAemc implementována možnost plné automatizace provedení wizardů včetně souvisejících úprav v mySPECTRA.
44. Umožnit UNDO a doplnění poznámky u archivovaných IO
Znění požadavku
Umožnit provádění následujících úkonů s archivovanými IO: akce typu UNDO v případě odeslání IO do archivu IO; doplnění poznámky (AP_COMMENT) k archivovanému oprávnění. V rámci detailní analýzy zhodnotit alternativní přístup, tedy, že požadavek na UNDO lze vyřešit i např kontrolou
provedení nevratných metaakcí, jako je archivace IO, a umožnit je pouze autorizovaným uživatelům, pokud jsou splněny definované předpoklady (např. není platné žádné stanovení poplatků, nebyly
provedeny určité kroky workflow atd.).
Předpokládaný způsob realizace
Pro archivované IO bude možné provést akci UNDO, bude možné přidat též poznámky
k archivovanému oprávnění.
V rámci detailní analýzy bude nutné zhodnotit alternativní přístup, tedy, že požadavek na UNDO lze vyřešit i např. kontrolou provedení nevratných metaakcí, jako je archivace IO, a umožnit je pouze autorizovaným uživatelům, pokud jsou splněny definované předpoklady (např. není platné žádné stanovení poplatků, nebyly provedeny určité kroky workflow atd.).
Implementace algoritmu pro výpočet ročního poplatku
a správního poplatku
45. Zajistit soulad s nařízením vlády č. 154/2005 Sb.
Znění požadavku
Algoritmus výpočtu platebního výměru bude v souladu s nařízením vlády č. 154/2005 Sb. o stanovení výše a způsobu výpočtu poplatků za využívání rádiových kmitočtů a čísel. Z důvodu zabránění
pochybností se podoba a rozsah nařízení vlády č. 154/2005 Sb. uvažuje ke dni podepsání smlouvy
o dílo a tuto podobu zaimplementuje Zhotovitel.
Odpovědnost a možnost provedení změn ve způsobu zpoplatnění (změna poplatků) bude na straně Objednatele a systém musí být dostatečně konfigurovatelný, aby umožňoval aktualizaci změn
administrátorů na straně Objednatele bez potřeby změny zdrojového kódu inovovaného systému.
Předpokládaný způsob realizace
Algoritmus bude v souladu s nařízením vlády č. 154/2005 Sb. o stanovení výše a způsobu výpočtu poplatků za využívání rádiových kmitočtů a čísel.
Zhotovitel předá zodpovědnost a vlastnictví za případy změn poplatků, a systém bude dostatečně konfigurovatelný, aby umožnil aktualizaci změn adminstrátorem bez zásahu do kódu.
Detaily nařízení budou vyjasněny během detailní analýzy a mohou vyžadovat též bližší specifikaci někerých detailů ze strany Objednatele.
46. Ve workflow zadefinovat pozici výpočtu ročního poplatku
Znění požadavku
Možnost zadefinovat pozici vypočtení ročního poplatku za využívání rádiových kmitočtů ve workflow, a to ještě před samotným tiskem/generováním IO.
Předpokládaný způsob realizace
Bude možno zadefinovat pozici vypočtení ročního poplatku za využívání rádiových kmitočtů
ve workflow, a to ještě před samotným tiskem/generováním IO.
47. Umožnit konfiguraci výpočtu ročního poplatku administrátorským zásahem
Znění požadavku
Inovovaný systém bude umět, přinejmenším administrátorským zásahem na straně Objednatele, nakonfigurovat výpočet ročního poplatku způsobem zahrnujícím všechny zákonné požadavky (viz nařízení vlády č. 154/2005 Sb.).
Předpokládaný způsob realizace
Inovovaný systém bude umět, přinejmenším administrátorským zásahem, nakonfigurovat výpočet
ročního poplatku způsobem zahrnujícím všechny zákonné požadavky (viz nařízení vlády č. 154/2005 Sb.), a to za předpokladu, že odsouhlasená struktura IO a konfigurace výpočtu takové detaily umožní.
48. Umožnit uživateli přístup k vypočtenému ročnímu poplatku
Znění požadavku
Umožnit k vypočtenému ročnímu poplatku přímý přístup uživateli bez nutnosti jej složitě hledat.
Předpokládaný způsob realizace
Inovovaný systém umožní uživateli mySPECTRA přímý přístup k vypočtenému ročnímu poplatku.
49. Zajistit vyhodnocení a propojení správního poplatku s IO systémem
Znění požadavku
Potřeba, aby inovovaný systém sám vyhodnotil výši správního poplatku podle vybraného úkonu (např. nové IO, prodloužení doby platnosti stávajícího IO) a typu radiokomunikační služby a umožnil propojení správního poplatku s IO či správním rozhodnutím (typicky prodloužení doby platnosti).
Předpokládaný způsob realizace
Výše správního poplatku bude automaticky vyhodnocena podle vybraného úkonu (např. nové IO, prodloužení doby platnosti stávajícího IO) a typu radiokomunikační služby. Propojení správního
poplatku s IO či správním rozhodnutím (typicky prodloužení doby platnosti) bude definováno pravidly a příslušným workflow.
Podpora číselníků volacích značek
50. Vytvořit číselníky přidělených volacích značek
Znění požadavku
Vytvořit číselníky/seznamy přidělených volacích značek v inovovaném systému pro radiokomunikační služby námořní pohyblivou, MMSI kódy, pozemní pohyblivou, leteckou pohyblivou, amatérskou
a rozhlasovou.
Mechanizmus přidělení volacích značek se liší mezi službami (námořní, amatérská, letecká atd.):
• námořní služba (pobřežní stanice, lodní stanice): MMSI kódy, volací znaky
• pozemní pohyblivá služba (fónické sítě): tvar volací značky závisí podle lokality žadatele a účelu použití značky
• letecká pohyblivá služba (letadlová stanice; letecká stanice): je dopředu známa poznávací značka letadla a na základě ní je vytvořena volací značka. V případě letecké stanice může být v rámci IO více volacích znaků vč. vícero přidělených kmitočtů
• amatérská služba: pravidla tvaru volací značky blíže specifikuje Vyhláška (155/2005 Sb.)
• rozhlasová služba: identifikátory pro DTV, DAB a PI kódy pro VKV FM vysílání Základní funkcionality:
• ověření syntaxe nové značky
• kde se ukáže během detailní analýzy, tam generovat podle definovaných pravidel volací značky automaticky
• validace k zabránění duplicitnímu využití značky (značka/kód se uvádí na IO, nepřiděluje
se samostatným dokumentem)
• aplikace ochranné lhůty - viz také požadavek č. 36
• možnost generování seznamu přidělených volacích značek či kódů a to včetně značek a kódů v ochranné lhůtě (tj. těch, které nelze přidělit jinému, než poslednímu držiteli či pouze
na základě jeho souhlasu)
Předpokládaný způsob realizace
Číselníky/seznamy přidělených volacích značek budou vytvořeny v inovovaném systému pro
radiokomunikační služby námořní pohyblivou, MMSI kódy, pozemní pohyblivou, leteckou pohyblivou, amatérskou a rozhlasovou. Přesná konfigurace volacích značek bude ujasněna v rámci detailní analýzy.
51. Automaticky generovat ATIS a MMSI kódy
Znění požadavku
Implementace automatického generování ATIS kódů a MMSI kódů v námořní pohyblivé službě
a kontrola duplicit. Automatické generování kódu bude vycházet ze stávající databáze a budou stanovena pravidla pro generování těchto kódů. Generování vezme v úvahu již přidělené značky.
Předpokládaný způsob realizace
Bude implementováno automatické generování ATIS kódů a MMSI kódů v námořní pohyblivé službě
a kontrola duplicit. Automatické generování bude vycházet ze stávající databáze.
Zachování číselníků a kartoték
52. Zachovat stávající číselníky a kartotéky (Rádiová zařízení, Antény, Stanoviště,
Adresy)
Znění požadavku
Je požadováno zachovat stávající číselníky a kartotéky, které musí být přístupné z inovovaného systému a jednotlivých procesů workflow. Jedná se o tyto číselníky/kartotéky: Rádiová zařízení, Antény, Stanoviště, Adresy, Satelity.
Předpokládaný způsob realizace
Stávající číselníky a kartotéky budou zachovány a udržovány. Budou přístupné z inovovaného Systému a jednotlivých procesů workflow. Jedná se o tyto číselníky/kartotéky: Rádiová zařízení, Antény, Stanoviště, Adresy, Satelity.
53. Umožnit evidenci nájemce IO
Znění požadavku
Umožnit v detailech IO evidenci nájemce tohoto IO (pronájem IO) a to včetně evidence uděleného
souhlasu Objednatelem nájemci.
Předpokládaný způsob realizace
V případě pronájmu IO bude bude nájemce detailně evidován, a to včetně uděleného souhlasu
Objednatelem nájemci.
Uvedený požadavek bude rozpracován během detailní analýzy resp. návrhové dokumentace
(HLDD/LLDD).
Školení uživatelů
54. Zajistit školení uživatelů
Znění požadavku
Provést školení uživatelů a správců inovovaného systému. Detaily jsou uvedeny ve smluvní
dokumentaci.
Předpokládaný způsob realizace
Bude provedeno školení uživatelů a správců inovovaného systému. Detaily jsou uvedeny ve smluvní
dokumentaci.
Dokumentace inovovaného systému
55. Dodat dokumentaci inovovaného systému
Znění požadavku
Dodat dokumentaci inovovaného systému. Detaily jsou uvedeny ve smluvní dokumentaci.
Předpokládaný způsob realizace
Bude dodána dokumentace inovovaného systému. Detaily jsou uvedeny ve smluvní dokumentaci.
Ostatní požadavky
56. Umožnit uložit více druhů vysílání u rádiového zařízení
Znění požadavku
V pozemní pohyblivé službě vzít v úvahu, že zařízení může mít více druhů vysílání. Je tak požadována možnost uložit více druhů vysílání u rádiového zařízení.
Předpokládaný způsob realizace
V pozemní pohyblivé službě bude vzato v úvahu, že zařízení může mít více druhů vysílání (druh vysílání). Bude umožněno uložit více druhů vysílání u rádiového zařízení.
57. Plnohodnotně nahradit stávající nástroj Vykuk
Znění požadavku
Plnohodnotná či lepší náhrada stávajícího nástroje Vykuk (z hlediska funkcí, přehledu a doby trvání hledání/dotazu, možností exportu vyhledaných údajů, doby vytvoření/zadání dotazu apod.).
Implementace vyhledávání IO na základě vyplnění formuláře s přibližně 60 vyhledávacími kriterií
s důrazem na rychlost vyhledávání.
Předpokládaný způsob realizace
Lokální data prohlížeče VYKUK budou nahrazena nativním nástrojem se stejnými nebo lepšími vlastnostmi (z hlediska funkcí, přehledu a doby trvání hledání/dotazu, možností exportu vyhledaných údajů, doby vytvoření/zadání dotazu apod.).
Vyhledávání bude založeno na vyplněných datech do formulářových polí s předdefinovanými vyhledávacími kritérii. Bude zajištěna velmi krátká reakční doba..
58. Umožnit správu rádiových kmitočtů pro vojenské účely
Znění požadavku
Podpora rádiových kmitočtů pro vojenské účely s cílem umožnit využívání rádiových kmitočtů
na základě IO a to se specifickými požadavky na výši zpoplatnění.
Jedná se o analogii k udělování jiných běžných IO. Od běžného IO se toto IO liší pouze jedním příznakem, který indikuje, že není zpoplatněno. Souvisí také s požadavky č. 26 a č. 27.
Bez zpoplatnění za využívání RK.
Předpokládaný způsob realizace
Inovovaný systém bude podporovat udělování IO pro vojenské účely s ohledem na specifické požadavky při stanovování výše zpoplatnění.
Označení IO pro vojenské účely bude zajištěno specifickým parametrem při zadávání vstupních infromací. Workflow bude identické jako u standardních IO.
59. Zajistit evidenci přídělů rádiových kmitočtů
Znění požadavku
Výsledem výběrových řízení, která jsou vedena mimo systém SPECTRA (a není záměrem tato výběrová řízení v inovovaném systému v budoucnu vést) jsou tzv. příděly rádiových kmitočtů.
V přídělu rádiových kmitočtů je uveden kmitočtový úsek, který je přidělen konkrétnímu držiteli, doba platnosti přídělu rádiových kmitočtů a dále podmínky přidělení (např. rozvojová kritéria výstavby 5G sítí, zda může být kmitočtový úsek sdílen s ostatními uživateli spektra apod.). Pro plnohodnotnou funkci tohoto požadavku je nutné zajistit, aby byl systém schopen níže uvedené údaje evidovat (např. prostřednitcvím SPECTRAplan):
• kmitočtový úsek přídělu rádiových kmitočtů
• radiokomunikační službu, ve které došlo k udělení
• držitele tohoto přídělu rádiových kmitočtů
• dobu platnosti přídělu rádiových kmitočtů
• zda mohou být kmitočty z kmitočtového úseku sdíleny
Inovovaný systém pak musí umět rozlišit, že žadatelem požadované kmitočty:
• se nacházejí v kmitočtovém úseku, kde byl udělen příděl rádiových kmitočtů (samotné
udělení přídělu rádiových kmitočtů bylo však řešeno mimo inovovaný systém) a pokud ano,
tak
• ověřit, že uživatelem nastavená doba platnosti IO je v souladu s dobou platnosti přídělu rádiových kmitočtů (jak při udělení nového IO, tak při jeho změně či prodloužení doby platnosti) a dále
• ověřit, že žadatelem je držitel přídělu rádiových kmitočtů. Pokud je žadatelem jiný subjekt než držitel přídělu rádiových kmitočtů, vyvolat dotaz, zda žadatel disponuje souhlasem s udělením IO. Pokud je ale umožněno sdílení, dotaz nevyvolávat a udělení IO přímo umožnit.
Předpokládaný způsob realizace
Příděly rádiových kmitočtů budou evidovány v inovovaném systému, nebo (volitelně) v systému SPECTRAplan (radiokomunikační služba, držitel přídělu).
Uvedený požadavek bude rozpracován během detailní analýzy resp. návrhové dokumentace
(HLDD/LLDD).
60. Zajistit evidenci a vystavování souhlasů zahraničních ambasád
Znění požadavku
Implementace podpory evidence a vystavování tzv. souhlasů v návaznosti na požadavky zahraničních ambasád.
V systému je nutné rozlišit, že se jedná o souhlas, nikoliv IO.
Obecné parametry, jako doba platnosti, případně zpoplatnění (není-li uplatňován princip reciprocity), držitel souhlasu, technické parametry, jsou zadávány stejně jako u normálního IO v dotčené službě.
Technické parametry jsou obdobně jako IO předmětem technické analýzy (koordinace). Bude nutná dílčí úprava existujících tiskových šablon.
Je nutné rozlišení, zda je vyžadován poplatek za využívání RK či nikoliv.
Stávající praxe je, že jsou souhlasy vedeny v systému SPECTRAplus jako klasická IO a dochází k tisku souhlasu s využitím Wordu. Cílem je v inovovaném systému umožnit rozlišit, že se jedná o souhlas, nikoliv o klasické IO a upravit tiskové sestavy ze stávajících tiskových šablon (PPS, pevná služba,
družicová služba).
Předpokládaný způsob realizace
Uvedený požadavek bude rozpracován během detailní analýzy resp. návrhové dokumentace (HLDD/LLDD).
61. Logovat změny existujících záznamů v databázi
Znění požadavku
Implementace logování v případě změny již existujících záznamů v databázi, a to včetně požadavku na uvedení důvodu změny uživatelem. V úvahu se vezme dopad na odezvu, velikost databáze
a výkonnost systému. Viz požadavek č. 22.
Předpokládaný způsob realizace
V obecné rovině mySPECTRA umožní historický pohled na změny dat v databázi.
V obecné rovině bude sledování změn omezené a nebude defaultně dostupné pro všechna databázová pole, a to za účelem zajištění výkonnosti systému (velikost DB, DB dotazování).
62. Zajistit Early Life Support / On-site Support
Znění požadavku
Po nasazení inovovaného systému do produkčního provozu zajistit období zvýšené podpory. Detaily jsou uvedeny ve smluvní dokumentaci (Příloha č. 2 Smlouvy o Dílo – Akceptační řízení).
Předpokládaný způsob realizace
Po nasazení inovovaného systému do produkčního provozu bude zajištěno období zvýšené podpory.
Detaily jsou uvedeny ve smluvní dokumentaci.
63. Provést testování
Znění požadavku
Zajistit testování systému. Další detaily jsou uvedeny ve smluvní dokumentaci (Příloha č.2 Smlouvy o Dílo – Akceptační řízení).
Předpokládaný způsob realizace
Bude zajištěno testování systému. Detaily jsou uvedeny ve smluvní dokumentaci.
64. Výběr kmitočtů mimo rastr
Znění požadavku
V případě PPS je velké množství situací (ročně několik stovek), kdy, zejména to platí pro krátkodobá IO, je zahraničními subjekty požadováno jiné kanálování (šířky kanálů a jejich středy) i duplexní odstupy, než jaké je používáno v ČR. Slíbená „dynamická alokace“, která byla původně navržena
LS telcom, byla následně označena jako „komplikovaná“ a nerealizovala se, aniž by byla vybrána jiná plnohodnotná alternativa.
Výše popsaná situace stále přetrvává, je tedy požadováno stále vytvoření buď „dynamické alokace“ či jiné plnohodnotné a smysluplné alternativy. Současně je však nutné vzít v úvahu to, že v případě technické analýzy při běhu wizardu si SPECTRAemc natahává informace ze SPECTRA. Funguje to
podle čísla kanálu v alokaci SPECTRAplan, nikoliv podle nominální hodnoty kmitočtu. Při řešení je tak nutné ověřit, zda není nutná i úprava wizardů v PPS. Analogická situace je i v pevné službě.
Předpokládaný způsob realizace
Uvedený požadavek bude rozpracován během detailní analýzy resp. návrhové dokumentace
(HLDD/LLDD).
65. Import/Export v ostatních službách
Znění požadavku
Je požadováno, aby inovovaný systém uměl provést export/import v ostatních službách, nejen
v pevné a rozhlasové službě.
Viz Požadavek č. 12 SPECTRAexhange essential a požadavek ID 8 SPECTRAemc a CHIRplus_BC.
Předpokládaný způsob realizace
Viz Požadavek č. 12 SPECTRAexhange essential a požadavek ID 8 SPECTRAemc a CHIRplus_BC.
66. Řešení problematiky průkazů odborné způsobilosti pro amatérskou službu
Znění požadavku
Setrvává požadavek na udělení IO v amatérské službě pouze těm žadatelům, kteří jsou držitelem
průkazu odborné způsobilosti. Očekávají se dvě workflow. První workflow bude na udělení průkazu odborné způsobilosti a jeho evidence v DB SPECTRA (využije se stávající tisková šablona, která je již implementována). Průkaz odborné způsobilosti je nyní veden již v DB SPECTRA, ale je uložen spolu s uděleným IO.
Druhé workflow se bude týkat udělení IO, kdy jedním z kroků je ověření, zda má žadatel průkaz odborné způsobilosti (viz výsledek workflow č. 1).
V rámci migrace dat/kontroly datové struktury je nutné vzít na vědomí, že v tuto chvíli je evidence průkazů odborné způsobilosti vedena na úrovni IO a neexistují pro průkazy odborné způsobilosti samostatné záznamy v databázi. Tyto záznamy budou muset vzniknout překlopením informací
z existujících IO z DB SPECTRA (informace existuje, pouze je vedena v jednom záznamu IO).
Předpokládaný způsob realizace
Uvedený požadavek bude rozpracován během detailní analýzy resp. návrhové dokumentace
(HLDD/LLDD).
67. Zpracování žádostí RRTV pomocí workflow
Znění požadavku
V rozhlasové službě existuje situace, která je iniciována Radou pro Rozhlasové a Televizní vysílání (RRTV). Tato RRTV zadá Objednateli požadavek na provedení kmitočtové koordinace FM vysílače. Smyslem je v rámci národní i mezinárodní kmitočtové koordinace nalézt volný kmitočet a hodnotu tohoto kmitočtu s technickými parametry uložit v DB SPECTRA (výkon, stanoviště, kmitočet, výška antény). Momentálně si výsledek koordinace Objednatel ukládá pouze v systému RadioLab.
Kmitočet a základní technické parametry následně Objednatel předá formou dopisu zpět do RRTV, která vystaví tzv. FM licenci provozovateli FM vysílače.
V okamžiku, kdy se provozovatel FM vysílače rozhodne požádat o udělení IO, obrátí se na
Objednatele s žádostí o udělení IO. Objednavatel zkoumá, zda je shoda mezi jeho žádostí
a zkoordinovanými údaji. Pokud ano a v minulosti byl nalezen volný kmitočet, udělí se nové IO. Pokud byly identifkovány rozdíly (přesunutí lokality FM vysílače, změna antény či výkonu apod.), je nutná nová kmitočtová koordinace (národní i mezinárodní).
Odlišností této situace oproti standardnímu průběhu vyřízení žádosti o IO je to, že je třeba zaznamenat v DB SPECTRA výsledek akce na základě žádosti RRTV (kmitočet, stanoviště, apod.) –
k udělení IO ale v ten okamžik ještě nedochází. Výsledek je také neveřejný a není zveřejněn na webu
Objednatele.
Předpokládaný způsob realizace
Uvedený požadavek bude rozpracován během detailní analýzy resp. návrhové dokumentace
(HLDD/LLDD).
Přílohy
Příloha 1 – Statistika spouštění činností/akcí ve SPECTRAplus za posledních
20 let užívání
AC_ID | LTX_TEXT | Počet spuštění | První použití | Poslední použití |
1032007 | o Complete Request | 364 944 | 26.07.2000 | 29.05.2020 |
1032806 | o Print Report "E" without Assessment | 246 661 | 15.08.2000 | 29.05.2020 |
1032034 | o Start Recurring Invoicing | 132 801 | 27.06.2005 | 29.05.2020 |
-2 | > Start (o Duplicate Request) | 127 339 | 21.01.2005 | 29.05.2020 |
1032020 | o Grant License | 121 220 | 17.07.2001 | 29.05.2020 |
1053007 | o Complete Request | 103 840 | 18.04.2001 | 29.05.2020 |
1032035 | o Check Costs | 95 565 | 22.02.2002 | 29.05.2020 |
1053806 | o Print Report "E" without Assessment | 86 842 | 18.04.2001 | 29.05.2020 |
1032006 | o Duplicate Request | 76 753 | 27.07.2000 | 28.05.2020 |
1032004 | o Send to Archive | 61 362 | 06.11.2000 | 29.05.2020 |
1080021 | o Print License | 51 874 | 03.04.2000 | 28.04.2020 |
1080007 | o Complete Request | 50 497 | 31.03.2000 | 28.05.2020 |
1032602 | Cancellation - Print Decision | 45 763 | 23.04.2007 | 29.05.2020 |
-98 | Entry triggered from other application | 43 843 | 26.05.2014 | 29.05.2020 |
1032600 | Cancellation - Start | 39 607 | 23.04.2007 | 29.05.2020 |
1100021 | o Print License | 39 325 | 20.06.2001 | 11.02.2020 |
1032604 | Cancellation - Come into Operational | 38 962 | 23.04.2007 | 29.05.2020 |
1032070 | o Technical Analysis | 35 143 | 15.01.2016 | 29.05.2020 |
1100007 | o Complete Request | 32 517 | 20.06.2001 | 29.05.2020 |
1032005 | o Copy | 31 621 | 24.11.2000 | 06.05.2020 |
1080020 | o Grant License | 28 424 | 03.05.2001 | 28.05.2020 |
1080004 | o Send to Archive | 24 825 | 03.04.2000 | 29.05.2020 |
-199 | > Start (o Prolongation) | 19 630 | 26.06.2014 | 29.05.2020 |
1053004 | o Send to Archive | 19 345 | 08.12.2001 | 29.05.2020 |
1032080 | o Check Frequency | 17 768 | 14.01.2016 | 29.05.2020 |
-91 | Webservice Import | 17 431 | 13.01.2016 | 29.05.2020 |
1032818 | o Ready for SPECTRAdet | 17 161 | 12.01.2016 | 29.05.2020 |
1053020 | o Grant final License | 16 317 | 18.04.2001 | 29.05.2020 |
1080006 | o Duplicate Request | 15 653 | 03.04.2000 | 27.05.2020 |
1032000 | > Start Licensing | 14 728 | 26.07.2000 | 28.05.2020 |
1100020 | o Grant License | 14 475 | 04.02.2003 | 29.05.2020 |
1053006 | o Duplicate Request | 11 017 | 13.02.2002 | 27.05.2020 |
1053034 | o Start Recurring Invoicing | 10 693 | 23.06.2005 | 29.05.2020 |
1053035 | o Check Costs | 10 503 | 21.02.2002 | 29.05.2020 |
1033007 | o Complete Request | 10 470 | 17.12.2002 | 29.05.2020 |
1032816 | o Start Prolongation | 10 431 | 30.10.2014 | 26.05.2020 |
1100004 | o Send to Archive | 9 619 | 13.09.2001 | 29.05.2020 |
1080812 | o Print License (int.) | 9 604 | 03.04.2000 | 11.12.2019 |
1032820 | o Start FS recurring Invoicing | 9 267 | 21.01.2003 | 27.04.2005 |
1025007 | o Complete Request | 8 778 | 22.03.2002 | 29.05.2020 |
1100034 | o Start Recurring Invoicing | 8 027 | 04.02.2003 | 28.05.2020 |
1070021 | o Print License | 7 602 | 21.06.2001 | 09.12.2019 |
1026007 | o Complete Request | 7 521 | 07.03.2002 | 16.02.2012 |
1033806 | o Print Report "E" without Assessment | 6 856 | 06.01.2003 | 18.05.2020 |
1025806 | o Print Report "E" without Assessment | 6 712 | 07.03.2002 | 25.05.2020 |
1101021 | o Print License | 6 354 | 25.06.2001 | 15.10.2019 |
1140007 | o Complete Request | 6 242 | 26.07.2000 | 28.05.2020 |
1070007 | o Complete Request | 6 221 | 21.06.2001 | 29.05.2020 |
1100006 | o Duplicate Request | 6 142 | 01.10.2001 | 26.05.2020 |
1523007 | o Complete Request | 5 268 | 30.12.2002 | 28.05.2020 |
1100000 | > Start Licensing Mobile | 0 000 | 00.00.0000 | 27.05.2020 |
1081806 | o Print Report "E" without Assessment | 4 950 | 14.04.2000 | 15.05.2020 |
1101007 | o Complete Request | 4 941 | 25.06.2001 | 29.05.2020 |
1523806 | o Print Report "E" without Assessment | 4 863 | 15.05.2002 | 27.05.2020 |
1025020 | o Grant final License | 4 589 | 24.02.2003 | 29.05.2020 |
1081007 | o Complete Request | 4 362 | 31.03.2000 | 26.05.2020 |
1025034 | o Start Recurring Invoicing | 4 312 | 06.02.2003 | 29.05.2020 |
1053817 | o Enter Tec Data | 4 122 | 13.03.2015 | 28.05.2020 |
1053000 | > Start Lic Main Final | 4 052 | 18.04.2001 | 28.05.2020 |
1112806 | o Print Report "E" without Assessment | 4 045 | 08.10.2001 | 03.03.2020 |
1033035 | o Check Costs | 4 028 | 13.01.2003 | 11.03.2020 |
1033034 | o Start Recurring Invoicing | 3 795 | 29.01.2003 | 30.04.2020 |
1140029 | o Approve Equipment | 3 728 | 30.05.2001 | 28.05.2020 |
1080816 | o Start Prolongation | 3 483 | 04.07.2014 | 28.05.2020 |
1026004 | o Send to Archive | 3 371 | 06.06.2000 | 21.12.2012 |
1033020 | o Grant License | 3 198 | 29.01.2003 | 29.05.2020 |
1053820 | o Start LM recurring Invoicing | 3 188 | 21.02.2002 | 27.04.2005 |
1140006 | o Duplicate Request | 3 049 | 26.07.2000 | 28.05.2020 |
1025004 | o Send to Archive | 2 919 | 09.05.2002 | 22.05.2020 |
1080000 | > Start Licensing Private | 2 883 | 03.04.2000 | 05.05.2020 |
1083021 | o Print License | 2 790 | 10.12.2002 | 25.11.2019 |
1112007 | o Complete Request | 2 644 | 21.08.2000 | 20.05.2020 |
1026806 | o Print Report "E" without Assessment | 2 542 | 06.03.2002 | 03.05.2012 |
1070020 | o Grant License | 2 464 | 28.02.2003 | 27.05.2020 |
1033006 | o Duplicate Request | 2 392 | 17.12.2002 | 02.03.2020 |
1026020 | o Grant final License | 2 337 | 06.03.2003 | 02.12.2011 |
1070034 | o Start Recurring Invoicing | 2 314 | 10.02.2003 | 27.05.2020 |
1026034 | o Start Recurring Invoicing | 2 280 | 06.02.2003 | 14.11.2011 |
1026006 | o Duplicate Request | 2 211 | 08.04.2002 | 30.11.2011 |
1033004 | o Send to Archive | 2 129 | 13.01.2003 | 30.04.2020 |
1081020 | o Grant License | 2 105 | 05.09.2003 | 26.05.2020 |
1523020 | o Grant final License | 2 057 | 08.01.2004 | 26.05.2020 |
1523034 | o Start Recurring Invoicing | 2 028 | 06.02.2003 | 26.05.2020 |
1032032 | o Start Invoicing short Term Fee | 1 973 | 08.04.2003 | 27.05.2020 |
1081004 | o Send to Archive | 1 858 | 03.04.2000 | 26.05.2020 |
1053032 | o Start Invoicing short Term Fee | 1 834 | 18.04.2001 | 21.05.2020 |
1021007 | o Complete Request | 1 796 | 10.04.2000 | 28.02.2002 |
1033602 | Cancellation - Print Decision | 1 783 | 21.09.2007 | 27.05.2020 |
-1 | Open Interface | 1 740 | 01.10.2008 | 29.05.2020 |
1025006 | o Duplicate Request | 1 722 | 29.08.2002 | 15.05.2020 |
-999 | Cancellation - Debtor | 1 682 | 07.03.2005 | 20.05.2020 |
1100602 | Cancellation - Print Decision | 1 675 | 27.04.2007 | 22.05.2020 |
1250007 | o Complete Request | 1 654 | 03.06.2003 | 27.04.2020 |
1000080 | o Check Frequency | 1 650 | 21.01.2016 | 06.02.2020 |
1053600 | Cancellation - Start | 1 646 | 21.04.2008 | 27.05.2020 |
1053602 | Cancellation - Print Decision | 1 638 | 21.04.2008 | 27.05.2020 |
1053025 | o Print Info Letter | 1 633 | 04.02.2002 | 21.01.2015 |
1053604 | Cancellation - Come into Operational | 1 585 | 21.04.2008 | 27.05.2020 |
1083007 | o Complete Request | 1 583 | 10.12.2002 | 27.05.2020 |
1053070 | o Technical Analysis | 1 476 | 19.03.2015 | 28.05.2020 |
1100816 | o Start Prolongation | 1 462 | 26.06.2014 | 28.05.2020 |
1070004 | o Send to Archive | 1 432 | 17.09.2001 | 26.05.2020 |
1523004 | o Send to Archive | 1 392 | 06.01.2003 | 21.05.2020 |
1032037 | o Bookkeeping Info | 1 377 | 18.11.2003 | 21.01.2020 |
1000816 | o Start Prolongation | 1 371 | 21.01.2016 | 06.03.2020 |
1021020 | o Grant preliminary License | 1 358 | 03.05.2001 | 03.05.2001 |
1080011 | o Duplicate Request | 1 339 | 07.06.2000 | 28.05.2020 |
1053011 | o Duplicate Request | 1 317 | 23.07.2002 | 23.03.2020 |
1101020 | o Grant License | 1 268 | 10.02.2003 | 29.05.2020 |
1110806 | o Print Report "E" without Assessment | 1 251 | 21.08.2000 | 29.11.2019 |
1021806 | o Print Report "E" without Assessment | 1 214 | 17.04.2000 | 05.03.2002 |
1101034 | o Start Recurring Invoicing | 1 212 | 10.02.2003 | 29.05.2020 |
1071021 | o Print License | 1 205 | 25.06.2001 | 17.10.2019 |
1100600 | Cancellation - Start | 1 134 | 27.04.2007 | 22.05.2020 |
1523006 | o Duplicate Request | 1 124 | 30.12.2002 | 26.05.2020 |
1100604 | Cancellation - Come into Operational | 1 105 | 03.02.2012 | 22.05.2020 |
1025000 | > Start (FM) Lic Main Final | 1 096 | 01.07.2002 | 25.05.2020 |
1081006 | o Duplicate Request | 1 073 | 03.04.2000 | 28.04.2020 |
1070006 | o Duplicate Request | 1 043 | 27.09.2001 | 27.05.2020 |
1080806 | o Print Report "E" without Assessment | 1 008 | 18.04.2000 | 28.05.2020 |
1070000 | > Start Licensing Mobile | 0 000 | 00.00.0000 | 25.05.2020 |
1071007 | o Complete Request | 991 | 09.07.2001 | 17.04.2020 |
1110007 | o Complete Request | 956 | 24.10.2000 | 27.04.2020 |
1032011 | o Duplicate Request | 914 | 03.08.2001 | 26.05.2020 |
1032603 | Cancellation - Origin Remains | 876 | 16.03.2005 | 22.04.2020 |
1053816 | o Start Prolongation | 849 | 09.01.2015 | 28.05.2020 |
-89 | Data Committed | 836 | 26.11.2012 | 25.05.2020 |
1112004 | o Send to Archive | 806 | 01.02.2002 | 15.04.2020 |
1000004 | o Send to Archive | 790 | 22.03.2016 | 15.05.2020 |
1081021 | o Print License | 788 | 04.04.2000 | 13.11.2019 |
1523000 | > Start (DVB) Lic Main Final | 764 | 15.05.2002 | 25.05.2020 |
1033600 | Cancellation - Start | 763 | 21.09.2007 | 27.05.2020 |
1101004 | o Send to Archive | 759 | 29.10.2001 | 06.05.2020 |
1100011 | o Duplicate Request | 731 | 05.03.2003 | 29.05.2020 |
1112020 | o Grant License | 727 | 05.02.2003 | 03.03.2020 |
1020007 | o Complete Request | 713 | 07.11.2000 | 07.10.2010 |
1033604 | Cancellation - Come into Operational | 696 | 21.09.2007 | 27.05.2020 |
1083020 | o Grant License | 680 | 29.07.2003 | 05.05.2020 |
1521806 | o Print Report "E" without Assessment | 673 | 24.10.2005 | 20.04.2020 |
1026602 | Cancellation - Print Decision | 673 | 27.05.2011 | 16.02.2012 |
1101006 | o Duplicate Request | 667 | 10.04.2002 | 14.04.2020 |
1250034 | o Start Recurring Invoicing | 659 | 14.12.2005 | 15.05.2020 |
1112032 | o Start Invoicing short Term Fee | 627 | 10.06.2005 | 03.03.2020 |
1053005 | o Copy | 622 | 12.03.2003 | 18.05.2020 |
1026600 | Cancellation - Start | 615 | 27.05.2011 | 16.02.2012 |
1026604 | Cancellation - Come into Operational | 615 | 27.05.2011 | 16.02.2012 |
1250020 | o Grant License | 605 | 30.12.2005 | 15.05.2020 |
1100603 | Cancellation - Origin Remains | 580 | 15.03.2005 | 27.05.2020 |
1020806 | o Print Report "E" without Assessment | 562 | 27.03.2001 | 05.03.2002 |
1100806 | o Print Report "E" without Assessment | 554 | 24.07.2001 | 29.05.2020 |
-998 | Cancellation - pass to licence dept. | 535 | 29.03.2005 | 04.10.2019 |
1025816 | o Start Prolongation | 520 | 05.02.2016 | 29.05.2020 |
1033080 | o Check Frequency | 518 | 14.01.2016 | 27.05.2020 |
1021000 | > Start (TV) Lic Main tec Doc | 513 | 02.11.2000 | 05.03.2002 |
-197 | > Start (o Non Technical Change) | 509 | 25.11.2014 | 25.05.2020 |
1083004 | o Send to Archive | 500 | 16.10.2003 | 05.05.2020 |
1053037 | o Bookkeeping Info | 498 | 05.11.2003 | 12.05.2020 |
1100608 | Cancellation - Print Notification | 469 | 08.03.2005 | 20.05.2020 |
1070600 | Cancellation - Start | 438 | 20.01.2010 | 05.05.2020 |
1053603 | Cancellation - Origin Remains | 423 | 10.03.2005 | 21.02.2020 |
1070602 | Cancellation - Print Decision | 412 | 20.01.2010 | 05.05.2020 |
1070604 | Cancellation - Come into Operational | 396 | 20.01.2010 | 05.05.2020 |
1521007 | o Complete Request | 391 | 25.10.2005 | 20.04.2020 |
1027806 | o Print Report "E" without Assessment | 374 | 29.03.2002 | 19.02.2018 |
1025037 | o Bookkeeping Info | 358 | 18.02.2004 | 19.05.2020 |
1112006 | o Duplicate Request | 357 | 12.08.2002 | 20.02.2020 |
1112011 | o Duplicate Request | 348 | 04.06.2003 | 19.05.2020 |
1250004 | o Send to Archive | 342 | 27.01.2004 | 14.05.2020 |
1033005 | o Copy | 324 | 09.07.2003 | 14.11.2017 |
1250006 | o Duplicate Request | 324 | 12.06.2003 | 08.04.2020 |
1083006 | o Duplicate Request | 302 | 17.06.2003 | 07.04.2020 |
1083806 | o Print Report "E" without Assessment | 287 | 26.05.2003 | 27.05.2020 |
1081000 | > Start Licensing Group | 283 | 03.04.2000 | 28.04.2020 |
1026035 | o Check Costs | 280 | 07.03.2002 | 17.06.2008 |
1101602 | Cancellation - Print Decision | 279 | 04.05.2012 | 07.05.2020 |
1101000 | > Start Licensing Earth | 274 | 21.06.2001 | 11.03.2020 |
1027007 | o Complete Request | 273 | 29.03.2002 | 02.03.2020 |
1033000 | > Start P-MP Licensing | 265 | 17.12.2002 | 02.03.2020 |
1070806 | o Print Report "E" without Assessment | 261 | 27.07.2001 | 27.05.2020 |
1071020 | o Grant License | 259 | 17.04.2002 | 14.04.2020 |
1112034 | o Start Recurring Invoicing | 259 | 05.02.2003 | 03.02.2020 |
1070603 | Cancellation - Origin Remains | 258 | 10.03.2005 | 28.05.2020 |
1110004 | o Send to Archive | 256 | 16.08.2000 | 27.04.2020 |
1025814 | o Start Non Technical Change | 238 | 02.02.2016 | 25.05.2020 |
1083000 | > Start Licensing Repeater | 237 | 10.12.2002 | 27.04.2020 |
1025035 | o Check Costs | 236 | 07.03.2002 | 24.07.2019 |
1100037 | o Bookkeeping Info | 235 | 08.12.2003 | 25.07.2017 |
1071034 | o Start Recurring Invoicing | 232 | 25.09.2003 | 17.04.2020 |
1000602 | Cancellation - Print Decision | 231 | 27.01.2016 | 22.04.2020 |
1000604 | Cancellation - Come into Operational | 216 | 27.01.2016 | 22.04.2020 |
1025608 | Cancellation - Print Notification | 214 | 08.03.2005 | 24.05.2018 |
1032608 | Cancellation - Print Notification | 206 | 13.07.2007 | 10.07.2019 |
1025032 | o Start Invoicing short Term Fee | 203 | 06.02.2003 | 25.05.2020 |
1000600 | Cancellation - Start | 202 | 13.04.2018 | 22.04.2020 |
1053821 | o Start FS recurring Invoicing | 198 | 08.07.2002 | 12.04.2005 |
1081816 | o Start Prolongation | 195 | 14.04.2015 | 25.05.2020 |
1071004 | o Send to Archive | 194 | 06.01.2003 | 12.05.2020 |
1101600 | Cancellation - Start | 194 | 04.05.2012 | 07.05.2020 |
1250806 | o Print Report "E" without Assessment | 191 | 12.06.2003 | 06.12.2019 |
1101604 | Cancellation - Come into Operational | 189 | 04.10.2012 | 07.05.2020 |
1080600 | Cancellation - Start | 186 | 20.04.2007 | 20.11.2019 |
1521020 | o Grant final License | 185 | 25.10.2005 | 20.04.2020 |
1100035 | o Check Costs | 181 | 27.02.2002 | 28.05.2020 |
1101816 | o Start Prolongation | 177 | 21.04.2015 | 29.05.2020 |
1033816 | o Start Prolongation | 177 | 30.10.2014 | 07.04.2020 |
1071006 | o Duplicate Request | 172 | 17.04.2002 | 06.08.2019 |
1020000 | > Start (FM) Lic Main tec Doc | 170 | 07.11.2000 | 07.10.2010 |
1101806 | o Print Report "E" without Assessment | 167 | 09.07.2001 | 29.05.2020 |
1140004 | o Send to Archive | 162 | 06.11.2000 | 08.11.2019 |
1140000 | > Start Radio Equipment | 158 | 26.07.2000 | 07.10.2015 |
1521034 | o Start Recurring Invoicing | 155 | 14.03.2011 | 20.04.2020 |
1070608 | Cancellation - Print Notification | 153 | 08.03.2005 | 02.05.2019 |
1101035 | o Check Costs | 151 | 26.05.2005 | 03.03.2020 |
1021006 | o Duplicate Request | 150 | 30.05.2000 | 29.01.2002 |
1053010 | o Set / Reset read only Mode | 147 | 12.03.2015 | 28.04.2020 |
1110020 | o Grant License | 141 | 05.02.2003 | 27.04.2020 |
1070011 | o Duplicate Request | 139 | 26.05.2003 | 14.05.2020 |
1250035 | o Check Costs | 138 | 16.06.2011 | 20.04.2020 |
1026000 | > Start (TV) Lic Main Final | 136 | 01.06.2000 | 09.11.2011 |
1032601 | Cancellation - Print Dossier | 135 | 04.12.2007 | 06.05.2020 |
1110034 | o Start Recurring Invoicing | 134 | 27.02.2002 | 27.04.2020 |
1112000 | > Start Licensing Orbit | 111 | 16.08.2000 | 06.10.2017 |
1033818 | o Ready for SPECTRAdet | 111 | 05.02.2016 | 11.03.2020 |
1523816 | o Start Prolongation | 109 | 29.02.2016 | 13.12.2019 |
1027004 | o Send to Archive | 109 | 29.03.2002 | 01.04.2020 |
1070816 | o Start Prolongation | 107 | 19.12.2014 | 25.05.2020 |
1053608 | Cancellation - Print Notification | 106 | 08.03.2005 | 24.04.2019 |
1250816 | o Start Prolongation | 105 | 09.09.2015 | 27.04.2020 |
1053038 | o Bookkeeping Info | 103 | 14.11.2003 | 22.10.2019 |
1110006 | o Duplicate Request | 102 | 09.01.2002 | 18.04.2019 |
1020006 | o Duplicate Request | 101 | 21.05.2001 | 15.01.2002 |
1521004 | o Send to Archive | 95 | 01.12.2005 | 12.05.2020 |
1081011 | o Duplicate Request | 93 | 04.09.2002 | 02.04.2020 |
1027020 | o Grant final License | 92 | 11.03.2003 | 03.03.2020 |
1032814 | o Start Non Technical Change | 91 | 25.11.2014 | 09.01.2019 |
1521000 | > Start (DAB) Lic Main Final | 90 | 21.10.2005 | 20.04.2020 |
1027034 | o Start Recurring Invoicing | 89 | 11.03.2003 | 02.03.2020 |
1100022 | o Print Request | 89 | 24.02.2003 | 27.04.2015 |
1250000 | > Start Licensing | 87 | 03.06.2003 | 25.03.2020 |
1100032 | o Start Invoicing short Term Fee | 86 | 31.05.2005 | 05.01.2012 |
1110035 | o Check Costs | 84 | 27.02.2002 | 06.12.2017 |
1025603 | Cancellation - Origin Remains | 83 | 15.03.2005 | 13.03.2020 |
1020004 | o Send to Archive | 79 | 17.05.2001 | 07.10.2010 |
1101011 | o Duplicate Request | 78 | 20.07.2004 | 27.04.2020 |
1083816 | o Start Prolongation | 75 | 06.05.2015 | 05.05.2020 |
1070022 | o Print Request | 74 | 10.07.2006 | 13.10.2014 |
1523037 | o Bookkeeping Info | 73 | 19.11.2014 | 27.05.2020 |
1027006 | o Duplicate Request | 71 | 29.03.2002 | 04.01.2018 |
1033011 | o Duplicate Request | 71 | 17.12.2003 | 05.02.2019 |
1033603 | Cancellation - Origin Remains | 70 | 05.04.2005 | 08.02.2019 |
1033070 | o Technical Analysis | 65 | 23.02.2016 | 15.01.2020 |
1025038 | o Bookkeeping Info | 62 | 18.04.2011 | 06.03.2020 |
1083812 | o Print License (int.) | 61 | 20.10.2005 | 13.02.2019 |
1100038 | o Bookkeeping Info | 60 | 11.12.2003 | 13.03.2018 |
1071806 | o Print Report "E" without Assessment | 59 | 18.07.2002 | 17.01.2020 |
1033037 | o Bookkeeping Info | 59 | 28.11.2003 | 01.08.2014 |
1112035 | o Check Costs | 59 | 29.07.2002 | 06.08.2018 |
1033032 | o Start Invoicing short Term Fee | 58 | 29.04.2004 | 09.05.2012 |
1022007 | o Complete Request | 57 | 01.10.2001 | 07.01.2002 |
1071035 | o Check Costs | 56 | 19.05.2008 | 20.06.2019 |
1070035 | o Check Costs | 54 | 26.02.2002 | 12.02.2020 |
1022806 | o Print Report "E" without Assessment | 54 | 01.10.2001 | 05.10.2001 |
1250602 | Cancellation - Print Decision | 52 | 11.10.2012 | 25.03.2020 |
1080801 | o Print report "Aa" | 44 | 17.04.2000 | 01.07.2013 |
1100005 | o Copy | 43 | 30.09.2013 | 21.03.2016 |
1100610 | Cancellation - Print Decision (Debtor) | 42 | 07.05.2013 | 04.10.2019 |
1032038 | o Bookkeeping Info | 40 | 19.01.2004 | 07.06.2019 |
1080005 | o Copy | 40 | 28.04.2000 | 02.04.2015 |
1521006 | o Duplicate Request | 38 | 30.07.2007 | 20.04.2020 |
1110000 | > Start Licensing Earth | 38 | 16.08.2000 | 20.04.2020 |
1071005 | o Copy | 38 | 15.09.2015 | 30.11.2015 |
1081812 | o Print License (int.) | 37 | 03.04.2000 | 17.10.2019 |
1523032 | o Start Invoicing short Term Fee | 37 | 06.10.2004 | 10.10.2017 |
1081801 | o Print report "Aa" | 37 | 14.04.2000 | 04.08.2005 |
1101603 | Cancellation - Origin Remains | 35 | 10.03.2005 | 17.05.2017 |
1083011 | o Duplicate Request | 35 | 17.09.2004 | 28.04.2020 |
1025011 | o Duplicate Request | 34 | 17.09.2003 | 16.04.2020 |
1021004 | o Send to Archive | 33 | 06.06.2000 | 28.02.2002 |
1112037 | o Bookkeeping Info | 32 | 23.04.2004 | 26.07.2019 |
1250604 | Cancellation - Come into Operational | 31 | 11.10.2012 | 31.03.2020 |
1250600 | Cancellation - Start | 31 | 11.10.2012 | 25.03.2020 |
1100814 | o Start Non Technical Change | 31 | 05.04.2016 | 25.05.2020 |
1523035 | o Check Costs | 30 | 19.02.2007 | 24.07.2008 |
1026032 | o Start Invoicing short Term Fee | 28 | 06.03.2003 | 02.12.2011 |
1101608 | Cancellation - Print Notification | 28 | 08.03.2005 | 30.04.2015 |
1521032 | o Start Invoicing short Term Fee | 27 | 25.10.2005 | 28.05.2019 |
1071000 | > Start Licensing Coast | 27 | 21.06.2001 | 19.06.2019 |
1250005 | o Copy | 26 | 04.06.2012 | 04.02.2019 |
1070037 | o Bookkeeping Info | 25 | 06.11.2003 | 02.01.2007 |
1070005 | o Copy | 25 | 27.09.2001 | 14.10.2014 |
1101037 | o Bookkeeping Info | 25 | 19.01.2004 | 11.04.2016 |
1083005 | o Copy | 23 | 13.01.2006 | 02.12.2008 |
1053008 | o View Request | 22 | 26.01.2005 | 20.04.2007 |
1027000 | > Start (AM) Lic Main Final | 21 | 29.03.2002 | 13.10.2016 |
1032810 | o Print Report "K" | 20 | 26.09.2001 | 31.12.2002 |
1521816 | o Start Prolongation | 20 | 05.05.2016 | 12.11.2018 |
1250011 | o Duplicate Request | 20 | 14.02.2011 | 25.02.2020 |
1101032 | o Start Invoicing short Term Fee | 20 | 24.03.2009 | 30.11.2018 |
1110037 | o Bookkeeping Info | 20 | 11.12.2003 | 21.07.2009 |
1081802 | o Print report "Ab" | 20 | 14.04.2000 | 04.08.2005 |
1032610 | Cancellation - Print Decision (Debtor) | 20 | 07.06.2012 | 13.05.2019 |
1523600 | Cancellation - Start | 18 | 06.06.2013 | 02.01.2020 |
1081805 | o Print Report "D" | 17 | 17.04.2000 | 28.06.2019 |
1110038 | o Bookkeeping Info | 16 | 15.12.2003 | 05.11.2004 |
1033608 | Cancellation - Print Notification | 16 | 28.03.2007 | 15.03.2013 |
1032801 | o Print report "Aa" | 16 | 31.08.2000 | 15.11.2011 |
1523604 | Cancellation - Come into Operational | 16 | 06.06.2013 | 06.06.2013 |
1523602 | Cancellation - Print Decision | 16 | 06.06.2013 | 06.06.2013 |
1110602 | Cancellation - Print Decision | 15 | 03.02.2012 | 26.04.2019 |
1053610 | Cancellation - Print Decision (Debtor) | 15 | 23.05.2012 | 22.05.2019 |
1070610 | Cancellation - Print Decision (Debtor) | 15 | 21.05.2015 | 18.06.2019 |
1025610 | Cancellation - Print Decision (Debtor) | 15 | 23.05.2018 | 23.05.2018 |
1039004 | o Send to Archive | 14 | 15.05.2001 | 18.07.2013 |
1523814 | o Start Non Technical Change | 14 | 06.11.2017 | 08.08.2018 |
1033810 | o Print Report "K" | 14 | 20.02.2004 | 23.07.2014 |
1101812 | o Print License (int.) | 14 | 12.02.2014 | 30.11.2018 |
1110600 | Cancellation - Start | 13 | 03.02.2012 | 26.04.2019 |
1101022 | o Print Request | 13 | 10.11.2003 | 13.12.2013 |
1032805 | o Print Report "D" | 13 | 07.08.2008 | 27.02.2019 |
1110604 | Cancellation - Come into Operational | 13 | 03.02.2012 | 26.04.2019 |
1112816 | o Start Prolongation | 13 | 11.02.2016 | 03.02.2020 |
1081005 | o Copy | 13 | 22.01.2004 | 18.11.2011 |
1059007 | o Complete Request | 13 | 02.09.2005 | 10.09.2013 |
1032009 | o Link / Unlink | 13 | 07.02.2005 | 03.01.2011 |
1112602 | Cancellation - Print Decision | 13 | 05.03.2013 | 05.02.2018 |
0000000 | o Start SMS Tool | 00 | 00.00.0000 | 11.02.2020 |
1523038 | o Bookkeeping Info | 13 | 10.01.2012 | 26.05.2020 |
1039007 | o Complete Request | 12 | 27.04.2001 | 15.08.2011 |
1053012 | o View Request | 12 | 08.02.2005 | 09.03.2016 |
1053814 | o Start Non Technical Change | 12 | 03.02.2015 | 25.02.2020 |
1050007 | o Complete Request | 11 | 08.09.2003 | 29.06.2005 |
1140022 | o Print Request | 11 | 23.04.2003 | 19.02.2008 |
1053015 | o Undo/Redo | 11 | 19.08.2002 | 24.06.2008 |
1250022 | o Print Request | 11 | 14.12.2005 | 09.09.2014 |
1110816 | o Start Prolongation | 11 | 05.05.2016 | 27.04.2020 |
1521037 | o Bookkeeping Info | 10 | 06.05.2016 | 14.10.2019 |
1100024 | o Print Reminder | 10 | 12.01.2015 | 18.03.2019 |
1053014 | o Modify official in Charge | 10 | 18.02.2003 | 21.02.2014 |
1038020 | o Grant License | 10 | 27.02.2012 | 27.02.2012 |
1523608 | Cancellation - Print Notification | 10 | 21.10.2013 | 03.05.2019 |
1080035 | o Check Costs | 9 | 31.05.2000 | 20.04.2015 |
1523024 | o Print Reminder | 9 | 13.05.2015 | 23.04.2019 |
1020005 | o Copy | 9 | 23.07.2001 | 24.07.2001 |
1032008 | o View Request | 9 | 03.02.2005 | 27.12.2018 |
1071011 | o Duplicate Request | 9 | 10.11.2005 | 15.01.2020 |
1080803 | o Print report "B" | 9 | 18.04.2000 | 08.10.2012 |
1000818 | o Ready for SPECTRAdet | 9 | 29.11.2018 | 04.11.2019 |
1112600 | Cancellation - Start | 9 | 05.03.2013 | 05.02.2018 |
1025024 | o Print Reminder | 9 | 16.06.2015 | 28.02.2019 |
1112604 | Cancellation - Come into Operational | 9 | 05.03.2013 | 05.02.2018 |
1100812 | o Print License (int.) | 8 | 27.07.2001 | 18.02.2020 |
1083801 | o Print report "Aa" | 8 | 17.02.2004 | 01.07.2013 |
1080807 | o Print Report "H" | 8 | 18.04.2000 | 22.08.2014 |
1032010 | o Set / Reset read only Mode | 8 | 31.03.2016 | 04.06.2019 |
1032014 | o Modify official in Charge | 8 | 17.07.2001 | 29.05.2012 |
1027037 | o Bookkeeping Info | 8 | 24.03.2014 | 13.06.2019 |
1523603 | Cancellation - Origin Remains | 8 | 09.09.2013 | 03.05.2019 |
1080015 | o Undo/Redo | 8 | 28.11.2005 | 24.11.2011 |
1081807 | o Print Report "H" | 8 | 17.04.2000 | 15.11.2005 |
1140005 | o Copy | 8 | 27.07.2000 | 28.01.2015 |
1053810 | o Print Report "K" | 7 | 06.02.2002 | 30.08.2013 |
1026011 | o Duplicate Request | 7 | 12.01.2004 | 28.04.2011 |
1027035 | o Check Costs | 7 | 29.10.2003 | 09.05.2013 |
1100609 | Cancellation - Print Dossier (Debtor) | 7 | 21.05.2008 | 04.10.2019 |
1071816 | o Start Prolongation | 7 | 21.07.2017 | 14.04.2020 |
1032804 | o Print Report "C" | 7 | 07.08.2008 | 07.08.2008 |
1032015 | o Undo/Redo | 7 | 29.08.2001 | 05.02.2010 |
1053009 | o Link / Unlink | 7 | 06.11.2002 | 03.06.2019 |
1021805 | o Print Report "D" | 7 | 17.04.2000 | 31.05.2000 |
1522000 | > Start (DVB) Lic Main tec Doc | 7 | 08.11.2000 | 13.02.2019 |
1070812 | o Print License (int.) | 7 | 30.05.2011 | 04.01.2017 |
1059015 | o Undo/Redo | 6 | 10.09.2013 | 10.09.2013 |
1524806 | o Print Report "E" without Assessment | 6 | 23.05.2018 | 10.09.2019 |
1027816 | o Start Prolongation | 6 | 13.03.2018 | 02.03.2020 |
1059004 | o Send to Archive | 6 | 11.01.2006 | 23.09.2013 |
1071604 | Cancellation - Come into Operational | 6 | 07.09.2012 | 02.10.2019 |
1080813 | o Print Report "M" | 6 | 16.03.2005 | 29.11.2013 |
1071602 | Cancellation - Print Decision | 6 | 07.09.2012 | 02.10.2019 |
1032012 | o View Request | 6 | 19.11.2009 | 03.07.2017 |
1053601 | Cancellation - Print Dossier | 6 | 11.06.2015 | 11.02.2020 |
1080025 | o Print Info Letter | 6 | 13.06.2003 | 02.09.2019 |
1071600 | Cancellation - Start | 6 | 07.09.2012 | 02.10.2019 |
1250601 | Cancellation - Print Dossier | 6 | 08.12.2015 | 08.12.2015 |
1081813 | o Print Report "M" | 6 | 17.04.2000 | 29.05.2000 |
1080802 | o Print report "Ab" | 6 | 18.04.2000 | 11.07.2011 |
1039000 | > Start Cancellation (by Licensee) | 6 | 06.09.2000 | 18.07.2013 |
1100810 | o Print Report "K" | 6 | 16.07.2001 | 09.06.2017 |
1100015 | o Undo/Redo | 6 | 28.06.2001 | 07.01.2008 |
1250037 | o Bookkeeping Info | 5 | 12.06.2008 | 24.02.2020 |
1081811 | o Print Report "L" | 5 | 17.04.2000 | 29.05.2000 |
1053031 | o Start Invoicing Admin Fee | 5 | 26.02.2002 | 17.06.2002 |
1059000 | > Start Cancellation (by Licensee) | 5 | 15.03.2005 | 10.09.2013 |
1140015 | o Undo/Redo | 5 | 04.11.2008 | 21.05.2013 |
1520007 | o Complete Request | 5 | 30.05.2000 | 30.05.2000 |
1521038 | o Bookkeeping Info | 5 | 02.02.2015 | 11.04.2019 |
1080804 | o Print Report "C" | 5 | 18.04.2000 | 30.03.2010 |
1025602 | Cancellation - Print Decision | 5 | 20.04.2018 | 24.05.2018 |
1110011 | o Duplicate Request | 5 | 04.11.2004 | 17.02.2017 |
1523011 | o Duplicate Request | 5 | 13.02.2014 | 05.02.2019 |
1025600 | Cancellation - Start | 5 | 14.04.2016 | 12.03.2020 |
1081809 | o Print Report "J" | 5 | 17.04.2000 | 29.05.2000 |
1081803 | o Print report "B" | 5 | 17.04.2000 | 04.08.2005 |
1070032 | o Start Invoicing short Term Fee | 5 | 29.04.2014 | 07.10.2015 |
1080014 | o Modify official in Charge | 5 | 16.11.2000 | 24.10.2011 |
1022000 | > Start (AM) Lic Main tec Doc | 5 | 01.10.2001 | 04.10.2001 |
1039020 | o Grant License | 5 | 10.05.2011 | 15.08.2011 |
1081804 | o Print Report "C" | 5 | 17.04.2000 | 04.08.2005 |
1081810 | o Print Report "K" | 4 | 17.04.2000 | 29.05.2000 |
1100601 | Cancellation - Print Dossier | 4 | 16.04.2012 | 07.07.2014 |
1032803 | o Print report "B" | 4 | 13.09.2000 | 22.05.2020 |
1523005 | o Copy | 4 | 17.10.2005 | 17.10.2005 |
1081035 | o Check Costs | 4 | 06.06.2006 | 24.08.2011 |
1021803 | o Print report "B" | 4 | 30.05.2000 | 30.05.2000 |
1021804 | o Print Report "C" | 4 | 30.05.2000 | 31.05.2000 |
1101038 | o Bookkeeping Info | 4 | 11.12.2003 | 20.04.2015 |
1033008 | o View Request | 4 | 25.05.2005 | 09.03.2006 |
1101814 | o Start Non Technical Change | 4 | 08.02.2016 | 05.02.2020 |
1022006 | o Duplicate Request | 4 | 01.10.2001 | 04.10.2001 |
1110032 | o Start Invoicing short Term Fee | 4 | 26.06.2006 | 29.09.2014 |
1080009 | o Link / Unlink | 4 | 24.11.2006 | 04.11.2010 |
1053801 | o Print report "Aa" | 4 | 06.02.2002 | 18.02.2015 |
1250025 | o Print Info Letter | 4 | 25.04.2013 | 09.09.2014 |
1070038 | o Bookkeeping Info | 4 | 17.06.2004 | 31.03.2009 |
1027032 | o Start Invoicing short Term Fee | 4 | 17.10.2003 | 27.01.2011 |
1071037 | o Bookkeeping Info | 4 | 24.02.2004 | 27.02.2006 |
1522007 | o Complete Request | 3 | 08.11.2000 | 17.05.2001 |
1081808 | o Print Report "I" | 3 | 17.04.2000 | 26.04.2000 |
1080811 | o Print Report "L" | 3 | 24.11.2005 | 26.04.2011 |
1033038 | o Bookkeeping Info | 3 | 31.10.2008 | 10.03.2017 |
1110608 | Cancellation - Print Notification | 3 | 25.04.2017 | 25.04.2017 |
1100025 | o Print Info Letter | 3 | 27.04.2015 | 26.07.2018 |
1080814 | o Start Non Technical Change | 3 | 26.02.2019 | 02.04.2020 |
1051806 | o Print Report "E" without Assessment | 3 | 25.09.2000 | 22.11.2001 |
1112038 | o Bookkeeping Info | 3 | 18.12.2003 | 10.03.2014 |
1027804 | o Print Report "C" | 3 | 01.03.2007 | 01.03.2007 |
1021811 | o Print Report "L" | 3 | 30.05.2000 | 31.05.2000 |
1112025 | o Print Info Letter | 3 | 10.04.2006 | 24.05.2011 |
1032821 | o Start BC (FM/DAB) recurring Invoicing | 3 | 03.02.2003 | 06.01.2005 |
1051007 | o Complete Request | 3 | 26.07.2000 | 08.12.2001 |
1022004 | o Send to Archive | 3 | 08.10.2001 | 28.02.2002 |
1050004 | o Send to Archive | 3 | 24.10.2003 | 25.11.2010 |
1100008 | o View Request | 3 | 22.05.2006 | 05.01.2009 |
1032606 | Cancellation - Correct of Cancellation Letter No. | 3 | 09.03.2009 | 05.06.2015 |
1000608 | Cancellation - Print Notification | 3 | 18.04.2016 | 18.04.2016 |
1050000 | > Start Preprocess | 3 | 03.06.2002 | 25.11.2010 |
1032025 | o Print Info Letter | 3 | 20.10.2005 | 25.06.2013 |
1032024 | o Print Reminder | 3 | 06.05.2004 | 10.02.2014 |
1100009 | o Link / Unlink | 3 | 10.10.2005 | 21.09.2012 |
1032027 | o Print Report "Vienna Agreement" | 3 | 06.10.2000 | 10.03.2005 |
1026038 | o Bookkeeping Info | 3 | 03.02.2004 | 14.04.2011 |
1021809 | o Print Report "J" | 2 | 30.05.2000 | 30.05.2000 |
1080805 | o Print Report "D" | 2 | 18.04.2000 | 07.03.2007 |
1140011 | o Duplicate Request | 2 | 16.11.2000 | 16.11.2000 |
1070609 | Cancellation - Print Dossier (Debtor) | 2 | 23.04.2019 | 23.04.2019 |
1070025 | o Print Info Letter | 2 | 29.04.2014 | 29.04.2014 |
1101610 | Cancellation - Print Decision (Debtor) | 2 | 19.05.2015 | 24.05.2018 |
1032028 | o Print Envelope | 2 | 10.02.2015 | 10.02.2015 |
1026037 | o Bookkeeping Info | 2 | 25.02.2004 | 25.02.2004 |
1100803 | o Print report "B" | 2 | 16.07.2001 | 20.07.2005 |
1081600 | Cancellation - Start | 2 | 05.10.2017 | 27.01.2020 |
1080810 | o Print Report "K" | 2 | 18.04.2000 | 27.03.2015 |
1522004 | o Send to Archive | 2 | 17.05.2001 | 07.03.2019 |
1026015 | o Undo/Redo | 2 | 07.08.2002 | 07.08.2002 |
1053024 | o Print Reminder | 2 | 09.10.2003 | 30.08.2013 |
1081024 | o Print Reminder | 2 | 14.07.2016 | 26.06.2019 |
1100802 | o Print report "Ab" | 2 | 16.07.2001 | 20.07.2005 |
1100605 | Cancellation - Appeal | 2 | 12.02.2016 | 08.06.2016 |
-198 | > Start (o Modification) | 2 | 25.11.2014 | 25.11.2014 |
1027023 | o Print Inquiry | 2 | 03.07.2014 | 03.07.2014 |
1524007 | o Complete Request | 2 | 23.05.2018 | 25.05.2018 |
1025005 | o Copy | 2 | 12.07.2013 | 08.03.2016 |
1250028 | o Print Envelope | 2 | 16.10.2014 | 16.10.2014 |
1100801 | o Print report "Aa" | 2 | 16.07.2001 | 20.07.2005 |
1027022 | o Print Request | 2 | 16.04.2014 | 16.04.2014 |
1070009 | o Link / Unlink | 2 | 23.07.2013 | 01.08.2013 |
1053027 | o Print Report "Vienna Agreement" | 2 | 18.04.2001 | 15.03.2002 |
1032605 | Cancellation - Appeal | 2 | 07.02.2018 | 07.02.2018 |
1100023 | o Print Inquiry | 2 | 28.06.2001 | 27.04.2015 |
1039006 | o Duplicate Request | 2 | 25.07.2011 | 18.07.2013 |
1071812 | o Print License (int.) | 2 | 26.01.2015 | 29.04.2015 |
1140014 | o Modify official in Charge | 2 | 30.08.2000 | 09.05.2001 |
1053022 | o Print Request | 2 | 18.04.2001 | 22.06.2006 |
1080808 | o Print Report "I" | 2 | 06.04.2000 | 18.04.2000 |
1021031 | o Start Invoicing Admin Fee | 2 | 30.05.2000 | 31.05.2000 |
1021808 | o Print Report "I" | 2 | 30.05.2000 | 30.05.2000 |
1110609 | Cancellation - Print Dossier (Debtor) | 2 | 12.01.2018 | 12.01.2018 |
1110603 | Cancellation - Origin Remains | 2 | 14.03.2005 | 17.01.2018 |
1070605 | Cancellation - Appeal | 2 | 23.07.2018 | 23.07.2018 |
1051000 | > Start Lic Main tec Doc | 2 | 29.05.2000 | 20.06.2002 |
1051004 | o Send to Archive | 2 | 08.12.2001 | 08.09.2003 |
1032031 | o Start Invoicing Admin Fee | 2 | 14.08.2002 | 30.01.2003 |
1021801 | o Print report "Aa" | 2 | 30.05.2000 | 30.05.2000 |
1053023 | o Print Inquiry | 2 | 23.03.2004 | 30.03.2004 |
1071603 | Cancellation - Origin Remains | 2 | 01.04.2005 | 22.05.2007 |
1026603 | Cancellation - Origin Remains | 2 | 11.04.2006 | 29.06.2006 |
1100805 | o Print Report "D" | 2 | 16.07.2001 | 20.07.2005 |
1033601 | Cancellation - Print Dossier | 1 | 22.01.2019 | 22.01.2019 |
1032022 | o Print Request | 1 | 18.02.2019 | 18.02.2019 |
1083813 | o Print Report "M" | 1 | 28.03.2007 | 28.03.2007 |
1032055 | o Add WF Notation | 1 | 23.11.2012 | 23.11.2012 |
1100809 | o Print Report "J" | 1 | 16.07.2001 | 16.07.2001 |
1053606 | Cancellation - Correct of Cancellation Letter No. | 1 | 04.04.2012 | 04.04.2012 |
1100807 | o Print Report "H" | 1 | 16.07.2001 | 16.07.2001 |
1110810 | o Print Report "K" | 1 | 16.01.2002 | 16.01.2002 |
1015000 | > Start Concessioning Main | 1 | 24.11.2003 | 24.11.2003 |
1058007 | o Complete Request | 1 | 12.01.2006 | 12.01.2006 |
1250008 | o View Request | 1 | 18.08.2016 | 18.08.2016 |
1058004 | o Send to Archive | 1 | 24.01.2006 | 24.01.2006 |
1032609 | Cancellation - Print Dossier (Debtor) | 1 | 10.04.2019 | 10.04.2019 |
1520005 | o Copy | 1 | 30.05.2000 | 30.05.2000 |
1088000 | > Start Rejection (by CTO) | 1 | 21.04.2004 | 21.04.2004 |
1521011 | o Duplicate Request | 1 | 02.11.2017 | 02.11.2017 |
1033023 | o Print Inquiry | 1 | 20.02.2004 | 20.02.2004 |
1081032 | o Start Invoicing short Term Fee | 1 | 17.04.2000 | 17.04.2000 |
1021807 | o Print Report "H" | 1 | 30.05.2000 | 30.05.2000 |
1109004 | o Send to Archive | 1 | 29.10.2001 | 29.10.2001 |
1053803 | o Print report "B" | 1 | 06.02.2002 | 06.02.2002 |
1033025 | o Print Info Letter | 1 | 02.08.2005 | 02.08.2005 |
1521600 | Cancellation - Start | 1 | 01.08.2019 | 01.08.2019 |
1110031 | o Start Invoicing Admin Fee | 1 | 27.02.2002 | 27.02.2002 |
1032807 | o Print Report "H" | 1 | 21.03.2005 | 21.03.2005 |
1250603 | Cancellation - Origin Remains | 1 | 20.03.2012 | 20.03.2012 |
1081023 | o Print Inquiry | 1 | 18.04.2000 | 18.04.2000 |
1112814 | o Start Non Technical Change | 1 | 09.01.2015 | 09.01.2015 |
1521603 | Cancellation - Origin Remains | 1 | 06.09.2019 | 06.09.2019 |
1100014 | o Modify official in Charge | 1 | 28.06.2001 | 28.06.2001 |
1021802 | o Print report "Ab" | 1 | 30.05.2000 | 30.05.2000 |
1021005 | o Copy | 1 | 28.08.2001 | 28.08.2001 |
1521602 | Cancellation - Print Decision | 1 | 01.08.2019 | 01.08.2019 |
1021813 | o Print Report "M" | 1 | 30.05.2000 | 30.05.2000 |
1100804 | o Print Report "C" | 1 | 16.07.2001 | 16.07.2001 |
1523025 | o Print Info Letter | 1 | 02.05.2006 | 02.05.2006 |
1021009 | o Link / Unlink | 1 | 17.07.2001 | 17.07.2001 |
1053028 | o Print Envelope | 1 | 04.05.2006 | 04.05.2006 |
1026009 | o Link / Unlink | 1 | 08.08.2006 | 08.08.2006 |
1053804 | o Print Report "C" | 1 | 06.02.2002 | 06.02.2002 |
1080008 | o View Request | 1 | 19.12.2005 | 19.12.2005 |
1083035 | o Check Costs | 1 | 12.10.2007 | 12.10.2007 |
1033012 | o View Request | 1 | 14.11.2012 | 14.11.2012 |
1100808 | o Print Report "I" | 1 | 16.07.2001 | 16.07.2001 |
1112810 | o Print Report "K" | 1 | 20.08.2002 | 20.08.2002 |
1032040 | o Attach Document | 1 | 28.06.2016 | 28.06.2016 |
1000814 | o Start Non Technical Change | 1 | 08.04.2016 | 08.04.2016 |
1112005 | o Copy | 1 | 07.03.2014 | 07.03.2014 |
1081814 | o Start Non Technical Change | 1 | 29.01.2016 | 29.01.2016 |
1100811 | o Print Report "L" | 1 | 16.07.2001 | 16.07.2001 |
1026031 | o Start Invoicing Admin Fee | 1 | 05.12.2002 | 05.12.2002 |
1109000 | > Start Cancellation (by Licensee) | 1 | 03.09.2001 | 03.09.2001 |
1524000 | > Start DVB-T2 | 1 | 23.05.2018 | 23.05.2018 |
1520004 | o Send to Archive | 1 | 06.06.2000 | 06.06.2000 |
1250038 | o Bookkeeping Info | 1 | 14.03.2008 | 14.03.2008 |
1100606 | Cancellation - Correct of Cancellation Letter No. | 1 | 25.02.2013 | 25.02.2013 |
1112008 | o View Request | 1 | 09.03.2017 | 09.03.2017 |
1058000 | > Start Rejection (by CTO) | 1 | 15.03.2005 | 15.03.2005 |
1059009 | o Link / Unlink | 1 | 12.01.2006 | 12.01.2006 |
1025015 | o Undo/Redo | 1 | 22.06.2011 | 22.06.2011 |
1070810 | o Print Report "K" | 1 | 29.01.2002 | 29.01.2002 |
1070601 | Cancellation - Print Dossier | 1 | 20.01.2010 | 20.01.2010 |
1053815 | o Start Modification | 1 | 25.11.2014 | 25.11.2014 |
1027005 | o Copy | 1 | 29.03.2002 | 29.03.2002 |
1038004 | o Send to Archive | 1 | 07.01.2003 | 07.01.2003 |
1110012 | o View Request | 1 | 04.03.2013 | 04.03.2013 |
1033606 | Cancellation - Correct of Cancellation Letter No. | 1 | 01.03.2013 | 01.03.2013 |
1051801 | o Print report "Aa" | 1 | 29.05.2000 | 29.05.2000 |
1088004 | o Send to Archive | 1 | 14.05.2004 | 14.05.2004 |
1053807 | o Print Report "H" | 1 | 03.07.2007 | 03.07.2007 |
1053813 | o Print Report "M" | 1 | 18.02.2015 | 18.02.2015 |
1110005 | o Copy | 1 | 22.10.2014 | 22.10.2014 |
1130000 | > Start Licensing | 1 | 25.06.2001 | 25.06.2001 |
1053811 | o Print Report "L" | 1 | 15.02.2002 | 15.02.2002 |
1038000 | > Start Rejection (by CTO) | 1 | 07.01.2003 | 07.01.2003 |
1522806 | o Print Report "E" without Assessment | 1 | 10.04.2001 | 10.04.2001 |
1080809 | o Print Report "J" | 1 | 18.04.2000 | 18.04.2000 |
1520000 | > Start (DAB) Lic Main tec Doc | 1 | 30.05.2000 | 30.05.2000 |
1015004 | o Send to Archive | 1 | 04.01.2005 | 04.01.2005 |
1080012 | o View Request | 1 | 29.09.2017 | 29.09.2017 |
1520806 | o Print Report "E" without Assessment | 1 | 30.05.2000 | 30.05.2000 |
1100813 | o Print Report "M" | 1 | 16.07.2001 | 16.07.2001 |
1000806 | o Print Report "E" without Assessment | 1 | 14.01.2020 | 14.01.2020 |
1521035 | o Check Costs | 1 | 06.09.2019 | 06.09.2019 |
1090000 | > Start Licensing | 1 | 25.06.2001 | 25.06.2001 |
1101024 | o Print Reminder | 1 | 26.06.2001 | 26.06.2001 |
1081025 | o Print Info Letter | 1 | 22.06.2006 | 22.06.2006 |
1053041 | o Send E-mail | 1 | 27.11.2012 | 27.11.2012 |
1053605 | Cancellation - Appeal | 1 | 15.10.2013 | 15.10.2013 |
1021011 | o Duplicate Request | 1 | 09.04.2001 | 09.04.2001 |
1021810 | o Print Report "K" | 1 | 31.05.2000 | 31.05.2000 |
1130004 | o Send to Archive | 1 | 08.10.2001 | 08.10.2001 |
1071810 | o Print Report "K" | 1 | 26.04.2002 | 26.04.2002 |
AKCEPTAČNÍ ŘÍZENÍ
Na začátku projektu projektoví manažeři Objednatele a Zhotovitele zpracují Metodiku řízení projektu
„Generační inovace SW nástroje pro správu kmitočtového spektra ČR“ (dále jen „projekt“ nebo
„mySPECTRA“), která bude vycházet z uznávané metodologie projektového řízení v souladu s principy standardů PRINCE2 a IPMA. Metodika řízení projektu podléhá schválení oběma Stranami.
1. Realizace a akceptace díla
1.1. Detailní analýza (včetně Plánu) dle definice v odst. 1.3 písm. b) Xxxxxxx o dílo Akceptačním kritériem je soulad dokumentů s podmínkami Smlouvy o dílo včetně Katalogu. Výsledkem akceptačního řízení může být:
a) „Akceptováno bez výhrad“, tzn. při kontrole kvality nebyly shledány nedostatky bránící užití / převzetí této části Díla nebo
b) „Akceptováno s výhradami“, tzn. při kontrole kvality byly shledány nedostatky, které samy o sobě nebo ve spojení s jinými nebrání užití / převzetí této části Díla nebo
c) „Neakceptováno“, tzn. při kontrole kvality byly shledány nedostatky bránící užití / převzetí této části Díla.
Zhotovitel odstraní všechny zjištěné nedostatky v termínu dohodnutém oběma Stranami. Odstranění zjištěných nedostatků bude opětovně ověřeno a výsledek bude zaznamenán formou samostatného zápisu v akceptačním protokolu.
1.2. Návrhová dokumentace (Návrh) dle definice v odst. 1.3 písm. b) Smlouvy o dílo
Akceptačním kritériem je soulad dokumentů s podmínkami Xxxxxxx o dílo včetně Katalogu / detailní analýzy.
Výsledkem akceptačního řízení může být:
a) „Akceptováno bez výhrad“, tzn. při kontrole kvality nebyly shledány nedostatky bránící užití / převzetí této části Díla nebo
b) „Akceptováno s výhradami“, tzn. při kontrole kvality byly shledány nedostatky, které samy o sobě nebo ve spojení s jinými nebrání užití / převzetí této části Díla nebo
c) „Neakceptováno“, tzn. při kontrole kvality byly shledány nedostatky bránící užití / převzetí této části Díla.
Zhotovitel odstraní všechny zjištěné nedostatky v termínu dohodnutém oběma Stranami. Odstranění zjištěných nedostatků bude opětovně ověřeno a výsledek bude zaznamenán formou samostatného zápisu v akceptačním protokolu.
1.3. Testování SW částí Díla
Schéma akceptačního testování softwarových částí díla je znázorněno na další straně:
Akceptační testování se skládá z následujících typů akceptací:
1. Factory Acceptance Testing (FAT),
2. Site Acceptance Testing (SAT),
3. Průřezové testování (PT).
Všechny typy testování projdou stejnou sadou testovacích scénářů, které vycházejí z analytické a návrhové dokumentace. Průchod akceptačním testem bude zaznamenán a vzájemně schválen oběma Stranami.
Objednatel v průběhu akceptačního testování může testovat i jinými postupy než podle testovacích scénářů, avšak k takto nalezeným chybám nebude v rámci akceptačního testování přihlíženo.
Navíc je možné provést za následujících podmínek fázi předběžného testování vybraných dokončených částí Díla:
- rozsah testování se týká samostatných částí Díla, které mohou být testovány odděleně,
- po úspěšném testování by daná část Díla měla zůstat nezměněná za podmínky, že stanovené testovací případy byly provedeny s využitím dohodnutých testovacích scénářů,
- předběžné testování je volitelné a je dohodnuto Projektovým týmem,
- předběžné testování se netýká mezníků stanovených pro platby.
Dílo je připraveno k použití v provozu, jakmile všechny jeho části projdou úspěšně akceptačním testováním podle akceptačních kritérií. Dílčí akceptace systému (například po dosažení úplné funkčnosti sady rádiových služeb) je přípustná za následujících podmínek:
- dílčí akceptace musí být schválena projektovými manažery obou Stran,
- analýza nákladů a přínosů Dílčí akceptace prokáže výhodnost tohoto přístupu pro realizaci projektu.
1.4. Závažnost chyb
Pokud se Dílo během testování nebo provozu nezachová podle specifikace v odsouhlasené dokumentaci, nastává incident. Příčinou incidentu bývá chyba, avšak ne každá chyba je chybou Díla. Aby příčina byla klasifikována jako chyba Díla, musí být naplněno alespoň jedno z těchto kritérií:
a) Z projevů Díla je nepochybné, že jde o chybu Díla (např. vadný popis pole).
b) Incident se opakuje a jeho sledováním lze jednoznačně dovodit, že jde o chybu Díla (např. vadná konfigurace některé větve workflow).
c) Incident se opakuje a lze nastavit takové logování Díla nebo IT systému, které prokáže, že příčiny spočívají v chybě Díla (např. opakující se náhodný pád aplikace).
d) Incident se neopakuje, ale příčiny incidentu lze odvodit z existujících logů Díla nebo logů jiných IT subsystémů, přičemž tyto příčiny spočívají v chybě Díla (např. nepředání povinného parametru na rozhraní s integrovaným systémem).
Objednatel rozhoduje o kategorizaci chyby Díla (dále chyby) dle závažnosti na základě níže uvedené tabulky.
Pravidla pro určení chyby:
Chyba způsobuje alespoň jeden z následujících stavů:
• v Díle se vyskytuje chyba znemožňující práci s Dílem a jeho použitelnost,
• Dílo nebo některá jeho základní část je nefunkční a požadovanou činnost předepsanou v testovacím scénáři nelze realizovat jinak,
• stav Díla (s přímou interakcí uživatele nebo bez ní) způsobuje kritické porušení konzistence dat, pro něž neexistuje dočasný postup nápravy.
Doplňková informace:
Dopad v testovacím prostředí:
Dílo v jeho základních funkcích nelze otestovat. Dílo způsobuje porušení konzistence dat.
Předpokládaný dopad v produkčním prostředí:
Bezprostředně ohrožuje činnost Objednatele jako orgánu státní správy nebo jeho povinnosti vyplývající ze zákona.
Závažnost 1: Blokující chyba
Závažnost 2: Kritická chyba | Pravidla pro určení chyby: Nejedná se o blokující chybu, ale chyba způsobuje alespoň jeden z následujících stavů: • nepoužitelnost či nefunkčnost důležitých funkcí Díla, přičemž požadovanou činnost předepsanou v testovacím scénáři lze realizovat použitelným a ze strany Objednatele akceptovaným náhradním způsobem, • Dílo umožňuje vykonat nepovolenou činnost, • objevují se nesprávné, neúplné nebo nekonzistentní výsledky, • objevují se závažné problémy s použitelností, chování Díla je nestabilní nebo výkonnostně nevyhovující, • stav Díla způsobuje porušení konzistence dat, při níž je četnost nebo složitost použití dočasného postupu nápravy příliš vysoká a měla by dopad na každodenní práci uživatelů. V každém z výše uvedených případů chyba zaviní, že není k dispozici důležitá a často používaná funkce Díla, nebo jej nelze spolehlivě použít pro příslušnou část každodenní činnosti. Dopad v testovacím prostředí: Dílo nelze v některé důležité funkci úspěšně otestovat nebo tato funkce není k dispozici nebo může způsobovat nekonzistenci dat. Předpokládaný dopad v produkčním prostředí: Může ohrozit činnost Objednatele jako orgánu státní správy nebo jeho povinnosti vyplývající ze zákona. |
Závažnost 3: Omezující chyba | Pravidla pro určení chyby: Nejedná se o chybu kategorie blokující nebo kritickou. Chyba způsobuje alespoň jeden z následujících stavů: • chyba zjevně komplikuje plnohodnotné využití systému, • Dílo je použitelné s omezenou funkčností, kterou lze vyřešit alternativními postupy akceptovanými Objednatelem, takže celková použitelnost není narušena. Dočasné řešení (alternativní postup) není pro Objednatele složité nebo činnost není častá, • Dílo nesprávně validuje vstupy uživatele, chyby uživatele nejsou indikovány okamžitě, • Dílo poskytuje nesrozumitelná chybová hlášení, neposkytuje jasná informativní hlášení nebo je naopak vypisuje na místě, kde by se vyskytnout neměla. Dopad v testovacím prostředí: Může omezovat testování, neboť vynucuje potřebu alternativních postupů. Předpokládaný dopad v produkčním prostředí: Bezprostředně neohrožuje činnost Objednatele jako orgánu státní správy nebo jeho povinnosti vyplývající ze zákona, ale významně snižuje jeho schopnost efektivně plnit povinnosti vyplývající ze zákona tím, že jej nutí využívat alternativní postupy, které mohou vést ke zvýšení relativní chybovosti. |
Závažnost 4: Triviální chyba | Pravidla pro určení chyby: Nejedná se o chybu v žádné z předchozích kategorií. Chyba má charakter estetické vady, překlepu, nevhodného popisku, Xxxx neposkytuje jasná chybová hlášení či informativní hlášení nebo je naopak vypisuje na místě, kde |
by se vyskytnout neměla apod. Jedná se o nedostatky, které do určité míry komplikují nebo neumožnují plnohodnotné využití Díla. Správná funkčnost a konzistence dat je zajištěna. Dopad v testovacím prostředí: Bez negativního dopadu na proces testování. Dopad v produkčním prostředí: Neohrožuje činnost Objednatele jako orgánu státní správy nebo jeho povinnosti vyplývající ze zákona. |
1.5. FAT
Testy Factory Acceptance Testing (FAT) budou provedeny na softwarových částech Díla instalovaných v infrastruktuře Zhotovitele. Integrované systémy třetích stran (GINIS, SKS atd.) budou pro účely FAT pouze simulovány.
FAT bude využívat testovací anonymizovaná data importovaná ze systému SPECTRAplus Objednatele.
Bude vypracován protokol z provedených testů se záznamem dat z testovacích scénářů. V protokolu budou také uvedeny všechny chyby, které byly nalezeny při průchodu testovacími scénáři. Chyby budou kategorizovány dle závažnosti a bude stanoven souhrnný počet nalezených chyb pro každou kategorii. Při kategorizaci chyb zjištěných při akceptaci FAT nebude pro určení jejich závažnosti přihlíženo k předpokládanému dopadu v produkčním prostředí.
Podle následující tabulky se bude určovat, zda bylo provedení FAT úspěšné, a jaký bude další postup:
Závažnost | Další postup ve FAT | Počet chyb Akceptováno | |
ano | ne | ||
1 | Oprava všech chyb závažnosti 1 a následné opakování FAT | 0 | 1+ |
2 | Pokud neakceptováno: • Snížení počtu chyb závažnosti 2 pod hranici akceptace FAT a následné opakování FAT. Pokud akceptováno: • Podpis akceptačního protokolu bez výhrad / s výhradami. • Snížení počtu chyb závažnosti 2 pod hranici akceptace SAT a následné zahájení SAT. | 0–49 | 50+ |
3 | Pokud neakceptováno: • Snížení počtu chyb závažnosti 3 pod hranici akceptace FAT a následné opakování FAT. Pokud akceptováno: • Podpis akceptačního protokolu bez výhrad / s výhradami. • Snížení počtu chyb závažnosti 3 pod hranici akceptace SAT a následné zahájení SAT. | 0–109 | 110+ |
4 | Chyby závažnosti 4 nemají vliv na výsledek FAT. Bezprostřední reakce není vyžadována. | 0+ | N/A |
Všechny nalezené chyby, které v Díle po dokončení FAT zůstanou nevyřešené, budou zaneseny do HelpDesku blíže specifikovaného v Příloze č. 9 ke Smlouvě.
1.6. SAT
Testy Site Acceptance Testing (SAT) budou provedeny na softwarových částech Díla instalovaných v testovací infrastruktuře Objednatele v konfiguraci odpovídající produkčnímu prostředí, a to včetně integrací s testovacími systémy třetích stran (GINIS, SKS atd.).
SAT bude využívat data importovaná z produkčního systému SPECTRAplus Objednatele. Data pro SAT nebudou anonymizovaná ani redukovaná z důvodu korektnosti testů. Tato data se budou nacházet pouze v prostředí Objednatele.
Bude vypracován protokol z provedených testů se záznamem dat z testovacích scénářů. V protokolu budou také uvedeny všechny chyby, které byly nalezeny při průchodu testovacími scénáři. Chyby budou kategorizovány dle závažnosti a bude stanoven souhrnný počet nalezených chyb pro každou kategorii.
Podle následující tabulky se bude určovat, zda bylo provedení SAT úspěšné a jaký bude další postup:
Závažnost | Další postup v SAT | Počet chyb Akceptováno | |
ano | ne | ||
1 | Oprava všech chyb závažnosti 1 a následné opakování SAT. | 0 | 1+ |
2 | Pokud neakceptováno: • Snížení počtu chyb závažnosti 2 pod hranici akceptace SAT a následné opakování SAT. Pokud akceptováno: • Podpis akceptačního protokolu bez výhrad / s výhradami. • Oprava všech chyb závažnosti 2. • Zahájení Průřezového testování. | 0–29 | 30+ |
3 | Pokud neakceptováno: • Snížení počtu chyb závažnosti 3 pod hranici akceptace SAT a následné opakování SAT. Pokud akceptováno: • Podpis akceptačního protokolu bez výhrad / s výhradami. • Snížení počtu chyb závažnosti 3 pod hranici akceptace Průřezového testování. • Zahájení Průřezového testování. | 0–89 | 90+ |
4 | Chyby závažnosti 4 nemají vliv na výsledek SAT. Bezprostřední reakce není vyžadována. | 0+ | N/A |
Všechny nalezené chyby, které v Díle po dokončení SAT zůstanou nevyřešené, budou zaneseny do HelpDesku.
1.7. Průřezové testování (PT)
Po akceptaci Díla (SAT) bude Dílo nainstalováno do produkčního prostředí Objednatele (prostředí včetně integrací s produkčními systémy třetích stran), ve kterém bude probíhat Průřezové testování. Jeho účelem
je ověření, že je Dílo bez vad, které samy o sobě, nebo ve spojení s jinými, brání užití / převzetí Díla, a Dílo je tak schopné řádného provozování v produkčním prostředí Objednatele.
Průřezové testování bude využívat data importovaná z produkčního systému SPECTRAplus Objednatele.
Po dobu Průřezové testování je původní produkční systém SPECTRAplus stále v plném, neomezeném provozu.
Bude vypracován protokol z provedených testů se záznamem dat z testovacích scénářů. V protokolu budou také uvedeny všechny chyby, které byly nalezeny při průchodu testovacími scénáři. Chyby budou kategorizovány dle závažnosti a bude stanoven souhrnný počet nalezených chyb pro každou kategorii.
Podle následující tabulky se bude určovat, zda bylo provedení PT úspěšné a jaký bude další postup:
Závažnost | Další postup v Průřezovém testování | Počet chyb Akceptováno | |
ano | ne | ||
1 | Oprava všech chyb závažnosti 1 a následné opakování PT. | 0 | 1+ |
2 | Oprava všech chyb závažnosti 2 a následné opakování PT | 0 | 1+ |
3 | Pokud neakceptováno: • Oprava všech chyb závažnosti 3 pod hranici akceptace PT a následné opakování PT. Pokud akceptováno: • Podpis akceptačního protokolu bez výhrad / s výhradami. • Oprava všech chyb závažnosti 3 a následné zahájení Závěrečného ověření funkčnosti. | 0-49 | 50+ |
4 | Pokud neakceptováno: • Snížení počtu chyb závažnosti 4 pod hranici akceptace a následné opakování PT. Pokud akceptováno: • Podpis akceptačního protokolu bez výhrad / s výhradami. • Zahájení Závěrečného ověření funkčnosti. | 0-99 | 100+ |
1.8. Závěrečné ověření funkčnosti
Po úspěšném Průřezovém testování a odstranění všech chyb závažnosti 3 bude provedena finální migrace dat z produkčního systému SPECTRAplus do produkčního prostředí mySPECTRA, bude odstaven původní systém SPECTRAplus a bude zahájeno Závěrečné ověření funkčnosti.
Zhotovitel se zavazuje na žádost Objednatele učiněnou v průběhu prvních 3 dnů od zahájení Závěrečného ověření funkčnosti obnovit do původního stavu (tedy stavu před zahájením Závěrečného ověření funkčnosti) systém SPECTRAplus.
Závěrečné ověření funkčnosti spočívá v plnohodnotném produkčním využívání Díla za zvýšené podpory Zhotovitele on-site. Cílem Závěrečného ověření funkčnosti je zachycení a odstranění chyb, které nebyly zaznamenány v průběhu akceptačního testování.
Délka Závěrečného ověření funkčnosti je dána Harmonogramem. Při zahájení Závěrečného ověření funkčnosti bude stanoven termín (roven datu odpovídajícímu poloviny délky Závěrečného ověření funkčnosti), ke kterému bude vyhotoven soupis nahlášených neopravených chyb. Během druhé poloviny Závěrečného ověření funkčnosti Zhotovitel opraví všechny chyby závažnosti 1, 2 a 3 uvedené v tomto seznamu. Chyby závažnosti 4 lze opravit v plánovaném SW release dodaném v rámci plnění Smlouvy na údržbu.
• Dílo je dokončeno, tedy provedeno, pokud Zhotovitel opraví všechny chyby závažnosti 1, 2 a 3 uvedené v tomto seznamu.
• Chyby nalezené až po vyhotovení tohoto seznamu budou opravovány v režimu záručního provozu.
Provedením Závěrečného ověření funkčnosti a následným podpisem předávacího protokolu Dílo přechází do záručního provozu.
1.9. Organizace akceptačního testování
O připravenosti testů FAT bude Zhotovitel písemně informovat Objednatele min. 10 pracovních dnů před navrhovaným termínem jejich konání. Současně s výzvou Zhotovitele k zahájení FAT na straně Objednatele poskytne Zhotovitel písemné prohlášení, že v rámci interního testování a přípravy na FAT neeviduje větší počet chyb, než připouští akceptační (rozhodovací) kritérium pro FAT. Následně Objednatel pod vedením Xxxxxxxxxxx, případně Objednatel samostatně ověří funkčnost díla zejména pomocí akceptovaných testovacích scénářů, aby se ověřil jeho soulad s analytickou a návrhovou dokumentací Software mySPECTRA a jejími případnými dalšími schválenými úpravami.
O připravenosti testů SAT bude Zhotovitel písemně informovat Objednatele min. 10 pracovních dnů před navrhovaným datem jejich konání. Následně Objednatel pod vedením Xxxxxxxxxxx, případně Objednatel samostatně ověří funkčnost díla zejména pomocí akceptovaných testovacích scénářů, aby se ověřil jeho soulad s analytickou a návrhovou dokumentací Díla a jejími případnými dalšími schválenými úpravami.
O připravenosti Průřezového testování bude Zhotovitel písemně informovat Objednatele min. 10 pracovních dnů před navrhovaným datem jejich konání. Následně Objednatel pod vedením Xxxxxxxxxxx, případně Objednatel samostatně ověří funkčnost díla zejména pomocí akceptovaných testovacích scénářů, aby se ověřil jeho soulad s analytickou a návrhovou dokumentací Díla a jejími případnými dalšími schválenými úpravami.
V případě neúspěšného akceptačního testování odstraní Zhotovitel zjištěné vady a následně písemně vyzve Objednatele k účasti na opakovaných testech (těch funkčních/systémových oblastí, které obsahovaly vady) min. 10 pracovních dnů před navrhovaným datem jejich konání. Objednatel si může vyžádat opakování akceptačních testů (podle příslušných testovacích scénářů), které proběhly úspěšně, ale mají souvislost s neúspěšnými akceptačními testy. Zhotovitel navrhne harmonogram opakovaného testování.
1.10.Instalace
Samotná instalace prostředí, instalace jednotlivých částí Díla do Factory Acceptance Testing Environment (FAT-E) provádí sám Zhotovitel, ostatní instalace budou prováděny Zhotovitelem v součinnosti s Objednatelem.
Zhotovitel provede instalace z vlastních zdrojů, a to ve spolupráci s Objednatelem. Objednatel je povinen poskytnout technické vybavení a spolupráci v rozsahu nezbytném pro úspěšnou instalaci. Zhotovitel poskytne instalační pokyny/požadavky na součinnost s dostatečným předstihem, v případě HW požadavků (vedoucích ke vzniku nároků na nákup nového hardware Objednatelem) min. 6 měsíců předem.
1.11.Součinnost Objednatele při instalaci a akceptačním testování
Za zajištění součinnosti na straně Objednatele odpovídá jeho Projektový manažer.
Objednatel poskytne Zhotoviteli své technické vybavení a poskytne potřebnou součinnost v rozsahu, který je nezbytný k tomu, aby Zhotovitel mohl plnit závazky vyplývající pro Zhotovitele ze Xxxxxxx o dílo.
Poskytování součinnosti Objednatele se řídí odst. 2.4. Smlouvy o dílo.
Součinnost Objednatele v souvislosti s přípravou a prováděním akceptačních testů včetně Závěrečného ověření funkčnosti zahrnuje (podle charakteru testů):
• dodávku a/nebo zajištění, a/nebo instalaci veškerého HW zařízení, spotřebního materiálu nebo jakýchkoli jiných položek, které jsou nezbytné pro plnění Díla, a které nejsou jeho součástí nebo součástí jeho dílčích dodávek, nebo které nejsou v odpovědnosti Zhotovitele jakýmkoli jiným způsobem,
• poskytnutí nezbytných a vhodně vybraných vzorků dat a šablon hlášení,
• zajištění veškerého potřebného technického vybavení a prostředí systému (LAN, WAN s dostatečnou šířkou pásma) a poskytnutí údajů nezbytných pro výkonnostní a akceptační testování,
• zajištění nezbytné instalační infrastruktury s dostatečnou kapacitou, včetně veškerých technologických požadavků vyplývajících z platné legislativy České republiky,
• zajištění přístupových práv pro příslušný personál (vzdálený přístup, bude-li to vyžádáno), pokud jde o přístup k objektům nebo zařízením (např. k počítačům, serverům), poskytnutí školícího vybavení (místnost, projektor, flipchart, jeden počítač na osobu),
• poskytnutí softwaru/licencí třetích stran k produktům, které vyžadují licence,
• zajištění náležitě kvalifikovaných osob pro školení, které mají dobré znalosti základů IT a správy kmitočtového spektra,
• zajištění náležitě kvalifikovaného správce systému, který převezme systém a bude kontaktní osobou mezi Xxxxxxxxxxxx a Objednatelem odpovědnou za hlášení problémů, přijímání nápravných opatření na základě pokynů od Zhotovitele a za řádné instalace aktualizací softwaru,
• zajištění účasti náležitě kvalifikovaných osob na provedení akceptačního testování a Závěrečného ověření funkčnosti,
• ověřování funkčnosti Díla během akceptačních testů i jiným způsobem, než průchodem testovacích scénářů,
• zaznamenávání každé nalezené vady Díla do HelpDesku bez zbytečného prodlení,
• zajišťování pravidelné údržby, kterou obvykle provádí uživatel nebo provozovatel,
• zajišťování správného používání Díla v souladu s provozními pokyny Zhotovitele,
• zajišťování bezpečnosti a integrity zálohování a obnovy softwaru a dat; Objednatel musí zajistit, aby byla provedena záloha příslušných údajů těsně předtím, než Zhotovitel provede jakoukoli práci na hardwaru nebo softwaru, který je součástí systému Objednatele,
• zajišťování aktualizací veškerého softwaru na aktuální podporovanou verzi podle požadavků Xxxxxxxxxxx.
Příloha č. 3 ke Smlouvě o dílo
ID Task Name
Doba trvání Zahájení
Dokončení
Předchůdci
Názvy zdrojů
2022
2023
2024
3. čtvrtlet 4. čtvrtlet 1. čtvrtlet 2. čtvrtlet 3. čtvrtlet 4. čtvrtlet 1. čtvrtlet 2. čtvrtlet 3. čtvrtlet 4. čtvrtlet 1. čtvrtlet 2. č
1 Příloha č. 3 - Harmonogram
608 dny
1.9. 21
29.12. 23
VII VIII IX X
XI XII I
II III IV V
VI VII VIII IX X
XI XII I
II III IV V
VI VII VIII IX X
XI XII I
II III IV
2 Podpis smlouvy o dílo, zahájení
0 dny
1.9. 21
1.9. 21
OBJ, ZHO
1.9.
70 dny | 16.9. 21 | 22.12. 21 | ||||
40 dny | 22.9. 21 | 16.11. 21 | 3 | OBJ, ZHO | OBJ, ZHO | |
3 Přípravná fáze, nastavení procesů komunikace, projektových 15 dny struktur
4 Detailní analýza
5 Zpracování výstupu Detailní analýza, včetně
implementačního, integračního a migračního plánu, Analytické konzultace
1.9. 21
21.9. 21 2
OBJ, ZHO
OBJ, ZHO
6 Předání integračních rozhraní systémů třetích stran
7 Připomínkové řízení na straně Objednatele
8 Zapracování připomínek k výstupu Zhotovitelem
9 Ověření způsobu zapracování připomínek k výstupu Objednatelem
10 Finalizace výstupu Zhotovitelem
11 Formální provedení akceptace Objednatelem
12 Odsouhlasená Detailní analýza
13 Návrhová dokumentace
14 Návrh vyšší úrovně (HLDD); Návrh nižší úrovně (LLDD)
15 Zpřístupnění stávajících integračních rozhraní systémů třetích stran
1 den
10 dny
5 dny
5 dny
5 dny
1 den
0 dny
110 dny
60 dny
5 dny
16.9. 21
17.11. 21
1.12. 21
8.12. 21
15.12. 21
22.12. 21
22.12. 21
17.12. 21
23.12. 21
17.12. 21
16.9. 21
30.11. 21
7.12. 21
14.12. 21
21.12. 21
22.12. 21
22.12. 21
19.5. 22
16.3. 22
23.12. 21
5SS
5
7
8
9
10
11
12
14SS
OBJ
OBJ ZHO OBJ
ZHO OBJ
OBJ, ZHO ZHO
OBJ
OBJ
OBJ ZHO OBJ
ZHO OBJ 22.12.
OBJ
ZHO
16 Specifikace rozhraní
17 Testovací scénáře pro FAT a SAT (zpracovává Zhotovitel v průběžné součinnosti Objednatele)
18 Připomínkové řízení na straně Objednatele
19 Zapracování připomínek k výstupu Zhotovitelem
20 Ověření způsobu zapracování připomínek k výstupu Objednatelem
21 Finalizace výstupu Zhotovitelem
22 Formální provedení akceptace Objednatelem
23 Odsouhlasená Návrhová dokumentace
24 Dodávky nezbytných aplikační SW licencí pro upgrade stávajícího systému
25 Definování SW licencí
26 Pořízení licencí
27 Instalace a konfigurace aplikačního a systémového SW
40 dny
60 dny
10 dny
5 dny
5 dny
5 dny
1 den
0 dny
120 dny
10 dny
30 dny
40 dny
23.12. 21
20.1. 22
14.4. 22
28.4. 22
5.5. 22
12.5. 22
19.5. 22
19.5. 22
12.5. 22
12.5. 22
26.5. 22
1.9. 22
16.2. 22
13.4. 22
27.4. 22
4.5. 22
11.5. 22
18.5. 22
19.5. 22
19.5. 22
26.10. 22
25.5. 22
6.7. 22
26.10. 22
12
12FS+20 dny
14;16;17
18
19
20
21
22
20
25
31;26
ZHO
OBJ, ZHO
OBJ ZHO OBJ
ZHO OBJ
OBJ, ZHO
ZHO OBJ
OBJ, ZHO
ZHO
OBJ, ZHO
OBJ ZHO OBJ
ZHO OBJ 19.5.
ZHO
OBJ
OBJ, ZHO
28 Dodávky nezbytného HW pro upgrade stávajícího systému
29 Definování HW běhového prostředí
30 Pořízení HW
31 Instalace a konfigurace HW běhového prostředí
80 dny
10 dny
60 dny
10 dny
12.5. 22
12.5. 22
26.5. 22
18.8. 22
31.8. 22
25.5. 22 20
17.8. 22 29
31.8. 22 30
ZHO OBJ OBJ
ZHO
OBJ
OBJ
Project: Příloha č. 3 - Harmonog Date: 20.8. 21
Task Split
Milestone Summary
Project Summary Inactive Task Inactive Milestone Inactive Summary
Manual Task Duration-only
Manual Summary Rollup Manual Summary
Page 1
Start-only Finish-only External Tasks
External Milestone
Deadline Progress Manual Progress
ID Task Name
Doba trvání Zahájení
Dokončení
Předchůdci
Názvy zdrojů
2022
2023
2024
3. čtvrtlet 4. čtvrtlet 1. čtvrtlet 2. čtvrtlet 3. čtvrtlet 4. čtvrtlet 1. čtvrtlet 2. čtvrtlet 3. čtvrtlet 4. čtvrtlet 1. čtvrtlet 2. č
32 Dodávky nových SW modulů pro rozšíření funkcionality celého systému a integrace se systémy Objednatele
263 dny
20.5. 22
23.5. 23
VII VIII IX X
XI XII I
II III IV V
VI VII VIII IX X
XI XII I
II III IV V
VI VII VIII IX X
XI XII I
II III IV
33 Vývoj a postupná implementace
34 Testování a odstraňování chyb (bug fixing)
35 Připravenost k FAT
36 Dodávky prací a služeb souvisejících se zákaznickými úpravami standardního (krabicového) SW
37 Vývoj a postupná implementace
38 Testování a odstraňování chyb (bug fixing)
39 Připravenost k FAT
40 Vývoj/Programování nových SW modulů, vytvoření rozhraní pro výměnu dat se SW třetích stran a jejich konfigurace
41 Vývoj a postupná implementace
42 Příprava a zpřístupnění integračního rozhraní účetního systému
43 Testování a odstraňování chyb (bug fixing)
44 Připravenost k FAT
45 Příprava a migrace testovacích dat
46 Příprava na kontrolu dat, metodika, případně vytvoření pomocných nástrojů
47 Kontrola a oprava dat
48 Příprava pro FAT
49 Příprava pro SAT, PT
50 Podepsaný Protokol o připravenosti testovacích dat
203 dny
60 dny
0 dny
263 dny
203 dny
60 dny
0 dny
263 dny
183 dny
105 dny
80 dny
0 dny
263 dny
60 dny
150 dny
40 dny
40 dny
0 dny
20.5. 22
1.3. 23
23.5. 23
20.5. 22
20.5. 22
1.3. 23
23.5. 23
20.5. 22
20.5. 22
1.6. 22
1.2. 23
23.5. 23
20.5. 22
20.5. 22
12.8. 22
29.3. 23
29.3. 23
23.5. 23
28.2. 23
23.5. 23
23.5. 23
23.5. 23
28.2. 23
23.5. 23
23.5. 23
23.5. 23
31.1. 23
25.10. 22
23.5. 23
23.5. 23
23.5. 23
11.8. 22
9.3. 23
23.5. 23
23.5. 23
23.5. 23
23
33
34
23
37
38
23
41SS
41
43
23
46
35FF;39FF;44FF;47
35FF;39FF;44FF;47
49
ZHO ZHO ZHO
ZHO ZHO ZHO
ZHO OBJ
ZHO ZHO
OBJ, ZHO OBJ
ZHO ZHO
OBJ, ZHO
OBJ
OBJ, ZHO
ZHO
ZHO
ZHO
OBJ
ZHO 23.5.
ZHO 23.5.
ZHO 23.5.
ZHO ZHO 23.5.
51 Testování dle testovacích scénářů (FAT)
52 Plánování realizace FAT
53 Příprava prostředí FAT
54 Výzva k připravenosti na FAT
55 Testování Objednatelem a opravy hlášených chyb Zhotovitelem
56 Vyhodnocení testování FAT
57 Úspěšné ukončení FAT
58 Testování dle testovacích scénářů (SAT)
59 Plánování realizace SAT
60 Příprava prostředí, včetně součinnosti Objednatele
61 Výzva k připravenosti na SAT
62 Testování Objednatelem a opravy hlášených chyb Zhotovitelem
63 Vyhodnocení testování SAT
61 dny
30 dny
10 dny
0 dny
30 dny
1 den
0 dny
41 dny
20 dny
10 dny
0 dny
20 dny
1 den
12.4. 23
12.4. 23
10.5. 23
10.5. 23
24.5. 23
5.7. 23
5.7. 23
6.7. 23
6.7. 23
20.7. 23
20.7. 23
3.8. 23
31.8. 23
5.7. 23
23.5. 23
23.5. 23
10.5. 23
4.7. 23
5.7. 23
5.7. 23
31.8. 23
2.8. 23
2.8. 23
20.7. 23
30.8. 23
31.8. 23
50FS-30 dny 52FF
52FS-10 dny 52
55
56
57
59FF
59FS-10 dny 59
62
ZHO ZHO ZHO
OBJ, ZHO
OBJ
OBJ, ZHO
ZHO
OBJ, ZHO
ZHO
OBJ, ZHO OBJ
ZHO ZHO 10.5.
OBJ, ZHO
OBJ 5.7.
ZHO OBJ, ZHO
20.7.
OBJ, ZHO OBJ
Project: Příloha č. 3 - Harmonog Date: 20.8. 21
Task
Split Milestone Summary
Project Summary
Inactive Task Inactive Milestone Inactive Summary
Manual Task
Duration-only
Manual Summary Rollup Manual Summary
Page 2
Start-only
Finish-only External Tasks External Milestone
Deadline
Progress Manual Progress
ID Task Name
Doba trvání Zahájení
Dokončení
Předchůdci
Názvy zdrojů
2022
2023
2024
3. čtvrtlet 4. čtvrtlet 1. čtvrtlet 2. čtvrtlet 3. čtvrtlet 4. čtvrtlet 1. čtvrtlet 2. čtvrtlet 3. čtvrtlet 4. čtvrtlet 1. čtvrtlet 2. č
VII VIII IX X
XI XII I
II III IV V
VI VII VIII IX X
XI XII I
II III IV V
VI VII VIII IX X
XI XII I
II III IV
64 Úspěšné ukončení SAT
65 Průřezové testování (PT)
66 Plánování realizace PT
67 Příprava prostředí, včetně součinnosti Objednatele
68 Výzva k připravenosti na PT
69 Testování Objednatelem a opravy hlášených chyb Zhotovitelem
70 Vyhodnocení testování PT
71 Úspěšné ukončení PT
72 Školící materiály a školení klíčových osob
73 Školení testerů před FAT
0 dny
41 dny
20 dny
10 dny
0 dny
20 dny
1 den
0 dny
121 dny
5 dny
31.8. 23
1.9. 23
1.9. 23
15.9. 23
15.9. 23
29.9. 23
27.10. 23
27.10. 23
1.6. 23
3.5. 23
31.8. 23
27.10. 23
28.9. 23
28.9. 23
15.9. 23
26.10. 23
27.10. 23
27.10. 23
16.11. 23
10.5. 23
63
64
66FF
66FS-10 dny 66
69
70
54FF
OBJ, ZHO
ZHO
OBJ, ZHO
ZHO
OBJ, ZHO
OBJ
OBJ, ZHO
OBJ, ZHO
OBJ, ZHO
31.8.
ZHO OBJ, ZHO
15.9.
OBJ, ZHO
OBJ 27.10.
74 Školení testerů před SAT a PT
75 Školení uživatelů před Závěrečným ověřením funkčnosti
5 dny
5 dny
13.7. 23
3.11. 23
20.7. 23
10.11. 23
61FF
81SF-5 dny
OBJ, ZHO OBJ, ZHO
OBJ, ZHO
OBJ, ZHO
76 Ukončení analytické, návrhové, vývojové, dodávkové, testovací a akceptační fáze
77 Závěrečné ověření funkčnosti
78 Vyčištění produkčního prostředí od zkušebních dat
79 Příprava finální migrace produkčních dat, včetně součinnosti Objednatele
80 Finální migrace produkčních dat, včetně součinnosti Objednatele
81 Ověření funkčnosti (produkční data), zvýšená podpora zhotovitele on-site
82 Soupis nahlášených neopravených chyb
83 Oprava všech nahlášených chyb závažnosti 1, 2 a 3
84 Vyhodnocení Závěrečného ověření funkčnosti
85 Úspěšné ukončení Závěrečného ověření funkčnosti
0 dny
45 dny
1 den
9 dny
5 dny
30 dny
0 dny
15 dny
1 den
0 dny
27.10. 23
30.10. 23
30.10. 23
30.10. 23
10.11. 23
17.11. 23
7.12. 23
8.12. 23
29.12. 23
29.12. 23
27.10. 23
29.12. 23
30.10. 23
9.11. 23
16.11. 23
28.12. 23
7.12. 23
28.12. 23
29.12. 23
29.12. 23
71
71
71
79
80
81FF-15 dny 82
81
84
OBJ, ZHO
OBJ, ZHO OBJ, ZHO OBJ, ZHO OBJ, ZHO
OBJ ZHO OBJ
OBJ, ZHO
27.10.
OBJ, ZHO OBJ, ZHO OBJ, ZHO
OBJ, ZHO
7.12. ZHO OBJ 29.12.
86 Dokumentace skutečného provedení (DSkP)
87 Zpracování DSkP
88 Připomínkové řízení na straně Objednatele
89 Zapracování připomínek k výstupu Zhotovitelem
90 Ověření způsobu zapracování připomínek k výstupu Objednatelem
91 Finalizace výstupu Zhotovitelem
92 Formální provedení akceptace Objednatelem
93 Odsouhlasená DSkP
94
95 Smluvní termín ukončení projektu
117 dny
90 dny
10 dny
5 dny
5 dny
5 dny
2 dny
0 dny
20.7. 23
20.7. 23
23.11. 23
7.12. 23
14.12. 23
21.12. 23
28.12. 23
29.12. 23
29.12. 23
22.11. 23 61
6.12. 23 87
13.12. 23 88
20.12. 23 89
27.12. 23 90
29.12. 23 91
29.12. 23 92
31.12. 23
ZHO OBJ ZHO OBJ
ZHO OBJ
OBJ, ZHO
ZHO OBJ ZHO OBJ
ZHO OBJ 29.12.
Project: Příloha č. 3 - Harmonog Date: 20.8. 21
Task Split
Milestone Summary
Project Summary Inactive Task Inactive Milestone Inactive Summary
Manual Task Duration-only
Manual Summary Rollup Manual Summary
Page 3
Start-only Finish-only External Tasks
External Milestone
Deadline Progress Manual Progress
Příloha č. 4 ke Smlouvě o dílo
Text přílohy znečitelněn z důvodu, že obsahuje obchodní tajemství.
LS telcom AG, Německo – Licenční ujednání s koncovým uživatelem systému mySPECTRA pro regulační orgány (EULA)
Příloha č. 4 ke Smlouvě o dílo
Knihovny třetích stran v systému mySPECTRA
Tento dokument obsahuje informace o knihovnách třetích stran používaných v systému mySPECTRA a jejich licenčních podmínkách. Pro tyto knihovny třetích stran platí následující licenční podmínky, které mají přednost před Licenčním ujednáním s koncovým uživatelem (EULA) nebo jinými licenčními podmínkami pro systém mySPECTRA, zejména pokud jde o přenositelnost a dostupnost zdrojového kódu pro knihovny třetích stran.