1. Термины и определения

1. Электронный документооборот (ЭДО) - обмен электронными документами по утвержденному регламенту.

2. Регламент ЭДО - порядок осуществления обмена электронными документами.

3. Оператор - Оператор электронного документооборота - юридическое лицо, осуществляющее функции по обеспечению электронного документооборота и соответствующее требованиям Федерального закона от 27.07.2006 N 149-ФЗ "Об информации, информационных технологиях и о защите информации", а также иным требованиям, утверждаемым Правительством Российской Федерации.

4. Отправитель - хозяйствующий субъект, подключившийся к ЭДО через Оператора, который инициирует начало документооборота путем отправки электронных документов Получателю.

5. Получатель - хозяйствующий субъект, подключившийся к ЭДО через Оператора, который получает электронный документ от Отправителя.

6. Электронный документ (Документ) - документированная информация, представленная в электронной форме, то есть в виде, пригодном для восприятия человеком с использованием электронных вычислительных машин, а также для передачи по информационно-телекоммуникационным сетям или обработки в информационных системах.

7. Целевой электронный документ (ЦЭД) - содержательный упорядоченный набор данных, передача которого важна для Отправителя по существу инициированного документооборота.

8. Вспомогательный электронный документ (ВЭД) - структурированный набор данных, значимых для хозяйствующего субъекта и создаваемых получателем.

9. Технологический электронный документ (ТЭД) - упорядоченный набор данных, описывающий параметры транзакции, фиксирующий этапы прохождения ЦЭД.

10. Односторонний электронный документ - электронный документ, который подписывает только один хозяйствующий субъект.

11. Двухсторонний электронный документ - электронный документ, который подписывают два хозяйствующих субъекта.

12. Многосторонний электронный документ - электронный документ, который подписывают три и более хозяйствующих субъекта.

13. Приглашение (ПР) - специальный ЦЭД, использующийся для двухстороннего согласования установления ЭДО между хозяйствующими субъектами и обеспечивающий обмен необходимыми для этого реквизитами сторон.

14. Логическое сообщение (ЛС) - ТЭД, представляющий собой единицу передачи информации между Операторами, состоящую из нескольких файлов и содержащую в себе информацию о передаче комплекта электронных документов и/или электронных подписей между Операторами.

15. Транспортный пакет (ТП) - ТЭД, представляющий собой единицу передачи информации на технологическом уровне, состоящую из СМS-сообщения с присоединенной ЭП Оператора, включающее в себя ZIP-файл, который содержит одно или несколько ЛС и ПР, либо один XML-файл с технологическими квитанциями.

16. Электронная подпись (КЭП) - реквизит Документа, предназначенный для защиты данного Документа от подделки, полученный в результате криптографического преобразования информации с использованием закрытого ключа электронной подписи, позволяющий идентифицировать владельца сертификата ключа ЭП, установить отсутствие искажения информации в Документе и для создания и проверки электронной подписи используются средства электронной подписи, имеющие подтверждение соответствия требованиям, установленным Федеральным законом Федеральный закон от 06.04.2011 N 63-ФЗ "Об электронной подписи".

17. Извещение о получении документа (ИОП) - ВЭД, являющийся XML-файлом установленного формата, фиксирующий факт получения получателем Документа.

18. Уведомление о принятии документа (УОП) - ТЭД, являющийся ЭП получателя Документа в формате CMS, фиксирующий факт принятия (согласия с условиями) полученного Документа.

19. Уведомление об уточнении документа (УОУ) - ВЭД, являющийся XML-файлом установленного формата, фиксирующий факт несогласия получателя Документа с полученным Документом, допускающий корректировку, исправление Документа или отказ от подписи.

20. Технологическая квитанция (ТК) - ТЭД технологического уровня, предназначенный для фиксации факта передачи ЛС или ПР, и результат его обработки от Оператора другому Оператору.

21. Транспортная квитанция (ТрК) - ТЭД транспортного уровня, предназначенный для фиксации факта получения ТП и результат его обработки, при передачи его от Оператора другому Оператору. Документ представляет собой СМS-сообщение с присоединенной ЭП Оператора получателя Документа, включающее в себя один XML-файл с транспортной квитанцией.

22. Маршрут - путь следования транспортного пакета (ТП), учитывающий направление движения относительно всех участников обмена

23. ID абонента - идентификатор участника электронного документооборота, выданный оператором, необходимый для авторизации и маршрутизации транспортного пакета.

24. Прикладной уровень ЭДО - уровень взаимодействия хозяйствующих субъектов порядке обмена Документами. На прикладном уровне описан порядок формирования и обмена Документами, подтверждения их получения или отказа в получении.

- Факт отправки - формирование Документа отправителем, осуществление необходимых действий по отправке Документа через Оператора и получение подтверждения даты и времени отправки Оператором;

- Факт доставки - выполнение всех необходимых действий Оператором получателя Документа по обеспечению технического и физического доступа к Документу получателем и формирование ИОП;

- Факт принятия - выполнение всех необходимых действий получателем Документа для подтверждения своего согласия с поступившим Документом и формирования УОП. С этого момента обе стороны считают Документ согласованным;

- Факт отказа - выполнение всех необходимых действий получателем Документа для подтверждения своего несогласия с полученным Документом и формирование УОУ. С этого момента обе стороны считают Документ не согласованным;

25. Технологический уровень - уровень взаимодействия Операторов в целях обеспечения настоящего регламента.

- Факт передачи - выполнение всех необходимых действий Оператором отправителя Документа по передаче Документа Оператору получателя Документа. Передача Документа фиксируется ТК. С момента передачи Документа ответственность за дальнейшую доставку Документа переходит к Оператору получателя Документа. Оператор получателя с момента направления Оператору отправителю ТК об успешном приеме Документов не позднее 4 часов должен доставить содержащиеся в ЛС полученного ТП Документы соответствующему получателю Документов;

- Гарантия целостности - процедура подписания транспортного пакета ЭП Оператора отправителя Документа.

26. Транспортный уровень - уровень взаимодействия программных средств с использованием конкретных сетевых протоколов.

- Факт приема Оператором - прием Оператором транспортного пакета, и передача отправителю ТрК об успешном приеме Документов.

2. Введение

Цели создания Технологии обмена электронными документами между хозяйствующими субъектами через операторов электронного документооборота, а также между операторами электронного документооборота (далее - Технология):

- создание единой сети хозяйствующих субъектов, имеющих необходимость обмена электронными документами. Обеспечение возможности обмена документами, в том числе счетами-фактурами в соответствии с Приказом Минфина России от 05.02.2021 N 14н "Об утверждении Порядка выставления и получения счетов-фактур в электронной форме по телекоммуникационным каналам связи с применением усиленной квалифицированной электронной подписи".

- выработка единых требований к процессу обмена документами между хозяйствующими субъектами, а также единых форматов технологических документов.

Использование Технологии предполагает выработку правил использования сети обмена, порядка идентификации абонентов, структуры транспортного контейнера.

Для реализации указанных целей операторам электронного документооборота (далее - ЭДО) необходимо исполнение следующих функций в рамках данной Технологии:

- совместимость технических средств ЭДО как на стороне Отправителя, так и на стороне Получателя, в условиях заключения договоров с разными Операторами, обеспечивается в соответствии с данной Технологией;

- взаимодействие Операторов в части регламента документооборота, форматов документов, способов передачи и получения документов регулируемых данной Технологией;

- обеспечение каждым из Операторов равноправного доступа всех Операторов к функционалу приема и отправки документов при осуществлении межоператорского взаимодействия;

- исполнение процедур взаимодействия участников ЭДО при обмене Документами с применением ЭП в соответствии с Методическими рекомендациями по порядку обмена электронными документами между хозяйствующими субъектами (далее - Методические рекомендации) и утвержденными нормативно-правовыми актами Порядками обмена между хозяйствующими субъектами отдельными электронными документами

Участие в сети обмена электронными документами является открытым.

Оператор, присоединяющийся к сети обмена электронными документами, принимает на себя обязательства по выполнению требований настоящей Технологии.

3. Сеть обмена

Участники сети обмена, между которыми запущена промышленная эксплуатация, составляют промышленную сеть обмена Документами. Актуальное состояние промышленной сети обмена содержится в описании сети. Описание сети позволяет структурировать информацию обо всех участниках сети обмена Документами и о настроенной между ними промышленной эксплуатации ЭДО. Структура описания сети подробно описана в Приложении № 4. Оператор размещает на своем официальном сайте в информационно-телекоммуникационной сети "Интернет" описание сети обмена и обеспечивает ее актуальное состояние.

Взаимодействие происходит между Оператором отправителя Документа и другим Оператором получателя Документа.

Оператор размещает на своем официальном сайте в информационно-телекоммуникационной сети "Интернет" реестр электронных документов и их форматы, которыми хозяйствующие субъекты могут обмениваться между собой через данного Оператора.

4. Типы документов, участвующих в электронном документообороте

Документы, участвующие в электронном документообороте, подразделяются на 3 типа:

1. Целевые электронные документы (ЦЭД).

2. Вспомогательные электронные документы (ВЭД).

3. Технологические электронные документы (ТЭД).

4.1. Целевые электронные документы.

К ЦЭД, участвующим в электронном документообороте между хозяйствующими субъектами через Операторов, относятся документы, предназначенные для оформления факта хозяйственной деятельности.

Перечень документов, обмен которыми обязан поддерживать Оператор, приведён на официальном сайте Федерального органа исполнительной власти, уполномоченного по контролю и надзору в области налогов и сборов (далее - уполномоченный орган исполнительной власти).

Так же к ЦЭД относится Приглашение (ПР), описание которого приведено в разделе 6

4.2. Вспомогательные электронные документы (ВЭД).

К ВЭД, относятся:

1. Извещение о получении документа (ИОП)

2. Уведомление об уточнении документа (УОУ)

4.3 Технологические электронные документы (ТЭД).

К ТЭД относятся:

1. Логическое сообщение (ЛС)

2. Транспортный пакет (ТП)

3. Уведомление о принятии документа (УОП)

4. Технологическая квитанция (ТК)

5. Транспортная квитанция (ТрК).

Описание, форматов передаваемых данных ВЭД и ТЭД приведены в разделе 6

5. Регламент ЭДО

Взаимодействие сторон при обмене электронными документами может осуществляться на трех уровнях (см. рис.1):

1. Прикладном - уровень клиентов, бизнес-логики;

2. Технологическом - уровень взаимодействия Операторов, выполнения технических регламентов.

3. Транспортном - уровень взаимодействия программных средств с использованием конкретных сетевых протоколов.

Регламент обмена электронными документами

Рис.1

Взаимодействие: Оператор отправителя Документа - Оператор получателя Документа осуществляется на всех трех уровнях.

На прикладном уровне Отправитель формирует ЦЭД, отправляет его Получателю и ожидает от него подтверждения факта получения ЦЭД или отказа в получении. На этом уровне основными единицами передачи данных являются ЦЭД и ЭП.

На технологическом уровне взаимодействие хозяйствующих субъектов прикладного уровня формализуется: описывается порядок взаимодействия и форматы передачи данных между ними при помощи Операторов. На этом уровне, основной единицей передачи данных являются логическое сообщение и транспортный пакет (см. раздел 6).

На транспортном уровне идет взаимодействие Операторов, обеспечивающих взаимодействие, Хозяйствующий субъект - Оператор Отправителя, и межоператорское взаимодействие Оператор Отправителя - Оператор Получателя.

На участках взаимодействия "отправитель Документа - Оператор Отправителя" и "Оператор Получателя - получатель Документа" могут использоваться различные транспортные протоколы.

Настоящая Технология предусматривает описание технологического уровня взаимодействия Операторов. Также Технологией предусмотрено на участке межоператорского взаимодействия использование конкретного транспортного протокола - HTTPS.

5.1. Прикладной уровень

5.1.1. Регламент обмена электронными документами

Взаимодействие хозяйствующих субъектов и Операторов при обмене электронными документами определяется требованиями Методических рекомендаций и утвержденными нормативно-правовыми актами Порядками обмена между хозяйствующими субъектами отдельными электронными документами.

5.1.2. Обмен электронными документами специального назначения

Взаимодействие при обмене Приглашениями (ПР) определяется настоящим Регламентом:

1. Отправитель формирует ПР к началу ЭДО.

2. Оператор Отправителя фиксирует дату и время отправки ПР своими средствами и проверяет данные Получателя на ресурсе уполномоченного органа исполнительной власти, содержащем сведения о зарегистрированных участниках электронного документооборота.

3. Если результат проверки положительный, Оператор Отправителя передает ПР Оператору Получателя. В противном случае, Отправителю направляется сообщение об ошибке.

4. Оператор Получателя фиксирует дату и время получения ПР своими средствами и передает ПР Получателю.

5. Получив ПР с типом "Запрос", Получатель проверяет его, принимает решение либо о согласии с ПР, либо об отказе в приеме ПР.

6. В случае согласия с полученным ПР с типом "Запрос", Получатель формирует ответное ПР с типом "Запрос", и отправляет его Отправителю через своего Оператора.

Факт установки связи: с момента передачи ответного ПР с типом "Запрос" Оператор Получателя и Получатель считают связь между Отправителем и Получателем установленной.

7. В случае несогласия с полученным ПР, Получатель формирует ПР с типом "Разрыв", и отправляет Отправителю через своего Оператора.

Факт разрыва связи: с момента передачи хотя бы одной стороной ПР с типом "Разрыв" Оператор Получателя и Получатель считают связь между Отправителем и Получателем не установленной.

8. Оператор Получателя фиксирует дату и время отправки ПР своими средствами и передает ПР Оператору Отправителя.

9. Оператор Отправителя фиксирует дату и время получения ПР своими средствами и передает ПР Отправителю.

5.2. Технологический уровень

В данном разделе описывается порядок взаимодействия Операторов между собой в целях выполнения Прикладного регламента. Основными задачами на данном уровне являются обеспечение гарантированной доставки документов и подписей под ними и четкое разграничение зон ответственности Операторов друг перед другом.

Единицей передачи данных между Операторами на технологическом уровне является ЛС. Оно позволяет группировать передаваемые документы и подписи, сопровождая их необходимой для маршрутизации метаинформацией. Логические сообщения в свою очередь для более эффективной передачи группируются в транспортные пакеты (ТП), которыми Операторы уже обмениваются непосредственно, используя соответствующий транспортный протокол. Структура логического сообщения и транспортного пакета подробно описана в разделе 6.

Для решения поставленных задач требуется обязательная взаимная аутентификация Операторов, гарантия целостности передаваемых данных, гарантия конфиденциальности передаваемых документов, обязательная фиксация фактов передачи логических сообщений от одного Оператора другому, обязательная фиксация фактов передачи транспортных пакетов от одного Оператора другому и их ответственности за дальнейшие действия.

Взаимная аутентификация Операторов должна обеспечивать однозначное понимание всеми участниками документооборота, от имени кого происходит передача или прием транспортных пакетов.

Гарантия целостности данных в процессе передачи транспортных пакетов должна обеспечиваться путем их подписания электронной подписью Оператора Отправителя.

При передаче логического сообщения между операторами, шифрование может не использоваться. При передаче Приглашений шифрование также не используется.

Факт передачи логического сообщения или Приглашения от Оператора к Оператору фиксируется Технологическим электронным документом (ТЭД) - технологической квитанцией (ТК). Квитанции формируются отдельно для каждого логического сообщения или Приглашения, но при передаче могут объединяться в один транспортный пакет. Обработка ЛС должна обеспечивать атомарность передачи набора из нескольких документов. Так, при возникновении ошибки, связанной лишь с одним ЛС все остальные документы и ЭП из того же ЛС также не должны приниматься. И наоборот, если Оператор Отправителя получил квитанцию об ошибке обработки ЛС, он должен считать, что ни один документ и электронная подпись из этого ЛС не был доставлен до Получателя.

Факт передачи транспортного пакета от Оператора к Оператору фиксируется другим ТЭД - транспортной квитанцией (ТрК). Квитанции формируются отдельно для каждого транспортного пакета после проверки целостности и структуры ТП. При возникновении ошибки, связанной с одним ЛС, все ЛС находящиеся в ТП не должны приниматься. И наоборот, если Оператор Отправителя получил квитанцию об ошибке обработки ТП, он должен считать, что ни одно ЛС не было доставлено до Оператора Получателя.

Рис.2. Логическое сообщение и технологические квитанции

5.2.1. Регламент взаимодействия операторов

Регламент взаимодействия операторов (Оператор Отправителя - Оператор Получателя) на технологическом уровне выглядит следующим образом (см. рис.4):

1. Оператор Отправителя упаковывает требующие пересылки документы и подписи в логические сообщения, формирует транспортный пакет, подписывает его и отправляет Оператору Получателя.

2. Оператор Получателя фиксирует дату получения ТП, проверяет его корректность (ЭП, структуру и формат, согласно п. 5.3. Транспортный пакет (ТП)) и в синхронном режиме сообщает Оператору Отправителя, принят ли данный ТП в обработку.

Если ТП прошел проверку и принят в обработку, с этого момента Оператор Получателя формирует соответствующие транспортные квитанции ТрК, содержащие результат обработки ТП, и принимает на себя ответственность в установленный срок проверить корректность и обработать каждое ЛС внутри ТП и в асинхронном режиме проинформировать Оператора Отправителя о результатах.

3. Оператор Получателя с момента принятия в обработку не позднее 4 часов распаковывает ТП, обрабатывает каждое ЛС и ПР по отдельности и формирует соответствующие технологические квитанции, содержащие результаты их обработки в соответствии с Методическими рекомендациями.

4. Оператор Получателя упаковывает сформированные ТК в транспортный пакет, подписывает его и передает Оператору Отправителя.

5. Если полученное ЛС корректно сформировано, идентифицирован получатель и присутствует вся информация, необходимая для дальнейшей обработки (согласно п. 6.1 Логическое сообщение (ЛС)), Оператор Получателя формирует положительную ТК. Положительная ТК фиксирует факт передачи ЛС. С этого момента Оператор Получателя принимает на себя обязательства и ответственность за все дальнейшие действия с ЛС. На данном уровне Оператор не проверяет состав документов внутри ЛС.

6. Если результат проверки ЛС отрицательный, то Оператор Получателя формирует отрицательную ТК с указанием причины. В этом случае передача ЛС считается не состоявшейся.

7. Оператор Отправителя фиксирует дату получения транспортного пакета с ТК, проверят его корректность (ЭП, структуру и формат) и обрабатывает содержащиеся в нем технологические квитанции.

Регламент обмена электронными документами, Технологический уровень

Рис.3 Регламент взаимодействия операторов

5.3. Транспортный уровень

Задача транспортного уровня - обеспечение гарантированной и защищенной передачи транспортных пакетов между Операторами.

В качестве основного протокола передачи данных используется протокол HTTPS (1.1) c взаимной аутентификацией (RSA). Операторы должны обеспечить взаимное доверие сертификатам друг друга, используемым для аутентификации и установки защищенного соединения. В качестве клиентского сертификата для установки HTTPS-соединения необходимо использовать самоподписанный RSA-сертификат. Этот сертификат должен совпадать с сертификатом, используемым для подписания транспортных пакетов. Оператор аутентифицирует Оператора-отправителя либо основываясь на данных из сертификата подписи под ТП, либо на основе аутентификационных данных транспортного уровня (HTTPS), доступных в процессе его приема.

Таким образом, каждый Оператор должен обеспечить инфраструктуру, гарантирующую бесперебойный прием HTTPS-запросов от других Операторов.

ТП должны передаваться HTTP-методом POST с указанием следующих заголовков:

Content-Disposition: attachment; filename="<ИДТП>.cms"

В заголовке указывается имя (идентификатор) ТП

При прямом обмене (Оператор отправителя - оператор получателя):

Send-Receipt-To: <адрес (URI)>

В заголовке указывается адрес, куда следует направлять транспортный пакет с квитанциями об обработке ЛС. Является обязательным при прямом обмене.

В теле запроса передается транспортный пакет в DER-кодировке:

BODY:<ТП В DER-кодировке>

Регламент обмена электронными документами,
Транспортный уровень

Рис.5

Подходящие коды ошибок из заданных диапазонов следует выбирать согласно общепринятым определениям кодов ошибок в документе RFC 2616 (http://tools.ietf.org/html/rfc2616#section-10). В случае возврата кода ошибки в теле HTTP-ответа необходимо сообщить детальную информацию о произошедшей ошибке.

При получении POST-запроса, содержащего ТП, Оператор-получатель должен проверить корректность ТП (проверить корректность электронной подписи под ним, аутентифицировать отправителя, проверить корректность ZIP-файла и наличие в нем допустимых директорий и файлов), и синхронно вернуть в HTTP-ответе транспортную квитанцию и код, отражающий наличие ошибок:

- Код 200 и ТК с успешным ответом, если ТП принят в обработку. ТП считается переданными и ответственность за его дальнейшую обработку лежит на Операторе-получателе ТП. В этом случае Оператор-получатель обязуется вернуть Оператору-отправителю ТК об обработке всех ЛС из данного транспортного пакета на адрес, указанный в HTTP-заголовке Send-Receipt-To.

- Код из диапазона 4xx, если не была пройдена аутентификация, либо были обнаружены ошибки в ТП. При данных кодах ответа ТК не формируется.

- Код из диапазона 5xx, если логическое сообщение невозможно обработать из-за сбоев на сервере Оператора-получателя.

Транспортные квитанции должны передаваться в теле ответа в DER-кодировке с указанием следующих заголовков:

- Сontent-type: text/plain

После обработки POST-запроса, содержащего ТП, принимающая сторона должна идентифицировать Оператора Получателя ТП, с помощью заголовка X-Recipient-Operator.

6. Форматы передаваемых данных

Форматы ЦЭД, ВЭД и ТЭД, использующихся в данной Технологии для обмена Документами, не утвержденными приказами ФОИВ, должны соответствовать требованиям к форматам Документов, являющихся приложением к Технологии. Форматы Извещения о Получении (ИОП) и Уведомления об Уточнении (УОУ) при обмене любыми видами электронных документов должны соответствовать требованиям Приказа ФНС России от 30.01.2012 N ММВ-7-6/36@.

Кодировка в ИОП и УОУ Windows-1251, при этом программными средствами должна обеспечиваться возможность автоматического распознавания других кодировок (utf-8, koi-8).

Уведомление о принятии документа (УОП) представляет собой CMS-сообщение, содержащее отсоединенную подпись Получателя под этим документом.

6.1. Логическое сообщение (ЛС)

Логическое сообщение - это ТЭД, который служит для передачи ЦЭД и ТЭД между Операторами на технологическом уровне и содержит информацию о передаче комплекта документов и/или ЭП под Документами и представляет собой ZIP-архив, содержащий директорию со следующими Документами:

- description.xml - описание ЛС (должен присутствовать всегда);

- <ИдДокумента>.bin - содержимое Документа (может быть множественным или отсутствовать, см. п. 7.2.2);

- <ИдКЭП>.p7s - ЭП под Документом (может отсутствовать);

Имя директории с Документами является идентификатором ЛС

Размер ЛС не должен превышать 72 мегабайт, а размер любого файла не должен превышать 60 мегабайт. Исходный объем файла, zip-архив которого содержится в ЛС, не должен превышать 1024 мегабайт.

Файл описания description.xml должен содержать один узел Сообщение или Приглашение. Формат файла описания задается следующей XSD-схемой (см. Приложение N 1):

Пример файла description.xml. (см. Приложение N 2)

6.2. Приглашение (ПР)

Приглашение является специальным ЦЭД, который также описывается XSD-схемой (см. Приложение N 1). Файл описания description.xml в таком случае содержит узел Приглашение.

6.3. Технологическая квитанция (ТК)

Технологическая квитанция представляет собой ТЭД, которым фиксируется факт передачи ЛС или ПР от Оператора-отправителя к Оператору-получателю и результат его обработки. Для каждого ЛС или ПР формируется своя ТК, но при передаче нескольких квитанций они объединяются в один файл receipts.xml.

Файл receipts.xml должен содержать один узел Квитанции, формат которого определен в следующей XSD-схеме (см. Приложение № 1):

Пример файла receipts.xml (Приложение № 3)

6.4. Транспортный пакет (ТП)

Транспортный пакет - это ТЭД, который служит для объединения нескольких ЛС и ПР в один файл для более эффективной передачи данных. На уровне ТП обеспечивается контроль целостности передаваемых данных. Также ТП служит для передачи ТК.

ТП представляет собой CMS-сообщение, содержащее присоединенную ЭП, созданную Оператором-отправителем. ЭП под ТП обеспечивает контроль целостности и неотказуемости передаваемых между Операторами данных. Также она может использоваться для аутентификации Оператора-отправителя.

Формирование ЭП под ТП должно осуществляться при помощи того же сертификата ЭП, который используется для установки HTTPS-соединения между Операторами.

Подписываемое содержимое ТП представляет собой zip-файл, содержащий:

- либо список директорий - по одной для каждого входящего в ТП ЛС или ПР я (имя каждой такой директории является идентификатором соответствующего ЛС/ПР);

- либо один файл receipts.xml с перечислением всех ТК об обработке полученных ЛС/ПР.

Имя файла ТП должно служить глобальным, уникальным идентификатором этого пакета. Для исключения проблем на уровне транспорта, рекомендуется, чтобы имя файла удовлетворяло регулярному выражению [a-z0-9_]+{1,100}.

6.5. Транспортная квитанция (ТрК)

Транспортная квитанция - это ТЭД, которым фиксируется факт передачи ТП от Узла-отправителя к Узлу-получателю (Оператор) Для каждого ТП формируется своя ТрК.

ТрК представляет собой CMS-сообщение, содержащее присоединенную ЭП, созданную Оператором-получателем. ЭП под ТрК обеспечивает контроль целостности и неотказуемости передаваемых между Операторами Документов.

Формирование ЭП под ТрК должно осуществляться при помощи того же сертификата ЭП, который используется для установки HTTPS-соединения между Операторами.

Подписываемое содержимое ТрК представляет собой xml-файл, содержащий один файл transport_receipt.xml с указанием обработанного ТП.

ТрК передается синхронно, в теле ответа в DER-кодировке:

BODY:< ТрК В DER-кодировке>

с указанием следующих заголовков:

- Сontent-type: text/plain

Формат ТрК определен в следующей XSD-схеме (см. Приложение № 5):

6.6. Описание сети

Описание сети позволяет структурировать информацию обо всех участниках сети обмена Документами и о настроенной между ними промышленной эксплуатации ЭДО.

В описании сети, для каждого участника сети обмена содержится информация о:

- ИНН/КПП участника ЭДО,

- Идентификаторе участника ЭДО,

- Шлюзе участника ЭДО,

- Самоподписанном сертификате участника,

Также в описании сети хранится информация о всех промышленных связях между всеми участниками сети.

Формат описания сети определен в следующей XSD-схеме (см. Приложение № 4).

6.7. Криптография

Для шифрования используются алгоритмы ГОСТ 28147-89. Для формирования ЭП используются алгоритмы ГОСТ Р 34.10-2012.

Зашифрованные данные и ЭП передаются при помощи контейнера PKCS #7 (RFC 2315, http://www.ietf.org/rfc/rfc2315.txt). Для сохранения содержимого используется DER или BER-кодирование.

Зашифрованные данные передаются в виде структуры ContentInfo со структурой EnvelopedData в качестве содержимого.

ЭП передаются в виде структуры ContentInfo со структурой SignedData в качестве содержимого. ЭП должна включать относящийся к ней сертификат ЭП и не должна включать подписанный ею Документ.

Шифрование Документов, передаваемых в составе первичного транспортного контейнера, должно производиться в адрес открытых ключей сертификатов Получателя, указанных для шифрования, и открытых ключей сертификатов Отправителя. Шифрование Документов, передаваемых в результате приема или обработки поступившего Документа, производится в адрес открытых ключей сертификатов Получателя, указанных для шифрования, открытых ключей сертификатов Отправителя и открытых ключей сертификатов должностных лиц, подписавших поступивший Документ.

6.8. Версионность

Версии форматов ЛС, ПР и ТК определяются пространством имен, указанным у корневого узла XML-файла сообщения, или XML-файла с квитанциями.

Программное обеспечение, обрабатывающее ЛС, ПР и ТК должно проверять версию их формата перед обработкой и явно сообщать об ошибке, если формат пришедшего ЛС или ТК не прошёл.

В целях избежания ошибок при смене версий форматов, программное обеспечение Оператора должно обеспечивать возможность взаимодействия с различными Операторами с использованием всех действующих версий форматов.

7. Используемые технологии

http

В xml-описании ТП и xml-документах, участвующих в документообороте, дата и время указываются в формате UTC. Указание даты, времени, часового пояса обязательно.

В соответствии с документом RFC 2616 (http://tools.ietf.org/html/rfc2616).

CMS

В соответствии с документом RFC 5652 (http://tools.ietf.org/html/rfc5652).

ZIP

Формат zip-архива описывается в открытой спецификации, доступной по адресу http://www.pkware.com/documents/casestudies/APPNOTE.TXT. Архивирование содержимого больше 4 ГБ должно производиться в соответствии с базовыми возможностями версии 4.5 (ZIP64) без использования шифрования, размеры менее 4 ГБ могут архивироваться в соответствии с базовыми возможностями версии 2.0 без использования шифрования.

XML

В соответствии с документом "Extensible Markup Language (XML) 1.0 (Fifth Edition)" (http://www.w3.org/TR/2008/REC-xml-20081126/).

XMLSchema (XSD)

Язык описания структуры XML---документа должен соответствовать требованиям следующих документов:

- "XML Schema Part 0: Primer Second Edition"

(http://www.w3.org/TR/xmlschema-0).

- "XML Schema Part 1: Structures Second Edition"

(http://www.w3.org/TR/xmlschema-1).

- "XML Schema Part 2: Datatypes Second Edition"

(http://www.w3.org/TR/xmlschema-2).

UUID

Используемые универсальные уникальные идентификаторы должны генерироваться согласно общим принципам формирования UUID version 1, изложенным в документе RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt). Универсальные уникальные идентификаторы представляются в виде шестнадцатеричного числа из 32 разрядов, записанного в нижнем регистре. https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

DER-кодировка

DER-кодировка должна проводиться в соответствии с требованиями стандарта X.690

(https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf).

8. Рекомендации разработчикам

8.1. Порядок взаимодействия программных комплексов Операторов

Оператору отправителю следует придерживаться следующих правил реагирования на ответы Оператора получателя:

- При отсутствии синхронного ответа от получателя, отправитель должен повторить отправку проблемного ТП позже. При повторном возникновении проблемы следует уведомить Оператора получателя.

- При ответе с HTTP-кодом из диапазона 400, а также при получении ТК со статусом ОшибкаОбработки, необходимо установить причины возникновения ошибок, устранить их и повторить отправку тех же ЛС/ПР.

- При получении ТК со статусом НеизвестныйИд отправитель должен повторить отправку проблемных ЛС/ПР в следующем сеансе связи. При повторном возникновении данной ошибки на одних и тех же ЛС/ПР необходимо установить причины возникновения ошибки, устранить их и повторить отправку этих ЛС/ПР.

- При ответе с HTTP-кодом из диапазона 500 необходимо уведомить Оператора получателя о проблеме. После исправления неисправности повторить отправку тех же ЛС/ПР.

Оператор-получатель, при обработке входящих ЛС/ПР внутри одного ТП, должен обрабатывать их в порядке, исключающим отправку ТК со статусом НеизвестныйИд, а именно: в первую очередь обрабатывать ЛС/ПР, в которых нет ссылок на другие Документы из того же ТП, ссылаться на Документы из уже обработанных ЛС/ПР.

Программное обеспечение, обрабатывающее входящие ТП, не должно обрабатывать ЛС из ТП, если ранее ТП с таким именем файла уже послан. Однако, на такой входящий ТП необходимо сформировать ответ, как при первом получении данного ТП.

Для проработки конфликтных ситуаций программному обеспечению Оператора необходимо сохранять в журналах работы следующую информацию:

- для каждого отправленного и полученного ТП его идентификатор и список идентификаторов, содержащихся в нем ЛС/ПР, а также содержимое ТК, если она присутствовала в ТП;

- для каждого отправленного и полученного ТП HTTP статус-код его обработки;

- для каждого обработанного ЛС/ПР результат его обработки, а также идентификаторы содержащихся в нем Документов и ЭП.

В составе ЛС для получателя Документа возможно указать атрибут ИдПодразделенияПолучателя. Если Отправителю известен ID абонента, то он может заполнить это поле в ЛС. При разборе входящего ЛС, в случае если Получатель указал ID абонента, то Документ адресуется соответствующим образом. В случае не нахождения указанного подразделения, обработка аналогична со случаем отсутствия данного атрибута в ЛС.

8.2. Реализация прикладных регламентов документооборота

Реализация прикладных регламентов документооборота ЦЭД осуществляется в соответствии с требованиями Методических рекомендаций и утвержденными нормативно-правовыми актами Порядками обмена между хозяйствующими субъектами отдельными электронными документами.

См. приложения в редакторе Adobe Reader