Companies have the opportunity to deliver electronic reporting not only through special operators, but also directly through the portal of the Federal Tax Service of Russia. So far, this is a pilot project, but, according to the tax service, by the end of September the service will be fully operational. And through it it will be possible to submit declarations for the third quarter (nine months). And now you can practice on the "refinements". The algorithm of actions is the following.
1 . Get an electronic signature and subscriber ID
Through the website of the Federal Tax Service, you can submit a declaration signed only by a legal representative, that is, a director, but not a chief accountant. Companies that already report through special operators can use the existing electronic signature. But those who previously reported only on paper will first need to purchase a certificate at any certification center included in the network of the DTC of the Federal Tax Service of Russia (the list is on the website www.nalog.ru). On average, this is 6-10 thousand rubles.
It is necessary to inform the special operator that the company is going to report through the website. Only then will the special operator register the company on the portal of the Federal Tax Service of Russia and provide the subscriber ID (a unique code without which reporting cannot be sent).
2 . Install a specialized program
To draw up a declaration and upload a file, the program "Taxpayer of a legal entity" is required. You can download it for free on the website www.nalog.ru in the section "Software for legal entities and individuals". It is not necessary to drive in all the reporting data again, you can import it from your computer from accounting program or flash drives ("Service" > "Receiving reports from magnetic media"). A successfully prepared and uploaded file will be added to the "Register of uploaded files" ("Tools" button).
3 . Form a shipping container with a declaration
Before sending the file, it is “packed” together with the digital signature and the identifier into a transport container. To do this, you need to go to the "Registry of uploaded files", select the file with the declaration and click the "Generate shipping container" button on the toolbar.
4. Submit reports through the tax service portal
To submit reports, you need to go to www.nalog.ru in the section "Presentation of tax and accounting reports in EV". But before that, it's better to make sure that software meets the requirements of the portal (for example, operating system must be Microsoft Windows XP, Vista or 7 and the browser is Microsoft Internet Explorer 6.0 and above or Safari 4.0 or above). To do this, click the link "Perform conditions check". After a successful check, you can unload the shipping container and send it to the inspection.
5 . Check that the reports are submitted to the inspection
The Interregional Inspectorate for Centralized Data Processing acts as a special operator when sending reports through the portal. In confirmation of acceptance of the declaration, she sends a receipt. The day of submission of the declaration will be the date that is listed on the receipt as the date of sending the reporting (clause 4, article 80 of the Tax Code of the Russian Federation). However, if the reporting does not pass the format-logical control, the companies will report the refusal to accept it and the reasons. If they are removed, the report can be resubmitted.
The article was published in the newspaper "UNP" No. 30,
JSC GNIVTs (FTS of Russia): 08/05/2016 from 05:00 Moscow time due to technological work at the FDC site, the federal level components (GPK, SM, IRUD, SP FU) of the GP-3 receiving complex will be unavailable. Estimated completion time is 12:00 Moscow time. At the same time, the Link-Service companywill hold engineering works. mail server in given time may not be available to send/receive emails. We apologize for any inconvenience caused.Posted Aug 4 2016 10:55 by Vyacheslav Abisalov
Posted Jan 19 2016, 04:51 by Vyacheslav Abisalov
Posted 18 Jan. 2016, 08:22 by Vyacheslav Abisalov
Submitted 8 Dec. 2015, 11:24 by Vyacheslav Abisalov
Submitted 6 Dec. 2015, 13:49 by Vyacheslav Abisalov
UNIFIED FORMAT OF TRANSPORT CONTAINER IN INFORMATION INTERACTION WITH RECEIVING COMPLEXES OF TAX AUTHORITIES VIA TELECOMMUNICATION CHANNELS USING ELECTRONIC DIGITAL SIGNATURE
1. Terms and definitions1.1. Electronic digital signature(EDS) - an attribute of an electronic document designed to protect this electronic document from forgery, obtained as a result of cryptographic transformation of information and allowing to identify the owner of the signature key certificate, as well as to establish the absence of information distortion in the electronic document.
1.2. Signature key certificate (certificate) - a document on paper or an electronic document with an EDS of an authorized person of the Certification Authority (hereinafter referred to as the CA), which includes a public key and is issued by the CA to confirm the authenticity of the EDS, identify the owner of the certificate and ensure the confidentiality of the transmitted information.
1.3. Electronic document (document) - a document presented in electronic form in accordance with the requirements of the format for of this type document.
1.4. Transaction - a single step of transferring a container with documents and EDS within the framework of a certain type of workflow, which determines the set of transferred documents, EDS, their sender and recipient.
1.5. Electronic document management (document flow) - a sequence of transactions for the exchange of documents between participants in the document flow, providing some regulated process for the exchange of documents (for example, document flow for the submission of tax returns (accounting reports)).
1.6. Transport container - a set of logically related documents and EDS, as well as related transport information, combined into one file.
1.7. Subscriber - a registered participant in information interaction who is a taxpayer or an authorized representative of a taxpayer.
1.8. NBO - tax declarations (calculations), financial statements and other documents that serve as the basis for the calculation and payment of taxes and fees.
2. General information2.1. This document describes the structure of the transport container formed and processed software tools tax authority in the course of information interaction with specialized telecom operators and subscribers in electronic form via telecommunication channels using EDS to ensure the organization of electronic document management when taxpayers submit tax declarations (calculations), financial statements and other documents that serve as the basis for calculating and paying taxes and fees. The list of types of workflow is given in appendices 4 - 11 to this document.
2.2. Information interaction occurs through the implementation of document flow through transactions - the transfer from one participant of the document flow to another transport container with a set of documents and EDS fixed for this transaction, made on behalf of authorized persons of the relevant participants in the document flow.
2.3. During the workflow, documents are transmitted in compressed and encrypted form, unless otherwise specified for a particular type of workflow. EDS under the documents are transferred in clear text.
2.4. For each type of workflow, the formats of service and technological documents used are given in the reference book of Workflow Types posted on the website www.nalog.ru.
3. General requirements for the composition of the container3.1. Contents of the shipping container
The transport container is a zip archive containing:
File with transport information in xml format;
Zip-archives of files with the contents of transferred documents;
Zip archives of files with document descriptions;
Files with the contents of the transmitted EDS.
The scheme of the transport container is shown in Figure 1.
Figure 1. Scheme of the transport container (not shown)
3.1.1. Files with the content of documents and digital signatures are named using universal unique identifiers in the format "
3.1.2. Transport information and files with the contents of documents and digital signatures are combined into a zip archive in STORE mode. The transport information file is not compressed or encrypted when transferred in a transport container.
3.1.3. Documents and EDS related to one transaction are transferred in one transport container.
3.1.4. The document description is present in the transport container as a separate zip-archive if the document description is determined by the type of document being transferred. The document description format is given in Annex 1 to this document. The document description contains additional information about the transferred file and is for informational purposes only. The document can be used to provide a more informative diagnostic message when transport container files cannot be decrypted.
3.1.5. The transport information description format is given in Appendix 2 to this document.
3.2. Transport container filename
3.2.1. The transport container is transmitted as a file with a unique name according to the format
3.2.4. If there are several documents in the container, the code of the document whose name is included in the name of the transaction type is indicated in the file name of the transport container.
3.2.5. The information in the file name must match the corresponding information in the transport information of the container.
3.3. Descriptions of document content types are provided in Annex 3 to this document.
3.4. Requirements for the types of workflow are given in Appendices 4 - 11 to this document.
4. Types of document flow participants and their identification4.1. The workflow is carried out between the following participants in the workflow.
4.3. The four-digit code of the tax authority in the coding of the SOUN classifier is used as the identifier of the tax authority.
4.4. A unique three-character code determined by the Federal Tax Service of Russia is used as an identifier for a specialized telecom operator and a trusted certification authority.
4.5. The subscriber ID has the format
| <префикс системы><код абонента> |
<префикс системы>- this is the identifier of a specialized telecom operator or a trusted certification authority; length<префикса системы>is equal to 3 characters;<префикс системы>must match the identifier of the specialized telecom operator whose services the subscriber uses;
<код абонента>is a unique subscriber code used in internal system a specialized telecom operator or a trusted certification authority; length<код абонента>no more than 43 characters.
5. Specification of technologies used5.1. Universally Unique Identifiers
5.1.1. Universally Unique Identifiers (UUIDs) are used to identify workflows, documents, and to generate file names in a transport container.
5.1.2. The universally unique identifiers used must be generated according to general principles UUID generation as outlined in RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt). Universally unique identifiers are represented as a 32-digit hexadecimal number written in lowercase.
5.2. Combining and Compressing Files
5.2.1. The zip archive format is used to combine multiple documents into a single shipping container and to compress the documents.
5.2.2. The zip archive format is described in the open specification available at http://www.pkware.com/documents/casestudies/APPNOTE.TXT . Archiving must be done in accordance with basic capabilities version 2.0, without using encryption.
5.2.3. The document is given the name "file" before compression, after which it is stored in the archive. The name of the archive is formed in accordance with clause 3.1.1. When extracting a document from an archive, information from the transport information description file is used to restore the original file name.
5.3. Cryptography
5.3.1. For encryption, algorithms GOST 28147-89 are used. Algorithms GOST R 34.10-2001 are used to form the EDS.
5.3.2. Encrypted data and EDS are transferred using the PKCS #7 container (RFC 2315, /content/base/). DER encoding is used to save to a file.
5.3.3. The encrypted data is passed as a ContentInfo structure with an EnvelopedData structure as the content.
5.3.4. Digital signatures are transmitted as a ContentInfo structure with a SignedData structure as the content. The digital signature may include a certificate and should not include signed content.
5.3.5. Encryption of documents transmitted as part of the primary transport container should be made to the address public keys the recipient's certificates specified for encryption, and the public keys of the sender's certificates. Encryption of documents transmitted as a result of receiving or processing an incoming document is carried out to the address of the public keys of the recipient's certificates specified for encryption, the public keys of the sender's certificates and the public keys of the certificates of the officials who signed the incoming document.
6. General requirements for the composition of the mail message when interacting with the unified system for submitting tax returns and financial statements in electronic form via telecommunication channelsWhen using the exchange of messages between specialized telecom operators and servers for the exchange of electronic documents of the unified receiving complex of the tax authority using the SMTP and POP3 protocols in the message format Email structure requirements mail message are set out in Appendix 12 to this document.
APPROVED
order of the Federal Tax Service of Russia
from " 19
» 04
2012
№ MMV-7-6/ [email protected]
Unified Shipping Container Format
during information interaction with receiving complexes
tax authorities via telecommunication channels
using an electronic signature
1. Terms and definitions
1.1. Electronic document(document) - a document submitted in electronic form, in accordance with the requirements of the format for this type of document.
1.2. transaction- a single step of transferring a container with documents and electronic signatures of the required type (ES) within the framework of a workflow of a certain type, which determines the set of transferred documents, ES, their sender and recipient.
1.3. Electronic document management (document flow)- a sequence of transactions for the exchange of documents between participants in the document flow, providing some regulated process for the exchange of documents (for example, document flow for the submission of tax returns (accounting reports)).
1.4. shipping container- a set of logically related documents and ES, as well as related transport information, combined into one file.
1.5. Subscriber- a registered participant in information interaction who is a taxpayer or an authorized representative of a taxpayer.
1.6. NBO - tax declarations (calculations), financial statements and other documents that serve as the basis for the calculation and payment of taxes and fees.
2. General information
2.1. This document describes the structure of the transport container generated and processed by the software of the tax authority in the course of information interaction with specialized telecom operators and subscribers in electronic form via telecommunication channels using ES to ensure the organization of electronic document management when taxpayers submit tax returns (calculations), financial statements and other documents serving as the basis for the calculation and payment of taxes and fees. The list of types of workflow is given in Appendices 4-11 to this document.
2.2. Information interaction occurs through the implementation of document flow through transactions - the transfer from one participant in the document flow to another transport container with a set of documents and ES fixed for this transaction, made on behalf of authorized persons of the relevant participants in the document flow.
2.3. During the workflow, documents are transmitted in compressed and encrypted form, unless otherwise specified for a particular type of workflow. ES under documents are transferred in open form.
2.4. For each type of workflow, the formats of service and technological documents used are given in the directory of types of workflow, posted on the website www. *****
3. General requirements to the composition of the container
3.1. Contents of the shipping container
The transport container is a zip archive containing:
- a file with transport information in xml format; zip-archives of files with the contents of transferred documents; zip-archives of files with descriptions of documents; files with the contents of the transferred ES;
The scheme of the transport container is shown in Figure 1.
Microsoft" href="/text/category/microsoft/" rel="bookmark">Microsoft Word, Microsoft Excel, Open Document Text, Document Spreadsheet, Open XML Word, and Open XML Spreadsheet that contain scanned images, the requirements are: black and white with a scanned document resolution of at least 150 and no more than 300 dpi using 256 grayscale.
3.4. Requirements for the types of workflow are given in Appendices 4 - 11 , 1 to this document.
4. Types of document flow participants and their identification
4.1. The workflow is carried out between the following participants in the workflow.
Symbol | Description |
subscriber | Taxpayer ( entity or individual entrepreneur) or his authorized representative |
tax authority | Tax authority of the Federal Tax Service of Russia |
special operator | Specialized telecom operator |
trusted CA | Certification authority included in the Network of Trusted CAs of the Federal Tax Service of Russia |
4.2. Identifiers of document flow participants consist of Latin characters a–z, 0–9, “@”, “.” and "-". Identifiers are case insensitive.
4.3. The four-digit code of the tax authority in the coding of the SOUN classifier is used as the identifier of the tax authority.
4.4. A unique three-character code determined by the Federal Tax Service of Russia is used as an identifier for a specialized telecom operator and a trusted certification authority.
4.5. The subscriber ID has the format
<префикс системы><код абонента>
<префикс системы>is the identifier of a specialized telecom operator or a trusted certification authority; length<префикса системы>is equal to 3 characters;<префикс системы>must match the identifier of the specialized telecom operator whose services the subscriber uses;
<код абонента>is a unique subscriber code used in the internal system of a specialized telecom operator or a trusted certification center; length<код абонента>no more than 43 characters.
5. Specification of technologies used
5.1. Universally Unique Identifiers
5.1.1. Universally Unique Identifiers (UUIDs) are used to identify workflows, documents, and to generate file names in a transport container.
5.1.2. The UUIDs used must be generated according to the general principles for generating UUIDs as outlined in RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt). Universally unique identifiers are represented as a 32-digit hexadecimal number written in lowercase.
5.2. Combining and Compressing Files
5.2.1. The zip archive format is used to combine multiple documents into a single shipping container and to compress the documents.
5.2.2. The zip archive format is described in the open specification available at http://www. /documents/casestudies/APPNOTE. txt. Archiving must be done in accordance with the basic features of version 2.0, without the use of encryption.
5.2.3. The document is given the name "file" before compression, after which it is stored in the archive. The name of the archive is formed in accordance with paragraph 3.1.1. When extracting a document from an archive, information from the transport information description file is used to restore the original file name.
5.3. Cryptography
5.3.1. Algorithms used for encryption GOST. Algorithms are used to generate ES GOST R 34.10-2001.
5.3.2. Encrypted data and ES are transferred using a PKCS #7 container (RFC 2315, http://www.ietf.org/rfc/rfc2315.txt). DER encoding is used to save to a file.
5.3.3. Encrypted data is transmitted as a structure ContentInfo with structure EnvelopedData as content.
5.3.4. EPs are transmitted as a structure ContentInfo with structure SignedData as content. The ES must include a certificate relating to it and must not include a document signed by it.
5.3.5. Encryption of documents transmitted as part of the primary transport container must be performed to the address of the public keys of the recipient's certificates specified for encryption, and the public keys of the sender's certificates. Encryption of documents transmitted as a result of receiving or processing an incoming document is carried out to the address of the public keys of the recipient's certificates specified for encryption, the public keys of the sender's certificates and the public keys of the certificates of the officials who signed the incoming document.
6. General requirements for the composition of the mail message when interacting with the unified system for submitting tax returns and financial statements in electronic form via telecommunication channels
When using the exchange of messages between specialized telecom operators and servers for the exchange of electronic documents of the unified receiving complex of the tax authority using the SMTP and POP3 protocols in the format of email messages, the requirements for the structure of the mail message are established in Appendix 12 to this document.
I. NBO document description format
(Version 02)
1. GENERAL
1.1. Purpose
This document describes the requirements for XML files for the electronic transmission of information about the NBO document contained in the transport container (hereinafter referred to as the exchange file).
2. DESCRIPTION OF THE EXCHANGE FILE
TR_DEKL_2_700_02_09_02_xx, where xx is Current version scheme.
The filename extension is xsd.
Format character string indicated in the form T(n-k) or T(=k), where n is the minimum number of characters in a line, k - maximum amount characters, the symbol ”-” is a separator, the symbol ”=” means fixed amount characters per line. If the minimum number of characters is 0, the format is T(0-k). If the maximum number of characters is unlimited, the format is T(n-). If the element is of indeterminate length, the format is T
· Additional Information. For complex elements, a link is provided to a table that describes the composition of this element. For elements that take a limited list of values from the classifier (code dictionary, etc.), the corresponding name of the classifier (code dictionary, etc.) is indicated or a list is given possible values. For a classifier (code dictionary, etc.), a reference to its location can be indicated. For elements that use a custom data type, the name of the type element is specified.
3. File exchange diagram
Fig.1. Exchange File Structure Diagram
4. List of structural elements of the logical model of the exchange file
The list of structural elements of the logical model of the exchange file is given in Table. 4.1
Table 4.1 |
||||||||||
Description of the transferred NBO document (description) |
||||||||||
Element name | Abbreviated name (code) of the element | Element type attribute | Element Format | Sign of mandatory element | Additional Information |
|||||
The name of the form of the transferred NBO document | nameForms | |||||||||
KND of the transmitted document NBO | KNDForms | |||||||||
Type of transferred document NBO | type of document | Accepts the values "primary" or "corrective" |
||||||||
Reporting year for which the NBO document is submitted | Generic element |
|||||||||
Code of the period for which the NBO document is transmitted | codePeriod | Code of the period for which the NBO document is transmitted, according to the Directory of codes defining the tax (reporting) period (SKNP) Coincides with the tax (reporting) period specified in the reporting Required if included in the report |
||||||||
Code of the tax authority in which the subscriber is registered | NPOLocationAccounting | Generic element<СОНОТип> |
||||||||
Code of the tax authority in which the administration of the object of taxation is carried out, according to which the NBO document is transmitted | NPOLocation | Generic element<СОНОТип>Codes from the Classifier of the system of designations of tax authorities |
||||||||
additional information | Generic element |
|||||||||
II. Format of the description of the appeal, letter and mailing list
(Version 02)
1. GENERAL
1.1. Purpose
This document describes the requirements for XML files for the electronic transmission of information about the description of the appeal, letter and distribution.
2. DESCRIPTION OF THE EXCHANGE FILE
2.1. General information about the exchange file
The name of the exchange file should look like this:
The file name extension is xml. The filename extension can be specified in both lowercase and uppercase letters.
Parameters of the first line of the exchange file
The first line of the XML file should look like this:
The name of the file containing the schema of the exchange file
The name of the file containing the XSD schema of the exchange file should look like this:
TR_PISRAS_2_700_03_09_02_xx, where xx is the current schema version.
The filename extension is xsd.
2.2. The logical model of the exchange file
The logical model of the file is presented graphically in Section 3 in Figure 1. The elements of the logical model of the exchange file are the elements and attributes of the XML file. A complete list of the structural elements of the logical file model and information about them is given in Section 4.
For each structural element of the logical file model, Section 4 provides the following information:
· The name of the element. The full name of the element is given.
· Abbreviated name of the element. The abbreviated name of the element is given. Abbreviated names can be written in letters and numbers.
· Sign of element type. It can take the following values: "C" - complex element(having nested ones), "P" - a simple element (having no nested ones); A is an attribute. If a custom data type is used to define an element, the name of the data type (typical element) is indicated in the "Additional Information" column.
element format. The format is presented in legend, which correspond to the following values: Т – character string; N is a numeric value (whole or fractional).
The format of a character string is specified as T(n-k) or T(=k), where n is the minimum number of characters in a string, k is the maximum number of characters, the symbol ”-” is a separator, the symbol ”=” means a fixed number of characters in line. If the minimum number of characters is 0, the format is T(0-k). If the maximum number of characters is unlimited, the format is T(n-). If the element is of indeterminate length, the format is T.
The format of a numeric value is specified as N(m. k), where m is the maximum number of characters in the number, including the sign (for a negative number), integer, and fractional part number without a separating decimal point, and k is the maximum number of decimal places. If the number of decimal places is 0 (that is, the number is an integer), then the format of the numeric value is N(m).
For simple elements that are basic in XML (defined at http://www.w3.org/TR/xmlschema-0), such as an element of type “date”, the “Element Format” field is left blank. For such elements, the type of the base element is indicated in the “Additional information” field.
The sign of the mandatory element determines the mandatory presence of the element in XML file. The attribute of the mandatory element can take the following values: “O” – the mandatory presence of the element (the name of the element and its value must be present in the exchange file); “H” – the presence of the element is optional (the name of the element and its value in the exchange file may be absent). If an element can take a limited list of values (according to the classifier, code dictionary, etc.), then the attribute of the element's obligation is supplemented with the symbol "К". For example: "OK". If the number of implementations of an element can be more than one, then the mandatory sign of the element is supplemented with the symbol “M”. For example: "OM, OKM".