Upozornění: Text přílohy byl získán strojově a nemusí přesně odpovídat originálu. Zejména u strojově nečitelných smluv, kde jsme použili OCR. originál smlouvy stáhnete odsud
Smlouva o vytvořenísw řešení pro Multlkanálový odbavovací systém a poskytování souvisejících služeb
ZMĚNOVÝ POŽADAVEK č. 12
KE SMLOUVĚ o VYTVOŘENÍ sw ŘEŠENÍ PRO
MULTIKANÁLOVÝ ODBAVOVACÍ SYSTÉM
A POSKYTOVÁNÍ SOUVISEJÍCÍCH SLUŽEB
Smluvní strany:
Operátor ICT a.s
,
se sídlem: Dělnická 213/12, PSČ 17000 Praha 7
učo: 027 95 281
bank. spojení: Česká spořitelna, a.s.
zastoupený: Michalem Fišerem, MBA, předsedou představenstva, a JUDr. Matejem Šandorem, PhD.,
místopředsedou představenstva
(dále jen „objednatel")
a
XT-Card a.s.
se sídlem: Seifertova 327/85, 130 00 Praha 3
IČO: 27408256, DIČ: czz7408256
společnost zapsaná v obchodním rejstříku vedeném Městským soudem v Praze,
oddíl B, vložka 10398
zastoupená lng. Martinem Rejzlem, předsedou představenstva, a Ing. Tomášem Vackem,
místopředsedou představenstva
společně s
GLOBDATA a.s.
se sídlem: Na příkopě 393/11, Staré Město, 110 00 Praha 1
IČO: 05642361, mč: CZ05642361
společnost zapsaná v obchodním rejstříku vedeném Městským soudem v Praze,
oddíl B, vložka 23165
zastoupená lng. Janem Kolouškem, předsedou představenstva, a Ing. Romanem Floriánem,
místopředsedou představenstva
Smlouva o vytvořenísw řešení pro Multlkanálový odbavovací systém a poskytování souvisejících služeb
(XT-Card a.s. a GLOBDATA a.s. společně dále jen „Poskytovatel")
dnešního dne uzavřely tento Změnový požadavek č. 12 ke Smlouvě o vytvoření SW řešení pro
Multikanálový odbavovací systém a poskytování souvisejících služeb, ve znění již uzavřených Dodatků
č1ač2
(dále jen „Změnový požadavek č. 12").
1. ÚVODNÍ USTANOVENÍ
1.1 Smluvní strany spolu uzavřely dne 4. 12. 2017 smlouvu o vytvoření SW řešení pro
Multikanálový odbavovací systém a poskytování souvisejících služeb, uveřejněnou
v registru smluv pod lD smlouvy 3723792, ke které smluvní strany uzavřely dne 16. 8.
2018 Dodatek č 1, kterým byl upraven výklad vybraných ustanovení Smlouvy, a to bez
vlivu na ňnanční a věcný rozsah plnění dle Smlouvy a dále Dodatek č. 2 ze dne
22.11.2018 a Dodatek č. 3 ze dne 2. 3. 2020, jehož předmětem byly tzv. nepodstatné
změny závazku ze Smlouvy (smlouva o vytvoření SW řešení pro Multikanálový
odbavovací systém a poskytování souvisejících služeb včetně dodatků dále jen
„Smlouva") .
1.2 V souladu s čl. 7 Smlouvy „Způsob poskytování rozvoje" smluvní strany dále přistupují
k uzavření tohoto Změnového požadavku č. 12, neboťtouto cestou Objednatel zadává
plnění Rozvoje dle Smlouvy.
1.3 Akceptace dílčích změnových požadavků bude provedena v souladu s čL 10 Smlouvy.
Objednatel je oprávněn, nikoliv povinen provést akceptaci všech dílčích změnových
požadavků samostatně nebo ijako výsledný soubor.
1.4 Pravidla úhrady ceny dle tohoto změnového požadavku č. 12 jsou stanovena v odst.
12.3 Smlouvy. Tato bude objednatelem uhrazena po akceptaci všech dílčích částí
Rozvoje dle tohoto Změnového požadavku č. 12, kdy přílohu faktury tvoří
objednatelem schválený seznam realizovaných prací, který bude obsahovat rozpis
jednotlivých rolí dle člověkodnů při realizaci Rozvoje.
ZADÁNÍ ZMĚNOVÉHO POŽADAVKU
2.1 Předmětem tohoto Změnového požadavku č. 12 je realizace dílčích funkcionalit
Systému, které představují rozvojové požadavky Objednatele. Seznam dílčích
funkcionalit představuje samostatnou přílohu č. 1 tohoto dokumentu.
2.2 Vsouladu sodst. 7.1.1 písm. b) a c) Smlouvy Objednatel stanoví, že Poskytovatel
předá k akceptaci veškeré dílčí funkcionality dle přílohy č. 1 nejpozději do 101
pracovních dní od uzavření tohoto Změnového požadavku č. 12, resp. udělení
souhlasu objednatele snavrženou Analýzou změnového požadavku. Maximální
rozsah člověkodní, které mohou být Poskytovatelem na realizaci tohoto Rozvoje
čerpány, činí 150 MD.
ANALÝZA ZMĚNOVÉHO POŽADAVKU
3.1 Poskytovatel neshledává vZadání změnového požadavku dle prilohy c. 1 ktomuto
dokumentu žádné vady, kdy na tomto základě ve lhůtě stanovené odst. 7.2 Smlouvy
připojuje přílohu č. 2, která stanovi podrobné detaily Analýzy v rozsahu:
Smlouva o vytvoření SW řešení pro Multlkanálový odbavovací systém a poskytování souvisejících služeb
3.1.1 popis požadovaného plnění,
3.1.2 doba poskytnutí plnění,
3.1.3 rozsah pracnosti každé z dílčích funkcionalit, vč. konečné ceny za realizaci.
4. ZÁVĚREČNÁ USTANOVENÍ
4.1 Objednatel tímto v souladu s odst. 7.4 Smlouvy vyslovuje svůj souhlas s navrženou
Analýzou změnového požadavku a zadává Poskytovateli jeho realizaci.
4.2 Tímto Změnovým požadavkem č. 12 je na základě Analýzy dle čl. 3 výše čerpáno 131
MD v celkové hodnotě 1 048 O00,- Kč bez DPH, což odpovídá Zadání Objednatele.
4.3 Smluvní strany prohlašují, že si tento Změnový požadavek č. 12 přečetly, že s jeho
obsahem souhlasí a na důkaz toho k němu připojují svoje podpisy.
Smlouva o vytvoření SW řešení pro Multlkanálový odbavovací systém a poskytování souvisejících služeb
Příloha č. 1
Seznam požadovaných funkcionalit v rámci Rozvoje
Shrnutí
Cílem tohoto požadavku na rozvoj core vrstvy systému MOS je zajištění potřebných funkcionalit pro
možnosti využití systému v rámci dalších IDS a to konkrétně nyní potřeby systému IDOL v rámci
Libereckého kraje. Dále požadavek zahrnuje dílčí funkcionality spojené s plánovanou implementací
nového e-shopu pid.litacka.cz
Sdílení uživatelských účtů a tokenů
Jednotlivé systémy lDS, respektive e-shopy lDS budou sdílet uživatelské účty. Tudíž bude možné se
jedním účtem přih lásit na e shop pid.litacka.cz, ale také na e-shop IDOL a další. Systém bude sdílet
také veškeré osob ní údaje evidované k daným účtům. Úroveň společných dat pro e-shopy IDS bude
až do úrovně toke nů, tedy bude možné využívat určité typy tokenů napříč e-shopy a IDS.
Systém musí umožnit definovat (tabulka vazeb v DB nebo administrace nebo config) jaké typy
identifikátorů lze využívat v jakých e-shop/IDS.
Uživatelské účty
Systém již nyní umožňuje využívat více FE rozhraní e-shop, nicméně využívá jednotného
uživatelského kmene bez rozlišení toho, kde účet vznikl a veškeré OÚ přiřazené k účtům mají
jednotného správce a množinu zpracovatelů bez ohledu na to na jakém FE (e-shop, mobapp atd.)
byly registrovány.
Systém nově umožní
o Rozlišit kde byl účet registrován. Přidání parametru do příslušné APl metody, rozšíření
příslušných tabulek v DB o tento příznak.
o Bude udržovat souhlasy se zpracováním údajů dle jednotlivých subjektů -companies
O Dle funkčních požadavků na nový e-shop bude nutné udělit souhlas se zpracováním
OÚ při prvotním přihlášení na e-shopjiného lDS, než ve kterém vznikla počáteční
registrace. Při dalším přihlášeníjiž nebude souhlas vyžadován. Tato funkcionalita
musí být dostupná přes APl. Rozšíření příslušných tabulek v DB o příznak, pro jaký lDS
má udělen souhlas pro zpracování OÚ. API musí na dotaz také vrátit stav příznaku se
zpracováním OU pro danou lDS.
Pouze jeden platný identifikátor
Systém nově umožní mít pouze jeden aktivní identifikátor pro danou lDS. Tedy bude držena nově
vazba identifikátorzúčetzlDs - 1:1:1. Při zvoleníjiného právě aktivního identifikátoru pro daný účet
Smlouva o vytvoření SW řešení pro Multlkanálový odbavovací systém a poskytování souvisejících služeb
budou automaticky převedeny veškeré kupony k tomuto identifikátoru pokud by systém stále
zachovával vazbu token : kupon.
Zde necháváme ke zvážení zda nepředělat vazbu přímo na účet : kupon a účet: identiňkátor. Tedy by
automaticky při zvolení identifikátoru k účtu bylyjasné všechny platné kupony a plně by se tak
naplnila architektura account based.
Prodejce
Systém nově umožní definovat unikátního prodejce a dopravce pro dané API key. Při použití
specifického API key bude na generované faktuře uváděn příslušný prodejce a dopravce. Stejně bude
na úrovni administrace systému rozlišitelné, jaký prodejce kupon prodal. Prodejci budou vazbou
příslušet k daným lDS.
Administrace
Administrace bude nově rozlišovat novou uživatelskou roli pro daný administrátorský účet. Účty
můžou mít role vjednom či několika IDS zároveň. Pro zvolený IDS potom mají právo vidět pouze ty
uživatele, kteří mají udělený souhlas se zpracováním OÚ pro daný IDS. Následně uživatel vidí veškeré
koupené produkty, přiřazené tokeny apod. pouze pro daný IDS.
Schvalování či zamítání fotografie pro konkrétní účet bude umožněno pouze tomu administrátorovi,
který má právo pro danou IDS, v rámci které byla změněná či nová fotografie nahrána.
Potvrzovací emaily apod. bude nutné posílat z jiné adresy pro definovaná APl key, případně bude
rozesílání přeneseno do jednotlivých front-end systémů
Tarif, časové kupóny - tarifní modul — zónově relační tarif
IDS Libereckého kraje má odlišný systém tarifu než PID. Tzv. časově zónově relační.
Tarif PID ijeho veškerá pravidla jsou nyní implementovány v rámci soustavy DB tabulek a dále v kódu.
Systém bude nově implementovat zónově relační tarif, a to formou implementace a načítání dat
z definovaného XML souboru. Systém musí umožnit nové načtení aktualizovaného XML a
automaticky tak změnit tarif. Metody tohoto modulu musí být dostupné v rámci API pro e-shop,
mobilní aplikaci apod. kde daný FE zavolá tarifní modul s číslem zóny od-do, CP, TP, požadovanou
platností od a modul mu navrátí veškeré informace včetně ceny jízdenky, které budou vstupem pro
prodání a uložení požadovaného kuponu.
Informace o zastávkách jsou ve formě opendat na portále otevřených dat
( https:[(doprávnímagy.kraj-lbc.cz[ogendata[?id=584a7ad7-1680-4d8d—a20b-7068c371c416_) TYÍO
zastávky by měly být součástí FE rozhraní (číselník) kvůli rychlosti uživatelské interakce, takže
samotný tarifní modul už bude přijímat přímo informace z-do ve formě čísla zóny.
Smlouva o vytvoření SW řešení pro Multlkanálový odbavovacísystém a poskytování souvisejících služeb
Příklad volání
//výběr integrovaného do pravniho systému
idsid: "IDOL
uživatel vybírá dle názvu/l D zastávky
í
frombusid: "5455042" //Antonínov
tobusid: „5455280" //Jesenný
cp: „2" l/dítě G-18
tp: „20" //časovka 90de nní
timefrom: „20/08/2021" l/Plat nost od
)
Uživatel vybírá dl e ID zony
í
fromzoneid: "7011" /llosefův Důl
tozoneid: „8014 " //J esenný žst.
CP: „1" //dospě lý 18+
TP: „30" //časovka 366
timefrom: „20/08/2021" //platnost od
l
Systém vrátí
í
ldsid: „ido|"
fromzoneid: "7011" l/Josefův Důl
tozoneid: „8014" //Jesen ný žst.
frombusid: " 5455042" //Antonínov
tobusid: „5455280" l/Jese nný
price: „1" //dospělý 18+
TP: „22" //časovka půlroční
fromsuperzoneid: „70"
fromsuperzoneid: „80"
allowzones: „3110, 1023, 3109, 9024"
Veškeré další informace související s tarifem lze nalézt zde -> htt : www.iidol.cz strank 7:'izdenk -
Samotné XML definující kompletní tarif předá Objednatel.
cp, TP
Systém umožní samostatnou správu pro tarifní kategorie jednotlivých IDS.
Smlouva o vytvoření sw řešení pro Multlkanálový odbavovací systém a poskytovánísouvlselících služeb
Příloha č. 2
Analýza Změnového požadavku
Popis MD
21
Analyz 7
57
zapracování připomínek k analýze
7
Úpravy tarifního modulu s
3
Přidání podpory zónově relačního tarifu 3
o Import XML dat tarifu 4
Importu dat z *.dat souborů (matice možných tras z nadzóny do nadzóny, matice tarifních vzdáleností) 10
Vypočet trasy a ceny kupónu 10
3
Sdílení uživatelských účtů mezi IDS, evidence osobních údajů pro každý IDS 131
Omezení identifikátorů na pouze aktivní pro každý lDS
Rozšíření odesílání emailů pro každý IDS
Úpravy integrace platební brány o podporu více instancí
Administrace
Nové role, možnost zařadit uživatelské účty k jednomu nebo více IDS
Úprava administrace o zobrazení a práci pouze s povolenými daty
Rozšíření tokenizace
Testování průběžné
.
Aktualizace dokumentace a zdrojových kódů
Celkem MD
Jedná o průběžný změnový požadavek pro potřeby systému IDOL v rámci Libereckého kraje, jehož
zbylá část (tj. 44 MD) bude objednána do 31.7.2020.
Termín realizace do 30.9.2020