Textová podoba smlouvy

Smlouva č. 6054331: Smlouva o veřejných službách v přepravě cestujících

Příloha 4, ....pdf

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á:



V tomto případě jsou povinnými atributy:

• card-id je číslo karty, která byla vydána

• when obsahuje datum a čas začátku platnosti aplikace (jméno atributu je z důvodu
   udržení zpětné kompatibility zavádějící)

• type specifikuje typ aplikace, možné hodnoty jsou: cash - elektronická peněženka, time
   - časový kupón a mad - MAD aplikace s vnořenými kontrakty (nesmí mít specifikováno
   počítadlo transakcí, protože nemůže mít žádné transakce - atributy max-tx-id, max-
   riding-tx-id či max-card-tx-id)

• valid-to obsahuje datum a čas platnosti do aplikace

Nepovinnými jsou:

• medium specifikuje typ karty (není-li uveden použije se hodnota classic)

• appl-id je identifikátor aplikace na kartě (není-li uveden použije se hodnota 0)

• max-tx-id (případně max-riding-tx-id či max-card-tx-id) je specifikováno v případě,
   že aplikace podporuje číslování transakcí. Pokud má tato aplikace vlastní počítadlo
   transakcí, pak je použit atribut max-tx-id. Druhou možností je počítadlo max-riding-
   tx-id napříč všemi aplikacemi (kontrakty), kde počítadlo počítá jednotlivé jízdy. Poslední
   možností je počítadlo transakcí max-card-tx-id používané všemi aplikacemi (kontrakty)
   na kartě při jakékoliv transakci. Není-li uveden ani jeden, pak se číslování transakcí
   nepoužívá v kontrolních algoritmech. Může být použit pouze jeden atribut z této trojice.
   Je-li hodnota 2048, pak číslo transakce za aplikaci (kartu) může nabývat hodnot 0 - 2047

Vydání 3  Revize 17                     Strana 15/74
          ČSAD SVT Praha s.r.o.

          CE02-PO    CARDS – interface

Jako odpověď je zasílán seznam jednotlivých aplikací, každá je označena, zda byla aplikace
úspěšně vydána (předvydána či aktivována) či nikoliv:

    
    
    
         
         
         
         
         ....
         
    

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í:

    

Atributy next-tx-id a when jsou povinné, when říká, kdy vyčtení zařízení nastalo a next-
tx-id říká číslo transakce, kterou zařízení vytvoří jako první po vyčtení. Tato informace
slouží především v okamžiku, kdy zařízení nevytváří data, protože umožňuje automatické
posouvání data, od kdy clearingové centrum čeká data od toho zařízení. Pokud na zařízení
dojde k resetu (tj. začne znova generovat číslo transakce od 0 nebo 1), pak je vhodné použít
atribut last-tx-id, který obsahuje poslední číslo transakce před resetem a next-tx-id
obsahuje číslo první transakce po resetu (musí být 0 nebo 1).

Další velmi jednoduchou transakcí je tzv. předstíraná transakce (tag dummy-transaction):

    

Tento tag nese informaci o transakci, která není ani hotovostní, tj. pouze systému říká, že na
zařízení vznikla transakce s předaným číslem, aby si systém nemyslel, že transakci tohoto
čísla nedostal. Transakce může být 3 typů (atribut type): stornovaná transakce (hodnota
canceled), storno transakce, která stornuje jinou transakci (hodnota cancel) a transakce
vzniklá při zavírání odpočtu (hodnota login). Další atribut tx-id nese pořadové číslo
transakce na zařízení a atribut when nese datum a čas vzniku transakce. Všechny atributy
jsou povinné.

Pokud je stornována karetní transakce, která změnila počítadlo transakcí, pak je nutno
použít rozšířenou variantu předstírané transakce:

    

V tomto případě máme navíc atributy card-id, medium, appl-id a contract-id, které
identifikují aplikaci a následně atribut appl-tx-id nese informaci o čísle stornované
transakce. Tato verze předstírané transakce je důležitá pro předání čísla transakce (na
zařízení - tx-id a za kartu/aplikaci/kontrakt - appl-tx-id), která vznikla, ale byla zrušena.

Dostáváme se k hotovostní transakci:

    

Pro potřeby clearingu jsou povinné pouze atributy tx-id a when, které již známe. Ostatní
atributy jsou nepovinné z hlediska formátu. Mohou být povinné z hlediska nařízení (např.
krajským úřadem) sběru určitých dat pro potřeby vyhodnocení. Jejich význam je následující:

• amount - nese objem transakce (kladné číslo s desetinou částí)

• departure-id (arrival-id) - obsahují 2 čísla oddělená středníkem, první je číslo
   nástupní (výstupní) zastávky podle CIS JŘ a druhé je tarifní číslo zastávky

• line - linka podle CIS JŘ

• sequence - spoj podle CIS JŘ

• tariff – obsahuje identifikátor typu tarifu (textový řetězec)

• tariff-km – obsahuje tarifní kilometry

• info-ids – obsahuje libovolné dodatečné informace (textový řetězec), obsah není
   clearingovým centrem nijak zpracováván

• valid-from – počátek platnosti jízdenky

• valid-to – konec platnosti jízdenky

• network-id – identifikace IDS, v jehož tarifu byla jízdenka vydána

• zones – čísla zón, kde je kupón platný, oddělená středníkem (zónový tarif)

• zone-route - číslo nástupní a výstupní zóny oddělené středníkem (zónově relační tarif)

• zones-interval - čísla počátku a konce intervalu zón, ve kterých kupón platí, nebo „*“

Vydání 3  Revize 17                     Strana 22/74
          ČSAD SVT Praha s.r.o.

          CE02-PO    CARDS – interface

Poslední tři uvedené atributy týkající se platnosti kupónu v zónách se navzájem vylučují, tedy
je možné uvést pouze jeden z těchto atributů.

Další skupinou transakcí jsou transakce na elektronickou peněženku:

    

Že se jedná o transakci na elektronickou peněženku, poznáme podle přítomnosti atributu
balance-after, který nese zůstatek elektronické peněženky po transakci. Po již známých
atributech tx-id a when nastupují další povinné atributy pro tento typ transakce:

• card-id, medium, appl-id a contract-id identifikují aplikaci či kontrakt, povolené
   kombinace jsou (v našem příkladu identifikujeme aplikaci - 2 odrážka):

• card-id - aplikace na kartě předaného čísla, typu classic a číslo aplikace 0

• card-id, appl-id - aplikace na kartě předaného čísla, typu classic a předaného čísla
   aplikace

• card-id, medium - aplikace na kartě předaného čísla, předaného typu a číslo aplikace 0

• card-id, medium, appl-id - aplikace na kartě předaného čísla, předaného typu a
   předaného číslo aplikace

• card-id, contract-id - kontrakt na kartě předaného čísla, typu classic, čísla aplikace
   0 a kontrakt předaného čísla

• card-id, appl-id, contract-id - kontrakt na kartě předaného čísla, typu classic,
   předaného čísla aplikace a kontrakt předaného čísla

• card-id, medium, contract-id - kontrakt na kartě předaného čísla, předaného typu,
   číslo aplikace 0 a kontrakt předaného čísla

• card-id, medium, appl-id, contract-id - kontrakt na kartě předaného čísla, předaného
   typu, předaného číslo aplikace a kontrakt předaného čísla

• type - informace o typu transakce, deposit - uložení peněz na peněženku či prodej
   kupónu, pay - zaplacení penězi z peněženky či jízda na kupón, refund – vrácení části či
   celé ceny kupónu

• amount - nese objem transakce

• balance-after - zůstatek elektronické peněženky po transakci

• appl-tx-id - hodnota počítadla transakcí za kontrakt, aplikaci či kartu (jedna z možností,
   v závislosti, zda aplikace nebo kontrakt byl vydán s atributem max-tx-id nebo max-
   card-tx-id). Pokud byla elektronická peněženka vydána tak, že nepodporuje počítadlo
   transakcí, pak je atribut nepovinný

Nepovinným, ale důležitým atributem je atribut cross, který identifikuje, že tato platební
transakce (u aplikací/kontraktů typu elektronická peněženka má význam pouze u typu
transakce pay, u aplikaci/kontraktů typu kupón má význam pouze u typu transakce deposit)
je přestupní. Hodnota atributu identifikuje pomocí hodnoty počítadla transakcí za kartu,
aplikaci či kontrakt transakci, ze které byl přestup realizován. Atribut cross je tedy možné
použít pouze v případě elektronických peněženek, které používají počítadlo transakcí.

Zbývající atributy mají význam pouze u transakce typu pay (jedná se o jízdu), jsou
nepovinné a popsané u příkladu hotovostní transakce (platí pro ně stejná pravidla z hlediska
jejich případného vyžadování). Jediným doposud nezmíněným atributem je get-on-when,
který spadá do stejné skupiny, tj. je nepovinný, ale jeho hodnota může být vyžadována.
Tento atribut je používán v případě použití systému check-in / check-out kdy nese informaci
o nástupu do vozidla (atribut when nese informaci o výstupu = vznik transakce).

Vydání 3  Revize 17                     Strana 23/74
          ČSAD SVT Praha s.r.o.

          CE02-PO    CARDS – interface

Další skupinou jsou transakce na kupón, začneme dobíjecí transakcí:

    

Přeskočíme již popsané atributy, tj. tx-id, when, card-id, medium, appl-id. Atribut type již
byl také popsán, protože se jedná o dobití kupónu, má hodnotu deposit. Atributy amount,
appl-tx-id a cross mají význam popsaný u transakce na elektronickou peněženku.

Následuje atribut person-type, který je používán pro výpočet žákovské/studentské dotace
(počítá se z ceny kupónu uvedené v atributu amount) na kupón (jeho hodnoty jsou: adult -
bez dotace, child nebo student - s dotací). Tento atribut bude v budoucnu pravděpodobně
nahrazen zjišťováním hodnoty typu osoby z atributu tariff (v ukázce uveden), který se
následně stane povinným (již dnes je v některých konfiguracích vyžadován). Následuje
atribut zones, který obsahuje čísla zón, kde je kupón platný, oddělená středníkem. Pokud
kupón platí v nějakém intervalu zón a za předpokladu, že názvy zón jsou čísla, lze místo
úplného výčtu použít atribut zones-interval, který obsahuje středníkem oddělená čísla
počátku a konce intervalu zón, ve ktreých kupón platí (např. zones-interval=“301;324“
pro kupón platný v zónách 301 až 324). Platí-li kupón ve všech zónách, stačí uvést *
(zones-interval=“*“). Obdobnou informaci v případě použití zónově relačního tarifu
obsahuje atribut zone-route, který obsahuje číslo nástupní a výstupní zóny oddělené
středníkem (např. zone-route="301;324"). Hodnoty těchto atributů nemusí být uvedeny,
pokud se jejich hodnota neměnila oproti časově předcházejícímu kupónu se stejným číslem
aplikace (jedná-li se o aplikaci) či kontraktu (jedná-li se o kontrakt). Využívá se např. při
"prodloužení" platnosti kupónu v autobuse (nemění se ani zóny, ani tarif, pouze se mění
platnost do kupónu). Systém si potom tyto hodnoty získá z předcházejícího kupónu.

Posledními atributy uvedenými v příkladu jsou atributy valid-from, valid-to, které
pomáhají identifikovat, kterého kupónu se transakce týká (dobití kupónu může nastat před
platností kupónu, navíc na kartě může s daným číslem existovat více kupónů - musí ovšem
mít disjunktní intervaly platností).

U dobití nemají atributy nesoucí informaci o jízdě (departure-id, arrival-id, line,
sequence, tariff-km, get-on-when, network-id) význam a nejsou v příkladu uvedeny. V
případě více tarifů na kupónu je možné uvést vložený tag add-data, který umožňuje
definovat jednotlivé ceny a jejich tarify:

    

         
         
    

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á:

    

První uvedené atributy až po atribut appl-id jsou významově identické jako v případě
dobíjení kupónu. Typ transakce je pay, protože je kupón použit. Atribut amount určuje váhu
této jízdy na kupón oproti ostatním jízdám (např. cena jednotlivého jízdného pro daný typ
osoby). Atributy appl-tx-id, departure-id, arrival-id, line, sequence a tariff-km
jsou významově stejné jako v případě transakce na elektronickou peněženku.

Atribut voucher-issuer je požadován v okamžiku, kdy je povolené křížové dobíjení kupónů
(kupón může prodat i jiný subjekt než vydavatel karty), a obsahuje provider-id subjektu,

Vydání 3  Revize 17                     Strana 24/74
          ČSAD SVT Praha s.r.o.

          CE02-PO    CARDS – interface

který kupón prodal. Pro další zvýšení bezpečnosti systému může být vyžadována i hodnota
atributu voucher-price, který obsahuje cenu kupónu. A v neposlední řadě může být
povinný atribut previous-contract-id, který obsahuje contract-id předcházejícího
kupónu. Chybí-li dobíjecí transakce, kupón je automaticky vydáván a u transakce jízdy je
uveden atribut previous-contract-id, pak kupónu jsou nastaveny zóny a typ osoby
(běžně uváděny v atributech zones, zone-route, zones-interval, person-type či
tariff) z kupónu na stejné kartě, ve stejné aplikaci a s contract-id rovným obsahu
atributu previous-contract-id. Povinné atributy valid-from a valid-to doplňují
jednoznačnou identifikaci kupónu tak, aby bylo možné jej případně ručně vytvořit.

Zbývají atributy, které je možné použít, a nedostaly se do příkladu. První je check-id, který
obsahuje dvě čísla oddělená středníkem podobně jako atributy departure-id a arrival-
id. Významem těchto čísel je také stejný, tj. první je číslo zastávky podle CIS JŘ a druhé je
tarifní číslo zastávky. Tento atribut se používá v okamžiku, kdy není známa nástupní a
výstupní zastávka, ale pouze zastávka, kde proběhla kontrola cestujícího na platnost
jízdenky (např. na ČD). Posledním je atribut cross, který má obdobný význam jako u
elektronické peněženky, tj. identifikuje jízdenku na kterou je realizován přestup. Používá se v
případě přestupních jízdenek, které se chovají jako kupóny s krátkou platností (umožňují
přestupy). Jeho hodnotou ovšem není číslo čítače transakcí za aplikaci, ale přímo číslo
aplikace či kontraktu, ze kterého je přestup realizován.

Dalším typem transakcí jsou refund transakce, které slouží k vyplacení peněz zpět držiteli
karty a zrušení aplikace/kontraktu (tyto transakce podléhají zúčtování na rozdíl od transakcí
claim-transaction, kde se pouze nastavují atributy elektronické peněženky či kupónu). V
případě elektronické peněženky transakce vypadá následovně:

    

Transakce vypadá jako transakce typu pay. Rozdíl je v neuvádění doplňujících informací a v
možnosti neuvést atribut balance-after. Není-li uveden zůstatek (atribut balance-after)
platnost do elektronické peněženky je nastavena na 11.6.2003 (datum transakce) + doba
hájení dopravců (a čas platnosti do bude 23:59:59) - např. bude-li ve skupině, ve které je
karta vydána, nastavena doba hájení na 3 dny, pak platnost do bude nastavena na
14.6.2003 23:59:59 (to je z důvodu možnosti zablokovat peněženku a nechat rozdistribuovat
seznam zakázaných karet do všech strojků). Výhodou oproti pay transakci je, že tato
transakce může být provedena v okamžiku, kdy je elektronická peněženka zablokovaná a
nebo již neplatná (v tomto případě nesmí být uveden atribut balance-after).

Obdobné je vrácení celé nebo části ceny kupónu cestujícímu:

    

Všechny atributy mají běžný význam jako u transakcí na kupón. Speciální význam má atribut
amount, který říká kolik peněz se má odečíst z ceny kupónu (je podstatné správně uvést
sazbu DPH). Druhý je atribut new-valid-to, který umožňuje zkrátit platnost kupónu.
Platnost musí být mezi datem uvedeným v atributu when a původní platností do (je-li
transakce provedena před začátkem platnosti kupónu, pak může mít shodnou hodnotu jako
platnost od).

A nyní bychom se měli dostat k popisu transakce s více doplňkovými informacemi:

    

         

         

    

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:

    

Navíc je uveden atribut balance-after a používá-li se počítadlo transakcí za tuto
elektronickou peněženku a touto operací se změní jeho hodnota (tento příklad), pak je nutno
uvést i atribut appl-tx-id. Poslední možnost je zrušení peněženky a převod jejího zůstatku
na peněženku na jiné kartě:

    

Zde máme navíc identifikaci cílové aplikace elektronická peněženka (jednalo-li by se o
kontrakty pak přidáme atributy contract-id a target-contract-id) pomocí atributů
target-card-id, target-medium a target-appl-id. Původní peněžence je nastaven
zůstatek na 0 a její platnost do je nastavena stejně jako v případě rušení elektronické
peněženky, cílová peněženka bude mít zůstatek 1124,30. U obou peněženek je hlídáno, zda
převáděná částka je skutečně 458,80.

V případě reklamací aplikací / kontraktů typu časový kupón se situace nepatrně zkomplikuje,
ale princip je stále stejný (pro identifikaci kupónu je vyžadováno zadání atributů valid-from
a valid-to a pokud je vyžadováno posílání atributů voucher-issuer a voucher-price u
transakcí použití kupónů, pak je nutné je uvádět i u claim-transaction). Reklamační
transakce se u kupónů používá výhradně na převod kupónu, protože druhu reklamační
operací je vrácení ceny kupónu (částečné nebo úplné) a to se provádí refund transakcí:

    

Zde vidíme převod kupónu na novou kartu, při kterém jsou zkopírovány všechny atributy z
kupónu původního (pokud by byl kupón kontraktem, pak je nutno doplnit contract-id
případně target-contract-id, samozřejmě je možné kopírovat kupón kontrakt na kupón
aplikace a obráceně). V rámci kopírování kupónu na jinou kartu dojde ke zrušení kupónu na

Vydání 3  Revize 17                     Strana 27/74
          ČSAD SVT Praha s.r.o.

          CE02-PO    CARDS – interface

původní kartě (změna ceny na 0 a změna platnosti do – pokud zdrojový kupón ještě nezačal
platit pak je jeho platnost do rovna platnosti od + 1s, pokud již platí, pak datum transakce).
Převod kupónu musí být doprovázen výdejem kupónu na cílové kartě (viz kapitoly 4.2.3,
4.2.4 a 4.2.5 o vydávání aplikací). U kupónů jsme tuto situaci nijak explicitně nezmiňovali,
ale pokud dojde ke změně hodnoty počítadla za aplikaci - kontrakt (nezávisle na typu tohoto
počítadla), pak je možné jeho hodnoty poslat pomocí atributů appl-tx-id a target-appl-
tx-id. Vždy musí být uvedena cena převáděného kupónu v atributu amount. Pokud má
kupón více cen v různých tarifech, pak je možné uvést vložené add-data tagy obsahující
definici těchto cen (viz. dobíjecí transakce na kupón).

Další skupinou jsou transakce s předplacenými položkami (tzv. greenlistem). První operací je
transakce zapsání položky o dobití elektronické peněženky z greenlistu na kartu:

    

Pro tuto transakci platí podobná pravidla jako pro běžné dobíjecí transakce na elektronickou
peněženku. Pomocí atributů card-id, medium, appl-id identifikujeme elektronickou
peněženku, tx-id a when mají stejný význam jako u běžného dobití. Pokud elektronická
peněženka používá čítač transakcí pak je nutno uvést atribut appl-tx-id. Nová je hodnota
tributu type (greenlist) a atribut greenlist-id, který identifikuje položku greenlistu
zapsanou na kartu. Ostatní atributy jsou nepovinné jako u dobití elektronické peněženky.

    

Výše je transakce zapsání kupónu na kartu. Podobně jako v případě dobití elektronické
peněženky transakce obsahuje atributy tx-id, when, card-id, medium, appl-id a
contract-id, greenlist-id, type a amount (v tomto případě cena kupónu). Nově jsou
přidány atributy valid-from a valid-to, které říkají jaká je platnost kupónu. V případě
dobití kupónu z greenlistu je potřeba poslat i výdej kontratku, viz kapitola 4.2.4.

Následují reklamační transakce nad předplacenými položkami. Zde je potřeba si uvědomit
skutečnost, že greenlist je v zařízeních a pokud se provede některá z následujících
reklamačních transakcí, pak v zařízeních je stále původní greenlist, dokud se do nich
nenahraje nový. Proto je záhodno reklamační transakce realizovat pouze v případě, že
původní karta je zablokována dostatečnou dobu.

    

Tato transakce informuje clearing o tom, že předplacená položka byla zrušena a zaplacené
peníze byly vráceny zákazníkovi. Transakce je zapsána stejně jak pro zrušení dobití
elektronické peněženky tak pro zrušení prodeje kupónu.

    

Poslední transakce s předplacenými položkami je převod položky z jedné karty na druhou
(zde je nutno upozornit, že obě karty musí být vydány stejným vydavatelem). Transakce je
obdobou převodu elektronické peněženky (kupónu) z karty na kartu. Je uvedena aplikace
původní (card-id, medium, appl-id) a aplikace cílová (target-card-id, target-medium,
target-appl-id – cílové atributy nemusí být uvedeny, pokud jejich hodnota je stejná jako
hodnota zdrojová – v našem případě není nutné uvádět target-medium).

Vydání 3  Revize 17                     Strana 28/74
          ČSAD SVT Praha s.r.o.

          CE02-PO    CARDS – interface

Odpovědí na zaslání transakcí je seznam chybějících transakcí (tj. seznam období, za která
chybí data):

    
    
    
         
         

              
              
         
         ...
         
              
         
    

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ědí na zaslání transakcí je seznam chybějících transakcí (tj. seznam období, za která
chybí 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á:

    

Stačí identifikovat elektronickou peněženku a objem vracených peněz (atribut amount).
Reakcí na tuto transakci je nastavení zůstatku elektronické peněženky na 0 a platnost do
bude 11.6.2003 (datum transakce) + doba hájení dopravců (a čas platnosti do bude
23:59:59) - např. bude-li ve skupině, ve které je karta vydána, nastavena doba hájení na 3
dny, pak platnost do bude nastavena na 14.6.2003 23:59:59 (to je z důvodu možnosti
zablokovat peněženku a nechat rozdistribuovat seznam zakázaných karet do všech strojků).

Odpovědí na zaslání transakcí je seznam chybějících transakcí (tj. seznam období, za která
chybí data):

Vydání 3  Revize 17                     Strana 32/74
          ČSAD SVT Praha s.r.o.

          CE02-PO    CARDS – interface

    
    
    
         
         

              
              
         
         ...
         
              
         
    

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

    
    
    
         
         
    

Odpovědí je seznam položek (stored-item) s vygenerovanými identifikátory (greenlist-
id), které jsou unikátní v rámci každého vydavatele karet. Pokud externí program operuje
nad kartami pouze jednoho vydavatele, pak je i greenlist-id unikátní. Druhým typem
položky je not-stored-item, která identifikuje (pomocí atributu item-id a when) položku,
jenž se nepodařilo uložit a důvod (atribut reason), proč se ji nepodařilo uložit.

Specifikace DTD viz kapitola 4.2.21.14.

           4.2.11. Lokální seznam předplacených položek
                           (greenlist)

Externí program (prodejce) si může kdykoliv ověřit, které jeho položky již byly zákazníkem
vyzvednuty a které ještě ne. Složí k tomu následující dotaz:

    
    
    
         
    

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ý:

    
    
    

Vydání 3  Revize 17                     Strana 36/74
          ČSAD SVT Praha s.r.o.

          CE02-PO    CARDS – interface

Odpovědí je seznam předplacených položek za všechny systémy a vydavatele karet v nich,
kterým může operátor dobít elektronickou peněženku, případně prodat kupón na kartu
(obsahuje položky zatím na kartu nezapsané):

    
    
    
         
    

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):

    
    
    

Vydání 3  Revize 17                     Strana 39/74
          ČSAD SVT Praha s.r.o.

          CE02-PO    CARDS – interface

Clearingové centrum odpoví seznamem návrhů na zablokování vzniklých od předaného data
(atribut last-suggestion), není-li specifikováno, pak kompletním seznamem návrhů –
seznam neobsahuje již zablokované aplikace (karty):

    
    
    
         
         ...
         
    

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:

    
    
    

Odpovědí je kompletní seznam všech (i historických) subjektů clearingu, spolu s příznakem,
zda jsou aktivní a zda je možné dobíjet jimi vydané aplikace:

    
    
    
         
         
         ...
         
    

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ý:

    
    
    

Odpovědí je seznam všech subjektů (vydavatelů karet), jejichž karty může subjekt zprávu
posílající akceptovat. U každého takového subjektu je specifikováno jaké operace s jakými
typy aplikací (kontraktů) na kartě je možno provádět. Formát odpovědi se může lišit subjekt
od subjektu, především podle dodavatele zařízení. V této kapitole je uveden standardní
formát (použitelný pouze v případě použití zasílání podepsaných souborů):

Vydání 3  Revize 17                     Strana 40/74
          ČSAD SVT Praha s.r.o.

          CE02-PO    CARDS – interface

    
    
    
         
         
         ...
         
    

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:

    
    
    

Odpovědí je globální seznam zakázaných karet jako v případě odesílání lokálního seznamu
zakázaných karet (viz 4.2.7).

Specifikace DTD viz kapitola 4.2.21.23.

                   4.2.19.1. Verze bez identifikace skupiny

Je stejná jako v předchozím příkladě, akorát verze je 2.0 a ne 2.1. Odpověď dorazí také ve
verzi 2.0, tj. stejně jako v kapitole 4.2.7.1.

           4.2.20. Chyba během zpracování

Tato zpráva je zasílána v okamžiku, kdy došlo k chybě během zpracování zaslaných dat a
tato chyba je způsobena daty, která byla zpracovávána (a chyba není běžnou „aplikační
chybou"). Do této kategorie chyb patří např.:

• špatné kódování dat (nejsou v kódování, které je uvedeno v hlavičce XML souboru)

• špatný formát dat (nejsou v souladu s DTD)

• špatný obsah dat (data není možné převést na požadovaný formát, např. špatný formát
   datumu či čísla karty)

Touto zprávou nejsou posílány informace o chybách zpracování na serveru, např.
nemožnost spojit se s databází, vytvořit soubor a podobně. Tyto chyby jsou signalizovány
jiným způsobem.

Je-li posílán balík dokumentů ke zpracování, může se stát, že některá data jsou zpracována
korektně a některá ne (dokonce se na nějakém dokumentu může zpracování zastavit).

Vydání 3  Revize 17                     Strana 41/74
          ČSAD SVT Praha s.r.o.

          CE02-PO    CARDS – interface

Zpráva o chybě bude vypadat např. následovně:

    
    
    
        
    

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