Международная организация
Правила от 15 марта 1999 года

Окончательные правила разработки сообщений ЭДИФАКТ ООН для ЭОД. Представлены Группой РГЭ

Принято
Европейской экономической комиссией Организации Объединенных Наций
15 марта 1999 года

    --------------------------------
    <*> Настоящий документ воспроизводится в том виде, в котором он был получен секретариатом.


    Настоящий документ был представлен Рабочей группой по ЭДИФАКТ (РГЭ) для публикации. Он заменяет собой предыдущий документ TRADE/WP.4/R.840/Rev.4 и согласуется с версией 4 синтаксических правил ЭДИФАКТ ООН. В документе TRADE/CEFACT/1999/2 описываются стратегия и график внедрения.
    ПРЕДИСЛОВИЕ
    i) Справочная информация
    На пятьдесят пятой сессии Совещания экспертов (UN/ECE/TRADE/WP.4/GE.1) по элементам данных и автоматическому обмену данными (TRADE/CEFACT/GE.1/1997/1, 7 апреля 1997 года) Председатель ГЭ.1 подчеркнул необходимость включения в правила разработки сообщений требований по версии 4 синтаксических правил, включая правила для интерактивного ЭДИФАКТ ООН. С учетом этого было выдвинуто предложение о создании новой группы, которое было поддержано участниками совещания. В соответствии с полномочиями, предоставленными ей на пятьдесят пятой сессии Совещания экспертов, РГЭ одобрила круг ведения Группы ПРС по версии 4 синтаксических правил, который содержится в Приложении C к документу GE.1/ESG/97N0048 от 30 июня 1997 года (доклад о работе совещания Руководящей группы по ЭДИФАКТ ООН, состоявшегося 19 - 20 мая 1997 года). РГЭ уполномочила ГПРС по четвертой версии синтаксических правил на своем совещании, которое состоялось 22 августа 1997 года.
    Круг ведения этой новой Группы по правилам разработки сообщений (ПРЭ) включает в себя следующие основные задачи:
    1.Цель заключается в ведении и публикации правил разработки сообщений ЭДИФАКТ ООН в соответствии с процедурами ЭДИФАКТ ООН.
    2.Включение в правила разработки сообщений версии 4 синтаксических правил прикладного уровня ЭДИФАКТ (ИСО 9735) для пакетного и интерактивного ЭОД.
    3.Представление правил разработки сообщений ЭДИФАКТ ООН для утверждения СЕФАКТ к сентябрю 1998 года и выделение достаточного времени для их изучения регионами.
    4.Изучение мнений пользователей ЭДИФАКТ ООН по всем добавлениям или изменениям к правилам разработки сообщений на основе консультаций путем широкого распространения предложений Группы.
    5.Налаживание процесса обеспечения качества с целью подготовки качественного продукта в соответствии с принятыми методами контроля качества.
    6.Представление докладов о ходе работы на каждом совещании ОГД Руководящей Группе ОГД.
    7.Пересмотр правил разработки сообщений должен производиться с одобрения РГЭ.
    8.До представления правил разработки сообщения для окончательного утверждения Группа ПРС должна подготовить график и стратегию внедрения в консультации с сопредседателями ОГТО.
    Группа использовала в значительной степени те же самые процедуры, что и Группа, занимавшаяся подготовкой правил разработки сообщений по версии 3 синтаксических правил. В документе R.1083 определены организационная структура и рабочие процедуры для двух групп Группы ПРС: Редакционной группы (РГ) и Группы по обеспечению качества (ГОК). График выполнения текущей задачи содержится в круге ведения.
    ii) Философия разработки сообщений
    Для разработки набора согласованных правил, позволяющих проводить различие между случаями, требующими разработки сегмента, и случаями, требующими разработки составного элемента данных, предыдущая Группа ПРС в первую очередь проанализировала Справочник для пакетного ЭДИФАКТ ООН с целью определения подхода, использовавшегося для разработки структур существующих элементов и составных элементов данных. На основе результатов этого анализа Группа разработала набор согласованных правил, устанавливающих различие между случаями, требующими разработки сегмента, и случаями, требующими разработки составного элемента данных. Настоящий пересмотренный вариант опирается на философию, которая была разработана для пакетного обмена данными. Он также содержит правила разработки сообщений для интерактивного ЭОД, правила использования указателей зависимости и использования методов повтора. Разработчики сообщений ЭОД в течение длительного периода времени работали над решением проблемы интеграции данных, необходимых для электронной торговли, в контекст стандартного синтаксиса ЭОД с целью обеспечения "семантически полного" обмена. Интерактивный ЭОД усложняет данную проблему, поскольку сообщения представляют собой последовательность обменов, например, осуществляемых в ходе телефонного разговора, а не отдельные сообщения, не требующие ответа. Кроме того, интерактивный ЭОД вводит новые концепции и методы моделирования, которые ведут к созданию структур, в отношении которых, по сравнению с традиционными пакетными структурами, возникают проблемы дублирующей и перекрывающей функциональности. В действительности же философия разработки сообщений для пакетного и интерактивного ЭОД является практически одинаковой. Однако результирующие структуры могут характеризоваться несколько отличным форматом.
    В интерактивном ЭОД обычно используются методы моделирования, которые включают в себя проведение полного анализа коммерческого процесса и разработку моделей процесса и данных. Эти модели используются для разрешения семантических противоречий в описании коммерческого процесса и разработки недвусмысленных стандартных определений для каждого компонента синтаксических правил интерактивного ЭОД, например сценария, диалога, роли, сообщения, структуры сообщения, группировки информации и простых элементов данных. Поскольку это в большей степени является "искусством", чем "наукой", необходимо использовать сбалансированный подход, для того чтобы стремление обеспечить однозначное описание потребностей модели процесса не привело к появлению громадного числа стандартов. Модель процесса позволяет определить функцию сообщения или коммерческую функцию, а также набор коммерческих данных, носящих обязательный или факультативный характер в зависимости от потребностей коммерческого процесса. На этом уровне специфицированные для сообщений потребности в данных, как правило, касаются не уровня элемента данных, а определяются в виде коммерческой функции. Модель данных подробно описывает логические взаимосвязи между элементами данных в виде "объектов" (объектов, которые описывает информация), "атрибутов" (элементы данных, которые описывают объект), а также кардинальные взаимосвязи между "объектами". Именно на этом этапе перспективы структурного оформления сообщений для пакетного и интерактивного ЭОД начинают расходиться. Интерактивный ЭОД, "который опирается на разработку моделированных потребностей в данных, должен по-прежнему использовать "немоделированные" структуры для представления своих потребностей. При разработке интерактивных структур основное внимание уделяется представлению группировок данных, обмен которыми ведется в рамках коммерческого процесса. Эти группировки данных составляются из одного или более объектов модели данных, включаемых в сегменты для интерактивного ЭОД и называемых иногда "семантическими единицами". Таким образом, эти "семантические единицы" представляют собой набор элементов данных, необходимых для сообщения одной коммерческой функции.
    Таким образом, общая философия разработки стандартных элементов является точно такой же, что и в случае пакетного ЭОД, однако их представление отличается от более привычных построений пакетного ЭОД. Это в свою очередь позволяет говорить о проблеме дублирующей или перекрывающейся функциональности. Однако то, что в рамках пакетного ЭОД может служить источником дублирующей или перекрывающейся функциональности сегментов (из-за присутствия схожих структур более низкого уровня), полностью теряет свое значение в контексте интерактивного ЭОД. Интерактивный ЭОД должен обеспечивать передачу требуемого набора данных, который может состоять из комбинаций структур более низкого уровня, используемых в различных сегментах. Однако любая из этих структур будет уже по определению не похожа на другие в силу передаваемой ею коммерческой функции. Именно в этом заключается основная мысль, позволяющая в полной мере оценить различия, которые будут существовать во внешнем оформлении результирующих интерактивных стандартов.
    В документе TRADE/WP.4/R.1237 "Interactive Message Design Guidelines" ставится цель разработки "кратких, эффективных и простых" сообщений и вспомогательных структур данных. Эта цель вытекает из признания следующих коммерческих потребностей:
    В крупномасштабных интерактивных системах, характеризующихся большим объемом сделок и короткими сроками предоставления ответов, использование квалификаторов ведет к резкому увеличению затрат на обработку и связь. Разработка интерактивных сегментов и составных элементов данных должна вестись с учетом функционального определения на основе наиболее эффективного использования простых элементов данных и при минимальном использовании квалификаторов.
    Порядок размещения самостоятельных элементов данных и интерактивных составных элементов данных в рамках интерактивных сегментов имеет важное значение для эффективной обработки интерактивных сообщений.
    Косвенное и прямое определение (см. Приложение A) являются приемлемой методологией для удовлетворения потребностей, связанных с интерактивными коммерческими операциями.
    Пакетный обмен требует прямого определения в контексте приемлемых уровней обобщения в качестве средства разработки повторно используемых базовых структур. Интерактивный ЭОД позволяет использовать косвенное определение (например, определение с помощью функциональных определений сообщений или местоположения структуры в рамках сообщения) в качестве средства разработки повторно используемых структур и удовлетворения требований, касающихся краткости, эффективности и простоты сообщений. Обеспечение сбалансированности между использованием прямых и косвенных структур требует творческого подхода к разработке, а также соблюдения общей философии разработки.
    Поскольку настоящий пересмотренный вариант содержит правила, применимые одновременно как к пакетному, так и интерактивному ЭОД, эти правила были дополнены и сгруппированы по разделам. Эти правила согласуются с базовой философией, на основе которой был разработан четвертый пересмотренный вариант. Однако вследствие различий в правилах разработки сообщений для пакетного и интерактивного ЭОД основные принципы были сгруппированы по следующим разделам:
    a. Философия, применимая одновременно к разработке сообщений для пакетного и интерактивного ЭОД:
    1) Наиболее важным аспектом разработки сообщений является формулировка определений, описывающих значение данных, и составление наименований непосредственно на основе этих определений для обозначения данных.
    2) Сообщение представляет собой структуру для данных, передаваемых в рамках определенного информационного обмена между двумя сторонами.
    3) Сегменты и сегментные группы являются одними из базовых компонентов сообщений. Сегмент и / или сегментная группа представляет собой функционально взаимосвязанный набор элементов данных, чьи характеристики определяют одно отличное понятие (например, сторону, место, продукт, услугу, документ и т.д.). По прагматическим соображениям ЭДИФАКТ ООН рекомендует отдавать предпочтение разработке родовых, а не конкретных сегментов.
    4) Одной из целей определения сегмента является описание понятия, которое он представляет на определенном уровне обобщения. Уровень обобщения, как правило, зависит от информационной модели, которая используется в качестве основы для разработки сообщения ЭДИФАКТ ООН. В справочниках ЭДИФАКТ ООН существуют сегменты с высоким уровнем обобщения (например, ATT-атрибуты) и сегменты с низким уровнем обобщения (например, DOC-характеристики документа / сообщения). При выявлении возможного дублирования или перекрываемости функциональности сегмента с другим сегментом необходимо сопоставлять только сегменты, которые были разработаны на одном и том же уровне обобщения. Это правило не применимо, например, к сопоставлению документа DOC с сегментом ATT, поскольку последний характеризуется столь высоким уровнем обобщения, что может включать в себя все сегменты более низкого уровня.
    5) По прагматическим соображениям рекомендуется установить предел в отношении максимально допустимого уровня обобщения для сегментов. Поскольку терм класса объекта (см. Приложение B) представляет наиболее значимое понятие, он также может использоваться для определения уровня обобщения. Таким образом, используемый в качестве определяющего критерия максимально высокий уровень обобщения достигается в том случае, когда термом класса объекта является слово, которое тождественно одному из слов, взятому из перечня термов представления (например, quantity, rate, amount). Отметим, что сегмент ATT характеризуется более высоким уровнем обобщения по сравнению с этим максимальным пределом, однако эти принципы не будут применяться ретроактивно.
    6) В рамках ЭДИФАКТ ООН могут быть идентифицированы две подструктуры сообщения для представления одного отличного понятия. Первая подструктура представляет собой самостоятельный сегмент, который идентифицирует одно понятие, чьи характеристики полностью определяются элементами данных, специфицированными в справочнике ЭДИФАКТ ООН по этому сегменту. Вторая подструктура представляет собой сегментную группу, которая может идентифицировать одно понятие, чьи характеристики полностью определяются элементами данных, специфицированными в справочниках ЭДИФАКТ ООН по этим сегментам в рамках сегментной группы.
    7) В рамках ЭДИФАКТ ООН сегментная группа может также использоваться для определения зависимости между двумя сегментами или для определения иерархической взаимосвязи между сегментами. В этих случаях сегментная группа представляет широкое понятие, а сегмент (сегменты) в рамках сегментной группы и подчиненная сегментная группа (группы) представляют более узкие понятия. Каждое узкое понятие наследует все характеристики широкого понятия, а также как минимум одну дополнительную отличительную характеристику, которая обеспечивает дифференциацию более узких концепций на одном и том же уровне обобщения.
    8) Пусковой сегмент представляет собой первый сегмент в сегментной группе и позволяет определить функциональный контекст использования сегментной группы в ходе составления сообщения.
    9) Простой элемент данных идентифицирует одну единицу данных, чьи характеристики полностью определяются спецификацией элемента данных в справочниках ЭДИФАКТ ООН.
    10) Правило разработки, ограничивавшее спецификацию текстового элемента данных максимальной длиной в 17, 35 или 70 буквенно-цифровых знаков, было исключено. Это означает, что разработчики сообщений могут специфицировать такую максимальную длину элемента данных, которая представляется им целесообразной для него (например, 128 буквенно-цифровых символов). В то же время максимальная длина должна быть специфицирована по каждому элементу данных.
    11) Синтаксические правила (ISO9735/1) четко определяют порядок использования указателей зависимости. С учетом этого разработка новых правил использования указателей зависимости для сообщений, сегментных групп и сегментов непосредственно опиралась на них. Был проведен анализ использования указателей зависимости в отношении структур составных элементов данных. Результаты этого анализа позволили разработать правила, обеспечивающие формальную систему обозначений для выражения взаимосвязей.
    b. Философия, применимая только к разработке пакетных сообщений:
    1) Разработка родового сегмента позволяет использовать такие сегменты в различных областях применения за счет спецификации каждого конкретного случая использования в определяющем элементе данных. Данный определяющий элемент данных является следующим элементом данных после метки сегмента в сегменте и позволяет определять функциональный контекст использования сегмента в ходе составления сообщения.
    2) По соображениям непротиворечивости новые правила разработки сегментов требуют, чтобы все сегменты специфицировались с помощью определяющего элемента данных. Этот определяющий элемент данных может обладать обязательным или условным статусом, поскольку в рамках сегментной группы сегмент может определяться другим сегментом более высокого уровня, что устраняет необходимость дополнительного определения.
    3) Структура сегмента состоит из определяющего элемента данных и одного или более дополнительных элементов данных. Все элементы данных в рамках одного сегмента должны непосредственно относиться к понятию, представляемому сегментом. В случае, когда элемент данных представляет характеристику, которая только частично связана с понятием, этот элемент данных требует дополнительного отдельного сегмента.
    4) Данный процесс рационализации при правильном его использовании не позволит присвоить одну и ту же характеристику более одного раза одному понятию. Это означает, что в структуре сегмента один и тот же элемент данных не может быть специфицирован дважды.
    5) В соответствии с данной философией метод повторения может использоваться только в отношении определенных составных элементов данных или составных элементов данных, содержащих элементы данных 1131/3055. В первом случае определяющий элемент данных может использоваться для присвоения различных характеристик определенному составному элементу данных. Во втором случае различные значения элементов 1131/3055 позволяют по-разному ссылаться на присвоенные величины для описываемой характеристики.
    6) Элементы данных представляют собой первичную единицу информации. По прагматическим соображениям в ЭДИФАКТ ООН предусмотрено два способа выражения элемента данных для определения конкретных характеристик сегментов: в виде простого элемента данных и составного элемента данных.
    7) Составной элемент данных идентифицирует одну единицу данных, чьи характеристики не полностью специфицированы в справочниках ЭДИФАКТ ООН (т.е. перечни кодов, ведущиеся другими организациями) или / и чьи характеристики представления могут существовать в двух различных формах (например, в кодированной и / или некодированной) или чьи характеристики определяются совокупностью двух элементных данных (например, определяющим элементом данных и простым элементом данных).
    8) Содержащиеся в настоящем документе правила разработки элементов данных согласуются с философией разработки, предусматривающей наличие только двух структур элементов данных. С целью согласования текущей практики разработки с данной философией разработка структуры составного элемента данных ограничивается одним из восьми форматов, определенных в этих правилах.
    c. Философия, применимая только к разработке сообщений для интерактивного ЭОД
    Интерактивный ЭОД отличается от пакетного ЭОД рядом характеристик. Операция интерактивного ЭОД является одним из примеров конкретного сценария. Она состоит из одного или более диалогов, происходящих одновременно или последовательно между двумя или более сторонами. Диалог состоит из пары попеременных обменов ЭДИФАКТ: обмена отправителя и обмена респондента. Интерактивный ЭОД обладает следующими особенностями:
    - Формализованной взаимосвязью между двумя сторонами, использующими диалог.
    - Способностью динамически управлять ходом интерактивной операции ЭОД в зависимости от результатов предыдущих обменов в рамках диалога.
    - Коротким временем ответа.
    - Все сообщения, обмен которыми производится в рамках диалога, касаются одной и той же коммерческой операции.
    Вследствие этого философия разработки сообщений для интерактивного ЭОД опирается на следующие основные предпосылки:
    1) Операция представляет собой контролируемый набор диалогов, которые могут происходить между двумя или более сторонами.
    2) Интерактивная деловая операция описывается с помощью сценария. Сценарии описывают взаимосвязи и информационные обмены между двумя сторонами в интерактивной коммерческой операции.
    3) Сценарий описывает этапы осуществления операции.
    4) Целью разработки сообщений для интерактивного ЭОД является удовлетворение потребностей в интерактивном обмене данными при минимальной сложности и избыточности. Задача заключается в удовлетворении коммерческих потребностей, которые могут быть определены на основе родового подхода в рамках сценария.
    5) Интерактивные сообщения должны быть краткими, эффективными и простыми с точки зрения их функций и разработки.
    6) При разработке сообщений для интерактивного ЭОД должна ставиться цель создания родовых сообщений.
    7) Значение термина "родовой" в контексте интерактивного ЭОД, по всей видимости, должно согласовываться с коммерческой функцией операции интерактивного ЭОД. Так, например, сценарий, разработанный для интерактивного резервирования мест, должен предусматривать разработку таких сообщений, которые обеспечат удовлетворение коммерческих потребностей пользователей данного сценария. Следовательно, эти сообщения будут носить родовой характер для всех секторов, к которым применяется данный сценарий интерактивного ЭОД (например, для секторов железнодорожного, воздушного, паромного транспорта, проката автомобилей, гостиничного хозяйства, такси, туроператоров и т.д.).
    8) Правила разработки сообщений для интерактивного ЭОД должны позволять составление таких сообщений, которые бы обеспечивали гибкость, стандартизацию и эффективность, необходимые для удовлетворения коммерческих потребностей в интерактивном ЭОД.
    9) Порядок размещения самостоятельных элементов данных и интерактивных составных элементов данных в рамках интерактивных сегментов имеет важное значение для эффективной обработки интерактивных сообщений.
    10) Прямое и косвенное определение (см. Приложение A) является приемлемой методологией для удовлетворения потребностей, связанных с интерактивными коммерческими операциями.
    iii) Наименование и определение
    После тщательного анализа стандарта ИСО 11179, и в частности международного стандарта ИСО МЭК 11179-5 (Naming and identification principles for data elements), предыдущая Группа ПРС рекомендовала включить раздел 6 (и информационное Приложение A) в Правила разработки сообщений ЭДИФАКТ ООН. Данное добавление не затрагивает сущности настоящей рекомендации.
    Для облегчения полномасштабного применения этих принципов в среде ЭДИФАКТ ООН потребовалось внести следующие изменения:
    a) Охват принципов был с целью включения в него не только наименования простых элементов данных, но также и наименования составных элементов данных и сегментов.
    b) Правила использования терминов - квалификаторов в наименовании элементов данных были модифицированы с целью их согласования с использованием определяющих элементов данных в ЭДИФАКТ ООН.
    c) Существующий терм ЭДИФАКТ ООН "coded" в конце названия простого элемента данных был заменен термом представления "code" в соответствии с ИСО 11179-5.
    d) Было признано, что терм "ber" использовался непоследовательно во многих справочниках данных, что вело к двусмысленности. В некоторых случаях "ber" описывает арифметическую величину. В других случаях "номер" используется для ссылки на значение из схемы идентификации (например, страхового полиса), в качестве отличительной характеристики проведения различий между двумя. С целью дифференциации этих двух типов использования был введен терм представления "identificator", а определение "ber" было ограничено арифметической величиной.
    С учетом того, что коммерческие термины часто являются частью наименования значения кода, было сочтено, что правила наименования ИСО 11179-5 не подходят для структурирования наименований значений кодов.
    Во всех справочниках ЭДИФАКТ ООН вместо терминов "функция" сегмента, "описание" элемента данных, "описание" значения кода и т.д. рекомендуется использовать термин "определение". Данная рекомендация согласуется со стандартом ИСО 11179.
    iv) Методы предупреждения коллизий
    В версию 4 синтаксических правил был включен новый метод, позволяющий предупреждать коллизии между сегментами благодаря использованию сегментной группы UGH/UGT.
    Спецификация сообщения будет обеспечивать недвусмысленную идентификацию каждого сегмента сообщения по получении. Идентификация будет производиться на основе метки сегмента и местоположения сегмента в переданном сообщении. Идентификация не будет зависеть от статуса сегмента или максимального числа появлений.
    Сегментная группа UGH/UGT должна использоваться в спецификации сообщения в тех случаях, когда иным образом невозможно обеспечить недвусмысленную идентификацию каждого сегмента сообщения по получении на основании метки сегмента и местоположения сегмента в переданном сообщении.
    В этом случае сегментная группа UGH/UGT должна специфицироваться в начале и в конце сегментной группы, которая иным образом не может быть однозначно идентифицирована.
    v) Указатели зависимости
    Указатели зависимости являются новой концепцией, которая была включена в версию 4 синтаксических правил. В соответствующих случаях указатели зависимости могут использоваться в сообщении в спецификации сегмента и в составном элементе данных для выражения взаимосвязей. В указателе зависимости определяется перечень из двух или более компонентов (таким компонентом может являться сегментная группа, сегмент, составной элемент данных, самостоятельный элемент данных или компонентный элемент данных). Любой компонент может подчиняться нескольким указателям зависимости.
    vi) Методы повторения
    Спецификация множественных появлений сообщения в рамках группы или в рамках обмена; группы в рамках обмена и сегментной группы и / или сегмента в рамках сообщения, которая существовала в предыдущей версии стандарта ISO 9735, была расширена в версии 4 синтаксических правил. Была создана дополнительная возможность спецификации множественных появлений самостоятельного элемента данных и / или составного элемента данных в сегменте. Однако в пакетном ЭОД возможность использования повторяющихся элементов данных была ограничена в соответствии с философией их разработки.
    vii) Резюме
    Основные различия между настоящим пересмотренным вариантом и четвертым пересмотренным вариантом правил разработки сообщений заключаются в следующем:
    - включение правил разработки сообщений для интерактивного ЭОД,
    - новые правила в отношении методов предупреждения коллизий,
    - использование указателей зависимости, и
    - методы повторения.
    Группа проявила осторожный подход при разработке дополнительных правил с целью сохранения основополагающей философии, на которую опирался четвертый пересмотренный вариант, и, следовательно, правил, разработанных на основе данной философии.
    В результате настоящего пересмотра в новые синтаксические правила была включена концепция интерактивного ЭОД, расширен охват перечня символов, включены методы указателей зависимости и повторения элементов данных, усовершенствованы правила пакетного обмена, использования групп и сегментов заголовка сообщения и включены новые сегменты для предотвращения коллизий. Были разработаны новые правила для интерактивного ЭОД, а также правила использования указателей зависимости, повторяющихся элементов данных и методов предотвращения коллизий. Кроме того, была усовершенствована функциональность сегмента заголовка пакетного сообщения (UNH), что означает отмену предыдущего правила, касающегося обязательного использования сегмента начала сообщения (BGM). В новое правило было внесено соответствующее изменение. Что касается других вопросов, то проведенный анализ позволил сделать вывод об их неприменимости для разработки сообщений и, следовательно, отсутствии необходимости в разработке правил по ним.
    Группа также рассмотрела вопросы безопасности и компонентов, не относящихся к ЭДИФАКТ. Как и предыдущая Группа ПРС она приняла решение о том, что эти вопросы относятся к сфере внедрения, а не разработки сообщений.
    Принятие более четкого, согласованного и непротиворечивого набора принципов разработки сообщений будет содействовать повышению качества справочников данных и, следовательно, удовлетворению растущих потребностей пользователей ЭДИФАКТ ООН.
    ПРАВИЛА РАЗРАБОТКИ СООБЩЕНИЙ ЭДИФАКТ ООН ДЛЯ ЭОД
    1.ВВЕДЕНИЕ
    Группа по правилам разработки сообщений (ГПРС) ЭДИФАКТ ООН (Электронный обмен данными в управлении, торговле и на транспорте Организации Объединенных Наций) подготовила Правила разработки сообщений ЭДИФАКТ ООН для ЭОД. Они были подготовлены по поручению групп по разработке сообщений и групп по технической оценке, которые отвечают за разработку сообщений ЭДИФАКТ ООН. Эти правила подразумевают знание процесса и процедур ЭДИФАКТ ООН и синтаксических правил прикладного уровня ЭДИФАКТ (ИСО 9735). Конкретной областью применения правил разработки сообщений является разработка сообщений, вследствие чего из них целенаправленно исключены процедуры и другие спецификации, касающиеся других смежных областей, таких, как моделирование информации, разработка справочников и внедрение сообщений.
    В настоящем пересмотренном варианте сохранена структура пунктов, использовавшаяся в версии 4. Однако каждый из первоначальных пунктов был подвергнут дополнительной разбивке с целью включения правил, касающихся разработки сообщений одновременно для пакетного и интерактивного ЭОД. Последовательность пунктов соответствует иерархической структуре сообщения. В тех случаях, когда правило содержит термин, выделенный курсивом <*>, это означает, что определение этого термина приводится в Приложении A (Определения).

    -------------------------------
    <*> В тексте документа вместо курсива использовано выделение фигурными скобками.


    Нормативное Приложение B (Правила наименования элементов данных и сегментов) является неотъемлемой частью настоящего документа и содержит правила наименования элементов и сегментов данных. Данное Приложение содержит перечень термов представления, которые должны использоваться в связи с правилами наименования.
    Информационное Приложение C (Примеры наименования для справочника элементов данных) включено исключительно в справочных целях. Оно содержит перечень примеров простых элементов данных и иллюстрирует возможности применения правил наименования, описанных в Приложении D.
    Информационное Приложение D (Модель процесса разработки сообщения) включено с целью иллюстрации этапа процесса разработки и внедрения сообщения, на котором применяются правила разработки сообщения.
    2.ОХВАТ
    Настоящий документ определяет обязательный набор правил, которые должны использоваться для разработки и технической оценки сообщений и компонентов сообщений ЭДИФАКТ ООН. Данные правила призваны заложить согласованную и объективную основу для разработки сообщений, согласующуюся с версиями 1, 2, 3 и 4 синтаксических правил прикладного уровня ЭДИФАКТ ООН. Исключением служат лишь те правила, в которых в версии 4 вводится концепция указателей зависимости и повторяющихся элементов данных, которая должна применяться только к версии 4 синтаксических правил.
    3.СПРАВОЧНЫЕ МАТЕРИАЛЫ
    Нижеследующие стандарты содержат положения, которые в соответствии со ссылками, содержащимися в настоящем документе, являются положениями изложенных в нем правил.
  1.    ИСО 646     Обработка  информации.  Набор  семибитных кодированных 
               знаков ИСО для обмена информацией 
   ИСО 9735    Электронный обмен  данными в управлении, торговле и на 
               транспорте    (ЭДИФАКТ).    Синтаксические     правила 
               прикладного уровня (версии 1,  2,  3 и 4 (части 1, 2 и 
               3)) 
   ИСО 11179-5 Информационная     технология.      Спецификация     и 
               стандартизация элементов данных.  Часть 5  -  Принципы 
               наименования и идентификации элементов данных.
    2. 4.ПРАВИЛА РАЗРАБОТКИ СООБЩЕНИЙ
    В настоящей первоначальной версии пятого пересмотренного варианта в конце каждого правила указывается номер исходного правила (либо из документа R.840/Rev.4, либо из документа R.1237), например "[R.840 - Правило 13]".
    Если в правило было внесено изменение, например для включения положений, касающихся интерактивного ЭОД, то это указывается звездочкой, например правило "[R.840 - Правило 3*]".
    Если речь идет о полностью новом правиле, например касающемся указателей зависимости, то номер исходного правила не указывается.
    4.1 Общие правила
    4.1.1.Правила, касающиеся одновременно пакетного и интерактивного ЭОД
    Правило 1: Для разработки {сообщений}, {сегментов и элементов данных} не должны использоваться элементы справочника ЭДИФАКТ ООН, подлежащие исключению. [R.840 - Правило 1]
    Правило 2: Для разработки {сегментов и элементов данных} не должны использоваться {служебные элементы синтаксического справочника}. [R.840 - Правило 2]
    Правило 3: Для разработки {сообщений} не должны использоваться {служебные элементы синтаксического справочника}, за исключением {служебных сегментов заголовка сообщения} (UNH/UIH), разделителя зон (UNS), заголовка сегментной группы предупреждения коллизий (UGH), окончания сегментной группы предупреждения коллизий (UGT) и {окончания сообщения} (UNT/UIT). [R.840 - Правило 3*]
    Правило 4: Указатель зависимости должен специфицироваться с помощью допустимого {идентификатора} зависимости, содержащегося в нормативном Приложении E.
    4.2 Сообщения
    4.2.1.Правила, касающиеся одновременно пакетного и интерактивного ЭОД
    Правило 5: Коммерческая цель {сообщения}, специфицированная в {определении сообщения}, не должна дублироваться и представляться с коммерческой целью другого сообщения в {целевом справочнике ЭДИФАКТ ООН}. [R.840 - Правило 4*]
    Правило 6: {Сообщение} должно идентифицироваться с помощью кода {типа сообщения}, который состоит из шести прописных алфавитных знаков из набора знаков ИСО 646, и должно носить уникальный характер в справочниках пакетных и интерактивных сообщений ЭДИФАКТ ООН. [R.840 - Правило 5*]
    Правило 7: Наименование {сообщения} должно быть уникальным в рамках {целевого справочника ЭДИФАКТ ООН}. [R.840 - Правило 6*]
    Правило 8: Наименование {сообщения} должно согласовываться с {определением сообщения}. [R.840 - Правило 7]
    Правило 9: {Сообщение} должно начинаться со {служебного сегмента заголовка сообщения} (UNH/UIH) и заканчиваться {служебным сегментом} окончания сообщения (UNT/UIT). [R.840 - Правило 8*]
    Правило 10: {Сообщение} должно быть структурировано таким образом, чтобы не допускать {коллизии сегментов}. [R.840 - Правило 10]
    Правило 11: {Сегментная группа} UGH/UGT должна использоваться в {спецификации сообщения} для предупреждения {коллизий сегментов}, которых иным образом невозможно избежать. В этом случае в начале и в конце {сегментной группы}, которая не может быть однозначно идентифицирована, должна специфицироваться {сегментная группа} UGH/UGT.
    Правило 12: Во всех случаях использования {сегментная группа} UGH/UGT должна обладать {максимальным числом появлений в размере единицы и должна специфицироваться с помощью условного} или {обязательного} статуса, идентичного {статусу сегментной группы}, которую она определяет.
    Правило 13: В {сегментной группе} UGH/UGT {сегмент} UGH должен являться {пусковым сегментом}. UGT должен являться последним {сегментом} в {сегментной группе, быть обязательным} и специфицироваться {максимальным числом появлений} в размере единицы.
    Правило 14: Цель каждого {сегмента} и каждой {сегментной группы} в рамках {сообщения} должна специфицироваться в {зоне пояснения сегмента данных}. [R.840 - Правило 12]
    Правило 15: Спецификации использования каждого {сегмента} в {зоне пояснений сегмента данных} должна согласовываться с {определением сегмента в справочниках сегментов} ЭДИФАКТ ООН. [R.840 - Правило 13]
    Правило 16: Спецификация использования каждого {сегмента} и каждой {сегментной группы} в {зоне пояснения сегмента данных} должна согласовываться со {статусом} и {максимальным числом появлений}, определенными в {табличной форме представления сегмента}. [R.840 - Правило 14]
    Правило 17: Структура {табличного представления сегмента} должна согласовываться с {определением сегмента} и {зоной пояснения сегмента данных}. [R.840 - Правило 15*]
    Правило 18: {Сегмент} или {сегментная группа}, специфицированные в {табличной форме представления сегмента}, должны обладать либо {обязательным}, либо {условным статусом}. [R.840 - Правило 16]
    Правило 19: {Сегменту} или {сегментной группе}, специфицированным в {табличной форме представления сегмента}, должно быть присвоено {максимальное число} появлений. [R.840 - Правило 17]
    Правило 20: {Указатель зависимости} не должен специфицироваться в отношении {сегментов} или {сегментных групп}, имеющих {обязательный статус}.
    Правило 21: {Указатели зависимости}, специфицированные в отношении одного и того же {сегмента} или {сегментной группы}, не должны вступать между собой в конфликт.
    Правило 22: В {указателе зависимости} должны перечисляться {идентификаторы местоположения} по меньшей мере двух отличных {сегментных групп} или {одной сегментной группы} и {одного сегмента}, или {двух сегментов}.
    Правило 23: В перечне {указателя зависимости} должны специфицироваться только {идентификаторы местоположения сегментов} и / или {сегментных групп} одного и того же иерархического уровня и в рамках одной и той же родительской структуры ({сообщения} или {сегментной группы}).
    4.2.2.Правила, применимые к пакетному ЭОД
    Правило 24: {Сообщение} должно специфицироваться с помощью по меньшей мере одного {сегмента}, расположенного между {служебным сегментом} заголовка сообщения (UNH) и {служебным сегментом} окончания сообщения (UNT), которые не являются {сегментом} начала сообщения (BGM) или {служебным сегментом} разделения зон (UNS), соответственно. [R.840 - Правило 9]
    Правило 25: {Сегмент} начала сообщения (BGM) должен являться первым {сегментом}, который не является {служебным сегментом}. Он должен являться {самостоятельным сегментом} с {обязательным статусом} и {максимальным числом} появлений в размере единицы. [R.840 - Правило 11]
    4.2.3.Правила, применимые к интерактивному ЭОД
    Правило 26: {Сообщение} должно специфицироваться с помощью по меньшей мере одного {сегмента}, расположенного между {служебным сегментом} заголовка сообщения (UIH) и {служебным сегментом} окончания сообщения (UIT), который не является {служебным сегментом} разделения зон (UNS). [R.1237 - Правило 50*]
    4.3 Разбитые на зоны сообщения
    4.3.1.Правила, касающиеся одновременно пакетного и интерактивного ЭОД
    Правило 27: {Служебный сегмент} разделения зон (UNS) должен специфицироваться только для предупреждения {коллизий сегментов} между {сегментами}, расположенными в одной зоне сообщения, и {сегментами}, расположенными в следующей зоне {сообщения}. Он должен специфицироваться для разделения этих зон {разбитого} на зоны сообщения и обладать максимальным числом появлений в размере единицы, {обязательным статусом} и использоваться в качестве {самостоятельного сегмента} в начале подробной зоны и / или зоны резюме. [R.840 - Правило 18]
    Правило 28: Зоны {разбитого на зоны сообщения} должны идентифицироваться одновременно в {зоне пояснения сегмента данных} и в {табличной форме представления сегмента}, а также содержать один из следующих наборов:
    - зону заголовка и подробную зону;
    - зону заголовка, подробную зону и зону резюме;
    - подробную зону и зону резюме;
    - [R.840 - Правило 19]
    4.4 Сегментные группы
    4.4.1.Правила, касающиеся одновременно пакетного и интерактивного ЭОД
    Правило 29: {Сегментная группа} должна начинаться с {пускового сегмента}. [R.840 - Правило 20]
    Правило 30: {Пусковой сегмент} должен обладать {обязательным статусом}. [R.840 - Правило 21]
    Правило 31: {Пусковой сегмент} должен обладать {максимальным числом} появлений {в размере} единицы [R.840 - Правило 22]
    Правило 32: {Сегментная группа} должна содержать по меньшей мере еще один - другой {сегмент} или {сегментную группу} в дополнение к {пусковому сегменту}. [R.840 - Правило 23]
    4.5 Сегменты
    4.5.1.Правила, касающиеся одновременно пакетного и интерактивного ЭОД
    Правило 33: {Сегмент} должен идентифицироваться с помощью {метки сегмента}, которая должна состоять из трех прописных алфавитных знаков из набора знаков ИСО 646. {Сегмент пользователя} не должен начинаться с буквы "U". [R.840 - Правило 24]
    Правило 34: {Метка сегмента} должна носить уникальный характер в {справочниках сегментов} ЭДИФАКТ ООН для пакетного и интерактивного ЭОД [R.840 - Правило 25*]
    Правило 35: {Определение сегмента} должно:
    - описывать цель {сегмента},
    - согласовываться с {определениями его элементов данных},
    - не содержать {определений его элементов данных},
    - носить уникальный характер в рамках {целевого справочника сегментов ЭДИФАКТ ООН},
    - давать полное название акронимов в первом случае их появления,
    - не содержать аббревиатур,
    - не содержать грамматических родовых различий,
    - не содержать фраз "не требующий пояснений", "предстоит определить", "будет представлен" или их синонимов, если только данная фраза не является неотъемлемой частью {определения сегмента}.
    - [R.840 - Правило 26*]
    Правило 36: Наименование {сегмента} должно носить уникальный характер в {целевом справочнике сегментов ЭДИФАКТ ООН}. [R.840 - Правило 27*]
    Правило 37: Название сегмента должно согласовываться с {определением сегмента}. [R.840 - Правило 28]
    Правило 38: Цель {сегмента} не должна дублироваться и не должна представляться целью другого {сегмента} в рамках {целевого справочника ЭДИФАКТ ООН} на одном и том же уровне обобщения. [R.840 - Правило 29]
    Правило 39: {Элемент (элементы) данных} в рамках {сегмента} должен быть непосредственно связан с целью {сегмента}. [R.840 - Правило 33]
    Правило 40: {Элемент (элементы) данных} в рамках {сегмента} должен идентифицироваться с помощью {обязательного или условного статуса}. [R.840 - Правило 34]
    Правило 41: В отношении всех {элементов данных}, следующих за {определяющим} элементом данных в {сегменте}, в первую очередь должны специфицироваться {обязательные элементы данных}, а затем - {условные элементы данных}. [R.840 - Правило 37]
    Правило 42: Дополнительно включаемый в существующий {сегмент элемент данных} должен иметь {статус условного} и идентифицироваться в конце {сегмента}. [R.840 - Правило 38]
    Правило 43: {Самостоятельный элемент данных} должен заменяться в структуре {сегмента} только {составным элементом данных}, если:
    - в структуре {составного элемента данных} специфицирован {самостоятельный элемент данных} со своим исходным {статусом} или {условным статусом} в качестве первого {компонентного элемента данных},
    - {статус составного элемента данных} эквивалентен {статусу} первого {компонентного элемента данных},
    - другие {компонентные элементы данных} имеют {условный статус}.
    - [R.840 - Правило 39*]
    Правило 44: В случае исключения {элемента} данных из существующего {сегмента}, соответствующий {сегмент} подлежит исключению из {целевого справочника сегментов ЭДИФАКТ ООН}. [R.840 - Правило 40*]
    Правило 45: В случае изменения {статуса элемента данных с условного} на {обязательный} в существующем {сегменте} соответствующий {сегмент} подлежит исключению из {целевого справочника сегментов ЭДИФАКТ ООН}. [R.840 - Правило 41*]
    Правило 46: {Элемент данных в рамках сегмента} должен специфицироваться с помощью {максимального числа появлений}. [R.1237 - Правило 37*]
    Правило 47: Указатель зависимости не должен специфицироваться в отношении {элементов данных}, имеющих {обязательный статус}.
    Правило 48: {Указатели зависимости}, специфицированные в отношении одного и того же {элемента данных}, не должны вступать между собой в конфликт.
    Правило 49: В указателе зависимости должны перечисляться {идентификаторы местоположения} по меньшей мере двух отличных {элементов данных}.
    Правило 50: В {указателе зависимости} должны перечисляться только {идентификаторы местоположения}, содержащиеся в {сегменте}, к которому применяются {указатели зависимости}.
    Правило 51: {Указатель зависимости} должен использоваться только для выражения взаимосвязей в рамках {сегмента между}:
    - {самостоятельными элементами данных}, или
    - {составными элементами данных}, или
    - {самостоятельными элементами данных} и {составными элементами данных}.
    4.5.2.Правила, применимые к пакетному ЭОД
    Правило 52: {Сегмент} не должен повторять полностью содержание другого {сегмента}. [R.840 - Правило 30]
    Правило 53: {Сегмент} должен специфицироваться с помощью {определяющего} элемента данных, который является первым {элементом данных} после {метки сегмента} в составе {сегмента}. [R.840 - Правило 31]
    Правило 54: {Сегмент} должен специфицироваться с помощью по меньшей мере еще одного {элемента данных} в дополнение к {определяющему элементу данных}, который определяет сегмент. [R.840 - Правило 32]
    Правило 55: Один и тот же {элемент данных} может иметь только одно местоположение в рамках {сегмента}. [R.840 - Правило 35*]
    Правило 56: Только {определенные составные элементы данных} или составные элементы данных, содержащие {элементы данных} 1131/3055, могут являться {повторяющимися элементами данных}. [R.840 - Правило 35*]
    Правило 57: Определенный {составной элемент данных} должен специфицироваться с помощью {максимального числа появлений}, меньшего или равного числу величин кодов, специфицированных для {определяющего} элемента данных {составного элемента данных}. [R.840 - Правило 36*]
    4.5.3.Правила, применимые к интерактивному ЭОД
    Правило 58: {Сегмент} не должен содержать полный набор {элементов данных} другого {сегмента} из {справочника сегментов для интерактивного ЭОД}. [R.1237 - Правило 30*]
    Правило 59: {Сегмент} должен быть специфицирован с помощью по меньшей мере одного {элемента данных}, не являющегося {определяющим элементом данных}.
    Правило 60: В тех случаях, когда сегмент является определенным сегментом, в первую очередь должны указываться {обязательные элементы данных}, а после них - {условные элементы данных}. [R.1237 - Правило 36*]
    Правило 61: В {сегменте}, который требует определения, {определяющий элемент данных} должен являться первым {элементом данных} в {сегменте}.
    Правило 62: Квалификатор сегмента не должен являться {повторяющимся элементом данных}.
    4.6 Составные элементы данных
    4.6.1.Правила, касающиеся одновременно пакетного и интерактивного ЭОД
    Правило 63: {Определение составного элемента данных} должно:
    - описывать значение {составного элемента данных},
    - определять, что представляет собой {составной элемент данных}, а не только, что он собой не представляет,
    - согласовываться с {определениями его элементов данных},
    - не содержать определений его {элементов данных},
    - носить уникальный характер в рамках {целевого справочника составных элементов данных} ЭДИФАКТ ООН,
    - излагаться в единственном числе,
    - давать полное название акронимов в первом случае их появления,
    - не содержать аббревиатур,
    - не содержать грамматических родовых различий,
    - не содержать фраз "не требующий пояснения", "предстоит определить", "будет представлен" или их синонимов, если только данная фраза не является неотъемлемой частью определения составного элемента данных.
    - [R.840 - Правило 43*]
    Правило 64: Наименование {составного элемента данных} должно носить уникальный характер в {целевом справочнике составных элементов данных ЭДИФАКТ ООН}. [R.840 - Правило 44*]
    Правило 65: Наименование {составного элемента данных} должно согласовываться с его определением. [R.840 - Правило 45]
    Правило 66: Наименование {элементов данных} в паре {простых элементов данных} должны иметь идентичный терм класса объекта и свойства. Кодированный {простой элемент данных} должен обладать {термом представления} "код" или {термом представления} "идентификатор". Некодированный {простой элемент данных} должен иметь {терм представления} "описание" или {терм представления} "наименование". [R.840 - Правило 48*]
    Правило 67: {Определения элементов данных} в паре {простых элементов данных} должны быть идентичны, за исключением вводной фразы. Определение кодированного {простого элемента данных} должно начинаться со слов "код, специфицирующий...". Определение некодированного {простого элемента данных}, если он обладает {термом представления} "описание", должно начинаться со слов "свободное по форме описание...", а если он обладает {термом представления} "наименование", оно должно начинаться со слова "наименование...". [R.840 - Правило 49]
    Правило 68: {Компонентный элемент данных} должен специфицироваться с помощью либо {обязательного}, либо {условного статуса}. [R.840 - Правило 50]
    Правило 69: {Компонентный элемент данных} не должен являться {повторяющимся элементом данных}.
    Правило 70: В случае изменения {статуса с условного} на {обязательный компонентного элемента данных} в существующем {составном элементе данных} соответствующий {составной элемент данных} подлежит исключению из {целевого справочника составных элементов данных ЭДИФАКТ ООН}.
    Правило 71: {Статус} кодированного {простого элемента данных}
    должен быть обязательным в структуре {составного элемента данных}, который состоит только из {кодированного простого элемента данных}, за которым следуют {простые элементы данных} 1131 и 3055 (т.е. в соответствии со структурой 2 Правила 81).
    Правило 72: Дополнительно включаемый в существующий {составной элемент данных простой элемент данных} должен обладать {условным статусом} и специфицироваться в конце {составного элемента данных}. [R.1237 - Правило 26*]
    Правило 73: В случае исключения {компонентного элемента данных} из существующего {составного элемента данных} соответствующий {составной элемент данных} подлежит исключению из {целевого справочника составных элементов данных ЭДИФАКТ ООН}.
    Правило 74: {Указатель зависимости} должен специфицироваться только в отношении {компонентных элементов данных с условным статусом}.
    Правило 75: {Указатели зависимости}, специфицированные в отношении одного и того же {компонентного элемента данных}, не должны вступать между собой в конфликт.
    Правило 76: В {указателе зависимости} должны перечисляться {идентификаторы местоположения} по меньшей мере двух отличных {компонентных элементов данных}.
    Правило 77: В {указателе зависимости} должны перечисляться только {идентификаторы местоположения}, содержащиеся в {составном элементе данных}, к которому применяется {указатель зависимости}.
    4.6.2.Правила, применимые к пакетному ЭОД
    Правило 78: {Составной элемент данных} должен специфицироваться в том случае, когда необходимо:
    - сослаться на {внешний перечень кодов} (использование простых элементов данных 1131 и 3055),
    - объединить {простые элементы данных} в {пару простых элементов данных},
    - дополнительно определить {простой элемент данных} (определение тех характеристик, которые не описываются {квалификатором элемента данных}, который определяет сегмент),
    - определить {пару простых элементов данных}.
    - [R.840 - Правило 42]
    Правило 79: Наименование {составного элемента данных} должно обладать теми же {термами класса объекта} и {свойства}, что и кодированные или некодированные {простые элементы данных}, специфицированные в структуре {составного элемента данных}, за исключением {простых элементов данных} 1131 и 3055. [R.840 - Правило 46]
    Правило 80: {Определяющий элемент данных} в рамках {составного элемента данных} должен иметь обязательный статус. [R.840 - Правило 51]
    Правило 81: {Составной элемент данных} должен обладать одной из следующих структур:
  2.        {Структура 1:} 
   Кодированный элемент данных                       См. Примечание 1 
   Некодированный элемент данных                     См. Примечание 1 
       {Структура 2:} 
   Кодированный элемент данных 
   1131 
   3055 
       {Структура 3:} 
   Кодированный элемент данных                       См. Примечание 1 
   1131 
   3055 
   Некодированный элемент данных                     См. Примечание 1 
       {Структура 4:} 
   Определяющий элемент данных 
   Кодированный элемент данных 
       {Структура 5:} 
   Определяющий элемент данных 
   Некодированный элемент данных 
       {Структура 6:} 
   Определяющий элемент данных 
   Кодированный элемент данных                       См. Примечание 1 
   Некодированный элемент данных                     См. Примечание 1 
       {Структура 7:} 
   Определяющий элемент данных 
   Кодированный элемент данных 
   1131 
   3055 
       {Структура 8:} 
   Определяющий элемент данных 
   Кодированный элемент данных                       См. Примечание 1 
   1131 
   3055 
   Некодированный элемент данных                     См. Примечание 1
    3. Примечание 1. Элемент данных является частью {пары простых элементов данных}. [R.840 - Правило 47]
    4.6.3.Правила, применимые к интерактивному ЭОД
    Правило 82: {Составной элемент данных} должен специфицироваться в тех случаях, когда необходимо:
    - сослаться на внешний перечень кодов (использование {простых элементов данных} 1131 & 3055),
    - объединить {простые элементы данных} в {пару простых элементов данных},
    - дополнительно определить {простой элемент данных} (определение тех характеристик, которые не описываются {квалификатором элемента данных}, который определяет {сегмент}),
    - определить {пару простых элементов данных},
    - сгруппировать данные, {представляющие одну коммерческую цель}.
    Правило 83: Наименование {составного элемента данных} должно согласовываться с {определением этого составного элемента данных}.
    Правило 84: {Составной элемент данных} не должен содержать только полного набора {компонентных элементов данных} другого {составного элемента данных} из {справочника составных элементов данных} для интерактивного ЭОД. [R.123 - Правило 17*]
    Правило 85: В {составном элементе данных}, требующем определения, {определяющий элемент данных} должен специфицироваться в качестве первого {компонентного элемента данных} в {составном элементе данных}. [R.1237 - Правило 24*]
    Правило 86: В определенном {составном элементе данных} обязательные {простые элементы данных} должны указываться сразу же после {составного определяющего элемента данных}. В неопределенном {составном элементе данных} в первую очередь должны указываться обязательные {простые элементы данных}. [R.1237 - Правило 23*]
    Правило 87: Квалификатор {составного элемента данных} должен следовать сразу же за {компонентным элементом данных}, который он определяет. [R.1237 - Правило 25*]
    4.7 Простые элементы данных
    4.7.1.Правила, касающиеся одновременно пакетного и интерактивного ЭОД
    Правило 88: {Определение простого элемента данных должно:}
    - описывать значение {простого элемента данных},
    - определять, что представляет собой {простой элемент данных}, а не только то, что он собой не представляет,
    - носить уникальный характер в {справочнике элементов данных} ЭДИФАКТ ООН,
    - излагаться в единственном числе,
    - давать полное название акронимов в первом случае их появления,
    - не содержать аббревиатур,
    - не содержать грамматических родовых различий,
    - не содержать фраз "не требующий пояснения", "предстоит определить", "будет представлен" или синонимов этих фраз, если только такие фразы не являются неотъемлемой частью определения элемента данных.
    - [R.840 - Правило 52]
    Правило 89: Наименование {простого элемента данных} должно носить уникальный характер в {справочнике элементов данных} ЭДИФАКТ ООН. [R.840 - Правило 53]
    Правило 90: Наименование {простого элемента данных} должно согласовываться с его определением. [R.840 - Правило 54]
    Правило 91: Наименование кодированного {простого элемента данных}, который не идентифицирован в качестве {определяющего элемента данных}, должно заканчиваться {термом представления} "код" или {термом представления} "идентификатор". [R.840 - Правило 55*]
    Правило 92: {Простой элемент данных} должен специфицироваться с помощью {представления значения данных}. [R.840 - Правило 56]
    Правило 93: Кодированный {простой элемент данных}, который связан с {перечнем кодов} ЭДИФАКТ ООН, должен специфицироваться с помощью {представления значения данных} в виде по меньшей мере трех буквенно-цифровых знаков. [R.840 - Правило 57]
    4.8 Внешние перечни кодов
    4.8.1.Правила, касающиеся одновременно пакетного и интерактивного ЭОД
    Правила, применимые к данному разделу, отсутствуют.
    4.8.2.Правила, применимые к пакетному ЭОД
    Правило 94: Идентификация {внешнего перечня кодов} может обеспечиваться путем использования {простых элементов данных} 1131 и 3055 в рамках {составного элемента данных}. [R.840 - Правило 58]
    Правило 95: Кодированный {самостоятельный элемент данных} или кодированный {компонентный элемент данных}, за которыми непосредственно не следуют {компонентные элементы данных} 1131 и 3055, должны по меньшей мере обладать одним значением кода, специфицированным в отношении {элемента данных} в {справочнике перечней кодов} ЭДИФАКТ ООН, за исключением случаев, когда были идентифицированы одобренная ЕЭК ООН рекомендация или {перечень кодов} ИСО. [R.840 - Правило 59]
    4.8.3.Правила, применимые к интерактивному ЭОД
    Правила, применимые к данному разделу, отсутствуют.
    4.9 Значения кодов
    4.9.1.Правила, касающиеся одновременно пакетного и интерактивного ЭОД
    Правило 96: Наименование значения {кода} и {определение значения кода} должны согласовываться с охватом наименования {простого элемента данных} и {определением простого элемента данных}, к которому они относятся. [R.840 - Правило 60]
    Правило 97: {Определение значения кода} должно:
    - носить уникальный характер в {перечне кодов} для {простого элемента данных}, к которому оно относится,
    - излагаться в единственном числе,
    - определять, что представляет собой значение кода,
    - давать полное название акронимов в первом случае их появления,
    - не содержать аббревиатур,
    - не содержать фраз "не требующий пояснения", "предстоит определить", "будет представлен" или синонимов этих фраз, если только такие фразы не являются неотъемлемой частью определения значения кода,
    - [R.840 - Правило 61]
    Правило 98: Наименование {значения кода} должно согласовываться с {определением значения кода}. [R.840 - Правило 62]
    Правило 99: {Значение кода} для {определяющего элемента данных} должно указываться только в {справочнике перечней кодов} ЭДИФАКТ ООН. [R.840 - Правило 64]