Specifikace požadavků na provozování zúčtovacího centra DÚK

Příloha č. 1 ke smlouvě o poskytování služeb „Provozování zúčtovacího centra DÚK“

1. Popis systému DÚK

1.1Zónově-relační tarif a výpočet ceny jízdného

Integrovaný tarif DÚK je tarif zónově-relační. Území kraje bylo rozděleno na cca 410 tarifních zón podle pravidla obec = zóna (existují i výjimky u územně členitých obcí, které jsou rozděleny na více tarifních zón). Každá tarifní zóna má své označení třímístným číslem a názvem a je pro tarif prezentovaná vždy jednou tarifní zastávkou. Tarifní zastávky sousedních zón jsou propojeny tarifními hranami a každá hrana má délku v tarifních jednicích. Cena jízdného se odvíjí od součtu tarifních jednic mezi výchozí a cílovou zónou, v případě cesty v rámci jedné tarifní zóny je počet tarifních jednic roven 0 a pro zóny s MHD je cena stanovena separátně (a takové zóně je přiřazen i speciální počet tarifních jednic).

Pro nalezení nejnižší ceny při cestě mezi zónami se používá Dijkstrův algoritmus. Při použití různých druhů dopravy je samozřejmě možné, že se cestující nepohybuje vždy tímto nejkratším směrem a proto jsou v tarifu vytvořeny tzv. kontrolní nadzóny, které ohraničují prostor, kudy se cestující může v rámci zakoupené relace pohybovat. Kontrolních xxxxxx je stanoveno zhruba 82 a v rámci tarifu je určena tzv. matice povolených cest, která ukazuje povolené nadzóny mezi výchozí a cílovou zónou relačního jízdného.

1.2Druhy jízdních dokladů DÚK

Jízdní doklady DÚK jsou z hlediska prostorové platnosti: jednozónové,relační a síťovéJednozónová jízdenka platí v rámci jedné zóny, relační jízdenka platí z jedné výchozí zóny do jiné cílové zóny. Síťová jízdenka je pak platná na definované síti (existují jak jízdenky platné na celou síť DÚK, tak i na území DÚK + definovanou oblast v Německu).

Z hlediska časové platnosti se jízdní doklady dělí na jízdenky pro jednotlivou jízdu a na předplatní časové jízdenky. Jízdenky pro jednotlivou jízdu mají časovou platnost stanovenou v minutách (45, 90, 120, 180 atp.) od okamžiku zakoupení, která se podobně jako cena jízdného odvíjí od počtu tarifních jednic. Předplatní časové jízdenky jsou prodávány ve variantách: jednodenní (s platností do 4:00 následujícího dne), dále pak se sedmidenní, třicetidenní,devadesátidenní, stoosmdesátidenní, 365denní a roční časovou platností. Časové předplatní jízdenky umožňují neomezené cestování v relaci a v časovém období, pro které byly zakoupeny.

Z hlediska formy se jízdní doklady DÚK dělí na papírové a elektronické jízdní doklady. Obecně jsou přestupní nejen elektronické jízdenky, ale i papírové. Tarif DÚK konkrétně specifikuje, jaké jízdní doklady jsou v které formě vydávány. Elektronické jízdní doklady jsou nahrané na bezkontaktní čipové kartě DÚK.

1.3Odlišnosti tarifu DÚK v zónách s MHD

Tarif DÚK bude platit i v městských hromadných dopravách ve městech, které leží na území Ústeckého kraje. Zde tarif DÚK bude absorbovat tarify vyhlášené radami měst a zároveň přitom zohlední regule legislativy, které jsou v řadě bodů pro příměstskou a pro městskou dopravu odlišné.

Relační jízdní doklady, pokud v rámci své relace obsahují zónu s MHD, platí v rámci své časové platnosti i v této zóně s MHD. Jejich sortiment a platnost se bude plně řídit pravidly DÚK. V prostředcích MHD se bude prodávat jen velmi omezený sortiment jízdních dokladů, předplatní časové jízdenky se budou prodávat výhradně na předprodejích.

U ostatních dopravců (mimo provozovatele MHD) budou na území města jednozónové jízdní doklady uznávány dle podmínek stanovených Tarifem DÚK.

1.4Subjekty zapojené do krajského zúčtovacího centra DÚK a jejich role

Vydavatel karty – vydavatelem bezkontaktní čipové karty DÚK jsou v systému DÚK pouze někteří dopravci, kteří tuto činnost zajišťují na základě Smlouvy o veřejných službách v přepravě cestujících veřejnou linkovou dopravou k zajištění dopravní obslužnosti Ústeckého kraje. Činnost vydávání karet DÚK zahrnuje jejich vydávání jednotlivým držitelům karet na základě jejich písemné žádosti v případě osobní karty (a ústní v případě anonymní varianty karty), včetně správy jejich životního cyklu. Vydavatel je povinen čísla vydaných karet pravidelně zasílat do zúčtovacího centra. Stejně tak je povinen vydavatel karet pravidelně zasílat aktualizovaný seznam blacklistovaných karet, přičemž blacklistace karty je prováděna v situacích popsaných v Podmínkách o vydávání a užívání BČK DÚK.

Provozovatel Zúčtovacího centra DÚK – dodavatel služby – předmětu plnění, vítězný uchazeč ze zadávacího řízení. Zúčtování je zajišťováno na základě smlouvy uzavřené s objednatelem.

Objednatel – Ústecký kraj, zadavatel veřejné zakázky. Je ve smluvním vztahu s Provozovatelem ZC.

Poskytovatel služby – libovolný subjekt (např. dopravce) poskytující služby či zboží, jejichž úplata je zúčtována v ZC. Je ve smluvním vztahu s Objednatelem.

Kmenový poskytovatel služby – subjekt, který je s držitelem karty ve smluvním vztahu jako vydavatel (provozovatel) kartové aplikace. V případě užití elektronických peněz je jejich vydavatelem. Kmenový dopravce= vydavatel dopravní aplikace DÚK je specifickým případem v kartové aplikaci DÚK. Je ve smluvním vztahu s Objednatelem.

Držitel karty – koncový příjemce služby, v kartové aplikaci DÚK je to cestující. Je ve smluvním vztahu s poskytovatelem služby, případně kmenovým poskytovatelem služby.

Model Zúčtovacího centra není statický a v průběhu plnění může docházet ke změně poskytovatelů služby, případně k zavádění nových poskytovatelů služeb.

1.5Bezkontaktní čipové karty v integrovaném dopravním systému DÚK

V DÚK budou primárně používány bezkontaktní čipové karty DÚK- Mifare DESFire EV 1 8 kB. Bezkontaktní čipová karta DÚK:

• bude sloužit jako elektronická peněženka a nosič integrovaného jízdního dokladu u všech dopravců DÚK

• osobní BČK – je vydána konkrétnímu držiteli. Je opatřena fotografií držitele, jménem a příjmením držitele a logickým číslem karty;

• anonymní BČK – není vydána konkrétnímu držiteli. Je opatřena pouze logickým číslem karty.

Dopravci v systému budou vystupovat jako správci aplikace DÚK na multifunkční kartě a zároveň jako vydavatelé elektronických peněžních prostředků dle zákona o platebním styku. Tato role je obecně nazývána „kmenový dopravce“, případně vydavatel karty. Svého vydavatele karty si cestující volí již při podávání žádosti o vydání karty respektive žádosti o aktivaci aplikace DÚK s ohledem na to, kterého dopravce má nejlépe dostupného pro řešení případných reklamací či jiných problémů spojených s použitím karty v dopravě. Kmenovým dopravcem nemusí nutně být všichni dopravci zapojení v DÚK, není to podmínkou.

Dopravci provozující veřejnou linkovou autobusovou dopravu v Ústeckém kraji budou pro odbavování cestujících používat odbavovací systémy, které zvládnou odbavení cestujících na Tarif DÚK v hotovosti či prostřednictvím bezkontaktní čipové karty Mifare DESFire EV1 8kB. Nástup cestujících bude vždy předními dveřmi a řidič bude provádět kontrolu a prodej jízdních dokladů.

Vedle BČK DÚK jsou dopravci (zejména dopravci MHD) oprávněni využívat i své vlastní bezkontaktní čipové karty. Vlastní čipové karty dopravců, které nejsou kartami BČK DÚK, budou v rámci DÚK sloužit pouze jako nosiče peněz, prostřednictvím kterých lze uhradit papírový jízdní doklad DÚK. Tyto tržby budou z pohledu zúčtovacího centra evidovány jako hotovostní transakce.

1.6 Vstupy do systému Zúčtovacího centra DÚK

Vstupními daty do systému Zúčtovacího centra DÚK jsou:

1.6.1 Transakční data

1. Transakční data z prodejních a odbavovacích zařízení jsou zasílána do ZC ve většině případů ve stanoveném formátu (viz Příloha č.1_b)- podrobněji viz kapitola 1.6.2. Akceptačním zařízením mohou být obecně jakákoliv zařízení, které slouží k prodeji zboží či služeb či validaci jízdního dokladu (elektronického), podstatné je, aby zařízení bylo schopno dodávat transakční data (dále jen transakce) ve stanoveném formátu a v případě kartové aplikace DÚK i dle principů zúčtování uvedených v Příloze č. 1a. Jsou to zejména:

o Transakce o prodeji papírových i elektronických jízdních dokladů;

o Transakce související s odbavením cestujících ve veřejné dopravě, tj. prodej elektronické a papírové jízdenky či časového kupónu zakoupených prostřednictvím karty BČK DÚK, prodej jízdenek v hotovosti či na jinou kartu mimo kartovou aplikaci a systém BČK DÚK;

o Transakce související s prodejem zboží nebo služeb souvisejících se systémem BČK DÚK (jízdní řád, poplatek za služby na kartě);

o Transakce související s odbavením cestujících v kartové aplikaci BČK DÚK v podobě validace/akceptace platných elektronických jízdních dokladů;

o Dobití (vybití bez prodeje služby) elektronické peněženky.

o Systém musí být připraven i na zpracování dat o prodeji SMS jízdenek, které budou dodávány z backoffice pro zpracování SMS jízdenek jednotlivých dopravních podniků. Tato data nejsou v současné době zpracovávána, avšak ZC na ně musí být připraveno.

o Systém musí být připraven i na zpracování dat o použití bezkontaktní platební karty (nejen pro platbu, ale později možná i jako identifikátoru k prokázání nároku na čerpání služby- za předpokladu, že identifikátor včetně služby bude uveden v backoffice), které budou dodávány z jednotlivých odbavovacích systémů. Tato data nejsou v současné době zpracovávána, avšak ZC na ně musí být připraveno.

Jedná se tedy o transakce související jak s odbavovacím systémem veřejné dopravy, tak i o libovolné jiné transakce standardního formátu. Formát dat je uveden v Příloze č. 1b tohoto dokumentu.

1.6.2 Transakční data zasílaná do ZC

Vedle akceptačních zařízení, která posílají do ZC transakční data ve formátu popsaném v Příloze č.1b, existují však i další kanály odbavování cestujících (např. SMS jízdenky, papírové jízdenky prodané ve stacionárních automatech), kdy se nepracuje s BČK DÚK a kdy zařízení/systémy nejsou po HW ani SW stránce připraveny na zasílání dat do ZC DÚK. Způsob zasílání těchto dat je pak dohodnut individuálně. Nejčastěji provozovatelé těchto systémů zasílají měsíční přehledy s počtem prodaných jízdenek v dané ceně.

1.6.3 Transakční data dopravní aplikace DÚK

V následujících řádcích jsou detailně popsaná data z prodejních a odbavovacích zařízení DÚK. Dodavatel ZC však musí počítat s tím, že tento výčet se v budoucnu může rozšířit o další zdroje obdobných dat. Vždy však platí, že data jsou z prodejních a odbavovacích zařízení odesílána do zúčtovacího centra ve formátu popsaném v Příloze č. 1b.

1.6.3.1 Data z odbavovacích zařízení příměstské autobusové dopravy

- Při prodeji nebo odbavení elektronického jízdního dokladu se do transakce zasílané do ZC dostane údaj o čase odbavení, typu jízdního dokladu (tj. tarifu), časové platnosti (od-do), ceně a způsobu úhrady, prodejci kuponu, vydavateli dopravní aplikace, číslu čipu karty a o relaci, pro kterou byl jízdní doklad zakoupen. Do ZC jde dále údaj o nástupní zóně cestujícího na dané lince, o číslu linky a spoje a číslu zařízení, kde k odbavení došlo.

- V případě zakoupení papírového jízdního dokladu a jeho zaplacení v hotovosti se do ZC dostane informace o čase odbavení, typu tarifu, částce, číslu linky a spoje a číslu zařízení, kde k odbavení došlo.

- V případě zakoupení papírového jízdního dokladu (pro držitele karty, pro spolucestujícího, případně jízdenky pro spoluzavazadlo), a zaplacení těchto jízdních dokladů z EP se do ZC dostane informace o čase odbavení, částce, číslu linky a spoje a číslu zařízení, kde k odbavení došlo. Dále pak informace o číslu čipu karty, vydavateli dopravní aplikace a o počátečním a konečném stavu EP (pokud bylo hrazeno z EP).

- V případě dobíjení nebo vybíjení EP (vybíjení = zaplacení jízdního dokladu prostřednictvím EP) se do ZC dostane údaj o čase, kdy k transakci došlo, číslu čipu karty, kmenovém dopravci karty a o počátečním a konečném stavu EP. Do ZC jde dále údaj o číslu linky a spoje a číslu zařízení, kde k odbavení došlo.

Při odbavení cestujícího na předprodejním místě dojde v níže uvedených případech k následujícímu:

- Při prodeji elektronického jízdního dokladu se do transakce zasílané do ZC dostane údaj o typu jízdního dokladu (tj. tarifu), časové platnosti (od-do), ceně a způsobu platby, prodejci kuponu, vydavateli karty, číslu čipu karty a o relaci, pro kterou byl jízdní doklad zakoupen. Do transakce jde rovněž údaj o číslu zařízení, kde k odbavení došlo.

- V případě zakoupení papírového jízdního dokladu a zaplacení tohoto jízdního dokladu z EP se do ZC dostane informace o částce a číslu zařízení, kde k odbavení došlo. Dále pak informace o číslu čipu karty, kmenovém dopravci karty a o počátečním a konečném stavu EP. V případě hotovostní úhrady pak součástí nebude číslo čipu karty.

- V případě dobíjení nebo vybíjení EP (vybíjení = zaplacení dokladu prostřednictvím EP) se do ZC dostane údaj o čase, kdy k transakci došlo, číslu čipu karty, kmenovém dopravci karty a o počátečním a konečném stavu EP. Do ZC jde i informace o čísle zařízení, kde k transakci došlo.

1.6.3.2 Data z odbavovacích zařízení městské hromadné dopravy

Ve vozidle:

- Při prodeji nebo odbavení elektronického jízdního dokladu se do transakce zasílané do ZC dostane údaj o typu jízdního dokladu (tj. tarifu), časové platnosti (od-do), ceně, prodejci kuponu, kmenovém dopravci karty, číslu čipu karty a o relaci, pro kterou byl jízdní doklad zakoupen. Do ZC jde dále údaj o zóně, kde se cestující na dané lince odbavil, o číslu linky a spoje a číslu zařízení, kde k odbavení došlo.

- V případě zakoupení papírového jízdního dokladu a jeho zaplacení v hotovosti (za předpokladu, že jízdní doklad vydá odbavovací zařízení), se do ZC dostanou informace o typu jízdního dokladu, časové platnosti (od-do), ceně, prodejci jízdního dokladu a relaci, pro kterou byl doklad vydán.

- Do ZC se rovněž nebudou dostávat informace o počtu jízdenek označených v označovacích ve vozidle (označují se pouze papírové jízdní doklady zakoupené v trafikách a v doplňkovém prodeji u řidiče). Naopak se počítá s tím, že do ZC se budou zasílat informace o jízdních dokladech zakoupených prostřednictvím sms zprávy případně aplikace SEJF.

- V případě zakoupení papírového jízdního dokladu pro spolucestujícího a zaplacení tohoto jízdního dokladu z EP se do ZC dostane informace o částce, číslu linky a spoje a číslu zařízení, kde k odbavení došlo. Dále pak informace o číslu čipu karty, kmenovém dopravci karty a o počátečním a konečném stavu EP.

Na předprodejních místech dopravce:

- Při prodeji elektronického jízdního dokladu a papírového dokladu placeného z EP se do transakce zasílané do ZC dostane údaj o typu jízdního dokladu (tj. tarifu), časové platnosti (od-do), ceně, prodejci kuponu, kmenovém dopravci karty, číslu čipu karty a o relaci, pro kterou byl jízdní doklad zakoupen. Do transakce jde dále údaj o číslu zařízení, kde k odbavení došlo. V případě papírového jízdního dokladu placeného hotovostně jsou uvedeny a do ZC zasílány všechny výše uvedené informace s výjimkou čísla čipu karty.

- V případě dobíjení nebo vybíjení EP (vybíjení = zaplacení dokladu prostřednictvím EP) se do ZC dostane údaj o číslu čipu karty, kmenovém dopravci karty a o počátečním a konečném stavu EP. Do ZC jde i informace o čísle zařízení, kde k transakci došlo.

1.6.3.3 Data z odbavovacích zařízení drážní dopravy

Ve vozidle (při odbavení u průvodčího ve vlaku na přenosných pokladnách):

- V případě zakoupení papírového jízdního dokladu a jeho zaplacení v hotovosti, se do ZC zasílají informace o čase odbavení, čísle vlaku, o zónách, pro který byl jízdní doklad zakoupen a o ceně jízdního dokladu. Do ZC není zasíláno číslo tarifu (což se projeví v některých sestavách IDS).

Na předprodejních místech dopravce:

- V případě zakoupení papírového jízdenky a hotovostní platby tohoto jízdního dokladu se do ZC dostane informace o částce, čase a číslu zařízení, kde k odbavení došlo. A o zónách, pro které byl jízdní doklad vydán.

1.6.3.4 Data z odbavovacích zařízení využívaných na turistických linkách (lodě, vlaky)

1.6.4 Globální seznamy karet a zařízení

Do zúčtovacího centra vstupují tyto seznamy:

- Seznamy inicializovaných kartových aplikací a jejich aktualizace. Tyto seznamy se importují přírůstkově (dávkově) ve stanovené periodě z backoffice jednotlivých vydavatelů karet,

- Seznamy blokovaných karet a blokovaných aplikací (blacklisty). Tyto seznamy se importují v celém obsahu ve stanovené periodě z backoffice jednotlivých vydavatelů karet, kteří mají možnost jimi vydané karty i blokovat;

- Seznamy zařízení včetně blokovaných zařízení, případě seznamy SAM v zařízeních. Tyto seznamy se generují od dopravců.

1.6.5 Statická data

Za statická data vstupující do Zúčtovacího centra se považují např. tarifní data a ceníky, popis tarifního systému DÚK.

1.6.6 Soubor pravidel

Vstupem do Zúčtovacího centra je popis principů zúčtování, který je uveden v Příloze č. 1a tohoto dokumentu včetně svých příloh. Správcem dokumentu je Odbor dopravy a silničního hospodářství Ústeckého kraje, dokument je možné průběžně měnit.

Systém elektronického odbavování cestujících v DÚK není statický. V průběhu plnění může docházet k zavedení nových kanálů elektronického odbavování cestujících (např. platba pomocí bezkontaktní platební karty, zavedení časových kuponů uložených v backoffice, které jsou pouze svázány s číslem bezkontaktní platební karty, aj.).

2. Základní požadavky na funkce zúčtovacího centra

Součástí předmětu zakázky je vedle samotného vytvoření a zajištění provozu Zúčtovacího centra DÚK, do něhož bude zapojeno maximálně 25 poskytovatelů služeb i následující:

• Implementace řešení, jejíž součástí je kromě jiného:

- Zapojování nových dopravců DÚK do Zúčtovacího centra DÚK (testování dat, smluvní zapojení dopravce, procesní zapojení dopravců, aj.)

- Aktualizace dokumentu Principy zúčtování DÚK

• Konzultační činnost po celou dobu plnění související s aplikací legislativy, na kterou je zúčtovací centrum navázáno (zejména jde o Zákon 101/2000 Sb., Zákon 284/2009 Sb. ve znění pozdějších předpisů; Zákon 89/2012 Sb.), a poskytování konzultací v oblasti interpretace výsledků zúčtování

• Publikování dat potřebných pro zajištění Dynamického portálu zúčtovacího centra (samotná dodávka Dynamického portálu zúčtovacího centra není předmětem této zakázky)

2.1 Požadované funkce zúčtovacího centra

2.1.1 Systémové

- Soulad s platnou legislativou, zejména Zákon 101/2000 Sb. (o ochraně osobních údajů), Zákon 284/2009 Sb. (O platebním styku), Zákon 89/2012 Sb. (nový občanský zákoník);

- Práce s různými sazbami DPH v souladu s aktuálně platnou legislativou;

- Komunikace s jinými zúčtovacími centry jiných kartových systémů a IDS formou definovaného a oboustranně odsouhlaseného datového rozhraní;

- Komunikace prostřednictvím definovaného rozhraní s kterýmkoliv výrobcem odbavovacího zařízení;

- Práce s UID karet Mifare( DESFire EV1, Mifare Classic);

- Práce s dalšími jedinečnými čísly nosičů produktů dopravní aplikace DÚK (např. tokeny do nichž jsou zašifrována čísla bezkontaktních platebních karet, atd.);

- Možnost zavádět různé uživatele, přiřazovat role a definovat jejich přístupová práva;

- Poskytnutí uživatelských a provozních manuálů a online kontextově orientované nápovědy ve webových aplikacích.

2.1.2 Provozní

- Zpracování dat obdržených od zapojených subjektů a distribuce definovaných dat jednotlivým subjektům. Pro komunikaci mezi subjekty a zúčtovacím centrem musí být použit zabezpečený protokol zajišťující integritu a důvěrnost dat;

- Pravidelné měsíční rozúčtování tržeb subjektů včetně přípravy podkladů pro převádění částek mezi dopravci;

- Provoz centrálního úložiště definovaných seznamů, číselníků a sestav (např. centrální blacklist karet a SAM, centrální whitelist karet a aplikací, seznam zařízení, aj.) a dále pak aktualizace a distribuce těchto centrálních seznamů;

- Provoz Zúčtovacího centra minimálně s těmito požadavky:

o Import výstupních dat z prodejních a odbavovacích systémů ve formátu dle Přílohy č.1b;

o Zúčtování elektronické peněženky s libovolným typem transakce (dopravní/nedopravní);

o Kontrola transakcí ze zařízení- kontrola konzistence dat, kontinuity transakcí a obsahu transakcí

o Evidence a rozúčtování transakcí realizovaných z EP;

o Evidence a rozúčtování hotovostních transakcí provedených na prodejních a odbavovacích zařízeních, pokud k nim dochází a jsou transakčně zpracovány;

o Evidence transakcí jiných karet než bezkontaktních čipových karet, pokud k nim dochází a jsou transakčně zpracovány;

o Provádění kontroly integrity a správnosti vstupních dat (úplnost, spojitost) včetně automatického reportingu na definovaný okruh subjektů v případě nalezení problémů;

o Určení a poskytování přesných podkladů pro vyrovnání vzájemných závazků mezi prodejci a poskytovateli služby navzájem;

o Zpřístupnění pouze nezbytných dat všem subjektům zapojených do ZC v souladu s jejich rolemi a přístupovými právy, přičemž objednatel má přístup neomezený;

o Provádění každodenního zpracování dat a reporting o neshodách v zaslaných datech a o datech nedodaných;

o Vytváření a zveřejňování podkladů pro účetní doklady a statistiky;

o Urgování subjektů zúčtování za nedodaná data formou notifikace e-mailem případně telefonem;

o Měsíční souhrny nespojitosti předávaných dat po dopravcích, resp. subjektech zúčtování (nezpracované transakce, chybějící odpočty, neaktivní zařízení, pozdě dodané transakce, blokované karty, neznámé karty….);

o Automatizované zpracování reklamačních transakcí;

- Provoz webového portálu Zúčtovacího centra pro uživatelský přístup protokolem https v různých rolích, které jsou dále popsány. Na portálu, který musí být online přístupný v režimu 24/7 (s výjimkou krátkodobých odstávek systému za účelem zajištění správy systému) jsou umístěna především:

o výstupní data systému z periodických rozúčtování (sestavy);

o online informace pro subjekty zúčtování v rolích Objednatel, Poskytovatel/Kmenový poskytovatel služby s cílem umožnit jim:

▪ kontrolu integrity a úplnosti poskytovaných dat z prodejních a odbavovacích zařízení;

▪ průběžné sledování celkové částky závazků vydavatelů elektronických peněz vyplývající z nevypořádaných částek vydaných elektronických peněz;

▪ filtrované informace např. za zařízení (transakce,…);

o dokumenty zúčtovacího centra (manuály, principy zúčtování, statická vstupní data – číselníky);

- Kontrolní mechanismy nad vstupními a výstupními daty a systémem zúčtování:

o Kontrola návazností na minulý měsíc (např. zařízení, zůstatky EP);

o Kontrola údajů v měsíční bilanci na rozpad v jednotlivých dalších statických sestavách;

o Nestandardní stavy systému:

▪ Nespojitý účet EP;

▪ Chybějící dobití/vybití pro případ nespojitého účtu EP;

▪ Podezřelé transakce (velké objemy v Kč na EP, velké počty transakcí na EP)

o Nedodaná nebo pozdě dodaná data po termínu dle principů zúčtování, Příloha č. 1a

o Další zprávy o chybách během zpracování;

- Logování všech přístupů na portál Zúčtovacího centra ve všech rolích s možností přiřadit různým rolím různá oprávnění;

Provozovatel zúčtovacího centra bude zpracovávat i data dodaná po termínu dodání definovaných dle principů zúčtování DÚK. Tyto pozdě dodané transakce (nezpracované v měsíci, do kterého dle data vytvoření transakce patří) budou dohledávány a zpracovávány v následujících měsících a budou reportovány formou speciální sestavy.

2.1.3 Dopravní

- Evidence transakcí check-in s jednotlivými typy elektronických jízdních dokladů v zónách s MHD (jednotlivá jednozónová jízdenka pro zónu s MHD, předplatní časová jednozónová jízdenka pro zóny s MHD, jednotlivá a časová předplatní mezizónová jízdenka);

- Evidence nákupů jízdních dokladů ve všech zastávkách pro konkrétní linky a spoje (všechna data s výjimkou předprodejních míst);

- Práce se daty o zónově relačním tarifu, cenách, časových platnostech;

- Rozúčtování tržeb z prodeje jednotlivých a časových předplatních jízdních dokladů DÚK v papírové i elektronické podobě (v podobě elektronického zápisu na BČK DÚK) bez ohledu na způsob úhrady (elektronicky, hotovost, platba pomocí bezkontaktní platební karty) dle stanovených Principů zúčtování, které jsou uvedeny v Příloze č.1a tohoto dokumentu.

- Rozúčtování dotací k jízdním dokladům DÚK. Dotace se automaticky dopočítává na všech linkách, dopravce si sám určí tarify, u kterých může žádat o dotaci;

- Zpracování dat z odbavovacích zařízení, která fungují ve více integrovaných dopravních systémech;

2.2Výstupy ze systému Zúčtovacího centra

Hlavním výstupem zúčtovacího centra DÚK jsou podklady o rozdělení tržeb a podklady pro vzájemnou přefakturaci tržeb mezi jednotlivými dopravci zapojenými do DÚK. Vedle toho jsou požadovány i další sestavy a přehledy a to včetně tzv. dynamických sestav, které budou zpřístupněny na portálu ZC DÚK- viz detailní popis v následujících kapitolách.

2.2.1 Automaticky generované výstupní sestavy

Výstupní data ze systému obsahují data těchto kategorií:

- Výstupní data (v tomto dokumentu nazývaná sestavy) o rozúčtování tržeb mezi prodejci a poskytovateli služeb a návazné formulářové sestavy. Tyto sestavy jsou distribuovány po skončení kalendářního měsíce elektronicky ve formátu PDF (např. faktury, měsíční bilance) nebo v XLS/CSV, jestliže je předpoklad, že se stanou vstupem do dalšího aplikačního zpracování v proprietárních SW subjektů zúčtování.

o Faktury mezi subjekty- vystavené faktury pro vzájemné vypořádání mezi subjekty. Každá vystavená faktura je současně daňovým dokladem a je uložena v pdf.

o bilance (např. objemy a počty transakcí, rozdělení transakcí podle jednotlivých vydavatelů EPP a podle toho, kdo provedl transakci na karty subjektu, které vydal EPP, zůstatky finančních prostředků na BČK po zpracování),

o bilance kupónů (přehled o definitivně rozúčtovaných částkách, částečně rozúčtovaných částkách, prodaných a nepoužitých jízdenkách),

o bilance elektronických peněženek v rámci Elektronické jízdenky (přehled všech elektronických peněženek, počáteční a koncové stavy na jejich účtech a sumarizované pohyby s možnostmi zobrazení dalších detailů),

o problémy ve zpracování (neznámé a nekryté transakce vzniklé zpracováním karet vydaných subjektem),

o zpracováním odmítnutá data (výpis transakcí s důvodem odmítnutí, např. blacklistovaná karta, neznámá karta),

o přehled chybějících dat,

o přehledy pozdě dodaných dat, tj. data dodaná po zpracování,

o přehled transakcí podle aplikací na kartě,

o podklady pro statistiku pro ČNB (počet karet vydaných za období a objem dobíjení),

o podklady pro vymáhání sankcí (za pozdě dodaná data),

Součástí výstupních sestav budou i výstupní sestavy pro zadavatele. Minimální rozsah těchto výstupních sestav pro zadavatele je uveden v Příloze č. 1c.

Výstupní sestavy budou vydávány měsíčně se souhrnnými vyrovnávacími doklady mezi dopravci. Zúčtovací centrum provede vždy nejpozději k 10. kalendářnímu dni (případně prvnímu následujícímu pracovnímu dni) v měsíci zúčtování za měsíc předchozí, nejpozději 11. kalendářní den (případně první následující pracovní den) vydá všechny souhrnné vyrovnávací doklady, které rozešle dopravcům pro vzájemné vyrovnání tržeb.

Aby jednotliví uživatelé mohli s těmito statistikami dále pracovat a archivovat je, je nutné tyto soubory ukládat v běžných formátech, např. *.xls, *.rtf, *.csv nebo *.pdf.

2.2.2 Podklady pro Dynamické výstupy

Objednatel má v plánu v budoucnu zprovoznit tzv. Dynamický portál zúčtovacího centra, který umožní dynamické zobrazování vybraných dat za zvolené období.

Portál zúčtovacího centra by pak měl např. umožnit zobrazit počet prodaných jízdních dokladů pro relaci A-B ve zvoleném období, u zvoleného dopravce v rozlišení dle nosiče jízdního dokladu a typu tarifu.

Za tímto účelem musí provozovatel zúčtovacího centra na svém webu zpřístupňovat budoucímu dodavateli Dynamického portálu zúčtovacího centra potřebná data a to ve formě připravených sestav, kdy přesný formát těchto sestav (pravděpodobně xml případně csv) bude definován dodavatelem Dynamického portálu zúčtovacího centra.

Data ve formě připravených sestav budou publikována vždy spolu s ostatními pravidelnými měsíčními výstupy 11.den následujícího měsíce následujícím po měsíci, za něž jsou data zpracována.

Provozovatel zúčtovacího centra musí dodavateli Dynamického portálu zúčtovacího centra poskytnout veškerou součinnost v rámci přípravy formátu a obsahu sestav. Součástí těchto sestav budou pouze informace, které jsou součástí výstupních dat z odbavovacích systémů dopravců a jsou tedy obsažena v dokumentu Cards interface, který tvoří Přílohu č.1b této specifikace.

Provozovatel zúčtovacího centra na výzvu Objednatele jednorázově vytvoří sestavy pro Dynamický portál zúčtovacího centra za období od 1. 1.2015 do 31. 12. 2016.

2.3 Zúčtovací modul

Základem rozúčtování tržeb z jízdného DÚK je statistický model. Algoritmus rozdělení tržeb mezi poskytovateli služeb (dopravce) vychází z Přílohy č.1a Principy zúčtování. Pro rozúčtování tržeb z jízdného není důležité, kolikrát a kde se daný jízdní doklad použil.

2.4 Uživatelský interface portálu ZC

Uživatelský interface portálu ZC je postaven na moderním intuitivním webovém designu a poskytuje dostatečnou záruku pro autorizovaný přístup v jednotlivých rolích:

- Poskytovatel služby (dopravce – export/import dat, přehled karet, seznamy odbavovacích zařízení v DÚK, výstupy – statická i dynamická data data)

- Objednatel (přehled o chybějících datech a odpočtech, přehled karet, odbavovací a prodejní zařízení v DÚK, Sestavy - statická data)

Přístupy uživatelů k datům jsou dány jejich rolemi. Uplatňuje se pravidlo, že s výjimkou Objednatele případně jím pověřené osoby jsou přístupy k datům omezeny na nezbytnou míru, kterou subjekt potřebuje pro svoji činnost.

2.5 Přenosy dat

Datové přenosy mezi jednotlivými subjekty a Zúčtovacím centrem jsou zabezpečeny ve třech aspektech bezpečnosti informačních technologií, tj. integrita, nepopiratelnost a důvěrnost.

Integrita dat je zabezpečena na úrovni číslování transakcí a je doplněna o systém elektronických podpisů se zajištěním nepopiratelnosti dat.

Důvěrnost je zabezpečena použitím šifrovacích tunelů pro přenos vlastních dat (https apod.)

3. Přílohy

• Příloha č. 1a – Principy zúčtování DÚK v aktuální verzi

• Příloha č. 1b – Definice vstupních dat - Cards Interface – struktura vstupních dat (soubor CE02-PO-CARDS-Interface-3_17.pdf)

• Příloha č.1c- Definice minimálního rozsahu výstupních sestav pro zadavatele

P r i n c i p y z ú č t o v á n í v i n t e g r o v a n é m d o p r a v n í m s ys t é m u D o p r a v a X x x x x x é h o k r a j e a f u n k c e z ú č t o v a c í h o c e n t r a

Tento dokument definuje principy zúčtování používané v rámci Integrovaného dopravního systému Doprava Ústeckého kraje.

Dokument bude představován jednotlivým dopravcům zapojeným v systému Doprava Ústeckého kraje (DÚK), dodavatelům jejich odbavovacích systémů a dodavatelům zúčtovacího centra.

V případě požadavku na změny tohoto dokumentu je potřeba kontaktovat Odbor dopravy a silničního hospodářství Ústeckého kraje, který žádost na změnu posoudí a následně v případě souhlasu schválí.

1. Činnosti zúčtovacího centra integrovaného dopravního systému Doprava Ústeckého kraje

Zúčtovací centrum bude:

1.1. Provádět clearing elektronické peněženky.

1.2. Rozúčtovávat tržby z prodeje elektronických jednotlivých a časových předplatních jízdních dokladů DÚK nahraných na bezkontaktní čipové kartě Ústeckého kraje (DESFire EV1) dle stanovených principů (viz kapitola 4 Principy rozúčtování tržeb v integrovaném dopravním systému Doprava Ústeckého kraje).

1.3. Evidovat a zpracovávat hotovostní transakce z odbavovacích zařízení.

1.4. Evidovat počty check-in (tj. transakcí) s jednotlivými typy elektronických jízdních dokladů v zónách s MHD (jednotlivá jednozónová jízdenka pro zónu s MHD, předplatní časová jednozónová jízdenka pro zóny s MHD, jednotlivá a časová předplatní mezizónová jízdenka).

1.5. Přebírat lokální seznamy zablokovaných dopravních aplikací (black listy) od jednotlivých vydavatelů karet. Okamžikem zpracováním lokálního black listu se změny projeví na black listu globálním.

1.6. Zpřístupňovat aktuální globální seznamy (black listy) zablokovaných karet a dopravních aplikací a umožňovat tak dopravcům jejich stažení a nahrání do odbavovacích zařízení.

1.7. Publikovat na svém serveru aktuální verzi dokumentu Principy zúčtování DÚK.

1.8. Zpřístupňovat na základě dohodnutých pravidel předprodejním místům dopravců informace o časovém předplatném jízdném a zůstatku financí v elektronické peněžence na konkrétní kartě.

1.9. Zpřístupňovat podklady pro finanční vyrovnání na základě daňových dokladů ve formátu pdf jednotlivým dopravcům a Odboru dopravy Ústeckého kraje v dohodnutých termínech.

1.10. Zajišťovat podklady pro finanční vyrovnání na základě daňových dokladů tak, aby každý účastník clearingu mohl vyrovnávat své pohledávky vůči ostatním účastníkům clearingu po každé závěrce.

1.11. Poskytovat statistické přehledy na linky zahrnuté v DÚK, spoje, tarify a relace zóny.

1.12. Zúčtovací centrum bude poskytovat dopravcům a objednatelům výstupy pro dopravce a další účastníky zúčtování.

1.13. Zúčtovací centrum bude poskytovat dopravcům údaje nezbytné k řešení reklamací.

1.14. Dopravci jsou povinni zasílat transakce do zúčtovacího centra nejpozději do 10. kalendářního dne od vzniku transakce. Transakce vzniklé předposlední a poslední den kalendářního měsíce je nutné odeslat rovněž nejpozději do 9. kalendářního dne následujícího měsíce. Toto ustanovení se týká dat z elektronických odbavovacích systémů ve vozidlech a na předprodejních místech. Transakce z odbavovacího systému o prodeji papírových jízdních dokladů placených hotově budou nad rámec výše uvedeného zpracovány i v případě, že budou poslány po 10. kalendářním dnu od vzniku transakce. I v tomto případě je vhodné, aby byla transakce do zúčtovacího centra doručena nejpozději do 9. kalendářního dne následujícího měsíce. Pokud bude transakce o papírové jízdence dodána po tomto termínu, bude zúčtována v rámci aktuálního účetního období, ve kterém bude dodána. Tržby z pozdě dodaných transakcí o prodeji papírových jízdních dokladů se budou zúčtovávat podle pravidel uvedených v bodech 4.2, 4.3 a 4.4. Zároveň bude informace o pozdním zúčtování jízdenky zahrnuta do příslušného reportu, který bude předán dopravci v rámci měsíční uzávěrky spolu s podklady pro zúčtování.

1.15. Dopravce je povinen zaslat jednou měsíčně do zúčtovacího centra (nejpozději však do 9. kalendářního dne následujícího měsíce) informaci o svých celkových tržbách na linkách zahrnutých v DÚK za papírové jízdenky prodané alternativními kanály (stacionární automaty, doplňkový prodej předtištěných papírových jízdenek u řidičů, v trafikách, SMS jízdenky, SEJF, aj.). Tyto tržby musí být vykazovány po jednotlivých tarifech.

1.16. Při zúčtování transakcí bere zúčtovací centrum v úvahu pouze transakce dodané dle termínů specifikovaných v bodě 1.14 a 1.15. Na data došlá po termínu nebude brán zřetel. Podklady pro měsíční zúčtování budou zúčtovacím centrem jednotlivým dopravcům předány 10. dne následujícího měsíce za měsíc předchozí (případně následující pracovní den, je-li 10. den nepracovní).

2. Popis zdrojů informací, se kterými pracuje zúčtovací centrum

Zdroje informací pro rozúčtování jízdních dokladů jsou:

2.1. Data o prodeji/odbavení jízdenek z odbavovacích systémů ve vozidlech

2.2. Data o prodeji jízdních dokladů z odbavovacích zařízení umístěných na předprodejních místech dopravců

2.3. Dokument „Struktura Tarifu ÚK“

2.4. Centrální blacklist (seznam blokovaných karet v rámci DÚK) dopravních aplikací na bezkontaktních čipových kartách Ústeckého kraje

2.5. Centrální whitelist (seznam vydaných karet v rámci DÚK) dopravních aplikací na bezkontaktních čipových kartách Ústeckého kraje

2.6. Seznamy odbavovacích zařízení, která mohou vydávat a akceptovat jízdní doklady DÚK a pracovat s elektronickou peněženkou na bezkontaktní čipové kartě Ústeckého kraje.

3. Odbavení cestujících, prodej jízdních dokladů IDS ÚK

3.1. Způsob odbavení cestujících s jízdním dokladem IDS ÚK v jednotlivých druzích veřejné osobní dopravy.

3.1.1. Železniční osobní doprava, dopravce ČD, a.s.

3.1.1.1. Cestující se v prostředí ČD odbavuje pouze prostřednictvím papírového jízdního dokladu. Elektronickou peněženku, ani elektronický jízdní doklad na BČK Ústeckého kraje není možné v prostředí ČD použít.

3.1.1.2. Prodej papírových jízdních dokladů DÚK – v osobních pokladnách obsazených železničních stanic pomocí odbavovacích zařízení ČD (UNIPOK).

3.1.1.3. Prodej papírových jízdních dokladů DÚK ve vlacích prostřednictvím přenosné osobní pokladny (mimo obsazenou stanici bez přirážky k jízdnému).

3.1.1.4. Kontrola papírových jízdních dokladů DÚK ve vlacích – provádí pověřený zaměstnanec dopravce.

3.1.2. Železniční osobní doprava, dopravce, dopravce GW Train Regio a.s.

3.1.2.1. Prodej a kontrola papírových a elektronických jízdních dokladů DÚK provádí průvodčí. Cestující je tedy odbaven vždy.

3.1.3. Veřejná linková autobusová doprava

3.1.3.1. Prodej a kontrola papírových a elektronických jízdních dokladů DÚK provádí řidič. V autobusech je povinný nástup předními dveřmi, cestující je tedy odbaven vždy.

3.1.4. Městská hromadná doprava v zóně Teplice

3.1.4.1. Prodej a kontrolu papírových a elektronických jízdních dokladů DÚK provádí řidič. Ve vozidlech je povinný nástup předními dveřmi, cestující je tedy odbaven vždy.

3.1.5. Městská hromadná doprava v zóně Ústí nad Labem

3.1.5.1. Prodej papírových jízdních dokladů DÚK – v předprodejních místech Dopravního podniku města Ústí nad Labem a.s., v automatech na výdej jízdenek, které jsou umístěny na vybraných zastávkách městské hromadné dopravy, u velkoodběratelů a v doplňkovém prodeji u řidiče (dle platného tarifu).

3.1.5.2. Kontrolu papírových jízdních dokladů DÚK provádí řidič a zaměstnanci přepravní kontroly na základě platného tarifu. Ve vozidlech je povinný nástup předními dveřmi, u autobusových linek celodenně, u trolejbusových linek od 20:00 do 04:00 hodin.

3.1.6. Městská hromadná doprava v zóně Děčín

3.1.6.1. Prodej a kontrolu papírových a elektronických jízdních dokladů DÚK provádí řidič. Ve vozidlech je povinný nástup předními dveřmi, cestující je tedy odbaven vždy.

3.1.7. Městská hromadná doprava v zóně Chomutov a Jirkov

3.1.7.1. Prodej a kontrolu papírových a elektronických jízdních dokladů DÚK provádí řidič. Ve vozidlech je povinný nástup předními dveřmi, cestující je tedy odbaven vždy.

3.1.8. Městská hromadná doprava v zóně Varnsdorf

3.1.8.1. Prodej a kontrolu papírových a elektronických jízdních dokladů DÚK provádí řidič. Ve vozidlech je povinný nástup předními dveřmi, cestující je tedy odbaven vždy.

3.1.9. Turistické linky

3.1.9.1. Prodej a kontrola papírových a elektronických jízdních dokladů DÚK – provádí řidič nebo průvodčí. Cestující je tedy odbaven vždy.

3.2. Prodej jízdních dokladů

3.2.1. Předpokládá se nejen křížové dobíjení elektronických peněženek, ale i křížové vydávání jízdních dokladů.

4. Principy rozúčtování tržeb v integrovaném dopravním systému Doprava Ústeckého kraje

4.1. Rozúčtování elektronických jízdních dokladů bez ohledu na druh jízdného1, časovou a zónovou/relační platnost

4.1.1. Elektronický jízdní doklad pro jednotlivou jízdu - cena jízdného se rozdělí mezi všechny dopravce v poměru, který je uveden v tabulce č. 1 v kapitole Podklady pro rozúčtování celkových tržeb jízdného mezi jednotlivé dopravce Podklady pro rozúčtování jízdného mezi jednotlivé dopravce. Pro potřeby rozúčtování není důležitá informace, kolikrát a kde se jízdní doklad použil. K rozúčtování dojde v okamžiku prodeje. Údaje z odbavovacích systémů o použití daného jízdního dokladu slouží pouze pro vyhodnocení využívání elektronických jízdních dokladů integrovaného dopravního systému DÚK. Celková částka odpovídající sumě vybraného jízdného za elektronické jízdní doklady pro jednotlivou jízdu se pro potřeby dalšího vyrovnání smluvních závazků mezi dopravcem a Ústeckým krajem započítá do celkových tržeb dopravce. Částky se přeúčtovávají včetně DPH.

4.1.2. Elektronický časový předplatní kupon - cena jízdného se rozdělí mezi všechny dopravce v poměru, který je uveden v tabulce č. 1 v kapitole Podklady pro rozúčtování celkových tržeb jízdného mezi jednotlivé dopravce Podklady pro rozúčtování jízdného mezi jednotlivé dopravce. Pro potřeby rozúčtování není důležitá informace o použití jízdního dokladu. K rozúčtování dojde v okamžiku prodeje. Údaje z odbavovacích systémů o použití daného jízdního dokladu slouží pouze pro vyhodnocení využívání elektronických jízdních dokladů integrovaného dopravního systému DÚK. Celková částka odpovídající sumě vybraného jízdného za elektronické časové předplatní kupony se pro potřeby dalšího vyrovnání smluvních závazků mezi dopravcem a Ústeckým krajem započítá do celkových tržeb dopravce. Částky se přeúčtovávají včetně DPH.

4.2. Rozúčtování papírových jízdních dokladů bez ohledu na druh jízdného2, časovou a zónovou/relační platnost

4.2.1. Jízdenky Elbe/Labe nejsou rozúčtovávány (vždy je celá částka příjmem dopravce, který ji prodal). Jedná se o tarify č. 2606, 2609, 2638.

4.2.2. Jízdní doklady na mezistátní relaci nejsou rozúčtovávány (vždy je celá částka příjmem dopravce, který ji prodal). Navíc tarify pro tyto jízdenky nebudou součástí tarifního XML. Byla stanovena čísla tarifů, která budou pro tyto účely dopravci využívávána: 103, 203, 5303.

4.2.3. Jízdenky EuroNisa nejsou rozúčtovávány (vždy je celá částka příjmem dopravce, který ji prodal). Jedná se o tarify č. 2706, 2709, 2738.

4.2.4. Clearingové centrum rozdělí ostatní tržby za papírové jízdní doklady (ty, které byly poslány standardní cestou dle bodu 1.15 a ty, které získalo dle bodu 1.16 a nespadají do bodů 4.2.1., 4.2.2., 4.2.3. a 4.4.) dle tabulky č. 1. Toto rozúčtování probíhá včetně DPH.

4.3. Podklady pro rozúčtování celkových tržeb jízdného mezi jednotlivé dopravce

4.3.1. Tržby budou rozúčtovány váženým průměrem, kde váhy jednotlivých dopravců jsou dány tabulkou č.1.

1 Druhem jízdného se myslí jízdné pro kategorie např. dítě, žák -15, student 15-26, atd.

2 Druhem jízdného se myslí jízdné pro kategorie např. dítě, žák -15, student 15-26, atd.

Oblast	Název	Provider	Dopravce	Dílky	%
CZ0426B	MHD Bílina	135	ARRIVA TEPLICE s.r.o.	1 676 485	0,28%
CZ0426M	MHD Teplice	135	ARRIVA TEPLICE s.r.o.	52 931 236	8,86%
CZ04261	PD Teplice	135	ARRIVA TEPLICE s.r.o.	22 957 186	3,84%
CZ04262	Teplicko	135	ARRIVA TEPLICE s.r.o.	14 206 567	2,38%
CZ04223	Chomutovsko	51	Autobusy Karlovy Vary, a.s.	11 592 959	1,94%
CZ04221	Kadaň - Žatec	51	Autobusy Karlovy Vary, a.s.	17 165 745	2,87%
CZ04252	Mostecká pánev	51	Autobusy Karlovy Vary, a.s.	12 227 658	2,05%
CZ04211	Šluknovsko	51	Autobusy Karlovy Vary, a.s.	24 626 572	4,12%
CZ04212	Děčínsko	83	BusLine a.s.	19 009 048	3,18%
CZ04233	Litoměřicko	83	BusLine a.s.	15 772 721	2,64%
CZ04242	Lounsko-západ	83	BusLine a.s.	10 505 240	1,76%
CZ04231	Lovosice - Louny	83	BusLine a.s.	21 878 770	3,66%
CZ04241	Podbořansko	83	BusLine a.s.	11 679 352	1,95%
CZ04271	Ústecko	83	BusLine a.s.	26 980 619	4,51%
CZ04222	Vejprtsko	83	BusLine a.s.	12 575 972	2,10%
CZ042CDO	ČD - Os, Sp	9	České dráhy a.s., Generální ředitelství	11 560 080	1,93%
CZ042CDR	ČD - R	9	České dráhy a.s., Generální ředitelství	4 634 448	0,78%
CZ04232	Dolní Poohří	47	ČSAD Slaný a.s.	29 914 389	5,00%
CZ04251	Litvínov - Bílina	47	ČSAD Slaný a.s.	17 866 848	2,99%
CZ0421M	MAD Děčín	146	Dopravní podnik města Děčína, a.s.	56 196 168	9,40%
CZ0427M	MHD Ústí nad Labem	142	Dopravní podnik města Ústí nad Labem a.s.	201 732 187	33,75%
Celkem				000 000 000	000,00%

Tabulka č.1 Počet dílů pro stanovení poměru, ve kterém se jízdné rozúčtuje mezi jednotlivé dopravce

4.3.2. Xxxxxxx je vyhlašována ÚK minimálně s 15 denním předstihem před počátkem její platnosti (tj. tabulka se může v čase měnit).

4.3.3. Clearingové centrum do celkové bilance dopravce započte veškeré dílčí doklady (vzniklé dle bodů dle bodů 4.1.1., 4.1.2., 4.2.4 a doklady na převod elektronických peněz), čímž vznikne výsledná bilance dopravce. Do bilance dopravce se nezapočítávají doklady uvedené v bodech 4.2.1., 4.2.2., a 4.2.3. Dopravce je KÚ vykazuje mimo clearingové centrum

4.3.4. Lze předpokládat, že budou uzavírány další nové smlouvy (objížďkové smlouvy) za účelem zajištění vozidel na provoz spojů po objízdných trasách linek, které byly zahrnuty do smlouvy (hlavní) uzavřené na 10 let v dané oblasti, kde budou vydávány integrované jízdenky DÚK. Tržby budou v dané oblasti po dobu uzavírky rozdělovány mezi smlouvu objížďkovou a mezi smlouvu hlavní následujícím způsobem:

a) Průběžné rozúčtování na oblasti bude probíhat pouze v dělení na hlavní oblasti dle podílů určených v bodu 4.3.1.

b) Rozdělení tržeb mezi smlouvu hlavní a objížďkovou bude provedeno následně, a to dle poměru skutečně ujetých kilometrů vykázaných dopravcem dle smlouvy hlavní a skutečně ujetých kilometrů vykázaných dopravcem dle smlouvy objížďkové. Dopravce dodá Ústeckému kraji do 10. kalendářního dne následujícího měsíce výkaz výkonů (tj. skutečně ujeté km) za příslušný měsíc zvlášť za smlouvu hlavní a zvlášť za smlouvu objížďkovou. Ústecký kraj provede neprodleně kontrolu výkazu, sníží tržby v hlavní oblasti o tržby přiřazené k objížďkové smlouvě a upravený report „Tržby na oblasti“ zašle k vystavení na web zúčtovacímu centru.

4.4. Rozúčtování turistických linek

a) Turistické linky jsou v provozu od 25.3.2016 do 31.10.2016.

b) Turistické linky provozují dopravci:

• KŽC Doprava, s.r.o. – linka T1 (Česká Kamenice – Kamenický Šenov) a T5 (Libochovice – Mšené Lázně – Roudnice nad Labem)

• Railway Capital a.s - linka T4 (Lovosice – Most) a T6 (Kadaň – Podbořan/Radonice x Xxxxxx)

• MBM rail s.r.o. - linka T3 (Ústí nad Labem – Velké Březno – Zubrnice)

• Labská plavební společnost, s.r.o. - lodní linka č. 901 (Ústí nad Labem

– centrum – Litoměřice)

c) Dopravci na turistických linkách budou od 25.3.2016 vydávat pouze papírové jízdní doklady. Od 1.6.2016 budou vydávat i jízdní doklady na bezkontaktních čipových kartách, nabíjet i vybíjet elektronické peněženky na kartách. Nebudou vydavateli vlastních karet.

d) Jízdenky (jízdenky i kupóny) na turistických linkách nejsou rozúčtovávány (vždy je celá částka příjmem dopravce, který ji prodal).

4.5. Reklamace jízdních dokladů a elektronické peněženky

4.5.1. Reklamaci elektronických jízdních dokladů řeší držitel karty u kmenového dopravce, tj. vydavatele karty.

4.5.2. Zúčtovací centrum bude poskytovat dopravcům údaje, nezbytné k řešení reklamací

4.5.3. V případě uznané reklamace elektronického jízdného dokladu (tj. cestujícímu je vyplacena za kupón částka určená na základě pravidel uvedených v Tarifu a SPP DÚK) zúčtovací centrum vybere zpět od jednotlivých dopravců již přiznané podíly dle tabulky platné v okamžiku prodeje elektronického jízdního dokladu.

4.6. Realizace finančních toků

4.6.1. KÚ Ústeckého kraje nebude účastníkem clearingu.

4.6.2. Za prostředky uložené v elektronické peněžence v dopravní aplikaci na kartě Ústeckého kraje (BČK DESFire EV1 8kB) ručí kmenový dopravce; tj. vydavatel karty, tj. dopravce, jehož cestující vybral při vyplňování žádosti o výrobu karty a aktivaci dopravní aplikace a jehož jménem se dopravní aplikace na kartu nahrála.

4.6.3. Pokud dojde k vložení prostředků do elektronické peněženky na kartě u jiného dopravce (dopravce č.1) než dopravce kmenového, je tento finanční obnos v měsíčním zúčtování EP, ve kterém došlo ke vkladu, od dopravce č.1 převeden kmenovému dopravci.

4.6.4. Z vkladů do EP se DPH neodvádí. DPH se odvádí až v okamžiku, kdy dojde z EP k zakoupení jízdního dokladu (není dopředu jasné s jakou xxxxxx DPH bude platba z EP realizována).

4.6.5. Pokud dojde k nákupu jízdního dokladu z EP (bez ohledu na to, jestli jde o doklad elektronický nebo papírový) u jiného dopravce, než dopravce kmenového, jsou tyto prostředky v měsíčním zúčtování převedeny od kmenového dopravce k prodejci jízdního dokladu.

4.6.6. Peníze za zakoupený elektronický časový předplatní kupon drží vydavatel karty, tj. kmenový dopravce. V případě, že dojde k reklamaci kuponu, je tato za celý obsah karty uplatňována u kmenového dopravce. Manipulační poplatek, který bude cestujícímu účtovat kmenový dopravce, není předmětem clearingu.

4.6.7. Reklamace uskutečňuje držitel karty vždy u kmenového dopravce. Ten je oprávněn v případě žádosti držitele karty kupon z karty odstranit a vyplatit držiteli karty částku odpovídající zbývající hodnotě kuponu. Konkrétní podmínky možnosti vracení časových předplatních dokladů definuje Tarif a SPP Dopravy Ústeckého kraje. Již rozdělené peníze mezi jednotlivé dopravce jsou vráceny zpět kmenovému dopravci, dle tabulky platné v okamžiku prodeje kupónu.

4.6.8. DPH z prodané jízdenky odvádí vždy prodejce jízdního dokladu.

4.6.9. Zúčtovací centrum provádí zúčtování celého jízdného, tj. částky včetně DPH. Dopravci si tedy mezi sebou přefakturovávají poměrnou část z jízdného včetně DPH. Díky tomu odvede každý dopravce DPH pouze za část jízdného, které mu po rozdělení jízdného mezi dopravce zůstane.

	Jméno:	Podpis:	Účinnost od:	3. 11. 2014
Zpracoval:			Razítko:
Přezkoumal:
Schválil:

PRO INFORMACI

P o p i s

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

O B S A H

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

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

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

1 . Ú Č E L

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 Ů S O B N O S T

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 Ý Z N A M P O U Ž I T Ý C H Z K R AT E K A D E F I N I C E P O J M Ů

3 . 1 . V ý z n a m p o u ž i t ý c h z k r a t e k

Zkratka	Význam
Clearing Clearingový systém CARDS EXCHANGE CARDS
SVT
XML, DTD
HTTP
HTTPS
ISO-639
ISO-3166
ISO-8601
XML Signature
SHA1
MAD

3 . 2 . D e f i n i c e p o j m ů

3 . 2 . 1 . V y d a v a t e l k a r e t

Účastník clearingu, který vydává karty, které ostatní používají.

3 . 2 . 2 . D o p r a v c e

Účastník clearingu, který akceptuje karty k placení jízdného.

3 . 2 . 3 . S u b j e k t

Účastník clearingu (dopravce, vydavatel karet a nebo obojí současně).

3 . 2 . 4 . V l a s t n í k k a r t y

Cestující, který si nechal vydat kartu.

3 . 2 . 5 . A p l i k a c e n a k a r t ě

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 . K o n t r a k t v a p l i k a c i

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 . S k u p i n a ( 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 . T E X T P O P I S U

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 . O b e c n á s p e c i f i k a c e

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 . Z p ů s o b k o m u n i k a c e

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 . Z p r a c o v á n í z p r á 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.

4 . 1 . 3 . F o r m á t z a s í l a n ý c h z p r á 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 . Z a b e z p e č e n í z p r á v p r o t i m o d i f i k a c i

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 xxxxx, podle kterého identifikuje příjemce konkrétní klíč).

Podepsaný soubor s transakcemi vypadá:

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 . R o z h r a n í m e z i c l e a r i n g o v ý m c e n t r e m a s u b j e k t y

Tyto zprávy jsou určeny pro přímou rutinní komunikaci mezi jednotlivými subjekty a clearingovým centrem.

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 . O p e r a c e n a r o z h r a n í

Dále jsou popsány jednotlivé typy zpráv, které jsou rozhraním podporovány.

4 . 2 . 1 . 1 . V y d á n í a p l i k a c e n a k a r t ě

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 . V y d á n í k o n t r a k t u p r o M A D a p l i k a c i

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 . H r o m a d n é v y d á n í a p l i k a c í n a k a r t á c h

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 . V y d á n í k a r t y

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.

4 . 2 . 1 . 5 . L o k á l n í s e z n a m z a k á z a n ý c h k a r e t , a p l i k a c í č i k o n t r a k t ů

Úč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 . Z m ě n a p l a t n o s t i a p l i k a c e ( k o n t r a k t u ) e l e k t r o n i c k á p e n ě ž e n k a

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 . T r a n s a k c e z a z a ř í z e n í

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

• 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 ř e d p l a c e n é p o l o ž k y ( g r e e n l i s t )

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 . L o k á l n í s e z n a m p ř e d p l a c e n ý c h p o l o ž e k ( g r e e n l i s t )

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 . 1 0 . S e z n a m p ř e d p l a c e n ý c h p o l o ž e k ( g r e e n l i s t )

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.

4 . 2 . 1 . 11 . Z m ě n a l o k á l n í h o s e z n a m u z a ř í z e n í

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 . 1 2 . V y t v o ř e n í p ř í s t u p u v l a s t n í k a k a r t y d o s y s t é m u

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 . 1 3 . I n f o r m a c e o z ů s t a t k u a p l i k a c e ( k o n t r a k t u ) e l e k t r o n i c k á p e n ě ž e n k a

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 . 1 4 . S e z n a m n á v r h ů n a z a b l o k o v á n í a p l i k a c í ( k o n t r a k t ů )

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 . 1 5 . S e z n a m s u b j e k t ů c l e a r i n g u

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 . 1 6 . S e z n a m a k c e p t o v a t e l n ý c h s u b j e k t ů

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

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 . 1 7 . G l o b á l n í s e z n a m z a b l o k o v a n ý c h k a r e t , a p l i k a c í č i k o n t r a k t ů

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 . 1 8 . C h y b a b ě h e m z p r a c o v á 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 . P o p i s o b e c n ý c h a t r i b u t ů

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

4 . 2 . 3 . V y d á n í a p l i k a c e n a k a r t ě

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

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 . V y d á n í k o n t r a k t u p r o M A D a p l i k a c i

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,

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 . H r o m a d n é v y d á n í a p l i k a c í n a k a r t á c h

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.

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 . V y d á n í k a r t y

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.

4 . 2 . 7 . L o k á l n í m s e z n a m z a k á z a n ý c h k a r e t , a p l i k a c í č i k o n t r a k t ů

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.

4 . 2 . 7 . 1 . Ve r z e b e z i d e n t i f i k a c e s k u p i n y 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 . Z m ě n a p l a t n o s t i a p l i k a c e M A D n e b o a p l i k a c e ( k o n t r a k t u ) e l e k t r o n i c k á p e n ě ž e n k a

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

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 . T r a n s a k c e z a z a ř í z e n í

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í

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

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

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:

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

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:

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

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.

4 . 2 . 9 . 1 . T r a n s a k c e b e z m o ž n o s t i h o t o v o s t n í c h p o l o ž e k a s p ř e d p l a c e n ý m i p o l o ž k a m i ( g r e e n l i s t )

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:

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

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ě

Odpověď je obsahově i významově identická s verzí 3.0. Specifikace DTD viz kapitola 4.2.21.10.

4 . 2 . 9 . 2 . T r a n s a k c e b e z m o ž n o s t i h o t o v o s t n í c h p o l o ž e k

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

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

Odpověď je obsahově i významově identická s verzí 2.2. Specifikace DTD viz kapitola 4.2.21.11.

4 . 2 . 9 . 3 . T r a n s a k c e b e z m o ž n o s t i u v e d e n í p o l o ž e k

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 . Ve r z e n a d á l e p r a c u j í c í s o d p o č t y

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:

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.

Odpověď obsahuje chybějící data (jako v případě verze 2.1), ale po odpočtech:

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

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

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

Odpovědí je lokální seznam zařízení a seznam neprovedených aktivací/deaktivací:

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.

4 . 2 . 1 5 . I n f o r m a c e o z ů s t a t k u a p l i k a c e ( k o n t r a k t u ) e l e k t r o n i c k á p e n ě ž e n k a

Tato zpráva požaduje po clearingovém centru zaslání zůstatku aplikace (kontraktu) elektronická peněženka:

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 . 1 6 . S e z n a m n á v r h ů n a z a b l o k o v á n í a p l i k a c í ( k o n t r a k t ů )

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

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

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

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 . 1 9 . G l o b á l n í s e z n a m z a k á z a n ý c h k a r e t , a p l i k a c í č i k o n t r a k t ů

4 . 2 . 2 0 . C h y b a b ě h e m z p r a c o v á 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).

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 . 2 1 . D T D j e d n o t l i v ý c h z p r á v

V této kapitole jsou uvedeny DTD všech výše zmiňovaných zpráv.

4 . 2 . 2 1 . 2 0 . D T D s e z n a m u n á v r h ů n a z a b l o k o v á n í a p l i k a c í ( k o n t r a k t ů )

4 . 3 . S e r v i s n í r o z h r a n í m e z i s u b j e k t y a c l e a r i n g o v ý m c e n t r e m

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 . O p e r a c e n a r o z h r a n í

V následujících kapitolách je popis jednotlivých zpráv rozhraní.

4 . 3 . 1 . 1 . I n i c i a l i z a c e a p l i k a c e ( k o n t r a k t u ) e l e k t r o n i c k á p e n ě ž e n k a

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 . I n i c i a l i z a c e a p l i k a c e ( k o n t r a k t u ) č a s o v ý k u p ó 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

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 . I n i c i a l i z a c e a p l i k a c e ( k o n t r a k t u ) e l e k t r o n i c k á p e n ě ž e n k a

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.

4 . 3 . 3 . I n i c i a l i z a c e a p l i k a c e ( k o n t r a k t u ) č a s o v ý k u p ó n

Zprava obsahuje časové kupóny spolu s objemem projetých peněz a specifikaci :

Pro každý kupón, který chceme inicializovat, zpráva obsahuje specifikaci kupónu card-id, medium, appl-id a případně contract-id. Pro bližší specifikaci je dodána i platnost časového kupónu v atributech valid-from a valid-to. Pokud platnost není specifikována, pak se vybírá kupón platný v okamžiku udaném atributem when.

Následující další atributy kupónu: objem projetých peněz, který bude aplikaci nastaven (atribut balance) a informace o dobití kupónu (atribut deposit-amount obsahuje cenu kupónu, deposit-vat sazbu DPH a deposit-person-type specifikuje typ osoby – bližší popis těchto atributů najdete při popisu dobíjecí transakce kupónu v kapitole 4.2.9 na straně 24). Atribut when a subject-id mají stejný význam jako v při inicializaci elektronické peněženky (viz kapitola 4.3.2).

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-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.

4 . 3 . 4 . D T D j e d n o t l i v ý c h z p r á v

V této kapitole jsou uvedeny DTD všech výše zmiňovaných zpráv.

4 . 3 . 4 . 1 . D T D i n i c i a l i z a c e a p l i k a c e ( k o n t r a k t u ) e l e k t r o n i c k á p e n ě ž e n k a

4 . 4 . J a k p ř e v é s t d a t a

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 . V y d á n í k a r t y

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.

<card-issues ... >

...

<card-issue ... />

...

</card-issues>

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.

4 . 4 . 6 . P r o d e j n o v é h o p ř í p a d n ě p r o d l o u ž e n í e x i s t u j í c í h o k u p ó n u – h o t o v o s t n í p l a t b a

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

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:

4 . 4 . 8 . P r o d e j k u p ó n u p l a c e n é h o e l e k t r o n i c k o u p e n ě ž e n k o u s o k a m ž i t o u j í z d o u

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.

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 . P R AV O M O C I A O D P O V Ě D N O S T I

Vzhledem k tomu, že se jedná o popis, pravomoci nejsou uvedeny.

6 . D O K U M E N TA C E A Z Á Z N A M Y V Ý S L E D K Ů

Vzhledem k tomu, že se jedná o popis, záznamy nejsou vytvářeny.

7 . Z M Ě N O V Á S L U Ž B A

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 Ř E H L E D R E V I Z Í

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 počítadel transakcí za aplikaci a do odpovědi byla přidána platnost aplikace (atributy valid-from a valid-to).	1. 3. 2009
1	14-15	V kapitole 4.2.4 byl vylepšen popis specifikace 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. 3. 2009
1	15	V kapitole 4.2.5 byla do odpovědi přidána platnost aplikace (atributy valid-from a valid-to).	1. 3. 2009
1	17	V kapitole 4.2.8 byly opraveny chyby v požadavku (ukázka XML)	1. 3. 2009
1	20	V kapitole 4.2.9 byl k nekaretní transakci přidán nepovinný atribut amount.	1. 3. 2009
1	31	V kapitole 4.2.18.2 byly v DTD požadavku správně 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. 3. 2009
1	32	V kapitole 4.2.18.3 byly v DTD požadavku správně 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. 3. 2009
1	32	V kapitole 4.2.18.4 byla do DTD odpovědi přidána platnost aplikace (atributy valid-from a valid-to).	1. 3. 2009
1	35-37	Do DTD v kapitole 4.2.18.9 přidán atribut contract- id a atribut amount u transaction tagu.	1. 3. 2009
1	37-38	Do DTD v kapitole 4.2.18.10 přidán atribut contract-id a atribut amount u transaction tagu.	1. 3. 2009
2	14	V kapitole 4.2.4 opraven název tagu z contracts-issues na contract-issues	16. 3. 2009
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- riding-tx-id	30. 3. 2009
3	14-15	Do kapitoly 4.2.4 přidána specifikace atributu max- riding-tx-id	30. 3. 2009

Číslo revize	Strana	Provedené změny	Účinnost od
3	15-16	Do kapitoly 4.2.5 přidána specifikace atributu max- riding-tx-id	30. 3. 2009
3	20-23	V kapitole 4.2.9 přidána možnost do tagu item vložit tag add-data a dummy-transaction může obsahovat identifikaci aplikace/kontraktu a hodnotu čítače transakcí za aplikaci/kontrakt (pro případ stornování karetní transakce při použití čítače transakcí za aplikaci/kartu)	30. 3. 2009
3	32-33	Do DTD v kapitole 4.2.18.2 přidána specifikace atributu max-riding-tx-id	30. 3. 2009
3	33	Do DTD v kapitole 4.2.18.3 přidána specifikace atributu max-riding-tx-id	30. 3. 2009
3	34	Do DTD v kapitole 4.2.18.4 přidána specifikace atributu max-riding-tx-id	30. 3. 2009
3	35-36	Do DTD v kapitole 4.2.18.9 přidána možnost do tagu item vložit tag add-data a dummy-transaction může obsahovat identifikaci aplikace/kontraktu a hodnotu počítadla transakcí za aplikaci/kontrakt	30. 3. 2009
4	8	Smazána kapitola 4.2.1.4 - rušení aplikací / kontraktů (řeší se pomocí claim-transaction)	7. 5. 2009
4	15	Smazána kapitola 4.2.6 - rušení aplikací / kontraktů (řeší se pomocí claim-transaction)	7. 5. 2009
4	19	V kapitole 4.2.8 doplněno, že amount je kladné číslo	7. 5. 2009
4	22-24	V kapitole 4.2.8 doplněn popis reklamací (claim- transaction)	7. 5. 2009
4	31	V kapitole 4.2.14 opravena specifikace typů karet, které se musí specifikovat	7. 5. 2009
4	32	V kapitole 4.2.17.2 atribut valid-to je povinný.	7. 5. 2009
4	34	Smazána kapitola 4.2.17.5 - rušení aplikací / kontraktů (řeší se pomocí claim-transaction)
4	37-38	V kapitole 4.2.17.8 doplněno DTD o reklamační transakci (claim-transaction)	7. 5. 2009
4	43	V kapitole 4.2.17.17 opraveno DTD odpovědi.	7. 5. 2009
4	49	V kapitole 4.4.3 opraven popis generovaní reklamace elektronické peněženky	7. 5. 2009
5	8	V kapitole 4.2.1.2 přidáno omezení na platnost kontraktu	16. 10. 2009
5	12	V kapitole 4.2.3 opraveno jméno atributu obsahující ridding	16. 10. 2009
5	14	V kapitole 4.2.4 opraveno jméno atributu obsahující ridding	16. 10. 2009
5	18-19	V kapitole 4.2.8 tag read-out dostal nepovinný atribut last-tx-id	16. 10. 2009
5	19	V kapitole 4.2.8 přidán popis dvou nových typů dummy-transaction, tj. cancel a login.	16. 10. 2009

Číslo revize	Strana	Provedené změny	Účinnost od
5	36-37	V kapitole 4.2.17.8 do DTD k tagu add-data přidány volitelné atributy zones a zone-route a k atributu type u tagu dummy-transaction přidány 2 typy: cancel a login	16. 10. 2009
5	38-39	V kapitole 4.2.17.9 do DTD k tagu add-data přidány volitelné atributy zones a zone-route a k atributu type u tagu dummy-transaction přidány 2 typy: cancel a login	16. 10. 2009
5	39-40	V kapitole 4.2.17.10 do DTD k tagu add-data přidány volitelné atributy zones a zone-route a k atributu type u tagu dummy-transaction přidány 2 typy: cancel a login	16. 10. 2009
5	49	V kapitole 4.4.3 opraven překlep v příkladu ve verzi 2.0	16. 10. 2009
6	21	V kapitole 4.2.8 v popisu transakce jízdy na kupón byl přidán atribut previous-contract-id	1. 6. 2011
6	24	V kapitole 4.2.8 do příkladu odpovědi na nahrání transakcí verze 2.1 přidán tag processing- statistic	1. 6. 2011
6	27	V kapitole 4.2.8 do příkladu odpovědi na nahrání transakcí verze 1.9 přidán tag processing- statistic	1. 6. 2011
6	37	V kapitole 4.2.17.8 doplněno DTD pro nahrávání transakcí o atribut previous-contract-id	1. 6. 2011
6	38	V kapitole 4.2.17.8 doplněno DTD odpovědi na nahrání transakcí za zařízení o tag processing- statistic	1. 6. 2011
6	41	V kapitole 4.2.17.11 doplněno DTD odpovědi na nahrání transakcí za zařízení po odpočtech o tag processing-statistic	1. 6. 2011
7	20	V kapitole 4.2.8 byl změněn popis atributu type (smazána zakázaná volba reset a přidána volba refund)	20. 9. 2011
7	21	V kapitole 4.2.8 přidán popis kupónové transakce refund.	20. 9. 2011
7	25	V kapitole 4.2.8 změněn popis tagu processing- statistic	20. 9. 2011
7	36-37	V kapitole 4.2.17.8 upraveno DTD (atribut type a new-valid-to tagu card-transaction)	20. 9. 2011
8	20	V kapitole 4.2.8 doplněn popis pro zadání celosíťové jízdenky	1. 11. 2012
8	21	V kapitole 4.2.8 dodána možnost zaslat ke kupónu více cen v různých tarifech	1. 11. 2012
8	23	V kapitole 4.2.8 zrušení elektronické peněženky obsahuje objem vracených peněz v atributu amount	1. 11. 2012
8	23	V kapitole 4.2.8 při rušení kupónu před začátkem jeho platnosti je platnost do vždy platnost od + 1s	1. 11. 2012

Číslo revize	Strana	Provedené změny					Účinnost od
8	23	V kapitole 4.2.8 převod peněz z jedné peněženky na druhou obsahuje specifikaci převáděné částky v atributu amount					1. 11. 2012
8	24	V kapitole 4.2.8 při převodu kupónu z jedné karty na druhou je nutno v amount uvést jeho cenu					1. 11. 2012
8	24	V kapitole 4.2.8 u claim-transaction možnost specifikovat více cen u kupónu pomocí vnoření add- data tagu					1. 11. 2012
8	25-26	Smazána kapitola 4.2.8.2 obsahující formát pro zaslání dat o vydání papírového opisu kupónu na ČD					1. 11. 2012
8	36	V kapitole 4.2.17.8 do add-data tagu přidán atribut amount a claim-transaction může obsahovat vnořený add-data					1. 11. 2012
8	38-39	Smazána kapitola 4.2.17.10 obsahující DTD formátu pro zaslání dat o vydání papírového opisu kupónu na ČD					1. 11. 2012
9	17	Přejmenována kapitola 4.2.7
9	17-18	V kapitole 4.2.7 zmíněna možnost upravit platnost aplikace MAD
9	37	Přejmenována kapitola 4.2.17.7
10	12	V kapitole 4.2.3 upraven popis atributu when					1. 5. 2012
10	19-24	V kapitole 4.2.8 přidán popis atributů zones- interval a info-ids, atributy přidány do příkladů. Změněn popis atributu zones. Doplněna věta o nutnosti vydat cílovou aplikaci při převodu kupónu					1. 5. 2012
10	38-39	V kapitole 4.2.17.8 zařízení verze 2.1 info-ids.	o	doplněno atributy	DTD transakcí zones-interval	za a	1. 5. 2012
11	19	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					25. 7. 2012
11	38	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.					25. 7. 2012
12	12	V Kapitole 4.2.2 byl doplněn popis atributu network- id i o možnost uvedení u transakcí.					1. 6. 2013
12	20-21	V kapitole 4.2.8 doplněny příklady použití atributu network-id.					1. 6. 2013
12	39-40	V kapitole 4.2.17.8 doplněn atribut network-id do DTD.					1. 6. 2013
13	21	V textu doplněn výčet atributů nesoucích informaci o jízdě o network-id. V příkladu opraven atribut tarif na tariff.					27. 9. 2013
13	22	V kapitole 4.2.8 doplněn příklad použití atributu network-id v tagu add-data.					27. 9. 2013

Číslo revize	Strana	Provedené změny	Účinnost od
13	39	V kapitole 4.2.17.8 k tagu add-data doplněn atribut network-id do DTD	27. 9. 2013
14	9	V kapitole 4.2.1.6 byly doplněny možnosti zasílání transakcí	5. 9. 2014
14	18-25	V kapitole 4.2.8 je nyní popsán nejnovější způsob zasílání transakčních dat ve verzi 2.2	5. 9. 2014
14	26-27	V kapitole 4.2.8.1 je popis verze 2.1 vzhledem k verzi 2.2	5. 9. 2014
14	31	V kapitole 4.2.9 byla změněna odpověď na zaslání lokálního seznamu zařízení	5. 9. 2014
14	39-41	V kapitole 4.2.17.8 je popis DTD transactions verze 2.2	5. 9. 2014
14	41-43	V kapitole 4.2.17.9 je obsah původní kapitoly 4.2.17.8 (tj. transactions verze 2.1)	5. 9. 2014
14	53	V kapitole 4.4.1 upravena formulace ve čtvrtém odstavci	5. 9. 2014
14	54	V kapitole 4.4.2 odstraněn překlep	5. 9. 2014
14	54-55	V kapitole 4.4.5 byl dopracován popis i pro transactions verze 2.2	5. 9. 2014
14	55-56	V kapitole 4.4.6 byl dopracován popis i pro transactions verze 2.2	5. 9. 2014
14	56-57	V kapitole 4.4.7 byl dopracován popis i pro transactions verze 2.2	5. 9. 2014
15	10	Kapitola 4.2.1.6 doplněna o popis předplacených položek (greenlist)	19. 9. 2014
15	11	Přidána kapitola 4.2.1.7 o prodeji předplacených položek (greenlist)	19. 9. 2014
15	11	Přidána kapitola 4.2.1.8 o statusu předplacených položek (greenlist)	19. 9. 2014
15	11	Přidána kapitola 4.2.1.9 o zaslání předplacených položek (greenlist)	19. 9. 2014
15	26-27	Kapitola 4.2.8 doplněna o popis předplacených položek (greenlist).	19. 9. 2014
15	28-29	Přidána kapitola 4.2.8.1 o transakcích ve verzi 2.2 (de facto verze 2.1 s předplacenými položkami - greenlistem)	19. 9. 2014
15	30-31	Kapitola 4.2.8.2 změněna na popis transakcí 2.1 oproti verzi 2.2.	19. 9. 2014
15	33-34	Přidána kapitola 4.2.9 o prodeji předplacených položek (greenlist)	19. 9. 2014
15	34	Přidána kapitola 4.2.10 o statusu předplacených položek (greenlist)	19. 9. 2014
15	34-35	Přidána kapitola 4.2.11 o zaslání předplacených položek (greenlist)	19. 9. 2014
15	44-46	Doplněn popis DTD transactions 3.0 v kapitole 4.2.20.8 o předplacené položky (greenlist)	19. 9. 2014

Číslo revize	Strana	Provedené změny	Účinnost od
15	46-49	Přidána kapitola 4.2.20.9 s popisem DTD transactions 2.2	19. 9. 2014
15	52-53	Přidána kapitola 4.2.20.13 s popisem DTD store- greenlist-items 1.0	19. 9. 2014
15	53	Přidána kapitola 4.2.20.14 s popisem DTD get- greenlist-items-status 1.0	19. 9. 2014
15	53	Přidána kapitola 4.2.20.15 s popisem DTD get- greenlist 1.0	19. 9. 2014
16	5	V kapitole 3.1 změněny odkazy na u následujících zkratek: ISO-639, ISO-3166, ISO-8601, MAD	23. 10. 2014
17	9	V kapitole 4.2.1.1 bylo zrušeno předvydání kupónů	3. 11. 2014
17	9	Přidána kapitola 4.2.1.4 o vydání karty	3. 11. 2014
17	14-15	V kapitole 4.2.3 smazáno předvydání kupónu	3. 11. 2014
17	17	Přidána kapitola 4.2.6 o vydání karty	3. 11. 2014
17	35	V kapitole 4.2.11 s lokálním greenlistem přidán tag no-item	3. 11. 2014
17	41-42	V kapitole 4.2.21.2 smazáno předvydání	3. 11. 2014
17	43	Přidána kapitola 4.2.21.5 s DTD vydáním karty	3. 11. 2014
17	55	V kapitole 4.2.21.15 přidáno v DTD no-item	3. 11. 2014

P Ř Í L O H Y

Vydání Počet

/ revize listů

Název přílohy, verze

Číslo přílohy

Příloha č.1_c- Definice minimálního rozsahu výstupních sestav pro zadavatele

Výstupní sestavy pro zpracování u subjektů zúčtování

Výstupní sestavy vycházejí ze stávajících sestav. Sestavy jsou vydávány měsíčně se souhrnnými vyrovnávacími doklady mezi dopravci. Formát výstupních sestav je zvolen tak, aby se dal importovat do vlastních SW partnerů (CSV, XML, bin).

Popis sestav:

1) Bilance EP

Sestava obsahuje následující položky – Subjekt (Název vydavatele EPP), Počáteční zůstatek (Suma Počáteční zůstatků EPP na všech vydaných kartách daného vydavatele EPP), Konečný zůstatek (Suma Konečných zůstatků EPP na všech vydaných kartách daného vydavatele EPP), Dobití (Suma připsaných EPP na karty vydavatele), Vybití (Suma vybíjecích transakcích EPP realizovaných na kartách vydavatele), Reklamace (Suma reklamačních vybití EPP na kartách vydavatele), Problémy (Suma problémových dobití/vybití EPP na kartách vydavatele), Průměrný zůstatek na kartě (Podíl celkové sumy zůstatků EPP na kartách vydavatele podělený celkovým počtem platných karet vydaných týmž vydavatelem).

2) Počty karet

Sestava obsahuje následující položky – Subjekt (Název dopravce DÚK), Typ (U každého dopravce DÚK se budou zobrazovat pod touto položkou následující informace – Karty aktivní v měsíci, karty vyrobené v měsíci, zrušené karty, platné karty celkem), Počet (Konkrétní číslo pro každou podkategorii Typu).

3) Počty prodaných jízdenek

Sestava obsahuje následující položky – Subjekt (Název dopravce DÚK), Typ (Dva možné druhy – elektronické, papírové; vždy bude samostatný řádek pro každou variantu typu), Tarif (číslo tarifu), Platnost ve dnech (Počet platných dní zakoupené jízdenky, v případě jednotlivých jízdenek se vyplňuje stejně jako u jednodenních číslo 1), Linka (Číslo dané linky, na které se prodal jízdní doklad dle tarifu a typu; v případě předprodejních zařízení bude položka nevyplněna), Počet (Celkový počet prodaných konkrétních jízdních dokladů na dané lince), Tržby bez DPH (Tržby za dané jízdní doklady bez DPH), Tržby s DPH (Tržby za dané jízdní doklady včetně DPH).

4) Počty prodaných jízdenek zóny

Sestava obsahuje následující položky – Subjekt (Název dopravce DÚK),Typ (Dva možné druhy – elektronické, papírové- každý typ je zobrazen na samostatném řádku), Tarif (vybraný tarif jízd. dokladu), Zóna nástupu (Počáteční zóna), Zóna výstupu (Cílová zóna, do které byl jízdní doklad zakoupen), Počet (Počet zakoupených jízdenek pro danou kombinaci nástupní a cílové zóny a tarif), Tržby bez DPH (celkové tržby za celkový počet takových jízdních dokladů bez DPH), Tržby s DPH (celkové tržby za celkový počet takových jízdních dokladů včetně DPH).

5) Prodané jízdenky Elbe-Labe, Euro Nisa a mezinárodní jízdenky (speciální tarify 103, 203, 5303, aj.)

Sestava obsahuje následující položky – Subjekt (Název dopravce DÚK), Typ (Dva možné druhy – elektronické, papírové; každý typ je zpracován na samostatném řádku), Tarif (vybraný tarif jízd. dokladu), Platnost ve dnech (Počet planých dní zakoupené jízdenky), Linka (Číslo linky, na které byl jízdní doklad prodán), Počet (Počet prodaných konkrétních jízdních dokladů na dané lince- tj. suma jízdních dokladů stejného typu a tarifu), Tržby bez DPH (tržby za danou sumu jízdních dokladů bez DPH), Tržby s DPH (tržby za danou sumu jízdních dokladů včetně DPH).

6) Storno počty

Sestava obsahuje následující položky - Subjekt (Název dopravce DÚK), Strojek (Uvedeno číslo odbavovacího zařízení), Počet (Počet storen provedených na daném odbavovacím zařízení).

7) Tržby na oblast

Sestava obsahuje následující položky - Subjekt (Název dopravce DÚK), Oblast (Daná oblast Ústeckého kraje, který daný subjekt obsluhuje), Kód (Kód dané oblasti), Tržba bez DPH (Celková tržba daného subjektu v dané oblasti bez DPH), Tržba s DPH (Celková tržba daného subjektu v dané oblasti včetně DPH).

8) Tržby na linky/spoj

Sestava obsahuje následující položky - Subjekt (Název dopravce DÚK), Linka (Číslo dané linky, na které se použila daná jízdenka), Počet spojů (počet záznamů o spoji na lince), Jednotlivé jízdenky- prodáno (Suma za jednotlivé jízdní doklady prodané na lince – elektronické i papírové), Časové jízdenky- prodáno (Suma za časové předplatní jízdenky prodané na lince).

9) Zamítnuté prodeje el. jízdenek

Sestava obsahuje následující položky - Subjekt (Název zapojeného dopravce), Tržby s DPH (Suma tržeb ze zamítnutých prodejů el. včetně DPH), Tržby bez DPH (Suma tržeb ze zamítnutých prodejů el. bez DPH)

10) Strojky na linkách

Sestava obsahuje následující položky - Subjekt (Název dopravce DÚK), Strojek (Uvedeno číslo odbavovacího zařízení), Linka (Číslo linky), Počet jízd (počet spojů, na které bylo zařízení nasazeno).

11) Nezpracované transakce dle dopravců a důvodu

Sestava obsahuje následující položky - Subjekt (Název zapojeného dopravce), Nezpracované transakce (Suma nezpracovaných transakcí)- každý důvod bude zpracován v samostatném sloupci, Tržby s DPH nezpracováno (Suma tržeb za nezpracované prodeje včetně DPH)- pro každý důvod samostatný sloupec, Tržby bez DPH nezpracováno (Suma tržeb za nezpracované prodeje bez DPH)- pro každý důvod nezpracování samostatný sloupec.

Příloha č. 2 ke smlouvě o poskytování služeb „Provozování zúčtovacího centra DÚK“

Návrh konečných sestav

Data budou ve formát xml, (případně csv).

Soubor definující karty používané pro odbavení v rámci DÚK

Jde o seznam karet s aktivní dopravní aplikací DÚK. Karty musí být definovány:

- Fyzickým číslem (tj. číslo čipu karty).

- Číslem aplikace.

- Číslem kmenového dopravce (= číslem závodu, kde byla karta vydaná).

- Počátkem platnosti karty, případně počátkem platnosti dopravní aplikace1.

- Koncem platnosti karty, případně koncem platnosti dopravní aplikace.

- Info o blokaci karty- u blokovaných karet bude uvedeno datum blokace karty.

Soubor definující zůstatky na EP

V sestavě musí být uvedeny zůstatky ke konci požadovaného kalendářního měsíce. Další informace, které musí být uvedeny:

- Seznam posledních zůstatků na elektronické peněžence na konci požadovaného kalendářního měsíce.

- Fyzické číslo karty (tj. číslo čipu karty).

- Číslo poslední operace provedené s EP.

- Datum a čas poslední operace provedené s EP.

- Zůstatek po poslední operaci na elektronické peněžence.

Soubor definující kupony, jejichž platnost přesahuje požadovaný kalendářní měsíc

V sestavě musí být uvedeny části kuponu přesahující konec požadovaného kalendářního měsíce. Součástí uvedených informací musí být:

- Fyzické číslo karty (tj. číslo čipu karty).

- Číslo aplikace (aplikace jízdenky)

- Číslo dopravce, u kterého byl kupón zakoupený

- Číslo kmenového dopravce (= číslo závodu, u něhož byla karta vydána)

- Prodejní cena kuponu

- Zůstatková cena kuponu (pro období přesahující konec kalendářního měsíce)

- Tarif- tj. číslo tarifu tvořené CP a TP

- Počátek platnosti kuponu (datum a čas začátku platnosti kuponu)

- Konec platnosti kuponu (datum a čas konce platnosti kuponu)

- Nástupní zóna- číslo počáteční zóny

- Cílová zóna- číslo cílové zóny kuponu

1 Vzhledem k tomu, že na kartu se bude v první fázi nahrávat pouze dopravní aplikace DÚK, předpokládá se, že blacklist karet = blacklist dopravní aplikace DÚK. Stejně tak se předpokládá, že datum počátku/konce karty odpovídá datu počátku/konce dopravní aplikace.

Document Metadata

Table of Contents

Specifikace požadavků na provozování zúčtovacího centra DÚK

Document Metadata