ГОСТ Р ИСО 9735-4-2012 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 4. Сообщение синтаксического и служебного уведомления для пакетного ЭОД (тип сообщения - CONTRL)

ГОСТ Р ИСО 9735-4-2012

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ЭЛЕКТРОННЫЙ ОБМЕН ДАННЫМИ В УПРАВЛЕНИИ, ТОРГОВЛЕ И НА ТРАНСПОРТЕ (EDIFACT)

Синтаксические правила для прикладного уровня
(версия 4, редакция 1)

Часть 4

Сообщение синтаксического и служебного уведомления для пакетного ЭОД (тип сообщения - CONTRL)

Electronic data interchange for administration, commerce and transport (EDIFACT). Application level syntax rules (Syntax version number: 4, Syntax release number: 1). Part 4. Syntax and service report message for batch EDI (message type - CONTRL)

ОКС 35.240.60

Дата введения 2014-01-01*
____________________
* Поправка (ИУС 5-2015).

Предисловие

1 ПОДГОТОВЛЕН ЗАО "Проспект" совместно с Ассоциацией автоматической идентификации "ЮНИСКАН/ГС1 РУС" на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 55 "Терминология, элементы данных и документация в бизнес-процессах и электронной торговле"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 20 ноября 2012 г. N 974-ст

4 Настоящий стандарт идентичен международному стандарту ИСО 9735-4:2002* "Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 4. Сообщение синтаксического и служебного уведомления для пакетного ЭОД (тип сообщения - CONTRL)" (ISO 9735-4:2002 "Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4, Syntax release number: 1) - Part 4: Syntax and service report message for batch EDI (message type - CONTRL")).

________________

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru).

ВНЕСЕНА поправка*, опубликованная в ИУС N 5, 2015 год

_________________________

* См. ярлык "Примечания".

Поправка внесена изготовителем базы данных

Введение

Настоящий стандарт обеспечивает возможность автоматической подготовки сообщения, пересылаемого в ответ на полученные обмен, группу сегментов, сообщение или пакет, с тем чтобы:

- подтвердить правильную синтаксическую структуру или

- отклонить неверную синтаксическую структуру.

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

Кроме того, данное сообщение может использоваться для сигнализации только о факте приема обмена.

В основе данного сообщения лежит аналогичное служебное сообщение, разработанное и опубликованное Европейской экономической комиссией Организации Объединенных Наций (UN/ECE) для использования в более ранних версиях ИСО 9735.

Комплекс стандартов ИСО 9735 состоит из следующих частей под общим названием "Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1)":

- Часть 1. Синтаксические правила, общие для всех частей;

- Часть 2. Синтаксические правила, специфичные для пакетного ЭОД;

- Часть 3. Синтаксические правила, специфичные для интерактивного ЭОД;

- Часть 4. Сообщение синтаксического и служебного уведомления для пакетного ЭОД (тип сообщения - CONTRL);

- Часть 5. Правила защиты для пакетного ЭОД (аутентичность, целостность и неотказуемость источника);

- Часть 6. Сообщение для защищенной аутентификации и защищенного квитирования (тип сообщения - AUTACK);

- Часть 7. Правила защиты для пакетного ЭОД (конфиденциальность);

- Часть 8. Ассоциированные данные в ЭОД;

- Часть 9. Сообщение для управления ключами и сертификатами защиты (тип сообщения - KEYMAN);

- Часть 10. Справочники служебных синтаксических структур.

1 Область применения

Настоящий стандарт определяет сообщение синтаксического и служебного уведомления для пакетного ЭОД (тип сообщения - CONTRL).

2 Соответствие стандарту

Для соответствия настоящему стандарту в обязательном элементе данных 0002 (номер версии синтаксических правил) должен использоваться номер версии "4", а в условном элементе данных 0076 (номер редакции синтаксических правил) должен указываться номер редакции "01". Каждый из этих элементов данных входит в сегмент UNB (заголовок обмена). В обменах, в которых продолжает использоваться синтаксис более ранних версий, для различения соответствующих синтаксических правил необходимо указывать следующие номера версий:

ИСО 9735:1988 - Номер версии синтаксических правил: 1;

ИСО 9735:1988 (перепечатанный с изменениями в 1990 г.) - Номер версии синтаксических правил: 2;

ИСО 9735:1988 с Изменением 1:1992 - Номер версии синтаксических правил: 3;

ИСО 9735:1998 - Номер версии синтаксических правил: 4.

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

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

Устройства, поддерживающие настоящий стандарт, признаются соответствующими ему, если они способны формировать и/или интерпретировать данные, структурированные и представленные в соответствии с требованиями настоящего стандарта.

Соответствие требованиям настоящего стандарта означает соответствие требованиям ИСО 9735-1, ИСО 9735-2 и ИСО 9735-10.

Положения других стандартов, указанных в настоящем стандарте, являются составными элементами критериев соответствия настоящему стандарту.

3 Нормативные ссылки

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

ИСО 9735-1:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 1. Синтаксические правила, общие для всех частей (ISO 9735-1:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4, Syntax release number: 1) - Part 1: Syntax rules common to all parts)

ИСО 9735-2:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 2. Синтаксические правила, специфичные для пакетного ЭОД (ISO 9735-2:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4, Syntax release number: 1) - Part 2: Syntax rules specific to batch EDI)

ИСО 9735-5:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 5. Правила защиты для пакетного ЭОД (аутентичность, целостность и неотказуемость источника) (ISO 9735-5:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4, Syntax release number: 1) - Part 5: Security rules for batch EDI (authenticity, integrity and non-repudiation of origin))

ИСО 9735-6:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 6. Сообщение для защищенной аутентификации и защищенного квитирования (тип сообщения - AUTACK) (ISO 9735-6:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4, Syntax release number: 1) - Part 6: Secure authentication and acknowledgement message (message type - AUTACK))

ИСО 9735-7:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 7. Правила защиты для пакетного ЭОД (конфиденциальность) (ISO 9735-7:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4, Syntax release number: 1) - Part 7: Security rules for batch EDI (confidentiality))

ИСО 9735-8:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 8. Ассоциированные данные в ЭОД (ISO 9735-8:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4, Syntax release number: 1) - Part 8: Associated data in EDI)

ИСО 9735-9:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 9. Сообщение для управления ключами и сертификатами защиты (тип сообщения - KEYMAN) (ISO 9735-9:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4, Syntax release number: 1) - Part 9: Security key and certificate management message (message type - KEYMAN))

ИСО 9735-10:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 10. Справочники служебных синтаксических структур (ISO 9735-10:2002, Electronic data interchange for administration, commerce and transport (EDIFACT) - Application level syntax rules (Syntax version number: 4, Syntax release number: 1) - Part 10: Syntax service directories).

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

В настоящем стандарте применены термины и определения по ИСО 9735-1, а также следующие термины с соответствующими определениями, характерными для сообщений типа CONTRL.

4.1 подтверждение (acknowledgement): Действие, означающее, что получатель обмена с запросом проверки:

- получил контрольные уровни подтвержденного обмена с запросом проверки и

- убедился в отсутствии в подтвержденном контрольном уровне фатальных синтаксических ошибок, которые препятствовали бы его дальнейшей обработке, и

- убедился в том, что все подтвержденные служебные сегменты (или их части) семантически корректны (если уведомление не содержит ошибок), и

- согласился выполнить действия, запрошенные в подтвержденных служебных сегментах (их контрольных уровнях), и

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

- любые синтаксические или семантические ошибки, подобные описанным выше, будут позже обнаружены в соответствующей части, или

- данная часть не может быть обработана по какой-то другой причине уже после того, как она была подтверждена в представленном сообщении CONTRL,

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

4.2 индикация приема обмена (indication of interchange receipt): Действие, означающее, что получатель обмена с запросом проверки:

- получил обмен с запросом проверки и

- подтверждает проверенные части обмена с запросом проверки для обеспечения гарантии того, что элементы данных, скопированные в сегмент уведомления UCI, синтаксически корректны, и

- принял на себя обязанность по уведомлению отправителя о подтверждении либо отклонении других частей обмена с запросом проверки и

- принял надлежащие меры предосторожности, чтобы гарантировать уведомление отправителя об этом.

4.3 отклонение (rejection): Действие, означающее, что получатель обмена с запросом проверки:

- не может подтвердить обмен с запросом проверки или соответствующую его часть по причинам, указанным в сообщении CONTRL, и

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

4.4 уведомлять (to report): Сообщать о действии (подтверждении или отклонении), предпринятом в отношении обмена с запросом проверки или какой-то его части.

4.5 уведомительный уровень (reporting-level): Сегмент в сообщении CONTRL, в котором размещается уведомление для соответствующего контрольного уровня.

Примечание - Уведомительные уровни - это сегменты UCI, UCF, UCM, UCS и UCD.

4.6 контрольный уровень (referenced-level): Одна из следующих частей обмена с запросом проверки:

- сегменты UNA, UNB и UNZ, а также любые защитные сегменты, используемые для защиты обмена с запросом проверки, указанного в сегменте UCI;

- сегменты UNG и UNE, а также любые защитные сегменты, используемые для защиты группы, указанной в сегменте UCF;

- целое сообщение или целый пакет, а также любые защитные сегменты, используемые для защиты сообщения или пакета, указанного в сегменте UCM;

- сегмент, вложенный в тело сообщения, указанный в сегменте UCS;

- автономный, составной или компонентный элемент данных, указанный в сегменте UCD.

Примечание - Структура сообщения типа CONTRL базируется на пяти сегментах (UCI, UCF, UCM, UCS и UCD), которые содержат указатель на ту или иную часть обмена с запросом проверки.

4.7 обмен с запросом проверки (subject interchange): Обмен, в ответ на который возвращается сообщение CONTRL.

5 Правила использования сообщения синтаксического и служебного уведомления для пакетного ЭОД

5.1 Функциональное определение

CONTRL - это сообщение, которое подтверждает либо отклоняет обмен, группу, сообщение или пакет после их приема и синтаксического контроля с указанием обнаруженных ошибок.

Сообщение CONTRL должно использоваться для:

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

2) только индикации приема обмена.

5.2 Сфера применения

Данная спецификация сообщения CONTRL должна использоваться в рамках 4-й версии синтаксических правил EDIFACT (ИСО 9735) и только для ответа на обмены, сформированные в соответствии с требованиями частей 1, 2, 5, 6, 7, 8, 9 и/или 10 ИСО 9735.

5.3 Принципы

5.3.1 Общие положения

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

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

__________________

"Соглашение об обмене" соответствует английскому - "Interchange Agreement" ("IA").

Обмен в направлении от А к В называется обменом с запросом проверки.

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

Сообщение CONTRL обеспечивает:

- индикацию действия, предпринятого получателем по результатам синтаксического контроля обмена с запросом проверки, или, как вариант,

- только индикацию приема обмена.

В первом случае конкретное действие (подтверждение или отклонение) показывает результат синтаксического контроля полученного обмена. Это действие может относиться ко всему обмену в целом либо только к каким-то его частям. Например, некоторые сообщения, пакеты или группы могут быть подтверждены, а другие - отклонены. Сообщение CONTRL должно указывать конкретное действие применительно ко всем частям обмена с запросом проверки.

Во втором случае осуществляется только индикация приема обмена.

На этапе синтаксического контроля обмен или его часть должны проверяться на соответствие:

- синтаксическим правилам EDIFACT (ИСО 9735), включая правила использования служебных сегментов, и

- синтаксическим положениям спецификаций типов принимаемых сообщений.

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

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

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

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

Сообщение CONTRL никогда не должно пересылаться внутри группы.

5.3.2 Взаимосвязь между сообщениями CONTRL и обменом с запросом проверки

В ответ на полученный обмен может быть отправлено не более двух сообщений CONTRL. Первое (необязательное) обеспечивает индикацию приема обмена, второе уведомляет о действии, предпринятом по результатам синтаксического контроля обмена с запросом проверки. Код действия, присутствующий в сегменте UCI, должен указывать, к какому типу относится сообщение - к первому или ко второму.

Если запрос подтверждения присутствует в сегменте UNB обмена с запросом проверки, то для уведомления о результатах его синтаксического контроля в ответ должно быть послано сообщение CONTRL второго типа (за исключением случаев, когда обмен с запросом проверки содержит только сообщения CONTRL - одно либо несколько). Необязательность первого сообщения означает, что если посылается хоть какое-то сообщение типа CONTRL, с ним всегда должен пересылаться второй тип сообщения CONTRL (за исключением случаев, когда обмен с запросом проверки содержит только сообщения CONTRL - одно либо несколько). Сегмент UCI в сообщениях CONTRL первого типа не должен использоваться для уведомления о каких-либо ошибках, то есть при возникновении необходимости уведомления об ошибках с помощью сегмента UCI должно отправляться только сообщение CONTRL второго типа.

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

Группы сегментов 1 и 3 не должны использоваться в сообщении CONTRL, которое обеспечивает индикацию приема обмена. Если обмен с запросом проверки содержит группы (сообщений или пакетов), то в сообщении CONTRL должна использоваться лишь группа сегментов 3. Если группы не используются в обмене с запросом проверки, то в сообщении CONTRL должна использоваться лишь группа сегментов 1.

При возникновении необходимости в пересылке UCM-группы (это группа сегментов 1 или 4) в ответ на каждое полученное сообщение или на каждый полученный пакет должна пересылаться не более чем одна такая группа.

Все уведомительные уровни должны следовать в том же порядке, в каком располагаются соответствующие им контрольные уровни в обмене с запросом проверки.

5.3.3 Использование кодов действий

Контрольные уровни обмена с запросом проверки, который может быть подтвержден либо отклонен, это уровни, указанные в сегментах UCI, UCF и UCM.

Сообщение CONTRL предоставляет также возможность подтверждения или отклонения полного обмена или полной группы без использования вложенных в них сообщений, пакетов или групп.

Конкретное действие (подтверждение либо отклонение) должно указываться кодом действия в сегментах UCI, UCF и UCM. Этот код может индицировать действие, относящееся к соответствующему контрольному уровню, а в некоторых случаях и к его нижележащим уровням.

Контрольный уровень обмена с запросом проверки считается явно определенным в уведомлении, если в сообщении CONTRL содержится соответствующий сегмент, в котором имеется ссылка на этот уровень. Для явного уведомления в отношении нижерасположенного контрольного уровня требуется подтверждение всех вышерасположенных уровней.

Контрольный уровень считается неявно определенным в уведомлении, если относящееся к нему конкретное действие указано в сегменте UCI либо UCF, содержащем ссылку на вышерасположенный уровень обмена с запросом проверки. Так, например, группа и все вложенные в нее сообщения или пакеты неявным образом отклоняются, если код действия, содержащийся в сегменте UCI, указывает на отклонение полного обмена с запросом проверки. В то же время сообщение или пакет являются неявно подтвержденными, когда код действия в UCI или UCF индицирует подтверждение сообщений и пакетов на следующем нижерасположенном уровне, и отсутствует сегмент UCM, отклоняющий рассматриваемые сообщение или пакет.

Коды действий 4 и 7 должны использоваться в сообщениях CONTRL, уведомляющих о действии, предпринятом по завершении контроля обмена. Код действия 8 должен использоваться только в сообщениях CONTRL, которые обеспечивают индикацию приема обмена. Коды определяются в элементе 0083 "Действие, кодированное".

5.3.4 Регистрация синтаксических ошибок

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

Каждый уведомительный уровень (то есть сегменты UCI, UCF, UCM, UCS и UCD) может регистрировать только одну ошибку. При обнаружении большего числа ошибок на уровне, определенном одним из указанных сегментов, получатель обмена с запросом проверки может выбрать регистрируемую ошибку по своему усмотрению. При этом нельзя пересылать несколько сообщений CONTRL в целях уведомления сразу о нескольких ошибках, и для каждой реализации контрольного уровня допускается представление не более чем одного уведомительного уровня.

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

Рекомендуется идентифицировать ошибки с максимально возможной точностью. Если точный код ошибки определен, то нельзя использовать более общий (и потому неточный) код. Местоположение ошибки также должно определяться с максимальной доступной точностью путем использования по возможности самого нижнего уведомительного уровня.

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

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

5.3.5 Ошибки в элементах данных, копируемых из обмена с запросом проверки в сообщение CONTRL

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

5.3.6 Избыточное уведомление о действии

Когда в UCI присутствует код действия 7, это не говорит об ошибке, если произведена пересылка сегментов UCM или UCF, подтверждающих сообщение, пакет или группу. Аналогично избыточные сегменты UCM могут подтверждать сообщения или пакеты в группе, когда указанный выше код используется в сегменте UCF.

5.3.7 Повторная передача

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

5.3.8 Подтверждение или отклонение сообщений CONTRL

В ответ на полученные обмены, содержащие только сообщения CONTRL (одно или несколько), не должно отправляться сообщение CONTRL второго типа (подтверждение или отклонение). Уведомления об ошибках в полученных сообщениях CONTRL должны формироваться иными способами.

Если в обмене, требующем ответа, содержатся одно или более сообщений CONTRL, то ответные сообщения CONTRL для полученного обмена должны формироваться так, как если бы этот обмен вообще не содержал сообщений CONTRL.

Если же в рамках обмена сообщения CONTRL перемежаются с сообщениями других типов, то неявное подтверждение или отклонение, касающееся полученных частей этого обмена, на сообщения CONTRL не распространяется.

5.4 Определение сообщения

5.4.1 Распознавание сегментов данных

Содержание данного подраздела должно соответствовать таблице сегментов (см. таблицу 1), представленной в 5.4.3, где показаны требования к статусу сегментов (обязательные, условные) и к максимальному числу их повторов.

Соответствующая информация об элементах данных в сегментах приведена в ИСО 9735-10.

0010 UNH - заголовок сообщения

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

Для соответствия требованиям настоящего стандарта сообщения синтаксического и служебного уведомления должны содержать следующие данные в составном элементе данных S009 сегмента UNH:

0020 UCI - характеристика обмена

Сегмент, идентифицирующий обмен, для которого требуется ответ (обмен с запросом проверки). Данный сегмент также индицирует прием обмена и иные предпринятые действия - подтверждение или отклонение сегментов UNA, UNB, UNZ и указывает на любую ошибку, относящуюся к этим сегментам. Сегмент может также идентифицировать ошибки, относящиеся к защитным сегментам USA, USC, USD, USH, USR, UST или USU, когда они возникают на уровне обмена. В зависимости от кода действия сегмент UCI способен указывать еще и на предпринятое действие по отношению к группам, сообщениям и пакетам в рамках того же обмена.

Обмен с запросом проверки должен идентифицироваться путем копирования его элементов данных, указывающих на отправителя обмена (InterchangeSender), получателя обмена (InterchangeRecipient) и контрольный номер обмена (InterchangeControlReference), в идентичные элементы данных рассматриваемого сегмента UCI. Могут также идентифицироваться ошибочные или упущенные сегменты UNA, UNB, UNZ, USA, USC, USD, USH, USR, UST или USU. Если не обнаружен ни один из сегментов, то выявленная ошибка ассоциируется с обменом в целом.

0030 Группа сегментов 1: UCM-SG2

Группа сегментов, пересылаемая в ответ на сообщение или пакет обмена с запросом проверки, идентифицированного в сегменте UCI. Эта группа сегментов должна использоваться лишь в том случае, если обмен с запросом проверки не содержит групп.

0040 UCM - характеристика сообщения или пакета

Сегмент, идентифицирующий сообщение или пакет обмена с запросом проверки и индицирующий предпринятые по ним действия - подтверждение или отклонение. Он также идентифицирует любую ошибку, относящуюся к сегментам UNH, UNT, UNO и UNP, и может идентифицировать ошибки, относящиеся к защитным сегментам USA, USC, USD, USH, USR, UST или USU, когда они возникают на уровне сообщения или пакета.

Сообщение должно идентифицироваться путем копирования его элементов данных, содержащих идентификатор сообщения (Messageldentifier) и справочный номер сообщения (MessageReferenceNumber), в идентичные элементы данных рассматриваемого сегмента UCM. Могут также идентифицироваться ошибочные или упущенные сегменты UNH, UNT, USA, USC, USD, USH, USR, UST или USU. Если не обнаружен ни один из сегментов, то выявленная ошибка ассоциируется с сообщением в целом.

Пакет должен идентифицироваться путем копирования его элементов данных, содержащих базовый идентификатор (Referenceldentification) и справочный номер пакета (MessageReferenceNumber), в идентичные элементы данных рассматриваемого сегмента UCM. Могут также идентифицироваться ошибочные или упущенные сегменты UNO, UNP, USA, USC, USD, USH, USR, UST или USU. Если не обнаружен ни один из сегментов, то выявленная ошибка ассоциируется с пакетом в целом.

0050 Группа сегментов 2: UCS-UCD

Группа сегментов, пересылаемая в ответ на полученный сегмент, который содержит одну или несколько ошибок и представляет собой часть сообщения, идентифицированного сегментом UCM в Группе сегментов 1.

0060 UCS - указатель ошибки в сегменте

Сегмент, идентифицирующий сегмент сообщения, содержащий ошибку, и любую ошибку, относящуюся к сегменту в целом.

0070 UCD - указатель ошибки в элементе данных

Сегмент, идентифицирующий ошибочный автономный, составной или компонентный элемент данных в том сегменте, который идентифицируется сегментом UCS в Группе сегментов 2, и указывающий характер ошибки.

0080 Группа сегментов 3: UCF-SG4

Группа сегментов, пересылаемая в ответ на полученную группу обмена с запросом проверки, идентифицированного в сегменте UCI. Эта группа сегментов может использоваться лишь тогда, когда обмен с запросом проверки содержит группы.

0090 UCF - характеристика группы

Сегмент, идентифицирующий группу в обмене с запросом проверки. Данный сегмент также указывает на предпринятое действие - подтверждение или отклонение сегментов UNG и UNE и идентифицирует любую ошибку, относящуюся к этим сегментам. Он может также идентифицировать ошибки, относящиеся к защитным сегментам USA, USC, USD, USH, USR, UST или USU, когда они возникают на уровне группы. В зависимости от кода действия сегмент UCF способен указывать еще и на предпринятое действие по отношению к сообщениям и пакетам в рамках той же группы.

Эта группа должна идентифицироваться путем копирования ее элементов данных, содержащих идентификатор приложения отправителя (ApplicationSender'sldentification), идентификатор приложения получателя (ApplicationRecipient'sldentification) и справочный номер группы (GroupReferenceNumber), в идентичные элементы данных рассматриваемого сегмента UCF. Могут также идентифицироваться ошибочные или упущенные сегменты UNG, UNE, USA, USC, USD, USH, USR, UST или USU. Если не обнаружен ни один из сегментов, то выявленная ошибка ассоциируется с группой в целом.

0100 Группа сегментов 4: UCM-SG5

Группа сегментов, пересылаемая в ответ на сообщение или пакет в Группе сегментов 3.

0110 UCM - Характеристика сообщения/пакета

Сегмент, идентифицирующий сообщение или пакет обмена с запросом проверки и индицирующий предпринятые по ним действия - подтверждение или отклонение. Данный сегмент также идентифицирует любую ошибку, относящуюся к сегментам UNH, UNT, UNO и UNP, и может идентифицировать ошибки, относящиеся к защитным сегментам USA, USC, USD, USH, USR, UST или USU, когда они возникают на уровне сообщения или пакета.

Сообщение должно идентифицироваться путем копирования его элементов данных, содержащих идентификатор сообщения (Messageldentifier) и справочный номер сообщения (MessageReferenceNumber), в идентичные элементы данных рассматриваемого сегмента. Могут также идентифицироваться ошибочные или упущенные сегменты UNH, UNT, USA, USC, USD, USH, USR, UST или USU. Если не обнаружен ни один из сегментов, то выявленная ошибка ассоциируется с сообщением в целом.

Пакет должен идентифицироваться путем копирования элементов данных, содержащих базовый идентификатор (Referenceldentification) и справочный номер пакета (PackageReferenceNumber), в идентичные элементы данных рассматриваемого сегмента UCM. Могут также идентифицироваться ошибочные или упущенные сегменты UNO, UNP, USA, USC, USD, USH, USR, UST или USU. Если не обнаружен ни один из сегментов, то выявленная ошибка ассоциируется с пакетом в целом.

0120 Группа сегментов 5: UCS-UCD

Группа сегментов, пересылаемая в ответ на полученный сегмент, который содержит одну или несколько ошибок и представляет собой часть сообщения, идентифицированного сегментом UCM в Группе сегментов 4.

0130 UCS - указатель ошибки в сегменте

Сегмент, идентифицирующий сегмент сообщения, содержащий ошибку, и любую ошибку, относящуюся к сегменту в целом.

0140 UCD - указатель ошибки в элементе данных

Сегмент, идентифицирующий ошибочный автономный, составной или компонентный элемент данных в том сегменте, который идентифицируется сегментом UCS в Группе сегментов 5, и указывающий характер ошибки.

0150 UNT - окончание сообщения

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

5.4.2 Указатель сегментов данных (упорядочены по тегам в алфавитном порядке)

__________________

Имеется в виду латинский алфавит.

UCD - индикация ошибки в элементе данных;

UC

UCI - характеристика обмена;

UCM - характеристика сообщения/пакета;

UCS - индикация ошибки в сегменте;

UNH - заголовок сообщения;

UNT - окончание сообщения.

5.4.3 Структура сообщения

Таблица 1* - Таблица сегментов

________________

* Качество таблицы в электронном исполнении соответствует качеству таблицы, приведенной в оригинале. - .

Приложение ДА
(справочное)

Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации

Таблица ДА.1

__________________________________________________________________________

УДК 658.6/.9:002.006.354 ОКС 35.240.60

Ключевые слова: электронный обмен данными, синтаксические правила, EDIFACT

__________________________________________________________________________

Электронный текст документа
и сверен по:

, 2014

Редакция документа с учетом
изменений и дополнений подготовлена