# ISDOC 6.0.2

### Národní standard pro elektronickou fakturaci

Copyright © 2022 MVČR

Copyright © 2014 ICT UNIE o.s.

23. března 2022

## 1. Úvod

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.

### 1.1. Konvence

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#`

## 2. Shoda se standardem

Standard ISDOC definuje shodu pro dokumenty, konzumenty a producenty.

### 2.1. Typy dokumentů ISDOC

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.

### 2.2. Dokument ISDOC

Dokument ISDOC musí splňovat následující požadavky:

1. Musí být reprezentován v souladu s požadavky definovanými v části 3 – „Reprezentace dokumentu“.

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

3. Musí splňovat pravidla definovaná v části 4 – „Pravidla“.

4. Pokud je dokument opatřen digitálním podpisem, musí splňovat požadavky definované v části 5 – „Digitální podpisy“.

5. Pokud je dokument opatřen časovým razítkem, musí splňovat požadavky definované v části 6 – „Časové razítko“.

### 2.3. Konzument ISDOC

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.

### 2.4. Producent ISDOC

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.

## 3. Reprezentace dokumentu

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

### Poznámka

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.

### 3.1. Dokument XML

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.

### 3.2. ISDOC.PDF

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:

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

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

3. Dokument ISDOC.PDF může obsahovat další vložené dokumenty a soubory.

#### 3.2.1. Vložené 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“.

Tabulka 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: `/Source` Použije se, pokud bylo PDF vygenerováno přímo z ISDOC dokumentu. `/Alternative` Použije se, pokud PDF i dokument ISDOC byly vygenerovány nezávisle na sobě – např. z databáze nebo objektového modelu v aplikaci – a jedná se tak o alternativní reprezentace stejných dat, ale žádná z nich není primárním zdrojem dat. `/Supplement` Použije se pro všechny vložené soubory s výjimkou vloženého dokumentu ISDOC.
`/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“.

Tabulka 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 `text/xml`. Pro ostatní vložené soubory se použije jim odpovídající typ.[RFC6838]

#### 3.2.2. Přílohy dokladu

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

### 3.3. Archiv

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:

1. Soubory uložené v archivu musí být nekomprimované nebo musí používat kompresní metodu „deflate“ popsanou v [RFC1951].

2. Archiv nesmí používat šifrování.

3. Archiv nesmí používat digitální podpisy.

4. Archiv nesmí používat funkci „patch data“.

5. Archiv nesmí být rozdělen do více souborů.

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

7. Archiv musí v kořenovém adresáři obsahovat soubor `manifest.xml` obsahující manifest.

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

Příklad 1. Manifest archivu – soubor `manifest.xml`

    <?xml version="1.0"?>
    <manifest xmlns="http://isdoc.cz/namespace/2013/manifest">
      <maindocument filename="FV2013-042.isdoc"/>
    </manifest>

### Poznámka

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

## 4. Pravidla

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

### 4.1. Pravidla pro typ dokumentu daňový doklad

#### 4.1.1. Vazba na původní doklad

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

#### 4.1.2. Konzistentní uvádění cizí měny

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

#### 4.1.3. Konzistentní uvádění tuzemské měny

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.

#### 4.1.4. Tuzemská a zahraniční měna musí být rozdílná

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

#### 4.1.5. Nedaňový doklad nesmí obsahovat řádkové položky podléhající DPH

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.

#### 4.1.6. Jednotky jednotlivých šarží v jedné řádce musí být stejné a odpovídat jednotce množství pro celou řádku

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.

#### 4.1.7. Součet množství za jednotlivé šarže musí odpovídat množství za celou řádku

Součet `Quantity` ze všech záznamů rozpisu šarží/sériových čísel musí odpovídat `InvoicedQuantity` dané řádky faktury.

#### 4.1.8. Sekundární identifikace zboží může být uvedena pouze v případě, že je uvedena i primární

Nepovinnou položku `SecondarySellersItemIdentification` lze uvést pouze v případě, že je uvedena také položka `SellersItemIdentification`.

#### 4.1.9. Terciální identifikace zboží může být uvedena pouze v případě, že je uvedena i primární a sekundární

Nepovinnou položku `TertiarySellersItemIdentification` lze uvést pouze v případě, že jsou uvedeny také položky `SellersItemIdentification` a `SecondarySellersItemIdentification`.

#### 4.1.10. Správce číselníku podrobnějšího typu dokumentu

Element `SubDocumentTypeOrigin` musí obsahovat pouze hodnoty uvedené v tabulce 3 – „Přípustné hodnoty pro element `SubDocumentTypeOrigin`“.

Tabulka 3. Přípustné hodnoty pro element `SubDocumentTypeOrigin`

Hodnota | Popis | Definice číselníku | Přidáno
--- | --- | --- | ---
`CBA` | Česká bankovní asociace | viz [ČBA-STD-29] | 1. ledna 2014

### 4.2. Pravidla pro typ dokumentu neplatební dokument

#### 4.2.1. Správce číselníku podrobnějšího typu dokumentu

Element `SubDocumentTypeOrigin` musí obsahovat pouze hodnoty uvedené v tabulce 3 – „Přípustné hodnoty pro element `SubDocumentTypeOrigin`“.

## 5. Digitální podpisy

### 5.1. Požadavky na digitální podpis v dokumentu ISDOC

1. Digitální podpis musí být v souladu s doporučením [XMLDSig-Core].

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

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

   Příklad 2. Použití transformace XPath v digitálním podpisu

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

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

   Příklad 3. Přiřazení unikátního identifikátoru podpisu

       <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
                  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
                  Id="Signature-1">
         ...
       </Signature>

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

### 5.2. Požadavky na vícenásobný podpis dokumentu ISDOC

1. Podpis musí být v souladu s požadavky definovanými v 5.1 – „Požadavky na digitální podpis v dokumentu ISDOC“.

2. Musí být použita transformace XPath a to následujícím způsobem:

   1. První podpis používá filtr `not(ancestor-or-self::dsig:Signature)`.

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

### 5.3. Ověření vícenásobného podpisu ve starších verzích formátu

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

1. Pokud dokument obsahuje alespoň jeden digitální podpis, ověří se poslední digitální podpis.

2. Poslední digitální podpis (element `Signature`) se z dokumentu odstraní a s takto upraveným dokumentem se opakuje krok 1.

## 6. Časové razítko

### 6.1. Požadavky na časové razítko v dokumentu ISDOC

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

2. Digitální podpis, který je předmětem časového razítka, musí obsahovat unikátní identifikátor uvnitř atributu `Id` elementu `Signature`.

3. Časové razítko musí být ve formě XAdES-T v souladu se specifikací [XAdES].

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

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

6. Č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].

Příklad 4. ISDOC s digitálními podpisy výstavce, příjemce a časovým razítkem

    <?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 `SignedInfo` obsahuje informace o podepisovaných datech, způsobu jejich kanonizace a metodě výpočtu podpisu.
❺ | Element `Reference` určuje data pro podepsání. Atribut `URI=""` říká, že se bude podepisovat celý stávající dokument (v našem případě původní faktura a podpis výstavce).
❻ | Element `Reference` musí mít přiřazen identifikátor, aby se na něj bylo možné odkázat z elementu `DataObjectFormat` (viz ⓲).
❼ | Element `Reference` určuje data pro podepsání. Atribut `URI="#Signature-2-SignedProperties"` říká, že se bude podepisovat element, který má identifikátor `Signature-2-SignedProperties`. V našem případě se jedná o element `SignedProperties` obsahující čas podepisování, otisk podpisového certifikátu (viz ⓯) a další informace. Zahrnutí těchto údajů do podpisu vyžaduje XAdES-BES.
❽ | Odkaz na podepisovaná data, v tomto případě na element `SignedProperties` (viz ⓭) obsahující zejména otisk podpisového certifikátu.
❾ | Element `KeyInfo` obsahuje podpisový certifikát. XAdES-BES vyžaduje, aby byl tento certifikát přítomen a byl podepsán jeho otisk v elementu `SigningCertificate`.
❿ | Element `Object` slouží jako kontejner, do kterého je možné přidat doplňující informace pro digitální podpis včetně časového razítka XAdES-T.
⓫ | Element `QualifyingProperties` obaluje všechny informace XAdES.
⓬ | Atribut `Target` obsahuje odkaz na digitální podpis, kterého se týká časové razítko.
⓭ | Element `SignedProperties` obaluje veškeré přídavné vlastnosti, které se podepisují. Zejména otisk podpisového certifikátu.
⓮ | Čas UTC podepisování dokumentu. Čas musí vyhovovat datovému typu `dateTime` W3C XML schémat.
⓯ | Informace o podpisovém certifikátu. Element `SigningCertificate` nesmí obsahovat atribut `Id` (viz [2011/130/EU]) – odpovídající certifikát v elementu `KeyInfo` (viz ❾) je nalezen na základě shody otisku certifikátu (viz ⓰).
⓰ | 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 `DigestMethod`.
⓱ | Element `IssuerSerial` a jeho podelementy identifikují certifikační autoritu, která vystavila podpisový certifikát.
⓲ | Element `DataObjectFormat` se pomocí atributu `ObjectReference` odkazuje na element `Reference` (viz ❺), který do podpisu zahrnuje celý dokument ISDOC. Musí obsahovat podelement `MimeType` určující MIME typ odkazovaných dat. V případě formátu ISDOC, který používá syntaxi XML, je MIME typ vždy `application/xml`.
⓳ | Element `EncapsulatedTimeStamp` obsahuje samotné časové razítko ve formátu ASN.1/DER zakódované pomocí base64.

## A. Implementační poznámky

### A.1. Zásada exportu maximálního množství informací

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.

### A.2. Výpočet DPH

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.

### A.3. Výpočet celkové ceny z jednotkové a počtu kusů

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.

### A.4. Identifikátory

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

### Poznámka

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

### A.5. Vyplňování položek v souladu s legislativou

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.

### A.6. Finanční částky

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:

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

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

### A.7. Použití typů UUIDType a ID36Type

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.

### A.8. Uživatelské elementy

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.

### A.9. Zúčtovací faktura

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.

### A.10. Vztahy mezi údaji uváděnými uvnitř elementů `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)

### A.11. Vztahy mezi údaji uvnitř elementu `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)

### A.12. Identifikace zápisu v rejstříku

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.

### A.13. Informace o platbě

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

### A.14. Vizuální podoba dokumentu

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

## B. Schémata pro jednotlivé typy dokumentů

### B.1. Schéma pro daňový doklad – `isdoc-invoice-6.0.2.xsd`

### Poznámka

Přehledný grafický diagram schématu je dostupný na adrese http://isdoc.cz/6.0.2/doc-cs/isdoc-invoice-6.0.2.html.

### B.2. Schéma pro neplatební dokument – `isdoc-commondocument-6.0.2.xsd`

### Poznámka

Přehledný grafický diagram schématu je dostupný na adrese http://isdoc.cz/6.0.2/doc-cs/isdoc-commondocument-6.0.2.html.

### B.3. Schéma pro manifest – `isdoc-manifest-6.0.2.xsd`

## C. Schéma pro kontrolu vybraných pravidel – `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

## D. Změny oproti předchozím verzím

### D.1. Změny oproti verzi 6.0.1 z 26.5.2014

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

## E. Možné změny pro další verze

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

## Reference

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