Фирмите имат възможност да доставят електронно отчитанене само чрез специални оператори, но и директно през портала на Федералната данъчна служба на Русия. Засега това е пилотен проект, но според данъчната служба до края на септември услугата ще заработи напълно. А чрез него ще могат да се подават декларации за третото тримесечие (девет месеца). И сега можете да тренирате върху "усъвършенстванията". Алгоритъмът на действията е следният.
1 . Вземете електронен подпис и абонатен идентификатор
Чрез уебсайта на Федералната данъчна служба можете да подадете декларация, подписана само от законен представител, тоест директор, но не и главен счетоводител. Фирмите, които вече се отчитат чрез специални оператори, могат да използват съществуващия електронен подпис. Но тези, които преди това са докладвали само на хартия, първо ще трябва да закупят сертификат във всеки сертификационен център, включен в мрежата на DTC на Федералната данъчна служба на Русия (списъкът е на уебсайта www.nalog.ru). Средно това е 6-10 хиляди рубли.
Необходимо е да информирате специалния оператор, че компанията ще докладва през уебсайта. Едва след това специалният оператор ще регистрира компанията на портала на Федералната данъчна служба на Русия и ще предостави идентификатора на абоната (уникален код, без който не може да се изпраща отчет).
2 . Инсталирайте специализирана програма
За съставяне на декларация и качване на файл е необходима програмата "Данъкоплатец на юридическо лице". Можете да го изтеглите безплатно от уебсайта www.nalog.ru в раздела „Софтуер за юридически и физически лица“. Не е необходимо да въвеждате отново всички отчетни данни, можете да ги импортирате от вашия компютър от счетоводна програмаили флашки („Сервиз“ > „Получаване на отчети от магнитни носители“). Успешно подготвен и качен файл ще бъде добавен в "Регистър на качените файлове" (бутон "Инструменти").
3 . Оформете транспортен контейнер с декларация
Преди изпращане файлът се „опакова“ заедно с цифровия подпис и идентификатора в транспортен контейнер. За да направите това, трябва да отидете в "Регистър на качените файлове", да изберете файла с декларацията и да натиснете бутона "Генериране на транспортен контейнер" от лентата с инструменти.
4. Изпращайте отчети през портала на данъчната служба
За да подадете отчети, трябва да отидете на www.nalog.ru в раздела „Представяне на данъчни и счетоводни отчети в EV“. Но преди това е по-добре да се уверите в това софтуеротговаря на изискванията на портала (напр. операционна систематрябва да е Microsoft Windows XP, Vista или 7 и браузърът е Microsoft Internet Explorer 6.0 и по-нова версия или Safari 4.0 или по-нова версия). За да направите това, щракнете върху връзката „Извършване на проверка на условията“. След успешна проверка можете да разтоварите транспортния контейнер и да го изпратите на проверка.
5 . Проверете дали докладите са предадени на инспекцията
Междурегионалният инспекторат за централизирана обработка на данни действа като специален оператор при изпращане на сигнали през портала. В потвърждение за приемане на декларацията тя изпраща разписка. Денят на подаване на декларацията ще бъде датата, посочена в разписката като дата на изпращане на отчета (клауза 4, член 80 от Данъчния кодекс на Руската федерация). Ако обаче отчетността не премине форматно-логическия контрол, компаниите ще докладват отказа за приемането й и причините. Ако бъдат премахнати, отчетът може да бъде подаден отново.
Статията е публикувана във вестник "УНП" бр.30,
JSC GNIVTS (FTS на Русия): 08/05/2016 от 05:00 московско време поради технологична работа на площадката на FDC, компонентите на федерално ниво (GPK, SM, IRUD, SP FU) на приемния комплекс GP-3 ще бъдете недостъпни. Очакваното време за завършване е 12:00 московско време.В същото време компанията Link-Serviceще задържи инженерни работи. пощенски сървър в дадено времеможе да не е достъпен за изпращане/получаване на имейли. Извиняваме се за причиненото неудобство.Публикувано на 4 авг 2016 10:55 от Вячеслав Абисалов
Публикувано на 19 ян 2016 г., 04:51 ч. от Вячеслав Абисалов
Публикувано на 18 ян. 2016, 08:22 от Вячеслав Абисалов
Изпратено на 8 дек. 2015, 11:24 от Вячеслав Абисалов
Изпратено на 6 дек. 2015, 13:49 от Вячеслав Абисалов
УНИФИЦИРАН ФОРМАТ НА ТРАНСПОРТЕН КОНТЕЙНЕР ПРИ ИНФОРМАЦИОННО ВЗАИМОДЕЙСТВИЕ С ПРИЕМАЩИ КОМПЛЕКСИ НА ДАНЪЧНИТЕ ОРГАНИ ЧРЕЗ ТЕЛЕКОМУНИКАЦИОННИ КАНАЛИ С ИЗПОЛЗВАНЕ НА ЕЛЕКТРОНЕН ЦИФРОВ ПОДПИС
1. Термини и определения1.1. Електронен цифров подпис(EDS) - атрибут на електронен документ, предназначен да защити този електронен документ от фалшифициране, получен в резултат на криптографска трансформация на информация и позволяващ да се идентифицира собственикът на сертификата за ключ за подпис, както и да се установи липсата на изкривяване на информация в електронния документ.
1.2. Сертификат за ключ за подпис (сертификат) - документ на хартиен носител или електронен документ с EDS на упълномощено лице от Удостоверяващия орган (наричан по-долу УО), който включва публичен ключ и се издава от УО за потвърждаване на автентичността. на EDS, идентифицира собственика на сертификата и гарантира поверителността на предадената информация.
1.3. Електронен документ (документ) - документ, представен в електронна форма в съответствие с изискванията на формата за от този типдокумент.
1.4. Транзакция - една стъпка на прехвърляне на контейнер с документи и EDS в рамките на определен тип работен процес, който определя набора от прехвърлени документи, EDS, техния подател и получател.
1.5. Електронно управление на документи (документооборот) - последователност от транзакции за обмен на документи между участниците в документопотока, осигуряващи някакъв регулиран процес за обмен на документи (например документооборот за подаване на данъчни декларации (счетоводни отчети)) .
1.6. Транспортен контейнер - набор от логически свързани документи и EDS, както и свързана транспортна информация, обединени в един файл.
1.7. Абонат - регистриран участник в информационното взаимодействие, който е данъкоплатец или упълномощен представител на данъкоплатец.
1.8. НБО - данъчни декларации (изчисления), финансови отчети и други документи, които служат като основа за изчисляване и плащане на данъци и такси.
2. Обща информация2.1. Този документописва структурата на формирания и обработен транспортен контейнер софтуерни инструментиданъчен орган в процеса на информационно взаимодействие със специализирани телекомуникационни оператори и абонати в електронна форма чрез телекомуникационни канали, използвайки EDS, за да осигури организирането на електронно управление на документи, когато данъкоплатците подават данъчни декларации (изчисления), финансови отчети и други документи, които служат като основа за изчисляване и плащане на данъци и такси. Списъкът на видовете работни процеси е даден в приложения 4 - 11 към този документ.
2.2. Информационното взаимодействие се осъществява чрез осъществяване на документен поток чрез транзакции - прехвърлянето от един участник в документния поток към друг транспортен контейнер с набор от документи и EDS, фиксирани за тази транзакция, извършено от името на упълномощени лица на съответните участници в документа поток.
2.3. По време на работния процес документите се предават в компресирана и криптирана форма, освен ако не е посочено друго за определен тип работен поток. EDS под документите се прехвърлят в ясен текст.
2.4. За всеки тип работен процес използваните формати на услуги и технологични документи са дадени в справочника на видовете работни процеси, публикуван на уебсайта www.nalog.ru.
3. Общи изисквания към състава на контейнера3.1. Съдържание на транспортния контейнер
Транспортният контейнер е zip архив, съдържащ:
Файл с транспортна информация в xml формат;
Zip-архиви на файлове със съдържанието на прехвърлените документи;
Zip архиви на файлове с описания на документи;
Файлове със съдържанието на предадения EDS.
Схемата на транспортния контейнер е показана на фигура 1.
Фигура 1. Схема на транспортния контейнер (не е показан)
3.1.1. Файловете със съдържание на документи и цифрови подписи се наименуват с помощта на универсални уникални идентификатори във формат "
3.1.2. Транспортната информация и файловете със съдържанието на документи и цифрови подписи се комбинират в zip архив в режим STORE. Файлът с транспортна информация не е компресиран или криптиран, когато се прехвърля в транспортен контейнер.
3.1.3. Документи и EDS, свързани с една сделка, се прехвърлят в един транспортен контейнер.
3.1.4. Описанието на документа присъства в транспортния контейнер като отделен zip-архив, ако описанието на документа се определя от вида на документа, който се прехвърля. Форматът на описанието на документа е даден в Приложение 1 към този документ. Описанието на документа съдържа допълнителна информация за прехвърления файл и е само за информационни цели. Документът може да се използва за предоставяне на по-информативно диагностично съобщение, когато файловете на транспортния контейнер не могат да бъдат декриптирани.
3.1.5. Форматът на описанието на транспортната информация е даден в допълнение 2 към този документ.
3.2. Име на файл за транспортен контейнер
3.2.1. Транспортният контейнер се предава като файл с уникално име според формата
3.2.4. Ако в контейнера има няколко документа, кодът на документа, чието име е включено в името на вида транзакция, се посочва в името на файла на транспортния контейнер.
3.2.5. Информацията в името на файла трябва да съвпада със съответната информация в транспортната информация на контейнера.
3.3. Описанията на типовете съдържание на документи са предоставени в Приложение 3 към този документ.
3.4. Изискванията към видовете работни процеси са дадени в Приложения 4 - 11 към този документ.
4. Видове участници в документооборота и тяхната идентификация4.1. Работният процес се извършва между следните участници в работния поток.
4.3. Четирицифреният код на данъчния орган в кодирането на класификатора SOUN се използва като идентификатор на данъчния орган.
4.4. Уникален код от три знака, определен от Федералната данъчна служба на Русия, се използва като идентификатор за специализиран телеком оператор и доверен сертифициращ орган.
4.5. Идентификационният номер на абоната има формат
| <префикс системы><код абонента> |
<префикс системы>- това е идентификаторът на специализиран телеком оператор или доверен удостоверяващ орган; дължина<префикса системы>е равно на 3 знака;<префикс системы>трябва да съвпада с идентификатора на специализирания телекомуникационен оператор, чиито услуги абонатът ползва;
<код абонента>е уникален абонатен код, използван в вътрешна системаспециализиран телеком оператор или доверен сертифициращ орган; дължина<код абонента>не повече от 43 знака.
5. Спецификация на използваните технологии5.1. Универсални уникални идентификатори
5.1.1. Универсалните уникални идентификатори (UUID) се използват за идентифициране на работни потоци, документи и за генериране на имена на файлове в транспортен контейнер.
5.1.2. Използваните универсални уникални идентификатори трябва да бъдат генерирани според основни принципиГенериране на UUID, както е посочено в RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt). Универсалните уникални идентификатори се представят като 32-цифрено шестнадесетично число, изписано с малки букви.
5.2. Комбиниране и компресиране на файлове
5.2.1. Архивният формат zip се използва за комбиниране на множество документи в един транспортен контейнер и за компресиране на документите.
5.2.2. Форматът на zip архива е описан в отворената спецификация, достъпна на http://www.pkware.com/documents/casestudies/APPNOTE.TXT. Архивирането трябва да се извършва в съответствие с основни възможностиверсия 2.0, без използване на криптиране.
5.2.3. Документът получава името "файл" преди компресиране, след което се съхранява в архива. Името на архива се формира в съответствие с параграф 3.1.1. Когато извличате документ от архив, информацията от файла с описание на транспортната информация се използва за възстановяване на оригиналното име на файл.
5.3. Криптография
5.3.1. За криптиране се използват алгоритми GOST 28147-89. За формиране на EDS се използват алгоритми GOST R 34.10-2001.
5.3.2. Шифрованите данни и EDS се прехвърлят с помощта на контейнера PKCS #7 (RFC 2315, /content/base/). DER кодирането се използва за запис във файл.
5.3.3. Шифрованите данни се предават като структура ContentInfo със структура EnvelopedData като съдържание.
5.3.4. Цифровите подписи се предават като структура ContentInfo със структура SignedData като съдържание. Цифровият подпис може да включва сертификат и не трябва да включва подписано съдържание.
5.3.5. Криптирането на документи, предадени като част от първичния транспортен контейнер, трябва да бъде направено до адреса публични ключовесертификатите на получателя, посочени за криптиране, и публичните ключове на сертификатите на подателя. Криптирането на документи, предадени в резултат на получаване или обработка на входящ документ, се извършва на адреса на публичните ключове на сертификатите на получателя, посочени за криптиране, публичните ключове на сертификатите на изпращача и публичните ключове на сертификатите на длъжностните лица, които подписал входящия документ.
6. Общи изисквания към състава на пощенското съобщение при взаимодействие с единната система за подаване на данъчни декларации и финансови отчети в електронен вид по телекомуникационни каналиПри използване на обмен на съобщения между специализирани телекомуникационни оператори и сървъри за обмен на електронни документи на единния приемен комплекс на данъчния орган с помощта на протоколите SMTP и POP3 във формат на съобщението електронна пощаструктурни изисквания имейл съобщениеса посочени в Приложение 12 към този документ.
ОДОБРЕНО
заповед на Федералната данъчна служба на Русия
от " 19
» 04
2012 г
№ MMV-7-6/ [имейл защитен]
Унифициран формат на контейнер за доставка
по време на информационно взаимодействие с приемни комплекси
данъчни органи чрез телекомуникационни канали
с помощта на електронен подпис
1. Термини и определения
1.1. Електронен документ(документ) - документ, представен в електронен вид, в съответствие с изискванията на формата за този вид документ.
1.2. сделка- една стъпка на прехвърляне на контейнер с документи и електронни подписиот необходимия тип (ES) в рамките на работен процес от определен тип, който определя набора от прехвърляни документи, ES, техния подател и получател.
1.3. Електронно управление на документи (управление на документи)- поредица от транзакции за обмен на документи между участниците в документооборота, осигуряващи някакъв регламентиран процес за обмен на документи (например документооборот за подаване на данъчни декларации (счетоводни отчети)).
1.4. транспортен контейнер- набор от логически свързани документи и ES, както и свързана транспортна информация, обединени в един файл.
1.5. Абонат– регистриран участник в информационното взаимодействие, който е данъкоплатец или упълномощен представител на данъкоплатец.
1.6. НБО -данъчни декларации (изчисления), финансови отчети и други документи, които служат като основа за изчисляване и плащане на данъци и такси.
2. Главна информация
2.1. Този документ описва структурата на транспортния контейнер, генериран и обработен от софтуера на данъчния орган в хода на информационното взаимодействие със специализирани телекомуникационни оператори и абонати в електронен вид чрез телекомуникационни канали, използващи ES, за да се осигури организирането на електронно управление на документи, когато данъкоплатците подават данъчни декларации (изчисления), финансови отчети и други документи, служещи като основа за изчисляване и плащане на данъци и такси. Списъкът на видовете работни процеси е даден в Приложения 4-11 към този документ.
2.2. Информационното взаимодействие се осъществява чрез осъществяване на документен поток чрез транзакции - прехвърлянето от един участник в документния поток към друг транспортен контейнер с набор от документи и ES, фиксирани за тази транзакция, извършено от името на упълномощени лица на съответните участници в документа поток.
2.3. По време на работния процес документите се предават в компресирана и криптирана форма, освен ако не е посочено друго за определен тип работен поток. ES по документи се прехвърлят в отворена форма.
2.4. За всеки тип работен процес използваните формати на сервизни и технологични документи са дадени в директорията на видовете работен процес, публикувана на уебсайта www. *****
3. Общи изискваниякъм състава на контейнера
3.1. Съдържание на транспортния контейнер
Транспортният контейнер е zip архив, съдържащ:
- файл с транспортна информация в xml формат; zip-архиви на файлове със съдържанието на прехвърлени документи; zip-архиви на файлове с описания на документи; файлове със съдържанието на прехвърлените ES;
Схемата на транспортния контейнер е показана на фигура 1.
Microsoft" href="/text/category/microsoft/" rel="bookmark">Microsoft Word, Microsoft Excel, Open Document Text, Document Spreadsheet, Open XML Word и Open XML Spreadsheet, които съдържат сканирани изображения, трябва да са черно-бели с разделителна способност на сканирания документ от най-малко 150 и не повече от 300 dpi, използвайки 256 нива на сивото.
3.4. Изискванията към видовете работни процеси са дадени в Приложения 4 - 11 , 1 към този документ.
4. Видове участници в документооборота и тяхната идентификация
4.1. Работният процес се извършва между следните участници в работния поток.
Символ | Описание |
абонат | данъкоплатец ( образуваниеили индивидуален предприемач) или негов упълномощен представител |
данъчен орган | Данъчен орган на Федералната данъчна служба на Русия |
специален оператор | Специализиран телеком оператор |
доверен CA | Сертифициращ орган, включен в мрежата от доверени CA на Федералната данъчна служба на Русия |
4.2. Идентификаторите на участниците в документния поток се състоят от латински букви a–z, 0–9, „@“, „.“ и "-". Идентификаторите не са чувствителни към главни и малки букви.
4.3. Четирицифреният код на данъчния орган в кодирането на класификатора SOUN се използва като идентификатор на данъчния орган.
4.4. Уникален код от три знака, определен от Федералната данъчна служба на Русия, се използва като идентификатор за специализиран телеком оператор и доверен сертифициращ орган.
4.5. Идентификационният номер на абоната има формат
<префикс системы><код абонента>
<префикс системы>е идентификатор на специализиран телеком оператор или доверен удостоверяващ орган; дължина<префикса системы>е равно на 3 знака;<префикс системы>трябва да съвпада с идентификатора на специализирания телекомуникационен оператор, чиито услуги абонатът ползва;
<код абонента>е уникален абонатен код, използван във вътрешната система на специализиран телеком оператор или доверен удостоверителен център; дължина<код абонента>не повече от 43 знака.
5. Спецификация на използваните технологии
5.1. Универсални уникални идентификатори
5.1.1. Универсалните уникални идентификатори (UUID) се използват за идентифициране на работни потоци, документи и за генериране на имена на файлове в транспортен контейнер.
5.1.2. Използваните UUID трябва да бъдат генерирани в съответствие с общите принципи за генериране на UUID, както е посочено в RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt). Универсалните уникални идентификатори се представят като 32-цифрено шестнадесетично число, изписано с малки букви.
5.2. Комбиниране и компресиране на файлове
5.2.1. Архивният формат zip се използва за комбиниране на множество документи в един транспортен контейнер и за компресиране на документите.
5.2.2. Форматът на zip архива е описан в отворената спецификация, достъпна на http://www. /documents/casestudies/APPNOTE. текст. Архивирането трябва да се извърши в съответствие с основните характеристики на версия 2.0, без използване на криптиране.
5.2.3. Документът получава името "файл" преди компресиране, след което се съхранява в архива. Името на архива се формира в съответствие с параграф 3.1.1. Когато извличате документ от архив, информацията от файла с описание на транспортната информация се използва за възстановяване на оригиналното име на файл.
5.3. Криптография
5.3.1. Алгоритми, използвани за криптиране ГОСТ. Алгоритмите се използват за генериране на ES ГОСТ Р 34.10-2001.
5.3.2. Шифрованите данни и ES се прехвърлят с помощта на контейнер PKCS #7 (RFC 2315, http://www.ietf.org/rfc/rfc2315.txt). DER кодирането се използва за запис във файл.
5.3.3. Криптираните данни се предават като структура ContentInfoсъс структура EnvelopedDataкато съдържание.
5.3.4. ОзВ се предават като структура ContentInfoсъс структура SignedDataкато съдържание. ES трябва да включва свързан с него сертификат и не трябва да включва документ, подписан от него.
5.3.5 Криптирането на документи, предавани като част от първичния транспортен контейнер, трябва да се извърши на адреса на публичните ключове на сертификатите на получателя, посочени за криптиране, и публичните ключове на сертификатите на подателя. Криптирането на документи, предадени в резултат на получаване или обработка на входящ документ, се извършва на адреса на публичните ключове на сертификатите на получателя, посочени за криптиране, публичните ключове на сертификатите на изпращача и публичните ключове на сертификатите на длъжностните лица, които подписал входящия документ.
6. Общи изисквания към състава на пощенското съобщение при взаимодействие с единната система за подаване на данъчни декларации и финансови отчети в електронен вид по телекомуникационни канали
При използване на обмен на съобщения между специализирани телекомуникационни оператори и сървъри за обмен на електронни документи на единния приемен комплекс на данъчния орган, използвайки протоколите SMTP и POP3 във формат на имейл съобщения, изискванията за структурата на пощенското съобщение са установени в Приложение 12 към този документ.
аз. Формат на описание на документа на NBO
(Версия 02)
1. ОБЩИ ПОЛОЖЕНИЯ
1.1. Предназначение
Този документ описва изискванията за XML файлове за електронно предаване на информация за NBO документа, съдържащ се в транспортния контейнер (наричан по-долу файл за обмен).
2. ОПИСАНИЕ НА ФАЙЛА ЗА ОБМЕН
TR_DEKL_2_700_02_09_02_xx, където xx е Сегашна версиясхема.
Разширението на името на файла е xsd.
формат символен низпосочен във формата T(n-k) или T(=k), където n е минималният брой знаци в ред, k - максимална сумасимволи, символът ”-” е разделител, символът ”=” означава фиксирана сумазнака на ред. Ако минималният брой знаци е 0, форматът е T(0-k). Ако максималният брой знаци е неограничен, форматът е T(n-). Ако елементът е с неопределена дължина, форматът е T
· Допълнителна информация. За сложни елементи е предоставена връзка към таблица, която описва състава на този елемент. За елементи, които вземат ограничен списък от стойности от класификатора (кодов речник и т.н.), се посочва съответното име на класификатора (кодов речник и т.н.) или се дава списък възможни стойности. За класификатор (кодов речник и др.) може да се посочи препратка към местоположението му. За елементи, които използват персонализиран тип данни, се посочва името на елемента тип.
3. Диаграма за обмен на файлове
Фиг. 1. Диаграма на структурата на файла за обмен
4. Списък на структурните елементи на логическия модел на файла за обмен
Списъкът на структурните елементи на логическия модел на файла за обмен е даден в табл. 4.1
Таблица 4.1 |
||||||||||
Описание на прехвърления НБО документ (описание) |
||||||||||
Име на елемент | Съкратено наименование (код) на елемента | Атрибут тип елемент | Формат на елемент | Знак на задължителен елемент | Допълнителна информация |
|||||
Името на формуляра на прехвърления НБО документ | nameShapes | |||||||||
КНД на предадения документ НБО | KNDForms | |||||||||
Вид на прехвърляния документ НБО | вид документ | Приема стойностите "основен" или "коригиращ" |
||||||||
Отчетна година, за която се представя документът за НБО | Общ елемент |
|||||||||
Код на периода, за който се предава НБО документа | codePeriod | Код на периода, за който се предава NBO документът, съгласно Справочника на кодовете, определящи данъчния (отчетен) период (SKNP) Съвпада с данъчния (отчетен) период, посочен в отчета Задължително, ако е включено в отчета |
||||||||
Код на данъчния орган, в който е регистриран абонатът | NPOLlocationAccounting | Общ елемент<СОНОТип> |
||||||||
Код на данъчния орган, в който се извършва администрирането на обекта на данъчно облагане, според който се предава документът на НБО | NPOLлокация | Общ елемент<СОНОТип>Кодове от Класификатора на системата от наименования на данъчните органи |
||||||||
Допълнителна информация | Общ елемент |
|||||||||
II. Формат на описанието на жалбата, писмото и пощенския списък
(Версия 02)
1. ОБЩИ ПОЛОЖЕНИЯ
1.1. Предназначение
Този документ описва изискванията за XML файлове за електронно предаване на информация относно описанието на жалбата, писмото и разпространението.
2. ОПИСАНИЕ НА ФАЙЛА ЗА ОБМЕН
2.1. Обща информация за обменния файл
Името на файла за обмен трябва да изглежда така:
Разширението на името на файла е xml. Разширението на името на файла може да бъде посочено както с малки, така и с главни букви.
Параметри на първия ред на файла за обмен
Първият ред на XML файла трябва да изглежда така:
Името на файла, съдържащ схемата на файла за обмен
Името на файла, съдържащ XSD схемата на файла за обмен, трябва да изглежда така:
TR_PISRAS_2_700_03_09_02_xx, където xx е текущата версия на схемата.
Разширението на името на файла е xsd.
2.2. Логическият модел на файла за обмен
Логическият модел на файла е представен графично в раздел 3 на фигура 1. Елементите на логическия модел на файла за обмен са елементите и атрибутите на XML файла. Пълен списък на структурните елементи на логическия файлов модел и информация за тях е дадена в Раздел 4.
За всеки структурен елемент на логическия файлов модел Раздел 4 предоставя следната информация:
· Името на елемента. Посочено е пълното име на елемента.
· Съкратено наименование на елемента. Дадено е съкратеното наименование на елемента. Съкратените имена могат да се изписват с букви и цифри.
· Знак за вид елемент. Може да приема следните стойности: "C" - сложен елемент(с вложени), "P" - прост елемент (без вложени); А е атрибут. Ако за дефиниране на елемент се използва персонализиран тип данни, името на типа данни (типичен елемент) се посочва в колоната „Допълнителна информация“.
формат на елемента. Форматът е представен в легенда, които отговарят на следните стойности: Т – символен низ; N е числова стойност (цяла или дробна).
Форматът на символен низ е посочен като T(n-k) или T(=k), където n е минималният брой знаци в низ, k е максималният брой знаци, символът ”-” е разделител, символът ”=” означава фиксиран брой знаци в ред. Ако минималният брой знаци е 0, форматът е T(0-k). Ако максималният брой знаци е неограничен, форматът е T(n-). Ако елементът е с неопределена дължина, форматът е T.
Форматът на числова стойност е определен като N(m. k), където m е максималният брой знаци в числото, включително знака (за отрицателно число), цяло число и дробна частчисло без разделителна десетична запетая, а k е максималният брой десетични знаци. Ако броят на десетичните знаци е 0 (т.е. числото е цяло число), тогава форматът на числовата стойност е N(m).
За прости елементи, които са основни в XML (дефинирани на http://www.w3.org/TR/xmlschema-0), като елемент от тип „date“, полето „Element Format“ се оставя празно. За такива елементи типът на базовия елемент е посочен в полето „Допълнителна информация“.
Знакът на задължителния елемент определя задължителното присъствие на елемента в XML файл. Атрибутът на задължителния елемент може да приема следните стойности: “O” – задължителното присъствие на елемента (името на елемента и неговата стойност трябва да присъстват във файла за обмен); “H” – наличието на елемента не е задължително (името на елемента и стойността му във файла за обмен може да липсват). Ако даден елемент може да приеме ограничен списък от стойности (според класификатора, кодов речник и т.н.), тогава атрибутът на задължението на елемента се допълва със символа "К". Например: „ОК“. Ако броят на реализациите на даден елемент може да бъде повече от едно, тогава задължителният знак на елемента се допълва със символа „М“. Например: "OM, OKM".