ECR BRÁNA - ROZHRANÍ ECR OBÁLKA 2.0. Verze dokumentu: 1.1 Datum vzniku: Počet stran: 16
|
|
- Ludmila Zemanová
- před 7 lety
- Počet zobrazení:
Transkript
1 ECR BRÁNA - ROZHRANÍ ECR OBÁLKA 2.0 Zhotovil: Častorál Radek Verze dokumentu: 1.1 Datum vzniku: Počet stran: 16
2 Verze dokumentu Změny 1.0 Úvodní verze určená pro implementátory 1.1 Popis ECR obálky v kapitole 2.3 v sekci Chyba opraven do souladu s XML schématem. V dokumentu nebyl popis chyby zanořen do elementu PopisChyby a nebyly popsány některé volitelné XML uzly. V souladu s tím doplněn text kapitoly
3 1. Úvod ECR brána je systém, který od roku 2002 slouží ke komunikaci celní správy s externími subjekty, převážně s deklaranty. Systém byl průběžně rozšiřován a modernizován, aby pružně reagoval na potřeby celní správy. K jeho zásadní modernizaci došlo v průběhu roku 2008 s cílem použít novou integrační platformu a aplikovat dlouholeté zkušenosti s provozem do samotného jádra ECR brány. Součástí rozšíření byly i dvě podstatné úpravy, které rozšiřují možnosti funkce směrem k deklarantům. Jednou z nich je použití moderních a standardizovaných zabezpečovacích standardů XML signature a XML encryption a druhou úprava ECR obálky tak, aby snáze splňovala různorodé potřeby zastřešovaných celních agend. Těmto dvěma změnám je věnován tento dokument. Současně ale zůstávají v platnosti všechny předchozí dokumenty vztahující se k rozhraní ECR obálky 1.5 a k zabezpečení formou SMIME podepisování a šifrování. K existujícím agendám ECR brána plně podporuje pro zpětnou kompatibilitu rozhraní 1.5, ale u nově vznikajících agend už bude vyžadováno rozhraní 2.0. Stejná pravidla platí pro využívání mechanizmů zabezpečení datových výměn.
4 2. Komunikační zpráva ECR obálka 2.0 ECR obálka je hlavní komunikační zpráva na ECR bráně 2.0 a slouží k zapouzdřování informací o přenášené zprávě, které jsou důležité pro její správné nasměrování na serverovou aplikaci, ověření zabezpečení a pro sledování jejího toku systémem. Veškerá data určená pro průchod ECR bránou musí být do této obálky zapouzdřena. Pro všechny elementy ECR obálky 2.0 je přiřazený jmenný prostor Změny proti verzi 1.5 Hlavní zpráva používaná ECR bránou byla původně navržena pro použití ve dvou vybraných režimech. Obsahuje proto některé režimově specifické údaje a na druhou stranu neumožňuje případné rozšíření o elementy využitelné v agendách nově zaváděných. V rámci změn ECR brány se ukázalo jako maximálně účelné rozvinout definici rozhraní na novou obecnější verzi. Původní ECR brána informovala o chybových stavech pomocí dvou zpráv ChybaVAN a CZ907A. Důvody pro toto dvojí informování se postupně stíraly a v nové verzi je použit již jednotný způsob vracení chyby formou oddílu v ECR obálce. Pro zpětnou kompatibilitu je zajištěno generování původních zpráv. Hlavní změny ECR obálky proti verzi 1.5 jsou následující: - Odstraněny režimově vynucené atributy (např. JmenoSouboru pro ECRFTP) a nahrazeny volnější strukturou atributů zprávy. <Zprava><Atributy><Atribut Nazev="JmenoSouboru" Hodnota="soubor" - Uvolněna sekce Ucastnici tak, aby mohl být počet účastníků větší než doposud podporovaní 3. <Ucastnici><Ucastnik Role="deklarant" Identifikator="05CZ " GuidScenare="" DatumCas="" AplikaceID="dd" AplikaceVerze="1.0 - Umožněno používání XML signature. - Umožněno používání XML encryption. - Lze přidat i atributy, které nejsou v době nynějšího návrhu známy. - Přidána část pro podporu hlášení o chybě. - Původní element <Zprava> rozdělen do dvou <Hlavicka> a <Zprava> podle toho, zda se informace týkají obálky nebo přenášené zprávy Systém kontrol Na příchozí ECR obálku jsou aplikovány kontroly specifické dle komunikační domény. Patří mezi ně zejména: - Kontrola proti XML schématu ECR obálky pro konkrétní doménu. - Logická kontrola vyplňování ECR obálky proti přenášeným datům. - Logická kontrola vyplněných údajů proti registrům komunikačních subjektů. - Rozšifrování a ověření zaručeného elektronického podpisu. Dále popsaný způsob vyplňování je obecně platný, nicméně pro jednotlivé komunikační domény může být zúžen a zpřísněn.
5 2.3. ECR obálka 2.0 Základní přehled o možných elementech ECR obálky dává následující tabulka. Hlavicka Název elementu XML typ Datový typ Povinnost vyplňování směrem do ECR brány Povinný Povinnost vyplňování směrem z ECR brány Povinný GuidObalky Atribut UUID Povinný Povinný VerzeObalky Atribut string[10] Povinný Povinný Domena Atribut string[20] Povinný Povinný Zprava Povinný Povinný Typ Atribut string[30] Povinný Povinný HlavniID Atribut string[40] VedlejsiID Atribut string[40] Atributy Atribut [1-n] [1-n] Nazev Atribut string[20] Povinný Povinný Hodnota Atribut string[256] Povinný Povinný Popis s informacemi o obálce. Unikátní identifikátor jednoznačně určující právě jednu instanci ECR obálky. Označení verze ECR obálky. Jméno komunikační domény (agendy), pro kterou je určena datová výměna. s informacemi o přenášené zprávě. Jméno přenášené zprávy, typicky je jím kořenový element obalovaného XML. Hlavní identifikátor přenášené zprávy. Vedlejší identifikátor přenášené zprávy. Seznam doplňkových atributů. Doplňkový atribut. Název doplňkového atributu. Hodnota doplňkového
6 atributu. RozsireneInformace Atribut Ucastnici Ucastnik [1-n] [1-n] Nazev Atribut string[20] Povinný Povinný Hodnota Atribut string[256] Povinný Povinný Povinný Povinný [1-n] Povinný Povinný [1-n] Role Atribut string[20] Povinný Povinný Identifikator Atribut string[40] GuidScenare Atribut UUID DatumCas Atribut datetime AplikaceID Atribut string[50] AplikaceVerze Atribut string[20] Místo, kam lze uložit další dodatečné informace. Doplňkový atribut. Název doplňkového atributu. Hodnota doplňkového atributu. Seznam stran, které se účastní datové výměny (např. deklarant, VAN operátor, GŘC atd.). Komunikační strana. Role komunikační strany (deklarant, VAN, zástupce, PVS, VVAN, GRC) v předem definovaných řetězcích. Jednoznačný identifikátor komunikující strany. Označení scénáře v rámci agendy komunikující strany. Datum a čas průchodu obálky agendou komunikující strany. Označení aplikace, která se o průchod komunikující stranou stará. Označení verze aplikace, která se o průchod komunikující
7 stranou stará. SMIMEZprava string pro umístění přenášené zprávy v SMIME formátu. XMLZprava pro umístění přenášené zprávy v XML formátu. SignatureContext Atribut string[15] Výčtový typ určující rozsah prováděného zaručeného elektronického podpisu. Může nabývat hodnot "envelope" (výchozí hodnota) a "datacontent". Data obsahuje XML data v otevřeném tvaru. EncryptedData obsahuje XML data v šifrovaném tvaru dle doporučení W3C - XML encryption. Signature Umístění informací o elektronickém podpisu dle doporučení W3C - XML signature. BinarníZprava pro umístění přenášené binární zprávy kódované jako base64 SignatureContext Atribut string[15] Výčtový typ určující rozsah prováděného zaručeného elektronického podpisu. Může nabývat hodnot "envelope" (výchozí hodnota) a "datacontent".
8 Data string EncryptedData Signature Chyba Nesmí být PopisChyby obsahuje binární data v kódování base64. obsahuje binární data v šifrovaném tvaru dle doporučení W3C - XML encryption. Umístění informací o elektronickém podpisu dle doporučení W3C - XML signature. Pokud při zpracování došlo k chybě, budou zde umístěny příslušné informace. Kod Atribut int Nesmí být Povinný Číselný kód chyby. GuidPuvodniObalky Atribut UUID Nesmí být TypChyby Atribut string[20] Nesmí být Povinný Obsahuje GUID původní obálky, ke které se chyba vztahuje, pokud jí je možné načíst. Označení typu chyby, resp. zdroje chyby. Popis Atribut string[256] Nesmí být Popis chyby. Data string Nesmí být Signature Nesmí být Hlavicka Pokud je to k popisu chyby nutné, jsou zde uvedena data chyby. Umístění informací o elektronickém podpisu dle doporučení W3C - XML signature pro element hlášené chyby Tento element je povinný a obsahuje hlavní informace o agendě a datové výměně. Každá instance ECR obálky musí mít vygenerovaný unikátní GUID (UUID) identifikátor v atributu GuidObalky, uvedenou komunikační doménu v atributu Domena a
9 uvedenou identifikaci verze obálky, což je v současné době konstanta 2.0 v atributu Verze Zprava Tento povinný element zapouzdřuje informace o konkrétní přenášené zprávě nebo datové výměně. Udává se Typ datové výměny, což je u XML komunikací zpravidla jméno kořenového elementu přenášené zprávy. Dále se uvádí volitelně až dva identifikátory z přenášené zprávy, které mohou mít význam pro směrování zprávy. Způsob vyplňování elementů HlavniID a VedlesiID je určen doménou a typem výměny, nicméně ve většině domén se požaduje uvedený alespoň jeden z těchto identifikátorů. V některých případech je nutné uvádět v obálce ještě další atributy a pro ně je určena volitelná struktura Atributy/Atribut RozsireneInformace Tento nepovinný element je v současné době nepoužíván a rezervován pro případná rozšíření ECR obálky v budoucích doménách Ucastnici Povinný element obsahuje informace o všech zúčastněných komunikačních partnerech. Každý zúčastněný komunikační partner musí pro průchodu zprávy jeho systémem přidat jeden podelement Ucastník a uvést svoji roli do atributu Role, svoji identifikaci do atributu Identifikator, datum a čas průchodu zprávy jeho systémem do atributu DatumCas a informace o programovém modulu, který obálku zpracovával, do atributů AplikaceID a AplikaceVerze. Tři nejčastější současné role jsou deklarant (vyplní deklarant, resp. jeho SW), operator (vyplní např. VAN operátor) a grc (vyplní ECR brána). Dále se dle komunikačních mechanizmů mohou vyskytnout i role vvan a pvs. Všechny role kromě grc musí povinně vyplnit všech 5 atributů kromě volitelného GuidScenare, což je GUID, u něhož ECR brána zaručuje, že ho v nezměněné podobě vrátí v odpovědi ve stejné sekci. ECR brána vyplňuje pouze roli a datum a čas a volitelně dle domény identifikaci scénáře. V odpovědi ECR brány se všechny sekce vracejí, neuvádí se však u nich zpravidla již informace o programovém modulu Datový přenášený obsah Příchozí ECR obálka musí obsahovat právě jeden z elementů SmimeZprava, XmlZprava nebo BinarniZprava. V těchto elementech je samotný přenášený datový obsah SmimeZprava Je udržován pro zpětnou kompatibilitu a obsahuje stejný obsah jako v případě starší ECR obálky 1.5. Pro nové domény již není tento způsob komunikace podporován XmlZprava se uvede, mají-li přenášená data formát XML. Ta jsou pak přímo vložena jako podelement elementu Data. Zde je důležité je oddělit jiným jmenným prostorem nebo
10 uvedením prázdného, aby nebyla interpretována v kontextu jmenného prostoru ECR obálky. Mají-li být data šifrována, umístí se do struktury XML encryption do elementu EncryptedData. Do elementu Signature je možné uvést zaručený elektronický podpis. Obsah elementů EncryptedData a Signature je určen doporučeními W3C a popsán v kapitole BinarniZprava se uvede, mají-li přenášená data binární nebo jinou než XML povahu. Ta jsou pak přímo zakódovaná v base64 jako textová hodnota elementu Data. Mají-li být data šifrována, umístí se do struktury XML encryption do elementu EncryptedData. Do elementu Signature je možné uvést zaručený elektronický podpis. Obsah elementů EncryptedData a Signature je určen doporučeními W3C a popsán v kapitole Chyba Tento element nesmí být uveden v příchozí zprávě. Je vždy generován ECR bránou a informuje o některém z problémů, ke kterým může při příjmu, ověřování a kontrole zprávy dojít. Odpovídá-li ECR brána zprávou ECR obálka 2.0 s uvedeným elementem Chyba, není uveden žádný z datových elementů z kapitoly má vždy na svém podelementu PopisChyby uveden číselný Kod chyby a její zdroj TypChyby. Volitelně může být přítomen atribut GuidPuvodniObalky, jenž odkazuje na identifikaci ECR obálky, k níž je chyba hlášena. Rovněž volitelně je obsažen Popis chyby a u některých chyb i další doprovodná informace v podobě chybných dat v textovém elementu Data. U agend, které vyžadují opatření chybových zpráv zaručenou elektronickou značkou (chyba je právně závaznou zprávou), je tato značka přítomna v elementu Signature a strukturou odpovídá kapitole Seznam chyb, které může ECR brána aktuálně vracet, je uveden v kapitole 4.
11 3. Formáty zabezpečení dat ECR obálky 3.1. Šifrování Šifrování v ECR obálce se plně řídí doporučením W3C XML Encryption ( Je-li datový obsah šifrován, použije se jako vstup pro XML encryption element Data. Ten je následně nahrazen elementem EncryptedData už ve jmenném prostoru příslušného W3C doporučení. Příklad použitého šifrování je na následujícím zkráceném XML fragmentu: <XmlZprava> <EncryptedData Type=" xmlns=" <EncryptionMethod Algorithm=" cbc" <KeyInfo xmlns=" <EncryptedKey xmlns=" <EncryptionMethod Algorithm=" <KeyInfo xmlns=" <X509Data> <X509IssuerSerial> <X509IssuerName>CN=VM-BTS CA, OU=Technologie, O=Aquasoft s.r.o., L=Prague, S=Czech Republic, C=CZ</X509IssuerName> <X509SerialNumber> </X509SerialNumber> </X509IssuerSerial> </X509Data> </KeyInfo> <CipherData> <CipherValue>RkSilm7TlI2Nzc+Y+OVm+2KT0WoQtB7wky+aAtfowWxecq+9jV /huxtq80ddmht9oovueh1uja1oa1norrzsta==</ciphervalue> </CipherData> </EncryptedKey> </KeyInfo> <CipherData> <CipherValue>Yg82r6P+QvWTYhujTR0NWm4AoRvbXEi6Oc6pTw+4zFM3c0MeA hz+. AD7GHNDIgMPVS6fqfwkUifoEgJgmJFrVEcc27I3fQvYj7p5Z99iOV7GaYVVJes +GrO/UbaIQ==</CipherValue> </CipherData> </EncryptedData> </XmlZprava>
12 3.2. Zaručený elektronický podpis Zaručený elektronický podpis se v ECR obálce plně řídí doporučením W3C XML Signature ( Použití zaručeného elektronického podpisu nad otevřeným XML přináší jako výhodu fakt, že - pokud nejsou šifrována jsou data čitelná. To usnadňuje případné dohledávání problémů. Při používání XML signature je nutné mít na paměti zejména následující fakta: 1) Je vždy nutné provést kánonizaci XML a uvést ji ve struktuře podpisu. 2) Předmětem podpisu je vždy element SignatureInfo, který obsahuje miniaturu (SHA5 hash) podepisovaného dokumentu. 3) Znaky typu mezera, tabulátor a formátování konce řádku jsou pro XML signature významnými znaky, kanonizace je neodstraňuje a jejich změna vede na porušení podpisu. Mezi procesem podepsání zprávy a ověření podpisu tedy nesmí dojít například k přeformátování XML. 4) Pojmenování jmenných prostorů a jejich hodnoty jsou pro XML signature významnými znaky, kánonizace s nimi nijak nepracuje a nesmí být měněny. Je také nutné vést v patrnosti, že přidání pojmenovaného jmenného prostoru se promítne v DOM reprezentaci do všech podřízených, které tento jmenný prostor zdědí, a to může narušit podpis, přestože nadřazený element nebyl předmětem podpisu. V ECR bráně je vždy předlohou pro výpočet miniatury samotná přenášená zpráva uvnitř elementu Data, nikoliv element Data samotný. Součástí zaručeného elektronického podpisu musí být i veřejná část certifikátu použitelná pro ověření. Z pohledu doporučení W3C podporuje ECR brána následující typy XML signature: Typ Enveloping Tento typ znamená, že přenášená zpráva není umístěna jako potomek elementu Data (ten zůstává prázdný), ale je obsažena přímo jako definovaný objekt uvnitř struktury Signature, která je potomkem elementu XmlZprava nebo BinarniZprava. Při tomto použití nemusí být předepsána žádná transformace, ale výsledek nelze šifrovat, protože došlo v přemístění dat. Příklad uvádí následující fragment: <XmlZprava> <Data <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI="#dataID"> <DigestMethod Algorithm=" <DigestValue>59vhtCKrP1oxMOgWl+YOMexcOwQ=</DigestValue> </Reference> </SignedInfo>
13 <SignatureValue>cw55CRsMlzP+h/ihf4g9CQHq+vR8KMq+WefYV0XDVhgS9uOgq lsavthzlrjuz25ufpbjy9slvkqtrbkktauyga==</signaturevalue> <KeyInfo> <X509Data> <X509Certificate>MIIE+../ISwJKV7</X509Certificate> </X509Data> </KeyInfo> <Object Id="dataID"> <CZ384A xmlns=""> <AOSD> <AOSD01>08CZ JZUV4J2D17</AOSD01> </AOSD> </CZ384A> </Object> </Signature> </XmlZprava> Typ Enveloped, mimo zprávu, SignatureContext = envelope Tento typ znamená, že je podpis vytvořen v kontextu celé ECR obálky (v době podpisu již byla sestavena) a element Signature je umístěn jako potomek elementu XmlZprava nebo BinarniZprava. Vždy musí být uvedena transformace enveloped-signature a xpath, která určuje cestu k podepisovaným datům. <XmlZprava> <Data> <CZ384A xmlns=""> <AOSD> <AOSD01>08CZ JZUV4J2D17</AOSD01> </AOSD> </CZ384A> </Data> <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI=""> <Transforms> <Transform Algorithm=" <Transform Algorithm=" <XPath xmlns:parns="
14 r-or-self::cz384a[/parns:ecrobalka/parns:xmlzprava/parns:data/cz384a =.]</XPath> </Transform> </Transforms> <DigestMethod Algorithm=" <DigestValue>QKp4Lv7MzQ69wEVxcgA/EPXd18o=</DigestValue> </Reference> </SignedInfo> <SignatureValue>coZcE+3q/xzoiQz3AKIuoGtWQC4zkW8MEd3Ppui5QgMKlFy EjMG8uW+4rebs2Z9/UDtE04fOW12T4Oxh7PN4mw==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIE+jCCBGO./ISwJKV7</X509Certificate> </X509Data> </KeyInfo> </Signature> </XmlZprava> Typ Enveloped, mimo zprávu, SignatureContext = datacontent Princip tohoto podpisu je stejný jako v případě s tím rozdílem, že při podpis vznikl nad přenášenou zprávou, která nebyla ještě vložena do ECR obálky. Stejný postup se pak musí aplikovat při ověřování podpisu. Protože toto není výchozí nastavení atributu SignatureContent, musí být na elementu XmlZpráva uveden. <XmlZprava SignatureContext="datacontent"> </XmlZprava> Typ Enveloped, uvnitř zprávy, SignatureContext = envelope Tento typ znamená, že je podpis vytvořen v kontextu celé ECR obálky (v době podpisu již byla sestavena) a element Signature je umístěn jako potomek kořenového elementu podepisované zprávy. Vždy musí být uvedena transformace enveloped-signature. <XmlZprava> <Data> <CZ384A xmlns=""> <AOSD> <AOSD01>08CZ JZUV4J2D17</AOSD01> </AOSD> <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI=""> <Transforms>
15 <Transform Algorithm=" </Transforms> <DigestMethod Algorithm=" <DigestValue>FXHzwKRRyvE1IV5BrWqNXxZy/MA=</DigestValue> </Reference> </SignedInfo> <SignatureValue>DeECqDL1FfRAnSR6EMyrwF3b8EpiFDGvBW+6DwK0S2PCz gjahoqdjeg76hpqtzvatskgqreorrzn2g1lyjygjg==</signaturevalue> <KeyInfo> <X509Data> <X509Certificate>MIIE+jCCBGOgAwIBA../ISwJKV7</X509Certificate> </X509Data> </KeyInfo> </Signature> </CZ384A> </Data> </XmlZprava> Typ Enveloped, uvnitř zprávy, SignatureContext = datacontent Princip tohoto podpisu je stejný jako v případě s tím rozdílem, že při podpis vznikl nad přenášenou zprávou, která nebyla ještě vložena do ECR obálky. Stejný postup se pak musí aplikovat při ověřování podpisu. Protože toto není výchozí nastavení atributu SignatureContent, musí být na elementu XmlZpráva uveden. <XmlZprava SignatureContext="datacontent"> </XmlZprava> 3.3. Kombinace zaručeného elektronického podpisu a šifrování Při kombinaci obou zabezpečení se nejprve provede vytvoření zaručeného elektronického podpisu a následně se provede šifrování elementu Data. V tomto případě nelze použít typ XML Signature popsaný v kapitole 3.2.1, protože by data uvnitř elementu Signature ve výsledku nebyla zašifrována. Při zpracování příchozí zprávy se postupuje obráceně, nejprve se dešifruje a u výsledku ověří podpis.
16 4. Příloha A číselník chyb odesílaných ECR bránou Kód Text chyby 0 Invalid incomming XML 1 Internal server error 2 Invalid incomming XML message type 3 Message domain is not valid 4 ID for declarant is unknown 5 VAN operator $ is not allowed for domain $ 6 At least primary or secondary identifier have to be filled in 7 Message $ is not allowed to pass through in the domain $ 11 Load from MIME failed in the $ phase. 12 Decrypt SMIME/XML failed with: $ 13 Verify sign SMIME/XML failed due to an incorrect sign format with: $ 14 Verify sign SMIME/XML failed due to message changes Verify sign SMIME/XML failed due to the incorrect certificate chain or certificate revocation. Certificate number: $ Verify sign SMIME/XML failed due to the unauthorized certificate. Certificate number: $ 17 Decoding base64 in MIME failed in the $ phase. 18 Incorrect data security found: $ 53 XML schema general validation error 54 Invalid child element 55 Incomplete content 56 Value too short 57 Value too long 58 Invalid datatype 59 Pattern constraint failed 60 Attribute missing 70 Primary identifier is not equal to inner message 71 Secondary identifier is not equal to inner message 72 Message type is not equal to inner message 73 Unable to perform inner XML controls in order to incomplete inner message
ECR brána - rozhraní ECR obálka 2.0
Zhotovil: Radek Častorál Datum vzniku: 24.11.2014 Jméno souboru: ECR brána - rozhraní ECR obálka 2.0 Počet stran: 19 Verze dokumentu Změny 1.0 Úvodní verze určená pro implementátory. 1.1 Popis ECR obálky
VíceSpecifikace integračního rozhraní
C E R T I C O N www.certicon.cz E V R O P S K Á 1 1, 1 6 0 0 0 P R A H A 6, CZ Specifikace integračního rozhraní aplikace ORO web klient Jan Chroustovský, Martin Falc, Kamil Matoušek Zadavatel: Generální
VíceDalší XML technologie
XML teorie a praxe značkovacích jazyků (4IZ238) Jirka Kosek Poslední modifikace: $Date: 2012/05/17 18:58:55 $ Obsah Odkazy... 3 Odkazy v rámci jednoho dokumentu... 4 XLink (XML Linking Language)... 5 XLink
VíceZabezpečená middleware komunikace
České vysoké učení technické v Praze F a k u l t a e l e k t r o t e c h n i c k á Zabezpečená middleware komunikace autor: František Hlavan vedoucí práce: Ing. Jan Kubr Katedra počítačů leden 211 Cíle
VíceIntegrovaný informační systém Státní pokladny (IISSP) Dokumentace API - integrační dokumentace
Česká republika Vlastník: Logica Czech Republic s.r.o. Page 1 of 10 Česká republika Obsah 1. Úvod...3 2. Východiska a postupy...4 2.1 Způsob dešifrování a ověření sady přístupových údajů...4 2.2 Způsob
VíceSpecifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt.
C E R T I C O N www.certicon.cz V Á C L A V S K Á 1 2 1 2 0 0 0 P R A H A 2 Specifikace rozhraní Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů Martin Falc, SW architekt
VíceXML Signatures. Autor
XML Signatures Autor Martin Lasoň Abstrakt Digitální podpisy zajišťují integritu, autenticitu a nepopiratelnost dat na Webu. Takové rysy jsou zvlášť důležité pro dokumenty, které reprezentují závazky jako
VíceFunkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5
Funkční specifikace ABOKWS Aplikační rozhraní elektronického bankovnictví ABO-K Verze 0.5 Přehled změn Verze Datum Změnil Popis 0.1 26.2.2013 MB Úvod, Osnova dokumentu, funkce ABOKWS 0.2 18.4.2014 MB Tabulky
VíceVybrané technické informace pro předávání účetních záznamů do centrálního systému účetních informací státu
Vybrané technické informace pro předávání účetních záznamů do centrálního systému účetních informací státu verze k 30.10.2009 1 OBSAH: A. Datové prvky a jejich struktura...4 Komunikační obálka...4 Význam
Více2 PŘÍKLAD IMPORTU ZATÍŽENÍ Z XML
ROZHRANÍ ESA XML Ing. Richard Vondráček SCIA CZ, s. r. o., Thákurova 3, 160 00 Praha 6 www.scia.cz 1 OTEVŘENÝ FORMÁT Jednou z mnoha užitečných vlastností programu ESA PT je podpora otevřeného rozhraní
VíceAPI pro volání služby kurzovního lístku KB
OBSAH API pro volání služby Kurzovní lístek KB... 2 Poskytované informace... 2 Informace pro volání resource exchange-rates... 3 Příklady request / response z volání služby kurzovního lístku... 5 Způsoby
VíceA. Datové prvky a jejich struktura... 5. Identifikátory... 6. Identifikace ÚJ... 6. Identifikace ZO... 6. Identifikace CSÚIS... 6. Záhlaví...
Technický manuál (Pracovní verze k 10.12.2009) Slovník pojmů... 5 A. Datové prvky a jejich struktura... 5 Struktura komunikační obálky... 6 Identifikátory... 6 Identifikátor přenosu... 6 Identifikace ÚJ...
VíceVykazování dat o poskytovaných sociálních službách
Vykazování dat o poskytovaných sociálních službách (verze dokumentu 1.4) Odpovědná osoba: Ing. Radomír Martinka V Praze dne: 24.4.2014 Klasifikace: CHRÁNĚNÉ OKsystem s.r.o. Na Pankráci 125, 140 21 Praha
VíceVykazování dat o poskytovaných sociálních službách
Vykazování dat o poskytovaných sociálních službách (verze dokumentu 1.2) Odpovědná osoba: Ing. Radomír Martinka V Praze dne: 18.4.2011 Klasifikace: CHRÁNĚNÉ OKsystem s.r.o. Na Pankráci 125, 140 21 Praha
Vícel Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci
l Kontakt s klientem SSP automatizované komunikace s ÚP ČR v součinnosti a exekuci Obsah: 1. SEZNAM POUŽITÝCH ZKRATEK... 3 2. POPIS SLUŽBY... 4 2.1 Forma a struktura rozhraní... 4 2.2 Dostupnost služby...
VíceISDOC 6.0.1 Národní standard pro elektronickou fakturaci
Národní standard pro elektronickou fakturaci 26. května 2014 1. Úvod... 1 1.1. Konvence... 1 2. Shoda se standardem... 2 2.1. Typy dokumentů ISDOC... 2 2.2. Dokument ISDOC... 2 2.3. Konzument ISDOC...
VícePODMÍNKY POSKYTOVÁNÍ PŘÍSTUPU K PORTÁLU NAMĚŘENÝCH DAT POMOCÍ WEBOVÝCH SLUŽEB SPOLEČNOSTI ČEZ DISTRIBUCE, A. S.
PODMÍNKY POSKYTOVÁNÍ PŘÍSTUPU K PORTÁLU NAMĚŘENÝCH DAT POMOCÍ WEBOVÝCH SLUŽEB SPOLEČNOSTI ČEZ DISTRIBUCE, A. S. 1 ÚVOD... 5 2 POPIS VÝMĚNY DAT... 6 2.1 KOMUNIKAČNÍ SCÉNÁŘE... 6 2.2 TECHNOLOGIE KOMUNIKACE...
VíceV této příloze je podrobně popsána struktura XML dokumentu s mapou (viz kapitolu 5.3), příklad tohoto XML dokumentu je na přiloženém CD v souboru
Příloha 1: Struktura XML dokumentu V této příloze je podrobně popsána struktura XML dokumentu s mapou (viz kapitolu 5.3), příklad tohoto XML dokumentu je na přiloženém CD v souboru /mapa/map.xml. Obsah
VíceVýměnný formát XML DTM DMVS PK
Výměnný formát XML DTM DMVS PK Představení partnerským krajům Praha 8. 2. 2016 Krajský úřad Plzeňského kraje Odbor informatiky Koncept etapizace tvorby výměnného formátu XML aktualizačních zakázek Digitální
VíceXML a bezpečnost. Dagmar BRECHLEROVÁ. KIT PEF ČZU a EUROMISE, Praha Dagmar.Brechlerova@seznam.cz
XML a bezpečnost Dagmar BRECHLEROVÁ KIT PEF ČZU a EUROMISE, Praha Dagmar.Brechlerova@seznam.cz INFORUM 2006: 12. konference o profesionálních informačních zdrojích Praha, 23. - 25.5. 2006 Abstrakt. Webové
VícePopis B2B rozhraní pro elektronickou neschopenku
Popis B2B rozhraní pro elektronickou neschopenku Historie dokumentu Verze Datum Změny 0.9 30. 4. 2019 Vytvoření dokumentu Obsah 1 Účel dokumentu... 3 2 Charakteristika rozhraní... 3 2.1 Způsob komunikace...
VíceTRANSPORTY výbušnin (TranV)
TRANSPORTY výbušnin (TranV) Ze zákona vyplývá povinnost sledování přeprav výbušnin. Předpokladem zajištění provázanosti polohy vozidel v čase a PČR je poskytování polohy vozidla předepsaným způsobem. Komunikace
VícePopis struktury XML rozhraní pro elektronické podání hromadné žádosti. o obnovu oprávnění k činnosti
NA PŘÍKOPĚ 28 115 03 PRAHA 1 Popis struktury XML rozhraní pro elektronické podání hromadné žádosti o obnovu oprávnění k činnosti Obsah Popis struktury XML rozhraní... 1 pro elektronické podání hromadné
VíceKatalog egon služeb verze: 0.01
Katalog egon služeb verze: 0.01 Historie verzí Verze Datum Popis 0.01 20.7.2011 egon služby prototypu OBSAH 1 Úvod... 5 1.1 Členění dokumentu... 5 1.2 Třídy služeb... 5 1.3 SLA služeb... 6 1.3.1 SLA-01...
VíceElektronická evidence tržeb Seminář pro vývojáře pokladních systémů
Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů Praha, Štěpánská 28 15. 1. 2018 Základní informace o projektu Gabriela Čížková, SPCSS Kritické chyby Propustné chyby Pravidla a doporučené
VíceWindows Server 2003 Active Directory
Windows Server 2003 Active Directory Active Directory ukládá informace o počítačích, uživatelích a ostatních objektech v síti. Zpřístupňuje tyto zdroje uživatelům. Poskytuje komplexní informace o organizaci,
VícePopis struktury XML rozhraní pro hromadné hlášení změn pojišťovnami, pojišťovacími agenty (PA) a pojišťovacími makléři (PM)
NA PŘÍKOPĚ 28 115 03 PRAHA 1 Popis struktury XML rozhraní pro hromadné hlášení změn pojišťovnami, pojišťovacími agenty (PA) a pojišťovacími makléři (PM) Obsah Popis struktury XML rozhraní... 1 pro hromadné
VíceNA PŘÍKOPĚ PRAHA 1. Popis struktury XML rozhraní pro elektronické podání hromadné žádosti o zápis do registru podle ZDPZ
NA PŘÍKOPĚ 28 115 03 PRAHA 1 Popis struktury XML rozhraní pro elektronické podání hromadné žádosti o zápis do registru podle ZDPZ Obsah Úvod, účel dokumentu... 3 Použité zkratky... 3 Důležité pokyny k
VíceTechnický manuál Centrálního systému účetních informací státu
Integrovaný informační systém Státní pokladny (IISSP) Technický manuál Centrálního systému účetních informací státu Technické informace pro práci s Centrálním systémem účetních informací státu Obsah 1
VíceValidace souborů DS3
Validace souborů DS3 Verze: 1.33 1. Rozsah...1 1.1 Identifikace systému...1 1.2 Přehled systému...1 2. Přehled verzí a změny v nich...1 3. Použité dokumenty...2 4. Shrnutí údajů o programovém vybavení...4
VíceKomentář k datovému standardu a automatizovaným kontrolám obsahu common.xsd
Komentář k datovému standardu a automatizovaným kontrolám obsahu common.xsd Ohlašovací povinnost: Definice common.xsd popisuje pole společná pro všechna hlášení Formulář: Všechny ohlašovací povinnosti
VíceEXTRAKT z mezinárodní normy
EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové
VíceJava a XML. 10/26/09 1/7 Java a XML
Java a XML Java i XML jsou přenositelné V javě existuje podpora pro práci s XML, nejčastější akce prováděné při zpracování XML: načítání XML elementů generování nových elementů nebo úprava starého zápis
VíceObsah. Úroveň I - Přehled. Úroveň II - Principy. Kapitola 1. Kapitola 2
Úroveň I - Přehled Úroveň II - Principy Kapitola 1 Kapitola 2 1. Základní pojmy a souvislosti 27 1.1 Zpráva vs. dokument 27 1.2 Písemná, listinná a elektronická podoba dokumentu 27 1.3 Podpis, elektronický
VícePopis egon služby. E04 - robautentizace. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů
Popis egon služby E04 - robautentizace Název dokumentu: Autor: Popis egon služeb Verze: 01.00 Datum aktualizace: 25. 12. 2016 Účel: Popis egon služeb v rámci základních registrů Počet stran: 9 Obsah 1
VíceRESTful API TAMZ 1. Cvičení 11
RESTful API TAMZ 1 Cvičení 11 REST Architektura rozhraní navržená pro distribuované prostředí Pojem REST byl představen v roce 2000 v disertační práci Roye Fieldinga, zkratka z Representional State Transfer
VíceVstupní data pro program Deformace ve formátu XML
geocaktualizace:22.11.2004 Vstupní data pro program Deformace ve formátu XML Pro formát vstupních dat je využit jazyk XML pro popis strukturovaných dat. Formát je definován v souladu s definicí jazyka
VícePokročilé techniky tvorby sestav v Caché. ZENové Reporty
Pokročilé techniky tvorby sestav v Caché ZENové Reporty Úvodem Jednoduché sestavy Pokročilé sestavy Ladění Historie ZEN reporty sdílejí podobný princip definování obsahu jako ZENové stránky Byly uvedeny
VíceMetodické pokyny a validační pravidla pro vyplnění formuláře. Žádost
Metodické pokyny a validační pravidla pro vyplnění formuláře Žádost Vydání Schváleno Ministerstvem pro místní rozvoj České republiky dne 06.10.2016 Verze v0.1 Účinnost 07.10.2016 Formulář Žádost k uveřejnění
VíceVyužití XML v DB aplikacích
Využití XML v DB aplikacích Michal Kopecký Výběr ze slajdů k 7. přednášce předmětu Databázové Aplikace (DBI026) na MFF UK Komunikace aplikace s okolím Databázová aplikace potřebuje často komunikovat s
VícePRG036 Technologie XML
PRG036 Technologie XML Přednáší: Irena Mlýnková (mlynkova@ksi.mff.cuni.cz) Martin Nečaský (necasky@ksi.mff.cuni.cz) LS 2010 Stránka přednášky: http://www.ksi.mff.cuni.cz/~mlynkova/prg036/ 1 Osnova předmětu
VíceProjekt: 1.5, Registrační číslo: CZ.1.07/1.5.00/ Digitální podpisy
VY_32_INOVACE_BEZP_08 Projekt: 1.5, Registrační číslo: CZ.1.07/1.5.00/34.0304 Digitální podpisy Základní myšlenkou elektronického podpisu je obdoba klasického podpisu, jež má zaručit jednoznačnou identifikaci
VícePřehled základních kontrol v ISoSS
Informační systém o státní službě (ISoSS) Název dokumentu: Verze dokumentu: 1.0 (z 17. 7. 2015) Strana: 1/7 Historie dokumentu Historie revizí Číslo Datum revize Popis revize Změny revize označeny 1. 0
VíceKomunikace MED. Popis komunikačního rozhraní s externími evidencemi. Autor analýzy: Zadavatel: Generální ředitelství cel. 140 96 Praha 4. ver.: 01.
Komunikace MED Popis komunikačního rozhraní s externími evidencemi ver.: 01.020 Autor analýzy: TranSoft a.s Vrbenská 2082 370 21 České Budějovice Zadavatel: Generální ředitelství cel Budějovická 7 140
Více[1] ICAReNewZEP v1.2 Uživatelská příručka
[1] ICAReNewZEP v1.2 Uživatelská příručka 06.10.2011 [2] Obsah 1 - ÚVOD... 3 2 - POUŽITÉ ZKRATKY... 3 3 POŽADAVKY... 4 3.1 POŽADAVKY PRO SPRÁVNÝ CHOD APLIKACE... 4 3.2 POŽADAVKY NA OBNOVOVANÝ CERTIFIKÁT...
VícePodpora XML v.net. Podpora XML v.net. nezávislý publicista. Jirka Kosek. http://www.kosek
Podpora XML v.net Podpora XML v.net Jirka Kosek nezávislý publicista http://www.kosek kosek.cz Co nás čeká? Co nás čeká?! podpora XML ve VisualStudio.NET! architektura System.Xml! čtení XML dokumentů!
VíceSpisová agenda. Popis komunikačního rozhraní. Autor analýzy: Zadavatel: ver.: 08.003. TranSoft a.s Vrbenská 2082 370 21 České Budějovice
Spisová agenda Popis komunikačního rozhraní ver.: 08.003 Autor analýzy: TranSoft a.s Vrbenská 2082 370 2 České Budějovice Zadavatel: Generální ředitelství cel Budějovická 7 40 96 Praha 4 Obsah Spisová
VíceOracle XML DB. Tomáš Nykodým
Oracle XML DB Tomáš Nykodým xnykodym@fi.muni.cz Osnova Oracle XML DB Architektura Oracle XML DB Hlavní rysy Oracle XML DB Hlavní rysy Oracle XML DB - pokračování XMLType XML Repository Využívání databázových
VíceNÁVOD NA ZPRACOVÁNÍ A ODESLÁNÍ
NÁVOD NA ZPRACOVÁNÍ A ODESLÁNÍ ELEKTRONICKÉHO FORMULÁŘE EVIDENČNÍHO LISTU VYSÍLACÍ STANICE BEZDRÁTOVÉHO MÍSTNÍHO INFORMAČNÍHO SYSTÉMU (BMIS) I. Zpracování elektronického formuláře Pro vyplňování formuláře
VíceERP-001, verze 2_10, platnost od
ERP-001, verze 2_10, platnost od 2010.08.01. ELEKTRONICKÉ PŘEDEPISOVÁNÍ HUMÁNNÍCH LÉČIVÝCH PŘÍPRAVKŮ ERP-001.pdf (208,89 KB) Tímto technickým dokumentem jsou, v souladu s 80 zákona č. 378/2007 Sb., o léčivech
VíceNávrh funkcí webových služeb (WS) pro komunikaci mezi Informačním systémem datových schránek (ISDS) a spisovými službami (SS)
Návrh funkcí webových služeb (WS) pro komunikaci mezi Informačním systémem datových schránek (ISDS) a spisovými službami (SS) Úvod Návrh funkcí WS pro komunikaci mezi IS DS a SS vychází z výsledků předchozích
VíceJSON API pro zjišťování cen MtG karet
JSON API pro zjišťování cen MtG karet Autor: Ing. Jiří Bažant Verze: 1.0 Datum: 20.9.2014 Changelog Verze Datum Autor Poznámka 1.0 17.9.2014 Ing. Jiří Bažant 20.9.2014 Ing. Jiří Bažant Oprava příkladu
VícePrezentace XML. XML popisuje strukturu dat, neřeší vzhled definice vzhledu:
Realizováno za finanční podpory ESF a státního rozpočtu ČR v rámci v projektu Zkvalitnění a rozšíření možností studia na TUL pro studenty se SVP reg. č. CZ.1.07/2.2.00/29.0011 Definice vzhledu Prezentace
VícePožadavky pro výběrová řízení TerraBus ESB/G2x
Dokument: Převod dat TerraBus ESB/G2x Požadavky pro výběrová řízení TerraBus ESB/G2x Obsah 1. Účel dokumentu... 2 2. Použité termíny a zkratky... 2 3. Požadavky... 3 Účel dokumentu Účelem tohoto dokumentu
VíceNÁVOD NA VYPLNĚNÍ REGISTRAČNÍ ŽÁDOSTI PROGRAMU POTENCIÁL 1. PODPOROVANÁ AKTIVITA V RÁMCI PROGRAMU
NÁVOD NA VYPLNĚNÍ REGISTRAČNÍ ŽÁDOSTI PROGRAMU POTENCIÁL 1. PODPOROVANÁ AKTIVITA V RÁMCI PROGRAMU Žadatel vyplňuje minimálně jedno a maximálně 4 políčka. Políčko c) a d) je pouze doplňující k prvním dvou
VíceELEKTRONICKÉ PODÁNÍ OBČANA
Strana č. 1 ELEKTRONICKÉ PODÁNÍ OBČANA NÁVOD NA VYPLŇOVÁNÍ A ODESLÁNÍ FORMULÁŘŮ IČ: 63078236, DIČ: CZ63078236, OR: MS v Praze, oddíl B, vložka 3044 Strana 1 / 13 Strana č. 2 1 Obsah 1 Obsah... 2 2 Úvod...
VícePříloha 8: Zadávací dokumentace pro systém elektronických formulářů
Příloha 8: Zadávací dokumentace pro systém elektronických formulářů Server bude serverová databázová aplikace, která umožňuje řídit oběh elektronických dokumentů po organizaci, a případně mimo ni. Umožní
VícePopis egon služby. E164 - iszrprobe. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů
Popis egon služby E164 - iszrprobe Název dokumentu: Popis egon služeb Verze: 04.01 Autor: Správa základních registrů Datum aktualizace: Účel: Popis egon služeb v rámci základních registrů Počet stran:
VíceKnihovna RecDBXLib ZÁZNAMY V DATABOXU TXV 003 49.01
PROGRAMOVATELNÉ AUTOMATY Knihovna RecDBXLib ZÁZNAMY V DATABOXU TXV 003 49.01 KNIHOVNA RecDBXLib DATABÁZE V DATABOXU 2. vydání řijen 2008 OBSAH 1. ÚVOD...3 2. KNIHOVNA RecDBXLib DATABÁZE V DATABOXU...4
VíceXML terminologie a charakteristiky. Roman Malo
XML terminologie a charakteristiky Roman Malo XML extensible Markup Language (rozšiřitelný značkovací jazyk) Verze 1.0, 1.1 http://www.w3.org/xml Rozdíly v podpoře různých znakových sad a práci s řídícími
VíceZrušení profilu zadavatele
Zrušení profilu zadavatele Vydání Schváleno Ministerstvem pro místní rozvoj České republiky dne 17.07.2015 Verze v03.1 Účinnost 03.12.2012 Verze v03.2 Účinnost 08.02.2013 Verze v03.3 Účinnost 14.07.2014
VícePříručka uživatele HELPDESK GEOVAP
HELPDESK GEOVAP verze 1.2 11.11.2008 OBSAH 1 REGISTRACE DO HELPDESK...1 2 PŘIHLÁŠENÍ A ODHLÁŠENÍ...1 3 ZÁKLADNÍ OBRAZOVKA HELPDESK...2 4 PŘEHLED HLÁŠENÍ...2 5 ZALOŽENÍ NOVÉHO HLÁŠENÍ...3 6 ZOBRAZENÍ/EDITACE
VíceUŽIVATELSKÁ PŘÍRUČKA K INTERNETOVÉ VERZI REGISTRU SČÍTACÍCH OBVODŮ A BUDOV (irso 4.x) VERZE 1.0
UŽIVATELSKÁ PŘÍRUČKA K INTERNETOVÉ VERZI REGISTRU SČÍTACÍCH OBVODŮ A BUDOV (irso 4.x) VERZE 1.0 OBSAH 1 ÚVOD... 3 1.1 HOME STRÁNKA... 3 1.2 INFORMACE O GENEROVANÉ STRÁNCE... 4 2 VYHLEDÁVÁNÍ V ÚZEMÍ...
VíceTechnická dokumentace B2C WS postcode
Technická dokumentace B2C WS postcode Zpracoval Útvar Datum vytvoření 01.06.2016 Pavel Kořízek, Jan Magnusek KC4 Datum aktualizace 23.06.2016_verze 0.4 Počet stran 7 Počet příloh 1 Obsah 1. Úvod... 3 2.
VíceObsah prezentace. Co je to XML? Vlastnosti. Validita
Obsah prezentace Co je to XML? Vlastnosti Validita Co je to XML? EXtensible Markup Language Účelem je usnadnit sdílení dat napříč informačními systémy Popis dokumentu z hlediska věcného obsahu Vyvinuto
Více(podle stavu k , resp )
Metodický návod pro vyplnění R 43-01 - Přílohy výkazu o škole/školském zařízení o poskytovaných podpůrných opatřeních personálního charakteru a jejich finanční náročnosti pro rozpočtové účely roku 2019
VíceTechnická specifikace struktury ABO formátu UHL1 DATOVÝ SOUBOR
Technická specifikace struktury ABO formátu Formát ABO se v České republice a na Slovensku běžně používá pro výměnu finančních zpráv. Jeho struktura je pevně definována, a to podle dále uvedeného přehledu.
VíceStručný průvodce aplikací Sběr dat pro CEP a CEZ
Stručný průvodce aplikací Sběr dat pro CEP a CEZ (verze 1.0) Rada pro výzkum a vývoj Úřad vlády ČR Určeno necertifikovanému dodavateli dat RVV 2003 1. Vstup do aplikace Informace pro uživatele, uživatelské
VíceDokumentace ke službě SMS Connect. www.smsbrana.cz
Dokumentace ke službě SMS Connect www.smsbrana.cz Obsah 1 ZÁKLADNÍ INFORMACE... 3 1.1 Aktivace služby SMS Connect... 3 1.2 Přístupové údaje... 3 1.3 Přístupový bod služby URL adresa pro SMS Connect...
VícePřístup k OpenDatům o veřejných zakázkách
Přístup k OpenDatům o veřejných zakázkách Sestavy s daty o veřejných zakázkách jsou dostupné třemi způsoby: 1) V levém menu na webu www.isvz.cz pod položkou Statistiky ve složce OpenData 2) Seznam statistik
VíceEIDAS, DIGITÁLNÍ DŮVĚRA A MODERNÍ PAPERLESS V PRAXI. Jan Tejchman Business Consultant
EIDAS, DIGITÁLNÍ DŮVĚRA A MODERNÍ PAPERLESS V PRAXI Jan Tejchman Business Consultant Digitální Evropa Digitální transformace Moderní paperless Právní validita Služby vytvářející důvěru Business aplikace
VíceI.CA RemoteSeal. Ing. Filip Michl První certifikační autorita, a.s
Technické řešení služby I.CA RemoteSeal Ing. Filip Michl První certifikační autorita, a.s. 5. 4. 2018 Agenda Úvod ARX CoSign vs. DocuSign Signature Appliance Architektura Zřízení služby Aktivace služby
VícePopis rozhraní eneschopenky pro zaměstnavatele
Popis rozhraní eneschopenky pro zaměstnavatele Historie dokumentu Verze Datum Změny 1.0 30. 7. 2019 Vytvoření dokumentu Obsah 1 Účel dokumentu... 3 2 Seznam provedených změn... 3 3 Popis služeb... 3 3.1
VíceSprávnost XML dokumentu
Realizováno za finanční podpory ESF a státního rozpočtu ČR v rámci v projektu Zkvalitnění a rozšíření možností studia na TUL pro studenty se SVP reg. č. CZ.1.07/2.2.00/29.0011 Správnost XML dokumentu Správně
VíceNávrh technických pravidel pro tvorbu SIP
Návrh technických pravidel pro tvorbu SIP Použití některých elementů XML schématu dle přílohy 3 národního standardu pro elektronické systémy spisové služby verze: 7 Národní standard pro elektronické systémy
VíceZákladní přehled funkcí aplikace VVZ
Základní přehled funkcí aplikace VVZ Účel dokumentu Tento metodický manuál popisuje základní přehled funkcionalit aplikace, tak aby se každý uživatel aplikace mohl rychle a efektivně seznámit s novým prostředím
Více24. XML. Aby se dokument XML vůbec zobrazil musí být well-formed (správně strukturovaný). To znamená, že splňuje formální požadavky specifikace XML.
24. XML Úvod Značkovací jazyk XML (extensible Markup Language) vznikl ze staršího a obecnějšího jazyku SGML (Standard Generalized Markup Language). XML byl vyvinut konsorciem W3C, aby poskytl standardní
VíceSpráva VF XML DTM DMVS Datový model a ontologický popis
Správa VF XML DTM DMVS Datový model a ontologický popis Verze 1.0 Standard VF XML DTM DMVS Objednatel Plzeňský kraj Institut plánování a rozvoje hlavního města Prahy Zlínský kraj Kraj Vysočina Liberecký
VíceMetody tvorby ontologií a sémantický web. Martin Malčík, Rostislav Miarka
Metody tvorby ontologií a sémantický web Martin Malčík, Rostislav Miarka Obsah Reprezentace znalostí Ontologie a sémantický web Tvorba ontologií Hierarchie znalostí (D.R.Tobin) Data jakékoliv znakové řetězce
VíceCo nás čeká při skartačním řízení? Připravte se na změny balíčku SIP
Co nás čeká při skartačním řízení? Připravte se na změny balíčku SIP ISSS 2017, Hradec Králové 3. dubna 2017 Ze světa... SIP (Submission Information Package) vychází z normy ISO 14721:2003 Space data and
VíceDatabázové systémy. - SQL * definice dat * aktualizace * pohledy. Tomáš Skopal
Databázové systémy - SQL * definice dat * aktualizace * pohledy Tomáš Skopal Osnova přednášky definice dat definice (schémat) tabulek a integritních omezení CREATE TABLE změna definice schématu ALTER TABLE
VíceNSWI096 - INTERNET JavaScript
NSWI096 - INTERNET JavaScript Mgr. Petr Lasák JAVASCRIPT JAK SE DNES POUŽÍVÁ Skriptovací (interpretovaný) jazyk Umožňuje interaktivitu Použití: Dialogy Kontrola dat ve formulářích Změny v (X)HTML dokumentu
VíceMetodika vyplnění identifikace organizace a vyplnění masek pro správné generování daňových přiznání a kontrolních hlášení
Metodika vyplnění identifikace organizace a vyplnění masek pro správné generování daňových přiznání a kontrolních hlášení 1. Identifikace organizace Pro správné vyplňování přiznání k dani z přidané hodnoty
VícePopis výměnného formátu XML
Příloha č.: 7 Verze: 2.0 Datum: 15.5.2013 Popis výměnného formátu XML Principy výměnného formátu DTM DMVS textový soubor ve formátu XML (jednotný formát, nezávislost na software) symbologie není součástí
VíceZEMĚMĚŘICKÝ ÚŘAD. Uživatelská příručka - Metadatový editor MDE. Pod Sídlištěm 9/1800, Praha 8. Verze IS nebo části IS: 1.01. Účel poslední změny:
ZEMĚMĚŘICKÝ ÚŘAD Pod Sídlištěm 9/1800, Praha 8 Uživatelská příručka - Metadatový editor MDE Verze IS nebo části IS: Účel poslední změny: Počet listů dokumentu: 1.01 úprava dokumentace 8 Číslo jednací dokumentu:
VíceGENERÁLNÍ ŘEDITELSTVÍ CEL 140 96 Praha 4, Budějovická 7
GENERÁLNÍ ŘEDITELSTVÍ CEL 140 96 Praha 4, Budějovická 7 Všem uchazečům VÁŠ DOPIS ZNAČKY NAŠE ZNAČKA VYŘIZUJE / LINKA DATUM 20009/2013-900000-010 Kovářová/261332550 15.04.2013 4. odpověď na dotaz k zadávací
VíceDatabáze I. Přednáška 4
Databáze I Přednáška 4 Definice dat v SQL Definice tabulek CREATE TABLE jméno_tab (jm_atributu typ [integr. omez.], jm_atributu typ [integr. omez.], ); integritní omezení lze dodefinovat později Definice
Víceasto kladené otázky týkající se zpráv hlášení výdeje LP na identifikovaného pacienta pro SÚKL dle 82 odst.(3) písm.d zákona 378/2008, zákon o lé
Často kladené otázky týkající se zpráv hlášení výdeje LP na identifikovaného pacienta pro SÚKL dle 82 odst.(3) písm.d zákona 378/2008, zákon o léčivech, zasílaných SW lékárny do centrálního úložiště (CÚ)
VíceZadavatel může předat MMR údaje o koncesní smlouvě následujícími způsoby:
1.1 Úvod Tento metodický pokyn je určen pro zadavatele, kteří mají povinnost podle zákona č. 139/2006 Sb., o koncesních smlouvách a koncesním řízení (koncesní zákon) zapsat údaje o koncesní smlouvě do
VíceCo nového ve spisové službě? Národní standard pro elektronické systémy spisové služby a jeho optimalizace
Co nového ve spisové službě? Národní standard pro elektronické systémy spisové služby a jeho optimalizace Tomáš Dvořák, Archiv hl. města Prahy Radek Pokorný, Státní okresní archiv Hradec Králové DRMS Forum
Více