Standard elektronické fakturace - Popis rozhraní pro zasílání e-faktur a e-dokumentů koncovým spotřebitelům do aplikací elektronického bankovnictví

Standard ČBA_29

Standard elektronické fakturace - Popis rozhraní pro zasílání e-faktur a e-dokumentů koncovým spotřebitelům do aplikací elektronického bankovnictví

Datum vydání: leden 2014

1/38

STANDARD ELEKTRONICKÉ FAKTURACE – POPIS ROZHRANÍ PRO ZASÍLÁNÍ E-FAKTUR A E-DOKUMENTŮ KONCOVÝM SPOTŘEBITELŮM DO APLIKACÍ ELEKTRONICKÉHO BANKOVNICTVÍ

OBSAH ÚVOD........................................................................................................................................................................... 5 VYUŽITÍ ...................................................................................................................................................................... 6 VÝCHODISKA ............................................................................................................................................................. 7 ROZSAH ....................................................................................................................................................................... 7 PRAVIDLA ................................................................................................................................................................... 8 POPIS ......................................................................................................................................................................... 10 6.1 AKTIVACE / DEAKTIVACE ZE STRANY VÝSTAVCE .................................................................................... 10 6.1.1 Žádost o aktivaci / deaktivaci nebo zjištění stavu účtu (výstavce → banka) ................................................ 10 6.1.2 Odpověď na žádost o aktivaci / deaktivaci nebo o zjištění stavu účtu (výstavce → banka) ........................ 11 6.2 AKTIVACE / DEAKTIVACE ZE STRANY BANKY .......................................................................................... 13 6.2.1 Źádost o aktivaci / deaktivaci (banka → výstavce) ...................................................................................... 13 6.2.2 Odpověď na žádost o aktivaci / deaktivaci (výstavce → banka) .................................................................. 14 6.2.2.1 Číselník pro důvod neprovedení aktivace služby na straně výstavce ..................................................... 14 6.3 VÝMĚNA DAT ................................................................................................................................................. 15 6.3.1 Zaslání podkladů k platbě a doručení faktur do EB (výstavce → banka) .................................................... 15 6.3.1.1 Číselníky pro typ dokumentu e-faktura.................................................................................................... 18 6.3.2 Definice množiny položek pro metadata PDF pro e-faktury......................................................................... 19 6.3.3 Zaslání e-dokumentů do EB (výstavce → banka) ....................................................................................... 20 6.3.3.1 Definice množiny položek pro metadata PDF pro e-dokumenty ............................................................. 22 6.3.3.2 Číselník pro typ dokumentu e-dokument plněný do položky BankDocumentType.................................. 22 6.3.4 Potvrzení o přijetí dokumentů zaslaných do EB (banka → výstavce).......................................................... 23 6.3.4.1 Číselník stavů zpracování dokumentů zaslaných do EB......................................................................... 24 7 PŘEDÁVÁNÍ ŽÁDOSTÍ O AKTIVACI ZE STRANY BANKY A NOTIFIKAČNÍCH REPORTŮ PROSTŘEDNICTVÍM DOWNLOAD WEBOVÉ SLUŽBY (DOWNLOADWS) ........................................................................................................ 25 7.1 DATOVÉ TYPY ................................................................................................................................................ 25 7.2 OPERACE PRO HROMADNÉ STAHOVÁNÍ DOKUMENTŮ ............................................................................. 25 7.2.1 Hlavička ....................................................................................................................................................... 25 7.2.2 Popis parametrů požadavku ........................................................................................................................ 25 7.2.3 Popis parametrů odpovědi........................................................................................................................... 26 7.3 OPERACE PRO OZNAČENÍ DOKUMENTŮ K OPĚTOVNÉMU STAŽENÍ ......................................................... 26 7.3.1 Operace pro označení dokumentů pomocí časového intervalu ................................................................... 26 7.3.1.1 Hlavička .................................................................................................................................................. 26 7.3.1.2 Popis parametrů požadavku ................................................................................................................... 26 7.3.2 Popis parametrů odpovědi markDocumentsByTimeRange ......................................................................... 27 7.4 KOMUNIKACE S WEBOVOU SLUŽBOU ......................................................................................................... 27 7.4.1 Zabezpečení a autentizace ......................................................................................................................... 27 7.4.2 Přenosové protokoly .................................................................................................................................... 27 7.4.3 MTOM kódování. ......................................................................................................................................... 27 8 PŘEDÁVÁNÍ E-FAKTUR, E-DOKUMENTŮ A ODPOVĚDÍ NA ŽÁDOSTI O AKTIVACI PROSTŘEDNICTVÍM UPLOAD WEBOVÉ SLUŽBY (UPLOADWS) ..................................................................................................................................... 28 8.1 DATOVÉ TYPY ................................................................................................................................................ 28 8.2 HLAVIČKA METODY ...................................................................................................................................... 28 8.3 POPIS PARAMETRŮ ........................................................................................................................................ 28 8.4 NÁVRATOVÉ KÓDY SLUŽBY ........................................................................................................................ 29 8.4.1 Úspěšné volání služby................................................................................................................................. 29 1 2 3 4 5 6


2/38

Neúspěšné volání služby............................................................................................................................. 29 8.4.2 8.5 KOMUNIKACE S WEBOVOU SLUŽBOU ......................................................................................................... 30 8.5.1 Zabezpečení a autentizace ......................................................................................................................... 30 8.5.2 Přenosové protokoly .................................................................................................................................... 30 8.5.3 MTOM kódování. ......................................................................................................................................... 30 9 PŘÍLOHY ................................................................................................................................................................... 31 9.1 Příloha č.1 - Definice struktury žádosti o aktivaci (deaktivaci) služby ze strany banky ............................................... 31 9.2 Příloha č.2 - Definice struktury odpovědi výstavce na žádost o aktivaci (deaktivaci) služby ze strany banky ................ 33 9.3 Příloha č.3 - Definice struktury podkladů k platbě zaslaná výstavcem ...................................................................... 35 9.4 Příloha č.4 - Definice struktury e-dokumentů ........................................................................................................ 36 9.5 Příloha č.5 - Definice struktury notifikačního reportu o přijetí dokumentů do EB ...................................................... 37


3/38

VYSVĚTLIVKY Název EB WS IBAN BIC

Popis Elektronické bankovnictví webová služba International Bank Account Number Bank Identifier Code

ISDOC

Information System Document - standard pro elektronickou fakturaci v ČR, který definovalo sdružení SPIS (nyní ICT Unie) krátká struktura XML vycházející z plného formátu ISDOC_v6 Business-To-Customer/Consumer – v kontextu tohoto dokumentu se jedná o elektrnonickou komunikaci mezi výstavci a koncovými spotřebiteli prostřednictvím kanálů EB jakýkoli dokument s platební instrukcí (faktura, zálohová platba, upomínka...) jakýkoli dokument bez platební instrukce (smlouva, informace, potvrzení, ...) e-faktura nebo e-dokument společnost, která je v příslušné bance registrovaná jako společnost, která může zasílat do EB dokumenty pro koncové spotřebitele klient příslušné banky s možností přijímat dokumenty prostřednictvím elektronického bankovnictví

B2C-ISDOC_v1 B2C

E-FAKTURA E-DOKUMENT DOKUMENT VÝSTAVCE KONCOVÝ SPOTŘEBITEL (ZÁKAZNÍK, KLIENT) JPÚ WS SFTP ISDS


jednorázový příkaz k úhradě webová služba Secure File Transfer Protocol informační systém datových schránek

4/38

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 popisuje rozhraní pro zasílání e-faktur a e-dokumentů koncovým spotřebitelům do aplikací elektronického bankovnictví (dále jen „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.


5/38

2

VYUŽITÍ

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.


6/38

3

VÝCHODISKA

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 ISDOC, formát elektronické fakturace v ČR.

4

•

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

ROZSAH

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 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 - pro zasílání 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í faktur do EB (výstavce → banka) b) Potvrzení o přijetí faktur do EB (banka → výstavce)


7/38

5

PRAVIDLA

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í dva údaje: •

identifikační číslo(a) zákazníka pod kterým je evidován u výstavce (např. zákaznické číslo, číslo smlouvy, číslo odběrného místa apod.),

•

číslo bankovního účtu zákazníka (pod kterým si aktivoval službu).

Podporované typy formátů zasílaných dokumentů a příloh: • Zjednodušený formát B2C-ISDOC_v1 nebo ISDOC_v6 a 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 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 nebo . • 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 . Je-li vyplněn hodnotou dle číselníku (např. 1 Faktura – daňový doklad) jedná se o e-fakturu. Je-li prázdný jedná se o e-dokument dále specifikovaný v elementu .


8/38

• Při použití WS, kde je možné lépe specifikovat požadavek, je typ dokumentu rovněž specifikován (1 – e-faktura, 2 – e-dokument), což umožní WS rychleji obsloužit požadavek bez nutnosti analyzovat strukturovaná data. • Při použití SFTP či ISDS, tj. tam, kde taková možnost není, je tedy nutné určit typ dokumentu výše uvedeným postupem. V případě SFTP je však ještě možné vyhradit jednotlivým typům dokumentů samostatné adresáře a zjednodušit tak zpracování příchozích dokumentů.

Generování jednorázových platebních příkazů k úhradě (JPÚ) Generování JPÚ v EB je dán čí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í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.


9/38

6

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

AKTIVACE / DEAKTIVACE ZE STRANY VÝSTAVCE

Aktivace a deaktivace služby ze strany výstavce je řešena následovně: • Způsob: web service na straně banky • Formát: web service WSDL 6.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ů 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.

Datum vydání: leden 2014 10/38

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í bankovní účet a ClientOnTargetConsolidator

-

ClientOnTargetConsolidator je povinná položka obsahující referenční číslo (čísla) klienta 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 1 2

-

6.1.2

dokumentů pro uvedený

Popis Změna na žádost klienta 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ů. 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 0 1

Popis OK, změna proběhla úspěšně. Účet může využívat službu a pro dané ClientOnTargetConsolidator je aktivní. Lze poslat efakturu nebo e-dokument.


2

3

-1

Úč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. Účet má službu zablokovanou. Nelze poslat e-fakturu ani e-dokument. Také nelze změnit status klienta ze strany výstavce. Chyba, response obsahuje element StatusErrorDescription, kde je chyba vydefinována.

Návratové chybové kódy v elementu StatusErrorDescription pro Status -1: ErrorCode -1 -2 -3 -4

ErrorDescription Neexistující nebo zablokovaný účet výstavce Nevalidní request Účet klienta nebyl nalezen

-5

Pro účet klienta nebylo nalezeno ClientOnTargetConsolidator pro deaktivaci Nebylo možno změnit status u klienta

-6

Status klienta byl již změněn

-1000

Vnitřní chyba systému banky


Vysvětlení Výstavce použil špatné jméno/heslo nebo má účet zablokovaný. Request není správně vyplněn. Účet klienta nebyl v systému banky nalezen nebo neumožňuje službu. Pro zadanou kombinaci účtu klienta a SupplierID nebyl nalezen záznam, který by umožnil deaktivaci. Status klienta pro požadované SupplierID nebylo možné změnit. Možnost změny může být blokována. Status klienta pro zadané SupplierID je již změněn na požadovanou hodnotu. Nespecifikovaný problém v systémech banky. Služba je nyní nedostupná.

6.2

AKTIVACE / DEAKTIVACE ZE STRANY BANKY

Aktivace a deaktivace služby ze strany banky je řešena následovně: • Způsob: web service na straně banky • Formát: web service WSDL

6.2.1

Źádost o aktivaci / deaktivaci (banka → výstavce)

Struktura žádosti o aktivaci (deaktivaci) služby ze strany banky:


6.2.2

Odpověď na žádost o aktivaci / deaktivaci (výstavce → banka)

Struktura odpovědi výstavce na žádost o aktivaci (deaktivaci) služby ze strany banky:

6.2.2.1

Číselník pro důvod neprovedení aktivace služby na straně výstavce

StatusCode StatusDescription

Význam

01

Služba je již aktivní

Klient se opakovaně snaží zaktivovat již aktivní službu u výstavce.

03

V jeden den více požadavků

V jeden den klient podal více požadavků na aktivaci/deaktivaci a výstavce není schopen rozlišit poslední status.

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 Nekompatibilní služba

Klient ukončil vztah s výstavcem.

08


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.

6.3

VÝMĚNA DAT

Tato podkapitola řeší zasílání dokumentů a potvrzování jejich přijetí. 6.3.1

Zaslání podkladů k platbě a doručení faktur do EB (výstavce → banka)

Způsob komunikace: • SFTP • WS • ISDS (implementace tohoto způsobu komunikace je na dohodě s danou bankou) Formát - jednotlivé faktury, nebo dávka faktur: •

XML (B2C-ISDOC_v1 / ISDOC_v6) a PDF nebo

•

pouze XML (B2C-ISDOC / ISDOC) nebo

•

PDF s metadaty v hlavičce.

Vytvoření dávky s daty: Dávku tvoří zip soubor, ve kterém jsou obsaženy jednotlivé dokumenty ve zvoleném formátu + maximálně jedna příloha ve formátu PDF, pokud ji výstavce pro daný typ dokladu vytváří. Příslušnost přílohy ke strukturovaným datům je zřejmá ze sekce SupplementsList. Maximální velikost jedné zipované dávky je 2GB.


Struktura podkladů k platbě zaslaná výstavcem ve formátu B2C-ISDOC:



6.3.1.1

Číselníky pro typ dokumentu e-faktura

Typ dokladu (DocumentType v dokumentu Invoice)

Popis dokladu (BankDocumentType v dokumentu Invoice)

Znaménko u Poznámka částky k zaplacení

1 Faktura bez vyúčtování záloh

1 Faktura – daňový doklad

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

2 Opravný daňový doklad (dobropis) 3 Opravný daňový doklad (vrubopis) 4 Zálohová faktura (nedaňový zálohový list) 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)

+ 5 Zálohová faktura (nedaňový zálohový list) 6 Výzva k platbě 7 Zálohová platba

Generování JPÚ

“+“ Faktura bez vyúčtování záloh

ANO

“+“ Doplatek Faktura s vyúčtováním záloh “-“ Přeplatek Faktura s vyúčtováním záloh "+" Upomínka

ANO

NE

ANO NE ANO ANO

+

ANO + NE -

Pozn. V případě, že e-faktura je hrazena inkasní platební metodou, tak v částce k zaplacení je očekávána hodnota 0,- Kč.


6.3.2

Definice množiny položek pro metadata PDF pro e-faktury

Název položky DocumentType BankDocumentType TargetConsolidator ClientOnTargetConsolidator ClientBankAccount DocumentID UUID IssueDate Note LocalCurrency SupplierID CustomerName ParcialPayment PaidAmount01 PaymentMeansCode01 PaymentDueDate01 BankAccount01 BankCode01 Name01 IBAN01 BIC01 VariableSymbol01 ConstantSymbol01 SpecificSymbol01 ….

Typ položky Integer Integer String String String String String Date String String String String Boolean Decimal Integer Date String String String String String String String String

PaidAmount12 PaymentMeansCode12 PaymentDueDate12 BankAccount12 BankCode12 Name12 IBAN12 BIC12 VariableSymbol12 ConstantSymbol12 SpecificSymbol12

Decimal Integer Date String String String String String String String String


Ekvivalent v B2C-ISDOC DocumentType BankDocumentType TargetConsolidator ClientOnTargetConsolidator ClientBankAccount ID UUID IssueDate Note LocalCurrency AccountingSuplierParty/Party/PartyIdentification/ID AccountingCustomerParty/Party/PartyName/Name PaymentMeans/Payment ParcialPayment=False (default=true) PaymentMeans/Payment/PaidAmount PaymentMeans/Payment/PaymentMeansCode PaymentMeans/Payment/Details/PaymentDueDate PaymentMeans/Payment/Details/BankAccount/ID PaymentMeans/Payment/Details/BankAccount/BankCode PaymentMeans/Payment/Details/BankAccount/Name PaymentMeans/Payment/Details/BankAccount/IBAN PaymentMeans/Payment/Details/BankAccount/BIC PaymentMeans/Payment/Details/VariableSymbol PaymentMeans/Payment/Details/ConstantSymbol PaymentMeans/Payment/Details/SpecificSymbol Položky od PaidAmountNN až SpecificSymbolNN se až 12x opakují. NN nabývá hodnot 01,02,…,12. PaymentMeans/Payment/PaidAmount PaymentMeans/Payment/PaymentMeansCode PaymentMeans/Payment/Details/PaymentDueDate PaymentMeans/Payment/Details/BankAccount/ID PaymentMeans/Payment/Details/BankAccount/BankCode PaymentMeans/Payment/Details/BankAccount/Name PaymentMeans/Payment/Details/BankAccount/IBAN PaymentMeans/Payment/Details/BankAccount/BIC PaymentMeans/Payment/Details/VariableSymbol PaymentMeans/Payment/Details/ConstantSymbol PaymentMeans/Payment/Details/SpecificSymbol

6.3.3

Zaslání e-dokumentů do EB (výstavce → banka)

Způsob: WS, SFTP, ISDS (volitelné) Formát – jednotlivě nebo dávkou: •

XML (B2C-ISDOC_v1 / ISDOC_v6) a PDF

•

PDF s metadaty v hlavičce.

Struktura dat zaslaná výstavcem:



6.3.3.1

Definice množiny položek pro metadata PDF pro e-dokumenty

Název položky DocumentType BankDocumentType TargetConsolidator ClientOnTargetConsolidator ClientBankAccount DocumentID UUID IssueDate Note SupplierID CustomerName

6.3.3.2

Kód 0 A DP DR DS DZ S SM U1 U2 VS VV ZA

Typ položky Integer Integer String String String String String Date String String String

Ekvivalent v B2C-ISDOC DocumentType BankDocumentType TargetConsolidator ClientOnTargetConsolidator ClientBankAccount ID UUID IssueDate Note AccountingSuplierParty/Party/PartyIdentification/ID AccountingCustomerParty/Party/PartyName/Name

Číselník pro typ dokumentu e-dokument plněný do položky BankDocumentType.

Název dokumentu Dokument (neplatební dokument bez rozlišení) Avízo Daňové potvrzení, Daňový doklad k přijaté platbě Detailní rozpis Dopis o stornu Dopis o změně Sdělení, informace Smlouva, dodatek smlouvy 1. Upomínka (neplatební) 2. Upomínka (neplatební) Dopis ve výročí smlouvy Vyúčtování (neplatební) Zápočet, platba zápočtem – nedaňový doklad


6.3.4

Potvrzení o přijetí dokumentů zaslaných do EB (banka → výstavce)

Způsob: WS, SFTP, e-mail, ISDS (volitelné) Formát: XML Struktura potvrzení o přijetí dokumentů zaslaných do EB:


6.3.4.1

Číselník stavů zpracování dokumentů zaslaných do EB

Text stavu Dokument úspěšně importován

Kód stavu 10000

Neplatné číslo účtu klienta

10001

Neplatný kód banky klienta Nezadána fakturovaná částka k zaplacení u platebního dokumentu 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 Soubor 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) Nesouhlasí hodnota podepisování s faktickým stavem (např. není od výstavce podepsáno, ale má být) Neplatná měna Nekorektní dávka, ZIP soubor - dávku nebylo možno rozzipovat, chyba při přenosu Čí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)

10002 10003 10004 10006 10007 10008 10011 10012 10015 10016 10018 10019 10020 10023 10024 10025 10029 10030 10031 10032 10033 10034


10035 10036 10041 10042 10043 10044 10047 10048

7

PŘEDÁVÁNÍ ŽÁDOSTÍ O AKTIVACI ZE STRANY BANKY A NOTIFIKAČNÍCH REPORTŮ PROSTŘEDNICTVÍM DOWNLOAD WEBOVÉ SLUŽBY (DOWNLOADWS)

Cílem této specifikace je definovat webovou službu, která umožní stahování souborů ve formě strukturovaných dat ze systému bank do systému výstavců dokumentů. Jedná se o strukturovaná data žádostí o aktivaci / deaktivaci k elektronickému zasílání dokumentů do EB (přihláška / odhláška) a notifikačních reportů. Dále v textu bude obojí označováno pojmem dokument. 7.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ů.

7.2

OPERACE PRO HROMADNÉ STAHOVÁNÍ DOKUMENTŮ

Operace umožní klientovi hromadně stáhnout všechny nové dokumenty daného typu a formátu. Maximální počet dokumentů, které tato operace umožní stáhnout při jednom volání je 500. Klient má možnost tuto hodnotu snížit uvedením nepovinného parametru. Návratem operace budou dokumenty odpovídající parametrům požadavku. Odpověď bude také obsahovat informace o počtu právě přenášených dokumentů a o počtu nových dokumentů daného typu a formátu, které jsou aktuálně dostupné na serveru. 7.2.1

Hlavička •

public

documentsResponse

getNewDocuments(documentsRequest

documentsRequest)-

Objekty documentsResponse a documentsRequest zapouzdřují data požadavku a odpovědi. 7.2.2

Popis parametrů požadavku

• •

– Objekt zapouzdřující data požadavku. Skládá se z credentials, documentType, formatType, maxDocumentsNumber a attachment.

documentsRequest documentsRequest

credentials credentials – Obsahuje údaje potřebné k autentifikaci uživatele a ověření jeho práv k užívání této služby. Skládá se z username a password.

•

string username

– Uživatelské jméno.

•

string password

– Uživatelské heslo.

•

integer documentType – Identifikuje požadovaný typ dokumentu. Povolené hodnoty a jim odpovídající typy jsou uvedeny v následující tabulce:

Hodnota Typ dokumentu 1 Aktivace/Deaktivace 2 Notifikační report


•

Hodnota 1

•

7.2.3

7.3

1

– Identifikuje požadovaný formát dokumentu. Povolené hodnoty a jim odpovídající formáty jsou uvedeny v následující tabulce.

integer formatType

Formát dokumentu XML

– Udává maximální počet dokumentů, který může operace zaslat v odpovědi. Hodnota maxDocumentsNumber musí být v rozmezí 1 – 500 včetně. Parametr maxDocumentsNumber je nepovinný. Pokud není uveden, operace vrátí maximálně 500 dokumentů.

integer maxDocumentsNumber

Popis parametrů odpovědi

•

documentsResponse documentsResponse

•

integer

•

integer responseDocumentsNumber

•

document[] documents – Zapouzdřuje jeden dokument a potřebné metainformace. Skládá se z documentId, fileName a dataHandler.

– Objekt zapouzdřující data odpovědi. Skládá se z remainingDocumentsNumber, responseDocumentsNumber a libovolného počtu opakování documents. remainingDocumentsNumber – Hodnota udávající, kolik nových dokumentů požadovaného typu a formátu se ještě na serveru nachází.

– Udává počet dokumentů přenášených v odpovědi.

•

integer documentId

•

string fileName

•

base64Binary dataHandler – Element zapouzdřující přenášený XML dokument definovaný příslušným XSD dle typu dokumentu

– Jedinečný identifikátor dokumentu.

– Název souboru.

OPERACE PRO OZNAČENÍ DOKUMENTŮ K OPĚTOVNÉMU STAŽENÍ

Z předchozí zkušenosti vyplývá, že dochází k situacím, kdy výstavce nepřijme zasílaná data korektně. Je tedy užitečné implementovat metodu, která by umožnila v systému banky označit zvolené dokumenty, které již byly jednou staženy, speciálním příznakem umožňujícím jejich opětovné stažení předchozí operací getNewDocuments(). V požadavku výstavce specifikuje dokumenty, které žádá opakovaně stáhnout. V odpovědi obdrží informaci o tom, kolik dokumentů vyhovovalo jeho požadavkům a je připraveno pro opakované stažení. Operace pro označení dokumentů pomocí časového intervalu

7.3.1

Označí ke stažení všechny dokumenty, které byly přijaty systémem od odesílatele ve zvoleném časovém intervalu. 7.3.1.1

Hlavička

•

public markDocumentsResponse markDocumentsByTimeRange(markDocumentsByTimeRangeRequest markDocumentsByTimeRangeRequest) - Objekty markDocumentsResponse

a markDocumentsByTimeRangeRequest zapouzdřují data požadavku a odpovědi.

7.3.1.2

Popis parametrů požadavku

•

markDocumentsByTimeRangeRequest markDocumentsByTimeRangeRequest

– Objekt

zapouzdřující data požadavku. Skládá se z credentials, dateFrom a dateTo. 1

Teoreticky není tento parametr nutný. Do budoucna ale může vzniknout požadavek na jiné formáty než XML, a pak nebude nutné měnit volání WS, ale pouze se rozšíří obor hodnot parametru formatType o další hodnotu.


•

Credentials

•

String username

– Uživatelské jméno.

•

String password

– Uživatelské heslo.

•

dateTime dateFrom

•

dateTime dateTo

7.3.2

– Datum a čas udávající spodní hranici časového intervalu.

– Datum a čas udávající horní hranici časového intervalu.

Popis parametrů odpovědi markDocumentsByTimeRange

• •

7.4

credentials – Obsahuje údaje potřebné k autentifikaci uživatele a ověření jeho práv k užívání této služby. Skládá se z username a password.

markDocumentsResponse markDocumentsResponse – Objekt zapouzdřující data odpovědi. Skládá se z hodnoty markedDocumentsNumber.

– Udává počet dokumentů, které vyhovovaly požadavku a byly označeny příznakem umožňujícím jejich opakované stažení.

Integer markedDocumentsNumber

KOMUNIKACE S WEBOVOU SLUŽBOU

V této kapitole jsou shrnuty základní vlastnosti komunikace s webovou službou. 7.4.1

Zabezpečení a autentizace

Služba bude komunikovat přes HTTPS protokol. Server banky se bude identifikovat certifikátem od důvěryhodné certifikační autority. 7.4.2

Přenosové protokoly

Služba bude dostupná prostřednictvím protokolu SOAP nad protokolem HTTP 1.1 a bude využívat přenosového kódování chunked. 7.4.3

MTOM kódování.

Dokumenty budou poslány uživateli ve formě XML souborů dle příslušného xsd schématu. 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).


8

PŘEDÁVÁNÍ E-FAKTUR, E-DOKUMENTŮ A ODPOVĚDÍ NA ŽÁDOSTI O AKTIVACI PROSTŘEDNICTVÍM UPLOAD WEBOVÉ SLUŽBY (UPLOADWS)

Cílem této specifikace je definovat webovou službu, která umožní zasílání souborů ve formě strukturovaných dat ze systému výstavců dokumentů do systémů bank. Jedná se o strukturovaná data odpovědí na žádosti o aktivaci / deaktivaci k elektronickému zasílání dokumentů do EB (přihláška / odhláška) a notifikačních reportů. Dále v textu bude obojí označováno pojmem dokument. 8.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ů. 8.2

HLAVIČKA METODY •

8.3

public UploadResponseVO upload(UploadRequestVO request)

POPIS PARAMETRŮ •

UploadRequestVO request

•

FileContainerVO[ ] attachments

– objekt požadavku na upload. Je složen z: – seznam příloh pro upload. 2

• String name – jedinečné jméno přílohy • String dataHandler – data přílohy kódovaná •

CredentialsVO credentials • String username • String password

•

v base64

– údaje pro autentizaci

– uživatelské jméno – heslo

FileContainerVO document

– container obsahující dokument pro upload

• String name – jméno dokumentu • String dataHandler – data dokumentu kódovaná v base64 • Int documentType – typ dokumentu

documentType id 1 2 3

Typ dokumentu e-invoice e-document Odpověď na aktivaci

• int formatType – formát souboru.

formatType id 1 2 2

Podporované hodnoty: Formát dokumentu

Jednotlivé faktury ve struktuře B2C-ISDOC (s přílohami mimo nebo bez) Jednotlivé faktury v ISDOC (s přílohami nebo bez)

Přílohy k určitým strukturovaným datům musí mít jedinečné neduplicitní názvy.


formatType id 3 4 5 6 7 8

Formát dokumentu Jednotlivé faktury v ISDOCX (s přílohami uvnitř ISDOCX a nikoli v parametrech WS) Jednotlivé PDF s daty v metadatech PDF Dávka s více PDF s daty v metadatech PDF komprimovaná pomocí metody ZIP.3 Dávka s více B2C-ISDOC strukturami a případně PDF přílohami, komprimovaná pomocí metody ZIP.4 Dávka s více ISDOC strukturami a případně PDF přílohami, komprimovaná pomocí metody ZIP.5 Dávka s více ISDOCX strukturami (s přílohami uvnitř ISDOCX a nikoli v parametrech WS), komprimovaná pomocí metody ZIP.

Je zřejmé, že pro e-dokumenty tj. documentType id = 2 není možné použít formatType id = 4 a 5. Dále CommonDocument struktura B2C-ISDOC bude totožná s CommonDocument strukturou ISDOC/ISDOCX, takže varianty 1, 2 jsou pro eDocument prakticky totožné a varianta 2 je jen jejich zazipovaná verze. Obdobné platí i o formatType id = 6, 7 a 8, kde se jedná jen o dávky formátů 1, 2 a 3.

8.4

NÁVRATOVÉ KÓDY SLUŽBY

8.4.1

Úspěšné volání služby

V případě úspěšného volání služby je stavovou hodnotou přenosového protokolu HTTP hodnota 200 OK. V SOAP zprávě odpovědi je úspěšnost volání potvrzena stavovým kódem v návratovém elementu typu UploadResponseVO. •

UploadResponseVO return

– návratový objekt

• int code – stavový kód • String details – nepovinný popis

Code 0

stavového kódu

Popis Operace byla úspěšně dokončena

Upload Webová služba nevaliduje formální správnost přenášeného dokumentu. Případná chyba v tomto dokumentu nebude klientovi prostřednictvím Upload WS nikterak signalizována. Pro signalizaci tohoto typu chyb je definován notifikační report. 8.4.2

Neúspěšné volání služby

Neúspěšné volání služby zaviněná nekorektní vstupní SOAP zprávou či výjimkou při běhu služby jsou signalizována na úrovni HTTP protokolu takovým stavovým kódem, který nejlépe odpovídá povaze chyby, která nastala. Význam stavových kódů HTTP protokolu je definován v RFC 2616. V těle návratové SOAP zprávy vrátí služba SOAP element Fault typu Fault nesoucí informace o chybě. Datový typ Fault včetně významu jeho prvků jsou definovány v http://www.w3.org/2003/05/soap-envelope/ a http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapfault. • 3 4 5

Fault Fault

– datový typ nesoucí informace o chybě

Vzhledem k tomu, že je každý výstavce při volání WS jednoznačně identifikován není nutné, aby byl k dávce připojen elektronický podpis. Nemělo by dojít k problémům s rozpoznáním, jaké PDF patří ke konkrétnímu B2C-ISDOC, protože strukturovaná data mají v sobě sekci SuplementsList s vyjmenováním příloh a označením grafického obrazu přílohy. Nemělo by dojít k problémům s rozpoznáním, jaké PDF patří ke konkrétnímu ISDOC, protože strukturovaná data mají v sobě sekci SuplementsList s vyjmenováním příloh a označením grafického obrazu přílohy.


• Faultcode – chybový kód • Reason – popis chyby

• Detail – podrobné informace o chybě

Podrobné informace o chybě v elementu detail jsou uloženy v datové struktuře uploadServiceFault. •

UploadServiceFault uploadServiceFault • int errorCode – chybový kód • String errorDescription – popis

errorCode -1 -2 -3 -4 -5 -1000

– návratový kód

chyby

Popis Chyba autentizace uživatele Chyba autorizace uživatele Neplatný dokument Příliš mnoho požadavků na server Duplicitní názvy příloh Jiná chyba

Všechny uvedené chyby mají za důsledek fakt, že přenášený dokument včetně případných příloh nebyl WS přijat. Výstavce je o neúspěchu a jeho příčinách informován na úrovni SOAP nebo HTPP a je jeho odpovědností, aby se po odstranění příčin problému pokusil daný dokument a jeho případné přílohy znovu odeslat na UploadWS.

8.5

KOMUNIKACE S WEBOVOU SLUŽBOU

V této kapitole jsou shrnuty základní vlastnosti komunikace s webovou službou. 8.5.1

Zabezpečení a autentizace

Služba bude komunikovat přes HTTPS protokol. Server banky se bude identifikovat certifikátem od nějaké důvěryhodné certifikační autority. 8.5.2

Přenosové protokoly

Služba bude dostupná prostřednictvím protokolu SOAP nad protokolem HTTP 1.1 a bude využívat přenosového kódování chunked. 8.5.3

MTOM kódování.

Dokumenty budou poslány uživateli ve formě XML souborů dle příslušného xsd schématu. 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).


9 9.1

PŘÍLOHY Příloha č.1 - Definice struktury žádosti o aktivaci (deaktivaci) služby ze strany banky

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="Message"> <xs:annotation> <xs:documentation xml:lang="cs">Kořenový element. <xs:complexType> <xs:sequence> <xs:element name="Subscription" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Element aktivace/deaktivace <xs:complexType> <xs:sequence> <xs:choice> <xs:element name="ClientBankAccount " type="xs:string" nillable="false"> <xs:annotation> <xs:documentation xml:lang="cs">Kompletní číslo bankovního účtu příjemce faktury, tj. předčíslí (6znaků), číslo účtu (10 znaků) a kód banky (4 znaky) <xs:element name="ClientIBANBankAccount"> <xs:annotation> <xs:documentation>Kompletní číslo bankovního účtu příjemce faktury ve formátu IBAN a BIC. <xs:complexType> <xs:sequence> <xs:element name="BIC" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Kód banky podle ISO 9362, tzv. SWIFT kód <xs:element name="IBAN" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Mezinárodní číslo účtu (IBAN)


31/38

<xs:element name="SupplierID" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Identifikace příjemce aktivace. IČO odesílatele faktur. <xs:element name="ClientOnTargetConsolidator" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Identifikátor nebo kombinace více různých identifikátorů klienta v systému výstavce faktur. Tedy např. číslo smluvního účtu. <xs:element name="Activate" type="xs:integer"> <xs:annotation> <xs:documentation xml:lang="cs">Aktivace – 1 / Deaktivace – 0 <xs:element name="Created" type="xs:dateTime"> <xs:annotation> <xs:documentation xml:lang="cs">Datum aktivace nebo deaktivace ve formátu YYYY-MM-DDTHH:MM:SSZ. Čas je v časové zóně UTC. <xs:element name="refNumTran" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Referenční číslo transakce. banky


32/38

9.2

Příloha č.2 - Definice struktury odpovědi výstavce na žádost o aktivaci (deaktivaci) služby ze strany banky

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="Message"> <xs:annotation> <xs:documentation xml:lang="cs">Kořenový element <xs:complexType> <xs:sequence> <xs:element name="ActivationAnswer" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Element aktivace/deaktivace <xs:complexType> <xs:sequence> <xs:choice> <xs:element name="ClientBankAccount " type="xs:string" nillable="false"> <xs:annotation> <xs:documentation xml:lang="cs">Kompletní číslo bankovního účtu příjemce faktury, tj. předčíslí (6znaků), číslo účtu (10 znaků) a kód banky (4 znaky) <xs:element name="ClientIBANBankAccount"> <xs:annotation> <xs:documentation>Kompletní číslo bankovního účtu příjemce faktury ve formátu IBAN a BIC. <xs:complexType> <xs:sequence> <xs:element name="BIC" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Kód banky podle ISO 9362, tzv. SWIFT kód <xs:element name="IBAN" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Mezinárodní číslo účtu (IBAN)


33/38

<xs:element name="SupplierID" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Identifikace příjemce aktivace. IČO odesílatele faktur. <xs:element name="ClientOnTargetConsolidator" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Identifikátor nebo kombinace více různých identifikátorů klienta v systému výstavce faktur. Tedy např. číslo smluvního účtu. <xs:element name="Activated" type="xs:integer"> <xs:annotation> <xs:documentation xml:lang="cs">Aktivováno – 1 / Neaktivováno – 0 <xs:element name="StatusCode" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="cs">Důvod neaktivace <xs:element name="StatusDescription" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="cs">Důvod neaktivace <xs:element name="Created" type="xs:dateTime"> <xs:annotation> <xs:documentation xml:lang="cs">Datum aktivace nebo deaktivace ve formátu YYYY-MM-DDTHH:MM:SSZ. Čas je v časové zóně UTC. <xs:element name="refNumTran" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Referenční číslo transakce.


34/38

9.3

Příloha č.3 - Definice struktury podkladů k platbě zaslaná výstavcem

Příloha č.3 bude doplněna po vydání odsouhlasené struktury ISDOC v6 ze strany ICT Unie.


35/38

9.4

Příloha č.4 - Definice struktury e-dokumentů

Příloha č.4 bude doplněna po vydání odsouhlasené struktury ISDOC v6 ze strany ICT Unie.


36/38

9.5

Příloha č.5 - Definice struktury notifikačního reportu o přijetí dokumentů do EB

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="Message"> <xs:annotation> <xs:documentation xml:lang="cs">Kořenový element <xs:documentation xml:lang="en">root element <xs:complexType> <xs:sequence> <xs:element name="Notification" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Notifikační zpráva <xs:complexType> <xs:sequence> <xs:element name="BankCode" type="xs:string"> <xs:annotation> <xs:documentation>Kód přijímající banky <xs:element name="SupplierID" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">IČO výstavce <xs:element name="DocumentID" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Lidsky čitelné číslo dokladu


37/38

<xs:element name="UUID" type="xs:string" nillable="false"> <xs:annotation> <xs:documentation xml:lang="cs">GUID identifikace od emitujícího systému <xs:choice> <xs:element name="Status"> <xs:complexType> <xs:sequence> <xs:element name="StatusCode" type="xs:integer"> <xs:annotation> <xs:documentation xml:lang="cs">Identifikace stavu zpracování <xs:element name="StatusDescription" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="cs">Popis stavu zpracování <xs:documentation xml:lang="en">invoice number <xs:element name="DeliveryDate" type="xs:dateTime"> <xs:annotation> <xs:documentation xml:lang="cs">Datum a čas zpracování ve formátu YYYY-MM-DDTHH:MM:SSZ. Čas je v časové zóně UTC. <xs:element name="ReadingDate" type="xs:dateTime"> <xs:annotation> <xs:documentation xml:lang="cs">Datum a čas přečtení ve formátu YYYY-MM-DDTHH:MM:SSZ. Čas je v časové zóně UTC.


38/38

Standard elektronické fakturace - Popis rozhraní pro zasílání e-faktur a e-dokumentů koncovým spotřebitelům do aplikací elektronického bankovnictví

Recommend Documents