ЕВРОПЕЙСКАЯ ЭКОНОМИЧЕСКАЯ КОМИССИЯ ООН
ОКОНЧАТЕЛЬНЫЕ ПРАВИЛА
РАЗРАБОТКИ СООБЩЕНИЙ ЭДИФАКТ ООН ДЛЯ ЭОД
(15 - 17 марта 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) Было признано, что терм "number" использовался
непоследовательно во многих справочниках данных, что вело к
двусмысленности. В некоторых случаях "number" описывает
арифметическую величину. В других случаях "номер" используется для
ссылки на значение из схемы идентификации (например, страхового
полиса), в качестве отличительной характеристики проведения
различий между двумя. С целью дифференциации этих двух типов
использования был введен терм представления "identificator", а
определение "number" было ограничено арифметической величиной.
С учетом того, что коммерческие термины часто являются частью
наименования значения кода, было сочтено, что правила наименования
ИСО 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. СПРАВОЧНЫЕ МАТЕРИАЛЫ
Нижеследующие стандарты содержат положения, которые в
соответствии со ссылками, содержащимися в настоящем документе,
являются положениями изложенных в нем правил.
ИСО 646 Обработка информации. Набор семибитных кодированных
знаков ИСО для обмена информацией
ИСО 9735 Электронный обмен данными в управлении, торговле и на
транспорте (ЭДИФАКТ). Синтаксические правила
прикладного уровня (версии 1, 2, 3 и 4 (части 1, 2 и
3))
ИСО 11179-5 Информационная технология. Спецификация и
стандартизация элементов данных. Часть 5 - Принципы
наименования и идентификации элементов данных.
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: {Составной элемент данных} должен обладать одной
из следующих структур:
{Структура 1:}
Кодированный элемент данных См. Примечание 1
Некодированный элемент данных См. Примечание 1
{Структура 2:}
Кодированный элемент данных
1131
3055
{Структура 3:}
Кодированный элемент данных См. Примечание 1
1131
3055
Некодированный элемент данных См. Примечание 1
{Структура 4:}
Определяющий элемент данных
Кодированный элемент данных
{Структура 5:}
Определяющий элемент данных
Некодированный элемент данных
{Структура 6:}
Определяющий элемент данных
Кодированный элемент данных См. Примечание 1
Некодированный элемент данных См. Примечание 1
{Структура 7:}
Определяющий элемент данных
Кодированный элемент данных
1131
3055
{Структура 8:}
Определяющий элемент данных
Кодированный элемент данных См. Примечание 1
1131
3055
Некодированный элемент данных См. Примечание 1
Примечание 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]
Приложение A
(нормативное)
ОПРЕДЕЛЕНИЯ
Примечание:
1. Если слово или фраза выделены в определении курсивом, это
означает, что определение этого слова или фразы приводится в
настоящем Приложении.
2. В определениях используются ссылки на следующие документы
ЭДИФАКТ ООН:
R.1023 TRADE/WP.4/GE.1/R.1023 (Rules for Presentation
of Standardised Messages and Directories
Documentation)
ИСО 9735: Синтаксические правила прикладного уровня ЭДИФАКТ,
часть 1
A.1 пакетный ЭОД: электронный обмен данными, в рамках которого
не предъявляется строгих требований к формализованному обмену
данными с точки зрения немедленного интерактивного
направления запросов и ответов участниками. [1]
A.2 характеристика: особенность или свойство объекта. [2]
A.3 перечень кодов: полный набор {значений элемента данных}
кодированного {простого элемента данных}. (ИСО 9735) [3]
A.4 справочник кодов: список идентифицированных и
специфицированных {перечней кодов}. (ИСО 9735) [4]
A.5 значение кода: кодированное представление допустимого
{значения элемента данных}. [5]
A.6 определение значения кода: определение, описывающее
содержание {значения кода} и позволяющее его дифференциацию
от всех других {значений кодов} в перечне кодов. В документе
называется "описанием значения кода". (R.1023) [6]
A.7 компонентный элемент данных: {простой элемент данных},
используемый в {составном элементе данных}. (ИСО 9735) [7]
A.8 составной элемент данных: идентифицированный, имеющий
наименование и структурированный набор функционально
взаимосвязанных {компонентных элементов данных}, определенный
в {спецификации компонентного элемента данных}. Он
представляет собой единицу данных. Кроме того, в {операции
И-ЭОД} он может представлять {единую коммерческую цель}. [8]
A.9 определение составного элемента данных: определение,
описывающее содержание {составного элемента данных} и
позволяющее его дифференциацию от всех других {составных
элементов данных}. В документе называется "описанием
составного элемента данных". (R.1023) [9]
A.10 справочник составных элементов данных: перечень
идентифицированных и имеющих наименования {составных
элементов данных} с указанием их {спецификаций}. (ИСО 9735)
[10]
A.11 спецификация составного элемента данных: описание {составного
элемента данных} в {справочнике составных элементов данных},
включая спецификацию местоположения, {статуса} и любых
{указателей зависимости компонентных элементов данных},
образующих {составной элемент данных}. [11]
A.12 условный: тип {статуса}, используемый в {спецификации
сообщения, спецификации сегмента или спецификации
составного элемента данных для указания того, что сегментная
группа, сегмент, составной элемент данных, самостоятельный
элемент данных или компонентный элемент данных} используются
факультативно или при наличии соответствующих условий. (ИСО
9735) [12]
A.13 элемент данных: единица данных, описываемая в {спецификации
элемента данных}. Существует два вида элементов данных:
{простой элемент данных} и {составной элемент данных}.
(ИСО 9735) [13]
A.14 определение элемента данных: определение, описывающее
содержание {простого элемента данных (определение простого
элемента данных)} или {составного элемента данных
(определение составного элемента данных)}. [14]
A.15 справочник элементов данных: перечень идентифицированных,
имеющих наименования и специфицированных {простых элементов
данных (справочник простых элементов данных)} или {составных
элементов данных (справочник составных элементов данных)}.
(ИСО 9735) [15]
A.16 спецификация элемента данных: спецификация {составного
элемента данных} в {справочнике составных элементов данных
(спецификация составного элемента данных)} или {простого
элемента данных в справочнике простых элементов данных
(спецификация простого элемента данных)}. (ИСО 9735) [16]
A.17 значение элемента данных: Конкретное содержание {простого
элемента данных, описанное, в спецификации простого элемента
данных} и, если {простой элемент данных является
кодированным}, в {перечне кодов}. (ИСО 9735) [17]
A.18 зона пояснения сегмента данных: Зона {спецификации
сообщения}, которая определяет использование каждого
{сегмента} и каждой {сегментной группы} в сообщении. [18]
A.19 представление значения данных: Типы допустимых знаков
(например, буквенных, цифровых) и заданная длина {значения
элемента} данных {простого элемента данных}. (ИСО 9735) [19]
A.20 идентификатор зависимости: {Идентификатор}, используемый в
{указателе зависимости} для спецификации типа зависимости
между взаимосвязанными структурами данных, перечисленными в
{указателе зависимости}. (ИСО 9735) [20]
A.21 указатель зависимости: Указатель, используемый:
i) в {спецификации сообщения} для выражения взаимосвязей
между {сегментами}, между {сегментными группами} или между
{сегментами} и {сегментными группами};
ii) в {спецификации сегмента} для выражения взаимосвязей
между {элементами данных};
iii) в {спецификации составного элемента данных} для
выражения взаимосвязей между {составными элементами данных}.
[21]
A.22 диалог: Двусторонний разговор между инициатором и
респондентом в рамках {интерактивной операции ЭОД}. Формально
состоит из пары обменов. (ИСО 9735) [22]
A.23 прямое определение: придание конкретного значения {простому
элементу данных с помощью определяющего элемента данных}.
[23]
A.24 внешний перечень кодов: Перечень {значений кодов}, не
включенных в {справочник кодов ЭДИФАКТ ООН}, который ведется
и публикуется признанной организацией по ведению кодов. [24]
A.25 идентификатор: знак или группа знаков, используемых для
идентификации или наименования данных и, возможно, для
указания определенных свойств этих данных. (ИСО 9735) [25]
A.26 И-ЭОД (Интерактивный ЭОД): Обмен заранее определенными и
структурированными данными в рамках {диалога}, который
согласуется с частями 1 и 3 синтаксических правил ИСО 9735, с
определенной коммерческой целью между парой взаимодействующих
процессов в режиме реального времени. (ИСО 9735) [26]
A.27 операция И-ЭОД: Конкретный {сценарий}. Состоит из одного или
более {диалогов}. (ИСО 9735) [27]
A.28 косвенное определение: Придание конкретного значения
{простому элементу данных} с помощью функционального(ых)
определения(и) того типа интерактивного сообщения,
интерактивного {сегмента} и / или {составного элемента
данных}, к которым он относится; или с помощью местоположения
{простого элемента данных} в интерактивном {сегменте} или
интерактивном {составном элементе данных}. [28]
A.29 уровень обобщения: Степень, в которой преимущество отдается
широким или общим характеристикам по сравнению с узкими или
конкретными характеристиками. [29]
A.30 обязательный: Тип статуса, используемый в {спецификации
сообщения, спецификации сегмента} или {спецификации
составного элемента данных}, для указания того, что
{сегментная группа, сегмент, составной элемент данных,
самостоятельный элемент данных} или {компонентный элемент
данных} должны использоваться по меньшей мере один раз. (ИСО
9735) [30]
A.31 максимальное число появлений: Максимальное число появлений
чего-либо в специфицированном местоположении в рамках
{сообщения} или его составных частей. [31]
A.32 сообщение: Идентифицированный, имеющий наименование и
структурированный набор функционально взаимосвязанных
{сегментов}, соответствующий потребностям операции
конкретного типа (например, счету - фактуре) и описанный в
{спецификации сообщения}; сообщение начинается с {заголовка
сообщения} и заканчивается {окончанием сообщения}. В ходе
передачи сообщение представляет собой конкретный
упорядоченный набор {сегментов} в соответствии со
{спецификацией сообщения}. (ИСО 9735) [32]
A.33 определение сообщения: Зона {спецификации сообщения}, которая
описывает функцию {сообщения} и обеспечивает его
дифференциацию от всех других {сообщений}. В документе
называется "функциональным определением". (R.1023) [33]
A.34 справочник сообщений: Перечень идентифицируемых и имеющих
наименования {сообщений} с указанием {спецификаций
сообщений}. (ИСО 9735) [34]
A.35 заголовок сообщения: {Служебный сегмент}, начинающий и
уникально идентифицирующий {сообщение}. (ИСО 9735) [35]
A.36 спецификация сообщения: Описание {сообщения} в {справочнике
сообщений}, включая спецификацию местоположения, {статуса,
максимального числа появлений} и любых указателей
{зависимости сегментов} и {сегментных групп, образующих
сообщение}. [36]
A.37 окончание сообщения: {Служебный сегмент}, заканчивающий
{сообщение}. (ИСО 9735) [37]
A.38 тип сообщения: код, идентифицирующий тип {сообщения}.
(ИСО 9735) [38]
A.39 терм класса объекта: первый компонент наименования {простого
элемента данных, составного элемента данных} или {сегмента},
представляющий наиболее значимое понятие. [39]
A.40 идентификатор местоположения: {идентификатор}, используемый в
{указателе зависимости} для идентификации компонента
({сегментной группы}, {сегмента} или {элемента данных}) с
помощью его местоположения в родительском образовании.
(ИСО 9735) [40]
A.41 терм свойства: обязательный компонент наименования {простого
элемента данных} или факультативный компонент наименования
{составного элемента данных} или {сегмента}. Он носит
подчиненный характер по отношению к {терму класса объекта} и
представляет собой отличительную характеристику или свойство
наиболее значимого понятия. [41]
A.42 определенный составной элемент данных: {составной элемент
данных}, чьим первым {компонентным элементом данных} является
{определяющий элемент данных}. [42]
A.43 определяющий элемент данных: {простой элемент данных}, чье
{значение элемента данных}, взятое из соответствующего
{справочника кодов} ЭДИФАКТ ООН, придает конкретное значение
{составному элементу данных} или {сегменту}. [43]
A.44 определенный сегмент: {сегмент}, первым {элементом данных}
которого является {определяющий элемент данных}. [44]
A.45 определяющий терм: компонент наименования, используемый в
качестве наименования {значения кода в перечне кодов} для
{определяющего элемента данных}. [45]
A.46 повторяющийся элемент данных: {составной элемент данных} или
{самостоятельный элемент данных}, максимальное число
появлений которого в {спецификации сегмента} больше единицы.
(ИСО 9735) [46]
A.47 терм представления: обязательный компонент наименования
{простого элемента данных}, который определяется в
регулируемом наборе термов представления и описывает форму
набора допустимых {значений элемента данных} для
определенного {элемента данных}. [47]
A.48 сценарий: формальная спецификация класса видов коммерческой
деятельности, преследующих одну и ту же коммерческую цель.
(ИСО 9735) [48]
A.49 разбитое на зоны сообщение: спецификация сообщения, разбитая
на две или более заранее определенных зон. [49]
A.50 сегмент: идентифицированный, имеющий наименование и
структурированный набор функционально взаимосвязанных
{составных элементов данных} и / или {самостоятельных
элементов данных}, описанный в {спецификации сегмента}.
Существует два типа сегментов: {сегмент пользователя} и
{служебный сегмент}. [50]
A.51 коллизия сегментов: коллизия сегментов возникает в том
случае, когда последовательная обработка ряда {сегментов} в
рамках любой конкретной реализации {сообщения} приводит к
двусмысленной идентификации любого {сегмента} с точки зрения
его обычного местоположения в {спецификации сообщения}. [51]
A.52 определение сегмента: определение, описывающее цель
{сегмента} и обеспечивающее его дифференциацию во всех других
{сегментах}. В документе называется "описанием сегмента".
(R.1023) [52]
A.53 справочник сегментов: перечень идентифицированных и имеющих
наименования {сегментов} с указанием их {спецификации}.
(ИСО 9735) [53]
A.54 сегментная группа: идентифицированный иерархический набор
{сегментов} и / или {сегментных групп} в рамках {сообщения}
(ИСО 9735) [54]
A.55 спецификация сегмента: описание {сегмента} в {справочнике
сегментов}, включая спецификацию местоположения, {статуса},
{максимального числа появлений} и любых {указателей
зависимости элементов данных}, образующих {сегмент}. [55]
A.56 табличная форма представления сегментов: зона {спецификации
сообщения}, в которой в табличной форме описывается
иерархическая структура {сообщения}. В табличной форме
представления сегмента идентифицируются и специфицируются
местоположение, {статус}, {максимальное число появлений} и
любые {указатели зависимости сегментов} и {сегментных групп}
в рамках {сообщения}. [56]
A.57 метка сегмента: {простой элемент данных}, уникально
идентифицирующий {сегмент} путем ссылки на {справочник
сегментов}. (ИСО 9735) [57]
A.58 служебный сегмент: {сегмент}, используемый
i) в служебных {сообщениях};
ii) для управления передачи данных. Спецификация служебного
сегмента содержит только служебные {составные элементы
данных} и / или служебные {простые элементы данных}. {Метка
сегмента} служебного сегмента начинается с буквы "U". [58]
A.59 одна коммерческая цель: данные, представляющие всю
совокупность или часть коммерческого процесса. [59]
A.60 простой элемент данных: {элемент данных}, содержащий одно
{значение} элемента данных. Существует два вида использования
{простого элемента данных}: в {составном элементе данных
(компонентный элемент данных)}; и в {сегменте вне составного
элемента данных (самостоятельный элемент данных)}. (ИСО 9735)
[60]
A.61 определение простого элемента данных: определение,
описывающее значение {простого элемента данных} и
обеспечивающее его дифференциацию от всех других {простых
элементов данных}. В документе называется "описанием элемента
данных". (R.1023) [61]
A.62 справочник простых элементов данных: перечень
идентифицированных и имеющих наименования {простых элементов
данных} с указанием их {спецификации} простых {элементов
данных}. (ИСО 9735) [62]
A.63 пара простых элементов данных: набор, состоящий из двух
{простых элементов данных}, один из которых содержит
информацию в кодированном виде, а другой является
описательным эквивалентом кодированной формы. [63]
A.64 спецификация простого элемента данных: набор атрибутов,
описывающих {простой элемент данных} в {справочнике простых
элементов данных}. (ИСО 9735) [64]
A.65 самостоятельный элемент данных: {простой элемент данных},
используемый в {сегменте} вне {составного элемента данных}.
(ИСО 9735) [65]
A.66 самостоятельный сегмент: {сегмент}, используемый в
{сообщении} вне {сегментной группы}. [66]
A.67 статус: атрибут {сегмента, составного элемента данных} или
{простого элемента данных}, определяющий правила присутствия
или отсутствия {сегмента / элемента данных} при использовании
{сообщения}. Существует два типа статуса: {условный} и
{обязательный}. (ИСО 9735) [67]
A.68 синтаксический служебный справочник: справочник, содержащий
служебные {сообщения, служебные сегменты, служебные составные
элементы данных} и служебные {элементы данных}, ведущиеся в
рамках ИСО 9735 (ЭДИФАКТ Синтаксические правила прикладного
уровня). [68]
A.69 целевой справочник ЭДИФАКТ ООН: следующий, удовлетворяющий
требованиям ведения справочник ЭДИФАКТ ООН (для пакетного или
интерактивного ЭОД), для которого предназначен предлагаемый
элемент. [69]
A.70 пусковой сегмент: {сегмент}, начинающий {сегментную группу}.
(ИСО 9735) [70]
A.71 сегмент пользователя: {сегмент}, специфицированный в
{справочнике сегментов} ЭДИФАКТ ООН. {Метка сегмента}
пользователя не начинается с буквы "U". [71]
Приложение B
(нормативное)
ПРАВИЛА
НАИМЕНОВАНИЯ ЭЛЕМЕНТОВ ДАННЫХ И СЕГМЕНТОВ
B.1 Введение
Настоящее Приложение содержит правила для определения
структурированных наименований простых элементов данных, составных
элементов данных и сегментов ЭДИФАКТ ООН. Эти правила были
разработаны на основе рекомендаций и принципов, описанных в
разделе 6 документа ИСО 11179-5 (Guidelines for structured naming
conventions). В некоторых случаях эти руководящие принципы были
адаптированы с учетом особенностей ЭДИФАКТ ООН. В частности, они
были расширены с целью включения в их охват не только правил
вопросов наименования простых элементов данных, но также и правил
наименования составных элементов данных и сегментов. Правила
использования определяющих термов были модифицированы с целью
приведения их в соответствие с правилами использования
определяющих элементов данных в ЭДИФАКТ ООН.
Данные правила классифицируются следующим образом:
Семантические правила - правила, определяющие методику
присвоения значения содержанию наименования
Синтаксические правила - правила, определяющие структуру
наименования и порядок и использование компонентов наименования
Лексические правила - правила, определяющие форму слова и
словарные принципы, применяемые к наименованию и его компонентам.
Один из фундаментальных принципов, изложенных в ИСО 11179,
который поддерживает ЭДИФАКТ ООН, заключается в том, что в первую
очередь должно разрабатываться определение, на основе которого
составляется наименование.
B.2 Семантические правила
Наименования состоят из следующих компонентов: {терм класса
объекта, терм свойства и терм представления}.
Правило B1: {Терм класса объекта} должен представлять наиболее
значимое понятие.
Так например, в наименованиях {простых элементов данных}:
Reference version number
---------
Amount function code
------
Movement type description
--------
подчеркнутые слова являются {термами класса объекта}.
Правило B2: {Терм свойства} должен представлять отличительную
характеристику или свойство наиболее значимого понятия. Терм
свойства должен естественно присутствовать в определении.
Так например, в наименованиях {простых элементов данных}:
Reference version number
-------
Amount function code
--------
Movement type description
----
подчеркнутые слова являются {термами свойства}.
Правило B3: {Терм представления} должен описывать форму набора
допустимых {значений элемента данных простого элемента данных}.
Так например, в наименованиях {простых элементов данных}:
Reference version number
------
Amount function code
----
Movement type description
-----------
подчеркнутые слова являются {термами представления}.
Правило B4: {Терм представления} должен являться одним из
термов, включенных в перечень одобренных {термов представления}
(см. правило B5).
Правило B5: {Определяющий терм} должен специфицироваться
только в качестве наименования {значения кода} в {перечне кодов
для определяющего элемента данных}, который определяет {простой
элемент данных}.
Правило B6: {Определяющие термы} должны обеспечивать
присвоение конкретного значения наименованию {простого элемента
данных} в случаях, когда при нем присутствует {определяющий
элемент данных}.
Так например, в {перечне кодов} для {определяющего элемента
данных}, именуемого "Cost total amount qualifier", наименования
{значений кодов}:
Budget period
Accounting period
Tax period
являются определяющими {термами простого элемента данных},
именуемого "Cost total amount" в тех случаях, когда этот {простой
элемент данных} сопровождается {определяющим элементом данных} под
наименованием "Cost total amount qualifier".
B.3 Синтаксические правила
Правило B7:
a) Наименование {простого элемента данных}, который не
является {определяющим элементом данных}, должно иметь следующий
формат:
¦ Терм класса ¦ Терм ¦ Терм ¦
¦ объектов ¦ свойства ¦представления¦
L------------------+---------------+--------------
b) Наименование {простого элемента данных}, который является
{определяющим элементом данных}, должно иметь следующий формат:
¦ Терм класса ¦ Терм свойства ¦ Терм ¦"квалификатор"¦
¦ объекта ¦ ¦представления¦ ¦
L-------------+---------------+-------------+---------------
c) Наименование {составного элемента данных} должно иметь
следующий формат:
¦ Терм класса ¦ Терм свойства ¦
¦ объекта ¦ ------------- ¦
L-------------+----------------
d) Наименование {сегмента} должно иметь следующий формат:
¦ Терм класса ¦ Терм свойства ¦
¦ объекта ¦ ------------- ¦
L-------------+----------------
Все термы являются обязательными, за исключением подчеркнутых.
Подчеркнутые термы носят факультативный характер.
Правило B8: Один и только один {терм класса объекта} должен
присутствовать в наименовании {элемента данных} или {сегмента}.
Правило B9: Один и только один {терм свойства} должен
присутствовать в наименовании {простого элемента данных}.
Правило B10: Один и только один {терм свойства} может
присутствовать в наименовании {составного элемента данных} или
{сегмента}.
Правило B11: Один и только один {терм представления} должен
присутствовать в наименовании {простого элемента данных}.
Правило B12: Наименование {определяющего элемента данных}
должно заканчиваться словом "qualifier" после {терма
представления}.
B.4 Лексические правила
Правило B13: Наименование должно иметь единственное число.
Правило B14: {Терм класса объекта} или {терм свойства} должны
состоять из одного или более слов.
Правило B15: {Терм представления} должен состоять только из
одного слова.
Правило B16: Составные компоненты наименования и слова в
терме, состоящем из нескольких слов, должны разделяться знаком
пробела.
Правило B17: В наименовании не должны использоваться
специальные знаки.
Правило B18: Аббревиатуры, акронимы и инициалы не должны
использоваться в наименовании.
Правило B19: Наименование не должно содержать лишних слов.
Так, например, в наименовании {простого элемента данных} "Employee
last name" {термом свойства} является "last name", а {термом
представления} - "name". При одновременном использовании {терма
свойства} и {терма представления} повторное использование слова
"name" является излишним, вследствие чего оно исключается.
B.5 Перечень термов представления
Нижеследующий перечень содержит допустимые {термы
представления}. Запросы о включении дополнительных {термов
представления} должны обрабатываться в соответствии с процедурами
запроса о ведении данных ЭДИФАКТ ООН.
amount (сумма) Количество денежных единиц. Обычно с указанием
типа денежной единицы.
code (код) Последовательность знаков, представляющая собой
член набора значений.
description Последовательность предложений, описывающая лицо,
(описание) объект, место, событие или понятие. К описаниям
также относятся определения, которые обычно
состоят из одного или двух предложений, а также
большие по объему тексты.
identifier Последовательность знаков, используемая для
(идентификатор) уникальной идентификации и дифференциации
конкретного значения в рамках схемы идентификации.
name Слово или фраза, представляющая собой
(наименование) отличительное обозначение лица, объекта, места,
события или понятия. То, под чем известно или
каким образом называется лицо, объект, место,
событие или понятие.
number (номер) Арифметическое выражение, представляющее собой
конкретную величину. Примечание: Зачастую может
также обозначать принадлежность к
последовательности или серии.
percent Отношение в виде сотой доли величин,
(процент) характеризующихся одной и той же единицей
измерения.
quantity Число неденежных единиц. Обычно указывается с
(количество) единицей измерения.
rate Отношение одного измеренного количества или суммы
(соотношение) к другому измеренному количеству или сумме.
Приложение C
(информационное)
ПРИМЕРЫ НАИМЕНОВАНИЯ ДЛЯ СПРАВОЧНИКА ЭЛЕМЕНТОВ ДАННЫХ
C.1 Введение
В настоящем информационном Приложении приводится выборка
простых элементов данных, взятых из справочника элементов данных
D.97A ЭДИФАКТ ООН. Оно служит иллюстрацией возможностей
использования правил наименования, определенных в Приложении B.
Настоящее Приложение включено в документ только для информации и
НЕ предназначено для подачи запросов на ведение данных в
справочнике.
C.2 Справочник элементов данных D.97A
------T----------------------------T-----------------------------¬
¦Метка¦Наименование элемента данных¦ Пример наименования ¦
+-----+----------------------------+-----------------------------+
¦1000 ¦Document/message name ¦Document name ¦
+-----+----------------------------+-----------------------------+
¦1050 ¦Sequence number ¦Sequence number ¦
+-----+----------------------------+-----------------------------+
¦1056 ¦Version ¦Version identifier ¦
+-----+----------------------------+-----------------------------+
¦1058 ¦Release ¦Release identifier ¦
+-----+----------------------------+-----------------------------+
¦1153 ¦Reference qualifier ¦Reference identifier ¦
¦ ¦ ¦qualifier ¦
+-----+----------------------------+-----------------------------+
¦1154 ¦Reference number ¦Reference identifier ¦
+-----+----------------------------+-----------------------------+
¦1222 ¦Configuration level ¦Configuration level number ¦
+-----+----------------------------+-----------------------------+
¦1245 ¦Status indicator, coded ¦Status code ¦
+-----+----------------------------+-----------------------------+
¦1366 ¦Document/message source ¦Document source description ¦
+-----+----------------------------+-----------------------------+
¦1475 ¦Message type identifier ¦Message type code ¦
+-----+----------------------------+-----------------------------+
¦1476 ¦Control agency ¦Control agency identifier ¦
+-----+----------------------------+-----------------------------+
¦1490 ¦Consolidation item number ¦Item identifier ¦
+-----+----------------------------+-----------------------------+
¦3035 ¦Party qualifier ¦Party function code ¦
¦ ¦ ¦qualifier ¦
+-----+----------------------------+-----------------------------+
¦3036 ¦Party name ¦Party name ¦
+-----+----------------------------+-----------------------------+
¦3039 ¦Party id. Identification ¦Party code ¦
+-----+----------------------------+-----------------------------+
¦3397 ¦Name status, coded ¦Name status code ¦
+-----+----------------------------+-----------------------------+
¦3398 ¦Name component ¦Name component description ¦
+-----+----------------------------+-----------------------------+
¦4043 ¦Class of trade, coded ¦Trade class code ¦
+-----+----------------------------+-----------------------------+
¦5004 ¦Monetary amount ¦Monetary amount ¦
+-----+----------------------------+-----------------------------+
¦5393 ¦Price multiplier qualifier ¦Price multiplier qualifier ¦
+-----+----------------------------+-----------------------------+
¦5402 ¦Rate of exchange ¦Exchange rate ¦
+-----+----------------------------+-----------------------------+
¦6174 ¦Size ¦Size number ¦
+-----+----------------------------+-----------------------------+
¦6341 ¦Currency market exchange, ¦Currency market exchange code¦
¦ ¦coded ¦ ¦
+-----+----------------------------+-----------------------------+
¦6345 ¦Currency, coded ¦Currency code ¦
+-----+----------------------------+-----------------------------+
¦6350 ¦Number of units ¦Units number ¦
+-----+----------------------------+-----------------------------+
¦6353 ¦Number of units qualifier ¦Unit type code qualifier ¦
+-----+----------------------------+-----------------------------+
¦6426 ¦Number of stages ¦Stages count number ¦
+-----+----------------------------+-----------------------------+
¦6428 ¦Actual stage count ¦Stages actual count number ¦
+-----+----------------------------+-----------------------------+
¦6432 ¦Significant digits ¦Significant digits number ¦
+-----+----------------------------+-----------------------------+
¦6434 ¦Statistical concept ¦Statistical concept code ¦
¦ ¦identifier ¦ ¦
+-----+----------------------------+-----------------------------+
¦7124 ¦UNDG number ¦United Nations Dangerous ¦
¦ ¦ ¦Goods identifier ¦
+-----+----------------------------+-----------------------------+
¦7436 ¦Level one id. ¦Level one identifier ¦
+-----+----------------------------+-----------------------------+
¦7500 ¦Type of damage ¦Damage type description ¦
+-----+----------------------------+-----------------------------+
¦7501 ¦Type of damage, coded ¦Damage type code ¦
+-----+----------------------------+-----------------------------+
¦7502 ¦Damage area ¦Damage area description ¦
+-----+----------------------------+-----------------------------+
¦7503 ¦Damage area identification ¦Damage area code ¦
+-----+----------------------------+-----------------------------+
¦8211 ¦Permission for transport, ¦Transport permission code ¦
¦ ¦coded ¦ ¦
+-----+----------------------------+-----------------------------+
¦8341 ¦Haulage arrangements, coded ¦Haulage arrangements code ¦
+-----+----------------------------+-----------------------------+
¦8351 ¦Hazard code identification ¦Hazard code ¦
+-----+----------------------------+-----------------------------+
¦9430 ¦Footnote set identifier ¦Footnote set code ¦
+-----+----------------------------+-----------------------------+
¦9432 ¦Footnote identifier ¦Footnote code ¦
+-----+----------------------------+-----------------------------+
¦9434 ¦Code name ¦Code value name ¦
L-----+----------------------------+------------------------------
Приложение D
(информационное)
МОДЕЛЬ ПРОЦЕССА РАЗРАБОТКИ СООБЩЕНИЯ
Потребность в разработке сообщений ЭДИФАКТ ООН возникает в том
случае, когда участники устанавливают, что их коммерческие
потребности опираются на информацию, обмен которой должен вестись
в электронном режиме.
-----------------------------------------------------------------¬
¦ ¦КОММЕРЧЕСКИЕ ¦ПРОЦЕДУРЫ ¦
¦ ¦ПРОЦЕДУРЫ ¦ЭДИФАКТ ¦
¦ ¦ ¦ ¦
¦ \¦/ \¦/ ¦
¦ КОММЕРЧЕСКИЕ ----------------------¬ СООБЩЕНИЯ ЭДИФАКТ ¦
¦ ПОТРЕБНОСТИ ¦РАЗРАБОТКА ОБМЕНА ЭОД+---------------------> ¦
¦ ---------------->¦ МЕЖДУ ТОРГОВЫМИ ¦ СОГЛАШЕНИЕ ОБ ОБМЕНЕ ¦
¦ ¦ ПАРТНЕРАМИ +---------------------> ¦
¦ L---------------------- ¦
¦ /¦\ ¦
¦ ¦ ¦
¦ ¦УЧАСТНИКИ ¦
L-----------------------------------------------------------------
Рисунок D.1 Разработка обмена ЭОД между торговыми
партнерами
Анализ и определение наиболее важных коммерческих потребностей
служат основой для деятельности по разработке. Внутрифирменные,
правовые и / или коммерческие процедуры также могут использоваться
в процессе разработки. Процедуры ЭДИФАКТ ООН обеспечивают
разработку необходимых стандартов и стандартизированную поддержку
широкого круга различных коммерческих функций.
После принятия решения о ведении коммерческих операций с
помощью электронных средств могут быть определены требования
индивидуальных коммерческих функций. Это в свою очередь позволит
разработать модель ключевых аспектов изучаемой коммерческой среды.
После согласования общих требований со всеми участниками могут
быть определены конкретные системные требования. Эти системные
требования позволят специфицировать все информационные обмены,
которые будут осуществляться между различными участниками, а также
функции, которые они будут призваны выполнять. В разрабатываемом
сценарии коммерческой сделки должны быть описаны все
информационные обмены, осуществляемые операторами в электронном
режиме. Все коммерческие ограничивающие условия между этими
обменами также требуют идентификации. Это включает в себя
определение каждого события, инициирующего определенный
информационный обмен.
---------------T-----------------------------------------------------------------------------------¬
¦ ¦КОММЕРЧЕСКИЕ ПРОЦЕДУРЫ ¦ ПРОЦЕДУРЫ ЭДИФАКТ ¦
¦ +------------------------T----------------¬ +-------¬ ¦
¦ \¦/ ¦ ¦ ¦ ¦ ¦
¦ -------------¬ ¦ ¦ ¦ ¦ ¦
¦КОММЕРЧЕСКИЕ¦ОПРЕДЕЛЕНИЕ ¦ КОММЕРЧЕСКИЕ¦ ¦ ¦ ¦ ¦
¦ПОТРЕБНОСТИ ¦КОММЕРЧЕСКИХ+¬ТРЕБОВАНИЯ ¦ ¦ ¦ ¦ ¦
¦ ¦ТРЕБОВАНИЙ ¦¦ -----------¦ ¦ ¦ ¦ ¦
¦ ¦ A1¦+-- \¦/ ¦ ¦ ¦ ¦
¦ L-------------¦ -----------¬ ¦ ¦ ¦ ¦
¦ /¦\ ¦ ¦АНАЛИЗ ¦ ИНФОРМАЦИОННЫЕ¦ ¦ ¦ ¦
¦ ¦ L->¦СИСТЕМНЫХ +¬ОБМЕНЫ ¦ ¦ ¦ ¦
¦ ¦ ¦ТРЕБОВАНИЙ¦¦ -------------¦ ¦ ¦ ¦
¦ ¦ ¦ A2¦+-- \¦/ ¦ ¦ ¦
¦ ¦ L-----------¦ --------------¬ ¦ ¦ ¦
¦ ¦ /¦\ ¦ ¦ОПРЕДЕЛЕНИЕ ¦ ТРЕБОВАНИЯ¦ ¦ ¦
¦ ¦ ¦ +>¦ТРЕБОВАНИЙ К +¬К ПЕРЕДАЧЕ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ИНФОРМАЦИИ ¦¦СООБЩЕНИЙ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ A3¦¦ ---------¦ ¦ ¦
¦ ¦ ¦ ¦ L--------------+-- \¦/ ¦ ¦
¦ ¦ ¦ ¦ /¦\ ¦ -------------¬ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦РАЗРАБОТКА ¦ ¦СООБЩЕНИЯ ЭДИФАКТ ¦
¦ ¦ ¦ ¦ ¦ +>¦СПЕЦИФИКАЦИЙ+T--+------------------->¦
¦ ¦ ¦ ¦ ¦ ¦ ¦СООБЩЕНИЙ ¦¦ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ ¦ A4¦¦ \¦/ ¦
¦ ¦ ¦ ¦ ¦ ¦ L-------------¦ -----------¬СОГЛАШЕНИЕ¦
¦ ¦ ¦ ¦ ¦ ¦ /¦\ L>¦ПОДГОТОВКА¦ОБ ОБМЕНЕ ¦
¦ ¦ ¦ ¦ ¦ L-------+-------->¦СОГЛАШЕНИЯ+--------->¦
¦ ¦ ¦ L-------+----------------+-------->¦ОБ ОБМЕНЕ ¦ ¦
¦ ¦ ¦ ¦ ¦ ¦ A5¦ ¦
¦ ¦ ¦ ¦ ¦ L----------- ¦
¦ ¦ ¦ ¦ ¦ /¦\ ¦
¦ +-----------------+--------------+----------------+--------------- ¦
¦ ¦УЧАСТНИКИ ¦
L---------------------------------------------------------------------------------------------------
Рисунок D.2 Разработка обмена ЭОД между торговыми
партнерами
После определения системных требований проводится изучение
всех информационных обменов с целью установления их соответствия
требованиям передачи с помощью электронных средств. Информационные
обмены, отобранные в качестве кандидатов для передачи электронными
средствами, подробно анализируются для определения четких
требований к данным конкретных информационных обменов.
Требования к данным каждого электронного обмена информацией
могут структурироваться в идентифицируемый и обладающий
наименованием набор компонентов, каждый из которых описывает
конкретный субъект с помощью своих соответствующих атрибутов.
Первоначальная спецификация сообщения разрабатывается на основе
этих определений компонентов и / или моделей данных. См. также
TRADE/WP.4/GE.1 R.1212 (Draft Business and Information Modelling
Framework for UN/EDIFACT).
Необходимо изучить существующий справочник сообщений ЭДИФАКТ
ООН для определения того, не соответствует ли одно из существующих
сообщений требуемой коммерческой функции.
Если одно или несколько из существующих сообщений выполняют
данную функцию, спецификация сообщения сопоставляется со
спецификацией, содержащейся в справочнике сообщений ЭДИФАКТ ООН.
Если некоторые требования не охватываются существующим сообщением,
необходимо подготовить и подать запрос о ведении данных в
соответствии с процедурами ЭДИФАКТ ООН.
Если ни одно из существующих сообщений ЭДИФАКТ ООН не
соответствует предъявляемым требованиям, необходимо подготовить и
подать в соответствии с процедурами ЭДИФАКТ ООН запрос о ведении
данных для нового сообщения.
После определения индивидуальных сообщений стороны, желающие
участвовать в электронном обмене, как правило, заключают
официальные соглашения об обмене.
----------------------------------------------------------------------------------------------------¬
¦ ¦
¦ ¦ПРОЦЕДУРЫ ЭДИФАКТ ¦
¦ +------------------T------------------T---------------T-----------¬ ¦
¦ \¦/ ¦ ¦ ¦ ¦ ¦
¦ -------------¬ ¦ ¦ ¦ ¦ ¦
¦ ¦РАЗБИВКА ¦ КОМПОНЕНТЫ ¦ ¦ ¦ ¦ ¦
¦--------->¦ИНФОРМАЦИИ ¦ СООБЩЕНИЯ ¦ ¦ ¦ ¦ ¦
¦ТРЕБОВАНИЯ¦СООБЩЕНИЯ НА+¬ --------- ¦ ¦ ¦ ¦ ¦
¦К ПЕРЕДАЧЕ¦КОМПОНЕНТЫ ¦+-- ¦ ¦ ¦ ¦ ¦
¦СООБЩЕНИЙ ¦ A4.1¦¦ \¦/ ¦ ¦ ¦ ¦
¦ L-------------¦ -------------¬ ¦ ¦ ¦ ¦
¦ ¦ ¦СОГЛАСОВАНИЕ¦ СОГЛАСОВАННЫЕ ¦ ¦ ¦ ¦
¦ L>¦КОМПОНЕНТОВ +¬КОМПОНЕНТЫ ¦ ¦ ¦ ¦
¦ ¦ A4.2¦¦ ------------ ¦ ¦ ¦ ¦
¦ L-------------+-- \¦/ СУЩЕСТВУЮЩИЕ ¦ ¦ ¦
¦ ¦ --------------¬ СЕГМЕНТЫ ¦ ¦ ¦
¦ ¦ ¦ИДЕНТИФИКАЦИЯ¦ ------------ ¦ ¦ ¦
¦ ¦ ¦СУЩЕСТВУЮЩИХ +-+------------+--¬ ¦ ¦
¦ L>¦СЕГМЕНТОВ +¬ ¦ ¦ ¦ ¦
¦ ¦ A4.3¦¦ \¦/ ¦ ¦ ¦
¦ L--------------¦ -------------¬ ¦ ¦ ¦
¦ ¦ ¦СПЕЦИФИКАЦИЯ¦ ¦ ¦ ¦
¦ --+ ¦ТРЕБОВАНИЙ ¦ ¦ ¦ ¦
¦ ТРЕБОВАНИЯ ¦ L>¦К НОВОМУ +¬¦ ¦ ¦
¦ К НОВОМУ ¦ ¦СЕГМЕНТУ ¦¦¦ \¦/ ¦
¦ СЕГМЕНТУ ¦ ¦ A4.4¦¦¦ -------------¬ ¦
¦ L----------- L-------------¦L>¦РАЗРАБОТКА ¦СООБЩЕНИЯ¦
¦ --+ ¦СПЕЦИФИКАЦИИ¦ЭДИФАКТ ¦
¦ ¦ L->¦СООБЩЕНИЯ +-------->¦
¦ НОВЫЕ ¦ ¦ A4.5¦ ¦
¦ СЕГМЕНТЫ ¦ L------------- ¦
¦ L--------- ¦
¦ ¦
L----------------------------------------------------------------------------------------------------
Рис. D.3 Разработка спецификации сообщения
Требования к данным информационного обмена анализируются с
целью их разбивки на компоненты, представляющие конкретный
субъект. Все атрибуты компонента должны быть связаны с
определяемым компонентом субъектом. Для обеспечения того, чтобы
каждый атрибут был связан с одной единицей информации о субъекте,
необходимо использовать конкретные методы моделирования /
стандартизации. Если атрибут не является полностью зависимым от
описываемого компонентом субъекта, необходимо создать новый
компонент для описания полного содержания субъекта атрибута. После
согласования компонентов необходимо изучить справочник сегментов
ЭДИФАКТ ООН с целью выявления уже существующих сегментов,
удовлетворяющих требованиям каждого идентифицированного
компонента. Требованиям отдельного компонента может удовлетворять
один сегмент или комбинация сегментов, специфицированная в
сегментной группе. Подробности в одном или более атрибутах могут
быть удовлетворены путем запроса о создании дополнительных
значений кодов определяющего элемента данных для существующего
сегмента или составного элемента данных.
Что касается атрибутов, не охватываемых существующим сегментом
ЭДИФАКТ ООН, то в соответствии с правилами разработки сообщений
может быть направлен запрос о ведении одного или более новых
сегментов. Запросы о ведении данных для новых сегментов, элементов
данных и новых значений кодов должны составляться и подаваться в
соответствии с процедурами ЭДИФАКТ ООН.
Завершив распределение требований к данным для конкретного
информационного обмена по существующим и / или новым сегментам, на
основе правил разработки сообщений может быть составлена
спецификация сообщения. Структура сообщения, включая обязательный
или условный статус и число появлений каждого сегмента и / или
сегментной группы, определяются с учетом требований
информационного обмена.
Приложение E
(нормативное)
СИСТЕМА ОБОЗНАЧЕНИЙ ДЛЯ УКАЗАТЕЛЕЙ ЗАВИСИМОСТИ
Система обозначений для указателей зависимости включает в себя
идентификатор зависимости, после которого в скобках приводится
перечень идентификаторов местоположения, разделенных запятыми,
например D3(030, 060, 090). Идентификаторы местоположения
указывают на соответствующие структуры данных, такие, как
сегменты, сегментные группы и элементы данных.
Идентификаторы зависимости:
D1 ONE AND ONLY ONE
Должен присутствовать один и только один из идентификаторов
местоположения перечня.
D2 ALL OR NONE
Если присутствует один идентификатор местоположения перечня,
то должны присутствовать и все остальные.
D3 ONE OR MORE
Должен присутствовать по меньшей мере один из идентификаторов
местоположения перечня.
D4 ONE OR NONE
Должен присутствовать только один идентификатор местоположения
перечня.
D5 IF FIRST, THEN ALL
Если присутствует первый идентификатор местоположения перечня,
то должны присутствовать и все остальные. Допускается
присутствие одного или более идентификаторов местоположения,
не специфицированных в качестве первого идентификатора в
перечне без необходимости присутствия первого идентификатора
местоположения.
D6 IF FIRST, THEN AT LEAST ONE MORE
Если присутствует первый идентификатор местоположения перечня,
то должен присутствовать по меньшей мере еще один
идентификатор. Допускается присутствие одного или более
идентификаторов местоположения, не специфицированных в
качестве первого в перечне без необходимости присутствия
первого идентификатора перечня.
D7 IF FIRST, THEN NONE OF THE OTHERS
Если присутствует первый идентификатор местоположения перечня,
то другие не должны присутствовать.
|
