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

Transkript

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

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

3 Obsah: 1 ÚVOD VYUŽITÍ A VÝCHODISKA ROZSAH A PRAVIDLA POPIS AKTIVACE/DEAKTIVACE SLUŽBY Aktivace/deaktivace služby ze strany výstavce Aktivace/deaktivace služby ze strany banky VÝMĚNA DAT Zaslání e-faktur a e-dokumentů do EB (výstavce banka) PŘEDÁVANÁ DATA E-faktura ve formátu XML (B2C-ISDOC 6.0) E-dokument ve formátu XML (B2C-ISDOC 6.0) E-faktura ve formátu PDF s metadaty v hlavičce E-dokument ve formátu PDF s metadaty v hlavičce Použité číselníky Potvrzení o přijetí dokumentů zaslaných do EB (banka výstavce) DEFINICE WEBOVÝCH SLUŽEB PRO KOMUNIKACI SE SYSTÉMY BANKY DATOVÉ TYPY KOMUNIKACE S WEBOVÝMI SLUŽBAMI Přenosové protokoly Přílohy zpráv ZABEZPEČNÍ A AUTENTIZACE WS Varianta 1 Základní úroveň zabezpečení Varianta 2 - Zvýšená úroveň zabezpečení PŘEDÁVÁNÍ ŽÁDOSTÍ O AKTIVACI ZE STRANY BANKY A NOTIFIKAČNÍCH REPORTŮ PROSTŘEDNICTVÍM DOWNLOAD WEBOVÉ SLUŽBY (DOWNLOADWS) OPERACE PRO HROMADNÉ STAHOVÁNÍ DOKUMENTŮ Hlavička Popis parametrů požadavku Popis parametrů odpovědi OPERACE PRO OZNAČENÍ DOKUMENTŮ K OPĚTOVNÉMU STAŽENÍ Operace pro označení dokumentů pomocí časového intervalu Popis parametrů odpovědi markdocumentsbytimerange NEÚSPĚŠNÉ VOLÁNÍ OPERACÍ SLUŽBY PŘEDÁVÁNÍ E-FAKTUR, E-DOKUMENTŮ A ODPOVĚDÍ NA ŽÁDOSTI O AKTIVACI PROSTŘEDNICTVÍM UPLOAD WEBOVÉ SLUŽBY (UPLOADWS) HLAVIČKA METODY POPIS PARAMETRŮ NÁVRATOVÉ KÓDY SLUŽBY Úspěšné volání služby Neúspěšné volání služby KOMUNIKAČNÍ KANÁL SFTP KOMUNIKAČNÍ PROTOKOL SFTP ZABEZPEČENÍ SFTP Varianta 1 - Základní úroveň zabezpečení Varianta 2 - Zvýšená úroveň zabezpečení PŘENOS DAT POMOCÍ ISDS PŘÍLOHY Příloha č. 1 - Definice struktury žádosti o aktivaci (deaktivaci) služby ze strany banky Příloha č. 2 - Definice struktury odpovědi výstavce na žádost o aktivaci (deaktivaci) služby ze strany banky Příloha č. 3 Definice struktury dávky Příklady dávek Příloha č. 4 - Definice struktury podkladů k platbě zaslaná výstavcem Příloha č. 5 - Definice struktury e-dokumentů Příloha č. 6 - Definice struktury notifikačního reportu o přijetí dokumentů do EB Příloha č. 7 WSDL pro UploadWS Příklady volání UploadWS Příloha č. 8 WSDL pro DownloadWS Příklady volání DownloadWS Příloha č. 9 WSDL pro WS UserAccountStatus...83 Datum vydání: duben 2014, aktualizace duben /86

4 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 /86

5 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 (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 /86

6 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 /86

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

8 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 /86

9 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 /86

10 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 /86

11 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 /86

12 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 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 č Formát: SOAP XML zpráva Zabezpečení a autentizace WS je shodné se zabezpečením definovaným v kapitole Žá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 /86

13 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 Pro zajištění unikátnosti doporučujeme používat min. 10 znaků 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 /86

14 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 Vnitřní chyba systému banky Nespecifikovaný problém v systémech banky. Služba je nyní nedostupná 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 Źá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 /86

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

16 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 /86

17 Čí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í 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 /86

18 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) 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ř :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 /86

19 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 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é 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 /86

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

21 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 /86

22 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 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 /86

23 4.3.5 Použité číselníky Čí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 Čí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 /86

24 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 Potvrzení o přijetí dokumentů zaslaných do EB (banka výstavce) Komunikační kanál: WS, SFTP, 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 /86

25 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> </SupplierID> <Batch> <BatchName>Davka_ _1100.xml</BatchName> <StatusCode>10036</StatusCode> <StatusDescription> Nekorektní dávka.</statusdescription> <DeliveryDate> T11: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> </SupplierID> <Document> <DocumentID>FA111111</DocumentID> <UUID>39140CEC D7-C355F9D31665</UUID> <Status> <StatusCode>10000</StatusCode> <StatusDescription> Dokument úspěšně importován </StatusDescription> <DeliveryDate> T11:50:10Z</DeliveryDate> </Status> </Document> </Notification> <Notification> <BankCode>0800</BankCode> <SupplierID> </SupplierID> <Document> <DocumentID>FA111112</DocumentID> <UUID>6940AD61-4D10-4BAC-802A-98773B344FBF</UUID> <Status> <StatusCode>10004</StatusCode> <StatusDescription>Nezadáno datum splatnosti / platnosti </StatusDescription> <DeliveryDate> T11:50:15Z</DeliveryDate> </Status> </Document> </Notification> </Message> Datum vydání: duben 2014, aktualizace duben /86

26 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 /86

27 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> </SupplierID> <Document> <DocumentID>FA111111</DocumentID> <UUID>39140CEC D7-C355F9D31665</UUID> <ReadingDate> T17:20:35Z </ReadingDate> </Document> </Notification> </Message> Číselník stavů zpracování dokumentů zaslaných do EB StatusCode Text stavu Dokument úspěšně importován Neplatné číslo účtu klienta Neplatný kód banky klienta Nezadána fakturovaná částka k zaplacení u e-faktury Nezadáno datum splatnosti / platnosti Neplatná identifikace výstavce Nesprávný/neúplný formát dat Neplatný elektronický podpis Neplatné číslo účtu výstavce Neplatný kód banky výstavce Neplatná fakturovaná částka Neplatné datum splatnosti Neplatný Variabilní symbol Neplatný Konstantní symbol Neplatný Specifický symbol Dokument překročil velikost 400KB Neplatný formát faktury Klient nemá k účtu EB Neplatný prefix čísla účtu výstavce Neplatný IBAN výstavce Neplatný prefix čísla účtu klienta Neplatný IBAN klienta Neplatný obsah položky typu e-dokumentu (není v seznamu povolených hodnot číselníku) Neplatná měna Nekorektní dávka Číslo účtu klienta není vyplněno IBAN klienta nepatří k účtu Nevyplněn účet výstavce IBAN výstavce nepatří k účtu Popis dokumentu (položka note) příliš dlouhá nebo nekorektní Příliš velká dávka (nad 2GB) Datum vydání: duben 2014, aktualizace duben /86

28 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í Integer je dán Base64Binary je dán DateTime je dán 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 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 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 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 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 /86