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
Příloha č. 4 ke Smlouvě o veřejných službách
SMLOUVA O SPOLUPRÁCI PŘI ZAJIŠŤOVÁNÍ DOPRAVNÍ OBSLUŽNOSTI
VEŘEJNOU LINKOVOU DOPRAVOU A VEŘEJNOU DRÁŽNÍ OSOBNÍ
DOPRAVOU
uzavřená níže uvedeného dne, měsíce a roku v souladu s ustanoveními § 24 zákona č.
129/2000 Sb., o krajích (krajské zřízení), ve znění pozdějších předpisů, a § 160, § 163 a násl.
zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů, mezi smluvními stranami:
1. Ústecký kraj
Sídlo: Velká Hradební 3118/48, 400 02 Ústí nad Labem
Zastoupený: Oldřichem Bubeníčkem, hejtmanem
IČ: 70892156
DIČ: CZ70892156
Bankovní spojení: Česká spořitelna, a.s., číslo účtu: 882733379/0800
(dále jen „Kraj“)
a
2. Statutární město Teplice
Sídlo: náměstí Svobody 2, 415 95 Teplice
Zastoupené: Jaroslav Kubera, primátor města
IČ: 00266621
DIČ: CZ0026621
Bankovní spojení:19-226501/0100
(dále jen „Město“, společně s Krajem dále jen „Smluvní strany“)
VZHLEDEM K TOMU, ŽE:
(A) Kraj v souladu s § 3 zákona č. 194/2010 Sb., o veřejných službách v přepravě
cestujících a o změně dalších zákonů, v platném znění, zajišťuje dopravní obslužnost
území Kraje veřejnými službami v přepravě cestujících veřejnou drážní osobní
dopravou a veřejnou linkovou dopravou, a to v rámci integrovaného dopravního
systému Kraje;
(B) Město v souladu s § 3 zákona č. 194/2010 Sb., o veřejných službách v přepravě
cestujících a o změně dalších zákonů, v platném znění, zajišťuje dopravní obslužnost
územního obvodu Města veřejnou drážní osobní dopravou a veřejnou linkovou
dopravou;
(C) trasy některých linek a spojů zajišťujících dopravní obslužnost území Kraje v rámci
integrovaného dopravního systému Kraje jsou zčásti vedeny v územním obvodu
Města, v důsledku čehož je dopravní obslužnost v tomto obvodu paralelně zajišťována
Krajem i Městem;
(D) podstatná část linek a spojů veřejné drážní osobní dopravy a veřejné linkové dopravy,
jejichž trasy vedou v územním obvodu Města, je provozována dopravcem zajišťujícím
dopravní obslužnost Města;
(E) je v zájmu občanů i návštěvníků Kraje a Města, kteří využívají veřejnou drážní osobní
dopravu a veřejnou linkovou dopravu, aby byly vzájemně uznávány papírové i
elektronické jízdní doklady (dále jen „jízdní doklady“) vystavované dopravci
zajišťujícími dopravní obslužnost území Kraje na straně jedné a dopravcem
zajišťujícím dopravní obslužnost územního obvodu Města na straně druhé, v důsledku
čehož mají Kraj i Město zájem na tom, aby se dopravce zajišťující dopravní
obslužnost územního obvodu Města zapojil do integrovaného dopravního systému
Kraje;
(F) vzájemné uznávání jízdních dokladů vystavovaných dopravci zajišťujícími dopravní
obslužnost území Kraje a dopravcem zajišťujícím dopravní obslužnost územního
obvodu Města ve smyslu bodu (E) výše může mít za následek, že některé tržby za
dopravní výkony provedené jedním dopravcem obdrží jiný dopravce;
(G) dopravci zajišťující dopravní obslužnost území Kraje ani dopravce zajišťující dopravní
obslužnost územního obvodu Města nenesou žádné riziko spojené s výší tržeb;
(H) lze předpokládat, že vzájemné uznávání jízdních dokladů vystavovaných dopravci
zajišťujícími dopravní obslužnost území Kraje a dopravcem zajišťujícím dopravní
obslužnost územního obvodu Města ve smyslu bodu (E) výše bude mít vliv na celkové
tržby dopravce zajišťujícího dopravní obslužnost územního obvodu Města;
(I) v důsledku shora uvedeného lze předpokládat, že může dojít i k situaci, kdy se zvýší
platba kompenzace hrazené Městem dopravci zajišťujícímu dopravní obslužnost
územního obvodu Města. V tomto případě má Kraj zájem Městu nahradit tuto
zvýšenou platbu kompenzace za podmínek sjednaných v této smlouvě;
(J) z výše uvedených důvodů je nezbytné stanovit principy vyrovnávání tržeb obdržených
dopravci zajišťujícími dopravní obslužnost území Kraje v rámci integrovaného
dopravního systému Kraje na straně jedné a dopravcem zajišťujícím dopravní
obslužnost územního obvodu Města na straně druhé mezi Krajem a Městem, jakož i
stanovit způsob řešení dalších souvisejících otázek;
DOHODLY SE SMLUVNÍ STRANY NÁSLEDOVNĚ:
Článek I.
DEFINICE POJMŮ
1. Pro účely této smlouvy budou mít následující pojmy níže uvedený význam:
a) „dopravce MHD“ znamená dopravce určeného Městem, který zajišťuje dopravní
obslužnost územního obvodu Města;
b) „dopravci DÚK“ znamenají dopravce určené Krajem, kteří v rámci DÚK zajišťují
dopravní obslužnost Kraje veřejnou linkovou dopravou a veřejnou drážní osobní
2
dopravou, výčet dopravců DÚK je uveden v příloze 1 Smluvních přepravních
podmínek DÚK zveřejněných na webu Kraje;
c) „tržby“ znamenají tržby z jízdného a tržby z přepravy zavazadel, které jsou
realizovány na základě smlouvy o veřejných službách v přepravě cestujících
uzavřené mezi dopravcem MHD a Městem nebo mezi dopravcem DÚK a Krajem;
d) „referenční měsíční tržby“ znamenají průměrné měsíční tržby dopravce MHD v Kč
bez DPH, o nichž lze předpokládat, že by byly dopravcem MHD realizovány při
neexistenci vzájemného uznávání jízdních dokladů vystavovaných dopravci DÚK
na straně jedné a dopravcem MHD na straně druhé ve smyslu této smlouvy, a které
se ve vztahu k jednotlivému kalendářnímu měsíci vypočítají jako součin (i)
dopravního výkonu skutečně realizovaného dopravcem MHD na linkách a spojích
objednávaných Městem v rámci MHD v příslušném kalendářním měsíci a (ii)
referenčních tržeb na 1 km;
e) „referenční tržby na 1 km“ znamenají průměrné tržby dopravce MHD na 1 km
provedeného dopravního výkonu v Kč bez DPH, o nichž lze předpokládat, že by
byly dopravcem MHD realizovány při neexistenci vzájemného uznávání jízdních
dokladů vystavovaných dopravci DÚK na straně jedné a dopravcem MHD na
straně druhé ve smyslu této smlouvy;
f) „DÚK“ znamená integrovaný dopravní systém Kraje nazvaný Doprava Ústeckého
kraje, v jehož rámci zajišťují dopravci určení Krajem dopravní obslužnost Kraje
veřejnou linkovou dopravou a veřejnou drážní osobní dopravou;
g) „MHD“ znamená veřejnou drážní osobní dopravu a veřejnou linkovou dopravu
(městskou hromadnou dopravu), jejímž prostřednictvím Město zajišťuje dopravní
obslužnost územního obvodu Města;
h) „zúčtovací centrum“ znamená osobu vybranou Krajem v souladu se zákonem č.
137/2006 Sb., o veřejných zakázkách, ve znění pozdějších změn, která bude
provádět rozúčtování tržeb mezi dopravci DÚK a dopravcem Města a vykonávat
další s tím související činnosti. Ke dni uzavření této smlouvy je zúčtovacím
centrem ČSAD SVT Praha, s.r.o., IČ 45805202, se sídlem Praha 8, Křižíkova 4-6.
V případě změny v osobě zúčtovacího centra Kraj sdělí identifikační a kontaktní
údaje nového zúčtovacího centra Městu nejpozději 2 měsíce před změnou v osobě
zúčtovacího centra.
Článek II.
ÚČEL SMLOUVY
1. Účelem této smlouvy je vzájemná spolupráce a koordinace Smluvních stran směřující k
(i) zajištění vzájemného uznávání jízdních dokladů vystavovaných dopravci DÚK na
straně jedné a dopravcem MHD na straně druhé opravňujících cestující k využívání
služeb veřejné drážní osobní dopravy a veřejné linkové dopravy poskytovaných těmito
dopravci a (ii) nastavení principů vyrovnávání snížených tržeb (resp. zvýšené
kompenzace hrazené Městem dopravci MHD za zajišťování provozu MHD) v důsledku
vzájemného uznávání jízdních dokladů dle této smlouvy.
3
Článek III.
PRÁVA A POVINNOSTI SMLUVNÍCH STRAN
1. Smluvní strany se dohodly na struktuře tarifu a výši cen jízdného a přepravného
uvedených v příloze č. 1 této smlouvy (dále jen „Ceník jízdného DÚK“) a na
bezplatných přepravách osob uvedených v příloze č. 2 této smlouvy (dále jen
„Bezplatné přepravy“). Smluvní strany se zavazují, že budou dodržovat strukturu
jízdních dokladů a výši cen jízdného a přepraveného dle Ceníku jízdného DÚK a
Bezplatné přepravy a že bez souhlasu druhé Smluvní strany nebudou zavádět v zóně
Teplice žádné další typy jízdních dokladů nad rámec jízdních dokladů stanovených
Ceníkem jízdného DÚK nebo bezplatné přepravy nad rámec Bezplatných přeprav,
vyjma slev závazně stanovených obecně závaznými právními předpisy (např. výměrem
Ministerstva financí, kterým se vydává seznam zboží s regulovanými cenami). Ve
vztahu ke slevám závazně stanoveným obecně závaznými právními předpisy se Smluvní
strany zavazují upravit Ceník jízdného DÚK a/nebo Bezplatné přepravy takovým
způsobem, aby neodporovaly obecně závazným právním předpisům. Kraj je oprávněn
změnit na strukturu tarifu a výši cen jízdného a přepravného uvedených v Ceníku
jízdného DÚK bez souhlasu Města pouze v případech, kdy tyto změny nebudou mít
vliv na výši jednozónových jízdních dokladů pro zónu Teplice a dopravce MHD
dostane od Kraje s dvouměsíčním předstihem veškerá data potřebná ke změnám Ceníku
jízdného DÚK, Tarifu DÚK a Smluvních přepravních podmínek DÚK, a tyto změny
nebudou mít vliv na úpravu SW, tj. bude se jednat pouze o změnu vstupních dat ve
formátu xml a binárních souborů, které dopravci MHD poskytne Kraj.
Před případným zavedením nového typu jízdního dokladu v zóně Teplice nad rámec
Ceníku jízdného DÚK uvedeného v příloze 1 této smlouvy nebo bezplatné přepravy nad
rámec Bezplatných přeprav uvedených v příloze 2 této smlouvy nebo učiněním
jakéhokoliv jiného kroku ve smyslu předchozího pododstavce (s výjimkou zavedení
slevy závazně stanovené obecně závaznými právními předpisy) musí být Smluvními
stranami uzavřen písemný dodatek k této smlouvě upravující dopady takového kroku na
práva a povinnosti Smluvních stran dle této smlouvy.
V případě zavedení slevy závazně stanovené obecně závaznými právními předpisy musí
být Smluvními stranami uzavřen písemný dodatek k této smlouvě upravující dopady
takové slevy na práva a povinnosti Smluvních stran dle této smlouvy ještě před
zavedením příslušné slevy, je-li to možné, jinak bez zbytečného odkladu po jejím
zavedení.
2. Kraj se zavazuje zajistit, že dopravci DÚK budou v rámci DÚK na linkách vymezených
přílohou 2 Smluvních přepravních podmínek DÚK,
a) od 1.1.2015 uznávat papírové jízdní doklady vydané dle Tarifu DÚK a
vystavené na zabezpečeném papíře s ochrannými prvky definovanými Krajem,
které opravňují cestující k využívání služeb veřejné drážní osobní dopravy a
veřejné linkové dopravy v zóně Teplice a které budou vydány v souladu s
přílohu č. 1 této smlouvy;
b) od 1.1.2015 uznávat elektronické jízdní doklady vydané dle Tarifu DÚK a
uložené na bezkontaktní čipové kartě Mifare DESFire EV 1 8kB, které opravňují
cestující k využívání služeb veřejné drážní osobní dopravy a veřejné linkové
dopravy v zóně Teplice a které budou vydány v souladu s přílohu č. 1 této
smlouvy;
4
c) nejpozději od 1.1.2015 akceptovat při prodeji jízdních dokladů opravňujících
cestující k využívání služeb veřejné drážní osobní dopravy a veřejné linkové
dopravy elektronické peníze v aplikaci dopravní peněženka uložené dopravcem
MHD na bezkontaktní čipové kartě Mifare DESFire EV 1 8Kb v rámci DÚK;
d) nejpozději od 1.1.2015 v rámci DÚK plnohodnotně pracovat s aplikací
elektronická jízdenka a elektronická peněženka na kartách vydaných dopravcem
MHD (tj. prodej elektronických jízdenek a jejich zápis do aplikace vydané
jménem dopravce MHD; dobíjení elektronické peněženky vydané dopravcem
MHD);
e) od 1.1.2015 umožňovat bezplatnou přepravu osob uvedených v příloze č. 2 této
smlouvy.
3. Kraj se zavazuje, že Městu poskytne veškeré potřebné informace o DÚK včetně
zejména informací o Tarifu DÚK, Smluvních přepravních podmínkách DÚK,
zúčtovacím centru a způsobu a frekvenci komunikace se zúčtovacím centrem nejpozději
2 měsíce před jakoukoliv změnou. Kraj se dále zavazuje na žádost Města zaškolit osoby
určené Městem (např. kontrolory působící u dopravce MHD) v podmínkách
relevantních pro jejich činnost v souladu s touto smlouvou a Město se zavazuje zajistit
náležitou součinnost všech osob dopravce MHD, o jejichž zaškolení požádá.
4. Kraj se zavazuje, že Městu poskytne zabezpečený papír s ochrannými prvky pro tisk
jízdních dokladů dopravcem MHD v rámci DÚK.
5. Město se zavazuje, že dopravce MHD bude vydávat papírové jízdní doklady DÚK na
zabezpečeném papíru s ochrannými prvky, který Kraj poskytne Městu a Město následně
dopravci MHD.
6. Město se zavazuje zajistit, že dopravce MHD bude na všech linkách MHD,
a) od 1.1.2015 uznávat papírové jízdní doklady vydané dle Tarifu DÚK a
vystavené na zabezpečeném papíře s ochrannými prvky definovanými Krajem,
které budou vydány v souladu s přílohu č. 1 této smlouvy, a to v souladu s jejich
časovou platností dle Tarifu DÚK a za podmínky, že jsou platné pro tarifní zónu
Teplice;
b) nejpozději od 1.1.2015 uznávat elektronické jízdní doklady vydané dle Tarifu
DÚK a uložené na bezkontaktní čipové kartě Mifare DESFire EV 1 8kB, které
budou vydány v souladu s přílohu č. 1 této smlouvy, a to v souladu s jejich
časovou platností dle Tarifu DÚK a za podmínky, že jsou platné pro tarifní zónu
Teplice;
c) nejpozději od 1. 1. 2015 v rámci DÚK akceptovat při prodeji jízdních dokladů
opravňujících cestující k využívání služeb veřejné drážní osobní dopravy a
veřejné linkové dopravy elektronické peníze v aplikaci dopravní peněženka
uložené dopravci DÚK na bezkontaktní čipové kartě Mifare DESFire EV 1 8kB;
d) nejpozději od 1. 1. 2015 v rámci DÚK plnohodnotně pracovat s aplikací
elektronická jízdenka a elektronická peněženka na kartách vydaných dopravci
DÚK (tj. prodej elektronických jízdenek a jejich zápis do aplikace vydané
jménem dopravce DÚK; dobíjení elektronické peněženky vydané dopravcem
DÚK);
e) od 1.1.2015 umožňovat bezplatnou přepravu osob uvedených v příloze č. 2 této
smlouvy.
5
7. Město se zavazuje zajistit, že potisk karet vydaných dopravcem MHD, které budou
platné v rámci celého systému DÚK, bude v souladu s grafickým manuálem karet
vydaným Krajem.
8. Město se zavazuje, že nebude měnit rozsah ročního dopravního výkonu objednaného u
dopravce MHD o více než 10 %, a to ve vztahu k plánovanému ročnímu dopravnímu
výkonu pro rok 2015 v rozsahu 2 043 046 km. Před případnou změnou rozsahu ročního
dopravního výkonu dopravce MHD o více než 10 % musí být Smluvními stranami
uzavřen písemný dodatek k této smlouvě upravující dopady takové změny rozsahu
ročního dopravního výkonu dopravce MHD na práva a povinnosti Smluvních stran dle
této smlouvy.
9. Město se zavazuje, že po celou dobu trvání této smlouvy bude zachován přinejmenším
stejný rozsah kontrol dodržování tarifních a smluvních přepravních podmínek ze strany
cestujících využívajících služeb veřejné drážní osobní dopravy a veřejné linkové
dopravy poskytovaných dopravcem MHD v rámci MHD jako v kalendářním roce 2013,
tj. 520. Pokud se v kterémkoliv kalendářním roce trvání této smlouvy sníží rozsah
objednaného dopravního výkonu dopravce MHD oproti rozsahu objednaného
dopravního výkonu dopravce MHD v kalendářním roce 2013, tj. 2 294 385 km, je
Město oprávněno pro daný kalendářní rok ve stejném poměru snížit minimální
požadovaný rozsah kontrol dodržování tarifních a smluvních přepravních podmínek ve
smyslu předcházející věty.
10. Město se zavazuje zajistit, že kontroloři a pověření zaměstnanci dopravce MHD budou
kontrolovat i jízdní doklady vydané dopravci DÚK opravňující cestující k využívání
služeb veřejné drážní osobní dopravy a veřejné linkové dopravy poskytovaných
dopravci DÚK na linkách a spojích dopravce MHD. Smluvní strany pro vyloučení
pochybností sjednávají, že cestující s neplatnou jízdenkou vydanou dopravcem DÚK (tj.
zejména jízdenkou po uplynutí časové platnosti nebo jízdenkou neplatnou v příslušné
zóně) budou považováni za cestující bez platné jízdenky.
11. Město se zavazuje, že bude samo nebo prostřednictvím dopravce MHD dodávat do
zúčtovacího centra a v záloze (kopii) Kraji úplné a správné údaje o tržbách dopravce
MHD (zejména údaje o počtu a typech jednotlivých prodaných jízdních dokladů a
tržbách z přepravy zavazadel) a případné další údaje v souladu s požadavky zúčtovacího
centra, a to v pravidelných intervalech sdělených Městu zúčtovacím centrem s alespoň
dvouměsíčním předstihem, přičemž tyto intervaly nebudou kratší než 24 hodin. Pro
komunikaci se zúčtovacím centrem budou předpokládány formáty dat definované
vstupní větou Cards Interface společnosti ČSAD SVT, jehož popis tvoří přílohu č. 3 této
smlouvy. Informace o vybraných druzích jízdních dokladů (např. SMS jízdenky,
předtištěné jízdenky prodávané v doplňkovém prodeji u řidičů a u smluvních prodejců,
jízdní doklady prodávané ve stacionárních automatech, aj.) budou dodané ve formátu
definovaném zúčtovacím centrem.
12. Město se zavazuje na žádost Kraje poskytnout Kraji bez zbytečného odkladu kopie
veškerých výkazů, které dopravce MHD předkládá nebo je povinen předkládat Městu
v souvislosti s jím poskytovanými veřejnými službami ve veřejné drážní osobní dopravě
a ve veřejné linkové dopravě, včetně zejména výkazů nákladů a výnosů (včetně tržeb)
z přepravní činnosti dle platných a účinných právních předpisů.
13. Smluvní strany se zavazují vzájemně se informovat o plánovaných změnách v jízdních
řádech linek a spojů provozovaných dopravci (spočívající např. v omezení dopravy),
které by mohly mít vliv na kapacitní požadavky veřejné drážní osobní dopravy a veřejné
linkové dopravy provozované dopravci DÚK a dopravcem MHD v územním obvodu
6
Města, vyjma nezbytných změn vyvolaných dočasnými omezeními provozu na
komunikacích či uzavírkami komunikací.
14. Smluvní strany se zavazují vzájemně se informovat nejméně 90 dní předem o veškerých
zamýšlených změnách v Tarifu DÚK a Smluvních přepravních podmínkách DÚK.
Smluvní strany pro vyloučení pochybností sjednávají, že nebude nijak dotčena možnost
uplatňování Tarifu DÚK a Smluvních přepravních podmínek DÚK ze strany dopravce
MHD a dopravců DÚK vůči všem cestujícím využívajícím jejich služby bez ohledu na
to, který dopravce těmto cestujícím vydal příslušný jízdní doklad platný dle Tarifu DÚK
a Smluvních přepravních podmínek DÚK.
15. Jestliže bude dopravce MHD zajišťovat přepravu cestujících mimo územní obvod Města
jako dopravci DÚK, zavazuje se Město zajistit, že ceny jízdních dokladů vydávaných
dopravcem MHD opravňujících k cestě do jiných zón v rámci DÚK budou shodné
s cenami jízdních dokladů vydávaných dopravci DÚK opravňujících k cestě do
takových jiných zón v rámci DÚK. Smluvní strany pro vyloučení pochybností
sjednávají, že o ceně jízdních dokladů ve smyslu tohoto odstavce bude oprávněn
rozhodovat Kraj.
16. Smluvní strany se zavazují zajistit, že tarif a smluvní přepravní podmínky budou
jednotné, resp. že Tarif DÚK a Smluvní přepravní podmínky DÚK budou zahrnovat
veškerá specifika tarifu a dalších pravidel v zóně Teplice.
a) Kraj se zavazuje zajistit, že dopravci DÚK budou (i) počínaje 1. 1. 2015
oprávněni vydávat ve svých prodejních místech jízdní doklady pro zónu Teplice
dle Ceníku jízdného DÚK uvedené v příloze 1 a dle Tarifu DÚK a Smluvních
přepravních podmínek DÚK, který bude zahrnovat veškerá specifika tarifu a další
pravidla v zóně Teplice, a (ii) počínaje 1. 1. 2015 povinni uznávat jízdní doklady
dopravce MHD platné dle Tarifu DÚK a Smluvních přepravních podmínek DÚK.
b) Město se zavazuje zajistit, že dopravce MHD bude (i) počínaje 1.12.2014,
nejdříve však po podpisu této smlouvy, oprávněn vydávat ve svých prodejních
místech jízdní doklady dle Tarifu DÚK a Smluvních přepravních podmínek DÚK
a (ii) počínaje 1. 1. 2015 povinen uznávat jízdní doklady vydané dopravci DÚK
platné v zóně Teplice dle Tarifu DÚK a Smluvních přepravních podmínek DÚK.
17. Smluvní strany se zavazují zajistit, že k 1. lednu každého druhého kalendářního roku
trvání této smlouvy počínaje kalendářním rokem 2017 budou pro období následujících
dvou kalendářních let navýšeny tarify uvedené v příloze č. 1 této smlouvy o procento
odpovídající míře inflace vyjádřené přírůstkem průměrného ročního indexu
spotřebitelských cen, která vyjadřuje procentní změnu (a) průměrné cenové hladiny za
12 po sobě jdoucích kalendářních měsíců do června bezprostředně předcházejícího
kalendářního roku oproti (b) průměrné cenové hladině za 12 po sobě jdoucích
kalendářních měsíců v období od července 2013 do června 2014, a to dle dat
uveřejněných Českým statistickým úřadem. Částka, o kterou se má v souladu
s postupem uvedeným v předcházející větě ten který tarif navýšit, musí být před jeho
případným navýšením zokrouhlena na celé koruny české v souladu s matematickými
pravidly zaokrouhlování (přičemž číslice 5 se zaokrouhluje nahoru).
Příklad: Pro roky 2017 a 2018 budou tarify uvedené v příloze č. 1 této smlouvy
k 1.1.2017 navýšeny o procento odpovídající míře inflace vyjádřené přírůstkem
průměrného ročního indexu spotřebitelských cen, která vyjadřuje procentní změnu (a)
průměrné cenové hladiny za 12 po sobě jdoucích kalendářních měsíců do června 2016
(tj. od července 2015) oproti (b) průměrné cenové hladině za 12 po sobě jdoucích
kalendářních měsíců v období od července 2013 do června 2014, a to dle dat
7
uveřejněných Českým statistickým úřadem. Pokud by měl být určitý tarif navýšen o 0,4
Kč, bude v souladu s matematickými pravidly zaokrouhlování tato částka zaokrouhlena
na 0 Kč, a tedy fakticky k žádnému navýšení nedojde. Pokud by však měl být určitý
tarif navýšen o 0,5 Kč, bude v souladu s matematickými pravidly zaokrouhlování tato
částka zaokrouhlena na 1 Kč, a tedy dojde k navýšení daného tarifu o 1 Kč.
18. Jestliže Město v rozporu s bezprostředně předcházejícím odstavcem nezajistí navýšení
kteréhokoliv z tarifů uvedených v příloze č. 1 této smlouvy, budou referenční tržby na 1
km dle této smlouvy po dobu, po kterou nebude příslušný tarif navýšen,
v odpovídajícím rozsahu sníženy.
Článek IV.
PRINCIPY VYROVNÁVÁNÍ TRŽEB MEZI KRAJEM A MĚSTEM
1. Kraj se zavazuje dorovnávat Městu za podmínek stanovených v této smlouvě referenční
tržby na 1 km, s tím, že:
referenční tržby na 1 km pro období kalendářního roku 2015 a pro období
kalendářního roku 2016 se rovnají 21,59 Kč bez DPH; v případě změny
zákonné sazby DPH pro jízdné ve veřejné dopravě Smluvní strany upraví výši
referenčních tržeb na 1 km bez DPH tak, aby výše referenčních tržeb na 1 km
s DPH byla shodná před i po změně zákonné sazby DPH s tím, že výsledek
bude zaokrouhlen matematicky na 2 desetinná místa (např. v případě změny
zákonné sazby DPH pro jízdné ve veřejné dopravě z 15 % na 17 % by
referenční tržby na 1 km činily 21,22 (po zaokrouhlení z 21,2209) Kč bez
DPH, přičemž výše referenčních tržeb na 1 km s DPH by před i po změně
zákonné sazby DPH činila 24,8285 Kč);
referenční tržby na 1 km pro období kalendářního roku 2017 a každého
následujícího kalendářního roku (Refi) se vypočítají dle vzorce:
���������������� = ����������������−1 ∙ ��������������������−1
��������������������−2
i je i-tý kalendářní rok,
Refi-1 jsou referenční tržby na 1 km platné pro bezprostředně předcházející
kalendářní rok,
Skuti-1 jsou skutečné tržby dosažené v rámci příslušné části DÚK
v bezprostředně předcházejícím kalendářním roce ze všech jízdních
dokladů, jejichž počáteční nebo cílová zóna bude zóna Teplice a
Skuti-2 jsou skutečné tržby dosažené v rámci příslušné části DÚK
v kalendářním roce bezprostředně předcházejícím předcházejícímu
kalendářnímu roku ze všech jízdních dokladů, jejichž počáteční nebo
cílová zóna bude zóna Teplice,
[například referenční tržby na 1 km pro období kalendářního roku
2017 (Ref2017) se vypočítají jako součin referenčních tržeb na 1 km
platných pro kalendářní rok 2016 (Ref2016) a podílu skutečných tržeb
na 1 km dosažených v rámci příslušné části DÚK v kalendářním roce
2016 ze všech jízdních dokladů, jejichž počáteční nebo cílová zóna
bude zóna Teplice (Skut2016) a skutečných tržeb na 1 km dosažených
8
v rámci příslušné části DÚK v kalendářním roce 2015 (Skut2015) ze
všech jízdních dokladů, jejichž počáteční nebo cílová zóna bude zóna
Teplice, tj. dle vzorce:
������������2017 = ������������2016 ∙ ��������������������������������22001156];
2. Vyrovnávání tržeb a s tím spojené zvýšené kompenzace hrazené Městem dopravci
MHD ze strany Kraje se bude řídit následujícími pravidly:
a) zúčtovací centrum na základě informací dle čl. III odst. 11 této smlouvy výše
vypočítá v souladu s předem stanoveným algoritmem zohledňujícím vlivy
zapojení dopravce MHD do DÚK ve vztahu ke každému kalendářnímu měsíci
výši tržeb dopravce MHD, která odpovídá dopravnímu výkonu realizovanému
dopravcem MHD na linkách a spojích objednaných Městem v rámci MHD
v příslušném kalendářním měsíci (dále jen „normalizované skutečné tržby
dopravce MHD“);
b) Město poskytne Kraji informace o dopravním výkonu skutečně provedeném
dopravcem MHD v rámci MHD v každém kalendářním měsíci vždy nejpozději
do 10. dne bezprostředně následujícího kalendářního měsíce (dále jen „dopravní
výkon MHD“);
c) Kraj na základě dopravního výkonu MHD a referenčních tržeb na 1 km vypočte
výši referenčních měsíčních tržeb a porovná ji s výší normalizovaných
skutečných tržeb dopravce MHD vypočítaných zúčtovacím centrem pro
příslušný kalendářní měsíc dle písm. a) výše (tj. nikoliv s výší tržeb skutečně
inkasovaných dopravcem MHD v příslušném kalendářním měsíci, ale s výší
tržeb vypočítaných zúčtovacím centrem postupem ve smyslu čl. V odst. 4 této
smlouvy);
d) v případě, že budou normalizované skutečné tržby dopravce MHD ve vyjádření
bez DPH v příslušném kalendářním měsíci vyšší než referenční měsíční tržby
bez DPH, bude Město povinno zaslat částku odpovídající tomuto rozdílu Kraji, a
to nejpozději do 21 dnů ode dne, kdy obdrží výzvu k úhradě od Kraje;
e) budou-li naopak normalizované skutečné tržby dopravce MHD ve vyjádření bez
DPH v příslušném kalendářním měsíci nižší než referenční měsíční tržby bez
DPH, bude Kraj povinen zaslat částku odpovídající tomuto rozdílu Městu, a to
nejpozději do 21 dnů ode dne, kdy obdrží od Města výzvu k úhradě obsahující
informace o dopravním výkonu MHD a zároveň bude mít k dispozici informace
ze zúčtovacího centra o normalizovaných skutečných tržbách dopravce MHD;
f) tržby z časového jízdného na období přesahující jeden měsíc budou pro účely
této smlouvy zahrnovány do tržeb celé ve vztahu k měsíci, ve kterém byly
prodány (tj. nebudou děleny poměrně podle ceny časového kupónu připadající
na příslušný kalendářní měsíc);
g) v případě změny zákonné sazby DPH pro jízdné ve veřejné dopravě nebo
v případě jiných změn právních předpisů, které budou mít vliv na pravidla
dohodnutá touto smlouvou, budou Smluvní strany jednat o případné změně
pravidel dohodnutých v této smlouvě;
h) referenční tržby na 1 km, referenční měsíční tržby a normalizované skutečné
tržby dopravce MHD budou pro účely této smlouvy zahrnovat výlučně tržby
z jízdného a přepravy zavazadel;
9
i) pro vyloučení pochybností Smluvní strany výslovně sjednávají, že referenční
tržby na 1 km, referenční měsíční tržby a normalizované skutečné tržby
dopravce MHD se musí vztahovat výlučně k dopravním výkonům provedeným
dopravcem MHD na linkách a spojích objednávaných městem v rámci MHD;
j) pro vyloučení pochybností se dále stanoví, že vyrovnávání tržeb mezi Krajem a
Městem bude prováděno v pravidelných měsíčních intervalech.
Článek V.
ZAPOJENÍ DOPRAVCE MHD DO DÚK
1. Za účelem zapojení dopravce MHD do DÚK se Město se zavazuje zajistit, že dopravce
MHD uzavře se zúčtovacím centrem smlouvu, na jejímž základě se dopravce MHD
zaváže dodržovat veškerá práva a povinnosti vyplývající z jeho účasti v DÚK stanovená
Krajem. Za tímto účelem Město zejména zajistí, že dopravce bude dodržovat práva a
povinnosti uvedená v odst. 2 až 8 níže.
2. Město se zavazuje zajistit, že v souvislosti s přistoupením k DÚK dopravce MHD:
a) bude na všech jím provozovaných linkách a spojích uznávat platné jízdní doklady
DÚK vydané dopravci DÚK, jakož i jakékoliv jiné jízdní doklady, jejichž povinné
uznávání dopravcem MHD na jím provozovaných linkách a spojích objednávaných
Městem v rámci MHD bude Kraj oprávněn jednostranně stanovit;
b) bude předávat zúčtovacímu centru data o bezkontaktních čipových kartách (pokud
byly takové karty před uvedeným datem vydány) a identifikační data o zařízeních
používaných dopravcem MHD v elektronickém odbavovacím systému;
c) poskytne Kraji veškerou možnou součinnost potřebnou k tomu, aby mohlo dojít k
bezproblémovému zapojení dopravce MHD do DÚK k 1.1.2015; v této souvislosti
zejména, nikoliv však výlučně, poskytne Kraji v Krajem stanovené lhůtě vzorovou
čipovou kartu vydávanou dopravcem MHD či technické údaje o elektronickém
odbavovacím systému používaném dopravcem MHD, resp. jakýkoliv doklad či
informaci s tím související, zúčastní se jednání souvisejících se zavedením DÚK a
dle pokynů Kraje učinit jakýkoliv další úkon nezbytný k propojení (zajištění
kompatibility) elektronických odbavovacích systému a čipových karet používaných
jednotlivými dopravci zapojenými do DÚK podle pokynů Kraje;
d) bude vydávat a akceptovat bezkontaktní čipové karty se strukturou odpovídající
struktuře BČK Ústeckého kraje, která bude Krajem sdělena dopravci MHD do 3
pracovních dnů poté, co (i) dojde k podpisu této smlouvy oběma Smluvními stranami
a zároveň (ii) se dopravce MHD vůči Kraji písemně zaváže zachovávat mlčenlivost
ohledně struktury BČK Ústeckého kraje;
e) bude předávat zúčtovacímu centru a v záloze Kraji v pravidelných intervalech
sdělených zúčtovacím centrem s alespoň dvouměsíčním předstihem, přičemž tyto
intervaly nebudou kratší než 24 hodin (i) informace o bezkontaktních čipových
kartách (nově vydané, zrušené, blokované), (ii) informace o transakcích
elektronického odbavovacího systému, (iii) identifikační data o změnách zařízení
používaných dopravcem MHD v elektronickém odbavovacím systému,
f) bude předávat Kraji informace o provedených dopravních výkonech za kalendářní
měsíc nejpozději do 10. dne následujícího kalendářního měsíce;
10
g) zajistí, aby informace o transakcích elektronického odbavovacího systému byly
úplné, a zamezí ztrátám transakcí (ztrátou transakce se rozumí přerušení vzestupné
řady čísel transakcí realizovaných dopravcem MHD);
h) bude přijímat od zúčtovacího centra aktualizovaný seznam zakázaných čipových
karet (tzv. blacklist) a tento nahrávat do všech zařízení elektronického odbavovacího
systému tak, aby nebylo možné použití zakázaných čipových karet;
i) bude evidovat elektronickým odbavovacím systémem všechny cestující
s elektronickým jízdním dokladem;
j) uzavře s Krajem smlouvu o utajení informací v souladu se vzorem uvedeným
v příloze č. 5 této smlouvy;
k) bude dodržovat Krajem stanovenou politiku bezpečnosti odbavovacího systému
DÚK, jejíž zpřístupnění dopravci MHD bude podmíněné uzavřením smlouvy o
utajení informací a uzavře s Krajem smlouvu o zajištění bezpečnosti odbavovacího
systému v souladu se vzorem v příloze č. 6 této smlouvy;
l) zajistí potřebný počet SAM modulů a poskytne Kraji veškerou jím požadovanou
součinnost tak, aby Kraj mohl na tyto SAM moduly nahrát bezpečnostní algoritmy a
klíče systému pro komunikaci s bezkontaktními čipovými kartami;
m) bude dodržovat další práva a povinnosti související s čipovými kartami a
elektronickým odbavovacím systémem, jak jsou uvedeny v příloze č. 4 této smlouvy;
n) bude kontrolovat platnost jízdních dokladů vydaných dopravcem DÚK dle Tarifu
DÚK a Smluvních přepravních podmínek DÚK zveřejněných na stránkách Kraje
www.dopravauk.cz.
3. Město se zavazuje zajistit, že komunikace dopravce MHD se zúčtovacím centrem bude
realizována prostřednictvím formátů dat definovaných vstupní větou Cards Interface
společnosti ČSAD SVT, jehož popis tvoří přílohu č. 3 této smlouvy.
4. Mezi jednotlivými dopravci zapojenými do DÚK (tj. včetně dopravce MHD) bude
probíhat v každém kalendářním měsíci vzájemné zúčtování jimi inkasovaných tržeb, a to
dle pokynů zúčtovacího centra. Zúčtovací centrum bude na základě informací
poskytnutých dopravcem MHD a dopravci zapojenými do DÚK, identifikovat ve vztahu
ke každému kalendářnímu měsíci výkony provedené dopravcem MHD výhradně na
linkách a spojích provozovaných dopravcem MHD a dopravní výkony provedené jinými
dopravci na jiných linkách v rámci DÚK. Zúčtovací centrum následně vypočte výši tržeb,
která takovým výkonům dopravce MHD odpovídá, a porovná ji s výší tržeb, kterou
dopravcem MHD v příslušném kalendářním měsíci skutečně inkasoval. V případě, že
budou tržby skutečně inkasované dopravcem MHD v příslušném kalendářním měsíci
vyšší než tržby, které souvisí s výkony provedenými dopravcem MHD, Město zajistí, že
dopravce MHD zašle částku odpovídající tomuto rozdílu třetí osobě či třetím osobám
(jiným dopravcům zapojeným do DÚK, a to přímo nebo prostřednictvím zúčtovacího
centra) prostřednictvím bankovního převodu a dle instrukcí zúčtovacího centra. Budou-li
naopak tržby skutečně inkasované dopravcem MHD v příslušném kalendářním měsíci
nižší než tržby, které by měl dopravce MHD inkasovat za výkony provedené v
příslušném kalendářním měsíci, bude dopravci MHD zaslána částka odpovídající tomuto
rozdílu třetí osobou či třetími osobami (jinými dopravci zapojenými do DÚK, a to přímo
nebo prostřednictvím zúčtovacího centra) prostřednictvím bankovního převodu a dle
instrukcí zúčtovacího centra. Město zajistí, že se dopravce MHD v souvislosti s
prováděním zúčtování dle tohoto odstavce bude řídit písemnými instrukcemi zúčtovacího
11
centra a příslušnou platbu vždy provede (resp. přijme) do 10 kalendářních dnů ode dne,
kdy dopravce MHD takovou písemnou instrukci obdrží. Kraj bude oprávněn stanovit
podrobnosti týkající se zúčtování tržeb dle tohoto odstavce a dále stanovit, ve vztahu ke
kterým jízdním dokladům bude zúčtování probíhat odlišným způsobem.
5. Kraj předá dopravci MHD ve stanovené lhůtě veškeré potřebné informace o DÚK včetně
informací o zúčtovacím centru, způsobu a frekvenci komunikace mezi dopravcem MHD
a zúčtovacím centrem a formátu dat používaných v rámci DÚK. Město zajistí, že
dopravce MHD vyvine maximální možnou součinnost při testování vzájemné
kompatibility jednotlivých součástí elektronického odbavovacího systému DÚK.
6. Město se zavazuje zajistit, že bezkontaktní čipové karty a elektronický odbavovací
systém používané dopravcem MHD budou po celou dobu jeho účasti v DÚK
kompatibilní s bezkontaktními čipovými kartami a elektronickým odbavovacím
systémem DÚK Kraje.
7. Město se zavazuje, že dopravce MHD bude vydávat karty anonymní a karty osobní.
Osobní karty budou vydávány konkrétnímu držiteli. Na osobní kartě budou natištěny
následující údaje: jméno, příjmení, datum narození, logické číslo karty ve formě čárového
kódu. Karty budou vydávány bez evidence osobních údajů, tj. osobní údaje žadatele
budou zpracovávány pouze po nezbytně dlouhou dobu nutnou pro výrobu a krátké
otestování karty.
8. Pokud to bude nezbytné pro naplnění níže uvedených principů fungování DÚK, bude
Město povinno za níže uvedených podmínek zajistit, že dopravce MHD na žádost Kraje
změní jím používaný elektronický odbavovací systém či bezkontaktní čipové karty
(případně též odchylně od parametrů bezkontaktních čipových karet či elektronického
odbavovacího systému) tak, aby byly tyto principy naplněny:
- zachování plné kontroly Kraje nad DÚK;
- fungování DÚK tak, aby byly spravedlivě distribuovány platby mezi jednotlivými
dopravci zapojenými DÚK;
- ochrana investic (vložených finančních prostředků) cestujících;
- zamezení podvodů či snížení zvýšeného rizika podvodů s nástroji DÚK; a
- efektivní a uživatelsky přátelský systém.
Po obdržení žádosti Kraje o zajištění změny elektronického odbavovacího systému či
bezkontaktních čipových karet používaných dopravcem MHD Město zajistí, že dopravce
MHD Kraji bez zbytečného odkladu předloží podrobnou kalkulaci veškerých účelných a
hospodárných nákladů, které by si taková změna vyžádala.
Pokud Kraj rozhodne, že dopravce MHD bude povinen příslušnou změnu provést,
zavazuje se Město zajistit, že dopravce MHD takovou změnu bez zbytečného odkladu
zajistí, a Kraj bude povinen dopravci MHD uhradit veškeré skutečné účelně a hospodárně
vynaložené náklady nezbytné pro její provedení.
Dopravce MHD však nebude oprávněn zajistit změnu jím používaného elektronického
odbavovacího systému či bezkontaktních čipových karet ve smyslu tohoto odstavce,
pokud a dokud o jejím provedení v souladu s výše uvedeným nerozhodne Kraj. Bude-li
rozhodnutí Kraje o provedení změny dopravcem MHD používaného elektronického
odbavovacího systému či bezkontaktních čipových karet ve smyslu tohoto odstavce
podmíněno naplněním určitých zákonných předpokladů (např. z oblasti veřejných
12
zakázek, veřejné podpory nebo jiné oblasti), nebude o provedení takové změny možné
rozhodnout dříve, než budou příslušné zákonné předpoklady naplněny.
Článek VI.
ZÁVĚREČNÁ USTANOVENÍ
1. Tato smlouva se uzavírá na dobu určitou do prosince 2024, přičemž poslední den
platnosti této smlouvy v prosinci 2024 bude Krajem upřesněn předem nejpozději dne
30.9.2023.
2. Tato smlouva nabývá účinnosti v celém rozsahu ke dni 1.1.2015 s výjimkou čl. I, čl. III
odst. 6, 9, 10, 14, 15 a 16, čl. V a čl. VI, které nabývají účinnosti podpisem smlouvy
oběma Smluvními stranami.
3. Tato smlouva může být ukončena dohodou Smluvních stran.
4. Tato smlouva může být dále jednostranně ukončena písemnou výpovědí kterékoliv ze
Smluvních stran pouze k 31. 12. příslušného kalendářního roku s výpovědní dobou
v délce nejméně 6 měsíců. Výpovědní doba dle předcházející věty počíná běžet 1. dne
kalendářního měsíce následujícího po dni, kdy byla výpověď doručena druhé Smluvní
straně.
5. Touto smlouvou nejsou zakládána žádná práva třetích osob vůči Kraji ani Městu.
6. Změny a doplňky této smlouvy lze provádět výlučně formou písemných, vzestupně
číslovaných dodatků, které se po podpisu poslední Smluvní stranou stanou nedílnou
součástí této smlouvy.
7. Smlouva je vyhotovena ve čtyřech stejnopisech, všechny s platností originálu, z nichž
dva stejnopisy obdrží Kraj a dva stejnopisy Město.
8. Tato smlouva je uzavírána jako veřejnoprávní smlouva ve smyslu § 160 zákona č.
500/2004 Sb., správního řádu, ve znění pozdějších změn. Pro vztahy touto smlouvou
výslovně neupravené se použije ustanovení § 170 zákona č. 500/2004 Sb., správního
řádu, ve znění pozdějších změn.
9. Nedílnou součástí této smlouvy jsou následující přílohy:
Příloha č. 1 – Ceník jízdného DÚK
Příloha č. 2 – Bezplatná přeprava osob
Příloha č. 3 – Popis Cards Interface
Příloha č. 4 – Čipové karty a elektronický odbavovací systém
Příloha č. 5 – Návrh smlouvy o utajení informací
Příloha č. 6 – Návrh smlouvy o zajištění bezpečnosti odbavovacího systému
10. Tato smlouva byla schválena usnesením zastupitelstva Ústeckého kraje č. 76/20Z/2014 ze
dne 15. 12. 2014 a usnesením zastupitelstva Statutárního města Teplice č. 084/14 ze dne
12. 12. 2014.
13
SMLUVNÍ STRANY PROHLAŠUJÍ, ŽE TUTO SMLOUVU UZAVŘELY NA ZÁKLADĚ VÁŽNÉ A SVOBODNÉ
VŮLE, NIKOLI V TÍSNI ZA NÁPADNĚ NEVÝHODNÝCH PODMÍNEK A NA DŮKAZ TOHO PŘIPOJUJÍ SVÉ
VLASTNORUČNÍ PODPISY.
V Ústí nad Labem dne 17. 12. 2014 V Teplicích dne 29. 12. 2014
Oldřich Bubeníček Jaroslav Kubera
Hejtman Ústeckého kraje Primátor Statutárního města Teplice
14
Příloha č. 5 ke Smlouvě o veřejných službách
Bezplatná přeprava osob
Bezplatné přepravy v rámci DÚK (vč. zóny 401 Teplice):
1. jedno dítě nebo dvě děti do 6 let v doprovodu cestujícího staršího 10 let s platným
jízdním dokladem,
2. průvodce držitele průkazu ZTP/P,
3. vodicí, asistenční nebo služební pes,
4. cestující může bezplatně přepravovat 3 ruční zavazadla; za ruční zavazadlo se
považuje:
a) snadno přenosné věci, které lze umístit ve vozidle na místo pod sedadlem
nebo nad sedadlem cestujícího nebo podle potřeby držet na klíně,
b) zavazadla do rozměru 20 x 30 x 50 cm,
c) zavazadla tyčovitého tvaru do délky 150 cm a do průměru 10 cm,
d) zavazadla tvaru desky do rozměru 80 x 100 x 5 cm,
e) zvířata ve schráně s nepropustným dnem do rozměrů 20 x 30 x 50 cm,
f) nákupní tašky na kolečkách,
g) dětské kočárky s dítětem (pro přepravu dětských kočárků bez dítěte platí
ustanovení o přepravě spoluzavazadel),
h) vozíky pro invalidy držitelů průkazů ZTP a ZTP/P,
i) zdravotní pomůcky,
j) jedna souprava lyží,
k) sáně,
l) snowboard,
m) jeden pár bruslí s chrániči nebo jeden pár kolečkových bruslí.
Bezplatné přepravy v zóně 401 Teplice nad rámec DÚK:
1. držitelé průkazů ZTP a ZTP/P,
2. doprovod dítěte do tří let věku (maximálně 1 osoba na 1 dítě). Doprovod dítěte
musí prokázat věk dítěte občanským průkazem nebo cestovním pasem.
Příloha č. 6 ke Smlouvě o veřejných službách
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Jméno: Podpis: Účinnost od: 3. 11. 2014
Zpracoval: Jiří Mareš Razítko:
Přezkoumal: Petr Semecký
INFORMACI
Schválil: David Švingr
PRO
Popis
CARDS - interface
Související dokumenty (ON, výkresy, formuláře, přílohy)
- -
Zdroj tisku:
\\samba\SVT-dokument\Dokumentace\Rizena\CE02-PO-CARDS-Interface\CE02-PO-CARDS-Interface-3_17.pdf
Dokument je distribuován a řízen elektronicky, jestliže v papírové podobě není označen razítkem pro řízení dokumentu,
podpisem správce dokumentace a červeným číslem kopie. Platnost výtisku elektronicky distribuovaného dokumentu ověří
uživatel tak, že zkontroluje platnost odpovídajícího elektronického dokumentu na serveru (jen jméno souboru). Ověření
provede před použitím vytištěného dokumentu, ověření má platnost 7 dní, o ověření provede záznam v připojené tabulce.
Datum Podpis Datum Podpis Datum Podpis
Vydání 3 Revize 17 Strana 1/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
OBSAH
Popis....................................................................................................................................... 1
CARDS - interface................................................................................................................... 1
1.Účel.................................................................................................................................. 5
2.Působnost......................................................................................................................... 5
3.Význam použitých zkratek a Definice pojmů.....................................................................5
3.1.Význam použitých zkratek..........................................................................................5
3.2.Definice pojmů........................................................................................................... 5
3.2.1.Vydavatel karet....................................................................................................5
3.2.2.Dopravce............................................................................................................. 5
3.2.3.Subjekt................................................................................................................ 5
3.2.4.Vlastník karty.......................................................................................................5
3.2.5.Aplikace na kartě.................................................................................................5
3.2.6.Kontrakt v aplikaci...............................................................................................6
3.2.7.Skupina (síť)........................................................................................................6
4.Text popisu....................................................................................................................... 6
4.1.Obecná specifikace....................................................................................................6
4.1.1.Způsob komunikace............................................................................................6
4.1.2.Zpracování zpráv.................................................................................................6
4.1.3.Formát zasílaných zpráv......................................................................................6
4.1.3.1.Zabezpečení zpráv proti modifikaci...........................................................7
4.2.Rozhraní mezi clearingovým centrem a subjekty.......................................................8
4.2.1.Operace na rozhraní............................................................................................9
4.2.1.1.Vydání aplikace na kartě...........................................................................9
4.2.1.2.Vydání kontraktu pro MAD aplikaci...........................................................9
4.2.1.3.Hromadné vydání aplikací na kartách.......................................................9
4.2.1.4.Vydání karty..............................................................................................9
4.2.1.5.Lokální seznam zakázaných karet, aplikací či kontraktů.........................10
4.2.1.6.Změna platnosti aplikace (kontraktu) elektronická peněženka................10
4.2.1.7.Transakce za zařízení.............................................................................10
4.2.1.8.Předplacené položky (greenlist)..............................................................11
4.2.1.9.Lokální seznam předplacených položek (greenlist).................................11
4.2.1.10.Seznam předplacených položek (greenlist)...........................................11
4.2.1.11.Změna lokálního seznamu zařízení.......................................................11
4.2.1.12.Vytvoření přístupu vlastníka karty do systému......................................12
4.2.1.13.Informace o zůstatku aplikace (kontraktu) elektronická peněženka......12
4.2.1.14.Seznam návrhů na zablokování aplikací (kontraktů).............................12
4.2.1.15.Seznam subjektů clearingu...................................................................12
4.2.1.16.Seznam akceptovatelných subjektů......................................................12
4.2.1.17.Globální seznam zablokovaných karet, aplikací či kontraktů................13
4.2.1.18.Chyba během zpracování.....................................................................13
4.2.2.Popis obecných atributů....................................................................................13
4.2.3.Vydání aplikace na kartě...................................................................................14
4.2.4.Vydání kontraktu pro MAD aplikaci....................................................................15
4.2.5.Hromadné vydání aplikací na kartách................................................................16
4.2.6.Vydání karty.......................................................................................................17
4.2.7.Lokálním seznam zakázaných karet, aplikací či kontraktů................................18
4.2.7.1.Verze bez identifikace skupiny................................................................19
4.2.8.Změna platnosti aplikace MAD nebo aplikace (kontraktu) elektronická
peněženka.................................................................................................................. 19
4.2.9.Transakce za zařízení.......................................................................................20
4.2.9.1.Transakce bez možnosti hotovostních položek a s předplacenými
položkami (greenlist)...........................................................................................29
4.2.9.2.Transakce bez možnosti hotovostních položek.......................................31
4.2.9.3.Transakce bez možnosti uvedení položek..............................................32
Vydání 3 Revize 17 Strana 2/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.9.4.Verze nadále pracující s odpočty............................................................32
4.2.10.Předplacené položky (greenlist)......................................................................34
4.2.11.Lokální seznam předplacených položek (greenlist).........................................35
4.2.12.Seznam předplacených položek (greenlist).....................................................35
4.2.13.Změna lokálního seznamu zařízení.................................................................36
4.2.14.Vytvoření přístupu vlastníka karty do systému.................................................37
4.2.15.Informace o zůstatku aplikace (kontraktu) elektronická peněženka................38
4.2.16.Seznam návrhů na zablokování aplikací (kontraktů).......................................38
4.2.17.Seznam subjektů clearingu..............................................................................39
4.2.18.Seznam akceptovatelných subjektů.................................................................39
4.2.19.Globální seznam zakázaných karet, aplikací či kontraktů................................40
4.2.19.1.Verze bez identifikace skupiny..............................................................40
4.2.20.Chyba během zpracování................................................................................40
4.2.21.DTD jednotlivých zpráv....................................................................................41
4.2.21.1.DTD seznamu zpracovávaných souborů...............................................41
4.2.21.2.DTD vydání aplikace na kartě...............................................................41
4.2.21.3.DTD vydání kontraktu pro MAD aplikaci...............................................42
4.2.21.4.DTD hromadného vydání aplikací na kartách.......................................42
4.2.21.5.DTD vydání karty..................................................................................43
4.2.21.6.DTD lokálního seznamu zakázaných karet, aplikací či kontraktů..........43
4.2.21.7.DTD lokálního seznamu zakázaných karet, aplikací či kontraktů bez
identifikace skupiny.............................................................................................44
4.2.21.8.DTD změny platnosti aplikace MAD nebo aplikace (kontraktu)
elektronická peněženka......................................................................................44
4.2.21.9.DTD transakcí za zařízení.....................................................................45
4.2.21.10.DTD transakcí bez možnosti hotovostních položek a s předplacenými
položkami (greenlist)...........................................................................................48
4.2.21.11.DTD transakcí bez možnosti hotovostních položek.............................50
4.2.21.12.DTD transakcí za zařízení bez podpoložek.........................................52
4.2.21.13.DTD transakcí za zařízení po odpočtech............................................53
4.2.21.14.DTD předplacených položek (greenlist)..............................................54
4.2.21.15.DTD lokálního seznamu předplacených položek (greenlist)................55
4.2.21.16.DTD seznamu předplacených položek (greenlist)...............................55
4.2.21.17.DTD změny lokálního seznamu zařízení.............................................56
4.2.21.18.DTD vytvoření přístupu vlastníka karty do systému............................56
4.2.21.19.DTD informace o zůstatku aplikace (kontraktu) elektronická peněženka
............................................................................................................................ 56
4.2.21.20.DTD seznamu návrhů na zablokování aplikací (kontraktů).................57
4.2.21.21.DTD seznamu subjektů clearingu.......................................................57
4.2.21.22.DTD seznam akceptovatelných subjektů............................................57
4.2.21.23.DTD globálního seznamu zakázaných karet.......................................58
4.2.21.24.DTD chyby během zpracování............................................................58
4.3.Servisní rozhraní mezi subjekty a clearingovým centrem.........................................59
4.3.1.Operace na rozhraní..........................................................................................59
4.3.1.1.Inicializace aplikace (kontraktu) elektronická peněženka........................59
4.3.1.2.Inicializace aplikace (kontraktu) časový kupón.......................................59
4.3.2.Inicializace aplikace (kontraktu) elektronická peněženka..................................60
4.3.3.Inicializace aplikace (kontraktu) časový kupón..................................................61
4.3.4.DTD jednotlivých zpráv......................................................................................62
4.3.4.1.DTD inicializace aplikace (kontraktu) elektronická peněženka................62
4.3.4.2.DTD inicializace aplikace (kontraktu) časový kupón...............................62
4.4.Jak převést data.......................................................................................................63
4.4.1.Vydání karty.......................................................................................................63
4.4.2.Dobití peněženky...............................................................................................64
4.4.3.Reklamace elektronické peněženky..................................................................64
4.4.4.Jízda na elektronickou peněženku.....................................................................64
Vydání 3 Revize 17 Strana 3/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.4.5.Vrácení elektronických peněz............................................................................64
4.4.6.Prodej nového případně prodloužení existujícího kupónu – hotovostní platba...65
4.4.7.Jízda na kupón..................................................................................................66
4.4.8.Prodej kupónu placeného elektronickou peněženkou s okamžitou jízdou.........67
5.Pravomoci a odpovědnosti..............................................................................................67
6.Dokumentace a záznamy výsledků................................................................................67
7.Změnová služba.............................................................................................................68
8.Přehled revizí..................................................................................................................68
Přílohy............................................................................................................................... 73
Vydání 3 Revize 17 Strana 4/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
1. ÚČEL
Tento popis specifikuje rozhraní mezi clearingovým systémem CARDS EXCHANGE a
odbavovacím systémem dopravce. Tedy skupinu XML zpráv, které jsou použity pro zasílání
dat. Obsahem specifikace není popis uživatelského rozhraní systému, či jiných komponent.
2. PŮSOBNOST
Tento popis je určen pro dodavatele odbavovacích systémů dopravců, kteří jsou nuceni
provést konverzi svých dat do podoby vyžadované touto specifikací.
3. VÝZNAM POUŽITÝCH ZKRATEK A DEFINICE POJMŮ
3.1. Význam použitých zkratek
Zkratka Význam
Clearing Clearingový systém CARDS EXCHANGE
CARDS ČSAD SVT Praha s.r.o.
SVT
XML, Formát posílání dat, více viz http://www.w3.org/XML/
DTD
HTTP Komunikační protokol požadavek/odpověď používaný v prostředí internetu
(http://www.faqs.org/rfcs/rfc1945.html a http://www.faqs.org/rfcs/rfc2616.html)
HTTPS Bezpečný HTTP (http://www.faqs.org/rfcs/rfc2818.html
a http://www.faqs.org/rfcs/rfc2817.html)
ISO-639 ISO norma pro kódování jazyka do podoby dvouznakového řetězce
(http://www.iso.org/iso/home/standards/language_codes.htm)
ISO-3166 ISO norma pro kódování kódů zemí do dvouznakového řetězce
(http://www.iso.org/iso/country_codes.htm)
ISO-8601 ISO norma pro zápis data, času a časových intervalů
(http://www.iso.org/iso/home/standards/iso8601.htm)
XML W3C specifikace pro podepisování XML dokumentů nebo jejich částí
Signature (http://www.w3.org/TR/xmldsig-core/)
SHA1 Hashovací algoritmus (http://en.wikipedia.org/wiki/SHA-1)
MAD Mifare Application Directory (http://www.mifare.net/en/technology/mifare-
3.2. application-directory/), pro naše potřeby je podstatné, že na kartu se umisťují
aplikace, např. el. peněženka nebo dopravní kupón, a v nich mohou ještě
existovat kontrakty, např. jednotlivé kupóny se zónami a platností
Definice pojmů
3.2.1. Vydavatel karet
Účastník clearingu, který vydává karty, které ostatní používají.
3.2.2. Dopravce
Účastník clearingu, který akceptuje karty k placení jízdného.
3.2.3. Subjekt
Účastník clearingu (dopravce, vydavatel karet a nebo obojí současně).
3.2.4. Vlastník karty
Cestující, který si nechal vydat kartu.
Vydání 3 Revize 17 Strana 5/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
3.2.5. Aplikace na kartě
Např. elektronická peněženka, časový kupón (nebo též jenom kupón – někdy se používá i
termín časová jízdenka nebo předplatní časová jízdenka).
3.2.6. Kontrakt v aplikaci
Obdoba aplikace na kartě, taktéž může být např. elektronická peněženka a nebo časový
kupón. Kontrakt je v aplikaci typu "mad". Vytváří strukturu podobnou struktuře na kartě
používající MAD.
3.2.7. Skupina (síť)
Dopravci jsou pro lepší organizaci shlukováni do skupin (sítí). Skupinou rozumíme např.
Středočeský kraj. Každá skupiny má definovanou dobu na dodání dat (jak dlouho od vzniku
transakce může maximálně trvat dodání transakce do clearingového centra), den závěrky
(kolikátý den v měsíci) a dobu hájení dopravců (především doba na rozdistribuování
seznamu zakázaných karet do zařízení).
4. TEXT POPISU
Popis rozhraní (zpráv) clearingového systému je rozdělen na 2 skupiny:
• zprávy běžně používané subjekty pro komunikaci s clearingovým centrem
• servisní rozhraní pro komunikaci, která je manuálně kontrolována provozovatelem
clearingového centra
4.1. Obecná specifikace
V následujících kapitolách jsou popsány jednotlivé zprávy, které slouží k rutinní komunikaci
mezi subjektem a clearingovým centrem.
4.1.1. Způsob komunikace
Jedním z cílů clearingového systému je zjednodušení vztahů mezi vydavateli karet a
dopravci. Proto v systému existuje clearingové centrum, s nímž ostatní komunikují podle
schématu každý s jedním a jeden se všemi.
Pro jednoduché napojení všech participantů clearingového systému na centrum je vhodné
volit internet, který je již v dnešní době hodně rozšířen. Pro zajištění bezpečnosti
komunikace je potřeba použít bezpečnou variantu protokolu HTTP, tj. HTTPS. Tento způsob
komunikace je šifrován, tudíž není možné odposlechnout obsah komunikace mezi serverem
a klientem.
Pro jednoznačnou identifikaci uživatele subjektu je použita trojice: kód subjektu, uživatelské
jméno a heslo, které nebude posíláno v otevřené podobě internetem, ale bude zasíláno v
zabezpečené podobě (tj. již v bezpečném kanálu).
Všechna komunikace je ve tvaru žádost a odpověď. Komunikaci vždy iniciuje subjekt
clearingu. Pokud subjekt clearingu zasílá data do centra, tak je centrum potvrzuje ve své
odpovědi. Centrum si musí poradit se situací, kdy jsou mu stejná data poslána znova. Pokud
subjekt clearingu vyžaduje data a pokud mu nedorazí v pořádku, vyžádá si je opakovaně.
4.1.2. Zpracování zpráv
Za jednotku operace je považována zpráva (soubor), tj. zpráva je zpracována celá, nebo
vůbec. Výjimku tvoří posílání transakcí a vydání karet, kde může být zpracována jakákoliv
část souboru. Clearingovému systému tato skutečnost nevadí, protože on detekuje, která
část souboru již byla nahrána a která nikoliv. Při případném opakovaném zpracování
clearingové centrum zpracovává pouze nezpracovanou část souboru.
Pokud chyby ve zpracování nejsou považovány za fatální a pokud zaslaný požadavek
podporuje opakované zpracování, nedojde k přerušení zpracování návazných souborů, tedy
např. při výdeji aplikace na kartě, nelze-li aplikaci vydat, pak je o tom uživatel pouze
informován a ostatní vydání jsou provedena.
Vydání 3 Revize 17 Strana 6/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.1.3. Formát zasílaných zpráv
Jak je uvedeno výše komunikace mezi subjekty clearingu a rozhraním probíhá přes internet.
Tato komunikace je realizována posíláním souborů protokolem HTTPS. Tyto soubory
obsahují všechna potřebná data uvedená v předchozí kapitole.
Data jsou posílána ve formátu XML, který je hodně rozšířen a je vhodný pro komunikaci
mezi „nezávislými" subjekty. Protože je tento formát poměrně „upovídaný", pak je vhodné
soubory s XML ještě posílat v komprimované podobě. Zde je vhodné použít ZIP formát, který
je též hojně rozšířen.
V případě použití ZIP formátu je možné odeslat více souborů v jednom ZIP archivu.
Zpracování souborů probíhá podle pořadí uvedeného ve speciálním souboru ce.xml (viz
kapitola 4.1.3.1) nebo není-li uveden pak v abecedním pořadí podle názvů. Pořadí může být
důležité např. při výdeji karty a jejím následném dobití, kde výdej musí být před nabitím, jinak
dojde k chybě. Jako odpověď je opět odeslán ZIP soubor se stejným počtem souborů, jako
obsahoval odesílaný ZIP soubor (obsahuje méně souborů, pokud u zpracování některého
souboru dojde k chybě, která přeruší zpracování). Jména souborů budou všechna stejně
změněna (bude přidán suffix „-res" - jako response - odpověď, před poslední tečku v názvu
souboru, není-li v názvu tečka, pak na jeho konec). Tato konvence umožňuje v odpovědi
identifikovat soubory, které jsou reakcí na zvolení požadavek a opačně - navíc je zajištěno,
že soubory nemají stejná jména. Jména souborů nesmějí obsahovat následující řetězce
znaků: „../", „~", „/", „\", „*", „&". Navíc jméno souboru ce.xml je rezervováno pro speciální
soubor popisující obsah ZIP archivu (viz kapitola 4.1.3.1)
Všechny zprávy obsahují specifikace verze zprávy, což umožní vyvíjet protokol a zároveň
zachovat zpětnou kompatibilitu. Každá zpráva navíc obsahuje atribut lang, kde může
odesílatel požadavku specifikovat, jaký jazyk preferuje pro zasílání odpovědí (jde především
o textová pole - např. typu důvod návrhu na zablokování aplikace či vysvětlení nezdaření
operace). Hodnota atributu je složena z dvouznakového kódu jazyka (např. cs - čeština, en -
angličtina) dle normy ISO-639, volitelně následována podtržítkem a dvouznakovým kódem
země (např. CZ - Česká republika, US - Spojené Státy Americké, UK - Velká Británie) dle
normy ISO-3166. Takže platná hodnota atributu lang je např. cs, cs_CZ, en, en_US, en_UK.
Server se pokusí poslat odpověď v požadovaném jazyce, nebude-li to možné odešle ji v
anglickém jazyce.
4.1.3.1. Zabezpečení zpráv proti modifikaci
Zprávy nejsou nijak kódovány, aby se subjekt mohl kdykoliv podívat, jaká data odesílá, či
dostává zpět. Bohužel tato skutečnost umožňuje modifikování zpráv bez možnosti odhalení
této skutečnosti.
Chceme-li zabránit modifikaci, pak každá zpráva musí na konci obsahovat XML Signature
(podpis), který je vždy verifikován. Pokud je platný, zpráva nebyla měněna, pokud je
neplatný, zpráva byla modifikována a bude odmítnuto její zpracování. Ve své podstatě se
jedná o hash XML dokumentu, který je dále zakódován privátním klíče odesílatele. Pro
ověření je rozkódován pomocí veřejného klíče odesílatele známého příjemci. Existence
podpisu v dokumentech posílaných a přijímaných subjektem bude vynucena nastavením
parametrů subjektu, nikoliv rozhraním samotným.
Podpis je vložen přímo do podepisovaného XML dokumentu (enveloped signature). Jako
hashovací algoritmus je použit SHA1 a pro kódování DSA klíče (privátní a veřejný). V
podpisu nebude předáván veřejný klíč pro ověření platnosti podpisu, tento klíč odesílatele
bude muset příjemce znát (bude se pouze přenášet domluvené jméno klíče, podle kterého
identifikuje příjemce konkrétní klíč).
Vydání 3 Revize 17 Strana 7/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Podepsaný soubor s transakcemi vypadá:
...
d5zYkk1VGVUBhY9rbYh02LTwHCQ=
FuyTkfsz3BCtRZj2ZexVHyTfHbdEpanAfqodsvkBWrxFM29aNYdCsw==
KEY_NAME
V neposlední řadě je nutno zabránit možnosti smazání nebo přidání celého souboru, který by
mohl být zpracován, do ZIP archivu (jak do ZIPu posílaného tak odesílaného). Tento
problém řeší existence souboru s názvem ce.xml, který má následující obsah:
Každý soubor, který se má zpracovat je reprezentován tagem file, kde v atributu name je
jeho jméno. Soubory jsou zpracovávány v pořadí, v jakém jsou uvedeny. Tento soubor musí
být samozřejmě opatřen podpisem, aby nemohl být neautorizovaně měněn (viz výše).
Přítomnost tohoto souboru bude vynucena stejně jako přítomnost podpisu dokumentů. Jako
odpověď na tento soubor je soubor ce-res.xml se seznamem zpracovaných souborů:
Počet souborů v požadavku a v odpovědi se může lišit, protože při zpracovaní souboru může
dojít k chybě, která zastaví celé zpracování. Obsah a význam je obdobný jako v případě
požadavku.
Specifikace DTD viz kapitola 4.2.21.1.
4.2. Rozhraní mezi clearingovým centrem a subjekty
Tyto zprávy jsou určeny pro přímou rutinní komunikaci mezi jednotlivými subjekty a
clearingovým centrem.
Vydání 3 Revize 17 Strana 8/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Popis je rozdělen na následující tematické celky:
• popis jednotlivých operací rozhraní
• podrobná specifikace obsahu (struktura dat) pro jednotlivé zprávy
• reference použitých DTD pro dříve popsané zprávy
4.2.1. Operace na rozhraní
Dále jsou popsány jednotlivé typy zpráv, které jsou rozhraním podporovány.
4.2.1.1. Vydání aplikace na kartě
Zpráva je zasílána jako informace o vydání aplikace na kartě (vydavatelem je subjekt zprávu
zasílající). Pokud karta, na které je aplikace vydávána neexistuje, pak je automaticky vydána
a jejím vydavatelem je subjekt, jenž soubor zaslal.
Primárně je nutné specifikovat, o jaký typ aplikace se jedná: elektronická peněženka, časový
kupón případně MAD. Typ MAD je učen jako kontejner pro kontrakty, které jsou konkrétními
kupóny. Důležitá je též platnost (od, do) aplikace. Na kartě může v každý okamžik existovat
pouze jedna platná aplikace s konkrétním číslem aplikace. Dále je nutno specifikovat
počítadlo transakcí za aplikaci (zda se nepoužívá, zda je za aplikaci či za kartu).
Odpovědí je zpráva obsahující jednotlivé aplikace spolu s příznakem, zda byly vydány, či
nikoliv. Pokud nebylo vydání úspěšné, pak je přidán důvod nevydání.
Podrobnější popis zpráv nejdete v kapitole 4.2.3.
4.2.1.2. Vydání kontraktu pro MAD aplikaci
Pokud je jako typ aplikace specifikován MAD, pak tato aplikace může obsahovat tzv.
kontrakty, které představují konkrétní zúčtovatelné jednotky. Vydání kontraktu pro MAD
aplikaci je obdoba vydání aplikace na kartě (viz kapitola 4.2.1.1) s tím rozdílem, že kontrakt
je specifikován svým číslem a aplikací (aplikace je specifikována svým číslem a kartou),
kontrakt již nemůže být typu MAD a kontrakt musí mít platnost uvnitř platnosti mateřské MAD
aplikace. Vydavatelem kontraktu je subjekt zprávu zasílající.
Atributy, které je nutné pro kontrakt specifikovat jsou stejné jako pro aplikaci, navíc je možné
jako počítadlo použít počítadlo transakcí za kontrakt. Kontrakty nepodporují předvydání
kupónů.
Odpověď je opět analogická odpovědi vydání aplikace, pouze je opět dodána specifikace
kontraktu.
Podrobnější popis zpráv najdete v kapitole 4.2.4.
4.2.1.3. Hromadné vydání aplikací na kartách
Zpráva pro hromadné vydání karet je rozšířením zprávy pro vydání aplikace (viz kapitola
4.2.1.1) s tím, že je možné specifikovat subjekt, který aplikaci vydal. Je tedy možné, aby tato
zpráva byla zaslána jiným subjektem, než subjektem, jenž je z pohledu clearingového centra
vydavatelem aplikace. Hromadné vydání nepodporuje předvydání a následnou aktivaci
kupónů. Používá se především v případě hromadného vydávání karet jedním subjektem v
zastoupení subjektů druhých.
Odpověď je obdobná s odpovědí na vydání aplikace.
Podrobnější popis zpráv najdete v kapitole 4.2.5.
4.2.1.4. Vydání karty
Pokud je nutné vydat kartu jiným vydavatelem než aplikace, nelze použít ani vydání aplikace
ani hromadné vydání aplikací, protože tam je vždy karta vydána (pokud již neexistuje)
stejným subjektem jako aplikace. Proto existuje vydání karty, kde je možné specifikovat
jakým subjektem má být karty vydána.
Odpovědí je seznam vydaných a nevydaných karet.
Podrobnější popis zpráv najdete v kapitole 4.2.6.
Vydání 3 Revize 17 Strana 9/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.1.5. Lokální seznam zakázaných karet, aplikací či
kontraktů
Účelem této zprávy je možnost blokovat jednotlivé karty, jejich aplikace, případně jejich
kontrakty. Žádost o zablokování karty, aplikace či kontraktu může zaslat pouze její
vydavatel. Zpráva vždy obsahuje všechny zablokované položky (neposílají se tedy změny,
ale vždy celý seznam). Okamžikem zpracování zprávy jsou karty, aplikace či kontrakty
umístěny na globální seznam zakázaných a jsou distribuovány ostatním subjektům. Z
hlediska clearingového centra je karta, aplikace či kontrakt zablokován okamžikem, kdy je
zaslán lokální seznam, na kterém figuruje.
Odpovědí je globální seznam zakázaných karet, aplikací či kontraktů. Ten obsahuje všechny
karty, aplikace či kontrakty, které může subjekt, jemuž se globální seznam zasílán,
akceptovat (určeno podle vydavatele a práv na akceptaci jím vydaných aplikací) spolu s
datem a časem od kdy na seznamu figurují. Atributem tohoto seznamu je datum jeho
poslední změny.
Globální seznam zakázaných karet, aplikací či kontraktů existuje i v rozšířené variantě (ta
základní je pouze z důvodů zpětné kompatibility), která navíc pro každou zablokovanou
položku obsahuje informaci o skupině (síti), ve které byla vydána. Dále obsahuje i informaci
o časovém intervalu, po kterém je karta ze seznamu smazána, pokud na ni nebyla vytvořena
transakce (tj. pokud karta není používána).
Podrobnější popis zpráv najdete v kapitole 4.2.7.
4.2.1.6. Změna platnosti aplikace (kontraktu)
elektronická peněženka
Protože elektronické peněženky jsou v porovnání s kupóny dlouhodobě existující aplikace, je
též možné měnit jejich atributy jako např. jejich platnost. Takže tato zpráva slouží pouze ke
změně platnosti aplikací (kontraktů) typu elektronická peněženka. Změnu je možné provést
oběma směry (prodloužení i zkrácení) ovšem vždy je možné měnit pouze platnost do. Při
zkracování platnosti, není možné platnost do posunout do minulosti. Změnu platnosti může
provést pouze vydavatel elektronické peněženky.
Odpovědí je seznam požadavků na změnu platnosti spolu s příznakem, zda byla změna
úspěšná. Pokud nebyla, je přidán i důvod, proč nebylo možné změnu provést.
Podrobnější popis zpráv najdete v kapitole 4.2.8.
4.2.1.7. Transakce za zařízení
Jedná se o nejsložitější skupinu zpráv. V každé zprávě jsou transakce pouze za jedno
zařízení. V zásadě existují dva různé druhy zprávy (podle typu kontroly úplnosti dat):
• po transakcích - je zasílána každá transakce na zařízení vytvořená, protože kompletnost
dodaných dat se kontroluje na úrovni jednotlivých transakcí, kterých může být více typů:
karetní (z hlediska clearingu ta nejdůležitější - ještě se dělí na dobíjecí, vybíjecí a
nastavovací), hotovostní, slepá (nese informaci např. o stornované transakci) a informace
o vyčtení strojku; jedná se o preferovaný způsob dodávání dat, který navíc obsahuje další
poddruhy:
• s hotovostními podpoložkami – v tomto formátu jde zaslat i transakci s položkami,
které jsou karetní a hotovostní, např. odečtení peněz z elektronické peněženky,
zakoupení kupónu a jízda na kupón, případně jízda na kupón a doplatek v hotovosti,
nebo dokonce více karetních transakcí nad různými kartami, tato nejposlednější verze
je i připravena na předplacené položky (tzv. greenlist)
• s podpoložkami pouze na kartu – lze zaslat transakci reprezentující více operací nad
jednou kartou (např. odečtení peněz z elektronické peněženky a dobití kupónu), v
posledním vylepšení je také připravena na předplacené položky (tzv. greenlist)
• bez podpoložek - každá transakce může obsahovat pouze jedinou operaci právě nad
jednou aplikací (kontraktem), existuje z důvodů zpětné kompatibility
Vydání 3 Revize 17 Strana 10/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
• po odpočtech - jsou zasílány pouze karetní transakce (žádné hotovostní), které jsou
zařazeny do odpočtů, úplnost dat je kontrolována právě na úrovni odpočtů; tento způsob
dodávání dat je podporován už jen z důvodů zpětné kompatibility
O každé transakci je nutno předat informace nutné pro správné rozdělení peněz, což je
především na jakém zařízení, na jakou aplikaci či kontrakt byla transakce provedena, její typ
(dobíjecí, vybíjecí a nastavovací), v jakém objemu či sazbě DPH, případně v jakém stavu se
aplikace po provedení transakce nachází (zůstatek elektronické peněženky). Doplňkovými
vlastnostmi potřebnými pro rozdělení peněz jsou: tarif, typ osoby, seznam zón, zónová
relace, příznak jde-li o přestupní lístek, či dokonce odkaz na konkrétní jízdenku, ze které se
přestup realizuje.
Pro správné řazení transakcí a kontroly úplnosti dodaných dat je nutné předat pořadové číslo
transakce za zařízení, případně hodnoty počítadel transakcí za kartu, aplikaci či kontrakt,
jsou-li používány.
Dále je nutno předat informace nutné pro správné spárování transakce s konkrétní aplikací
(kontraktem), což je platnost u kupónů. Pro rozumné zrekonstruování neznámého
(nedorazilo vydání aplikace či kontraktu) kupónu může být požadována identifikace
vydavatele či dokonce cena kupónu.
V neposlední řadě se jedná o informace, které jsou primárně využívány především pro
vyhodnocování, tj. nástupní a výstupní zastávka, místo kontroly, linka, spoj a čas nástupu.
Řada atributů transakce může být v tomto dokumentu označena za nepovinnou, ale může
být vyžadována v závislosti na konkrétní implementaci (konkrétním systému clearingu).
Odpovědí na seznam transakcí (případně seznam odpočtů s transakcemi) je seznam dat,
která nám od strojku chybí, tj. intervaly dat (kde od a do je vždy pořadové číslo
transakce/odpočtu a datum).
Podrobnější popis zpráv najdete v kapitole 4.2.9.
4.2.1.8. Předplacené položky (greenlist)
Předplacené položky (tzv. greenlist) se používají v okamžiku, kdy si zákazník bez přítomnosti
karty dobije elektronickou peněženku, případně si zakoupí kupón. Následně si dobití (kupón)
nahraje na kartu v zařízení, které zná tzv. greenlist. Do clearingu je zasílán seznam položek,
které jsou identifikovány lokálním ID prodejce.
Odpovědí je potvrzení přijmutí položky spolu s vygenerovaným vzestupným pořadovým
číslem položky (toto číslo je unikátní v rámci jednoho vydavatele karet). Toto číslo slouží k
ochraně před opakovaným zapsáním položky na kartu různými zařízeními. Tj. při nahrání
položky na kartu se na kartu zapíše i ID položky a nelze již na kartu nahrát žádná položka s
číslem menším nebo rovným zapsané položce.
Podrobnější popis zpráv najdete v kapitole 4.2.10.
4.2.1.9. Lokální seznam předplacených položek
(greenlist)
Tento seznam předplacených položek slouží pro potřeby prodejce předplacených položek,
který položku vytvořil. Především může zjistit, které položky jsou již zákazníky vyzvednuty a
které ještě ne. Seznam obsahuje pouze položky vytvořené subjektem, který požadavek
zaslal.
Podrobnější popis zpráv najdete v kapitole 4.2.11.
4.2.1.10. Seznam předplacených položek (greenlist)
Tato operace slouží ke stažení greenlistu, který je následně nahrán do zařízení, jenž zapisují
položky na kartu. Odpovědí je seznam položek spolu s jejich unikátními čísly. Je zaručeno
systémem, že číslo je unikátní v rámci vydavatele karty.
Podrobnější popis zpráv najdete v kapitole 4.2.12.
Vydání 3 Revize 17 Strana 11/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.1.11. Změna lokálního seznamu zařízení
Posílané změny lokálního seznamu zařízení jsou seřazeny chronologicky s informací o čase,
kdy nastaly. Změnou chápeme aktivaci případně deaktivaci zařízení, což je uvedení zařízení
do provozu (užívání) případně jeho stažení z provozu.
Odpovědí je aktuální globální seznam zařízení.
Podrobnější popis zpráv najdete v kapitole 4.2.13.
4.2.1.12. Vytvoření přístupu vlastníka karty do systému
Na úrovni karty je možné vytvořit uživatele s uživatelským jménem (spíš se jedná o číslo
karty či podobný identifikátor než uživatelské jméno) a heslem, který má možnost přihlásit se
do systému a sledovat změny na své kartě. Zasláním zprávy, která pro každou kartu
obsahuje navíc požadované uživatelské jméno a email, je vytvořen nový uživatelský přístup
ke kartě, pokud již neexistuje. Zadání hesla a aktivace účtu je provedena pomocí předaného
emailu. Přístup může vytvořit pouze vydavatel karty.
Odpovědí je seznam požadavků spolu s příznakem, zda byl přístup vytvořen nebo nikoliv.
Nebyl-li vytvořen, je přidán i důvod, proč se vytvoření přístupu nezdařilo.
Podrobnější popis zpráv najdete v kapitole 4.2.14.
4.2.1.13. Informace o zůstatku aplikace (kontraktu)
elektronická peněženka
Dojde-li ke ztrátě karty a následné reklamaci, pak jediný způsob jak zjistit zůstatek na
elektronické peněžence je pomocí clearingového centra. A právě tomuto účelu slouží tato
zpráva. V požadavku je zaslána identifikace aplikace (či kontraktu).
V odpovědi jde spolu s identifikaci aplikace (či kontraktu) i její zůstatek a datum, ke kterému
je platný (zpracování v clearingovém systému je o n dní zpožděné, takže jde o datum, do
kdy je zpracováno). Zůstatek není sdělen v případě, že aplikaci (kontrakt) vydal jiný subjekt,
než který požadavek zaslal, případně nejedná-li se o typ elektronická peněženka.
Podrobnější popis zpráv najdete v kapitole 4.2.15.
4.2.1.14. Seznam návrhů na zablokování aplikací
(kontraktů)
Clearingové centrum provádí nejenom finanční zpracování došlých transakcí, ale i jejich
kontrolu z hlediska bezpečnosti systému. Pokud je detekováno podezřelé chování, pak je
vydavatelský subjekt informován o této skutečnosti v podobě seznamu návrhů na
zablokování. V požadavku je zaslán pouze datum a čas posledního již zpracovaného návrhu
na zablokování.
Odpověď obsahuje vždy datum a čas transakce, při jejímž zpracování bylo podezřelé
chování objeveno. Následuje identifikace aplikace (kontraktu) a slovní popis jaký typ
podezřelého chování byl odhalen.
Podrobnější popis zpráv najdete v kapitole 4.2.16.
4.2.1.15. Seznam subjektů clearingu
Odpovědí na prázdný požadavek je seznam všech subjektů clearingu. Každý subjekt je
identifikován pomocí jednoznačného provider-id, obsahuje jméno subjektu a příznak, zda
je aktivní.
Podrobnější popis zpráv najdete v kapitole 4.2.17.
4.2.1.16. Seznam akceptovatelných subjektů
Jedná se o jednu ze stěžejních zpráv celého clearingového systému, protože její obsah
informuje zařízení subjektu, čí karty (ve smyslu "kterým subjektem vydané") je možné
akceptovat a jaké operace je možné s aplikacemi (kontrakty), na kartě obsaženými,
provádět.
Odpověď může být zaslána v podobě podepsaného XML souboru, jenž je nutné na straně
dopravce dále zpracovat, nebo přímo ve formě binárního souboru, který se nahraje až do
zařízení. Takové zabezpečení je potřebné především z důvodu zabránění modifikace
obsahu souboru na straně subjektu a SVT doporučuje jeho využívání.
Vydání 3 Revize 17 Strana 12/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Odpověď tedy obsahuje seznam vydavatelů aplikací (kontraktů) a pro každý typ aplikace,
který má povolenou nějakou operaci, obsahuje příznaky, jaké operace je možné provádět s
jejich typy aplikací (kontraktů): dobíjet, akceptovat či nastavovat.
Je-li dodavatelem odbavovacího zařízení požadován speciální binární formát, pak tento je
popsán v samostatném dokumentu, jehož obsah tajný.
Podrobnější popis zpráv najdete v kapitole 4.2.18.
4.2.1.17. Globální seznam zablokovaných karet, aplikací
či kontraktů
Odpověď je zaslána na základě prázdného požadavku a obsahuje globální seznam
zakázaných karet, tak jak je popsán jako odpověď na lokální seznam zakázaných karet (viz
kapitola 4.2.1.5).
Podrobnější popis zpráv najdete v kapitole 4.2.19.
4.2.1.18. Chyba během zpracování
Jde o universální odpověď, která je zaslána v případě, že během zpracování jakékoliv zprávy
dojde k chybě, která zastaví zpracování následných souborů, ale ze které se systém dokáže
zotavit tak, že je schopen poslat odpověď uživateli standardní cestou. Obsahuje popis chyby,
a proč k ní došlo.
Podrobnější popis zpráv najdete v kapitole 4.2.20.
4.2.2. Popis obecných atributů
Řada zpráv obsahuje atributy, které jsou jim společné. Z tohoto důvodu jsou tyto atributy
popsány společně v této kapitole.
• card-id je číslo karty, která je kódováno hexadecimálně (např. 0000008A88FE00 nebo
001258FE)
• medium specifikuje typ karty, který umožňuje zpracovat karty s prolínajícími se číselnými
řadami (nebýt tohoto atributu systém by se domníval, že se jedná o jednu kartu a nikoliv o
2 se stejným číslem, ale různým typem media), možné hodnoty jsou:
• classic – (implicitní není-li atribut uveden) karta z řady Mifare Classic (ať 1k tak 4k) s
identifikátorem 4B dlouhým
• desfire – karta z řady Mifare DESFire s identifikátorem 7B dlouhým
• appl-id je číslo aplikace na kartě, číslo je zapsáno dekadicky bez znaménka, jeho
rozsah je 4B
• contract-id je číslo kontraktu v aplikaci typu MAD, tj. identifikuje např. konkrétní kupón
v aplikaci dopravní kupóny, číslo je zapsáno hexadecimálně, rozsah je 4B
• provider-id je identifikátor konkrétního subjektu, jedná se o decimální číslo v rozsahu 0-
65535
• network-id je identifikátor sítě (skupiny), skupinou se rozumí např. Středočeský kraj,
používá se především k dodatečné identifikaci karty, aby bylo zřejmé z jaké skupiny je její
vydavatel, či k identifikaci transakce, aby bylo zřejmé v jakém IDS byla jízdenka prodána.
Jedná se o řetězec ve formátu "XXX YYY", kde XXX identifikuje zemi a YYY sít v této
zemi, X a Y jsou dekadická čísla
• datum a čas je uváděn ve formátu YYYY-MM-DD HH:mm:SS (tj. 2008-12-23 08:05:32),
kde:
• YYYY je čtyřmístný rok
• MM je dvoumístný měsíc (1-12)
• DD je dvoumístný den (1-31)
• HH jsou dvoumístná hodiny (0-23)
• mm jsou dvoumístné minuty (0-59)
• SS jsou dvoumístné sekundy (0-59)
• ceny jsou kódovány jako desetinné číslo s desetinou tečkou (např. 100.5)
Vydání 3 Revize 17 Strana 13/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Vydání 3 Revize 17 Strana 14/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.3. Vydání aplikace na kartě
Tato informace je posílána jako seznam vydání:
Nejčastějším užitím je vydání aplikace (jakéhokoliv typu), který vypadá:
Zpráva obsahuje seznam aplikací s příznakem, zda byla akce úspěšná (rozlišeno názvem
tagu). Vydaná (aktivovaná) i nevydaná (neaktivovaná) aplikace obsahuje číslo karty v
atributu card-id a u obou obsahuje atribut appl-id s číslem aplikace (i v případě, že v
požadavku není uvedeno). Neaktivované aplikace obsahují atribut reason, který udává
důvod, proč nebyla aplikace aktivována. Dále obsahuje i platnost aplikace (atributy valid-
from a valid-to). Tyto atributy pomáhají jednoznačně identifikovat aplikace v případě, že je
vydáváno více aplikací se stejným číslem na jednu kartu.
Specifikace DTD viz kapitola 4.2.21.2.
4.2.4. Vydání kontraktu pro MAD aplikaci
Tato zpráva je obdobou vydání aplikace (viz kapitola 4.2.3) tentokrát pro kontrakty:
Každá aplikace, ve které je vydán kontrakt musí být typu mad. Novými atributy jsou
contract-id, který nese číslo kontraktu, a max-appl-tx-id nesoucí maximální hodnotu
čítače transakcí za aplikaci. Význam všech atributů je identický s významem u vydání
aplikace, pouze atribut max-tx-id signalizuje počítadlo transakcí za kontrakt nikoliv aplikaci
(o počítadlech transakcí viz následující odstavec). Povinnými atributy jsou card-id, medium,
appl-id, contract-id, valid-from (obdoba atributu when), valid-to, type a nepovinným
max-tx-id, max-appl-tx-id a max-card-tx-id.
Ze čtveřice atributů specifikujících číslování transakcí za kontrakt - max-tx-id (aplikaci -
max-appl-tx-id, kartu - max-card-tx-id či za kartu, ale pouze jízdy - max-riding-tx-id)
může být použit maximálně jeden. Tyto atributy jsou obdobou podobných atributů použitých
při vydání aplikace (viz kapitola 4.2.3). Je-li specifikován atribut max-tx-id, pak každý
kontrakt má vlastní počítadlo. Je-li použit atribut max-appl-tx-id, pak mají všechny
kontrakty v jedné aplikaci společné počítadlo. Je-li použit atribut max-card-tx-id, pak mají
všechny aplikace i kontrakty na kartě společné počítadlo. Je-li použit max-riding-tx-id,
Vydání 3 Revize 17 Strana 16/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
pak mají všechny aplikace i kontrakty společné počítadlo jízd. Není-li použit žádný, pak
žádné takové počítadlo kontrakt nemá.
Odpověď je opět obdobná jako v případě vydání aplikace, tj. obsahuje jednotlivé vydávané
kontrakty a u každého je příznak, zda se vydání zdařilo s případným popisem, proč se
vydání nepovedlo:
Význam všech tagů a atributů je zřejmý díky předchozímu textu.
Specifikace DTD viz kapitola 4.2.21.3.
4.2.5. Hromadné vydání aplikací na kartách
Jedná se o seznam vydání aplikací na kartách (vychází ze zprávy vydání aplikace - viz
kapitola 4.2.3):
Oproti vydání aplikace (viz kapitola 4.2.3) obsahuje bulk-card-issue nový povinný atribut
provider-id, který identifikuje subjekt, jenž je vydavatelem aplikace. Dalšími povinnými
atributy (známými z vydání aplikace) jsou card-id, medium, appl-id, type a valid-to.
Atribut valid-from obsahuje datum a čas vydání aplikace (obdoba atributu when při vydání
aplikace). Nepovinnými atributy (mají stejný význam jako v případě vydání aplikace) jsou:
max-tx-id, max-riding-tx-id a max-card-tx-id.
Vydání 3 Revize 17 Strana 17/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Jako odpověď je zasílán seznam aplikací, který obsahuje úspěšně vydané a nevydané
aplikace:
Význam jednotlivých tagů a atributů je zřejmý díky předchozím kapitolám.
Specifikace DTD viz kapitola 4.2.21.4.
4.2.6. Vydání karty
Pokud chcete využít vydání karty jiným subjektem, pak jej musíte poslat dřív než začnete
vydávat aplikace, tj. před soubory z kapitol 4.2.3 a 4.2.5. Informace je posílána jako seznam
vydání:
Každý tag medium-issue vydá jednu kartu. Význam a obsah atributů card-id a medium
(nepovinné) jsou zřejmé. Atribut provider-id specifikuje vydavatele karty a je povinný.
Jako odpověď je zasílán seznam jednotlivých úspěšně vydaných karet následovaný
seznamem neúspěšně vydaných karet:
Zpráva obsahuje seznam karet s příznakem, zda byla akce úspěšná (rozlišeno názvem
tagu). Vydaná (aktivovaná) i nevydaná (neaktivovaná) aplikace obsahuje číslo karty v
atributu card-id a typ media v atributu medium. Neaktivované karty obsahují atribut reason,
který udává důvod, proč nebyla aplikace aktivována.
Specifikace DTD viz kapitola 4.2.21.5.
Vydání 3 Revize 17 Strana 18/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.7. Lokálním seznam zakázaných karet, aplikací či
kontraktů
Lokální seznam zakázaných karet, aplikací či kontraktů je posílán jako seznam čísel karet
(volitelný je typ karty), případně včetně čísla aplikace či kontraktu:
Atribut card-id spolu s nepovinným atributem medium specifikuje kartu. Pokud není uveden
atribut appl-id, pak je blokována celá karta, je-li uveden atribut appl-id, pak je blokována
pouze uvedená aplikace. Je-li uveden i atribut contract-id pak je blokován pouze uvedený
kontrakt.
Odpovědí je globální seznam zakázaných karet, aplikací či kontraktů, který má podobný
obsah jako seznam lokální, navíc obsahuje datum a čas vložení karty, aplikace či kontraktu
na seznam zablokovaných a specifikaci skupiny, ve které byla karta vydána (primární
skupina vydavatele karty):
Atribut last-change říká, kdy se naposledy měnil globální seznam zakázaných karet,
aplikací či kontraktů, aby mohlo dojít k optimalizaci jeho zpracování a nahrávání do zařízení.
Pokud je uveden atribut ignore-not-used-for informuje o zapnutí volby neposílání
nepoužívaných karet, aplikací či kontraktů na seznam zakázaných karet a jeho hodnota
specifikuje, jak dlouho musí být karta nepoužívána, aby se na seznam zakázaných
nedostala (hodnota je specifikována jako interval dle ISO-8601). Podobně jako u lokálního
seznamu zakázaných karet, není-li uveden atribut appl-id je blokována celá karta, je-li
uveden atribut appl-id je blokována konkrétní aplikace, je-li uveden atribut appl-id i
contract-id pak je blokován konkrétní kontrakt. Atribut network-id specifikuje skupinu, ve
které byla karta, aplikace či kontrakt vydán.
Po globálním seznamu zakázaných karet následuje seznam karet, které se nepodařilo
zablokovat nebo odblokovat, tj. tag non-blacked-card je pro karty, aplikace či kontrakty,
které se nepodařilo zablokovat a non-unblacked-card je pro karty, aplikace či kontrakty,
které není možné odblokovat. Atributy card-id, medium, appl-id, contract-id a when mají
stejný význam jako v předešlých případech. Atribut reason obsahuje důvod, proč není
možné kartu, aplikaci či kontrakt zablokovat (odblokovat).
Specifikace DTD viz kapitola 4.2.21.6.
Vydání 3 Revize 17 Strana 19/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.7.1. Verze bez identifikace skupiny
Požadavek je stejný jako v případě verze 2.1, pouze je ve verzi 2.0.
Odpovědí je globální seznam zakázaných karet (aplikací), který je podobný jako v případě
verze 2.1 (neobsahuje atributy network-id a ignore-not-used-for):
Specifikace DTD viz kapitola 4.2.21.7.
4.2.8. Změna platnosti aplikace MAD nebo aplikace
(kontraktu) elektronická peněženka
Informace o změně platnosti elektronických peněženek a MAD aplikací je posílána jako
seznam aplikací (kontraktů) spolu s novou platností do:
Atribut card-id spolu s nepovinnými atributy medium, appl-id a contract-id specifikují
MAD aplikaci nebo elektronickou peněženku. Atribut valid-to nese novou platnost do
aplikace.
V odpovědi je seznam všech požadavků na změnu s identifikací, zda se změna zdařila (tag
changed-card-validity) nebo ne (tag not-changed-card-validity spolu s důvodem
neúspěchu v atributu reason):
Vydání 3 Revize 17 Strana 20/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
V odpovědi je aplikace na kartě specifikována podobně jako v požadavku, pouze atributy
medium a appl-id jsou uvedeny vždy.
Specifikace DTD viz kapitola 4.2.21.8.
4.2.9. Transakce za zařízení
Obsahem zprávy je seznam transakcí za jedno zařízení:
...
Uvnitř tagu transactions jsou chronologicky (jak šly za sebou podle času vzniku) umístěny
jednotlivé transakce (pokud budeme vyčtení zařízení považovat za transakci - tag read-
out). Zpráva vždy obsahuje data pouze za jedno zařízení, které je specifikováno atributem
device-id.
Speciální význam má atribut tx-id, který obsahuje číslo transakce. Z důvodů kontroly
úplnosti dodaných dat musí každá transakce (jak budou popsány dále) obsahovat unikátní
číslo a navíc čísla musí jít za sebou. Zaslány musí být všechny transakce, které mají
Vydání 3 Revize 17 Strana 21/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
přidělené číslo. Maximální hodnota čítače je definovány při aktivaci zařízení. Počítadlo musí
být dostatečně veliké, aby k jeho otočení nedošlo dříve jak za 10 dní.
Protože existuje hodně variant zasílání transakcí, pak si jednotlivé typy transakcí projdeme
detailně. Začneme tím nejjednodušším, informací o vyčtení zařízení:
V tomto případě je vytvořen kupón, který má 2 ceny (každá je rozdělována zvlášť), každá
může navíc mít definovánu dotaci. Typ osoby je identifikován z tarifu.
Příklad transakce jízdy na kupón vypadá:
Vydání 3 Revize 17 Strana 25/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Pokud je nutné k jedné transakci uvést více informací o linkách, zastávkách a tarifech, pak je
možné do tagu card-transaction či transaction vnořit tag add-data, který má jako
volitelné atributy: departure-id, arrival-id, line, sequence, tariff, tariff-km, info-
ids a network-id. Využití je v případě prodeje více obdobných jízdenek v jedné transakci
(např. skupina 5ti lidí) nebo v případě, kdy jeden dopravní prostředek jede po 2 linkách či
přejíždí mezi dvěma IDS. Protože zpracování vnořených tagů je pomalejší než zpracování
atributů, pak doporučujeme použít tag add-data skutečně pouze v případě, že je potřeba
poslat více než jeden add-data tag. Dále je vhodné atributy, které by měly stejnou hodnotu
u všech add-data tagů specifikovat u nadřazeného tagu (card-transaction).
Dalším rozšířením možností je multitransakce, která obsahuje více vnořených podtransakcí
(slouží pro případ, kdy je více operací provedeno v jednom kroku a má jedno tx-id):
Všechny atributy již známe z dřívějších popisů, a protože tato varianta je pouze kombinací
možností již dříve vysvětlených. Dokonce je analogie mezi transaction a sub-
transaction a podobně i card-transaction a card-sub-transaction. Tj. Tyto tagy
popisují vždy to samé, zapisuje se to stejně. Akorát sub-* tag použijeme uvnitř multi-
transaction a neuvádíme u něj atributy tx-id a when.
Pokud v jednom kroku prodáme kupón, zaplatíme jej z elektronické peněženky a ještě na něj
cestující rovnou pojede (vše se např. realizuje v autobuse), pak bude transakce vypadat jako
v našem příkladě. První je transakce odečtení peněz z elektronické peněženky, druhá je
transakce dobití kupónu a třetí je jeho použití. Druhým příkladem je jízda na kupón, který
ovšem neplatí po celé délce trasy a proto je cestující nucen doplatit:
K tagu multi-transaction se zapisují pouze atributy tx-id a when. Ostatní atributy
zůstávají u vnořených tagů.
Bude-li nutné k tagu *sub-transaction zapsat více skupin dopravních informací, pak je
jako v případě *transaction možno uvést vnořený tag add-data:
Doposud nezmíněnou sub-transakcí je dummy-sub-transaction. Její využití je především v
okamžiku, kdy je stornována multi-transaction, kde se operovalo s počítadly transakcí za
kartu (appl-tx-id) a takové sub-transakce byly minimálně 2. Pak tuto skutečnost nelze
Vydání 3 Revize 17 Strana 26/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
zapsat normální dummy-transaction. Pokud byla stornována transakce prodeje kupónu z
elektronické peněženky (první příklad na multi-transaction), pak ji zapíšeme:
Není nutné uvádět tam prostřední transakci prodeje kupónu, protože nezměnila hodnotu
žádného počítadla, kterou bychom již nedostali jinak.
Velkou skupinou transakcí jsou reklamační transakce (tag claim-transaction). Tato
skupina transakcí slouží obecně k reklamacím nad aplikacemi / kontrakty všech
podporovaných typů. Reklamační transakci může provést pouze vydavatel karty. Skupina
atributů je velmi podobná skupině atributů u tag card-transaction. Stejný význam mají
atributy tx-id a when, které identifikují transakci na zařízení. Aplikaci nebo kontrakt
identifikují atributy card-id, medium, appl-id, contract-id, valid-from, valid-to,
voucher-issuer a voucher-price. Nové jsou atributy, které identifikují cílovou aplikaci /
kontrakt (pokud se v rámci reklamace aplikace / kontrakt převádí na novou kartu): target-
card-id, target-medium, target-appl-id, target-contract-id, target-valid-from a
target-valid-to. Následují atributy, které již známe z tagu card-transaction a které slouží
k definování nových (po reklamaci) hodnot: amount, balance-after, tariff, zones, zone-
route a person-type. Pokud v rámci reklamace dochází ke změně hodnoty počítadla
transakcí za aplikaci / kontrakt (nezávisle na typu počítadle, které aplikace / kontrakt
používá) pak použijeme atributy appl-tx-id a target-appl-tx-id. Protože je atributů
hodně, způsobu použití ještě víc, ukážeme si nějaké příklady.
Nejjednodušší reklamační transakce popisuje nastavení zůstatku elektronické peněženky:
...
Odpověď v tagu processing-statistic obsahuje informaci o celkovém počtu
nahrávaných transakcí všech druhů (atribut total), kolik z nich bylo úspěšně zpracovaných
(atribut processed) a kolik z nich bylo ignorovaných (atribut ignored). V případě karetní
transakce s položkami jsou do počtů zahrnuty pouze položky (tag item), nikoliv transakce s
položkami jako taková. V žádné z hodnot těchto atributů nejsou zahrnuta dodatečná data
(tag add-data). Dále obsahuje seznam chybějících období specifikovaných tagem
missing-period. Období obsahuje první chybějící transakci (tag from) a poslední chybějící
transakci (tag to). Poslední období nemusí mít poslední chybějící transakci (většinou jej mít
nebude – tag to), pokud poslední transakce od daného zařízení nastala dříve, než je
aktuální datum a čas. Je-li zařízení deaktivováno, pak poslední období obsahuje tag to, ale
to může jako hodnotu atributu tx-id mít prázdný řetěz ("").
Diskontinuity se kontrolují na základě času aktivace a deaktivace zařízení (za tento časový
úsek jsou vyžadována data), na základě informací o vyčtení strojků, časů transakcí a
konečně na základě čísel transakcí, která musejí jít za sebou. Čítače transakcí v zařízeních
musí mít dostatečnou velikost, aby nedošlo k jejich otočení, tj. návratu na 0, během 10 dní.
Specifikace DTD viz kapitola 4.2.21.9.
Vydání 3 Revize 17 Strana 29/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.9.1. Transakce bez možnosti hotovostních položek a
s předplacenými položkami (greenlist)
Obsahem zprávy je seznam transakcí za jedno zařízení ve verzi 2.2. Obsah je stejný jako v
případě verze 3.0, akorát není podporován tag multi-transaction a místo něj existuje
card-transaction-with-itens:
Podstatným rozdílem verze 2.2 je tag card-transaction-with-items:
Všechny atributy již známe z dřívějších popisů, a protože tato varianta je pouze kombinací
možností již dříve vysvětlených nastíníme si pouze jak takovou transakci vytvořit. Pokud v
jednom kroku prodáme kupón, zaplatíme jej z elektronické peněženky a ještě na něj
cestující rovnou pojede (vše se např. realizuje v autobuse), pak bude transakce vypadat jako
Vydání 3 Revize 17 Strana 30/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
v našem příkladě. První je transakce odečtení peněz z elektronické peněženky, druhá je
transakce dobití kupónu a třetí je jeho použití.
K tagu card-transaction-with-items se zapisují pouze atributy tx-id, when, card-id,
medium a get-on-when. Ostatní atributy se přestěhovaly k tagu item a mají stejný význam a
používají se ve stejných případech (viz předcházející popis příkladů s použitím) jako u tagu
card-transaction.
Bude-li nutné k tagu item zapsat více skupin dopravních informací, pak je jako v případě
card-transaction možno úvést vnořený tag add-data:
-
...
Odpověď je obsahově i významově identická s verzí 3.0. Specifikace DTD viz kapitola
4.2.21.10.
Vydání 3 Revize 17 Strana 31/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.9.2. Transakce bez možnosti hotovostních položek
Obsahem zprávy je seznam transakcí za jedno zařízení ve verzi 2.1. Obsah je stejný jako v
případě verze 2.2, akorát nejsou podporovány transakce, kde atribut type má hodnotu
greenlist nebo greenlist-refund, a claim-transaction, kde je uveden atribut
greenlist-id:
Další změnou oproti verzi 2.2 je využití claim-transaction k vyplacení zůstatku
elektronické peněženky a její zrušení (zkrácení platnosti). Protože obecně platí pravidlo, že
claim-transaction se nezúčtovávají, pak zpětné vyplacení peněz nemá být claim-
transaction. Verze 2.1 to tak ovšem má:
...
Odpověď je obsahově i významově identická s verzí 2.2. Specifikace DTD viz kapitola
4.2.21.11.
4.2.9.3. Transakce bez možnosti uvedení položek
Tato zpráva je identická se zprávou ve verzi 2.1, ale nepodporuje tag card-transaction-
with-items:
Význam všeho je identický s popisem zprávy ve verzi 2.1. Tato zpráva je dopředu
kompatibilní, tj. platná zpráva verze 2.0 může být zaslána jako verze 2.1. až na hodnotu
atributu reset, která je ve verzi 2.1 nahrazena tagem claim-transact.
Odpovědí na zaslání transakcí je seznam chybějících transakcí, který je opět identický s
odpovědí ve verzi 2.1 pouze s rozdílně uvedenou verzí (2.0).
Specifikace DTD viz kapitola 4.2.21.12.
4.2.9.4. Verze nadále pracující s odpočty
Z důvodů větší zpětné kompatibility s verzí 1.X existuje i nadále podporované zasílání dat po
odpočtech. Význam tagů card-transaction a transaction a jejich atributů je identický
jako v předchozích kapitolách jenom jsou zanořeny do tagu login, který definuje pořadové
číslo odpočtu (význam je obdobný jako v případě atributu tx-id), od kdy do kdy odpočet
trval a kolik obsahuje transakcí. V případě posílání dat po odpočtech není vyžadována
unikátnost atributu tx-id:
Vydání 3 Revize 17 Strana 33/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
...
...
Tagy popisující transakce zůstaly stejné. Tag login obsahuje povinné atributy id (číslo
odpočtu – používá se ke kontrole úplnosti dat), from (datum a čas začátku odpočtu), to
(datum a čas konce odpočtu). Dalšími povinnými atributy jsou pay-tx-count, deposit-tx-
count a reset-tx-count, které specifikují počet transakcí (vybíjecích, dobíjecích a
resetovacích) v daném odpočtu. Obsahuje-li odpočet transakce, které nejsou karetní (tzv.
tag transaction, které obsahují doplňující informace o spojích apod.), pak se přičítají k
vybíjecím transakcím. Tyto sumární počty slouží pro křížovou kontrolu obsahu odpočtu.
Vydání 3 Revize 17 Strana 34/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Odpověď obsahuje chybějící data (jako v případě verze 2.1), ale po odpočtech:
...
Význam všech atributů je stejný jako ve verzi 2.1 akorát hodnoty atributů tagu
processing-statistic zahrnují pouze počet odpočtů (tag login). Dále místo atributu
tx-id specifikující číslo transakce v chybějících datech je použit atribut login-id
specifikující číslo odpočtu.
Diskontinuity se v případě odpočtů kontrolují podobně jako v případě jednotné číselné řady
transakcí (použití atributu tx-id), s tím rozdílem, že čítač odpočtů musí „vydržet" po dobu 30
dní (ne 10 jako v případě čítače transakcí).
Specifikace DTD viz kapitola 4.2.21.13.
4.2.10. Předplacené položky (greenlist)
Předplacené položky (položky greenlistu) vznikají prodejem v nějakém externím programu,
který nemá fyzický přístup ke kartě. De facto položka greenlistu je předpis, jakou transakci
na kartě provést. Jedná se o běžnou transakci, která nemá vyplněná ty atributy, které jsou
závislé na stavu karty. Při dobití peněženky se jedná o zůstatek pěněženky po dobití, při
prodeji kupónu o jeho kontrakt, případně přesnou platnost.
Externí aplikace posílá clearingu předplacené položky v následujícím formátu:
Každá položka reprezentuje dobití elektronické peněženky a nebo prodej kupónu. Všechny
položky obsahují atribut identifikující okamžik, kdy položka vznikla a kartu (card-id, medium,
appl-id a when). V případě dobití elektronické peněženky obsahuje položka standardní
atribut nesoucí informaci o objemu dobitých peněz (amount). V případě prodeje kupónu
položka obsahuje více atributů (amount je cena kupónu, tariff, valid-from, valid-to
obsahují platnost kupónu) a informaci o zónách (jeden z atributů zones, zone-route,
zones-interval). Dále oba typy položek obsahují item-id, což je identifikátor položky
generovaný externím programem. Clearing nijak nezpracovává toto číslo, pouze očekává, že
dvojice item-id a when je unikátní. To slouží k případnému dohledání položky a k
identifikaci řádku v odpovědi (obsahuje řádky odpovídající požadavku):
Vydání 3 Revize 17 Strana 35/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
V požadavku je specifikováno, kterých položek se požadavek týká.
Odpověď je velmi jednoduchá, obsahuje pro každou položku informaci, zda už je
zákazníkem nahrána na kartu (tag deployed-item, kdy se tak stalo je v atributu deployed-
when), zda položka stále čeká na nahrání (tag stored-item) nebo jí clearingové centrum
nezná (tag no-item). Každá položka obsahuje lokální identifikátor, čas prodeje a s výjimkou
neznámých položek identifikátor generovaný clearingovým centrem (odpověď obsahuje
pouze položky zaslané subjektem, který žádá o status položek greenlistu):
Specifikace DTD viz kapitola 4.2.21.15.
4.2.12. Seznam předplacených položek (greenlist)
Následujícím krokem po vytvoření předplacených položek, je jejich zaslání operátorovi (např.
dopravce), který realizuje jejich zápis na karty (jsou zasílány položky, které nebyly zatím
uloženy na kartu). Požadavek o zaslání je velmi jednoduchý:
Výpis položek je identický jako v případě jejich zaslání z externího programu (viz. kapitola
4.2.10), pouze místo item-id obsahují vygenerované greenlist-id. Pozor, tento
identifikátor je unikátní za vydavatele karet, takže v takto zaslaném seznamu unikátní být
nemusí.
Specifikace DTD viz kapitola 4.2.21.16.
4.2.13. Změna lokálního seznamu zařízení
Požadavkem je změna lokálního seznamu zakázaných zařízení. Jednotlivé změny jsou
reprezentovány aktivací a deaktivací zařízení a musí být seřazeny chronologicky. Každá
změna je reprezentována číslem zařízení, informací, zda se zařízení stává aktivním či nikoliv
a datem a časem, kdy změna nastala:
Atribut device-id je číslo zařízení, result říká co se se zařízením dělo (mohlo být
aktivováno – activated nebo deaktivováno – deactivated) a poslední povinný atribut
(when) říká, kdy tato změna nastala. Atribut max-tx-id (případně max-login-id) je
požadován pouze v případě aktivace zařízení a jeho hodnota říká maximální hodnotu čítače
transakcí (odpočtů) na zařízení (má stejný význam jako tentýž atribut u vydání aplikace, tj.
má-li hodnotu 65536, pak čítač může nabývat hodnot 0 až 65535). Zařízení buď používá
čítač transakcí nebo čítač odpočtů, nikdy ne oba najednou. Pokud je přítomen atribut tx-id
nebo max-tx-id, pak používá čítač transakcí (transakce musí být zasílány ve verzi 2.0 a
vyšší), jinak čítač odpočtů (transakce musí být zasílány ve verzi 1.9). Nepovinný atribut tx-
id (login-id) říká jaká je poslední transakce (odpočet) zařízení (v případě deaktivace) či
jaká je první transakce (odpočet) zařízení (v případě aktivace). Není-li atribut uveden, pak si
systém domýšlí hodnotu o jednu větší, než která byla použita při předcházející deaktivaci
(jde-li o první aktivaci pak „0"), v případě aktivace a prázdnou (neznámou) hodnotu v případě
deaktivace. Při aktivaci zařízení může mít atribut tx-id (login-id) jinou hodnotu než „0"
pouze v případě jedná-li se o první aktivaci zařízení v systému (jinak jeho uvedení je
identické s jeho neuvedením).
Vydání 3 Revize 17 Strana 37/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Odpovědí je lokální seznam zařízení a seznam neprovedených aktivací/deaktivací:
Jednotlivá aktivní zařízení subjektu jsou reprezentován tagem active-local-device. Za
nimi následují chybné aktivace/deaktivace, jméno tagu specifikuje, zda se jednalo o
nepovedenou aktivaci (not-activated) či deaktivaci (not-deactivated), atributy device-
id a when specifikují o jakou změnu se jedná a atribut reason říká, jaký nastal problém.
Specifikace DTD viz kapitola 4.2.21.17.
4.2.14. Vytvoření přístupu vlastníka karty do systému
Tato informace je posílána jako seznam karet spolu s uživatelským jménem a e-mailem
vlastníka karty přistupujícímu k webovému rozhraní:
Z ukázky je jasné, že co přístup to tag create-card-login, který obsahuje povinné atributy
card-id, medium, user-id (uživatelské jméno pro přihlášení - musí být minimálně 3 znaky
dlouhé) a e-mail (pomocí tohoto e-mailu proběhne aktivace účtu).
Odpovědí je seznam přihlášení, který je informuje o úspěšně vytvořených a nevytvořených:
Zpráva obsahuje seznam vytvořených/nevytvořených přihlášení, obě obsahují identifikaci
karty pomocí atributů card-id a medium. Nevytvořená přihlášení obsahují atribut reason,
který udává důvod, proč nebylo přihlášení vytvořeno.
Specifikace DTD viz kapitola 4.2.21.18.
Vydání 3 Revize 17 Strana 38/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.15. Informace o zůstatku aplikace (kontraktu)
elektronická peněženka
Tato zpráva požaduje po clearingovém centru zaslání zůstatku aplikace (kontraktu)
elektronická peněženka:
Je možné požadovat zůstatek od více aplikací (kontraktů).
Jako odpověď je zaslán zůstatek všech aplikací, které byly v požadavku a jejichž zůstatek je
k dispozici, a seznam všech aplikací, jejichž zůstatek nemůže být poslán, spolu s důvodem,
proč nelze zůstatek poslat:
Celkový zůstatek aplikace je v hodnotě atributu balance. Navíc, je-li kontrakt, aplikace či
karta na globálním seznamu zakázaných, pak je tato skutečnost signalizována přítomností
atributu is-black-from, jehož hodnota sděluje od kdy je zakázána. Seznam aplikací
(kontrakt), pro které není možné poslat zůstatek, obsahuje kartu (atribut card-id), typ karty
(atribut medium), číslo aplikace (atribut appl-id), případně číslo kontraktu (atribut
contract-id) a důvod (atribut reason), proč není možné poslat zůstatek. Nezanedbatelná
je informace, do kdy jsou zpracovány transakce (tag processed-till), který říká k jakému
datumu jsou platné zůstatky.
Specifikace DTD viz kapitola 4.2.21.19.
4.2.16. Seznam návrhů na zablokování aplikací
(kontraktů)
Vydavatel aplikace si může vyžádat zaslání seznamu, kde může specifikovat, jaký návrh
(lépe řečeno, kdy nastala ona poslední podezřelá transakce) naposledy obdržel (atribut
last-suggestion):
Atributy card-id, medium specifikují kartu, atribut appl-id specifikuje aplikaci, případně
atribut contract-id specifikuje kontrakt, který je navrhována na zablokování. Atribut when
říká datum a čas transakce, která je podezřelá a je kvůli ní aplikace navržena na
zablokování. Posledním je reason, který obsahuje důvod návrhu na zablokování aplikace na
kartě.
Specifikace DTD viz kapitola 4.2.21.20.
4.2.17. Seznam subjektů clearingu
Na požádání je systém schopen zaslat aktuální seznam subjektů clearingu:
Pro každý subjekt je specifikován jeho identifikátor (atribut provider-id), jeho jméno
(atribut name) a příznak, zda je aktivní (atribut active="yes") nebo ne (atribut
active="no").
Specifikace DTD viz kapitola 4.2.21.21.
4.2.18. Seznam akceptovatelných subjektů
Požadavek pro zaslání seznamu akceptovatelných subjektů je velmi jednoduchý:
Atribut last-change obsahuje otisk (časovou známku), podle které je možné identifikovat,
zda se obsah souboru změnil. Pokud je hodnota tohoto atributu shodná s posledním
zaslanou hodnotou, pak se obsah souboru nezměnil.
Pro každý subjekt, s jehož kartami může adresát odpovědi provádět alespoň nějakou
operaci, je uveden v seznamu. Subjekt je identifikován pomocí atributu provider-id. Atribut
rights obsahuje popis práv na operace nad kartou. Hodnota atributu je formátovaný
řetězec, který obsahuje jednotlivé typy karet (viz kapitola 4.2.3 - kromě typu mad) a za
dvojtečkou definici práv: A - akceptovat pro placení (u kupónu použití), D - dobití (u kupónu
vystavení nového). Mezi jednotlivými typy aplikací (kontraktů) s právy je mezera.
V případě, že je odpovědí chyba, pak je vždy posílána standardní XML chybová zpráva viz
kapitola 4.2.20.
Specifikace DTD viz kapitola 4.2.21.22.
4.2.19. Globální seznam zakázaných karet, aplikací či
kontraktů
Na vyžádání systém zašle globální seznam zakázaných karet:
Těchto chyb může být v dokumentu více. Atribut when specifikuje, kdy byl přijat požadavek
na zpracování, message obsahuje textový popis chyby a konečně type identifikuje přesně
typ vzniklé chyby (není příliš zajímavý pro koncového uživatele, ale pro případné dohledání
bližšího popisu na serveru). Chyba je uložena v souboru, jehož jméno je dáno jmennou
konvencí specifikovanou v kapitole 4.1.3 a je možné tudíž zjistit, u kterého souboru chyba
nastala.
Specifikace DTD viz kapitola 4.2.21.24.
4.2.21. DTD jednotlivých zpráv
V této kapitole jsou uvedeny DTD všech výše zmiňovaných zpráv.
4.2.21.1. DTD seznamu zpracovávaných souborů
Požadavek:
Odpověď:
4.2.21.2. DTD vydání aplikace na kartě
Požadavek:
Vydání 3 Revize 17 Strana 42/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Odpověď:
4.2.21.3. DTD vydání kontraktu pro MAD aplikaci
Požadavek:
Odpověď:
4.2.21.4. DTD hromadného vydání aplikací na kartách
Požadavek:
Vydání 3 Revize 17 Strana 43/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Odpověď:
4.2.21.5. DTD vydání karty
Požadavek:
Odpověď:
4.2.21.6. DTD lokálního seznamu zakázaných karet,
aplikací či kontraktů
Požadavek:
Odpověď:
Vydání 3 Revize 17 Strana 44/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.21.7. DTD lokálního seznamu zakázaných karet,
aplikací či kontraktů bez identifikace skupiny
Požadavek:
Odpověď:
4.2.21.8. DTD změny platnosti aplikace MAD nebo
aplikace (kontraktu) elektronická peněženka
Požadavek:
Odpověď:
Vydání 3 Revize 17 Strana 45/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.21.9. DTD transakcí za zařízení
Požadavek:
Vydání 3 Revize 17 Strana 46/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Vydání 3 Revize 17 Strana 47/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Odpověď:
4.2.21.10. DTD transakcí bez možnosti hotovostních
položek a s předplacenými položkami
(greenlist)
Vydání 3 Revize 17 Strana 48/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Vydání 3 Revize 17 Strana 49/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Vydání 3 Revize 17 Strana 50/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Odpověď:
4.2.21.11. DTD transakcí bez možnosti hotovostních
položek
Vydání 3 Revize 17 Strana 51/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Vydání 3 Revize 17 Strana 52/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Odpověď:
4.2.21.12. DTD transakcí za zařízení bez podpoložek
Požadavek:
Vydání 3 Revize 17 Strana 53/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.21.13. DTD transakcí za zařízení po odpočtech
Požadavek:
Vydání 3 Revize 17 Strana 54/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Odpověď:
4.2.21.14. DTD předplacených položek (greenlist)
Požadavek:
Odpověď:
Vydání 3 Revize 17 Strana 55/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.21.15. DTD lokálního seznamu předplacených položek
(greenlist)
Požadavek:
Odpověď:
4.2.21.16. DTD seznamu předplacených položek
(greenlist)
Požadavek:
Odpověď:
4.2.21.17. DTD změny lokálního seznamu zařízení
Požadavek:
Odpověď:
Vydání 3 Revize 17 Strana 56/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.21.18. DTD vytvoření přístupu vlastníka karty do
systému
Požadavek:
Odpověď:
4.2.21.19. DTD informace o zůstatku aplikace (kontraktu)
elektronická peněženka
Požadavek:
Odpověď:
Vydání 3 Revize 17 Strana 57/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.2.21.20. DTD seznamu návrhů na zablokování aplikací
(kontraktů)
Požadavek:
Odpověď:
4.2.21.21. DTD seznamu subjektů clearingu
Požadavek:
Odpověď:
4.2.21.22. DTD seznam akceptovatelných subjektů
Požadavek:
Vydání 3 Revize 17 Strana 58/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Odpověď:
4.2.21.23. DTD globálního seznamu zakázaných karet
Požadavek:
4.2.21.24. DTD chyby během zpracování
Odpověď:
Vydání 3 Revize 17 Strana 59/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.3. Servisní rozhraní mezi subjekty a clearingovým
centrem
Servisní rozhraní obsahuje zprávy, které nejsou určeny pro rutinní provoz, ale jsou určeny
především pro správnou inicializaci prostředí (např. karet a aplikací na nich), případně pro
jiné ne zcela rutinní zásahy. Tyto zprávy jsou odesílány standardním způsobem jako každá
jiná zpráva, ale mají pár specifik:
• umožňují specifikaci subjektu (zpravidla atribut subject-id), kterého se týkají, tj. nemusí
souhlasit se subjektem uživatele, který je odešle (tento atribut může po exportu zůstat
prázdný a bude doplněn ručně před odesláním)
• vyžadují výrazně vyšší práva
Struktura této kapitoly je stejná jako v případě kapitoly 4.2.
4.3.1. Operace na rozhraní
V následujících kapitolách je popis jednotlivých zpráv rozhraní.
4.3.1.1. Inicializace aplikace (kontraktu) elektronická
peněženka
Při spuštění clearingového systému mohou být aplikace (kontrakty) elektronická peněženka
spuštěny ve třech různých režimech: všechny mají zůstatek 0, všechny mají nastaven
neznámý zůstatek (ten se inicializuje z první zpracované transakce) a nebo mohou být
zůstatky inicializovány (za tímto účelem existuje tato zpráva).
Požadavkem je seznam aplikací (kontraktů) elektronická peněženka spolu se zůstatkem,
který jim má být nastaven. Zůstatek může být nastaven pouze elektronické peněžence, která
má nenastavený zůstatek a nebo zůstatek roven 0 a navíc je vydána subjektem
specifikovaným v hlavičce souboru.
Hlavička zprávy obsahuje specifikaci data, ke kterému jsou zůstatky platné, spolu se
specifikací subjektu (který je doplněn až provozovatelem systému). Tato zpráva není
nahratelná přímo do clearingového systému, ale musí být jinou cestou doručena
provozovateli.
Jako odpověď je zasílán seznam aplikací (kontraktů) elektronická peněženka, které byly
akceptovány a těch, které akceptovány nebyly spolu s důvodem k odmítnutí nastavení
zůstatku.
Podrobnější popis zpráv nejdete v kapitole 4.3.2.
4.3.1.2. Inicializace aplikace (kontraktu) časový kupón
Poněkud složitější problém je s kupóny, pokud jsou tyto používány už před spuštěním
clearingu. Jde o to, že rozdělení peněz za kupóny je založeno na použití kupónu. Pokud by
nebyl inicializován kupón, který byl před spuštěním používán, pak jeho vydavatel (jediný
subjekt, který jej před spuštěním clearingu mohl používat) přijde o podíl z ceny za toto
používání.
Inicializace aplikací (kontraktů) časový kupón je složitější v několika aspektech:
• inicializace je komplikovaná v tom, že je nutno dohledat všechny transakce použití
kupónu a pro ně určit hodnotu atribut amount (viz popis transakce použití kupónu v
kapitole 4.2.9 na straně 24), návazně je suma těchto hodnot zaslána jako inicializační
hodnota
• pro každý kupón je uvedena i specifikace dobití, tj. cena, sazba DPH a typ osoby (pro
určení dotace)
• je nutné inicializovat i kupón, který je platný po okamžiku, ke kterému je inicializace
prováděna, ale byl vydán před tímto okamžikem (u takového kupónu je uvedena
inicializaci na 0, ale je nutno uvést specifikaci dobití)
• díky předchozímu bodu mohou být v souboru dva časové kupóny se stejnou identifikací
(karta, aplikace, případně kontrakt), proto může být složitější aplikaci (kontrakt) časový
kupón identifikovat, je nutné nejen specifikovat aplikaci (kupón), ale je nutno zadat i její
platnost
Vydání 3 Revize 17 Strana 60/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Podobně jako inicializace peněženek (viz kapitola 4.3.1.1) je nutné v záhlaví specifikovat
subjekt a datum a čas platnosti inicializovaných hodnot. Proto tato zpráva nejde nahrát do
clearingu a musí se nejprve zaslat provozovateli systému, který ji doplní a nahraje. Časový
kupón lze inicializovat pouze v případě , kdy vydavatelem je subjekt specifikovaný v hlavičce
a kupón zatím nebyl inicializován (nemá nastavenu cenu ani nebylo zaznamenáno žádné
použití – tj. zpracována žádná transakce).
Odpovědí je opět seznam aplikací (kontraktů) časový kupón, které byly akceptovány a těch,
které akceptovány nebyly spolu s důvodem k odmítnutí nastavení zůstatku.
Podrobnější popis zpráv nejdete v kapitole 4.3.3.
4.3.2. Inicializace aplikace (kontraktu) elektronická
peněženka
Požadavkem je zpráva obsahující seznam zůstatků aplikací elektronická peněženka:
Pro identifikaci elektronické peněženky jsou použity známé atributy card-id, medium, appl-
id, případně contract-id. Zůstatek je specifikován atributem balance.
Atributem celého souboru je when, který obsahuje datum a čas, ke kterému jsou zůstatky
platné. Komplikací je atribut subject-id, který je právě oním, jenž je doplněn až
provozovatelem systému a proto není nutno se jím zabývat
Odpovědí je seznam úspěšných a neúspěšných nastavení (spolu s důvodem neúspěchu):
Zpráva obsahuje seznam inicializovaných (tag initialized-ewallet) a neinicializovaných
(tag not-initialized-ewallet) aplikací (kontraktů). Oba tagy obsahují číslo karty (atribut
card-id), typ karty (atribut medium), číslo aplikace (atribut appl-id) a případně kontrakt
(atribut contract-id). Neinicializované aplikace (kontrakty) obsahují atribut reason, který
udává důvod, proč nebyla aplikace inicializována.
Specifikace DTD viz kapitola 4.3.4.1.
Vydání 3 Revize 17 Strana 61/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.3.3. Inicializace aplikace (kontraktu) časový kupón
Zprava obsahuje časové kupóny spolu s objemem projetých peněz a specifikaci :
Zpráva obsahuje seznam inicializovaných (tag initialized-voucher) a neinicializovaných
(tag not-initialized-voucher) aplikací (kupónů). Oba tagy obsahují číslo karty (atribut
card-id), typ karty (atribut medium), číslo aplikace (atribut appl-id), případně číslo
kontraktu (atribut contract-id) a platnost kupónu (atributy valid-from a valid-to).
Neinicializované časové kupóny obsahují atribut reason, který udává důvod, proč nebyla
inicializace provedena.
Specifikace DTD viz kapitola 4.3.4.2.
Vydání 3 Revize 17 Strana 62/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
4.3.4. DTD jednotlivých zpráv
V této kapitole jsou uvedeny DTD všech výše zmiňovaných zpráv.
4.3.4.1. DTD inicializace aplikace (kontraktu)
elektronická peněženka
Požadavek
Odpověď:
4.3.4.2. DTD inicializace aplikace (kontraktu) časový
kupón
Požadavek:
Vydání 3 Revize 17 Strana 63/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Odpověď:
4.4. Jak převést data
V této kapitole si popíšeme co od dat očekává clearingové centrum CARDS EXCHANGE a
jak skutečná data dopravce vyexportovat, aby byla z pohledu clearingu CARDS
akceptovatelná a správná.
Na úvod je nutné si uvědomit, že datový model clearingu CARDS je stavový, takže není
např. možné nahrávat transakce, pokud neexistuje zařízení. Tato skutečnost komplikuje
testování, protože pro testování je vždy potřeba připravit prostředí.
Pro clearingový systém jsou zajímavé účetní jednotky na kartě (elektronická peněženka,
kupón, jízdenka), které se nějakým způsobem rozúčtovávají. Clearingové centrum na ně
pohlíží jako na samostatné části, které jsou umístěné na jedné kartě. Tj. pokud nějaká
transakce operuje nad více těmito jednotkami najednou, pak clearingové centrum vyžaduje
tuto transakci "rozepsat" do více tak, aby symbolizovaly operace nad každou takovou
jednotkou zvlášť.
V této kapitole se pokusíme postupovat podle jednotlivých operací reálného života (např.
prodej kupónu v předprodeji, zakoupení jízdenky v autobuse) a naznačit jakým způsobem by
se provedl export do XML zpráv.
4.4.1. Vydání karty
Akt vydání karty je většinou spojen s inicializací (prvotním nahráním obsahu na kartu). Na
kartu může být nahrána peněženka s nulovým zůstatkem, případně nahrány MAD aplikace.
Z hlediska clearingového systému se nevydávají karty, ale až konkrétní aplikace / kontrakty.
Většinou je přímo s vydáním karty spojen i akt nahrání některých aplikací.
Formát podporuje ve svém důsledku 2 možnosti vydání karty: (a) každý subjekt si vydává
karty sám nebo (b) je použito centrální vydávání.
Pokud jde o případ (a) pak je použita zpráva vydání aplikace na kartě z kapitoly 4.2.3, kde
každý tag card-issue reprezentuje vydání jedné aplikace. Touto zprávou není možné vydat
kontrakt a vydavatelem karty a aplikací na ní je subjekt, který zprávu zaslal.
...
Pokud se inicializace provádí centrálně, pak je pro systém vydavatelem jeden subjekt a
máme opět případ (a). Pokud je centrální vydávání karet, ale vydavatelé z hlediska
clearingového systému (někdy se též používá termín kmenoví dopravci) jsou různé subjekty,
jde o případ (b). Pak je nutné použít zprávu hromadné vydání aplikací na kartách z kapitoly
4.2.5, kde každý tag bulk-card-issue reprezentuje vydání aplikace a vydavatelem karty a
aplikace na ní je subjekt specifikovaný v atributu provider-id. Ani touto zprávou není
možné vydat kontrakt.
Vydání 3 Revize 17 Strana 64/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
...
4.4.2. Dobití peněženky
Pokud je peněženka vydána (viz. předchozí kapitola), pak její zůstatek je nastaven na 0.
Není-li tomu tak, protože karty s elektronickými peněženkami jsou v oběhu již před
spuštěním clearingu, pak existují dvě varianty, jak jim nastavit správný zůstatek: nastavení
zůstatku z první došlé transakce a nebo inicializace (viz. zpráva inicializace aplikace
(kontraktu) elektronická peněženka v kapitole 4.3.2).
Dobití elektronické peněženky (tj. navýšení zůstatku) je realizováno transakcí (viz. kapitola
4.2.9):
...
4.4.3. Reklamace elektronické peněženky
Dojde-li k reklamaci zůstatku elektronické peněženky zákazníkem a tento zůstatek je
změněn, pak zde máme speciální typ transakce (popis viz. kapitola 4.2.9), která nastaví
zůstatek elektronické peněženky a zamezí kontrole návaznosti zůstatku proti předchozí
transakci (stejné pro verzi 2.1 i 2.2):
...
Stejné řešení v případě verze 2.0:
...
4.4.4. Jízda na elektronickou peněženku
Jízda placená elektronickou peněženkou je variace na dané téma (opět blíže v kapitole
transakce za zřízení 4.2.9):
...
U transakce jízdy (ale nejenom u jízdy na elektronickou peněženku, ale i u jízdy na kupón)
mohou být vyžadovány dopravní informace, kterými jsou výstupní/nástupní zastávka, linka,
spoj, tarif atd (blíže viz. kapitola 4.2.9).
4.4.5. Vrácení elektronických peněz
Tato transakce je identická s předchozí transakcí (tj. jízdou), ale je rozdílná pokud jako její
součást má být elektronická peněženka vrácena a již dále nepoužívána (dále viz. kapitola
4.2.9):
...
Vydání 3 Revize 17 Strana 65/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Ve verzi 2.1 je nutné použít claim-transaction:
...
Ve verzi 2.0:
...
4.4.6. Prodej nového případně prodloužení existujícího
kupónu – hotovostní platba
Tyto dvě operace jsou z pohledu clearingu CARDS totéž. Proč? Kupón má platnost od a do.
Na konci platnosti je podle pravidel rozúčtování rozdělena cena kupónu. Pokud je kupón za
cenu X prodloužen o Y dní, pak z pohledu clearingu CARDS se jedná o vydání nového
kupónu s cenou X a platností Y dní od konce platnosti kupónu prodlužovaného. V případě,
že nový kupón bude mít stejné číslo jako kupón předcházející (jde-li o aplikaci pak číslo je v
atributu appl-id, jde-li o kontrakt, pak v contract-id), platnost tohoto druhého kupónu
musí začínat minimálně o sekundu později než končí platnost kupónu předcházejícího.
Navíc se situace komplikuje tím, že z pohledu prodeje kupónu v předprodeji se jedná o jednu
operaci, z pohledu clearingu CARDS se jedná o záznamy na dvou místech, protože je
nejprve nutné kupón vydat a pak poslat dobíjecí transakci, která mu nastaví cenu, sazbu
DPH apod. Pokud je kupón vydán v autobuse, pak se dokonce může jednat až o 3 operace,
protože je na něj okamžitě uskutečněna i jízda, což je pro clearing CARDS třetí operace.
Nejprve si povíme jak kupón vydat a pak teprve si předvedeme ukázku transakcí.
Kupón je reprezentován buď aplikací a nebo kontraktem. Pokud je reprezentován aplikací,
pak k jeho vydání (informování clearingu o jeho existenci) může dojít pomocí 2 zpráv: (a)
pokud je zpráva posílána subjektem, který kupón prodal a nebo (b) jiným subjektem
(centrálním) - např. je-li při centrálním vydáním karty na kartu nahrán i kupón (třeba promo
akce).
V případě (a) se použije zpráva vydání aplikace na kartě z kapitoly 4.2.3, kde každý tag
card-issue reprezentuje vydání jednoho kupónu:
...
Pro případ (b) se použije zpráva hromadné vydání aplikací na kartách z kapitoly 4.2.5, kde
každý tag bulk-card-issue reprezentuje jeden kupón (vydavatel kupónu je reprezentován
atribut provider-id):
...
V případě, že je kupón reprezentován kontraktem, pak k jeho vydání vždy slouží zpráva
vydání kontraktu pro MAD aplikaci z kapitoly 4.2.4, kde každý kupón je reprezentován tagem
contract-issue (není tedy možné vydat kupón jako kontrakt centrálně):
...
V tomto případě musí již na kartě existovat aplikace typu mad, ve které bude kontrakt kupón
umístěn.
Vydání 3 Revize 17 Strana 66/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
A jak exportovat transakce spojené s prodejem či prodloužením kupónu? Opět máme dvě
varianty: (c) prodej v předprodeji (tj. bez okamžité jízdy na kupón) nebo (d) prodej v
autobuse (tj. s okamžitou jízdou). Případ (d) se může ještě rozpadnout na dva pod-případy:
(da) prodej kupónu a jízda jsou na strojku provedeny v rámci jedné transakce (tj. počítadlo
transakcí za zařízení se inkrementuje o 1) a (db) prodej a jízda jsou provedeny jako dvě
transakce (tj. počítadlo transakcí za zařízení se inkrementuje o 2).
Takže případ (c) bude vypadat ve zprávě transakcí (blíže viz. kapitola 4.2.9), každá
transakce je representována jedním tagem card-transaction:
...
Pokud se bude jednat o případ (da), pak budeme tyto dvě transakce reprezentovat jedním
tagem multi-transaction a dvěma podtagy card-sub-transaction:
...
...
Budeme-li posílat transakce ve verzi 2.1 pak využijeme card-transactions-with-items
se dvěma podtagy item:
...
A poslední možností je případ (db), kdy máme 2 transakce a proto i 2 tagy card-
transaction:
...
4.4.7. Jízda na kupón
Tato možnost je velmi jednoduchá, protože se jedná o kousek z předcházející kapitoly, tj.
vždy reprezentujeme pomocí tagu card-transaction:
...
Jízda na kupón se může zkomplikovat pokud je k uhrazení jízdného použit kupón a zároveň
je účtován doplatek: (a) je zaplacen hotově (b) a nebo je zaplacen z elektronické peněženky.
Případ (a) může být zapsán pouze ve verzi 2.2 a to:
...
...
Vydání 3 Revize 17 Strana 67/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Případ (b) ve verzi 2.2:
...
...
A ve verzi 2.1:
...
4.4.8. Prodej kupónu placeného elektronickou
peněženkou s okamžitou jízdou
Jedná se asi o nejsložitější možný případ, tj. v autobuse si koupím nový kupón (nebo
prodloužím existující), ten zaplatím z elektronické peněženky a ihned na něj pojedu. Jde o
podobný případ jako byl uveden v předcházejících kapitolách, ale je zkomplikovaný o
skutečnost placení z elektronické peněženky.
Opět budeme mít 2 varianty, jak se toto dá exportovat a opět to záleží na tom jak se chová
zařízení, kde se tyto operace provedou: (a) každá operace bude znamenat navýšení
počítadla transakcí za zařízení (máme 3 operace) a nebo (b) se počítadlo zvýší pouze o 1.
Případ (a) bude zapsán pomocí 3 tagů card-transaction:
...
Případ (b) bude reprezentován jedním tagem card-transaction-with-items a třemi
podtagy item:
...
...
Obdobný problém je možné řešit např. v předprodeji, kde si vlastník karty může dobít
elektronickou peněženku a zakoupit 2 kupóny. Pak opět záleží, zda se počítadlo transakcí
předprodeje navýší s každou operací (případ (a)) a nebo jenom jednou (případ (b)).
5. PRAVOMOCI A ODPOVĚDNOSTI
Vzhledem k tomu, že se jedná o popis, pravomoci nejsou uvedeny.
6. DOKUMENTACE A ZÁZNAMY VÝSLEDKŮ
Vzhledem k tomu, že se jedná o popis, záznamy nejsou vytvářeny.
Vydání 3 Revize 17 Strana 68/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
7. ZMĚNOVÁ SLUŽBA
Za údržbu tohoto popisu odpovídá vedoucí útvaru IDS. Za potřebnou aktualizaci řízených
výtisků tohoto popisu odpovídá příslušný správce dokumentace.
8. PŘEHLED REVIZÍ
0. revize 3. vydání vznikla zásadním přepracováním formátu příručky, revize proti 2. vydání
8. revizi nejsou v souladu s dokumentací SJ uvedeny.
Číslo
revize Strana Provedené změny Účinnost od
1 5 Přidána kapitola 3.2.6 popisující kontrakt v aplikaci. 1. 3. 2009
1 13-14 V kapitole 4.2.3 byl vylepšen popis specifikace 1. 3. 2009
počítadel transakcí za aplikaci a do odpovědi byla
přidána platnost aplikace (atributy valid-from a
valid-to).
1 14-15 V kapitole 4.2.4 byl vylepšen popis specifikace 1. 3. 2009
počítadel transakcí za kontrakt, byl změněn atribut
when v požadavku za valid-from a do odpovědi byla
přidána platnost aplikace (atributy valid-from a
valid-to).
1 15 V kapitole 4.2.5 byla do odpovědi přidána platnost 1. 3. 2009
aplikace (atributy valid-from a valid-to).
1 17 V kapitole 4.2.8 byly opraveny chyby v požadavku 1. 3. 2009
(ukázka XML)
1 20 V kapitole 4.2.9 byl k nekaretní transakci přidán 1. 3. 2009
nepovinný atribut amount.
1 31 V kapitole 4.2.18.2 byly v DTD požadavku správně 1. 3. 2009
specifikovány atributy max-tx-id a max-card-tx-id
a do DTD odpovědi přidána platnost aplikace
(atributy valid-from a valid-to).
1 32 V kapitole 4.2.18.3 byly v DTD požadavku správně 1. 3. 2009
specifikovány atributy max-tx-id, max-appl-tx-id,
max-card-tx-id a změněn atribut when za valid-
from. Do DTD odpovědi byla přidána platnost
aplikace (atributy valid-from a valid-to).
1 32 V kapitole 4.2.18.4 byla do DTD odpovědi přidána 1. 3. 2009
platnost aplikace (atributy valid-from a valid-to).
1 35-37 Do DTD v kapitole 4.2.18.9 přidán atribut contract- 1. 3. 2009
id a atribut amount u transaction tagu.
1 37-38 Do DTD v kapitole 4.2.18.10 přidán atribut 1. 3. 2009
contract-id a atribut amount u transaction tagu.
2 14 V kapitole 4.2.4 opraven název tagu 16. 3. 2009
z contracts-issues na contract-issues
2 21 Vylepšen popis atributu cross. 16. 3. 2009
2 48-51 Dodána kapitola 4.4 o popisu jak exportovat 16. 3. 2009
3 13-14 Do kapitoly 4.2.3 přidána specifikace atributu max- 30. 3. 2009
riding-tx-id
3 14-15 Do kapitoly 4.2.4 přidána specifikace atributu max- 30. 3. 2009
riding-tx-id
Vydání 3 Revize 17 Strana 69/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Číslo Strana Provedené změny Účinnost od
revize 15-16
20-23 Do kapitoly 4.2.5 přidána specifikace atributu max- 30. 3. 2009
3 riding-tx-id 30. 3. 2009
3 32-33
33 V kapitole 4.2.9 přidána možnost do tagu item vložit 30. 3. 2009
3 34 tag add-data a dummy-transaction může 30. 3. 2009
3 obsahovat identifikaci aplikace/kontraktu a hodnotu 30. 3. 2009
3 35-36 čítače transakcí za aplikaci/kontrakt (pro případ 30. 3. 2009
3 stornování karetní transakce při použití čítače
8 transakcí za aplikaci/kartu) 7. 5. 2009
4 15 7. 5. 2009
4 19 Do DTD v kapitole 4.2.18.2 přidána specifikace 7. 5. 2009
4 22-24 atributu max-riding-tx-id 7. 5. 2009
4 31 7. 5. 2009
4 32 Do DTD v kapitole 4.2.18.3 přidána specifikace 7. 5. 2009
4 34 atributu max-riding-tx-id
4 37-38
4 43 Do DTD v kapitole 4.2.18.4 přidána specifikace
4 49 atributu max-riding-tx-id
4
5 8 Do DTD v kapitole 4.2.18.9 přidána možnost do tagu
5 12 item vložit tag add-data a dummy-transaction
5 14 může obsahovat identifikaci aplikace/kontraktu a
5 18-19 hodnotu počítadla transakcí za aplikaci/kontrakt
5 19
Smazána kapitola 4.2.1.4 - rušení aplikací / kontraktů
(řeší se pomocí claim-transaction)
Smazána kapitola 4.2.6 - rušení aplikací / kontraktů
(řeší se pomocí claim-transaction)
V kapitole 4.2.8 doplněno, že amount je kladné číslo
V kapitole 4.2.8 doplněn popis reklamací (claim-
transaction)
V kapitole 4.2.14 opravena specifikace typů karet,
které se musí specifikovat
V kapitole 4.2.17.2 atribut valid-to je povinný.
Smazána kapitola 4.2.17.5 - rušení aplikací / 7. 5. 2009
kontraktů (řeší se pomocí claim-transaction) 7. 5. 2009
7. 5. 2009
V kapitole 4.2.17.8 doplněno DTD o reklamační 16. 10. 2009
transakci (claim-transaction) 16. 10. 2009
16. 10. 2009
V kapitole 4.2.17.17 opraveno DTD odpovědi. 16. 10. 2009
16. 10. 2009
V kapitole 4.4.3 opraven popis generovaní reklamace
elektronické peněženky
V kapitole 4.2.1.2 přidáno omezení na platnost
kontraktu
V kapitole 4.2.3 opraveno jméno atributu obsahující
ridding
V kapitole 4.2.4 opraveno jméno atributu obsahující
ridding
V kapitole 4.2.8 tag read-out dostal nepovinný atribut
last-tx-id
V kapitole 4.2.8 přidán popis dvou nových typů
dummy-transaction, tj. cancel a login.
Vydání 3 Revize 17 Strana 70/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Číslo Strana Provedené změny Účinnost od
revize 36-37
V kapitole 4.2.17.8 do DTD k tagu add-data přidány 16. 10. 2009
5 38-39
volitelné atributy zones a zone-route a k atributu
5 39-40 type u tagu dummy-transaction přidány 2 typy:
5 49 cancel a login
21
5 24 V kapitole 4.2.17.9 do DTD k tagu add-data přidány 16. 10. 2009
6
6 27 volitelné atributy zones a zone-route a k atributu
type u tagu dummy-transaction přidány 2 typy:
6 37
38 cancel a login
6
6 41 V kapitole 4.2.17.10 do DTD k tagu add-data přidány 16. 10. 2009
20
6 21 volitelné atributy zones a zone-route a k atributu
25 type u tagu dummy-transaction přidány 2 typy:
7 36-37
20 cancel a login
7 21
7 23 V kapitole 4.4.3 opraven překlep v příkladu ve verzi 16. 10. 2009
7 23
8 2.0
8
8 V kapitole 4.2.8 v popisu transakce jízdy na kupón byl 1. 6. 2011
8
přidán atribut previous-contract-id
V kapitole 4.2.8 do příkladu odpovědi na nahrání 1. 6. 2011
transakcí verze 2.1 přidán tag processing-
statistic
V kapitole 4.2.8 do příkladu odpovědi na nahrání 1. 6. 2011
transakcí verze 1.9 přidán tag processing-
statistic
V kapitole 4.2.17.8 doplněno DTD pro nahrávání 1. 6. 2011
transakcí o atribut previous-contract-id
V kapitole 4.2.17.8 doplněno DTD odpovědi na 1. 6. 2011
nahrání transakcí za zařízení o tag processing-
statistic
V kapitole 4.2.17.11 doplněno DTD odpovědi na 1. 6. 2011
nahrání transakcí za zařízení po odpočtech o tag
processing-statistic
V kapitole 4.2.8 byl změněn popis atributu type 20. 9. 2011
(smazána zakázaná volba reset a přidána volba
refund)
V kapitole 4.2.8 přidán popis kupónové transakce 20. 9. 2011
refund.
V kapitole 4.2.8 změněn popis tagu processing- 20. 9. 2011
statistic
V kapitole 4.2.17.8 upraveno DTD (atribut type a 20. 9. 2011
new-valid-to tagu card-transaction)
V kapitole 4.2.8 doplněn popis pro zadání celosíťové 1. 11. 2012
jízdenky
V kapitole 4.2.8 dodána možnost zaslat ke kupónu 1. 11. 2012
více cen v různých tarifech
V kapitole 4.2.8 zrušení elektronické peněženky 1. 11. 2012
obsahuje objem vracených peněz v atributu amount
V kapitole 4.2.8 při rušení kupónu před začátkem 1. 11. 2012
jeho platnosti je platnost do vždy platnost od + 1s
Vydání 3 Revize 17 Strana 71/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Číslo Strana Provedené změny Účinnost od
revize 23
V kapitole 4.2.8 převod peněz z jedné peněženky na 1. 11. 2012
8 24
24 druhou obsahuje specifikaci převáděné částky v
8
8 25-26 atributu amount
36
8 V kapitole 4.2.8 při převodu kupónu z jedné karty na 1. 11. 2012
8 38-39
druhou je nutno v amount uvést jeho cenu
8 17
17-18 V kapitole 4.2.8 u claim-transaction možnost 1. 11. 2012
9 specifikovat více cen u kupónu pomocí vnoření add-
9 37
9 12 data tagu
10 19-24
10 Smazána kapitola 4.2.8.2 obsahující formát pro 1. 11. 2012
38-39
10 zaslání dat o vydání papírového opisu kupónu na ČD
19
11 V kapitole 4.2.17.8 do add-data tagu přidán atribut 1. 11. 2012
38
11 amount a claim-transaction může obsahovat
12 vnořený add-data
12 20-21
12 39-40 Smazána kapitola 4.2.17.10 obsahující DTD formátu 1. 11. 2012
12
13 21 pro zaslání dat o vydání papírového opisu kupónu na
13 22 ČD
Přejmenována kapitola 4.2.7
V kapitole 4.2.7 zmíněna možnost upravit platnost
aplikace MAD
Přejmenována kapitola 4.2.17.7 1. 5. 2012
1. 5. 2012
V kapitole 4.2.3 upraven popis atributu when
1. 5. 2012
V kapitole 4.2.8 přidán popis atributů zones- 25. 7. 2012
interval a info-ids, atributy přidány do příkladů. 25. 7. 2012
Změněn popis atributu zones. Doplněna věta o
nutnosti vydat cílovou aplikaci při převodu kupónu 1. 6. 2013
1. 6. 2013
V kapitole 4.2.17.8 doplněno DTD transakcí za 1. 6. 2013
zařízení verze 2.1 o atributy zones-interval a 27. 9. 2013
info-ids. 27. 9. 2013
V kapitole 4.2.8 doplněn popis nepovinných atributů
hotovostní transakce o atributy vat, valid-from,
valid-to, zones, zone-route a zones-interval
V kapitole 4.2.17.8 doplněno DTD transakcí za
zařízení verze 2.1 o atributy hotovostní transakce
vat, valid-from, valid-to, zones, zone-
route a zones-interval.
V Kapitole 4.2.2 byl doplněn popis atributu network-
id i o možnost uvedení u transakcí.
V kapitole 4.2.8 doplněny příklady použití atributu
network-id.
V kapitole 4.2.17.8 doplněn atribut network-id do
DTD.
V textu doplněn výčet atributů nesoucích informaci o
jízdě o network-id. V příkladu opraven atribut tarif
na tariff.
V kapitole 4.2.8 doplněn příklad použití atributu
network-id v tagu add-data.
Vydání 3 Revize 17 Strana 72/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Číslo Strana Provedené změny Účinnost od
revize 39
9 V kapitole 4.2.17.8 k tagu add-data doplněn atribut 27. 9. 2013
13
14 18-25 network-id do DTD
14 26-27
14 V kapitole 4.2.1.6 byly doplněny možnosti zasílání 5. 9. 2014
14 31
14 39-41 transakcí
14 41-43
14 V kapitole 4.2.8 je nyní popsán nejnovější způsob 5. 9. 2014
14 53
14 54 zasílání transakčních dat ve verzi 2.2
14 54-55
14 55-56 V kapitole 4.2.8.1 je popis verze 2.1 vzhledem k verzi 5. 9. 2014
15 56-57 2.2
15 10
15 11 V kapitole 4.2.9 byla změněna odpověď na zaslání 5. 9. 2014
15 11
15 11 lokálního seznamu zařízení
15 26-27
28-29 V kapitole 4.2.17.8 je popis DTD transactions 5. 9. 2014
15 verze 2.2
15 30-31
15 33-34 V kapitole 4.2.17.9 je obsah původní kapitoly 4.2.17.8 5. 9. 2014
15
15 34 (tj. transactions verze 2.1)
34-35
44-46 V kapitole 4.4.1 upravena formulace ve čtvrtém 5. 9. 2014
odstavci
V kapitole 4.4.2 odstraněn překlep 5. 9. 2014
V kapitole 4.4.5 byl dopracován popis i pro 5. 9. 2014
transactions verze 2.2
V kapitole 4.4.6 byl dopracován popis i pro 5. 9. 2014
transactions verze 2.2
V kapitole 4.4.7 byl dopracován popis i pro 5. 9. 2014
transactions verze 2.2
Kapitola 4.2.1.6 doplněna o popis předplacených 19. 9. 2014
položek (greenlist)
Přidána kapitola 4.2.1.7 o prodeji předplacených 19. 9. 2014
položek (greenlist)
Přidána kapitola 4.2.1.8 o statusu předplacených 19. 9. 2014
položek (greenlist)
Přidána kapitola 4.2.1.9 o zaslání předplacených 19. 9. 2014
položek (greenlist)
Kapitola 4.2.8 doplněna o popis předplacených 19. 9. 2014
položek (greenlist).
Přidána kapitola 4.2.8.1 o transakcích ve verzi 2.2 19. 9. 2014
(de facto verze 2.1 s předplacenými položkami -
greenlistem)
Kapitola 4.2.8.2 změněna na popis transakcí 2.1 19. 9. 2014
oproti verzi 2.2.
Přidána kapitola 4.2.9 o prodeji předplacených 19. 9. 2014
položek (greenlist)
Přidána kapitola 4.2.10 o statusu předplacených 19. 9. 2014
položek (greenlist)
Přidána kapitola 4.2.11 o zaslání předplacených 19. 9. 2014
položek (greenlist)
Doplněn popis DTD transactions 3.0 v kapitole 19. 9. 2014
4.2.20.8 o předplacené položky (greenlist)
Vydání 3 Revize 17 Strana 73/74
ČSAD SVT Praha s.r.o.
CE02-PO CARDS – interface
Číslo Strana Provedené změny Účinnost od
revize 46-49
Přidána kapitola 4.2.20.9 s popisem DTD 19. 9. 2014
15 52-53
transactions 2.2
15 53
Přidána kapitola 4.2.20.13 s popisem DTD store- 19. 9. 2014
15 53
greenlist-items 1.0
15 5
Přidána kapitola 4.2.20.14 s popisem DTD get- 19. 9. 2014
16 9
9 greenlist-items-status 1.0
17 14-15
17 17 Přidána kapitola 4.2.20.15 s popisem DTD get- 19. 9. 2014
17 35
17 greenlist 1.0
17 41-42
43 V kapitole 3.1 změněny odkazy na u následujících 23. 10. 2014
17 55
17 zkratek: ISO-639, ISO-3166, ISO-8601, MAD
17
V kapitole 4.2.1.1 bylo zrušeno předvydání kupónů 3. 11. 2014
Přidána kapitola 4.2.1.4 o vydání karty 3. 11. 2014
V kapitole 4.2.3 smazáno předvydání kupónu 3. 11. 2014
Přidána kapitola 4.2.6 o vydání karty 3. 11. 2014
V kapitole 4.2.11 s lokálním greenlistem přidán tag 3. 11. 2014
no-item
V kapitole 4.2.21.2 smazáno předvydání 3. 11. 2014
Přidána kapitola 4.2.21.5 s DTD vydáním karty 3. 11. 2014
V kapitole 4.2.21.15 přidáno v DTD no-item 3. 11. 2014
PŘÍLOHY
Číslo přílohy Název přílohy, verze Vydání Počet
/ revize listů
Vydání 3 Revize 17 Strana 74/74
Příloha č. 8 ke Smlouvě o veřejných službách
Specifikace informačního systému
Vozidla, která bude Dopravce využívat pro plnění závazku veřejné služby dle této
Smlouvy, musí splňovat následující požadavky:
Hlasový informační systém, jehož prostřednictvím budou cestující během
jízdy informováni minimálně o jednotlivých zastávkách a přestupních
možnostech
Čelní elektronická tabule pro zobrazení čísla linky a cílové stanice
Boční elektronická tabule pro zobrazení čísla linky a cílové stanice (tabule
umístěna na pravém boku vozidla)
Zadní elektronická tabule pro zobrazení čísla linky
Vnitřní 19“ barevný grafický displej pro zobrazování následujících zastávek,
čísla linky, cílové stanice, aktuálního času a eventuálně dalších dopravních
informací (platí pouze pro nově zakoupená vozidla)
Tlačítka k udávání znamení řidiči k výstupu v prostoru pro cestující
v dostupné výšce pro děti (alespoň jedno tlačítko na každé výstupní dveře
vozidla a jedno tlačítko v prostoru sedadel vyhrazených pro ZTP a ZTP/P)
Tlačítko k udávání znamení řidiči k výstupu dětského kočárku nebo
invalidního vozíku (tlačítka mohou býti pro každou skupinu cestujících zvlášť
nebo pro obě skupiny dohromady)
Elektronický odbavovací systém – dle přílohy č. 12 ke Smlouvě o veřejných
službách
Příloha č. 9 ke Smlouvě o veřejných službách
Standardy kvality a bezpečnosti
Standardy kvality a bezpečnosti dle zákona č. 194/2010 Sb., o veřejných službách
v přepravě cestujících, ve znění pozdějších předpisů a prováděcích předpisů
k tomuto zákonu, je povinen Dopravce dodržovat v plném znění a všech
ustanoveních u vozidel, která používá pro zajištění závazku veřejných služeb dle
této Smlouvy, a na která se tyto standardy dle výše uvedeného zákona vztahují.
Objednatel si další požadované standardy kvality a bezpečnosti nad rámec
standardů kvality a bezpečnosti uvedených ve výše uvedeném zákoně nevyhrazuje.
Příloha č. 10 ke Smlouvě o veřejných službách
Příloha č. 11 ke Smlouvě o závazku veřejných služeb
Příloha č. 12 ke Smlouvě o veřejných službách
Čipové karty a elektronický odbavovací systém
I. Nosič elektronického jízdného a elektronických peněz
1. Základním nosičem elektronických jízdních dokladů a základním platebním
prostředkem umožňujícím odbavení cestujících elektronickým odbavovacím
systémem je bezkontaktní čipová karta (dále jen „BČK“ nebo „čipová karta“)
Mifare DESFire EV-1 8k (MF3 IC D41D81), jejíž vydávání cestujícím zajišťuje
Dopravce dle této přílohy č. 4 smlouvy. S ohledem na předpokládané zavedení
IDS na území Ústeckého kraje a s tím související nezbytností zajistit
kompatibilitu čipových karet s elektronickými odbavovacími systémy ostatních
dopravců musí čipové karty vydávané Dopravcem dle této smlouvy splňovat
veškeré níže uvedené parametry, mít definovanou vnitřní strukturu a
požadované zabezpečení.
II. Vnitřní struktura bezkontaktní čipové karty
Vnitřní struktura bezkontaktní čipové karty je definována standardem MAD3 a
obsahuje dopravní aplikaci IDS ÚK, která se skládá ze 4 kompletních aplikací a 4
rezervních aplikací pro případné další doplnění struktury BČK IDS ÚK. Každá
aplikace obsahuje jeden nebo více souborů s daty, jejich popis je uveden dále.
1. Personalizační aplikace
Personalizační aplikaci tvoří 2 soubory s informacemi o kartě a o jejím držiteli.
a) Informace o kartě
V tomto souboru jsou obsaženy základní informace o kartě:
• Identifikace vydavatele
• Identifikace sítě
• Logické číslo karty
• Počátek platnosti karty
• Konec platnosti karty
• Bezpečnostní prvky
b) Informace o držiteli
Tento soubor obsahuje informace vztahující se k držiteli karty:
• Datum narození držitele
• Pohlaví držitele
• Jméno a Příjmení držitele
• Další bezvýznamový identifikátor
• 2x Profil držitele, včetně platnosti od - do
V případě přenosných anonymních karet jsou údaje o držiteli nahrazeny
ekvivalenty.
2. Aplikace Průkazy/Benefity
Obecná aplikace je tvořená 5 stejnými soubory s různými právy na zápis do
jednotlivých souborů.
Podrobný obsah souborů bude určen až při konkrétním využití daného souboru.
3. Aplikace jízdenky IDS
Celkem 10 souborů tvoří aplikaci Jízdenky IDS. V nich jsou uloženy informace o
jízdních dokladech, jejich kontrole a případně i místenkách (v IDS ÚK nevyužito).
a) Soubor jízdenka
Ve struktuře BČK IDS ÚK je vyhrazeno místo pro celkem 5 souborů s
informacemi o jízdních dokladech. Ke každému z nich zároveň náleží další
Příloha 12 – str. 1
soubor o Kontrole jízdenky.
O jízdních dokladech jsou zaznamenávány tyto informace:
• Identifikace sítě
• Kód prodejce dokladu
• Číslo kupónu v rámci karty
• Typ dokladu
• Zařízení, které doklad prodalo
• Počátek a konec platnosti dokladu (datum a čas)
• Informace o profilu cestujícího
• Odkaz na soubor s místenkou
• Povolené dopravní prostředky, třída, trasa
• Typ transakce
• Měna a cena jízdního dokladu
• Číslo SAM (Security Access Module) provádějícího zápis
• Počet cestujících
• Další dopravně-tarifní informace
b) Kontrola jízdenky
O kontrole jízdenky jsou do BČK zaznamenávány tyto informace:
• Identifikace sítě
• Identifikace dopravce provádějícího kontrolu
• Datum, čas, linka, spoj, vozidlo, zóna, stanice místa kontroly
• Číslo zařízení, kterým byla kontrola provedena
• Počítadlo přestupů
• Počet jízd na časový kupón
Ve struktuře je vyhrazen prostor pro 5 souborů kontrol jízdenek.
c) Místenka
Tento soubor obsahuje informace o místence:
• Datum a čas platnosti
• Číslo linky, spoje a vozu
• Vozovou třídu
• Typ prodejní transakce
• Počet místenek a čísla sedadel (až 4)
• Měna a cena
Ve struktuře je vyhrazen prostor pro 2 soubory místenek.
4. Aplikace Elektronická peněženka (dále jen „EP“)
Obsahuje 4 soubory včetně souboru s transakčním logem pro kontrolu stavu
peněženky.
d) Nastavení EP
Obsahuje informace o základním nastavení EP. Jsou to:
• Identifikace sítě
• Kód vydavatele EP
• Maximální hodnota EP
• Minimální hodnota EP
• Maximální výše debetu
• Maximální výše dobití
• Datum expirace EP
• Povolený debet ano/ne
• Měna EP
e) Osobní nastavení EP
Obsahuje informace o aktuálním uživatelském nastavení EP. V IDS ÚK se
Příloha 12 – str. 2
s tímto souborem aktuálně nepracuje.
f) Hodnota EP
Tento soubor obsahuje pouze informaci o aktuální hodnotě EP.
g) Log EP
Slouží pro uchování informací o posledních pěti transakcích. Soubor obsahuje
tyto informace:
• Pořadové číslo transakce na EP
• Hodnota EP před transakcí
• Hodnota transakce
• Číslo zařízení, které provedlo transakci
• Číslo SAM, který provedl záznam
• Datum transakce
• Čas transakce
• Typ operace (debet, kredit atp.)
5. Rezervní aplikace
Rezervní aplikace neobsahují žádné soubory a jsou určeny pro budoucí
potenciální využití.
III. Zabezpečení systému
1. Zabezpečení elektronického odbavovacího systému je provedeno v souladu
s dokumenty:
• „Nařízení vlády č. 295/2010 Sb. o stanovení požadavků a postupů pro
zajištění propojitelnosti elektronických systémů plateb a odbavení cestujících“
• „Základní technické parametry systémů pro elektronické odbavení cestujících
ve veřejné dopravě v ČR“ vydaným dne 14.12.2010 Sdružením pro dopravní
telematiku.
Detailní informace o způsobu zabezpečení a práci s bezkontaktní čipovou kartou
budou dopravci sděleny až po podpisu dohody o mlčenlivosti.
2. Pro úspěšné zapojení dopravce do systému IDS ÚK je nutné, aby dopravce:
• dodržoval veškeré bezpečnostní procesy vyplývající z použití bezkontaktních
čipových karet a jejich zabezpečení.
• poskytl Ústeckému kraji veškerou součinnost při aktualizaci bezpečnostních
procesů o informace týkající se odbavovacího zařízení dopravce.
• poskytl Ústeckému kraji veškerou součinnost při implementaci, testování a
akceptačních testech nutných pro certifikaci zařízení dopravce pro použití
v rámci IDS ÚK.
Poznámka: Dokument „Základní technické parametry systémů pro elektronické
odbavení cestujících ve veřejné dopravě v ČR“ je dostupný na adrese:
http://www.sdt.cz/download/doc/Zakladni_technicke_Parametry_EOC_dle_SDT.pdf
3. V souladu s výše uvedenými dokumenty jsou bezpečnostní algoritmy a klíče
systému pro komunikaci s BČK umístěny na tzv. SAM, což je bezpečnostní
modul k tomu určený. SAM je umístěn v každém zařízení, které bude pracovat
z čipovou kartou. Potřebné SAM si zajistí dopravce od svého dodavatele a
zabezpečení SAM provede Ústecký kraj.
IV. Vydávání bezkontaktních čipových karet cestujícím
1. Dopravce je povinen zajistit vydávání čipových karet cestujícím jakož i veškeré
další procesy související s životním cyklem čipových karet (příjem žádostí o
vydání čipové karty, personalizace čipové karty, výdej čipové karty
cestujícímu/držiteli, výměna čipové karty, její ztráta, odcizení, zničení, reklamace
atp.). Objednatel je oprávněn vyhradit si kdykoliv během Doby plnění této
smlouvy, že bude vydávání čipových karet namísto Dopravce zajišťovat sám
Příloha 12 – str. 3
nebo prostřednictvím třetího subjektu; Dopravce bude v takovém případě
povinen čipové karty vydávané Objednatelem, resp. jím pověřenou třetí osobou
při odbavování cestujících plně akceptovat a zajistit jejich kompatibilitu
s elektronickým odbavovacím systémem používaným Dopravcem.
2. Dopravce bude vydávat čipové karty ve variantách:
• Přenosná karta
• Osobní karta
• bez evidence osobních údajů
• s evidencí osobních údajů
a) Přenosná karta
• Přenosná karta je určena pro libovolného cestujícího a její vydání ani
používání není podmíněno zpracováním osobních údajů žadatele o
vydání nebo držitele karty. Jediným evidovaným identifikátorem této
karty je identifikační číslo karty. Ke každé kartě bude držiteli vydán tzv.
certifikát, který bude určen k prokázání vlastnictví konkrétní čipové
karty. Rovněž tento certifikát neobsahuje žádné osobní údaje držitele
karty.
• V případě nutnosti řešení procesů životního cyklu karty, jako je
například blokace, zrušení, převod elektronických peněz zpět na
hotovost atp. musí být předložen vydaný certifikát ke kartě, bez něj
nebude provedení jakéhokoliv procesu s kartou možné.
b) Osobní karta bez evidence osobních údajů
• Osobní karta je určena pro konkrétního cestujícího a její vydání je
podmíněno souhlasem se zpracováním osobních údajů žadatele o její
vydání. Karta obsahuje kromě evidenčního čísla také další osobní
údaje, jako jsou fotografie, jméno a příjmení držitele, datum narození
držitele.
• Analogicky k přenosné kartě bude také k osobní kartě vydáván
certifikát, kterým bude držitel při řešení procesů životního cyklu karty
prokazovat vlastnictví konkrétní karty.
• Dopravce nepovede žádnou databázi osobních údajů držitelů BČK.
c) Osobní karta s evidencí osobních údajů
Objednatel, nebo jím pověřený subjekt, povedou centrální registr osobních
údajů držitelů BČK vydaných dopravci zapojenými do IDS, a to za účelem
řešení životního cyklu BČK. Držitel osobní karty tak bude mít možnost,
v případě udělení souhlasu se zpracováním osobních údajů pro účely
řešení procesů životního cyklu karty, řešit procesy životního cyklu BČK
pouze předložením osobního dokladu, tj. bez certifikátu. Dopravce zde
bude vystupovat jako zpracovatel osobních údajů pro Objednatele, správce
osobních údajů, a bude pro něj zajišťovat veškeré služby front-office.
Nutnou podmínkou pro tuto činnost je vybavení prodejního místa čipových
karet výpočetní technikou (samostatné PC se čtečkou BČK) a on-line
připojením k centrálnímu serveru registru databáze osobních údajů držitelů
BČK.
3. V souvislosti s vydáváním čipových karet je Dopravce povinen dodržovat
zejména, nikoliv však výlučně, níže uvedené povinnosti:
a) Dopravce zabezpečí čipovou kartu proti neoprávněným zásahům do vnitřní
struktury čipové karty vlastními klíči;
b) Dopravce na BČK vymezí prostor a inicializuje (provede úvodní
formátování a zabezpečení) dopravní aplikaci IDS, která bude mít pro
Příloha 12 – str. 4
všechny dopravce jednotnou strukturu definovanou Objednatelem a která
bude ve vlastnictví Objednatele. Pro každé pracoviště inicializace musí
Dopravce disponovat alespoň jedním SAM modulem s algoritmy a klíči k
zabezpečení a přístupu k celé vnitřní struktuře čipové karty a s algoritmy a
klíči k zabezpečení a přístupu k vnitřní struktuře dopravní aplikace.
Inicializaci provede Dopravce dle algoritmů a principů dodaných
Objednatelem,
c) Vydávané čipové karty budou mít grafickou podobu dle vzoru dodaného
Ústeckým krajem.
d) Dopravce je povinen provozovat nejméně jedno prodejní místo čipových
karet zajišťující příjem žádostí o vydání čipové karty, výdej čipové karty
jakož i další procesy související s životním cyklem čipové karty. ;
Prodejním místem čipových karet bude informační kancelář dle přílohy č. 3
smlouvy. Nad rámec smlouvy může Dopravce zřídit i další prodejní místa
čipových karet, která musí být umístěna ve vhodných prostorách pro
prezenční navštěvování cestujícími/zákazníky. Umístění dalšího
prodejního místa čipových karet a otvírací dobu tohoto prodejního místa
oznámí Dopravce Objednateli.;
e) Při vydávání čipových karet je Dopravce povinen pracovat s osobními údaji
žadatele v co nejmenším rozsahu nutném pro vydání osobní čipové karty,
a to pouze po dobu potřebnou pro vydání čipové karty. Procesy musí
splňovat požadavky zákona č.101/2000 Sb. o ochraně osobních údajů a o
změně některých zákonů, v platném znění („zákon o ochraně osobních
údajů“);
f) Dopravce nesmí vést žádnou evidenci osobních údajů držitelů čipových
karet ve smyslu zákona o ochraně osobních údajů;
g) Procesy odbavení, elektronické odbavovací zařízení a procesy evidence
údajů z elektronických odbavovacích zařízení musí splňovat požadavky
zákona o ochraně osobních údajů (odbavovací systém dopravce bude
zpracovávat osobní údaje držitelů karet jiných vydavatelů);
h) Ke každé čipové kartě musí být současně vydán certifikát, prokazující
jejímu držiteli práva k příslušné čipové kartě;
i) O inicializaci dopravní aplikace na čipové kartě musí být proveden záznam
do logu obsahující číslo čipové karty, její platnost (od) – (do) a kód
Dopravce, který kartu vydal;
j) Pro případ ztráty čipové karty, jejího odcizení či jiné situace vyžadující
znemožnění použití karty k tomu neoprávněnou třetí osobou musí
Dopravce vydávat seznam zakázaných karet (tzv. blacklist);
k) Doba platnosti čipových karet musí být omezena datem 31.12.2024 a po
tomto datu již nebudou karty dopravce v rámci IDS akceptovány. To
neplatí, uzavře-li Objednatel s Dopravcem v době trvání této smlouvy jiný
smluvní vztah na zajišťování dopravní obslužnosti v Ústeckém kraji, který
svou dobou trvání přesáhne platnost této smlouvy.
l) Dopravce je povinen vydávat čipové karty a poskytovat další služby
související s celým životním cyklem čipových karet za ceny, které
nepřesáhnou níže uvedené maximální ceny (všechny ceny jsou uvedeny
včetně DPH):
Vydání čipové karty ve variantě osobní – 95 Kč
nepřenosná (bez evidence osobních údajů):
Příloha 12 – str. 5
(osobní – nepřenosná čipová karta musí být 95 Kč
vydána ve lhůtě do 21 kalendářních dnů od
přijetí příslušné žádosti k jejímu vydání)
Vydání čipové karty ve variantě osobní –
nepřenosná (s evidencí osobních údajů):
(osobní – nepřenosná čipová karta musí být 95 Kč
vydána ve lhůtě do 21 kalendářních dnů od
přijetí příslušné žádosti k jejímu vydání) 95 Kč
Vydání čipové karty ve variantě anonymní –
přenosná: zdarma
(anonymní – přenosná čipová karta musí být zdarma
vydána na počkání) 30 Kč
Vydání čipové karty při ztrátě, zcizení,
nefunkčnosti, neuznané reklamaci, nebo
změně osobních údajů vytištěných na kartě
Vydání karty při uznané reklamaci
Zablokování karty
Odblokování karty
Minimální vklad do elektronické peněženky 0 Kč
Maximální vklad do elektronické peněženky ekvivalent v Kč
odpovídající částce
150 EUR
Minimální částka pro zpětnou výměnu 0 Kč
elektronických peněz
Nutné náklady na zpětnou výměnu 30Kč
elektronických peněz
Poplatek za vyhotovení výpisu o pohybech na 20Kč/strana A4
kartě
Poplatek za vyhotovení opisu dokladu o 20Kč
zakoupení jízdného či dobití elektronické
peněženky
m) Dopravce je v souvislosti s vydáváním čipových karet a elektronickou
peněženkou povinen naplňovat veškeré podmínky zákona č. 284/2009 Sb.,
o platebním styku, v platném znění (dále jen „zákon o platebním styku“),
platné pro vydavatele elektronických peněž malého rozsahu a dodržovat
veškeré zákonné povinnosti s vydáváním elektronických peněz související;
v souvislosti s elektronickou peněženkou platí, že:
• elektronický peněžní prostředek je přijímán pro úhradu jízdného a
dovozného v dopravních prostředcích vydavatele (Dopravce či jiných
dopravců v rámci IDS) a příjemců (Dopravce či jiných dopravců v rámci
IDS);
• příjemcem elektronických peněžních prostředků je dopravce, který na
základě smlouvy s vydavatelem uznává ve svých dopravních
prostředcích i elektronické peněžní prostředky vydavatele;
• užíváním elektronického peněžního prostředku se rozumí
bezhotovostní platby jízdenek a nabíjení elektronických peněženek v
dopravních prostředcích a předprodejních kancelářích vydavatele,
příjemců nebo osoby, která je smluvně oprávněna nabíjet tyto
Příloha 12 – str. 6
elektronické peněžní prostředky.
Dopravce je dle zákona o platebním styku povinen provádět zpětnou
výměnu elektronických peněz uložených na čipových kartách dle této
smlouvy jejím držitelům. Porušením této povinnosti vznikne Objednateli
vůči Dopravci peněžní pohledávka z této smlouvy odpovídající výši částky
zpětně nevyměněných elektronických peněz, kterou je Objednatel
oprávněn čerpat z bankovní záruky dle čl. 3 odst. 7 této smlouvy a
následně odpovídající částky vyplácet držitelům předmětných čipových
karet.
n) Dopravce je povinen vést veškeré údaje o čipových kartách vydávaných
dle této smlouvy odděleně od údajů ostatních jím případně vydávaných
karet;
o) Dopravce je povinen ukládat hotovost ve výši celkového zůstatku
elektronických platebních prostředků vložených na čipové karty vydávané
dle této smlouvy odděleně od hotovosti vložené do ostatních jím případně
vydávaných karet (tedy na zvláštním účtu); Dopravce je v této souvislosti
povinen zasílat Objednateli pravidelné měsíční výpisy o zůstatku na tomto
zvláštním účtu;
p) Majitelem čipové karty je Dopravce;
q) V případě předčasného ukončení této smlouvy (před koncem Doby plnění)
je Dopravce povinen zejména:
• umožnit držitelům jím vydaných čipových karet používání těchto
čipových karet až do skončení jejich platnosti (do 31.12.2024);
• předat Objednateli veškeré informace o čipových kartách, o zůstatku
elektronického platebního prostředku a o časovém jízdném na čipových
kartách k datu předčasného ukončení smlouvy;
• převést veškerou hotovost ve výši celkového zůstatku elektronických
platebních prostředků vložených do čipových karet vydaných
Dopravcem dle této smlouvy k datu předčasného ukončení smlouvy na
bankovní účet určený za tím účelem Objednatelem.
Po splnění všech výše uvedených podmínek tohoto odstavce převezme
Objednatel, resp. jím pověřený třetí subjekt, veškeré závazky Dopravce
vyplývající ze zákona č. 284/2009 Sb., o platebním styku, v platném znění
a převezme za Dopravce řešení životního cyklu čipových karet (nové
čipové karty Dopravce však již nebudou vydávány).
V. Vydávání průkazů na slevu
1. Dopravce je povinen zajistit vystavování a ověřování žákovských a studentských
průkazů dle zásad uvedených ve Výměru MF č.1/2013 ze dne 28. listopadu
2012, kterým se vydává seznam zboží s regulovanými cenami, a je povinen
postupovat v této souvislosti dle Metodického pokynu pro poskytování
žákovského jízdného v železniční vnitrostátní dopravě osob a ve veřejné
vnitrostátní pravidelné autobusové osobní dopravě ze dne 20. března 2012
stanoveném Ministerstvem dopravy (č.j. 11/2012-410-TAR/1) , resp. dle výměru
a metodického pokynu či jiných předpisů, které výše uvedené předpisy v
průběhu plnění této smlouvy Dopravcem nahradí.
VI. Odbavovací zařízení v linkové autobusové dopravě
1. Všechna vozidla používaná Dopravcem k plnění této smlouvy musí být
vybavena elektronickým odbavovacím systémem umožňujícím odbavení
Příloha 12 – str. 7
cestujících prostřednictvím čipových karet dle této přílohy č. 4 smlouvy.
2. Pro nasazení zónově-relačního tarifu IDS ÚK musí odbavovací zařízení (dále jen
„OZ“) dopravce:
• pracovat s bezkontaktními čipovými kartami Mifare DESfire EV1 přes
komunikační rozhraní dle ISO 14443 „Identifikační karty, Bezkontaktní karty s
integrovanými obvody, Karty s vazbou na blízko“;
• splňovat podmínky Nařízení vlády č. 295/2010 Sb., o stanovení požadavků a
postupů pro zajištění propojitelnosti elektronických systémů plateb a
odbavení cestujících;
• mít veškeré klíče a bezpečnostní algoritmy pro práci s bezkontaktní čipovou
kartou uložené na SAM, zařízení musí proto disponovat pro účely odbavení
dokladů IDS ÚK jedním volným SAM slotem, nebo SAM modulem s
dostatkem místa pro dodatečné umístění algoritmů a klíčů IDS ÚK.
Bezpečnostní klíče dodá Ústecký kraj;
• k inicializaci zařízení používat rozdělený autentifikační klíč (autentifikace –
ověření identity uživatele tzn. obsluha se musí vůči zařízení identifikovat
pomocí PIN, hesla, osobní čipové karty nebo kontaktního identifikačního
čipu, či jinou ekvivalentní cestou);
• být v pravidelných intervalech validováno vůči centrálnímu serveru HSM IDS
ÚK;
• splňovat podmínky zákona č.101/2000Sb. na ochranu osobních údajů, ve
znění pozdějších předpisů, a to včetně všech procesů pracujících s daty z
odbavovacího zařízení dopravce;
• být pro systém IDS ÚK identifikovatelné jedinečným označením (například
výrobním číslem strojku);
• provést kompletní komunikaci (čtení i zápis) při jakékoliv operaci s BČK
(prodej jízdního dokladu, zobrazení jízdních dokladů na BČK při nástupu
cestujícího, dobití EP) v časovém limitu 2s.
3. Ve veřejné linkové autobusové dopravě je předpokládán nástup předními dveřmi
s prodejem a kontrolou jízdních dokladů řidičem. Odbavovací zařízení je proto
umístěno v prostoru řidiče. Volby provádí řidič, cestující pouze přikládá kartu a
odebírá papírový doklad. Ve vozidle je možné se bezhotovostně odbavit z karty
nebo provést platbu v hotovosti. Z operací s kartou je povoleno dobití
elektronické peněženky, zakoupení elektronické nebo papírové jízdenky pro
jednotlivou jízdu nebo časového kupónu. Odbavovací zařízení musí být
umístěno tak, aby nebránilo řidiči ve výhledu, aby bylo ergonomicky ovladatelné
a aby byly potřebné prvky snadno dosažitelné pro cestujícího.
V obrázku jsou použity následující značky:
Č – čtečka karet
P – pokladna na uchovávání hotovosti
Příloha 12 – str. 8
Ř – řídící jednotka s ovládacím terminálem
T – tiskárna papírových dokladů
4. Odbavovací zařízení pro linkovou dopravu musí umožnit prodej papírových
jízdních dokladů, elektronických jízdních dokladu, dobití elektronické peněženky,
zobrazení informací o jízdních dokladech uložených na BČK a další níže
specifikované funkce.
a) Prodej papírových jízdních dokladů:
• prodej papírového jízdního dokladu bez použití čipové karty (platba v
hotovosti);
• prodej papírového časového jízdního dokladu (sedmidenní jízdné do 30
tarifních jednic) bez použití čipové karty (platba v hotovosti);
• prodej papírového jízdního dokladu pro spolucestujícího (platba
elektronickou peněženkou), a to včetně možnosti volby více cestujících
(max. deset cestujících včetně držitele karty) v kombinaci různých tarifů
(např. dospělý a dítě).
b) Prodej elektronických jízdních dokladů:
• prodej elektronického přestupního jízdního dokladu pro jednotlivou jízdu
s použitím čipové karty (platba v hotovosti i elektronickou peněženkou);
• prodej elektronického přestupního časového jízdního dokladu (platba
v hotovosti i elektronickou peněženkou);
• prodej integrovaného přestupního jízdního dokladu pro jednotlivou jízdu
prostřednictvím čipové karty (platba elektronickou peněženkou) či bez
použití čipové karty (platba v hotovosti), a to včetně možnosti volby více
cestujících (max. deset cestujících včetně držitele karty) v kombinaci
různých tarifů (např. dospělý a dítě).
• prodej elektronického časového jízdního dokladu do libovolného místa
IDS,
c) Další operace:
• dobití elektronické peněženky na čipové kartě vydané i jiným
dopravcem či vydavatelem;
• kontrola elektronického jízdního, které má cestující na kartě již při
nástupu do vozidla.
• storno provedených transakcí ve stanoveném časovém limitu;
d) Další požadované funkce:
• upozornění obsluhy OZ na nutnost předložení průkazu na slevu;
• možnost zamezení provádění transakcí (všech nebo jen určených) s
čipovými kartami určeného vydavatele;
• možnost pracovat s výjimkami z tarifu (zákaz prodeje určených druhů
dokladů v určených zónách nebo časových obdobích atp.);
• zápis záznamu o provedení transakce do logu a na čipovou kartu, a to
jak pro prodej jízdního dokladu, tak i pro samotné odbavení;
• pro obsluhu jednoduchý prodej jízdního dokladu do cílové zóny mimo
aktuální linku (např. výběrem z číselníku zastávek/zón);
• jednoduché procházení všech jízdních dokladů na čipové kartě;
• OZ musí v souvislosti se zavedením plánovaných změn na jednotlivých
linkách pracovat s aktuálně platnými daty (do určitého data) a dále mít v
sobě uloženu alespoň jednu sadu dat s definovanou platností v
budoucnu (od určitého data);
• nahrávání/vyčítání dat do/ze zařízení zabezpečenou, jednoduchou,
nejlépe automatizovanou cestou (wifi, bluetooth, GPRS), a to včetně
Příloha 12 – str. 9
přenosu dat z jednotných číselníků do OZ;
5. Za účelem jednotného vzhledu papírových jízdních dokladů IDS ÚK Ústecký
kraj dodá všem zaintegrovaným autobusovým dopravcům papír do tiskáren
jízdních dokladů zabezpečený ochrannými prvky dle svého uvážení
nejpozději 1 měsíc před zahájením provozu. Bez souhlasu Objednatele není
Dopravce oprávněn používat papír k jiným účelům, než k tisku jízdních
dokladů IDS ÚK a příjmových dokladů vydaných k jízdním dokladům IDS ÚK
uložených na BČK a k dobití EP a k tisku certifikátu k BČK. Dopravce sdělí
Objednateli nejpozději 6 měsíců před datem zahájení provozu dle této
Smlouvy parametry papíru do tiskáren odbavovacího zařízení (zejména šířku
papíru a průměr role, příp. druh tiskárny).
6. Práce s linkami a tarify
Odbavovací zařízení může pracovat kromě linek zcela zařazených do IDS také s
linkami, které jsou v IDS zařazeny jen částečně (částí trasy – typicky linka přes
hranici kraje) nebo nejsou do IDS zařazeny vůbec (komerční linky). Pro tyto
případy musí zařízení pojmout jak tarif IDS, tak i tarif dopravce platný na
ostatních linkách. Zařízení pak musí pracovat s linkami tak, že když je:
• celá linka zařazena v IDS, používá tarif IDS,
• celá linka mimo IDS, používá tarif dopravce,
• linka zařazena do IDS jen částí trasy, tak pracuje zároveň s tarifem IDS a s
tarifem dopravce (respektive volí mezi nimi).
Způsob přepínání mezi tarify (volby tarifu) je věcí nastavení zařízení, vždy však
musí být splněno, že pokud je:
• nástupní zastávka v IDS a výstupní zastávka mimo IDS použije se tarif
dopravce,
• nástupní zastávka mimo IDS a výstupní zastávka v IDS použije se tarif
dopravce,
• nástupní i výstupní zastávka mimo IDS použije se tarif dopravce,
• nástupní i výstupní zastávka v IDS použije se tarif IDS.
7. Procesy prodeje jízdních dokladů IDS ÚK
a) Papírový jízdní doklad IDS ÚK
Při prodeji řidič:
• navolí nástupní zastávku (zónu) – toto zpravidla provádí zařízení
automaticky dle GPS případně dle jízdního řádu,
• navolí výstupní zastávku po trase linky nebo z číselníku vybere
zastávku či zónu mimo trasu linky,
• zvolí počátek platnosti JD v případě, že bude odlišné od aktuálního
data, jinak potvrdí předvolbu aktuálního dne a času,
• zvolí druh jízdného (zadá číslo tarifu),
• zvolí počet jízdních dokladů (jízdenky pro spolucestující),
Zařízení:
• vytiskne doklad,
• provede záznam do logu transakcí (prodejní i o odbavení),
• na konec odbavení upozorní zařízení zvukovým signálem.
Uvedený proces je prakticky stejný jak pro jízdní doklad pro jednotlivou
jízdu, tak i pro časový kupón. U časového kupónu nelze slučovat jízdní
doklady pro více cestujících, počet cestujících na jednom jízdním dokladu
bude vždy jeden.
Příloha 12 – str. 10
Při prodeji papírového časového kupónu zařízení nesmí povolit řidiči prodej
mimo tarifem nastavený rámec (tj. nad 30 tarifních jednic).
b) Elektronický jízdní doklad IDS ÚK pro jednotlivou jízdu
Při prodeji řidič:
• navolí nástupní zastávku (zónu) – toto zpravidla provádí zařízení
automaticky dle jízdního řádu,
• navolí výstupní zastávku po trase linky nebo z číselníku vybere
zastávku či zónu mimo trasu linky,
• zvolí počátek platnosti JD v případě, že bude odlišné od aktuálního
data, jinak potvrdí předvolbu aktuálního dne a času,
• zvolí druh jízdného (zadá číslo tarifu),
• zvolí počet jízdních dokladů (jízdenky pro spolucestující),
• vyzve cestujícího k přiložení karty.
Cestující následně přiloží kartu a zařízení zjistí její obsah.
Zařízení:
• při prodeji časového kupónu prohledá všechny sektory s časovými
kupóny a nalezne-li časový doklad se stejnou zónově-relační platností a
s časovou platností překrývající se s prodávaným dokladem, upozorní
na to řidiče,
• zobrazí možnost volby platby (v hotovosti nebo elektronickou
peněženou),
• provede odečtení částky z elektronické peněženky,
• zapíše doklad na kartu,
• provede záznam do logu transakcí (prodejní i o odbavení),
• vytiskne doklad,
• na konec odbavení upozorní zařízení zvukovým signálem.
c) Elektronický časový kupón
Proces je prakticky shodný při prodeji jízdenky pro jednotlivou jízdu i při
prodeji časového kupónu (zde opět odpadá volba počtu jízdních dokladů –
je vždy pouze jeden). Při prodeji časového jízdního dokladu je cena
časového jízdního dokladu určena vždy z číselníku.
8. Proces odbavení cestujícího s přestupním jízdním dokladem
Přestupní jízdní doklady jsou i papírové jízdní doklady (pro jednotlivou jízdu,
časové sedmidenní, Labe-Elbe). Tyto doklady jsou kontrolovány pouze vizuálně
řidičem, do OZ jsou zaznamenány pouze při jejich výdeji, nikoliv při přestupu.
Proces odbavení cestujícího s přestupním jízdním dokladem na BČK je
definován tak, že odbavovací zařízení po prohledání bezkontaktní čipové karty
zobrazí řidiči na displeji pouze ty jízdní doklady, které jsou v okamžiku kontroly
časově platné a které jsou zároveň zónově platné v nástupní zastávce.
a) Premisy
• OZ neprovádí kontrolu platnosti jízdního dokladu (dále jen „JD“), tuto
pravomoc má řidič;
• OZ pouze zobrazuje jízdní doklady z BČK podle předem stanoveného
pravidla (v okamžiku kontroly časově platné a které jsou zároveň
zónově platné v nástupní zastávce);
• výstupní zastávka není důležitá, kontroluje se pouze platnost v nástupní
zastávce;
• princip odbavení je totožný pro jízdenku pro jednotlivou jízdu i pro
časový kupón, dále uvádíme pod zkratkou JD – „jízdní doklad“.
b) Popis procesu odbavení
Příloha 12 – str. 11
• řidič na OZ nic nenastavuje a cestující přiloží BČK;
• OZ prohledá všechny JD na BČK a zobrazí pouze platný JD vybraný na
základě těchto požadavků (filtrů):
o časová platnost - porovná aktuální čas s údaji "od - do" na JD;
o prostorová platnost - z polohy GPS a jízdního řádu je OZ známa
nástupní zastávka, z číselníku zařazení zastávek do zón je
známa zóna nástupní zastávky, takto získanou zónu nástupní
zastávky porovná OZ pomocí matice povolených cest s údaji
"odkud - kam" na JD; výstupní zastávka se nekontroluje;
• vyfiltrovaný jízdní doklad zobrazí na displeji OZ;
• z vyfiltrovaného JD přečte OZ jeho TP (tarifní profil) a je-li TP žák,
student, senior atp. zobrazí na displeji upozornění, že je třeba předložit
průkaz na slevu; toto upozornění může být například formou nápisu
"nutný průkaz žák 6-15"/“"nutný průkaz žák 15-26" atp., nebo jinou
barvou podkladu zobrazených údajů (JD bez nutnosti předložit průkaz
například se šedivým podkladem, JD s nutností předložit průkaz na
slevu žák například s oranžovým podkladem, atp. každý druh
slevy/kategorii cestujících jinou barvou); v případě osobní bezkontaktní
čipové karty není nutné předkládat průkaz na slevu, pokud je tato sleva
aktivována na BČK, řidič však k provedení řádné kontroly potřebuje
informaci o TP uloženém v profilu cestujícího na BČK, proto v tomto
případě OZ zobrazí nápis „žák -15“, „student 15-26“, popř. „senior“
v zónách s MHD, ve kterých bude tato sleva poskytována dle platného
tarifu;
• pokud je nalezeno z časového a prostorového hlediska více JD, prioritu
zobrazení má ten JD, jehož časová platnost je kratší ("do" na JD
nastane dříve) a řidič je upozorněn na existenci dalšího platného JD;
• řidič z trasy linky vyhodnotí, zdali je možné na JD jet, je-li více JD tak
musí mít řidič možnost mezi JD jednoduše přepínat;
• vybraný JD řidič potvrdí klávesou a data o odbavení se zapíší do logu.
Poznámka: Za doklady neplatné z časového hlediska se považují jízdenky pro
jednotlivou jízdu a časové kupóny, jejichž platnost již skončila, nebo časové kupóny
zakoupené v předprodeji, jejichž platnost ještě nezačala. Za doklady neplatné z
hlediska zónově–relační platnosti se považují takové jízdní doklady, jejichž platnost
udaná maticí povolených cest neobsahuje kombinaci nástupní a výstupní zóny
nastavenou na odbavovacím zařízení.
9. Vstupní a výstupní data odbavovacího systému
Ústecký kraj předá dopravci datové soubory charakterizující IDS ÚK – číselníky
IDS – v elektronické podobě ve tvaru strukturovaného dokumentu (xml, csv, xls).
V případě změn v IDS ÚK bude Ústecký kraj vydávat aktualizace v úplném
znění, které nahradí předchozí verzi.
a) Dopravce bude předávat zúčtovacímu centru IDS ÚK datové soubory ve
tvaru strukturovaného dokumentu (xml, csv, xls) obsahující výstupní data.
Jedná se o:
• záznamy o zařazení nových karet do systému,
• záznamy o vyřazení karet ze systému,
• blacklist (seznam zakázaných karet vydaných dopravcem),
• záznamy o zařazení/vyřazení prvků odbavovacího systému
do/z provozu,
Příloha 12 – str. 12
• záznamy o prodaných jízdenkách pro jednotlivou jízdu a časových
kupónech,
• záznamy o dobití elektronické peněženky,
• záznamy o použití jízdenek pro jednotlivou jízdu a časových kupónů.
Data jsou předávána ve strukturovaném dokumentu (xml).
b) Vstupní data předává účtovatel dopravci. Jde především o:
• blacklist (seznam zakázaných karet vydaných všemi dopravci),
• záznamy o zakoupených jízdenkách pro jednotlivou jízdu a časových
kupónech u jiných dopravců,
• záznamy o dobití elektronické peněženky u jiných dopravců,
• záznamy o použití jízdenek pro jednotlivou jízdu a časových kupónů u
jiných dopravců.
Data jsou rovněž předávána ve strukturovaném dokumentu (xml).
c) Pro komunikaci se zúčtovacím centrem jsou předpokládány formáty dat
definované vstupní větou Cards Interface společnosti ČSAD SVT.
10. Vzory jízdních a příjmových dokladů
Za účelem jednoduché kontroly jízdních dokladů řidičem při přestupu je nutné
graficky rozlišovat jízdní doklady od dokladů příjmových (prodej JD uložených na
BČK, nabití elektronické peněženky). Níže jsou uvedeny vzory jízdních dokladů
o šířce 58 mm. Pro jinou šířku JD může Objednatel s Dopravcem dojednat jiný
vzor vycházející z obdobných principů, tj. jednotnost v rámci IDS ÚK, odlišení
jízdních dokladů od příjmových.
Vzor JD o šířce 58mm:
Jízdní doklad časový
Příloha 12 – str. 13
Jízdní doklad pro jednotlivou jízdu
Příjmový doklad za časový jízdní doklad uložený na BČK
Příloha 12 – str. 14
Příjmový doklad za jízdenku pro jednotlivou jízdu uloženou na BČK
Příloha 12 – str. 15
