JEDNOTNÝ FORMÁT PŘEPRAVNÍHO KONTEJNERU PRO INFORMAČNÍ INTERAKCI S PŘÍJEMMI DAŇOVÝCH ORGÁNŮ NA TELEKOMUNIKAČNÍCH KANÁLECH POMOCÍ ELEKTRONICKÉHO DIGITÁLNÍHO DIGITÁLU

1. Termíny a definice

1.1. Elektronický digitální podpis(EDS) - elektronický dokument nezbytný 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ý dokument.

1.2. Certifikát (certifikát) podpisového klíče - listinný dokument nebo elektronický dokument s digitálním podpisem 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 digitální podpis, identifikovat vlastníka certifikátu a zajistit důvěrnost přenášených informací.

1.3. Elektronický dokument (dokument) - dokument předložený v v elektronické podobě, podle požadavků na formát pro tohoto typu dokument.

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

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

1.6. Přepravní kontejner je soubor logicky souvisejících dokumentů a EDS, jakož i doprovodných přepravních informací, sloučených do jednoho souboru.

1.7. Účastník je 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 sloužící 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 pomocí softwaru správce daně 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 komunikačních kanálů využívajících EDS k zajištění organizace toku elektronických dokumentů při podávání daňových přiznání (kalkulací), účetních výkazů a dalších dokumentů sloužících jako podklad. pro výpočet a placení daní a poplatků. Seznam typů toku dokumentů je uveden v přílohách 4 - 11 tohoto dokumentu.

2.2. Sdělení 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 s pevnou sadou dokumentů pro tuto transakci a EDS provedené jménem oprávněných osob příslušných účastníků toku dokumentů.

2.3. V průběhu pracovního postupu jsou dokumenty přenášeny v komprimované a šifrované podobě, pokud není u konkrétního typu pracovního postupu uvedeno jinak. EDS pod dokumenty jsou převedeny na otevřený formulář.

2.4. Pro každý typ pracovního postupu jsou použité formáty servisních a technologických dokumentů uvedeny v adresáři Typy pracovních postupů zveřejněném 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 dopravních informací 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 znázorněno na obrázku 1.

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

3.1.1. Soubory s obsahem dokumentů a EDS jsou pojmenovány pomocí univerzálních jedinečných identifikátorů ve formátu " .bin“.

3.1.2. Transportní informace a soubory s obsahem dokumentů a EDS 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ý soubor a slouží pouze pro informační účely. Dokument lze použít pro informativnější diagnostickou zprávu, pokud není možné dešifrovat soubory přepravního kontejneru.

3.1.5. Formát pro popis dopravních informací je uveden v Dodatku 2 k tomuto dokumentu.

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

3.2.1. Přepravní kontejner se přenese jako soubor s jedinečné jméno podle formátu

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

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. Typy obsahu dokumentu jsou popsány v Dodatku 3 k tomuto dokumentu.

3.4. Požadavky na typy toku dokumentů 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ě je použit čtyřmístný kód správce daně v kódování klasifikátoru SAUN.

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ěryhodné certifikační centrum.

4.5. ID předplatitele má formát

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

<префикс системы>- jedná se o identifikátor specializovaného telekomunikačního operátora nebo důvěryhodného certifikačního centra; délka<префикса системы>rovna 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ý předplatitelský kód používaný během vnitřní systém specializovaný telekomunikační operátor nebo důvěryhodné certifikační centrum; 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á UID musí být generována podle obecné zásady generování UUID, jak je uvedeno v RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt). UID jsou reprezentovány jako 32bitové hexadecimální číslo zapsané malými písmeny.

5.2. Kombinování a komprimace 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. Před kompresí je dokument pojmenován „soubor“, podle kterého je uložen do archivu. Název archivu je vytvoř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. Pro šifrování se používají algoritmy GOST 28147-89. Pro generování 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, / obsah / základna /). 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 obsahem.

5.3.4. EDS jsou přenášeny jako struktura ContentInfo se strukturou SignedData jako obsahem. EDS může obsahovat certifikát a nemělo 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řijaté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ří podepsali přijatý 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 komunikač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ávy jsou stanoveny v příloze č. 12 tohoto dokumentu.

Společnosti nyní mají možnost podá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 „zadané“. Algoritmus akcí je následující.

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

Prostřednictvím webu FTS můžete podat prohlášení podepsané pouze zákonný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 ruského Federálního daňového střediska (seznam je k dispozici na webových stránkách 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 nahlásí identifikátor účastníka (jedinečný kód, bez kterého není možné odesílat zprávy).

2 ... Nainstalujte specializovaný program

K sepsání přiznání a nahrání souboru potřebujete program „Poplatník právnických osob“. Můžete si jej zdarma stáhnout na webových stránkách 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í software nebo flash disk ("Služba"> "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 "Služba").

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

Před odesláním je soubor „zabalen“ spolu s EDS 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. Podávejte hlášení prostřednictvím portálu daňové správy

Chcete-li podávat hlášení, musíte jít na www.nalog.ru v sekci „Podání daňových a účetních hlášení v EV“. Než to však uděláte, je lepší se ujistit, že 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 nebo vyšší nebo Safari 4.0 nebo vyšší). Chcete-li to provést, klikněte na odkaz „Zkontrolovat podmínky“. 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

Zvláštním provozovatelem při zasílání hlášení prostřednictvím portálu je Meziregionální inspektorát pro centralizované zpracování dat. Jako potvrzení o přijetí prohlášení zašle potvrzení. Dnem podání prohlášení bude datum, které je uvedeno v potvrzení jako datum odeslání zpráv (článek 4 článku 80 daňového řádu Ruské federace). Pokud však hlášení neprojde formátem a logickou kontrolou, budou společnosti o odmítnutí jeho přijetí a důvodech informovat. Jejich odstraněním lze hlášení přesměrovat.

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

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

Jednotný formát přepravního kontejneru
při komunikaci s přijímající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 na formát 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 určitého typu workflow, který určuje množinu předávaných dokumentů, ES, jejich odesílatele a příjemce.

1.3. Elektronický tok dokumentů (tok dokumentů)- sled transakcí pro výměnu dokumentů mezi účastníky workflow, poskytující určitý regulovaný proces pro výměnu dokumentů (např. workflow 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 elektronického podpisu, jakož i doprovodné přepravní informace, spojené 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 sloužící jako podklad pro výpočet a placení daní a poplatků.

2. Obecná informace

2.1. Tento dokument popisuje strukturu přepravního kontejneru, vytvořeného a zpracovaného softwarem správce daně v průběhu 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 elektronické podpisy pro zajištění organizace toku elektronických dokumentů při poplatníci předkládají 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ů toku dokumentů je uveden v přílohách 4-11 tohoto dokumentu.

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

2.3. V průběhu pracovního postupu jsou dokumenty přenášeny v komprimované a šifrované podobě, pokud není u konkrétního typu pracovního postupu uvedeno jinak. Elektronický podpis pod dokumenty se přenáší v čistém textu.

2.4. Pro každý typ workflow jsou použité formáty servisních a technologických dokumentů uvedeny v adresáři Typy 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řenášeného elektronického podpisu;

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

Microsoft "href =" / text / category / microsoft / "rel =" záložka "> Microsoft Word, Microsoft Excel, Open Document Text, Document Spreadsheet, Open XML Word a Open XML Spreadsheet obsahující naskenované obrázky mají následující požadavky: černobílý obrázek s rozlišením naskenovaného dokumentu minimálně 150 a maximálně 300 dpi s použitím 256 odstínů šedi .

3.4. Požadavky na typy toku dokumentů 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í centrum 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ů latinské abecedy a – z, 0–9, "@", "." a "-". V identifikátorech se nerozlišují malá a velká písmena.

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

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ěryhodné certifikační centrum.

4.5. ID předplatitele má formát

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

<префикс системы>- jedná se o identifikátor specializovaného telekomunikačního operátora nebo důvěryhodného certifikačního centra; délka<префикса системы>rovna 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 pokynů pro generování UUID, jak je uvedeno v RFC 4122 (http: // www. Ietf. Org / rfc / rfc4122.txt). UID jsou reprezentovány jako 32bitové hexadecimální číslo zapsané malými písmeny.

5.2. Kombinování a komprimace 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. / dokumenty / případové studie / APPNOTE. TXT. Archivace by měla být prováděna v souladu se základními možnostmi verze 2.0, bez použití šifrování.

5.2.3. Před kompresí je dokument pojmenován „soubor“, podle kterého je uložen do archivu. Název archivu je vytvoř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. Pro šifrování se používají algoritmy GOST... Pro generování EDS se používají algoritmy GOST R 34.10-2001.

5.3.2. Šifrovaná data a elektronický podpis 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. EDS jsou přenášeny jako struktura ContentInfo se strukturou SignedData jako obsah. ES musí obsahovat certifikát s tím související a nesmí obsahovat jím podepsaný dokument.

5.3.5 Šifrování dokumentů přenášených v rámci primárního přepravního kontejneru musí být provedeno na adrese 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řijaté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ří podepsali přijatý dokument.

6. Obecné požadavky na složení poštovní zprávy při interakci s jednotný systém 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 komunikač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.

já. Formát popisu předávaného dokumentu NBO

(Verze 02)

1. OBECNÉ INFORMACE

1.1. Jmenování

Tento dokument popisuje požadavky na XML soubory elektronického přenosu 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 aktuální verze schématu.

Přípona názvu souboru je xsd.

Formát znakového řetězce je označen jako T (n-k) nebo T (= k), kde n je minimální počet znaků v řádku, k je maximální částka znaky, symbol ”-” - 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ý, formát je T (n-). Pokud má prvek nedefinovanou 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řijímají 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ých hodnot. U klasifikátoru (číselníku apod.) může být uveden odkaz na jeho umístění. Pro položky používající vlastní typúdaje, je uveden název typického prvku.

3. Schéma výměnného souboru

Obr. 1. Schéma struktury výměnných souborů

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 položky	Zkrácený název (kód) prvku	Atribut typu prvku	Formát prvku	Povinný prvek	dodatečné informace
Název formy předávaného dokumentu NBO	Název formuláře
KND předávaného dokumentu NBO	KNDForms
Typ předávaného dokumentu NBO	typ dokumentu				Přebírá hodnoty „primární“ nebo „opravné“
Vykazovaný rok za období, za které je dokument NBO předán					Typický prvek
Kód období, pro které se dokument NBO přenáší	Kód období				Kód období, za které se dokument NBO přenáší, podle Adresáře kódů určujících daňové (vykazovací) období (SKNP) Shoduje se se zdaňovacím (vykazovacím) obdobím uvedeným ve výkazech Povinné, pokud jsou uvedeny v hlášení
Kód daňového úřadu, ve kterém je účastník registrován	Účet NOPA				Typický prvek<СОНОТип>
Kód daňového úřadu, ve kterém je předmět zdanění spravován, podle kterého se dokument NBO přenáší	BOPLocation				Typický prvek<СОНОТип>Kódy z Klasifikátoru systému označení finančních úřadů
dodatečné informace					Typický prvek (násobek)

II... Formát popisu odvolání, dopisu a pošty

(Verze 02)

1. OBECNÉ INFORMACE

1.1. Jmenování

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 být následující:

Přípona názvu souboru je xml. Příponu názvu souboru lze zadat malými i 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 XSD schéma výměnný soubor by měl vypadat takto:

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

Přípona názvu 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. 1. Prvky a atributy souboru XML jsou prvky logického modelu výměnného souboru. Úplný seznam strukturních prvků logického modelu 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 položky. Je uveden celý název prvku.

· Zkrácený název prvku. Je uveden 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: "S" - komplexní prvek (s vnořenými prvky), "P" - jednoduchý prvek (bez vnořených prvků); A je atribut. Pokud je k definování prvku použit uživatelsky definovaný datový typ, je název datového typu (typický prvek) uveden ve sloupci "Další informace".

· Formát prvku. Formát je uveden v konvence, které odpovídají následujícím hodnotám: T - řetězec znaků; N je číselná hodnota (celé číslo nebo zlomek).

Formát řetězce znaků je označen jako T (nk) nebo T (= k), kde n je minimální počet znaků v řetězci, k je maximální počet znaků, znak "-" je oddělovač, Znak "=" 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ý, formát je T (n-). Pokud má prvek nedefinovanou délku, formát je T.

Formát číselné hodnoty je uveden ve tvaru N (m. K), kde m je maximální počet číslic v čísle, včetně znaménka (pro záporné číslo), celého čísla a zlomkové části čísla bez znaku oddělující desetinnou čárku a k je maximální počet desetinných míst v čísle. Pokud je počet číslic ve zlomkové části čísla 0 (to znamená, že číslo je celé číslo), pak je formát číselné hodnoty N (m).

U jednoduchých prvků, které jsou základní v XML (definované v http: // www. W3.org/TR/xmlschema-0), například prvek s typem „date“, pole „Formát prvku“ není vyplněno. U takových prvků je typ základního prvku uveden v poli "Další informace".

Příznak povinného prvku definuje povinnou přítomnost prvku v XML soubor... Atribut obligatorní prvku může nabývat následujících hodnot: „О“ - povinná přítomnost prvku (název prvku a jeho hodnota musí být přítomny v souboru výměny); „N“ - přítomnost prvku je volitelná (název prvku a jeho hodnota nemusí v souboru výměny chybět). Pokud prvek může nabývat omezeného seznamu hodnot (podle klasifikátoru, slovníku kódů atd.), je povinný znak prvku doplněn o symbol „K“. Například: „OK“. Pokud počet realizací prvku může být více než jedna, pak je znak povinného prvku doplněn o symbol „M“. Například: „OM, OKM“.

AO GNIVTs (Federální daňová služba Ruska): 8. 5. 2016 od 05:00 moskevského času v souvislosti s technologickými pracemi v místě FTsOD, komponenty federální úrovni(GPK, SM, IRUD, SP FU) přijímacího komplexu GP-3 bude nedostupný. Předpokládaný čas dokončení prací 12:00 moskevského času. Zároveň společnost "Link-Service"bude provádět technické práce. Poštovní server v daný čas nemusí být k dispozici pro odesílání / přijímání e-mailů. Omlouváme se za způsobené nepříjemnosti.
Publikováno 4. srpna. 2016, 10:55 uživatelem Vyacheslav Abisalov

Dočasné prodloužení čekání na odpověď, když nám zavoláte Kvůli nehodě na straně Rostelecomu se při volání do Čeljabinské kanceláře na vícekanálový telefon 734-00-03 dočasně zvyšuje očekávání odpovědi
Publikováno 19. ledna. 2016 v 04:51 uživatelem Vyacheslav Abisalov

Vedení rozpočtových klasifikátorů od 1. ledna 2016 Příkazem Ministerstva financí Ruska ze dne 08.06.2015 č. 90n ze dne 1.12.2015 č. 190n byly provedeny změny ve struktuře klasifikátorů příjmů, výdajů a zdrojů financování rozpočtových schodků rozpočtová klasifikace RF. Chcete-li přejít, kontaktujte naše specialisty nová verze softwarový produkt"1C: Účetnictví státní instituce 8"!
Zveřejněno 18. ledna. 2016 v 08:22 uživatelem Vyacheslav Abisalov

Zprávy Federální daňové služby Ruské federace. Rutinní práce 8-9.12.15 Pozornost!Vzhledem k výkonu technologických prací na místě FTsOD budou od 18:00 moskevského času dne 12. 8. 2015 od 18:00 moskevského času k dispozici součásti federální úrovně (GPK, SM, IRUD, SP FU) přijímacího komplexu GP-3 Předpokládané dokončení datum 12:00 moskevského času dne 12.09.2015Pozornost!12/09/2015 od 13:00 moskevského času v souvislosti s prací prováděnou na webu FDCS za účelem instalace aktualizací GPC, poštovní server přijímací komplex GP-3 nebude k dispozici. Předpokládaná doba práce je 4 hodiny.
Publikováno 8. prosince. 2015, 11:24 uživatelem 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ídá na žádosti o potvrzení o splnění povinnosti poplatníka (plátce poplatků, daňového agenta) platit daně, poplatky, penále, pokuty, informace o stavu zúčtování daní, poplatků, penále, pokut, úroků, jakož i akt společného odsouhlasení daní, poplatků, pokut, pokut, úroků zasílaných finančním úřadům prostřednictvím telekomunikačních kanálů Poplatníci po ukončení technologických prací budou komunikace v běžném režimu oznámeny dodatečně.
Publikováno 6. prosince. 2015, 13:49 uživatelem Vyacheslav Abisalov