Формат edifact пример файла заказа

Обновлено: 04.07.2024

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТ Р 54878 — 2011/ISO/TS

20625:2002

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

Принципы формирования файлов XML схемы (XSD)

на основе инструкций по реализации

EDI(FACT)

Electronic data interchange for administration, commerce and

Rules for generation of XML scheme files (XSD) on the basis of EDI(FACT) implementation guidelines

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-Ф5 «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0—2004 «Стандартизация в Российской Федерации. Основные положения»

Сведения о стандарте

1 ПОДГОТОВЛЕН Научно-'бхкическим центром «ИНТЕК» на основе собственного аутентичного пере* вода на русский язык международного документа, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК100 «Стратегический и инновационный менеджмент»

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

4 Настоящий стандарт идентичен международ ному документу ИСО/ТС 20625:2002 «Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Принципы формирования файлов XML схемы (XSD) на основе инструкций по реализации EDI(FACT)» (ISO/TS 20625:2002 «Electronic data interchange for administration, commerce and transport (EDIFACT) — Rules for generation of XML scheme files (XSD) on the basis of EDI(FACT) implementation guidelines»>.

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

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

Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном укачятапа «Няцнсмяпнные стандарты», а текст нилАнаичи и попрааои — а ежемесячно издаваемом информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационнсм указателе «Национальные стандарты». Соответствующая информация. уведомление и тексты размещаются также в информационной системе общего пользования—на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет

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

Содержание

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

Введение

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

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

ЭЛЕКТРОННЫЙ ОБМЕН ДАННЫМИ В УПРАВЛЕНИИ. Т0РГ08ЛЕ И НА ТРАНСПОРТЕ

Принципы формирования файлов XML схемы (XSD) на основе инструкций по реализации EDI(FACT)

Electronic data interchange for administration, commerce and transport (EDIFACT).

Rules for generation of XML scheme files (XSD) on the basis of EDI(FACT) implementation guidelines

Дата введения — 2012 — 09 — 01

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

Настоящий стандарт устанавливает принципы выбора XML-схем (структур) из EDI MIG-инструкций, обеспечивающих применение обоснованного метода представления семантических данных.

В настоящем стандарте определен способ выбора XML-данных из UN/EDIFACT MIG-инструкций. Рассматриваемые принципы применимы и к другим EDI-стандартам.

Настоящий стандарт не распространяется на описания типов документов (DTDs).

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

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

ИСО 8601:2004 Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени (ISO 8601:2004. Data elements and interchange formats. Information interchange. Representation of dates and times)

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

3 Термины, определения и сокращения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 базовый семантический регистр (basic semantics register; 8SR).

3.2 базовая семантическая единица (basic semantic unit: BSU).

3.3 описание типа документа (document type definition; DTD).

3.4 электронный обмен данными (electronic data interchange; EDI).

3.5 электронный обмен данными в управлении, торговле и на транспорте (electronic data interchange for administration, commerce and transport: EDIFACT).

3.6 гипертекстовый язык разметки документов (hyper text mark-up language: HTML).

3.8 стандартный обобщенный язык описания документов (standard generalised mark-up language; SGML).

3.9 расширяемый язык описания связей (extensible link language: XLL).

3.10 расширяемый язык разметки (extensible mark-up language; XML).

3.11 расширяемое определение схемы (extensible schema definition; XSD).

3.12 расширяемый язык таблиц стилей (extensible stylesheet language; XSL).

3.13 www-консорциум (world wide web consortium: W3C).

3.14 элемент (element): Синтаксический структурный блок, содержащий данные и/или атрибуты.

3.15 имя (name): Имя в XML-языке начинается с буквы или допустимого специального символа, далее могут следовать буквы, цифры, дефисы, подчеркивания, двоеточия или точки. Имена, начинающиеся с «хт!в или со строки символов, которые примыкают к (('X’l'x') fM'I'm') ('L'|T)>, являются резервными для целей XML-стандартизации.

3.16 шаблон (template): Предварительно задаваемая эталонная структура, сравниваемая с полной структурной единицей (или содной из ее частей), которая должна быть распознана.

3.17 тег, метка (tag): Инструкция по форматированию или семантическая пометка.

a) Идентификационные данные MIG-инструкции.

b) Идентификационные данные служебного EDIFACT-каталога.

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

c) Контекстно связанные имена и описания сегментов и фупп сегментов.

e) Взаимосвязи между сегментами и группами сегментов.

4.3 Уровень: Сегменты и составные элементы данных

a) Структура сегментов и составных элементов данных, а также указание используемых ими позиций.

b) Состояние (стандартное или прикладное) элементов данных и составных элементов данных.

d) Контекстно связанные плена и описания.

f) Дополнительный текст, комментарии.

4.4 Уровень: Элемент дгнных

a) Характеристики EDI-элементов данных (тип. длина) и офаничения на их применение, основанные на MIG-инструкциях и контекстно связанном исполнении.

b) Контекстно связанные имена и описания элементов данных и при необходимости индивидуальные теги и описания, например, отбираемые из хранилищ данных типа ISO-BSR.

d) Дополнительный текст, комментарии.

e) Допустимые значения.

д) Четко задаваемые пользователем EDIFACT-коды или перечни ISO/UN-кодое. h) Четко задаваемые пользователем коды.

г) Произвольно задаваемые пользователем EDIFACT-коды или перечни ISO/UN-кодов.

j) Произвольно задаваемые пользователем коды, не содержащиеся в каталоге EDIFACT-кодов.

k) Принципы, которым долкны отвечать значения элементов данных.

l) Преобразование в поля в программах и неструктурированных файлах соответственно.

5 Требования к принципам логического вывода схем

a) MIG-техническая информация, перечисленная в разделе 4. при необходимости должна иметь возможность быть встроенной в схемы (структуры).

b) Структура MlG-инструкцни более низкого уровня должна быть легко доступной (XML- и традиционные EDI-инструкции должны быть сопоставимыми по структуре).

d) Существование варианта, определенного с помощью настоящего стандарта как обязательного, при котором семантические данные могут представляться в XML виде.

e) Разработчик MIG-инструкций решает, какие данные важны и какие структуры значимы для его конкретного приложения. Именно он должен определить, какие структурные элементы должны объединяться в схемы.

6 Принципы формирования XML-схем, отбираемых из EDI MIG-инструкций

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

6.1 Принцип 1: Наименование тега

Имена XML-структуры должны формироваться из EOI-тегое. которые будут префиксами, зависящими от уровня структуры (группы сегментов, сегмента, составного элемента данных или самого элемента данных). т. в.:

_G_*+ группа сегментов ♦ (суффикс) Пример: G_SG36 или GJJN_ALC

,S_*+ сегмент ♦ (суффикс) Пример: S_LIN

Х_"+ составной элемент данных ♦ (суффикс) Пример: С_С0&2_2

„0_"+ элемент данных + (суффикс) Пример: D_3035 или D_3035_10

Суффикс является дополн/ггельным элементом и может формироваться с использованием различных семантических интерпретаций EDI-элемекгое.

Если XML-схемный файл формируется из EDIFACT MIG-инструкции, то необходимо указывать лишь префикс *D_ a . Поскольку в других ED 1-стандартах должны использоваться иные префиксы, которые будут идентифицировать составные элементы данных и просто элементы данных путем применения цифровых тегов, то префиксы должны быгьобязательными.

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

Рекомендации W3C XML предполагают использование ‘тегов, не требующих пояснений*. Е01(РАСТ)-теги отвечают этим требованиям в большей степени, чем теги, записанные на естественном языке, поскольку для EDI-специалистов они представляют устоявшийся общепонятный смешанный язык из элементов романских, гречвсюго и восточных языков.

<xsd:eiement ref din:D_€345“ minOccurs=’O m maxOccurs='5’A>

din:G_SG25“ minOccurs=’1 m maxOccurs-'IO"/>

При необходимости «разговорные» теги могут формироваться из подходящего комментария. В этом случае EDI-источникдля соответствующего элемента должен документироваться с помощью соответствующего атрибута (см. также 6.9) или любого другого средства документирования.

<xsd:eiement name ='M_ORDERS">

<xsd:e>ement ref din:Currency’ minOccurs-’O’ maxOccurs />

<xsd:extension base s “string1..10">

<xsd:attribute name='EDIPath" type='xsd:string‘ fixed=‘ORDERS.SG2.NAD.C080.3036(0120:040:01) u f>

<!- - The attribute EDIPata contains the reference to the original EDI standard - •>

6.2 Принцип 2: Структура

6.2.1 Одни и те же EDI-теги или имена должны формировать сгруппированные элементы (см. также принцип, описанный в 6.10>.

6.2.2 Если желательно разграничивать различные семантические элементы одного и того же контейнера данных, то для них необходимо использовать различные теги путем добавления суффикса к EDI-тегу или присваивать им различные имена.

Примечание — Споооб. с помощью которого автор описывает MIG-инструкцию, должен отвечать требованиям соответствующего бязнес-процесса. поэтому и схема должна соответствующим образом структурироваться. Если, например. MIG-инструкция содержит ’дату документа" и "запрашиваемую дату поставки" в двух различных экземплярах DTM-сегмэнга. то соответственно должны формироваться и раздельные XML-элеменгы. Кроме того, если они документируются в одном и том же экземпляре DTM-сегмента. то будет формироваться только один XML-элеменг.

Несколько поясняющих примеров для 6.2.1 и 6.2.2:

Вариант 1: Инструкция содержит два ОТМ-сегмента (см. рисунок 1).

Установленный по умолчанию переход в ХМЬсхему в соответствии с 6.2.1 такое:

<xsd:element name =*S_DTM">

<xsd:element ref din:D_23807>

<xsd:element name = H D_2005' type xsd:decimar>

Примечание — Элемент D_2005 принадлежит к перечислимому типу данных и содержит две положительные величины '2 и '4'.

В другом варианте применение принципа 6.2.2 дает следующий результат:

<xsd:element name =’D_2380" type O_23S0_2" type Order_date’ type ="xsd:decimal"/>

Преобразование в XML-схэму аналогично преобразованию, применяемому по умолчанию в соответствии с принципом 6.2.1, т. е.:

<xsd:elerrvent name ='S_D“M'>

<xsd:element ref din:D_23807>

<xsd:elerrvent name ="D_2C05‘ type ="din:D_2005">

<xsd:documentation>Type of date</xsd: docu mentatton>

<xsd:element name =*D_2380 n type ='xsd:dedmal">

Поясняющий пример для 6.2.3:

<xsd:element name 0" maxOccurs='17>

<xsd:etenent ref='D_0010" minOccurs="0" maxOccurs=*1V>

<xsd:elenent ref='D_0017“ minOccurs= n 0" maxOccurs='1*/>

<xsd:etenent ref=’D_0020" minOccurs="0" maxOccurs='1‘/>

<xsd:etenent ref din:C_C5077>

<xsd:element name =‘D_2379" fixed fixed <xsd:element name =*D_2380* type xsd;decimar>

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

6.4 Принцип 4: Состояние

EDI-оостояние и прикладной статус в MIG-инструкции будут объединены eXML-состоянии (с поддержанием больших ограничений).

Состояние "обязательное"будет представляться с помощью минимально повторяющегося индекса "Г. а состояние "условное* — с помощью минимально повторяющегося индекса "0 я . Состояние задается атрибутом minOccurs.

<xsd:ekment ref="din:G_SG7" minOccurs-"0" maxOccurs-"5"/> <xsd:etement ref= "din:S_IMD" minOccurs-'Q" maxOccure

"1"/> <xsd:el*ment ref=‘din:C_C059" minOccurs="0" maxOccurs-"1"f>

<xsd:ebment ref="din:D 4022" minOccurs-"0" maxOccurs-"1’/>

Группа сегментов Сегмент

Составной элемент данных

<xsd:e>ement ref='din:G_UN" rninOccurs=’1 m maxOccurs="10'/> <xsd:e'ement ref= 'din:S_UN" minOccurs="1’ maxOccurs="1’/> Ofsd:etement ref=’din:C_C516" min0ccurs='1' max Occurs*'1‘/>

Состояние 'обязательное': Группа сегментов Сегмент

Составной элемент данных

<xsd:element ref=’din:D 0065" min0ccurs='1‘ maxOccurs="1"/>

6.5 Принцип 5: Максимальное число экземпляров

Число экземпляров MIG-инструкции формирует число XML-экэемоляров. Это значение будет задаваться с помощью XSD-атрибутэ maxOccurs.

Группа <xsd:element ref=’din:G_SG25' minOccurs='1' maxOccurs='10’/>

Сегмент <xsd:element ref=’din:S LIN* minOccurs='1" maxOccurs='1"/>

При использовании версии 4 EDiFACT-синтаксиса (см. ИСО 9735-1) и соответствующих каталогов этот принцип применим и ксоставным элементам данных, и кэлементам данных.

6.6 Принцип 6: Форматы элементов данных

6.6.1 Обозначения "ап" и "а” относятся к формату представления данных "строка", а обозначение "п" — к формату представления данных "десятичный". Для длин буквенно-символьных и цифровых элементов данных, как это определено в MIG-инструкции, будет формироваться соответствующий атрибут slmpleTypes.

6.6.2 Форматы представления даты могут передаваться в XML-типы данных "Pate", "timelnstant” и "time". В этом случае необходимо использовать преобразование форматов, имеющих следующее представление в XML:

date (дата): 1999-05-31 (согласно ИСО 8601)

time (время): 13:20:00

timelnstant (момент времени): 1999-05-31Т13:20:00

<xsd:simpieType пате* 'stringl.. 70“>

<xsd:maxLength value D_6345" type ="D_6345"/>

<xsd:documentation>Devtsche Mark</xsd:documentation> </xsd:annolation>

Работа содержит 1 файл

Эдифакт.doc

Группа сегментов кроме типовых сегментов данных может содержать другие группы сегментов.

Сегменты данных состоят из элементов данных, которые могут быть простыми (аналогом является поле данных) и составными (обычно 2-3 поля данных).

По правилам UN/EDIFACT не предусмотрено использование символов перевода строки и возврата каретки, но для наглядности на каждой строчке расположен отдельный сегмент.

Ниже приведены названия некоторых сегментов:

Каждый из элементов данных занимает свое определенное место в сегменте. Если какой-либо из элементов данных не требуется, то для его пропуска повторяют разделитель элементов данных (в примере - между первым и четвертым элементом расположено три разделителя). Назначение того или иного элемента данных определяется справочником сегментов EDSD, который входит в набор стандартов UN/EDIFACT.

Элементы данных могут быть простыми и составными, состоящими из компонентов. Для составных элементов данных предусмотрен еще один разделитель - в данном случае «двоеточие».

Четвертый элемент данных в вышеприведенном примере, являются составными, части которого разделены символом « : » Последовательность элементов данных в сегменте регламентируется справочником элементов данных и строго определена.

3. Справочники международного стандарта.

Как уже отмечалось выше разработка и сопровождение стандарта UN/EDIFACT в виде двух основных составляющих: системы справочников UNTDED (United Nations Trade Data Elements Directory) и UNTDID (United Nations Trade Data Interchange Directory) осуществляется Центром по упрощению практики и процедур в управлении, торговле и на транспорте CEFACT – (Centre for Facilitation of Practices and Procedures for Administration, Commerce and Transport).

Справочник UNTDED (United Nations Trade Data Elements Directory) - элементов внешнеторговых данных является базовым документом для стандарта EDIFACT. Он был утвержден Международной организацией по стандартизации в 1985 году. Справочник составлен на основе предложений по итогам деятельности Рабочей группы 4 ЕЭК ООН, которая приняла согласованные наборы стандартных элементов данных для различных областей применения. Разделы 1,2,3 и 4 Справочника составляют международный стандарт ISO 7372.

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

№ п/п	Наименование классификатора
1	Наименования и идентификаторы документов
2	Коды стран и валют
3	Классификатор видов транспорта
4	Коды для сокращения "INCOTERMS" (основных базисных условий купли-продажи)
5	Классификатор пунктов LOCOD
6	Классификатор указателей единиц измерения, используемых в международной торговле
7	Классификатор типов перевозки
8	Коды для названий видов упаковки
9	Коды, отобранные из руководства ИАТА СARGO-IMP
10	Коды элементов данных (английская версия UNTDED)

Справочник UNTDID (United Nations Trade Data Interchange Directory) - по электронному обмену торговыми данными содержит общие семантические и синтаксические правила для выполнения функций по передаче стандартных данных и состоит из следующих частей:

1. Единообразных правил поведения в области обмена внешнеторговыми данными с помощью средств связи (UNCID), предназначеных для создания правовой и стандартной основы для пользователей электронной передачи информации (EDIFACT) и других систем электронного обмена торговой информацией (EDI);

Руководящие принципы для составления

Синтаксические правила применения UN/EDIFACT предназначены оказать помощь пользователям EDI при внедрении ISO-UN/EDIFACT синтаксических правил и расширить некоторые правила, содержащиеся в стандарте ISO 9375. Эти правила являются частью комплекта документов, доступных пользователям, каждый из которых дополняет другие.

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

Кодирование и декодирование EDIFACT

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

Разрешите соглашение, сопоставляя квалификатор отправителя & идентификатор и квалификатор получателя.

Примените заголовок набора транзакций и сегменты трейлеров.

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

Замените разделители в полезных данных.

Создание XML-документа для каждого набора транзакций.

Запросите техническое подтверждение, функциональное подтверждение или и то, и другое, если оно настроено.

Проверьте конверт в соответствии с соглашением торгового партнера.

Разрешите соглашение, сопоставляя квалификатор и идентификатор отправителя вместе с квалификатором получателя и идентификатором.

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

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

Проверьте контрольный номер обмена для ранее полученных взаимоизменений.

Проверьте контрольный номер группы по отношению к другим контрольным номерам групп в обмене.

Проверьте контрольный номер набора транзакций для других контрольных номеров набора транзакций в этой группе.

Разделение обмена на наборы транзакций или сохранение всего обмена, например:

Разделение обмена на наборы транзакций — приостановка наборов транзакций при ошибке.

Действие декодирования разделяет обмен на наборы транзакций и анализирует каждый набор транзакций. Действие выводит только те наборы транзакций, которые не прошли проверку badMessages , и выводит оставшиеся наборы транзакций в goodMessages .

Разделение обмена на наборы транзакций — приостановка обмена по ошибке.

Действие декодирования разделяет обмен на наборы транзакций и анализирует каждый набор транзакций. Если один или несколько наборов транзакций в обмене данными не прошли проверку, действие выводит все наборы транзакций в этом обмене badMessages .

Сохранение обмена — приостановка наборов транзакций при ошибке.

Действие декодирования сохраняет обмен и обрабатывает весь пакетный обмен. Действие выводит только те наборы транзакций, которые не прошли проверку badMessages , и выводит оставшиеся наборы транзакций в goodMessages .

Сохранение обмена — приостановка обмена при ошибке.

Действие декодирования сохраняет обмен и обрабатывает весь пакетный обмен. Если один или несколько наборов транзакций в обмене данными не прошли проверку, действие выводит все наборы транзакций в этом обмене badMessages .

Создайте техническое подтверждение, функциональное подтверждение или и то, и другое, если оно настроено.

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

Функциональное подтверждение, которое подтверждает принятие или отклонение полученного обмена или группы.

Справочник по соединителям

Предварительные требования

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

Связан с той же подпиской Azure, что и ресурс приложения логики.

Находится в том же расположении или регионе Azure, что и ресурс приложения логики.

При использовании типа ресурса приложения логики (потребления) и операций EDIFACT ресурсу приложения логики не требуется ссылка на учетную запись интеграции. Однако эта учетная запись по-прежнему необходима для хранения артефактов, таких как партнеры, соглашения и сертификаты, вместе с операциями EDIFACT, X12или AS2 . Учетная запись интеграции по-прежнему должна соответствовать другим требованиям, таким как использование той же подписки Azure и существующей в том же расположении, что и ресурс приложения логики.

При использовании типа ресурса " приложение логики" (стандартный) и операций EDIFACT для рабочего процесса требуется подключение к учетной записи интеграции, созданной непосредственно из рабочего процесса при добавлении операции AS2.

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

Ресурс приложения логики и рабочий процесс, где вы хотите использовать операции EDIFACT.

В портал AzureОткройте ресурс приложения логики и рабочий процесс в конструкторе.

В конструкторе в разделе триггер или действие, в которое необходимо добавить действие EDIFACT, выберите новый шаг.

Под полем поиска Choose an operation (Выберите действие) выберите вкладку Все. В поле поиска введите edifact encode . В этом примере выберите действие с именем Encoded to EDIFACT Message by имя соглашения.

При появлении запроса на создание подключения к учетной записи интеграции укажите следующие сведения.

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

Когда все будет готово, выберите Создать.

После того как операция EDIFACT появится в конструкторе, укажите сведения для следующих свойств, относящихся к этой операции:

- Разделитель элементов данных
- Индикатор выпуска
- Разделитель компонентов
- Разделитель повторений
- Признак конца сегмента
- Суффикс признака конца сегмента
- Десятичный индикатор

В портал AzureОткройте ресурс приложения логики и рабочий процесс в конструкторе.

В конструкторе в разделе триггер или действие, в которое необходимо добавить действие EDIFACT, выберите Вставить новый шаг (знак "плюс"), а затем выберите Добавить действие.

При появлении запроса на создание подключения к учетной записи интеграции укажите следующие сведения.

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

Когда все будет готово, выберите Создать.

После отображения области сведения о EDIFACT в конструкторе введите сведения для следующих свойств:

В портал AzureОткройте ресурс приложения логики и рабочий процесс в конструкторе.

При появлении запроса на создание подключения к учетной записи интеграции укажите следующие сведения.

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

Когда все будет готово, выберите Создать.

- Разделитель компонентов
- Разделитель элементов данных
- Индикатор выпуска
- Разделитель повторений
- Признак конца сегмента
- Суффикс признака конца сегмента
- Десятичный индикатор
- Набор символов полезных данных
- Суффикс признака конца сегмента
- Сохранить обмен
- Приостановить обмен при ошибке

В портал AzureОткройте ресурс приложения логики и рабочий процесс в конструкторе.

При появлении запроса на создание подключения к учетной записи интеграции укажите следующие сведения.

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

Когда все будет готово, выберите Создать.

После отображения области сведения о EDIFACT в конструкторе введите сведения для следующих свойств:

Обработку сегментов UNH 2.5 в документах EDIFACT

Обновите или разверните схему с именем корневого узла UNH 2.5.

Например, предположим, что корневое имя схемы для образца поля UNH имеет значение EFACT_D03B_ORDERS_EAN008 . Для каждого D03B_ORDERS с разными сегментами UNH 2.5 понадобится развернуть отдельную схему.

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

независимо от того, используете ли вы действие декодирования или кодирования EDIFACT, отправьте схему и настройте параметры схемы в Параметры получения соглашения EDIFACT или отправьте Параметры разделы соответственно.

Чтобы изменить соглашение EDIFACT, в области соглашения выберите свое соглашение. На панели инструментов панели соглашения выберите изменить как JSON.

В receiveAgreement разделе соглашения найдите schemaReferences раздел и добавьте значение UNH 2.5.

В sendAgreement разделе соглашения найдите schemaReferences раздел и добавьте значение UNH 2.5.

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

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

Принципы формирования файлов XML схемы (XSD) на основе инструкций по реализации EDI(FACT)

Electronic data interchange for administration, commerce and transport (EDIFACT). Rules for generation of XML scheme files (XSD) on the basis of EDI(FACT) implementation guidelines

Дата введения 2012-09-01

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004* "Стандартизация в Российской Федерации. Основные положения"

Сведения о стандарте

1 ПОДГОТОВЛЕН Научно-техническим центром "ИНТЕК" на основе собственного аутентичного перевода на русский язык международного документа, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 "Стратегический и инновационный менеджмент"

4 Настоящий стандарт идентичен международному документу ИСО/ТС 20625:2002* "Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Принципы формирования файлов XML схемы (XSD) на основе инструкций по реализации EDI(FACT)" (ISO/TS 20625:2002 "Electronic data interchange for administration, commerce and transport (EDIFACT) - Rules for generation of XML scheme files (XSD) on the basis of EDI(FACT) implementation guidelines").

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

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

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

Введение

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

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

Настоящий стандарт не распространяется на описания типов документов (DTDs).

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

В настоящем стандарте использованы нормативные ссылки на следующие международные стандарты* (для датированных ссылок следует использовать только указанное издание, для недатированных ссылок следует использовать последнее издание указанного документа):

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

ИСО 8601:2004 Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени (ISO 8601:2004, Data elements and interchange formats. Information interchange. Representation of dates and times)

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

3 Термины, определения и сокращения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 базовый семантический регистр (basic semantics register; BSR).

3.2 базовая семантическая единица (basic semantic unit; BSU).

3.3 описание типа документа (document type definition; DTD).

3.4 электронный обмен данными (electronic data interchange; EDI).

3.5 электронный обмен данными в управлении, торговле и на транспорте (electronic data interchange for administration, commerce and transport; EDIFACT).

3.6 гипертекстовый язык разметки документов (hyper text mark-up language; HTML).

3.8 стандартный обобщенный язык описания документов (standard generalised mark-up language; SGML).

3.9 расширяемый язык описания связей (extensible link language; XLL).

3.10 расширяемый язык разметки (extensible mark-up language; XML).

3.11 расширяемое определение схемы (extensible schema definition; XSD).

3.12 расширяемый язык таблиц стилей (extensible stylesheet language; XSL).

3.13 www-консорциум (world wide web consortium; W3C).

3.14 элемент (element): Синтаксический структурный блок, содержащий данные и/или атрибуты.

3.15 имя (name): Имя в XML-языке начинается с буквы или допустимого специального символа, далее могут следовать буквы, цифры, дефисы, подчеркивания, двоеточия или точки. Имена, начинающиеся с "xml" или со строки символов, которые примыкают к (('Х'|'х') ('M'|'m') ('L'|'I')), являются резервными для целей XML-стандартизации.

3.16 шаблон (template): Предварительно задаваемая эталонная структура, сравниваемая с полной структурной единицей (или с одной из ее частей), которая должна быть распознана.

3.17 тег, метка (tag): Инструкция по форматированию или семантическая пометка.

4.1 Уровень: MIG

a) Идентификационные данные MIG-инструкции.

b) Идентификационные данные служебного EDIFACT-каталога.

b) Состояние (стандартное или прикладное) используемых сегментов и групп сегментов.

c) Контекстно связанные имена и описания сегментов и групп сегментов.

e) Взаимосвязи между сегментами и группами сегментов.

4.3 Уровень: Сегменты и составные элементы данных

a) Структура сегментов и составных элементов данных, а также указание используемых ими позиций.

b) Состояние (стандартное или прикладное) элементов данных и составных элементов данных.

d) Контекстно связанные имена и описания.

f) Дополнительный текст, комментарии.

4.4 Уровень: Элемент данных

a) Характеристики EDI-элементов данных (тип, длина) и ограничения на их применение, основанные на MIG-инструкциях и контекстно связанном исполнении.

d) Дополнительный текст, комментарии.

e) Допустимые значения.

g) Четко задаваемые пользователем EDIFACT-коды или перечни ISO/UN-кодов.

h) Четко задаваемые пользователем коды.

i) Произвольно задаваемые пользователем EDIFACT-коды или перечни ISO/UN-кодов.

j) Произвольно задаваемые пользователем коды, не содержащиеся в каталоге EDIFACT-кодов.

k) Принципы, которым должны отвечать значения элементов данных.

I) Преобразование в поля в программах и неструктурированных файлах соответственно.

5 Требования к принципам логического вывода схем

a) MIG-техническая информация, перечисленная в разделе 4, при необходимости должна иметь возможность быть встроенной в схемы (структуры).

b) Структура MIG-инструкции более низкого уровня должна быть легкодоступной (XML- и традиционные EDI-инструкции должны быть сопоставимыми по структуре).

d) Существование варианта, определенного с помощью настоящего стандарта как обязательного, при котором семантические данные могут представляться в ХМL-виде.

6 Принципы формирования XML-схем, отбираемых из EDI MIG-инструкций

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

Читайте также: