Firmy mají možnost dodávat elektronické hlášení nejen prostřednictvím speciálních operátorů, ale také přímo prostřednictvím portálu Federální daňové služby Ruska. Zatím se jedná o pilotní projekt, ale podle daňové služby bude služba plně funkční do konce září. A jeho prostřednictvím bude možné podávat přiznání za třetí čtvrtletí (devět měsíců). A nyní můžete cvičit na „zjemnění“. Algoritmus akcí je následující.

1 . Získejte elektronický podpis a ID předplatitele

Prostřednictvím webových stránek Federální daňové služby můžete podat prohlášení podepsané pouze právním zástupcem, tedy ředitelem, nikoli však hlavním účetním. Firmy, které se již hlásí přes speciální operátory, mohou využít stávající elektronický podpis. Ale ti, kteří dříve hlásili pouze na papíře, si budou muset nejprve zakoupit certifikát v jakémkoli certifikačním středisku zahrnutém v síti DTC Federální daňové služby Ruska (seznam je na webové stránce www.nalog.ru). V průměru je to 6-10 tisíc rublů.

Je nutné informovat speciálního operátora, že se společnost chystá nahlásit prostřednictvím webu. Teprve poté speciální operátor zaregistruje společnost na portálu Federální daňové služby Ruska a poskytne ID účastníka (jedinečný kód, bez kterého nelze hlášení odeslat).

2 . Nainstalujte specializovaný program

Pro sepsání přiznání a nahrání souboru je nutný program „Poplatník právnické osoby“. Můžete si jej zdarma stáhnout na webu www.nalog.ru v sekci „Software pro právnické a fyzické osoby“. Není nutné znovu zadávat všechna data hlášení, můžete je importovat ze svého počítače účetní program nebo flash disky ("Servis" > "Příjem zpráv z magnetických médií"). Úspěšně připravený a nahraný soubor bude přidán do "Evidence nahraných souborů" (tlačítko "Nástroje").

3 . Vytvořte přepravní kontejner s prohlášením

Před odesláním je soubor „zabalen“ spolu s digitálním podpisem a identifikátorem do přepravního kontejneru. Chcete-li to provést, musíte přejít do "Evidence nahraných souborů", vybrat soubor s prohlášením a kliknout na tlačítko "Vygenerovat přepravní kontejner" na panelu nástrojů.

4. Odesílejte hlášení prostřednictvím portálu daňové služby

Chcete-li podávat zprávy, musíte přejít na stránku www.nalog.ru v části „Prezentace daňových a účetních zpráv v EV“. Ale předtím je lepší se o tom přesvědčit software splňuje požadavky portálu (např. operační systém musí být Microsoft Windows XP, Vista nebo 7 a prohlížeč je Microsoft internet Explorer 6.0 a vyšší nebo Safari 4.0 nebo vyšší). Chcete-li to provést, klikněte na odkaz „Provést kontrolu podmínek“. Po úspěšné kontrole můžete přepravní kontejner vyložit a odeslat na kontrolu.

5 . Zkontrolujte, zda jsou hlášení předložena kontrole

Meziregionální inspektorát pro centralizované zpracování dat vystupuje při zasílání hlášení prostřednictvím portálu jako zvláštní operátor. Jako potvrzení o přijetí prohlášení zašle potvrzení. Dnem podání přiznání bude datum, které je uvedeno na potvrzení jako datum odeslání hlášení (článek 4, článek 80 daňového řádu Ruské federace). Pokud však hlášení neprojde formátově logickou kontrolou, společnosti oznámí odmítnutí přijetí a důvody. Pokud jsou odstraněny, lze zprávu odeslat znovu.

Článek vyšel v novinách „UNP“ č. 30,

JSC GNIVTs (FTS of Russia): 08/05/2016 od 05:00 moskevského času kvůli technologickým pracím v místě FDC budou komponenty na federální úrovni (GPK, SM, IRUD, SP FU) přijímacího komplexu GP-3 být nedostupný. Předpokládaný čas dokončení je ve 12:00 moskevského času, zároveň společnost Link-Servicebude držet inženýrské práce. poštovní server v daný čas nemusí být k dispozici pro odesílání/příjem e-mailů. Omlouváme se za způsobené nepříjemnosti.
Publikováno 4. srpna 2016 10:55 od Vjačeslava Abisalova
  • Dočasně se prodlužuje doba čekání na odpověď, když nám zavoláte Kvůli nehodě na straně Rostelecomu byla dočasně prodloužena čekací doba na odpověď při volání do Čeljabinské kanceláře na vícekanálovém telefonu 734-00-03
    Zveřejněno 19. ledna 2016, 04:51 od Vyacheslav Abisalov
  • Vedení rozpočtových klasifikátorů od 1. ledna 2016 Příkazy Ministerstva financí Ruska ze dne 08.06.2015 č. 90n, ze dne 01.12.2015 č. 190n zavedly změny ve struktuře klasifikátorů příjmů, výdajů a zdrojů financování rozpočtových schodků rozpočtové klasifikace Ruské federace. Kontaktujte naše specialisty pro přechod na nová verze softwarový produkt"1C: Účetní oddělení státní instituce 8"!
    Zveřejněno 18. ledna. 2016, 08:22 od Vyacheslav Abisalov
  • Zprávy Federální daňové služby Ruské federace. Rutinní práce 8-9.12.15 Pozornost!Vzhledem k technologickým pracím probíhajícím v místě FDC budou od 8. 12. 2015 v 18:00 moskevského času komponenty na federální úrovni (GPK, SM, IRUD, SP FU) přijímacího komplexu GP-3 nedostupné.Pozornost!12.09.2015 od 13:00 moskevského času v souvislosti s prací na instalaci aktualizací GPC na webu FTSOD, poštovní server přijímací komplex GP-3 nebude k dispozici. Předpokládaná doba práce je 4 hodiny.
    Předloženo 8. prosince. 2015, 11:24 od Vyacheslav Abisalov
  • Zpráva Federální daňové služby Ruské federace o technologické práci Zpráva Federální daňové služby Ruské federace: Vážení daňoví poplatníci! V souvislosti s prováděním technologických prací na straně Federální daňové služby Ruska, odpovědi na žádosti o potvrzení o splnění povinnosti poplatníka (plátce poplatků, daňového agenta) platit daně, poplatky, penále, pokuty, potvrzení o stavu plateb za daně, poplatky, penále, pokuty, úroky, jakož i akt o společném odsouhlasení daní, poplatků, penále, pokut, úroků zaslaných finančním úřadům prostřednictvím telekomunikačních kanálů, budou zaslány na Poplatníci po ukončení technologických prací O dokončení technologických prací a obnovení možnosti přijímat výše uvedené dokumenty prostřednictvím telekomunikačních kanálů bude komunikace v běžném režimu hlášena později.
    Předloženo 6. prosince. 2015, 13:49, Vjačeslav Abisalov
  • JEDNOTNÝ FORMÁT PŘEPRAVNÍHO KONTEJNERU V INFORMAČNÍ INTERAKCI S PŘIJÍMACÍMI KOMPLEXY DAŇOVÝCH ORGÁNŮ PROSTŘEDNICTVÍM TELEKOMUNIKAČNÍCH KANÁLŮ POMOCÍ ELEKTRONICKÉHO DIGITÁLNÍHO PODPISU

    1. Termíny a definice

    1.1. Elektronický digitální podpis(EDS) - atribut elektronického dokumentu určený k ochraně tohoto elektronického dokumentu před paděláním, získaný v důsledku kryptografické transformace informací a umožňující identifikovat vlastníka certifikátu podpisového klíče, jakož i prokázat absenci zkreslení informací v elektronickém dokumentu.

    1.2. Certifikát (certifikát) podpisového klíče - dokument na papíře nebo elektronický dokument s EDS oprávněné osoby Certifikační autority (dále jen CA), jehož součástí je veřejný klíč a je vydáván CA k potvrzení pravosti. EDS, identifikovat vlastníka certifikátu a zajistit důvěrnost přenášených informací.

    1.3. Elektronický dokument (dokument) - dokument prezentovaný v elektronické podobě v souladu s požadavky formátu pro tohoto typu dokument.

    1.4. Transakce - jediný krok přenosu kontejneru s dokumenty a EDS v rámci určitého typu workflow, který určuje množinu přenášených dokumentů, EDS, jejich odesílatele a příjemce.

    1.5. Elektronická správa dokumentů (tok dokumentů) - sled transakcí pro výměnu dokumentů mezi účastníky toku dokumentů, poskytující určitý regulovaný proces výměny dokumentů (například tok dokumentů pro podávání daňových přiznání (účetních sestav)) .

    1.6. Přepravní kontejner - soubor logicky souvisejících dokumentů a EDS, jakož i související přepravní informace, sloučené do jednoho souboru.

    1.7. Účastník - registrovaný účastník informační interakce, který je poplatníkem nebo zplnomocněným zástupcem poplatníka.

    1.8. NBO - daňová přiznání (kalkulace), účetní závěrky a další dokumenty, které slouží jako podklad pro výpočet a placení daní a poplatků.

    2. Obecné informace

    2.1. Tento dokument popisuje strukturu vytvořeného a zpracovaného přepravního kontejneru softwarových nástrojů finanční úřad v rámci informační interakce se specializovanými telekomunikačními operátory a účastníky v elektronické podobě prostřednictvím telekomunikačních kanálů s využitím EDS k zajištění organizace správy elektronických dokumentů při podávání daňových přiznání (kalkulací), účetních výkazů a dalších dokumentů, které slouží jako podklad pro výpočet a placení daní a poplatků. Seznam typů pracovních postupů je uveden v přílohách 4 - 11 tohoto dokumentu.

    2.2. K informační interakci dochází prostřednictvím implementace toku dokumentů prostřednictvím transakcí - přesun od jednoho účastníka toku dokumentů do jiného přepravního kontejneru se sadou dokumentů a EDS fixovaným pro tuto transakci, provedené jménem oprávněných osob příslušných účastníků dokumentu tok.

    2.3. Během pracovního postupu jsou dokumenty přenášeny v komprimované a šifrované podobě, pokud není pro konkrétní typ pracovního postupu uvedeno jinak. EDS pod dokumenty jsou převedeny v čistém textu.

    2.4. Pro každý typ pracovního postupu jsou použité formáty servisních a technologických dokumentů uvedeny v referenční knize Typy pracovních postupů zveřejněné na webových stránkách www.nalog.ru.

    3. Obecné požadavky na složení nádoby

    3.1. Obsah přepravního kontejneru

    Transportní kontejner je zip archiv obsahující:

    Soubor s informacemi o dopravě v xml formátu;

    ZIP archivy souborů s obsahem přenesených dokumentů;

    ZIP archivy souborů s popisy dokumentů;

    Soubory s obsahem přenášeného EDS.

    Schéma přepravního kontejneru je na obrázku 1.

    Obrázek 1. Schéma přepravního kontejneru (nezobrazeno)

    3.1.1. Soubory s obsahem dokumentů a digitálních podpisů jsou pojmenovány pomocí univerzálních jedinečných identifikátorů ve formátu " .zásobník".

    3.1.2. Transportní informace a soubory s obsahem dokumentů a digitálními podpisy jsou sloučeny do zip archivu v režimu STORE. Přenosový informační soubor není při přenosu v přepravním kontejneru komprimován ani zašifrován.

    3.1.3. Dokumenty a EDS týkající se jedné transakce jsou přenášeny v jednom přepravním kontejneru.

    3.1.4. Popis dokumentu je přítomen v přepravním kontejneru jako samostatný zip archiv, pokud je popis dokumentu určen typem přenášeného dokumentu. Formát popisu dokumentu je uveden v příloze č. 1 tohoto dokumentu. Popis dokumentu obsahuje další informace o přeneseném souboru a má pouze informativní charakter. Dokument lze použít k poskytnutí informativnější diagnostické zprávy, když soubory transportního kontejneru nelze dešifrovat.

    3.1.5. Formát popisu přepravních informací je uveden v příloze 2 tohoto dokumentu.

    3.2. Název souboru přepravního kontejneru

    3.2.1. Přepravní kontejner je přenášen jako soubor s jedinečným názvem podle formátu

    3.2.4. Pokud je v kontejneru více dokumentů, je v názvu souboru přepravního kontejneru uveden kód dokumentu, jehož název je součástí názvu typu transakce.

    3.2.5. Informace v názvu souboru se musí shodovat s odpovídajícími informacemi v přepravních informacích kontejneru.

    3.3. Popisy typů obsahu dokumentů jsou uvedeny v příloze 3 tohoto dokumentu.

    3.4. Požadavky na typy pracovních postupů jsou uvedeny v přílohách 4 - 11 tohoto dokumentu.

    4. Typy účastníků toku dokumentů a jejich identifikace

    4.1. Pracovní postup se provádí mezi následujícími účastníky pracovního postupu.

    4.3. Jako identifikátor správce daně se používá čtyřmístný kód správce daně v kódování klasifikátoru SOUN.

    4.4. Jedinečný třímístný kód určený Federální daňovou službou Ruska se používá jako identifikátor pro specializovaného telekomunikačního operátora a důvěryhodnou certifikační autoritu.

    4.5. ID předplatitele má formát

    <префикс системы><код абонента>

    <префикс системы>- jedná se o identifikátor specializovaného telekomunikačního operátora nebo důvěryhodné certifikační autority; délka<префикса системы>se rovná 3 znakům;<префикс системы>musí odpovídat identifikátoru specializovaného telekomunikačního operátora, jehož služby účastník využívá;

    <код абонента>je jedinečný kód předplatitele používaný v vnitřní systém specializovaný telekomunikační operátor nebo důvěryhodná certifikační autorita; délka<код абонента>ne více než 43 znaků.

    5. Specifikace použitých technologií

    5.1. Univerzálně jedinečné identifikátory

    5.1.1. Univerzálně jedinečné identifikátory (UUID) se používají k identifikaci pracovních postupů, dokumentů a ke generování názvů souborů v transportním kontejneru.

    5.1.2. Použité univerzálně jedinečné identifikátory musí být generovány podle obecné zásady Generování UUID, jak je uvedeno v RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt). Univerzálně jedinečné identifikátory jsou reprezentovány jako 32místné hexadecimální číslo zapsané malými písmeny.

    5.2. Kombinování a komprese souborů

    5.2.1. Formát archivu zip se používá ke spojení více dokumentů do jednoho přepravního kontejneru a ke komprimaci dokumentů.

    5.2.2. Formát archivu zip je popsán v otevřené specifikaci dostupné na http://www.pkware.com/documents/casestudies/APPNOTE.TXT. Archivace musí být provedena v souladu s základní schopnosti verze 2.0, bez použití šifrování.

    5.2.3. Dokument dostane před kompresí název „soubor“, po kterém se uloží do archivu. Název archivu je tvořen podle odstavce 3.1.1. Při extrahování dokumentu z archivu se informace ze souboru s popisem transportních informací použijí k obnovení původního názvu souboru.

    5.3. Kryptografie

    5.3.1. Pro šifrování se používají algoritmy GOST 28147-89. K vytvoření EDS se používají algoritmy GOST R 34.10-2001.

    5.3.2. Šifrovaná data a EDS jsou přenášeny pomocí kontejneru PKCS #7 (RFC 2315, /content/base/). Kódování DER se používá k uložení do souboru.

    5.3.3. Šifrovaná data jsou předávána jako struktura ContentInfo se strukturou EnvelopedData jako obsahem.

    5.3.4. Digitální podpisy jsou přenášeny jako struktura ContentInfo se strukturou SignedData jako obsahem. Digitální podpis může obsahovat certifikát a neměl by zahrnovat podepsaný obsah.

    5.3.5. Šifrování dokumentů přenášených jako součást primárního přepravního kontejneru by mělo být provedeno na adresu veřejné klíče certifikáty příjemce určené pro šifrování a veřejné klíče certifikátů odesílatele. Šifrování dokumentů přenášených v důsledku přijetí nebo zpracování příchozího dokumentu se provádí na adresu veřejných klíčů certifikátů příjemce určených pro šifrování, veřejných klíčů certifikátů odesílatele a veřejných klíčů certifikátů úředníků, kteří podepsal příchozí dokument.

    6. Obecné požadavky na složení poštovní zprávy při interakci s jednotným systémem pro podávání daňových přiznání a účetních výkazů v elektronické podobě prostřednictvím telekomunikačních kanálů

    Při využití výměny zpráv mezi specializovanými telekomunikačními operátory a servery pro výměnu elektronických dokumentů jednotného přijímacího komplexu správce daně pomocí protokolů SMTP a POP3 ve formátu zpráv E-mailem požadavky na strukturu poštovní zprávu jsou uvedeny v příloze 12 tohoto dokumentu.

    SCHVÁLENÝ
    nařízení Federální daňové služby Ruska
    z " 19 » 04 2012
    MMV-7-6/ [e-mail chráněný]

    Sjednocený formát přepravního kontejneru
    během informační interakce s přijímacími komplexy
    daňové úřady prostřednictvím telekomunikačních kanálů
    pomocí elektronického podpisu

    1. Termíny a definice

    1.1. Elektronický dokument(dokument) - dokument předložený v elektronické podobě, v souladu s požadavky formátu pro tento typ dokumentu.

    1.2. transakce- jediný krok přenesení kontejneru s dokumenty a elektronické podpisy požadovaného typu (ES) v rámci workflow určitého typu, který určuje množinu předávaných dokumentů, ES, jejich odesílatele a příjemce.

    1.3. Elektronická správa dokumentů (tok dokumentů)- sled transakcí pro výměnu dokumentů mezi účastníky toku dokumentů, zajišťující určitý regulovaný proces výměny dokumentů (např. tok dokumentů pro podávání daňových přiznání (účetních výkazů)).

    1.4. přepravní kontejner- soubor logicky souvisejících dokumentů a ES, jakož i souvisejících přepravních informací, spojených do jednoho souboru.

    1.5. Odběratel- registrovaný účastník informační interakce, který je poplatníkem nebo zplnomocněným zástupcem poplatníka.

    1.6. NBO - daňová přiznání (kalkulace), účetní závěrky a další dokumenty, které slouží jako podklad pro výpočet a placení daní a poplatků.

    2. Obecná informace

    2.1. Tento dokument popisuje strukturu přepravního kontejneru generovaného a zpracovávaného softwarem finančního úřadu v rámci informační interakce se specializovanými telekomunikačními operátory a účastníky v elektronické podobě prostřednictvím telekomunikačních kanálů využívajících ES pro zajištění organizace správy elektronických dokumentů při podávání poplatníků daňová přiznání (kalkulace), účetní závěrky a další dokumenty sloužící jako podklad pro výpočet a placení daní a poplatků. Seznam typů pracovních postupů je uveden v přílohách 4-11 tohoto dokumentu.

    2.2. K informační interakci dochází prostřednictvím implementace toku dokumentů prostřednictvím transakcí - přesun od jednoho účastníka toku dokumentů do jiného přepravního kontejneru se sadou dokumentů a ES fixovaných pro tuto transakci, prováděný jménem oprávněných osob příslušných účastníků dokumentu tok.

    2.3. Během pracovního postupu jsou dokumenty přenášeny v komprimované a šifrované podobě, pokud není pro konkrétní typ pracovního postupu uvedeno jinak. ES pod dokumenty jsou přenášeny v otevřené formě.

    2.4. Pro každý typ workflow jsou použité formáty servisních a technologických dokumentů uvedeny v adresáři typů workflow, zveřejněném na webu www. *****

    3. Obecné požadavky na složení nádoby

    3.1. Obsah přepravního kontejneru

    Transportní kontejner je zip archiv obsahující:

      soubor s transportními informacemi ve formátu xml; zip archivy souborů s obsahem přenesených dokumentů; zip archivy souborů s popisy dokumentů; soubory s obsahem přeneseného ES;

    Schéma přepravního kontejneru je na obrázku 1.

    Microsoft" href="/text/category/microsoft/" rel="bookmark">Microsoft Word, Microsoft Excel, Open Document Text, Document Spreadsheet, Open XML Word a Open XML Spreadsheet obsahující naskenované obrázky podléhají následujícím požadavkům: černobílý obrázek s rozlišením skenovaného dokumentu nejméně 150 a nejvýše 300 dpi s použitím 256 odstínů šedé.

    3.4. Požadavky na typy pracovních postupů jsou uvedeny v přílohách 4 - 11 , 1 k tomuto dokumentu.

    4. Typy účastníků toku dokumentů a jejich identifikace

    4.1. Pracovní postup se provádí mezi následujícími účastníky pracovního postupu.

    Symbol

    Popis

    odběratel

    daňový poplatník ( entita nebo fyzická osoba podnikatel) nebo jeho zplnomocněný zástupce

    daňový úřad

    Daňový úřad Federální daňové služby Ruska

    speciální operátor

    Specializovaný telekomunikační operátor

    důvěryhodná CA

    Certifikační autorita zahrnutá do sítě důvěryhodných CA Federální daňové služby Ruska

    4.2. Identifikátory účastníků toku dokumentů se skládají ze znaků latinky a–z, 0–9, „@“, „.“ a "-". V identifikátorech se nerozlišují malá a velká písmena.

    4.3. Jako identifikátor správce daně se používá čtyřmístný kód správce daně v kódování klasifikátoru SOUN.

    4.4. Jedinečný třímístný kód určený Federální daňovou službou Ruska se používá jako identifikátor pro specializovaného telekomunikačního operátora a důvěryhodnou certifikační autoritu.

    4.5. ID předplatitele má formát

    <префикс системы><код абонента>

    <префикс системы>je identifikátor specializovaného telekomunikačního operátora nebo důvěryhodné certifikační autority; délka<префикса системы>se rovná 3 znakům;<префикс системы>musí odpovídat identifikátoru specializovaného telekomunikačního operátora, jehož služby účastník využívá;

    <код абонента>je unikátní účastnický kód používaný v interním systému specializovaného telekomunikačního operátora nebo důvěryhodného certifikačního centra; délka<код абонента>ne více než 43 znaků.

    5. Specifikace použitých technologií

    5.1. Univerzálně jedinečné identifikátory

    5.1.1. Univerzálně jedinečné identifikátory (UUID) se používají k identifikaci pracovních postupů, dokumentů a ke generování názvů souborů v transportním kontejneru.

    5.1.2. Použité UUID musí být generovány podle obecných zásad pro generování UUID, jak je uvedeno v RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt). Univerzálně jedinečné identifikátory jsou reprezentovány jako 32místné hexadecimální číslo zapsané malými písmeny.

    5.2. Kombinování a komprese souborů

    5.2.1. Formát archivu zip se používá ke spojení více dokumentů do jednoho přepravního kontejneru a ke komprimaci dokumentů.

    5.2.2. Formát archivu zip je popsán v otevřené specifikaci dostupné na http://www. /documents/casestudies/APPNOTE. txt. Archivace musí být provedena v souladu se základními funkcemi verze 2.0, bez použití šifrování.

    5.2.3. Dokument dostane před kompresí název „soubor“, po kterém se uloží do archivu. Název archivu je tvořen v souladu s článkem 3.1.1. Při extrahování dokumentu z archivu se informace ze souboru s popisem transportních informací použijí k obnovení původního názvu souboru.

    5.3. Kryptografie

    5.3.1. Algoritmy používané pro šifrování GOST. Pro generování ES se používají algoritmy GOST R 34.10-2001.

    5.3.2. Šifrovaná data a ES jsou přenášeny pomocí kontejneru PKCS #7 (RFC 2315, http://www.ietf.org/rfc/rfc2315.txt). Kódování DER se používá k uložení do souboru.

    5.3.3. Šifrovaná data jsou přenášena jako struktura ContentInfo se strukturou EnvelopedData jako obsah.

    5.3.4. EP jsou přenášeny jako struktura ContentInfo se strukturou SignedData jako obsah. ES musí obsahovat certifikát, který se k němu vztahuje, a nesmí obsahovat dokument jím podepsaný.

    5.3.5 Šifrování dokumentů přenášených jako součást primárního přepravního kontejneru musí být provedeno na adresu veřejných klíčů certifikátů příjemce určených pro šifrování a veřejných klíčů certifikátů odesílatele. Šifrování dokumentů přenášených v důsledku přijetí nebo zpracování příchozího dokumentu se provádí na adresu veřejných klíčů certifikátů příjemce určených pro šifrování, veřejných klíčů certifikátů odesílatele a veřejných klíčů certifikátů úředníků, kteří podepsal příchozí dokument.

    6. Obecné požadavky na složení poštovní zprávy při interakci s jednotným systémem pro podávání daňových přiznání a účetních výkazů v elektronické podobě prostřednictvím telekomunikačních kanálů

    Při využití výměny zpráv mezi specializovanými telekomunikačními operátory a servery pro výměnu elektronických dokumentů jednotného přijímacího komplexu správce daně pomocí protokolů SMTP a POP3 ve formátu emailových zpráv jsou požadavky na strukturu poštovní zprávy stanovené v dodatku 12 k tomuto dokumentu.


    . Formát popisu dokumentu NBO

    (Verze 02)

    1. OBECNĚ

    1.1. Účel

    Tento dokument popisuje požadavky na soubory XML pro elektronický přenos informací o dokumentu NBO obsaženém v přepravním kontejneru (dále jen výměnný soubor).

    2. POPIS VÝMĚNNÉHO SOUBORU

    TR_DEKL_2_700_02_09_02_xx, kde xx je Současná verze systém.

    Přípona souboru je xsd.

    Formát znakový řetězec uvedeno ve tvaru T(n-k) nebo T(=k), kde n je minimální počet znaků v řádku, k - maximální částka znaků, symbol „-“ je oddělovač, symbol „=“ znamená pevná částka znaků na řádek. Pokud je minimální počet znaků 0, formát je T(0-k). Pokud je maximální počet znaků neomezený, je formát T(n-). Pokud má prvek neurčitou délku, formát je T

    · dodatečné informace. U složitých prvků je uveden odkaz na tabulku, která popisuje složení tohoto prvku. U prvků, které přebírají omezený seznam hodnot z klasifikátoru (slovník kódů atd.), je uveden odpovídající název klasifikátoru (slovník kódů atd.) nebo je uveden seznam možné hodnoty. U klasifikátoru (slovník kódů atd.) lze uvést odkaz na jeho umístění. U prvků, které používají vlastní datový typ, je zadán název prvku typu.

    3. Diagram výměny souborů

    Obr. 1. Diagram struktury souboru Exchange

    4. Seznam strukturních prvků logického modelu výměnného souboru

    Seznam strukturních prvků logického modelu výměnného souboru je uveden v tabulce. 4.1

    Tabulka 4.1

    Popis předávaného dokumentu NBO (popis)

    Název prvku

    Zkrácený název (kód) prvku

    Atribut typu prvku

    Formát prvku

    Značka povinného prvku

    dodatečné informace

    Název formuláře předávaného dokumentu NBO

    jmenné tvary

    KND předávaného dokumentu NBO

    KNDForms

    Typ předávaného dokumentu NBO

    typ dokumentu

    Přijímá hodnoty „primární“ nebo „opravné“

    Vykazovaný rok, za který je předložen dokument NBO

    Obecný prvek

    Kód období, za které se dokument NBO předává

    codePeriod

    Kód období, za které je dokument NBO předáván, podle Adresáře kódů definujících daňové (vykazovací) období (SKNP)

    Shoduje se s daňovým (vykazovacím) obdobím uvedeným ve vykazování

    Vyžaduje se, pokud je součástí zprávy

    Kód daňového úřadu, ve kterém je účastník registrován

    NPOLocationAccounting

    Obecný prvek<СОНОТип>

    Kodex finančního úřadu, ve kterém se provádí správa předmětu zdanění, podle kterého se předává dokument NBO

    NPOLumístění

    Obecný prvek<СОНОТип>Kódy z Klasifikátoru soustavy označení finančních úřadů

    dodatečné informace

    Obecný prvek (násobek)


    II. Formát popisu odvolání, dopisu a seznamu adres

    (Verze 02)

    1. OBECNĚ

    1.1. Účel

    Tento dokument popisuje požadavky na XML soubory pro elektronický přenos informací o popisu odvolání, dopisu a rozeslání.

    2. POPIS VÝMĚNNÉHO SOUBORU

    2.1. Obecné informace o výměnném souboru

    Název výměnného souboru by měl vypadat takto:

    Přípona názvu souboru je xml. Příponu souboru lze zadat jak malými, tak velkými písmeny.

    Parametry prvního řádku výměnného souboru

    První řádek souboru XML by měl vypadat takto:

    Název souboru obsahujícího schéma výměnného souboru

    Název souboru obsahujícího schéma XSD výměnného souboru by měl vypadat takto:

    TR_PISRAS_2_700_03_09_02_xx, kde xx je aktuální verze schématu.

    Přípona souboru je xsd.

    2.2. Logický model výměnného souboru

    Logický model souboru je graficky znázorněn v části 3 na obrázku 1. Prvky logického modelu výměnného souboru jsou prvky a atributy souboru XML. Úplný seznam strukturních prvků modelu logického souboru a informace o nich jsou uvedeny v části 4.

    Pro každý strukturální prvek modelu logického souboru poskytuje část 4 následující informace:

    · Název prvku. Je uveden celý název prvku.

    · Zkrácený název prvku. Uvádí se zkrácený název prvku. Zkrácené názvy lze psát písmeny a číslicemi.

    · Znak typu prvku. Může nabývat následujících hodnot: "C" - komplexní prvek(nemá vnořené), "P" - jednoduchý prvek (nemá žádné vnořené); A je atribut. Pokud je k definování prvku použit vlastní datový typ, je ve sloupci "Další informace" uveden název datového typu (typický prvek).

    formát prvku. Formát je uveden v legenda, které odpovídají následujícím hodnotám: Т – řetězec znaků; N je číselná hodnota (celá nebo zlomková).

    Formát znakového řetězce je specifikován jako T(n-k) nebo T(=k), kde n je minimální počet znaků v řetězci, k je maximální počet znaků, symbol „-“ je oddělovač, symbol „=“ znamená pevný počet znaků v řádku. Pokud je minimální počet znaků 0, formát je T(0-k). Pokud je maximální počet znaků neomezený, je formát T(n-). Pokud má prvek neurčitou délku, formát je T.

    Formát číselné hodnoty je určen jako N(m. k), kde m je maximální počet znaků v čísle, včetně znaménka (pro záporné číslo), celého čísla a zlomková částčíslo bez oddělovací desetinné čárky a k je maximální počet desetinných míst. Pokud je počet desetinných míst 0 (to znamená, že číslo je celé číslo), je formát číselné hodnoty N(m).

    U jednoduchých prvků, které jsou v XML základní (definované na http://www.w3.org/TR/xmlschema-0), jako je prvek typu „date“, je pole „Formát prvku“ ponecháno prázdné. U takových prvků je typ základního prvku uveden v poli „Další informace“.

    Znaménko povinného prvku určuje povinnou přítomnost prvku v XML soubor. Atribut povinného prvku může nabývat následujících hodnot: „O“ – povinná přítomnost prvku (název prvku a jeho hodnota musí být v souboru výměny); „H“ – přítomnost prvku je volitelná (jméno prvku a jeho hodnota ve výměnném souboru může chybět). Pokud prvek může nabývat omezeného seznamu hodnot (podle klasifikátoru, slovníku kódů atd.), pak je atribut povinnosti prvku doplněn o symbol „К“. Například: "OK". Pokud počet implementací prvku může být více než jedna, pak je povinný znak prvku doplněn o symbol „M“. Například: "OM, OKM".