Copyright © 2022 MVČR
Copyright © 2014 ICT UNIE o.s.
23. března 2022
TaxTotal
a
TaxSubTotal
LegalMonetaryTotal
isdoc-6.0.2.sch
Tento dokument definuje formáty pro elektronickou fakturaci souhrnně označované zkratkou
ISDOC. Formát byl původně definován pracovní skupinou pro elektronické standardy výměny dat
ICT Unie o.s.. Nyní se o další rozvoj a údržbu
formátu stará Ministerstvo vnitra České Republiky. Veškeré připomínky a dotazy k formátu a
jeho specifikaci zasílejte na adresu isdoc@mvcr.cz
.
Pokud si myslíte, že je ve specifikaci formátu chyba,
nahlaste ji pomocí https://github.com/isdoc/schema/issues.
V současné verzi ISDOC definuje formát pro fakturu a neplatební dokument, v dalších verzích může být přidána podpora pro další formáty.
Pokud se v textu nebo v příkladech objevují prefixy jmenných prostorů, platí pro ně následující mapování na jmenný prostor.
Prefix | Jmenný prostor |
---|---|
isdoc |
http://isdoc.cz/namespace/2013 |
manifest |
http://isdoc.cz/namespace/2013/manifest |
dsig |
http://www.w3.org/2000/09/xmldsig# |
xades |
http://uri.etsi.org/01903/v1.3.2# |
Standard ISDOC definuje shodu pro dokumenty, konzumenty a producenty.
Standard ISDOC definuje následující typy dokumentů:
daňový doklad – souhrnně označuje fakturu, opravný daňový doklad (dobropis), opravný daňový doklad (vrubopis), zálohovou fakturu (nedaňový zálohový list), daňový doklad při přijetí platby (daňový zálohový list), opravný daňový doklad při přijetí platby (dobropis daňového zálohového listu)a zjednodušený daňový doklad;
neplatební dokument.
Dokument ISDOC musí splňovat následující požadavky:
Musí být reprezentován v souladu s požadavky definovanými v části 3 – „Reprezentace dokumentu“.
Musí být jedním z typů dokumentů definovaných v tomto standardu:
Pokud se jedná o daňový doklad, musí být validní vůči schématu uvedenému v části
B.1 – „Schéma pro daňový doklad – isdoc-invoice-6.0.2.xsd
“ a jako kořenový element musí být použit element
Invoice
.
Pokud se jedná o neplatební dokument, musí být validní vůči schématu uvedenému
v části B.2 – „Schéma pro neplatební dokument – isdoc-commondocument-6.0.2.xsd
“ a jako kořenový element musí být
použit element
CommonDocument
.
Musí splňovat pravidla definovaná v části 4 – „Pravidla“.
Pokud je dokument opatřen digitálním podpisem, musí splňovat požadavky definované v části 5 – „Digitální podpisy“.
Pokud je dokument opatřen časovým razítkem, musí splňovat požadavky definované v části 6 – „Časové razítko“.
Konzument ISDOC je program, který načítá a zpracovává dokument ISDOC v souladu se sémantikou definovanou v tomto standardu. Konzument musí být schopen načíst a zpracovat alespoň jeden typ dokumentů ISDOC.
Konzument ISDOC musí být opatřen dokumentací, která vyjmenovává jaké typy dokumentů ISDOC a jaké verze standardu ISDOC jsou podporovány.
Producent ISDOC je program, který generuje dokument ISDOC v souladu se sémantikou definovanou v tomto standardu. Producent musí být schopen generovat alespoň jeden typ dokumentů ISDOC.
Producent ISDOC musí být opatřen dokumentací, která vyjmenovává jaké typy dokumentů ISDOC a jaké verze standardu ISDOC jsou podporovány.
Dokument ISDOC musí být reprezentován jako samostatný dokument XML, jako PDF/A-3 dokument
(tzv. ISDOC.PDF) nebo jako archiv. Pro samostatné dokumenty je doporučeno používat příponu
.isdoc
a pro archivy .isdocx
. Jméno dokumentů
ISDOC.PDF by mělo být zakončeno řetězcem -isdoc.pdf
.
Samostatný dokument je preferovaná forma pro výměnu dokumentů ISDOC. Je vhodná například při komunikaci pomocí webových služeb či pro zasílání dokumentů pomocí elektronické pošty nebo datových schránek. Reprezentace pomocí archivu je vhodná v případech, kdy chceme kromě samotného dokladu přenášet i další související přílohy jako jeden celek. Reprezentace ISDOC.PDF je vhodná v případě, kdy chceme příjemci dokladu umožnit snadnou vizuální kontrolu a přitom zachovat možnost strojového zpracování. ISDOC.PDF dovoluje i přenos souvisejících příloh.
ISDOC musí být well-formed dokument XML tak jak definuje specifikace [XML] a musí být uložen v kódování UTF-8.
ISDOC.PDF dokument musí splňovat všechny požadavky formátu PDF/A-3a, tak jak je definuje [ISO 19005-3], a navíc musí dodržet všechny následující požadavky:
Do ISDOC.PDF dokumentu je vložen dokument ISDOC využívající XML reprezentaci (3.1 – „Dokument XML“). Vložený dokument musí být pojmenovaný
invoice.isdoc
.
Pokud je příjemcem dokumentu veřejná správa, je do ISDOC.PDF dokumentu vložen soubor
pojmenovaný metadata-invoice-nsessl.xml
, který obsahuje metadata
nezbytná pro automatický příjem dokumentu do elektronické spisové služby. Obsah souboru
s metadaty musí splňovat požadavky definované v Národním standardu (§ 70, odst. 2 zákona
č. 499/2004 Sb.).
Dokument ISDOC.PDF může obsahovat další vložené dokumenty a soubory.
Pro vložení dokumentu ISDOC a případných metadat a příloh dokladu se musí používat
slovník File Specification Dictionary (viz [ISO 32000-1], sekce 7.11.3). Ten přitom musí být odkazován pomocí položky
AF
ze slovníku Catalog
(viz [ISO 19005-3],
příloha E.3). Zároveň musí být každý vložený soubor uveden i ve slovníku Name
Dictionary (viz [ISO 32000-1], sekce 7.7.4) ve stromu jmen
odkazovaném pomocí položky EmbeddedFiles
. Tím se zajistí, že běžné prohlížeče
PDF zobrazí vložené soubory jako přílohy.
Pro každý vložený soubor musí odpovídající objekt slovníku obsahovat minimálně položky uvedené v tabulce 1 – „Povinné položky ve slovníku popisujícím vložený soubor“.
Klíč | Hodnota |
---|---|
/Type |
Vždy /Filespec |
/F |
Jméno souboru. Pro vložený dokument ISDOC je to vždy
invoice.isdoc , pro metadata pro veřejnou správu je to vždy
metadata-invoice-nsessl.xml . Pro ostatní vložené soubory je
to jejich jméno.
|
/UF |
Jméno souboru. Obsahuje stejnou hodnotu jako položka F .
|
/AFRelationship |
Popisuje vztah vloženého souboru k dokumentu PDF. Přípustné jsou následující hodnoty:
|
/EF |
Slovník, který obsahuje položky F a UF , které
obsahují vložený souborový proud (viz [ISO 32000-1], sekce
7.11.4). Slovník souborového proudu musí povinně obsahovat položky uvedené
v tabulce 2 – „Povinné položky ve slovníku popisujícím souborový proud“.
|
Klíč | Hodnota |
---|---|
/Type |
Vždy /EmbeddedFile |
/SubType |
Typ internetového média pro vložený soubor. Pro dokument ISDOC a metadata
veřejné správy se vždy použije hodnota |
Pokud dokument ISDOC odkazuje na přílohy (element Supplement
), tak se
přílohy vloží jako soubory do dokumentu PDF. Z dokumentu ISDOC se pak na vložené soubory
odkazuje pomocí identifikátoru fragmentu ve tvaru #ef=jméno
souboru
. Např.:
... <Supplement> <Filename>#ef=OBCHODNI_PODMINKY.DOCX</Filename> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>Gm9hyD0uRKiUN3VOY7X0OIB1+DU=</DigestValue> </Supplement> ...
Archiv obsahující dokument ISDOC musí používat formát ZIP tak jak jej definuje specifikace [APPNOTE] a navíc musí dodržet všechny následující požadavky:
Soubory uložené v archivu musí být nekomprimované nebo musí používat kompresní metodu „deflate“ popsanou v [RFC1951].
Archiv nesmí používat šifrování.
Archiv nesmí používat digitální podpisy.
Archiv nesmí používat funkci „patch data“.
Archiv nesmí být rozdělen do více souborů.
Jména souborů musí být uložena v kódování UTF-8 a musí být nastaven příznak „Language encoding flag“ (bit 11).
Archiv musí v kořenovém adresáři obsahovat soubor manifest.xml
obsahující manifest.
Manifest je jednoduchý dokument XML, který slouží k snadnému a rychlému nalezení
dokumentu ISDOC v archivu. Elementy uvnitř manifestu musí být ve jmenném prostoru
http://isdoc.cz/namespace/2013/manifest
. Manifest musí obsahovat kořenový
element manifest
a ten musí obsahovat právě jeden element
maindocument
, který v atributu filename
určuje
umístění dokumentu ISDOC uvnitř archivu.
manifest.xml
<?xml version="1.0"?> <manifest xmlns="http://isdoc.cz/namespace/2013/manifest"> <maindocument filename="FV2013-042.isdoc"/> </manifest>
Starší verze formátu ISDOC nepodporovaly manifest (do verze 5.x včetně). Pro
zajištění zpětné kompatibility je doporučeno, aby aplikace v případě chybějícího
manifestu za hlavní dokument ISDOC v archivu považovala soubor v hlavním adresáři
archivu, který má příponu .isdoc
.
Jednotlivé typy dokumentů ISDOC musí splňovat následující pravidla. Některá
z následujících pravidel lze kontrolovat strojově pomocí schématu v jazyce Schematron.
Odpovídající schéma je v příloze C – „Schéma pro kontrolu vybraných pravidel – isdoc-6.0.2.sch
“.
Pro typ dokladu 2, 3 a 6 musí existovat vazba na původní doklad. Konkrétně tedy pro
DocumentType
= 2, 3, 6 musí existovat element
OriginalDocumentReference
a musí byt neprázdný.
Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy.
Konkrétně: pokud existuje element ForeignCurrencyCode
, pak musí existovat
všechny elementy s částkami pro cizí měnu tj. ty končící na Curr
.
Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud
neexistuje element ForeignCurrencyCode
, pak nesmí existovat žádný element pro
cizí měnu, tj. element končící na Curr
. Položky s kursem (CurrRate
i RefCurrRate
) musí být rovny hodnotě 1.
U dokladu v zahraniční měně nesmí být měna lokální a zahraniční shodné. Konkrétně
hodnota povinné položky LocalCurrencyCode
se nesmí rovnat hodnotě nepovinné
položky ForeignCurrencyCode
.
Je-li doklad nedaňový (element VATApplicable
obsahuje hodnotu
false
), musejí být i všechny jeho řádkové položky nedaňové, tedy
element VATApplicable
uvnitř elementu ClassifiedTaxCategory
rovněž
obsahuje hodnotu false
. Obráceně to však neplatí – na dokladu
podléhajícím DPH mohou být jednotlivé položky, které nejsou v evidenci DPH.
Jednotka v rozpisu všech šarží/sériových čísel (element StoreBatches
) musí
být stejná jako jednotka pro množství na řádce faktury. Jednotky u šarží jedné řádky
faktury musí být stejné. Pokud atribut pro jednotku v rozpisu šarží/sériových čísel není
uveden, tak se předpokládá, že je množství uvedeno ve stejné jednotce jako množství na
řádce faktury.
Součet Quantity
ze všech záznamů rozpisu šarží/sériových čísel musí
odpovídat InvoicedQuantity
dané řádky faktury.
Nepovinnou položku SecondarySellersItemIdentification
lze uvést pouze
v případě, že je uvedena také položka SellersItemIdentification
.
Nepovinnou položku TertiarySellersItemIdentification
lze uvést pouze
v případě, že jsou uvedeny také položky SellersItemIdentification
a
SecondarySellersItemIdentification
.
Element SubDocumentTypeOrigin
musí obsahovat pouze hodnoty uvedené
v tabulce 3 – „Přípustné hodnoty pro element SubDocumentTypeOrigin
“.
SubDocumentTypeOrigin
Hodnota | Popis | Definice číselníku | Přidáno |
---|---|---|---|
CBA |
Česká bankovní asociace | viz [ČBA-STD-29] | 1. ledna 2014 |
Element SubDocumentTypeOrigin
musí obsahovat pouze hodnoty uvedené
v tabulce 3 – „Přípustné hodnoty pro element SubDocumentTypeOrigin
“.
Digitální podpis musí být v souladu s doporučením [XMLDSig-Core].
Digitální podpis musí používat transformaci Enveloped
Signature a být uložen v elementu Signature
ze jmenného prostoru
http://www.w3.org/2000/09/xmldsig#
, který je vždy posledním elementem
uvnitř kořenového elementu dokument ISDOC (např. Invoice
).
Je doporučeno, aby kromě transformace Enveloped
Signature byla použita i transformace XPath, která umožní
pozdější přidání dalších podpisů tím, že podpisy samotné se vynechají z podepisování
pomocí XPath filtru not(ancestor-or-self::dsig:Signature)
.
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="Signature-1"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <XPath>not(ancestor-or-self::dsig:Signature)</XPath> </Transform> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>GRhVFHn8P5AoMcL0y1RJ4ICVRQZKdW+hcxo3gz8gvCc=</DigestValue> </Reference> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>...</X509Certificate> </X509Data> </KeyInfo> </Signature>
Je doporučeno, aby každý připojený digitální podpis obsahoval unikátní identifikátor
uvnitř atributu Id
. Hodnota identifikátoru musí odpovídat
produkčnímu pravidlu Name
tak, jak jej definuje specifikace [XML].[1]
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
Id="Signature-1">
...
</Signature>
Jako algoritmus pro výpočet otisku dokumentu se musí používat algoritmus z rodiny SHA-2. Algoritmus musí být identifikován v souladu s [RFC4051].
Podpis musí být v souladu s požadavky definovanými v 5.1 – „Požadavky na digitální podpis v dokumentu ISDOC“.
Musí být použita transformace XPath a to následujícím způsobem:
První podpis používá filtr
not(ancestor-or-self::dsig:Signature)
.
Další podpisy používají filtr not(ancestor-or-self::dsig:Signature) or
not(ancestor-or-self::dsig:Signature/preceding-sibling::dsig:Signature[N-1])
,
kde N je pořadí přidávaného podpisu (číslované od
jedna).
Do verze ISDOC 5.3.x mohly aplikace produkovat vícenásobné „enveloped“ podpisy bez použití transformace XPath. Selže-li jejich ověření standardním postupem, postupuje se následovně:
Pokud dokument obsahuje alespoň jeden digitální podpis, ověří se poslední digitální podpis.
Poslední digitální podpis (element Signature
) se z dokumentu odstraní a
s takto upraveným dokumentem se opakuje krok 1.
Dokument ISDOC musí obsahovat digitální podpis v souladu s 5.1 – „Požadavky na digitální podpis v dokumentu ISDOC“ a rozhodnutím komise [2011/130/EU].
Digitální podpis, který je předmětem časového razítka, musí obsahovat unikátní
identifikátor uvnitř atributu Id
elementu
Signature
.
Časové razítko musí být ve formě XAdES-T v souladu se specifikací [XAdES].
Digitální podpis, který je předmětem časového razítka, musí obsahovat podpisový
certifikát uvnitř elementu KeyInfo
(viz sekce 4.4.1 [XAdES]) a otisk podpisového certifikátu musí být součástí podepisovaných dat.[2]
Autoritě časového razítka se posílá otisk hodnoty digitálního podpisu v elementu
SignatureValue
.[3] Pro výpočet otisku musí být použit algoritmus z rodiny SHA-2.[4]
Časové razítko obdržené od autority časového razítka musí být uloženo v elementu
EncapsulatedTimeStamp
ve formátu ASN.1 zakódovaném v DER a následně pomocí
base64. Časové razítko musí vyhovovat formátu definovanému produkčním pravidlem
TimeStampToken
dle [RFC3161].
<?xml version="1.0" encoding="utf-8"?> <Invoice xmlns="http://isdoc.cz/namespace/2013" version="5.2.2"> <DocumentType>1</DocumentType> ... samotný obsah faktury ve formátu ISDOC ... <Signature❶ xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <XPath>not(ancestor-or-self::dsig:Signature)</XPath> </Transform> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>GRhVFHn8P5AoMcL0y1RJ4ICVRQZKdW+hcxo3gz8gvCc=</DigestValue> </Reference> </SignedInfo> <SignatureValue>w6sA... samotný digitální podpis zakódovaný pomocí base64 ...45pg==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIE... X.509 v3 certifikát ve formátu ASN.1/DER zakódovaný pomocí base64 ...RQkP</X509Certificate> </X509Data> </KeyInfo> </Signature> <Signature❷ xmlns="http://www.w3.org/2000/09/xmldsig#" Id❸="Signature-2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo❹> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <Reference❺ Id❻="Signature-2-Document-Reference" URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <XPath>not(ancestor-or-self::dsig:Signature) or not(ancestor-or-self::dsig:Signature/preceding-sibling::dsig:Signature[1])</XPath> </Transform> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>yHcv2564yvtGgJZcG4+1dm/jsmlX0qKGjGWUfu5cGpg=</DigestValue> </Reference> <Reference❼ URI❽="#Signature-2-SignedProperties"> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>iEy8FDlFUlbctpiVrwTf4cuTBKoBBXY5LDJIyuAG2KM=</DigestValue> </Reference> </SignedInfo> <SignatureValue>OcLa... samotný digitální podpis zakódovaný pomocí base64 ...t+jA==</SignatureValue> <KeyInfo❾> <X509Data> <X509Certificate>MIIE... X.509 v3 certifikát ve formátu ASN.1/DER zakódovaný pomocí base64 ...I2si0=</X509Certificate> </X509Data> </KeyInfo> <Object❿> <xades:QualifyingProperties⓫ xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target⓬="#Signature-2"> <xades:SignedProperties⓭ Id="Signature-2-SignedProperties"> <xades:SignedSignatureProperties> <xades:SigningTime⓮>2011-08-16T08:25:48.0724613Z</xades:SigningTime> <xades:SigningCertificate⓯> <xades:Cert> <xades:CertDigest> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue⓰>2w6LNdUhsrbRSWpoZhYKGo5BO1GmVzDuhZ7QOE5NgFg=</DigestValue> </xades:CertDigest> <xades:IssuerSerial⓱> <X509IssuerName>C=CZ, O="Česká pošta, s.p. [IČ 47114983]", CN=DEMO PostSignum Qualified CA 2</X509IssuerName> <X509SerialNumber>07B4E9</X509SerialNumber> </xades:IssuerSerial> </xades:Cert> </xades:SigningCertificate> </xades:SignedSignatureProperties> <xades:SignedDataObjectProperties> <xades:DataObjectFormat⓲ ObjectReference="#Signature-2-Document-Reference"> <xades:MimeType>application/xml</xades:MimeType> </xades:DataObjectFormat> </xades:SignedDataObjectProperties> </xades:SignedProperties> <xades:UnsignedProperties> <xades:UnsignedSignatureProperties> <xades:SignatureTimeStamp> <xades:EncapsulatedTimeStamp⓳ Encoding="http://uri.etsi.org/01903/v1.2.2#DER">MIIOB... Časové razítko zakódované v ASN.1/DER a následně base64 ...qp8=</xades:EncapsulatedTimeStamp> </xades:SignatureTimeStamp> </xades:UnsignedSignatureProperties> </xades:UnsignedProperties> </xades:QualifyingProperties> </Object> </Signature> </Invoice>
Digitální podpis výstavce dokumentu. Podepsán je původní obsah faktury. |
|
Digitální podpis příjemce dokumentu. Podepsán je celý předcházející dokument – tedy jak původní obsah faktury tak podpis výstavce. Navíc je kvůli požadavkům na shodu s XAdES-BES podepsán i podpisový certifikát příjemce (viz ❼). |
|
Digitální podpis, který chceme opatřit časovým razítkem, musí mít unikátní identifikátor. Časové razítko pomocí odkazu na identifikátor indikuje, kterého podpisu se týká. |
|
Element |
|
Element |
|
Element |
|
Element |
|
Odkaz na podepisovaná data, v tomto případě na element |
|
Element |
|
Element |
|
Element |
|
Atribut |
|
Element |
|
Čas UTC podepisování dokumentu. Čas musí vyhovovat datovému typu
|
|
Informace o podpisovém certifikátu. Element |
|
Hodnota otisku podpisového certifikátu zakódovaná pomocí base64. Otisk se počítá
nad certifikátem ve formátu ASN.1/DER. Algoritmus pro výpočet otisku je určen
předcházejícím elementem |
|
Element |
|
Element |
|
Element |
Producent ISDOC by měl do dokumentu ISDOC zapisovat všechny údaje, které má k dispozici a je možné je ve formátu ISDOC reprezentovat, i přestože takové údaje mohou být ve formátu ISDOC definovány jako nepovinné. Minimálně by se měly zapisovat všechny údaje, které je producent schopen zapsat do tiskové podoby dokladu. Například je-li v tiskové podobě faktury seznam objednávek, nesmí chybět ani v odpovídajícím dokumentu ISDOC. Uvedení více informací v tiskové podobě než v souboru ISDOC by bylo proti smyslu formátu ISDOC.
Příklady nepovinných údajů a situací, kdy by se měly v dokumentu ISDOC objevit:
Element IssuingSystem
– „Identifikace systému, který odesílá/generuje
fakturu“. Každý systém má nějaké jméno, označení, verzi atd. a neexistuje proto důvod
pro nevyplnění elementu. Navíc přítomnost takovéto informace umožňuje rychleji zjistit
„zdroj problémů“, pokud dokument plně neodpovídá standardu ISDOC.
Element Note
– „Poznámka“. Obsahuje-li systém k danému dokladu nějakou
poznámku, musí ji na doklad uvést.
Kolekce OrderReferences
– „Hlavičková kolekce objednávek pro případnou
vazbu“. Umožňuje-li systém vazby mezi objednávkami a daňovými doklady, musí
vyexportovat všechny známé vazby s maximem informací. Totéž platí i o řádkových
kolekcích, kde jsou i položky odkazující, který řádek objednávky konkrétní daňový
doklad fakturuje. Opět, pokud tuto informaci emitující systém eviduje, musí ji do
ISDOC uvést.
Zákon předepisuje u daňového dokladu jasně vyjádřené celkové částky daně po jednotlivých
sazbách. Formát ISDOC proto nevyžaduje, aby součet částek daně na jednotlivých řádkách
odpovídal hodnotě uvedené v daňovém sumáři (element TaxTotal
). Pokud je součet po
řádkách rozdílný od hodnoty v sumáři, má přednost hodnota v sumáři DPH.
Je věcí konzumenta ISDOC, jak se vyrovná s tím, že příchozí faktura obsahuje v řádcích něco jiného než v součtech. Některé implementace mohou například převzít řádky, jak přišly, a v případě menších rozdílů oproti sumáři k nim dogenerovat korekční řádek za příslušnou sazbu. Další možností je přepočítávání řádků podle obchodních pravidel přijímacího software (a tedy jejich korekce) tak, aby v součtu sumáři DPH odpovídaly (tzv. metoda rozpouštění rozdílu do řádků). Pokud je rozdíl velmi veliký a nelze jej při nejlepší vůli považovat za zaokrouhlovací rozdíl, je také možné upozornit obsluhu, aby tento doklad vůbec neimportovala a vrátila jej odesílateli. V tomto případě je velmi vhodné vygenerovat obsluze vytisknutelný protokol, který smysluplně popíše, co s čím nesouhlasí, protože obsluha emitující strany nemusí být zcela znalá a potřebuje vlastně jen předat pokud možno přesné informace svému dodavateli aplikace.
Toto pravidlo řeší vztah řádkových položek jednotková cena (JC), počet kusů (PK) a celková cena (CC). Na řádku nemusí platit, že JC*PK=CC. Důležitá pro další zpracování je pouze celková cena. Situace, na které je dobře vidět, kdy problém nastane, je prodej velkého počtu kusů o malé jednotkové ceně. Například pokud bychom vycházeli z nepatrné jednotkové ceny jednoho špendlíku, která je uložena technicky na nějaký počet desetinných míst, tu pak násobili počtem kusů v krabici (např. deset tisíc kusů) tak můžeme v celkové ceně dostat velmi veliký rozdíl. A protože v reálném světě se prostě krabice špendlíků prodává za celkovou cenu a nikdo neřeší jednotkovou cenu jednoho špendlíku, tak se tohoto pravidla drží i ISDOC. Jednotková cena na řádku sice existuje, protože je to zákonná povinná položka daňového dokladu, ale její obsah je uložen na tolik desetinných míst, na kolik stačí daný výpočetní systém. Neboli může se stát, že v konkrétním mezním případě nesouhlasí rovnice JC*PK=CC. V tom případě má přednost a do dalších výpočtů postupuje celková cena. Další související věcí je zaokrouhlování v případě vizuálního zobrazení faktury, což typicky provádějí aplikace typu ISDOC Reader. Tyto aplikace jsou zodpovědné za vizuální stránku faktury, takže i kdyby tam emitující systém uložil jednotkovou cenu s vysokou přesností (např. „11.25531246654“), tak aby tento řádek vypadal graficky rozumně v porovnání s ostatními řádky, musí se před zobrazením zaokrouhlit a opět dojde k porušení rovnice JC*PK=CC.
Údaje s datovým typem UUIDType
musí být do dokumentu ISDOC vyplněny
v souladu s principem jednoznačného identifikátoru UUID. Jedná se o elementy UUID
používané jako identifikátor uvnitř dalších elementů. Například tedy není možné vyplňovat do
těchto položek prázdný UUID (00000000-0000-0000-0000-000000000000). Ten ač vyhoví kontrole
v XSD na skladbu této položky, tak v případě posílání více dokladů s prázdným UUID se import
zachová špatně hned u druhého takového dokladu a prohlásí, že jde o opravu prvního
dokladu.
Historicky se vyvíjelo i pravidlo v XSD týkající se UUID. Pro verzi ISDOC 5.1 se nesmělo jednat o prázdný řetězec. Verze 5.2 dodefinovala syntaktickou skladbu UUID do skupin oddělených pomlčkou včetně definice množiny znaků A-Z a 0-9. Verze 5.3 přinesla rozšíření položek UUID i o malá písmena, čímž se definice stala kompatibilní s RFC 4122.
Pozor, hodnoty UUID nejsou z principu citlivé na velikost písmen, neboli přijde-li jednou tentýž UUID malými písmeny a jednou velkými písmeny, jedná se týž identifikátor a tedy totožný doklad. Proto je v případě textového porovnání s již uloženými UUID v databázi vhodné tyto položky normalizovat například na tvar „všechna písmena velká“.
U mnoha položek vyplývá z právních předpisů povinnost je vyplnit nějakou hodnotou. Pravidla ISDOC však mají být pokud možno na legislativě nezávislá, a proto se zde nesnažíme udržovat jejich kompletní přehled. Příklady pravidel:
Element CompanyID
(DIČ) by měl být u dokladu, který je předmětem DPH,
vždy vyplněn, protože se jedná o jednu z povinných položek daňového dokladu.
Obdobně element TaxPointDate
– „Datum zdanitelného plnění“, které by mělo
být na daňovém dokladu vždy vyplněno. Toto neplatí pro dobropisy a vrubopisy, u nich je
datem DPH podle zákona datum doručení dokladu protistraně, takže na vystaveném dokladu
se neuvádí. Pokud nejde o daňový doklad, element se rovněž v dokumentu ISDOC
nepoužije.
Pokud je odesílajícím subjektem česká firma, musí element
Invoice
/AccountingSupplierParty
/PostalAddress
/Country
/IdentificationCode
v souladu s ISO 3166-1 obsahovat hodnotu „CZ
“.
Je vyplněna informace o zápisu v rejstříku
Invoice
/AccountingSupplierParty
RegisterIdentification
.
Obecně lze požadovat, aby doklady splňovaly všechny náležitosti předepsané legislativou platnou v zemi vystavitele dokladu.
Ve finančních položkách všech dokladů používáme typicky vždy kladná čísla s výjimkou
případu, kdy uvedená hodnota je opravdu záporná. Pravidlo se týká například elementů
AlreadyClaimedTaxableAmount
, AlreadyClaimedTaxAmount
,
AlreadyClaimedTaxInclusiveAmount
, AlreadyClaimedTaxExclusiveAmount
,
PaidDepositsAmount
, které se ze své povahy odčítají.
Konkrétně jsou důležité dvě situace:
vztah daňových záloh:
TaxInclusiveAmount - AlreadyClaimedTaxInclusiveAmount = DifferenceTaxInclusiveAmount
neboli celková částka s daní – položka předepsané daňové zálohy v kladné částce = rozdíl, tj. celková částka k zaplacení s daní.
vztah nedaňových záloh a zaokrouhlení až k částce „k zaplacení“:
DifferenceTaxInclusiveAmount + PayableRoundingAmount - PaidDepositsAmount = PayableAmount
neboli celková částka k zaplacení s daní + haléřové vyrovnání (zaokrouhlení) - zaplacené nedaňové zálohy = částka k zaplacení.
Poslední, co v této souvislosti můžeme zmínit je situace dokladů typu
(DocumentType
) 2 a 6, tzn. dobropis faktury a dobropis daňového zálohového
listu. I v těchto případech je doklad dobropisu v kladných částkách a až jeho povaha (tedy
fakt, že jde o dobropis) naznačují, že všechna čísla je od původní faktury vlastně třeba
odečíst. Dobropis jako takový je ale vždy v kladných částkách. Toto pravidlo bylo
formulováno a stalo se závazné s verzí 5.2.1. Uvedená hodnota má být na faktuře opravdu
záporná pouze v případě, když se někdo snaží tímto způsobem udělat dobropis. Pokud tím
neklesne částka celého dokladu do záporu (jinak řečeno pokud takové položky jsou
v minoritě), nelze proti tomu nic namítat, protože tento postup praxe používá a ISDOC na to
musí umět reagovat. Pokud by ale záporná měla být většina položek, je třeba jít už cestou
skutečného dobropisu (a tedy tato většina bude uvedena kladně, zatímco „menšinové“ položky
budou záporně).
Ve formátu ISDOC existují elementy typu UUIDType a vedle nich elementy typu ID36Type.
Důvodem je, že některé položky musí být unikátní v rámci celého světa, typicky hlavičkový
identifikátor dokladu. Pod tímto identifikátorem doklad putuje vnějším světem a nesmí se
stát, že by se vyskytly na světě dva doklady se stejnou identifikací. Jiné položky,
například unikátní identifikátor řádku ID (element
Invoice/InvoiceLines/InvoiceLine/ID
), musí zaručit unikátnost řádku jen v rámci
jednoho dokladu. Teoreticky by tedy stačilo definovat například osmi znakovou položku a
publikovat, že jde o unikátní identifikátor řádku v rámci dokladu. Protože ale některé
informační systémy jsou již navrženy robustně a mohou i na identifikátory řádků používat
UUID, zatímco jiné systémy mohou používat třeba jen pořadová čísla, bylo třeba vymyslet
takový způsob, který by všem dovolil do výsledného souboru ISDOC uložit hodnotu použitou
v daném ekonomickém systému. Ideální je tedy znaková položka o maximální délce 36 znaků, kam
si každý odesílací systém uloží, co používá. Podstatné je, že ručí za unikátnost v rámci
jednoho dokladu.
Uživatelské elementy existují v ISDOC hlavičkové a řádkové. Uživatelské elementy a jejich obsah nejsou kontrolovány pomocí XML schématu a je tedy možné si do nich uložit jakoukoliv strukturu XML. Tyto elementy nemají obsahovat žádná „oficiální“ data (tj. data, která by měly využívat všechny systémy) – taková by patřila do společné nové verze formátu. Uživatelské elementy jsou určeny pro konkrétní implementace, kdy se příjemce a vystavitel dohodnou na jejich použití (v praxi se samozřejmě spíše dohodnou jejich IT dodavatelé, pokud to není rovnou tentýž subjekt). Podstatné ale je, že při konstrukci jmen a jmenného prostoru uživatelských elementů je třeba dodržovat určitou kázeň, aby se nemohlo stát, že dvě různé implementace použijí stejně pojmenovaný element. Jmenný prostor uživatelského elementu proto musí být unikátní, typicky obsahuje internetovou doménu realizační firmy. Příklad použití uživatelského elementu:
<Extensions> <extenze:AdditionalDiscount xmlns:extenze="http://abra.eu/praha/divize415/novak/projekt_zakaznicke_slevy_na_poukazy" >10</extenze:AdditionalDiscount> </Extensions>
Obdobně fungují i řádkové uživatelské elementy. Navíc je potřeba počítat s tím, že nelze vyžadovat přítomnost uživatelských elementů na všech řádcích. Přijímací systém musí být připraven na to, že uživatelské elementy součástí faktury vůbec nebudou.
Kolem uživatelských položek je poměrně velká praktická zkušenost, někdy i negativní, kdy se například systémy EDI kvůli uživatelským položkám rozjely do několika tzv. subsetů, na jejichž překlad je třeba speciálních můstků nebo nemusí být vůbec možný. Proto ISDOC přistoupil k uživatelským položkám jinak. Na jaře 2010 byla i do aplikací typu ISDOC Reader doplněna schopnost zobrazit obsah uživatelských elementů, což dovoluje všem si vůbec povšimnout, že tam nějaká uživatelská data jsou.
Ve zúčtovací faktuře se v kolekci NonTaxedDeposits
nedaňová zálohová faktura
uvádí pouze v případě, že byla zaplacena (a tudíž je třeba tuto zaplacenou částku odečíst od
částky k zaplacení), ale současně nebyla importována do daňové zálohy, která by mohla být
v kolekci TaxedDeposits
. V tom případě by se totiž odečítala jednou z principu
nedaňové zálohy a současně z principu odečtu zdaněné zálohy a to by byla chyba. Pokud je
daná nedaňová záloha vztažena do daňového zálohového listu, tak se sám tento daňový zálohový
list odečítá ve zúčtovací faktuře a nedaňová záloha již ne. Typické použití je, že doklad
daňový zálohový list má kolekci nedaňových zálohových listů (zaplacených) a není třeba jej
platit. A pokud se tento daňový zálohový list použije ve zúčtovací faktuře v kolekci
TaxedDeposits
, tak se odečte v příslušné kolekci a na konci není třeba zaplatit
nic.
TaxTotal
a
TaxSubTotal
Pro všechny údaje uváděné v sumáři DPH (element TaxSubTotal
) musí v místní,
případně cizí měně platit:
TaxableAmount + TaxAmount = TaxInclusiveAmount
AlreadyClaimedTaxableAmount + AlreadyClaimedTaxAmount = AlreadyClaimedTaxInclusiveAmount
DifferenceTaxableAmount + DifferenceTaxAmount = DifferenceTaxInclusiveAmount.
Pro celkové položky daně v sumáři DPH TaxTotal
musí platit, že se rovnají
součtu daní za každou sazbu tj. za každou kolekci TaxSubTotal
a to včetně cizí
měny, pokud je použita. Tedy:
TaxTotal/TaxAmount = SUM(TaxSubtotal/TaxAmount)
LegalMonetaryTotal
Uvnitř celkového sumáře LegalMonetaryTotal
musí jednotlivé položky souhlasit
se součty položek v příslušné sazbě (za všechny kolekce TaxSubTotal
). Pro všechny
musí v místní, případně cizí měně platit:
LegalMonetaryTotal/TaxExclusiveAmount = SUM (TaxSubTotal/TaxableAmount)
LegalMonetaryTotal/TaxInclusiveAmount = SUM (TaxSubTotal/TaxInclusiveAmount)
LegalMonetaryTotal/AlreadyClaimedTaxExclusiveAmount = SUM (TaxSubTotal/AlreadyClaimedTaxableAmount)
LegalMonetaryTotal/AlreadyClaimedTaxInclusiveAmount = SUM (TaxSubTotal/AlreadyClaimedTaxInclusiveAmount)
LegalMonetaryTotal/DifferenceTaxExclusiveAmount = SUM (TaxSubTotal/DifferenceTaxableAmount)
LegalMonetaryTotal/DifferenceTaxInclusiveAmount = SUM (TaxSubTotal/DifferenceTaxInclusiveAmount)
Někteří producenti elektronických faktur mají problém s naplněním elementů
RegisterKeptAt
, RegisterFileRef
a RegisterDate
, protože
údaje mají uložené jako jednu položku. Formát ISDOC proto alternativně umožňuje informaci
o zápisu do rejstříku uvést jako jeden řetězec v elementu Preformatted
. Emitující
systém si může vybrat jeden z těchto dvou způsobů reprezentace zápisu do rejstříku. Příjemce
dokumentů ISDOC se musí vyrovnat s oběma způsoby.
Element PaymentMeans
(podrobnosti platby) není povinný. Vynechat ho lze
například v situaci, kdy je doklad placený v hotovosti a hotovostní doklad ještě neexistuje
(a jeho název nelze tedy uvést do povinného podelementu Details
). Pro příjemce je
to pokyn „nic neplatit“, což je žádoucí u všech jiných způsobů platby než
bankovním účtem.
Dalším typickým případem neuvedení elementu PaymentMeans
je použití ISDOC pro
daňový zálohový list. Zde totiž nepřipadá v úvahu, že by měl být nějak placen, naopak on sám
se dělá pouze na přijatou platbu nedaňového zálohového listu, a předpokládá se tedy, že bude
obsahovat odpovídající částky v elementu NonTaxedDeposits
.
Je-li součástí dokumentu ISDOC reprezentovaného jako archiv
(.isdocx
) také jeho vizuální podoba, doporučuje se pro ni použít
formát PDF. Lze použít i další formáty ukládající vizuální podobu dokumentu (např. HTML,
formáty MS Word, MS Excel, obrázky JPEG, GIF, PNG, BMP, atd.). Musí však platit, že příloha
označená jako „vizuální podoba dokumentu“, musí být skutečně jeho vizuální podoba. Záměr je
mít pouze jednu vizuální podobu dokumentu, a proto v elementu SupplementsList
může být pouze jediný element Supplement
s atributem
preview="true"
.
isdoc-invoice-6.0.2.xsd
Přehledný grafický diagram schématu je dostupný na adrese http://isdoc.cz/6.0.2/doc-cs/isdoc-invoice-6.0.2.html.
isdoc-commondocument-6.0.2.xsd
Přehledný grafický diagram schématu je dostupný na adrese http://isdoc.cz/6.0.2/doc-cs/isdoc-commondocument-6.0.2.html.
isdoc-manifest-6.0.2.xsd
isdoc-6.0.2.sch
<?xml version="1.0" encoding="UTF-8"?> <sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2"> <sch:title>Kontrola vybraných pravidel ISDOC</sch:title> <sch:ns uri="http://isdoc.cz/namespace/2013" prefix="isdoc"/> <sch:pattern> <sch:title>Vazba na původní doklad</sch:title> <sch:rule context="isdoc:Invoice[isdoc:DocumentType = (2,3,6)]"> <sch:assert test="isdoc:OriginalDocumentReferences/*">Pro typ dokladu 2, 3 a 6 musí existovat vazba na původní doklad. Konkrétně tedy pro DocumentType = 2, 3, 6 musí existovat element OriginalDocumentReference a musí byt neprázdný.</sch:assert> </sch:rule> </sch:pattern> <sch:pattern> <sch:title>Konzistentní uvádění cizí měny</sch:title> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:LineExtensionAmount]"> <sch:assert test="isdoc:LineExtensionAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:LineExtensionAmountTaxInclusive]"> <sch:assert test="isdoc:LineExtensionAmountTaxInclusiveCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:DepositAmount]"> <sch:assert test="isdoc:DepositAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:TaxableDepositAmount]"> <sch:assert test="isdoc:TaxableDepositAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:TaxInclusiveDepositAmount]"> <sch:assert test="isdoc:TaxInclusiveDepositAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:TaxAmount]"> <sch:assert test="isdoc:TaxAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:TaxableAmount]"> <sch:assert test="isdoc:TaxableAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:TaxInclusiveAmount]"> <sch:assert test="isdoc:TaxInclusiveAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:AlreadyClaimedTaxableAmount]"> <sch:assert test="isdoc:AlreadyClaimedTaxableAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:AlreadyClaimedTaxAmount]"> <sch:assert test="isdoc:AlreadyClaimedTaxAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:AlreadyClaimedTaxInclusiveAmount]"> <sch:assert test="isdoc:AlreadyClaimedTaxInclusiveAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:DifferenceTaxableAmount]"> <sch:assert test="isdoc:DifferenceTaxableAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:DifferenceTaxAmount]"> <sch:assert test="isdoc:DifferenceTaxAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:DifferenceTaxInclusiveAmount]"> <sch:assert test="isdoc:DifferenceTaxInclusiveAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:TaxExclusiveAmount]"> <sch:assert test="isdoc:TaxExclusiveAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:AlreadyClaimedTaxExclusiveAmount]"> <sch:assert test="isdoc:AlreadyClaimedTaxExclusiveAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:DifferenceTaxExclusiveAmount]"> <sch:assert test="isdoc:DifferenceTaxExclusiveAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud xistuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:PayableRoundingAmount]"> <sch:assert test="isdoc:PayableRoundingAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:PaidDepositsAmount]"> <sch:assert test="isdoc:PaidDepositsAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]//*[isdoc:PayableAmount]"> <sch:assert test="isdoc:PayableAmountCurr">Doklad vystavený v cizí měně musí obsahovat v cizí měně i všechny finanční elementy. Konkrétně: pokud existuje element ForeignCurrencyCode, pak musí existovat všechny elementy s částkami pro cizí měnu tj. ty končící na Curr.</sch:assert> </sch:rule> </sch:pattern> <sch:pattern> <sch:title>Konzistentní uvádění tuzemské měny</sch:title> <sch:rule context="isdoc:Invoice[not(isdoc:ForeignCurrencyCode)]"> <sch:assert test="isdoc:CurrRate = 1">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="isdoc:RefCurrRate = 1">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> </sch:rule> <sch:rule context="isdoc:Invoice[not(isdoc:ForeignCurrencyCode)]"> <sch:assert test="not(.//isdoc:LineExtensionAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:LineExtensionAmountTaxInclusiveCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:DepositAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:TaxableDepositAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:TaxInclusiveDepositAmountCurr)">Doklad vystaven v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:TaxAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:TaxableAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:TaxInclusiveAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:AlreadyClaimedTaxableAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:AlreadyClaimedTaxAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:AlreadyClaimedTaxInclusiveAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:DifferenceTaxableAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:DifferenceTaxAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:DifferenceTaxInclusiveAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:TaxExclusiveAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRat) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:AlreadyClaimedTaxExclusiveAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:DifferenceTaxExclusiveAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:PayableRoundingAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:PaidDepositsAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> <sch:assert test="not(.//isdoc:PayableAmountCurr)">Doklad vystavený v tuzemské měně nesmí obsahovat žádný element v cizí měně. Pokud neexistuje element ForeignCurrencyCode, pak nesmí existovat žádný element pro cizí měnu, tj. element končící na Curr. Položky s kursem (CurrRate i RefCurrRate) musí být rovny hodnotě 1.</sch:assert> </sch:rule> </sch:pattern> <sch:pattern> <sch:title>Tuzemská a zahraniční měna musí být rozdílná</sch:title> <sch:rule context="isdoc:Invoice[isdoc:ForeignCurrencyCode]"> <sch:assert test="isdoc:ForeignCurrencyCode != isdoc:LocalCurrencyCode">U dokladu v zahraniční měně nesmí být měna lokální a zahraniční shodné. Konkrétně hodnota povinné položky LocalCurrencyCode se nesmí rovnat hodnotě nepovinné položky ForeignCurrencyCode.</sch:assert> </sch:rule> </sch:pattern> <sch:pattern> <sch:title>Nedaňový doklad nesmí obsahovat řádkové položky podléhající DPH</sch:title> <sch:rule context="isdoc:Invoice[isdoc:VATApplicable = 'false']"> <sch:assert test="every $va in isdoc:InvoiceLines/isdoc:InvoiceLine/isdoc:ClassifiedTaxCategory/isdoc:VATApplicable satisfied $va = 'false'">Je-li doklad nedaňový (element VATApplicable obsahuje hodnotu false), musejí být i všechny jeho řádkové položky nedaňové, tedy element VATApplicable uvnitř elementu ClassifiedTaxCategory rovněž obsahuje hodnotu false. Obráceně to však neplatí – na dokladu podléhajícím DPH mohou být jednotlivé položky, které nejsou v evidenci DPH.</sch:assert> </sch:rule> </sch:pattern> <sch:pattern> <sch:title>Jednotky jednotlivých šarží v jedné řádce musí být stejné a odpovídat jednotce množství pro celou řádku</sch:title> <sch:rule context="isdoc:Invoice/isdoc:InvoiceLines/isdoc:InvoiceLine[isdoc:Item/isdoc:StoreBatches]"> <sch:assert test="count(distinct-values(isdoc:Item/isdoc:StoreBatches/isdoc:StoreBatch/isdoc:Quantity/@unitCode)) le 1">Jednotka v rozpisu všech šarží/sériových čísel (element StoreBatches) musí být stejná jako jednotka pro množství na řádce faktury. Jednotky u šarží jedné řádky faktury musí být stejné. Pokud atribut pro jednotku v rozpisu šarží/sériových čísel není uveden, tak se předpokládá, že je množství uvedeno ve stejné jednotce jako množství na řádce faktury. </sch:assert> <sh:assert test="if (isdoc:InvoicedQuantity/@unitCode) then every $q in isdoc:Item/isdoc:StoreBatches/isdoc:StoreBatch/isdoc:Quantity) satisfies $q/@unitCode = isdoc:InvoicedQuantity/@unitCode else true()">Jednotka v rozpisu všech šarží/sériových čísel (element StoreBatches) musí být stejná jako jednotka pro množství na řádce faktury. Jednotky u šarží jedné řádky faktury musí být stejné. Pokud atribut pro jednotku v rozpisu šarží/sériových čísel není uveden, tak se předpokládá, že je množství uvedeno ve stejné jednotce jako množství na řádce faktury. </sch:assert> </sch:rule> </sch:pattern> <sch:pattern> <sch:title>Součet množství za jednotlivé šarže musí odpovídat množství za celou řádku</sch:title> <sch:rule context="isdoc:Invoice/isdoc:InvoiceLines/isdoc:InvoiceLine[isdoc:Item/isdoc:StoreBatches]"> <sch:assert test="sum(isdoc:Item/isdoc:StoreBatches/isdoc:StoreBatch/isdoc:Quantity) = isdoc:InvoicedQuantity">Součet Quantity ze všech záznamů rozpisu šarží/sériových čísel musí odpovídat InvoicedQuantity dané řádky faktury.</sch:assert> </sch:rule> </sch:pattern> <sch:pattern> <sch:title>Sekundární identifikace zboží může být uvedena pouze v případě, že je uvedena i primární</sch:title> <sch:rule context="isdoc:Invoice/isdoc:InvoiceLines/isdoc:InvoiceLine/isdoc:Item[isdoc:SecondarySellersItemIdentification]"> <sch:assert test="isdoc:SellersItemIdentification">Nepovinnou položku SecondarySellersItemIdentification lze uvést pouze v případě, že je uvedena také položka SellersItemIdentification.</sch:assert> </sch:rule> </sch:pattern> <sch:pattern> <sch:title>Terciální identifikace zboží může být uvedena pouze v případě, že je uvedena i primární a sekundární</sch:title> <sch:rule context="isdoc:Invoice/isdoc:InvoiceLines/isdoc:InvoiceLine/isdoc:Item[isdoc:TertiarySellersItemIdentification]"> <sch:assert test="isdoc:SellersItemIdentification and isdoc:SecondarySellersItemIdentification">Nepovinnou položku TertiarySellersItemIdentification lze uvést pouze v případě, že jsou uvedeny také položky SellersItemIdentification a SecondarySellersItemIdentification.</sch:assert> </sch:rule> </sch:pattern> </sch:schema
Přidána nová reprezentace dokumentu ISDOC.PDF, kdy je dokument ISDOC vložen do formátu PDF/A-3.
Vylepšení popisu některých elementů.
Schéma kontroluje unikátnost identifikátoru řádky dokladu.
Upřesnění detailů výpočtu časového razítka.
Následující seznam obsahuje navrhované změny a rozšíření pro některou z dalších verzí ISDOC.
Zvažujeme přidání nových typů dokumentu objednávka a potvrzení objednávky.
Zvažujeme přidání nového typu dokumentu, který bude sloužit jako kontejner pro uložení a přenos více dokumentů najednou, například při dávkovém zpracování.
[APPNOTE] APPNOTE.TXT – .ZIP File Format Specification. September 2007. PKWARE Inc. Dostupné na URL: http://www.pkware.com/documents/APPNOTE/APPNOTE-6.3.2.TXT
[RFC4051] Additional XML Security Uniform Resource Identifiers (URIs). April 2005. IETF. Dostupné na URL: http://www.ietf.org/rfc/rfc4051.txt
[ISO 19005-3] Document management – Electronic document file format for long-term preservation – Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3). 2012. ISO. Dostupné na URL: https://www.iso.org/standard/57229.html
[ISO 32000-1] Document management – Portable document format – Part 1: PDF 1.7. 2008. ISO. Dostupné na URL: https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf
[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition). W3C Recommendation. 26 November 2008. W3C. Dostupné na URL: http://www.w3.org/TR/REC-xml/
[XAdES] ETSI TS 101 903 V1.4.1: XML Advanced Electronic Signatures (XAdES) Technical Specification. June 2009. ETSI. Dostupné na URL: http://uri.etsi.org/01903/v1.4.1/ts_101903v010401p.pdf
[2011/130/EU] COMMISSION DECISION of 25 February 2011 establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market. Dostupné na URL: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:053:0066:0072:EN:PDF[5]
[ČBA-STD-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í. 2014. Česká bankovní asociace.
[RFC1951] DEFLATE Compressed Data Format Specification version 1.3 May 1996. IETF. Dostupné na URL: http://www.ietf.org/rfc/rfc1951.txt
[RFC3161] Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) August 2001. IETF. Dostupné na URL: http://www.ietf.org/rfc/rfc3161.txt
[RFC6838] Media Type Specifications and Registration Procedures January 2013. IETF. Dostupné na URL: http://www.ietf.org/rfc/rfc6838.txt
[XMLDSig-Core] XML Signature Syntax and Processing (Second Edition). W3C Recommendation. 10 June 2008. W3C. Dostupné na URL: http://www.w3.org/TR/xmldsig-core/
[1] Například nesmí začínat číslem, nesmí obsahovat mezery atd.
[2] Povinnost zahrnout podpisový certifikát do podpisu definuje forma XAdES-BES. Časové razítko ve formě XAdES-T musí splňovat i všechny požadavky na nižší formu XAdES-BES (resp. XAdES-EPES).
[3] Otisk se přitom počítá z elementu SignatureValue
včetně jeho obsahu
nikoliv z binární reprezentace hodnoty digitálního podpisu. Před výpočtem otisku se
ještě provádí kanonizace. Viz sekce 7.3 [XAdES].
[4] V současné době většina autorit časového razítka v ČR podporuje pouze algoritmus SHA-256.
[5] Kvůli chybám v českém překladu doporučujeme vycházet z anglické verze rozhodnutí komise.