1. Duben 2015 21 Úprava typu položky SubDocumentType v kapitole 4.3.3 a 4.3.4

Datum vydání: duben 2014 Poslední aktualizace: duben 2015

Přehled aktualizací POŘADÍ DATUM AKTUALIZACE strana OBSAH ZMĚN 1. Duben 2015 21 Úprava typu položky SubDocumentType v kapitole 4.3.3 a 4.3.4 Datum vydání: duben 2014, aktualizace duben 2015 2/86

Obsah: 1 ÚVOD...5 2 VYUŽITÍ A VÝCHODISKA...6 3 ROZSAH A PRAVIDLA...9 4 POPIS...12 4.1 AKTIVACE/DEAKTIVACE SLUŽBY...12 4.1.1 Aktivace/deaktivace služby ze strany výstavce...12 4.1.2 Aktivace/deaktivace služby ze strany banky...14 4.2 VÝMĚNA DAT...17 4.2.1 Zaslání e-faktur a e-dokumentů do EB (výstavce banka)...17 4.3 PŘEDÁVANÁ DATA...19 4.3.1 E-faktura ve formátu XML (B2C-ISDOC 6.0)...19 4.3.2 E-dokument ve formátu XML (B2C-ISDOC 6.0)...21 4.3.3 E-faktura ve formátu PDF s metadaty v hlavičce...22 4.3.4 E-dokument ve formátu PDF s metadaty v hlavičce...22 4.3.5 Použité číselníky...23 4.3.6 Potvrzení o přijetí dokumentů zaslaných do EB (banka výstavce)...24 5 DEFINICE WEBOVÝCH SLUŽEB PRO KOMUNIKACI SE SYSTÉMY BANKY...28 5.1 DATOVÉ TYPY...28 5.2 KOMUNIKACE S WEBOVÝMI SLUŽBAMI...28 5.2.1 Přenosové protokoly...28 5.2.2 Přílohy zpráv...28 5.3 ZABEZPEČNÍ A AUTENTIZACE WS...28 5.3.1 Varianta 1 Základní úroveň zabezpečení...28 5.3.2 Varianta 2 - Zvýšená úroveň zabezpečení...28 6 PŘEDÁVÁNÍ ŽÁDOSTÍ O AKTIVACI ZE STRANY BANKY A NOTIFIKAČNÍCH REPORTŮ PROSTŘEDNICTVÍM DOWNLOAD WEBOVÉ SLUŽBY (DOWNLOADWS)...30 6.1 OPERACE PRO HROMADNÉ STAHOVÁNÍ DOKUMENTŮ...30 6.1.1 Hlavička...30 6.1.2 Popis parametrů požadavku...30 6.1.3 Popis parametrů odpovědi...31 6.2 OPERACE PRO OZNAČENÍ DOKUMENTŮ K OPĚTOVNÉMU STAŽENÍ...31 6.2.1 Operace pro označení dokumentů pomocí časového intervalu...32 6.2.2 Popis parametrů odpovědi markdocumentsbytimerange...32 6.3 NEÚSPĚŠNÉ VOLÁNÍ OPERACÍ SLUŽBY...32 7 PŘEDÁVÁNÍ E-FAKTUR, E-DOKUMENTŮ A ODPOVĚDÍ NA ŽÁDOSTI O AKTIVACI PROSTŘEDNICTVÍM UPLOAD WEBOVÉ SLUŽBY (UPLOADWS)...34 7.1 HLAVIČKA METODY...34 7.2 POPIS PARAMETRŮ...34 7.3 NÁVRATOVÉ KÓDY SLUŽBY...35 7.3.1 Úspěšné volání služby...35 7.3.2 Neúspěšné volání služby...35 8 KOMUNIKAČNÍ KANÁL SFTP...37 8.1 KOMUNIKAČNÍ PROTOKOL SFTP...37 8.2 ZABEZPEČENÍ SFTP...37 8.2.1 Varianta 1 - Základní úroveň zabezpečení...37 8.2.2 Varianta 2 - Zvýšená úroveň zabezpečení...37 9 PŘENOS DAT POMOCÍ ISDS...38 10 PŘÍLOHY...39 10.1 Příloha č. 1 - Definice struktury žádosti o aktivaci (deaktivaci) služby ze strany banky...39 10.2 Příloha č. 2 - Definice struktury odpovědi výstavce na žádost o aktivaci (deaktivaci) služby ze strany banky...41 10.3 Příloha č. 3 Definice struktury dávky...43 10.3.1 Příklady dávek...44 10.4 Příloha č. 4 - Definice struktury podkladů k platbě zaslaná výstavcem...45 10.5 Příloha č. 5 - Definice struktury e-dokumentů...59 10.6 Příloha č. 6 - Definice struktury notifikačního reportu o přijetí dokumentů do EB...66 10.7 Příloha č. 7 WSDL pro UploadWS...69 10.7.1 Příklady volání UploadWS...71 10.8 Příloha č. 8 WSDL pro DownloadWS...77 10.8.1 Příklady volání DownloadWS...80 10.9 Příloha č. 9 WSDL pro WS UserAccountStatus...83 Datum vydání: duben 2014, aktualizace duben 2015 3/86

Použité zkratky Název Popis B2C Business-To-Customer/Consumer v kontextu tohoto dokumentu se jedná o elektronickou komunikaci mezi výstavci a koncovými spotřebiteli prostřednictvím kanálů EB B2C-ISDOC 6.0 krátká struktura XML vycházející z plného formátu ISDOC 6.0 BIC Bank Identifier Code DÁVKA XML soubor obsahující ZIP jednotlivých předávaných dokumentů DOKUMENT primárně znamená e-faktura nebo e-dokument, ale též aktivační/deaktivační zpráva EB elektronické bankovnictví E-DOKUMENT jakýkoli dokument bez platební instrukce (smlouva, informace, potvrzení,...) E-FAKTURA jakýkoli dokument s platební instrukcí (faktura, zálohová platba, výzva k platbě...) IBAN International Bank Account Number IDENTIFIKÁTOR NA STRANĚ VÝSTAVCE Jedná se o položku ClientOnTargetConsolidator - např. zákaznické číslo, číslo smlouvy, číslo odběrného místa, variabilní symbol, spojovací číslo, číslo odběratele apod. ISDOC Information System Document - standard pro elektronickou fakturaci v ČR, který definovalo sdružení SPIS (nyní ICT Unie) ISDS informační systém datových schránek JPÚ KONCOVÝ SPOTŘEBITEL (ZÁKAZNÍK, KLIENT) SFTP VÝSTAVCE WS jednorázový příkaz k úhradě klient příslušné banky s možností přijímat dokumenty prostřednictvím elektronického bankovnictví Secure File Transfer Protocol Společnost, která je u příslušné banky registrována jako společnost, která může zasílat do EB dokumenty pro koncové spotřebitele. webová služba Datum vydání: duben 2014, aktualizace duben 2015 4/86

1 ÚVOD Elektronická fakturace je moderní způsob předávání daňových dokladů. Jedná se o formu komunikace opírající se o platné zákony České republiky zrovnoprávňující elektronickou a listinnou formu fakturace, a to zejména: Zákon o elektronickém podpisu 227/2000 Sb., novelizovaný zákonem č. 440/2004 Sb, který určuje původ a pravost dokumentů, Zákon o dani z přidané hodnoty 235/2004 Sb., který definuje elektronickou fakturaci novelizovaný s účinností k 1. 1. 2013 (naplnění závazku harmonizovat národní legislativu ČR s evropskou směrnicí 2010/45/EU o elektronické fakturaci). Tento standard ČBA (dále jen Standard ) popisuje rozhraní pro zasílání e-faktur a e-dokumentů koncovým spotřebitelům do aplikací elektronického bankovnictví. Standard si klade za cíl zejména: usnadnit elektronickou fakturaci a elektronickou komunikaci obecně mezi výstavci dokumentů a jejich zákazníky, příjemci dokumentů a zajistit jednotný otevřený přístup všem účastníkům trhu v ekosystému elektronické fakturace při zasílání dokumentů do elektronického bankovnictví (dále jen EB ), tj. výstavcům faktur včetně jejich dodavatelů informačních systémů, poskytovatelům řešení, tak pro banky. Datum vydání: duben 2014, aktualizace duben 2015 5/86

2 VYUŽITÍ A VÝCHODISKA Praktické využití standardu pro elektronickou fakturaci spočívá především v přenosu platebních údajů bez zásahu lidského faktoru a jejich doručení do EB prostřednictvím elektronických faktur. Klient pak po přihlášení do elektronického bankovnictví pouze zkontroluje údaje, či případně ještě prověří detail faktury v příloze, a automaticky vygenerovaný platební příkaz odešle ke zpracování standardním procesem autorizace platby. Tím se jednak zvýší komfort pro klienty, ale také sníží počet chybně zadaných plateb. Banky jsou tradičně vnímány jako důvěryhodné instituce s vysokým stupněm zabezpečení. A proto standard bude navíc klientům bank umožňovat i příjem neplatebních dokumentů, čímž výstavcům a příjemcům umožní a především usnadní elektronickou komunikaci do zabezpečeného a důvěryhodného prostředí s možností archivace. Klienti elektronického bankovnictví tak budou mít všechny důležité dokumenty na jednom zabezpečeném místě. ČBA tímto krokem chce podpořit rozšíření a akceptaci elektronických faktur v ČR. Datum vydání: duben 2014, aktualizace duben 2015 6/86

Datum vydání: duben 2014, aktualizace duben 2015 7/86

Popis rozhraní vychází z těchto požadavků: standardizace zasílání e-faktur a e-dokumentů koncovým spotřebitelům do aplikací elektronického bankovnictví využití stávajících technologických standardů o Při přípravě standardu ČBA spolupracovala v oblasti výměny dat s ICT Unií, Pracovní skupinou pro elektronické standardy výměny dat, která definovala a spravuje ISDOC, formát elektronické fakturace v ČR. neomezování žádného účastníka trhu v poskytování služby umožnění přenosu nezbytných a nejčastěji používaných atributů tuzemské platby umožnění předávání informací v rámci procesu nastavení a zrušení služby a přenosu dat zohlednění současného stavu B2C elektronické fakturace Datum vydání: duben 2014, aktualizace duben 2015 8/86

3 ROZSAH A PRAVIDLA Popis rozhraní je specifikací technických parametrů pro účely předávání platebních údajů a dokumentů elektronickou cestou mezi výstavcem a bankou, a to zejména pro účely předvyplnění platebního příkazu. Popis rozhraní definuje: 1. komunikační protokoly, 2. formáty pro zasílání platebních údajů včetně jejich obsahu - zejména platebních instrukcí, faktur a dalších neplatebních dokumentů výstavců do EB. Oblasti Popisu rozhraní: I. Nastavení/zrušení služby Ia. Aktivace/deaktivace služby ze strany výstavce a) žádost o aktivaci/deaktivaci (výstavce banka) b) odpověď na žádost o aktivaci/deaktivaci (banka výstavce) Ib. Aktivace/deaktivace služby ze strany banky a) žádost o aktivaci/deaktivaci (banka výstavce) b) odpověď na žádost o aktivaci/deaktivaci (výstavce banka) II. Výměna dat a) Zaslání podkladů k platbě a doručení e-faktur a e-dokumentů do EB (výstavce banka) b) Potvrzení o přijetí e-faktur a e-dokumentů do EB (banka výstavce) Datum vydání: duben 2014, aktualizace duben 2015 9/86

Aktivace služby Klient si službu může aktivovat, pokud banka a výstavce službu nabízí. Způsoby aktivace jsou: na straně banky ve svém EB, na straně výstavce. Identifikátor příjemce dokumentů Jako identifikátor v komunikaci mezi bankou a výstavcem se používají vždy dva údaje: identifikátor na straně výstavce (např. zákaznické číslo, číslo smlouvy, číslo odběrného místa apod.); v případě více identifikátorů jsou tyto identifikátory odděleny technickým znakem pomlčky - číslo bankovního účtu zákazníka (pod kterým si aktivoval službu). Bankami přijímané typy formátů zasílaných dokumentů a příloh: Zjednodušený formát B2C-ISDOC 6.0 a vyšší nebo ISDOC 6.0 a nebo vyšší o Do EB je možné zasílat maximálně jednu přílohu, a to pouze ve formátu PDF, tj.: platební řádek (např. výzva k platbě) bez přílohy nebo jednu přílohu (např. faktura) ve formátu PDF, PDF s metadaty. Typy dokumentů Do EB lze zasílat dokumenty v max. velikosti 400kB: e-faktury - dokument s platební instrukcí (faktury, výzvy k platbě, zálohy, upomínky...) e-dokumenty - dokument bez platební instrukce (smlouvy, potvrzení, informace...). K identifikaci dokumentů slouží: číselníky pro typ dokumentu e-faktura, číselník pro typ dokumentu e-dokument. Identifikace dokumentu V případě ISDOC a B2C-ISDOC je možné zjistit identifikaci dokumentu, tj. zda se jedná o e-fakturu či e-dokument, z příslušného hlavního (rootového) elementu <Invoice> nebo <CommonDocument>. U strukturovaných dat, stejně jako u PDF s daty v hlavičce, je možné rozlišit e-fakturu a e-dokument podle obsahu elementu <DocumentType>. Je-li vyplněn hodnotou dle číselníku (např. 1 Faktura daňový doklad), jedná se o e-fakturu. Je-li DocumentType =0, jedná se o e-dokument dále specifikovaný v elementu <SubDocumentType>. Generování jednorázových platebních příkazů k úhradě (JPÚ) Datum vydání: duben 2014, aktualizace duben 2015 10/86

Generování JPÚ v EB je dáno číselníky pro typ dokladu e-faktura (resp. hodnotou znaménka částky k zaplacení). Platební kalendář / zálohové platby (implementace této funkcionality záleží na dané bance) Do EB je možné zasílat i předpisy zálohových plateb v počtu 1-12, a to maximálně na následujících 12 měsíců. Z důvodu častých změn záloh je však doporučováno posílat předpis záloh na 3 měsíce. Datum vydání: duben 2014, aktualizace duben 2015 11/86

4 POPIS Tato kapitola popisuje procesy a obsah dat spojenými s daným způsobem aktivace a deaktivace služby a výměnu dat mezi výstavcem a bankou. 4.1 AKTIVACE/DEAKTIVACE SLUŽBY 4.1.1 Aktivace/deaktivace služby ze strany výstavce Aktivace a deaktivace služby ze strany výstavce je řešena následovně: Způsob komunikace: WS na straně banky (WSDL 1.1). Definice WS viz WSDL Příloha č. 10.9. Formát: SOAP XML zpráva Zabezpečení a autentizace WS je shodné se zabezpečením definovaným v kapitole 5.3. 4.1.1.1 Žádost o aktivaci / deaktivaci nebo zjištění stavu účtu (výstavce banka) Struktura žádosti o aktivaci/deaktivaci služby nebo o zjištění stavu účtu ze strany výstavce: Popis jednotlivých elementů: - BankAccountID je povinná položka, která obsahuje buď právě element ClientBankAccount nebo právě ClientIBANBankAccount, nikdy ne oba elementy současně. ClientBankAccount číslo účtu vždy v délce 20 znaků, ve formátu: předčíslí účtu (pozice 1-6) doplněné 0 z leva na 6 znaků číslo účtu (pozice 7-16) - doplněné 0 z leva na 10 znaků Datum vydání: duben 2014, aktualizace duben 2015 12/86

kód banky (pozice 17-20) - doplněné 0 z leva na 4 znaky ClientIBANBankAccount Obsahuje elementy IBAN a BIC dle příslušných pravidel. Pokud je v requestu obsažený element ClientIBANBankAccount, jsou elementy IBAN a BIC povinné. - ChangeAction je povinná položka přesně specifikující o jaký požadavek se jedná. Může nabývat hodnot: 0 = Deactivate Deaktivace zasílání dokumentů pro uvedený bankovní účet a ClientOnTargetConsolidator 1 = Activate - Aktivace zasílání dokumentů pro uvedený bankovní účet a ClientOnTargetConsolidator 2 = CheckStatus Kontrola možnosti aktivace zasílání dokumentů pro uvedený bankovní účet a ClientOnTargetConsolidator - ClientOnTargetConsolidator je povinná položka obsahující identifikátor v systémech výstavce - StatusCode nepovinné, informace o iniciátorovi změny. S použitím tohoto atributu se počítá pouze v případě deaktivace, která může být vyvolána výstavcem bez aktivního souhlasu klienta např. při ukončení smluvního vztahu. StatusCode Popis 1 Změna na žádost klienta 2 Změna na žádost výstavce - TraceID je povinná položka obsahující jedinečný identifikátor (např. GUID) jednoznačně identifikující u výstavce konkrétní volání. Tento string může být max. 40 znaků dlouhý. Povolené znaky jsou a..z, A..Z a 0..9. Pro zajištění unikátnosti doporučujeme používat min. 10 znaků. 4.1.1.2 Odpověď na žádost o aktivaci / deaktivaci nebo o zjištění stavu účtu (výstavce banka) Struktura odpovědi na žádost o aktivaci/deaktivaci služby nebo o zjištění stavu účtu ze strany výstavce: Návratové kódy v poli Status: Status Popis 0 OK, změna proběhla úspěšně. 1 Účet může využívat službu a pro dané ClientOnTargetConsolidator je aktivní. Lze poslat e-fakturu nebo e-dokument. 2 Účet může využívat službu a pro dané ClientOnTargetConsolidator je neaktivní. V tomto okamžiku nelze poslat e-fakturu ani e-dokument, status se musí změnit. Datum vydání: duben 2014, aktualizace duben 2015 13/86

3 Účet má službu zablokovanou. Nelze poslat e-fakturu ani e- dokument. Také nelze změnit status klienta ze strany výstavce. -1 Chyba, response obsahuje element StatusErrorDescription, kde je chyba vydefinována. Návratové chybové kódy v elementu StatusErrorDescription pro Status -1: ErrorCode ErrorDescription Vysvětlení -1 Neexistující nebo zablokovaný účet výstavce Výstavce použil špatné jméno/heslo nebo má účet zablokovaný. -2 Nevalidní request Request není správně vyplněn. -3 Účet klienta nebyl nalezen Účet klienta nebyl v systému banky nalezen nebo neumožňuje službu. -4 Pro účet klienta nebylo nalezeno ClientOnTargetConsolidator pro deaktivaci Pro zadanou kombinaci účtu klienta a SupplierID nebyl nalezen záznam, který by umožnil deaktivaci. -5 Nebylo možno změnit status u klienta Status klienta pro požadované SupplierID nebylo možné změnit. Možnost změny může být blokována. -6 Status klienta byl již změněn Status klienta pro zadané SupplierID je již změněn na požadovanou hodnotu. -1000 Vnitřní chyba systému banky Nespecifikovaný problém v systémech banky. Služba je nyní nedostupná. 4.1.2 Aktivace/deaktivace služby ze strany banky Aktivace a deaktivace služby ze strany banky je řešena následovně: Způsob komunikace: WS na straně banky (WSDL 1.1) Formát: XML 4.1.2.1 Źádost o aktivaci/deaktivaci (banka výstavce) Grafické schéma struktury žádosti o aktivaci/deaktivaci služby ze strany banky (XSD viz Příloha č. 10.1): Datum vydání: duben 2014, aktualizace duben 2015 14/86

Datum vydání: duben 2014, aktualizace duben 2015 15/86

4.1.2.2 Odpověď na žádost o aktivaci / deaktivaci (výstavce banka) Grafické schéma struktury odpovědi výstavce na žádost o aktivaci/deaktivaci služby ze strany banky (XSD viz Příloha č. 10.2): Datum vydání: duben 2014, aktualizace duben 2015 16/86

4.1.2.3 Číselník pro důvod neprovedení aktivace služby na straně výstavce Pokud je element Activated = 1, elementy StatusCode a StatusDescription nejsou v XML obsaženy. Pokud je element Activated = 0, elementy StatusCode a StatusDescription jsou vyplněny dle následující tabulky: StatusCode StatusDescription Význam 01 Služba je již aktivní Klient se opakovaně snaží zaktivovat již aktivní službu u výstavce. 04 Zákaz aktivace služby Výstavce si nepřeje z jakéhokoli důvodu službu zákazníkovi aktivovat. 05 Odmítnutí klientem Zákazník změnil své rozhodnutí nebo nesouhlasí s aktivací služby jinou osobou a vyjádřil tak svůj nesouhlas s aktivací služby na straně výstavce. 06 Klient neexistuje Klient uvedl chybné / neexistující číslo zákazníka při aktivaci. 07 Klient ukončil vztah s výstavcem Klient ukončil vztah s výstavcem. 08 Nekompatibilní služba Klient má u výstavce sjednán produkt/službu u kterého není možné službu zřídit nebo má klient aktivovanou jinou službu a není možné mít současně aktivní jak službu výstavce tak službu banky. Pozn. Pokud v jeden den klient podal více požadavků na aktivaci/deaktivaci, tak výstavce rozliší poslední status na základě časového údaje obsaženého v položce Created. Dále, doba čekání na reakci ze strany výstavce na požadavek aktivace je omezena časovou lhůtou 62 dnů. Do této lhůty je výstavce povinován bance poskytnou na požadavek opověď. 4.2 VÝMĚNA DAT Tato podkapitola řeší zasílání dokumentů do EB a potvrzování jejich přijetí. 4.2.1 Zaslání e-faktur a e-dokumentů do EB (výstavce banka) Způsob komunikace: WS (WSDL verze 1.1) SFTP ISDS (implementace tohoto způsobu komunikace je na dohodě s danou bankou) Formát dokumentů: XML (B2C-ISDOC 6.0 / ISDOC 6.0) a PDF s grafickým obrazem dokumentu nebo pouze XML (B2C-ISDOC 6.0/ ISDOC 6.0) nebo PDF s metadaty v hlavičce obsahujícími identifikační či případně i fakturační údaje. Výstavce může zasílat dokumenty buď jednotlivě nebo v dávce. Datum vydání: duben 2014, aktualizace duben 2015 17/86

4.2.1.1 Definice dávky předávaných dokumentů Dávka pro přenos dokumentů od výstavce do banky příjemce bude vytvořena ve formě XML souboru (XSD viz Příloha č. 10.3). Maximální celková velikost dávky (výsledného XML souboru) je 2GB pro přenos pomocí WS a SFTP protokolu, 10 MB pro přenos kanálem Datových schránek (ISDS) viz vyhláška č. 194/2009 Sb. Jmenná konvence pro dávky je jm_davky.xml, přičemž jméno_dávky musí být pokaždé pro daného výstavce unikátní. Platné znaky jsou: [a..z], [A..Z], [0..9]. Extenze je pevně XML. Nesplnění konvence je reportovanou chybou dávky (chybová hláška 10036; dávka se v bance nezpracuje). 4.2.1.2 Popis položek struktury dávky Grafické schéma struktury dávky: SupplierID - ID výstavce dávky. BatchVersion Určuje verzi dávky s ohledem na případné další rozšíření. Aktuální hodnota = 1 CreationTime - Informativní datum čas vytvoření dávky. Získává se ze systémového času stroje, který měl by být synchronizovaný (UTC+01:00). Formát: YYYY-MM-DD HH:MM:SS (např. 2014-02-11 14:25:15) Hash - Obsahuje hash otisk ze ZIP souboru v base64 (kódování UTF-8). Aktuální hodnota metody hash funkce = SHA256 SignedHash - Obsahuje hash otisk ze ZIP souboru v base64 (kódování UTF-8). Aktuální hodnota metody hash funkce = SHA256. Tento Hash je podepsaný kvalifikovaným certifikátem. Podepsaný hash je převeden do base64. Batch - Obsahuje zip soubor s jednotlivými dokumenty převedeným následně pomocí base64 (kódování UTF-8) na ASCII. Datum vydání: duben 2014, aktualizace duben 2015 18/86

4.3 PŘEDÁVANÁ DATA Jak už bylo uvedeno výše, mohou být strukturovaná data e-faktur a e-dokumentů předávaná do EB buď ve formátu ISDOC 6.0 nebo vyšším nebo ve zjednodušeném XML formátu B2C-ISDOC 6.0 nebo vyšším. Struktura B2C-ISDOC 6.0 je odvozena zúžením formátu ISDOC 6.0 (viz www.isdoc.cz) a definice položek je v obou formátech shodná, a to i co do eventuálních číselníků, které jsou pro položky v plném formátu ISDOC definovány. Některé položky nepovinné v základním formátu ISDOC mohou být v odvozeném formátu B2C-ISDOC povinné. 4.3.1 E-faktura ve formátu XML (B2C-ISDOC 6.0) Grafické schéma struktury podkladů k platbě zaslaná výstavcem ve formátu B2C-ISDOC (XSD viz Příloha č. 10.4): Datum vydání: duben 2014, aktualizace duben 2015 19/86

Datum vydání: duben 2014, aktualizace duben 2015 20/86

4.3.2 E-dokument ve formátu XML (B2C-ISDOC 6.0) Grafické schéma struktury dat e-dokumentu B2C-ISDOC zasílaného výstavcem (XSD viz Příloha č. 10.5): Datum vydání: duben 2014, aktualizace duben 2015 21/86

4.3.3 E-faktura ve formátu PDF s metadaty v hlavičce Definice množiny položek pro metadata PDF pro e-faktury: Název položky Typ položky Ekvivalent v B2C-ISDOC DocumentType (=1, 6) Integer DocumentType SubDocumentType String SubDocumentType TargetConsolidator String TargetConsolidator ClientOnTargetConsolidator String ClientOnTargetConsolidator ClientBankAccount String ClientBankAccount DocumentID String ID UUID String UUID IssueDate Date IssueDate Note String Note LocalCurrency String LocalCurrency SupplierID String AccountingSuplierParty/Party/PartyIdentification/ID CustomerName String AccountingCustomerParty/Party/PartyName/Name PayableAmount Decimal LegalMonetaryTotal/PayableAmount ParcialPayment Boolean PaymentMeans/Payment ParcialPayment=False (default=true) PaidAmount01 Decimal PaymentMeans/Payment/PaidAmount PaymentMeansCode01 Integer PaymentMeans/Payment/PaymentMeansCode PaymentDueDate01 Date PaymentMeans/Payment/Details/PaymentDueDate BankAccount01 String PaymentMeans/Payment/Details/BankAccount/ID BankCode01 String PaymentMeans/Payment/Details/BankAccount/BankCode Name01 String PaymentMeans/Payment/Details/BankAccount/Name IBAN01 String PaymentMeans/Payment/Details/BankAccount/IBAN BIC01 String PaymentMeans/Payment/Details/BankAccount/BIC VariableSymbol01 String PaymentMeans/Payment/Details/VariableSymbol ConstantSymbol01 String PaymentMeans/Payment/Details/ConstantSymbol SpecificSymbol01 String PaymentMeans/Payment/Details/SpecificSymbol. Položky od PaidAmountNN až SpecificSymbolNN se až 12x opakují. NN nabývá hodnot 01,02,,12. PaidAmount12 Decimal PaymentMeans/Payment/PaidAmount PaymentMeansCode12 Integer PaymentMeans/Payment/PaymentMeansCode PaymentDueDate12 Date PaymentMeans/Payment/Details/PaymentDueDate BankAccount12 String PaymentMeans/Payment/Details/BankAccount/ID BankCode12 String PaymentMeans/Payment/Details/BankAccount/BankCode Name12 String PaymentMeans/Payment/Details/BankAccount/Name IBAN12 String PaymentMeans/Payment/Details/BankAccount/IBAN BIC12 String PaymentMeans/Payment/Details/BankAccount/BIC VariableSymbol12 String PaymentMeans/Payment/Details/VariableSymbol ConstantSymbol12 String PaymentMeans/Payment/Details/ConstantSymbol SpecificSymbol12 String PaymentMeans/Payment/Details/SpecificSymbol 4.3.4 E-dokument ve formátu PDF s metadaty v hlavičce Název položky Typ položky Ekvivalent v B2C-ISDOC DocumentType (= 0) Integer DocumentType SubDocumentType String SubDocumentType TargetConsolidator String TargetConsolidator ClientOnTargetConsolidator String ClientOnTargetConsolidator ClientBankAccount String ClientBankAccount DocumentID String ID UUID String UUID IssueDate Date IssueDate Note String Note SupplierID String AccountingSuplierParty/Party/PartyIdentification/ID CustomerName String AccountingCustomerParty/Party/PartyName/Name Datum vydání: duben 2014, aktualizace duben 2015 22/86

4.3.5 Použité číselníky 4.3.5.1 Číselníky pro typ dokumentu e-faktura Typ dokladu (DocumentType v dokumentu Invoice) Popis dokladu (SubDocumentType v dokumentu Invoice) 1 Faktura daňový doklad 1 Faktura bez vyúčtování záloh 2 Opravný daňový doklad (dobropis) 3 Opravný daňový doklad (vrubopis) 4 Zálohová faktura (nedaňový zálohový list) 2 Doplatek - Faktura s vyúčtováním záloh 3 Přeplatek - Faktura s vyúčtováním záloh 4 Upomínka (nedaňová platební) 5 Zálohová faktura (nedaňový zálohový list) 6 Výzva k platbě 7 Zálohová platba Znaménko u částky k zaplacení Poznámka +/- + Faktura bez vyúčtování záloh + Doplatek - Faktura s vyúčtováním záloh - Přeplatek - Faktura s vyúčtováním záloh Generování JPÚ ANO ANO NE "+" Upomínka ANO - NE + ANO + ANO 5 Daňový doklad při přijetí platby (daňový zálohový list) 6 Opravný daňový doklad při přijetí platby (dobropis daňového zálohového listu) + ANO - NE Pozn. V případě, že e-faktura je hrazena jinou platební metodou, tak v částce k zaplacení je očekávána hodnota 0,- Kč. Vedle částky k zaplacení se bude předávat i celková částka v poli PayableAmount v metadatech PDF resp. XML elementu Invoice/LegalMonetaryTotal/PayableAmount, nicméně předávání a zobrazování celkové částky v EB závisí na dané bance. 4.3.5.2 Číselník pro typ dokumentu e-dokument plněný do položky SubDocumentType. Kód Název dokumentu 0 Dokument (neplatební dokument bez rozlišení) A Avízo DP Daňové potvrzení, Daňový doklad k přijaté platbě DR Detailní rozpis DS Dopis o stornu DZ Dopis o změně S Sdělení, informace SM Smlouva, dodatek smlouvy U1 1. Upomínka (neplatební) U2 2. Upomínka (neplatební) Datum vydání: duben 2014, aktualizace duben 2015 23/86

Kód VS VV ZA Název dokumentu Dopis ve výročí smlouvy Vyúčtování (neplatební) Zápočet, platba zápočtem nedaňový doklad 4.3.6 Potvrzení o přijetí dokumentů zaslaných do EB (banka výstavce) Komunikační kanál: WS, SFTP, e-mail pro banku implementačně povinné komunikační kanály a volitelné pro výstavce ISDS pro banku implementačně volitelný komunikační kanál Formát: XML Potvrzení o přijetí dokumentů zaslaných do EB nebo-li notifikační report je XML soubor, ve kterém jsou předávány výstavci informace o stavu zpracování jak dávky tak jednotlivých faktur v dávce obsažených. Grafické schéma XML struktury potvrzení o přijetí dávek a dokumentů zaslaných do EB (XSD viz Příloha č. 10.6) Datum vydání: duben 2014, aktualizace duben 2015 24/86

V položce BatchName je předáváno jméno dávky zaslané výstavcem bance. Toto jméno musí být od jednoho výstavce, stejně jako UUID dokumentu, unikátní. Jeden notifikační report může notifikovat více dávek a více jednotlivých dokumentů, což je zajištěno opakováním elementu Notification. Příklad notifikace chybné dávky: <?xml version="1.0" encoding="utf-8"?> <Message> <Notification> <BankCode>0300</BankCode> <SupplierID>12345678</SupplierID> <Batch> <BatchName>Davka_20140130_1100.xml</BatchName> <StatusCode>10036</StatusCode> <StatusDescription> Nekorektní dávka.</statusdescription> <DeliveryDate>2014-01-30T11:30:12Z</DeliveryDate> </Batch> </Notification> </Message> Mezi elementy Batch a Document se v jedné notifikaci jedná o výlučný výběr (choice), což znamená, že je v daném elementu <Notification> notifikována buď dávka a nebo dokument (e-faktura, e-dokument). To znamená, že pokud je notifikován dokument, element Batch chybí. Příklad notifikace dvou faktur: <?xml version="1.0" encoding="utf-8"?> <Message> <Notification> <BankCode>0800</BankCode> <SupplierID>12345678</SupplierID> <Document> <DocumentID>FA111111</DocumentID> <UUID>39140CEC-1939-4164-98D7-C355F9D31665</UUID> <Status> <StatusCode>10000</StatusCode> <StatusDescription> Dokument úspěšně importován </StatusDescription> <DeliveryDate>2014-01-30T11:50:10Z</DeliveryDate> </Status> </Document> </Notification> <Notification> <BankCode>0800</BankCode> <SupplierID>12345678</SupplierID> <Document> <DocumentID>FA111112</DocumentID> <UUID>6940AD61-4D10-4BAC-802A-98773B344FBF</UUID> <Status> <StatusCode>10004</StatusCode> <StatusDescription>Nezadáno datum splatnosti / platnosti </StatusDescription> <DeliveryDate>2014-01-30T11:50:15Z</DeliveryDate> </Status> </Document> </Notification> </Message> Datum vydání: duben 2014, aktualizace duben 2015 25/86

Do standardu je zahrnuta nepovinná možnost informovat výstavce o tom, že klient dokument nejen obdržel, ale i přečetl (resp. otevřel). To je umožněno přes výlučný výběr (choice) mezi elementy Status a ReadingDate. Datum vydání: duben 2014, aktualizace duben 2015 26/86

Příklad notifikace o přečtení dokumentu z předchozí notifikace: <?xml version="1.0" encoding="utf-8"?> <Message> <Notification> <BankCode>0300</BankCode> <SupplierID>12345678</SupplierID> <Document> <DocumentID>FA111111</DocumentID> <UUID>39140CEC-1939-4164-98D7-C355F9D31665</UUID> <ReadingDate>2014-01-30T17:20:35Z </ReadingDate> </Document> </Notification> </Message> 4.3.6.1 Číselník stavů zpracování dokumentů zaslaných do EB StatusCode Text stavu 10000 Dokument úspěšně importován 10001 Neplatné číslo účtu klienta 10002 Neplatný kód banky klienta 10003 Nezadána fakturovaná částka k zaplacení u e-faktury 10004 Nezadáno datum splatnosti / platnosti 10006 Neplatná identifikace výstavce 10007 Nesprávný/neúplný formát dat 10008 Neplatný elektronický podpis 10011 Neplatné číslo účtu výstavce 10012 Neplatný kód banky výstavce 10015 Neplatná fakturovaná částka 10016 Neplatné datum splatnosti 10018 Neplatný Variabilní symbol 10019 Neplatný Konstantní symbol 10020 Neplatný Specifický symbol 10023 Dokument překročil velikost 400KB 10024 Neplatný formát faktury 10025 Klient nemá k účtu EB 10029 Neplatný prefix čísla účtu výstavce 10030 Neplatný IBAN výstavce 10031 Neplatný prefix čísla účtu klienta 10032 Neplatný IBAN klienta 10033 Neplatný obsah položky typu e-dokumentu (není v seznamu povolených hodnot číselníku) 10035 Neplatná měna 10036 Nekorektní dávka 10041 Číslo účtu klienta není vyplněno 10042 IBAN klienta nepatří k účtu 10043 Nevyplněn účet výstavce 10044 IBAN výstavce nepatří k účtu 10047 Popis dokumentu (položka note) příliš dlouhá nebo nekorektní 10048 Příliš velká dávka (nad 2GB) Datum vydání: duben 2014, aktualizace duben 2015 27/86

5 DEFINICE WEBOVÝCH SLUŽEB PRO KOMUNIKACI SE SYSTÉMY BANKY Cílem této specifikace je definovat obecné vlastnosti webových služeb pro komunikaci mezi výstavcem a bankou. 5.1 DATOVÉ TYPY Datové typy používané v této specifikaci vycházejí z primitivních a odvozených datových typů v definici XML Schema. Konkrétně: Datový typ string je dán definicí http://www.w3.org/tr/xmlschema-2/#string Integer je dán http://www.w3.org/tr/xmlschema-2/#integer Base64Binary je dán http://www.w3.org/tr/xmlschema-2/#base64binary DateTime je dán http://www.w3.org/tr/xmlschema-2/#datetime Ostatní datové typy jsou vždy složenými datovými typy z již definovaných typů. 5.2 KOMUNIKACE S WEBOVÝMI SLUŽBAMI V této kapitole jsou shrnuty základní vlastnosti komunikace s webovými službami. 5.2.1 Přenosové protokoly Služby budou dostupné prostřednictvím protokolu SOAP 1.2 nad protokolem HTTP 1.1 a budou využívat přenosového kódování chunked. 5.2.2 Přílohy zpráv Dokumenty budou poslány uživateli ve formě: XML souborů dle příslušného schématu typu XML Schema PDF soubory nebo PDF soubory s fakturačními údaji v metadatech Tyto soubory budou zasílány v elementech SOAP zprávy odpovědi. Pro optimalizaci přenosu bude použito kódování metodou MTOM (Message Transmission Optimaliation Mechanism). 5.3 ZABEZPEČNÍ A AUTENTIZACE WS Standard umožňuje více variant/úrovní zabezpečení. Konkrétní realizace bude dána dohodou mezi výstavcem a bankou. 5.3.1 Varianta 1 Základní úroveň zabezpečení Webové služby budou komunikovat prostřednictvím two-way SSL tj. přes protokol HTTPS s dodatečnou autentizací jménem a heslem na úrovni protokolu SOAP v těle zprávy. Server banky i klientská aplikace výstavce se budou identifikovat certifikátem od akreditované certifikační autority. 5.3.2 Varianta 2 - Zvýšená úroveň zabezpečení Webové služby budou komunikovat prostřednictvím one-way SSL tj. přes protokol HTTPS s použitím serverového certifikátu na straně banky. Datum vydání: duben 2014, aktualizace duben 2015 28/86