Мониторинг обменных курсов валют
18c0693f

Одноступенчатое формирование XML-документа


Развитие новых тенденций объединения технологий XML и EDI обеспечивает динамичный процесс формирования электронных документов и взаимодействия между информационными системами. Тенденция объединения XML и EDI является наиболее перспективным направлениям в использование электронных документов.

Рис. 1

На рис.1 представлена схема вариантов обмена Электронными документами для разных (мелких и крупных) компаний. Крупные компании продолжают использовать уже имеющие EDI-системы через VAN сеть (сеть с добавленной стоимостью, т.е. предоставление за плату добавочных услуг). Провайдеры предоставляют такую услугу, как подготовка и обмен EDI-сообщениями по средствам корпоративных сетей. Более мелкие компании, используя технологию XML/EDI осуществляют обмен через Internet.

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

Рис. 2

На рис.2 представлена схема формирования XML документа на клиентской стороне. В ходе начала обмена, клиент принимает от XML сервера шаблон (формально назовем XML шаблон). Текст простого шаблона на примере XML документа "инвойс" может иметь следующий вид:

<?xml version="1.0"> <!DOCTYPE InvoiceForm > <?xml-stylesheet type="text/xsl" server-config="Config.xml" href=" InvoiceForm.xsl" ?>

<Transaction id="768765324"> <ItemQuantity>3</ItemQuantity> </Transaction>

Элемент <Transaction> включает атрибут id, указывающий номер транзакции имеющий значение "768765324". Элемент <ItemQuantity> описывает количество "пунктов" инвойса, т.е. количество наименований перевозимого товара. Далее, используя язык описания стилей XSL, генерируется HTML форма, которая заполняется данными об отправителе и получателе груза, а также о самом грузе.


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



Рис. 3

Упрощенный вид генерируемой HTML формы представлен на рис. 3. После инициации события OnClick кнопки "Передача" (SUBMIT) происходит генерация следующего XML документа:

<?xml version="1.0"> <!DOCTYPE Invoice> <Transaction id="768765324"> <InvoiceNum>12345<InvoiceNum> <!-- номер инвойса --> <DataSend>20000105</DataSend> <!-- YYYYMMDD 5/01/2000 -->

<Consignor> <ConsignorName>OY Valio</ConsignorName> <!-- Отправитель --> <Address> <!-- Адрес --> <City>Helsinki</City> <Street/> <Zip>Box 789</Zip> <Country>FI</Country> </Address> </Consignor> <Consignee> <!-- Получатель --> <ConsigneeName>АО Северная столица</ConsigneeName> <Address> <City>Санкт-Петербург</City> <Street>Невский 176</Street> <Zip>194376</Zip> <Country>RU</Country> </Address> </Consignor>

<Goods> <!-- Описание товаров --> <Item id=1> <!-- Первая позиция --> <Name>Сыр</Name> <!-- Наименование товара --> <Qulity>200</Qulity> <!-- кол-во --> <TypeEQU>AAI</TypeEQU> <!-- тип измерения AAI - по весу --> <Price>300</ Price> <!-- Цена за ед. --> <Currently>FIM</Currently> <!-- тип используемой валюты --> </Item> <Item id=2> <!-- Вторая позиция --> <Name>Масло</Name> <Qulity>150</Qulity> <TypeEQU>AAU</TypeEQU> <!-- тип измерения AAU - упаковки--> <Price>500</ Price> <Currently>FIM</Currently> </Item> <Item id=2> <!-- Третья позиция --> <Name>Варенье</Name> <Qulity>100</Qulity> <TypeEQU>AAU</TypeEQU> <Price>180</ Price> <Currently>FIM</Currently> </Item>



</Goods> </Transaction>

Данный документ принимается XML сервером, который генерирует следующее EDI - сообщение:

UNH+768765324+INVOIC:D:96A:UN:EAN002'

BGM+380+12345+9+NA'

DTM+3:20000105:102'

NAD+SE+++OY Valio++Helsinki++Box 789+Fi'

NAD+By+++АО Северная столица ++Saint-Peterburg+Невский 176 + +RU' 		Заголовок Сообщения

Номер транзакции 768765324

Номер инвойса 12345

Дата выдачи 5.01.2000

Поставщик Valio

Адр: Helsinki Box 789 FI

Получатель "АО Северная столица" Адр: С-Петербург Пр. Невский 176 Россия
LIN+1'

IMD+F+011+:::Сыр'

MEA+AAI'

QTY+92:200'

PRI+INV:300'

CUX+2:USD' 		Первая позиция

Наим. Сыр

Ед.изм- кг

Кол-во 200 кг

Цена 300 за кг

Валюта - USD
LIN+2'

IMD+F+011+:::Масло'

MEA+AAU'

QTY+92:150'

PRI+INV:500'

CUX+2:USD' 		Вторая позиция

Наим. Масло

Ед.изм- упак

Кол-во 150 упак

Цена за упак - 500

Валюта - USD
LIN+3'

IMD+F+011+:::Варенье'

MEA+AAU'

QTY+92:100'

PRI+INV:180'

CUX+2:USD' 		Третья позиция

Наим. Варенье

Ед.изм- упак

Кол-во 100 упак

Цена 180 за упак

Валюта - USD
UNS+S'

CNT+4:3'

UNT+26+12345'		 Контрольная секция

Общее кол-во позиций- 3

Кол-во сегментов - 26 и Номер сообщения - 12345
Особой задачей для семантической проверки и разбора XML документа и формирования EDIFACT сообщения является разработка Таблицы определения данных - DTD. При разработке DTD, учитывая иерархическую структуру EDIFACT сообщения, разрабатывается объектная модель документа - DOM. На рис 3 представлена иерархическая схема сообщения INVOICE.

В рассматриваемом EDIFACT сообщении INVOICE можно выделить сегменты и сопоставить их с объектами ELEMENT объектной модели. В левой части таблицы представлены DOM элементы, а в правой соответствующие им сегменты или части сегментов. Значок # указывает, что в данном месте должно находится значение из соответствующего элемента DOM.



Корневой элемент

Name= "Transaction"

Attr "id = #"		 Сегмент UNH

UNH +#+INVOIC:D:96A:UN:EAN002'
Элементы:

Name ="InvoiceNum"

Value = # 		Сегмент BGM

BGM+380+#+9+NA'
Name ="Consignor "Сегмент NAD

NAD+SE+++#01++#02'
Дочерние элементы "Consignor "

Name = "ConsignorName"

Value = #01

Name ="Addsress"

Value = #02
Name ="Consignee "

Дочерние элементы "Consignee "

Name ="ConsigneeName "

Value = #01

Name ="Addsress"

Value = #02 		NAD+BY+++#01++#02'
Name ="Addsress"

Дочерние элементы "Addsress"

Name ="City "

Value = #01

Name ="Street"

Value = #02

Name ="Zip"

Value= #03

Name ="Country"

Value= #04 		Часть Сегмента NAD

#01+#02+#03+#04
Name ="Goods"

Дочерние элементы "Goods"

Name ="Item " 		Идентификатор группы сегментов:

LIN-IMD-QTY-MEA-PTI-CUX
Name ="Item"

Attr "id = #"

Дочерние элементы "Item"

Name ="Name"

Name ="Qulity"

Name ="TypeEQU"

Name ="Price "

Name ="TypeCur"

 Сегмент LIN

LIN+#'
Name ="Name"
Value = #		Сегмент IMD
IMD+F+011+:::#'
Name ="Qulity"
Value = #		Сегмент QTY
QTY+92:#'
Name ="TypeEQU "
Value= #		Сегмент MEA
MEA+#'
Name ="Price"
Value= #		Сегмент PRI
PRI+INV:#'
Name ="TypeCur"
Value= #		Сегмент CUX
CUX+2:#'
<


Интерпретация содержания сегмента осуществляется следующим образом: значение тага <InvoiceNum> из текста нашего XML документа ( <InvoiceNum>12345<InvoiceNum> ) будет преобразовано в BGM+380+12345+9+NA', что соответствует записи в левой части таблицы объкта Element ( Name ="InvoiceNum" Value = # ) и BGM+380+#+9+NA' в правой. Если какой либо сегмент содержит информацию из нескольких родственных (Sublin) тагов, то указывается номер вхождения:

Пример: Сегмент NAD содержит информацию из элемента "ConsigneeName" - вхождение #01 и элемента "Addsress" - вхождение #02:



Соответственно информация из элемента "Addsress" извлекается из дочерних элементов ( "City ", "Street" и "Country"), которые имеют свою часть вхождения в сегмент NAD:



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

Так для тага <InvoiceNum> атрибутом является:

EDI-Prefics - "BGM+380+"

EDI-Suffics - "+9+NA' ".

Для тегов, которые используют информацию при вводе из поля данных, используются атрибуты Title и Size.

Ниже представлена часть таблицы определения данных, которая иллюстрирует основы построения DTD для XML/EDI.

<!DOCTYPE Invoice [ <!ENTITY InvoiceNum (#PCDATA) > <!ATTLIST InvoiceNum EDI-Prefics CDATA #FIXED "BGM+380+" EDI-Suffics CDATA #FIXED "+9+NA'" Title CDATA"INVOICE" Size NUMBER #FIXED "8" >

<!ENTITY Consignor (ConsignorName, Address) > <!ATTLIST Consignor EDI-Prefics CDATA #FIXED "NAD+SE+++" EDI-Suffics CDATA "#FIXED "'" Title CDATA #FIXED "" Size NUMBER #FIXED "30" >



<!ENTITY ConsignorName (#PCDATA) > <!ATTLIST ConsignorName EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA "#FIXED "++" Title CDATA #FIXED ""Отправитель" Size NUMBER #FIXED "30" >

<!ENTITY Consignee (ConsigneeName, Address) > <!ATTLIST Consignee EDI-Prefics CDATA #FIXED "NAD+BY+++" EDI-Suffics CDATA "#FIXED "'" Title CDATA #FIXED "" Size NUMBER #FIXED "0" >

<!ENTITY ConsigneeName (#PCDATA) > <!ATTLIST ConsigneeName EDI-Prefics CDATA #FIXED "Отправитель " EDI-Suffics CDATA #FIXED "++" Title CDATA #FIXED "Получатель" Size NUMBER #FIXED "30" >

<!ENTITY Address (Street?,City,ZIP?,Country) > <!ATTLIST Address EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA #FIXED "'" Title CDATA #FIXED "Адрес" Size NUMBER #FIXED "30" >

<!ENTITY Street (#PCDATA) > <!ATTLIST Street EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA #FIXED "+'" Title CDATA #FIXED "Улица" Size NUMBER #FIXED "30" >

<!ENTITY City (#PCDATA) > <!ATTLIST City EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA #FIXED "+'" Title CDATA #FIXED "Город" Size NUMBER #FIXED "30" >

<!ENTITY Zip (#PCDATA) > <!ATTLIST Zip EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA #FIXED "+'" Title CDATA #FIXED "Индекс" Size NUMBER #FIXED "6" >

<!ENTITY Country (#PCDATA) > <!ATTLIST Country EDI-Prefics CDATA #FIXED "" EDI-Suffics CDATA #FIXED "" Title CDATA #FIXED "Страна" Size NUMBER #FIXED "3" > ]>

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




Самый выгодный курс обмена валюты