Оглавление
- Введение.
- История.
- Терминология.
- Документ (document или transaction set).
- Функциональная группа (Functional Group).
- Interchange.
- Конверт (Envelope).
- Сегмент.
- Опциональность сегментов.
- Порядок следования сегментов.
- Повторение сегментов.
- Элемент.
- Типы данных.
- Опциональность элементов.
- Структура EDI документа.
- Конверты (envelopes).
- Header (заголовок), Details (детали) и Summary (итог).
- Использование EDI в реальном документообороте.
Введение.
В данной статье представлено описание стандарта EDI ANSI ASC X12. Статья предназначена для начинающих специалистов, которые только начинают работать с электронным документооборотом в формате EDI ANSI ASC X12, но, возможно, будет интересна и профессионалам, которые уже имеют опыт работы в данной области.
В начале статьи даются общие термины (Interchange, функциональная группа, документ), детальное описание основных составляющих EDI документа (сегментов, элементов) и связь между ними. Затем описывается, как из этих составляющих формируются документы, детально разбирается их иерархическая структура. В конце статьи коротко описывается, как используется EDI в условиях реального электронного документооборота.
История.
Электронный документооборот EDI (Electronic Data Interchange) - обмен между компьютерами структурированной информацией по взаимосогласованным правилам.
Впервые EDI начал применяться в середине 60х годов в сфере железнодорожных и автомобильных перевозок. В 1968 году был организован комитет United States Transportation Data Coordinating Committee (TDCC) для работ над стандартом электронного документооборота для данной индустрии. В дальнейшем работой по расширению и усовершенствованию стандарта стал заниматься American National Standards Institute (ANSI).
Стандарт электронного обмена документами ANSI ASC X12 (American National Standards Institute Accredited Standards Committee X12) был разработан в 70-х годах, когда был важен малый размер электронного документа (для модемов со скоростями 300-1200 бит в секунду) и каждый байт должен был нести максимум информации. Таким образом, от «читаемости» электронного документа отказались в пользу «плотности информации». В то время коммуникации между компаниями были далеки от идеала, и нередки были случаи «обрыва» линии и потери данных. Поэтому формат электронных документов разрабатывался в том числе с целью сохранения целостности данных, для чего были использованы механизм «конвертов» (envelopes) и контрольные числа, которые позволяли проверять, что переданные данные небыли нарушены или потеряны.
Стандарт EDI можно определить как набор правил, определяющих структуру и формат EDI документа.
Существует несколько организаций, которые в данный момент работают над стандартами EDI:
- ANSI (American National Standards Institute) - это Институт, который устанавливает стандарты для многих видов деятельности. EDI занимается Комитет ANSI X12 - главная организация США по стандартизации EDI.
- EDIA (The Electronic Data Interchange Association, раннее известная как Transportation Data Coordinating Committee (TDCC))
- AIAG (The Automotive Industry Action Group) - группа стандартов для автомобильной промышленности. Данный стандарт является подгруппой стандартов ANSI X12.
- UCS (The Uniform Communications Standard) стандарт, используемый для бакалейной индустрии.
- EDIFACT (Electronic Data Interchange for Administration, Commerce, and Transport.) - Организация, занимающаяся стандартизацией EDI при Совете по Экономике и Социальной политике ООН. Стандарты EDIFACT, в отличии от ANSI X12, используются в основном в Европе, в то время как X12 - в Америке.
- ODETTE (The Organization for Data Exchange by Tele-Transmission in Europe.)
- VICS (The Voluntary Inter-industry Communication Standards) - организация, которая является подгруппой ANSI X12 и занимается стандартами для индустрии розничной торговли.
Стандарт EDI ANSI ASC X12 (далее - просто X12) включает в себя описание форматов документов (наборов транзакций - transaction sets) и имеет различные версии (связанные с развитием стандартов) - 4030VICS, 5010 и т.д.
Терминология.
Документ (document или transaction set).
Стандарт X12 оперирует понятием «документ» (document), или «набор транзакции» (transaction set). Документ - это набор данных, представляющих в совокупности законченную информацию, ценную для сторон, участвующих в документообороте.
Transaction set в большинстве случаев - это обычный документ, который компании используют в своей работе - например Invoice (счет) или Purchase Order (ордер заказа).
Функциональная группа (Functional Group).
Функциональная группа - это группа (набор) одинаковых по типу документов (ордеров, инвойсов и т.д.), которые входят в Interchange. Структура EDI будет описана дальше, но пока просто отметим, что начало и конец функциональной группы определяются сегментами GS/GE (GS/GE Envelope). Тип функциональной группы определяется элементом GS-01 (например, функциональная группа PO содержит ордера заказов - Purchase Orders, функциональная группа IN - инвойсы). Сегмент GS так же иногда служит для маршрутизации документов между подразделениями партнера-получателя документов.
Interchange.
Interchange это структурированный (согласно правилам, определяемым стандартом X12) набор данных, которым обмениваются партнеры по (электронному) документообороту.
Interchange - это больше, чем просто документ, скорее это пакет групп документов (хотя interchange может содержать всего одну группу с одним документом).
В дальнейшем я буду использовать термин «EDI документ» если речь идет об Interchange и просто «документ» если речь идет об отдельном документе (transaction set) из этого Interchange.
Можно изобразить структуру Interchange таким образом (позже мы разберем составляющие части и структуру более подробно):
рис 1.
Interchange начинается сегментом ISA и заканчивается сегментом IEA (ISA/IEA Envelope). ISA сегмент используется в том числе для маршрутизации документа между партнерами, участвующими в документообороте.
X12 определяет каждый EDI документ как набор сегментов и элементов, которые определяют этот документ, утверждает порядок следования сегментов в документе, порядок следования элементов в сегменте и отношения между сегментами и/или элементами.
В X12 каждому специфичному документу, например инвойсу (invoice), ордеру заказа (PO, purchase order) соответствует специальное имя - трехзначный номер-идентификатор. Например, invoice это 880, PO - 850, Ship Notice/Manifest - 856 и т.д. С полным набором можно ознакомиться, например, по адресу http://www.123edi.com/x12-asc.asp
Как выглядит EDI документ (пример):
ISA*00* *00* *ZZ*A1STORES *ZZ*LEXINGTON *020115*0900*U*00400*000000005*0*T*>~ GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~ ST*850*50001~ BEG*00*SA*ASNTESTORD**20060615~ PER*BD*DON SMITH~ PER*DC**TE*(123) 456-7890~ FOB*PP~ DTM*002*20060625~ DTM*010*20060618~ N1*ST*A1 STORES*93*0655~ N3*142 WAGON DRIVE~ N4*MIDDLETOWN*AR*72222~ N1*BT*A1 STORES*93*0655~ N3*75 CROSS ROAD~ N4*MIDDLETOWN*AR*72222~ PO1*001002003*10*EA*15**BP*123456411~ PID*A****ADIDAS BLUE T-SHIRT~ ITA*A***CC***1000~ PO1*002003004*20*EA*20**BP*123456817~ PID*A****NIKE RED T-SHIRT~ ITA*A***CC***1500~ PO1*003004005*10*EA*10**BP*123456908~ PID*A****PUMA WHITE T-SHIRT~ ITA*A***CC***1200~ PO1*004005006*10*EA*15**BP*123456321~ PID*A****REEBOK T-SHIRT~ ITA*C***CB***1400~ PO1*005006007*10*EA*20**BP*123456287~ PID*A****UMBRO UEFA CUP T-SHIRT~ ITA*A***CC***1600~ PO1*006007008*20*EA*1**BP*123456413~ PID*A****DEMIX BLUE T-SHIRT~ ITA*A***CC***1800~ CTT*6~ SE*33*50001~ GE*1*5~ IEA*1*000000005~
Следует отметить, что в данном примере переносы строк между сегментами поставлены специально, чтобы можно было легче "увидеть" структуру данных. На самом деле, переносы строк не используются (либо игнорируются) и данный EDI документ в оригинале должен был бы выглядять так, в виде "одной строки":
Однако в дальнейшем для удобства я буду отделять сегменты друг от друга переносом строки.
Вернемся к примеру EDI документа. По сегменту GS, который идет вторым, можно определить, что это EDI документ стандарта X12 (X), версия 4010 (004010). По сегменту ST можно сказать, что это 850 документ, или Purchase Order (ордер заказа). По остальному содержанию можно определить, что речь идет о заказе футболок различных фирм, узнать их цену и количество. О том, как читать документы будет рассказано дальше, но пока вы можете сами попытаться «понять» данный пример.
Конверт (Envelope).
Чтобы нагляднее представить структуру EDI документа, можно провести аналогию между ним и обычными бумажными документами, которые запечатаны в конверты (envelopes).
Самый верхний конверт (ISA/IEA Envelope) содержит внутри себя один или более конвертов (GS/GE Envelopes), в которых содержатся непосредственно сами документы, каждый в отдельном конверте (ST/SE Envelopes).
На конверте ISA/IEA «написаны» адреса компании-получателя и компании-отправителя.
На конверте GS/GE «написан» тип документов, которые в нем находятся. В таком конверте содержатся только документы одного типа - ордера, инвойсы и т.д. Так же на этом конверте может быть «написано», в какое подразделение компании-получателя направлены конечные документы.
Наконец самые последние конверты содержат непосредственно конечные документы - например, ордера заказа номер 000000123 и 000000124.
Можно изобразить структуру EDI-документа для наглядности так:
ISA <<< «верхний» конверт
GS <<< «внутренний» конверт, содержит документы одного типа
ST <<< конверт с документом
<документ 1> <<< непосредственно сам документ
SE
...
ST
<документ X>
SE
GE
... GS
ST
<документ 1>
SE
...
ST
<документ Y>
SE
GE
IEA
GS <<< «внутренний» конверт, содержит документы одного типа
ST <<< конверт с документом
<документ 1> <<< непосредственно сам документ
SE
...
ST
<документ X>
SE
GE
... GS
ST
<документ 1>
SE
...
ST
<документ Y>
SE
GE
IEA
Наш пример:
ISA*00* *00* *ZZ*A1STORES *ZZ*LEXINGTON *020115*0900*U*00400*000000005*0*T*>~
GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~
ST*850*50001~
BEG*00*SA*ASNTESTORD**20060615~
...
CTT*6~
SE*33*50001~
GE*1*5~
IEA*1*000000005~
GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~
ST*850*50001~
BEG*00*SA*ASNTESTORD**20060615~
...
CTT*6~
SE*33*50001~
GE*1*5~
IEA*1*000000005~
Сегмент.
Сегмент (segment) - комбинация связанных элементов или составных данных, которые сгруппированы для предоставления полезной информации. Например, сегмент может содержать информацию о товаре, его цвете, весе, размере, объеме и т.д. Сегмент может присутствовать в документе единожды, или встречаться несколько раз.
рис 2.
В X12 на первом месте всегда идет уникальный идентификатор сегмента (tag), состоящий (как правило) из 2-3 букв/цифр.
Пример сегмента:
PO1*002003004*20*EA*20**BP*123456817~
Сегмент состоит из идентификатора (tag) и элементов, разделенных специальными символами (element separator) - в нашем примере это «звездочка» (asterisk) - «*». Заканчиваются сегменты другим символом (segment terminator) - в нашем примере тильдой «~». Следует отметить, что разделители элементов и сегментов могут отличаться от данного примера.
рис 3.
Стандарт определяет, в каком порядке идут элементы в сегменте.
В примере выше представлен сегмент стандарта X12 с именем PO1, который имеет значение Baseline Item Data (Базовые данные товара). Рассмотрим его подробнее.
В начале идет идентификатор сегмента (PO1), затем идут элементы сегмента:
- Assigned Identificator (002003004, присвоенный идентификатор)
- Quantity Ordered (20, количество заказанных экземпляров товара)
- Unit/Basis Measurement Code (EA = Each, единица измерения количества товара)
- Unit Price (20, стоимость товара)
- элемент пропущен (!) (пропущен Basis Unit Price Code - код, идентифицирующий тип цены единицы товара)
- Product/Service Id Qualifier (BP = Buyer's Part Number, тип идентификатора товара/услуги)
- Product/Service Id (123456817, идентификатор товара/услуги)
Итак, данный сегмент «говорит» получателю - «в позиции 002003004 в нашем ордере заказа мы запрашиваем 20 единиц товара, который в нашей базе находится под идентификатором 123456817, по 20 долларов за единицу».
Опциональность сегментов.
Сегменты в документе имеют два типа опциональности:
M (mandatory) - обязательный сегмент. Обычно такие сегменты несут основную информацию в документе (без него документ или другие, зависимые сегменты, не могут быть поняты полностью и/или правильно). Если стандарт для данного документа определяет сегмент как обязательный, то он не может быть пропущен в документе. Примеры обязательных сегментов:
BEG*00*SA*ASNTESTORD**20060615~
Это (BEG) сегмент заголовка (см ниже, пункт Структура документа). Он содержит общую информацию документа (как «читать» сегменты - см. ниже):
- назначение (00 - Original)
- тип (SA - Stand-alone Order)
- номер ордера (ASNTESTORD)
- (20060615 - 6 Июня 2006)
Без этого сегмента нельзя было бы идентифицировать данный ордер.
PO1*001002003*10*EA*15**BP*123456411~
Это (PO1) сегмент деталей (см. ниже, пункт Структура документа). Он содержит базовые данные товара. Ордер заказа (PO) используется для заказа товара, и данные о товаре очевидным образом - основные данные этого документа, поэтому данный сегмент так же является обязательным.
O (optional) - необязательный, опциональный сегмент. Обычно это сегменты, содержащие второстепенную/вспомогательную информацию. Если стандарт определяет сегмент в документе как опциональный, то он может как присутствовать, так и отсутствовать, и при этом отсутствие опционального сегмента не будет являться ошибкой. Пример опционального сегмента:
PER*DC**TE*(123) 456-7890~
Это (PER) сегмент Administrative Communications Contact, т.е. «контактная информация». Он содержит следующую информацию (как «читать» сегменты - см. ниже):
- контактное лицо по вопросам доставки (DC - Delivery Contact)
- телефон (TE - Telephone)
- собственно сам номер телефона - (123) 456-7890
Данная информация является опциональной, без нее данный документ может быть прочитан - что заказано, количество, стоимость и т.д.
Порядок следования сегментов.
В документе сегменты идут друг за другом в порядке, определенном стандартом.
Повторение сегментов.
Как вы могли заметить, в примере документа некоторые сегменты повторяются. Некоторые из них идут сразу друг за другом (DTM, PER), некоторые повторяются в составе групп (PO1/PID/ITA и N1/(N2)/N3/N4). Существует два типа «повторения» сегментов:
Возможность многократного использования сегмента.
В данном случае сегмент может повториться несколько раз, но при этом каждый сегмент имеет различное значение, т.е. несет разную информацию (сходную по смыслу, но разную по содержанию). Например, два DTM сегмента в примере документа определяют даты, но первый из них (DTM*002*20060625~) определяет дату поставки, а второй (DTM*010*20060618~) - дату погрузки. Аналогично PER сегменты - каждый определяет контактную информацию, при этом первый (PER*BD*DON SMITH~) определяет имя или название покупателя, а второй (PER*DC**TE*(123) 456-7890~) - телефон контактного лица по вопросам доставки. В документе для печати (который используется людьми) это могло бы выглядеть так:
Отдел продаж: +7 812 765 4321
Отдел доставки:+7 812 123 4567
Склад:+7 812 321 7654
Отдел доставки:
Склад:
Следует отметить, что часто уникальность сегмента заключается в использовании различных значений элемента (одного или иногда больше) идентификатора. В большинстве случаев в сегменте есть специальный элемент, который идентифицирует содержание сегмента. В сегменте DTM это, например, элемент DTM-01, в сегменте PER - PER-01.
Стандарт определяет максимально возможное количество таких повторений (max use).
Пример:
рис 4.
Циклическое повторение данных (Loops).
Циклическая группа сегментов (loop) - это набор связанных друг с другом сегментов, которые повторяются в EDI документе в определенной последовательности. Например, группа сегментов N1/N2/N3/N4 представляет информацию об адресе, причем N1 несет информацию об этом адресе, N3 - непосредственно сам адрес, и N4 - географическое расположение.
N1*ST*A1 STORES*93*0655~
N3*142 WAGON DRIVE~
N4*MIDDLETOWN*AR*72222~
N3*142 WAGON DRIVE~
N4*MIDDLETOWN*AR*72222~
N1*BT*A1 STORES*93*0655~
N3*75 CROSS ROAD~
N4*MIDDLETOWN*AR*72222~
Группа PO1/PID/ITA несет информацию о заказанном товаре, его цене и количестве (PO1), описание этого товара (PID) и скидке/наценке (ITA).
PO1*001002003*10*EA*15**BP*123456411~
PID*A****ADIDAS BLUE T-SHIRT~
ITA*A***CC***1000~
PID*A****ADIDAS BLUE T-SHIRT~
ITA*A***CC***1000~
PO1*002003004*20*EA*20**BP*123456817~
PID*A****NIKE RED T-SHIRT~
ITA*A***CC***1500~
Такие циклические группы в свою очередь могут включать в себя другие циклические группы.
Пример:
рис 5.
X12 определяет два типа циклических повторений (loops) - связанные (Bounded) и несвязанные (Unbounded).
Несвязанные повторения имеют стартовый сегмент, который определяет всю группу. «Внутри» этой группы находятся остальные сегменты, их опциональность определяется, как указано выше, однако эти «дочерние» сегменты группы не могут существовать отдельно от стартового сегмента. В нашем примере PO1/PID/ITA сегменты PID и ITA не могут присутствовать в документе, если им не предшествует сегмент PO1. Может быть ситуация когда либо сегмент PID, либо сегмент ITA отсутствуют в группе (так как они опциональны), но ситуации когда PID и/или ITA присутствуют но нет сегмента PO1 быть не может. Это верно, даже если сама группа является опциональной. Следующая группа определяется стартовым сегментом, например N1/N2/N3/N4/N1/N2/N3/N4/N1/N2/N3/N4/… (стартовый сегмент - N1) или PO1/PID/ITA/PO1/PID/ITA/PO1/PID/ITA/PO1/PID/ITA… (стартовый сегмент - PO1) - тоесть, если в документе появляется стартовый сегмент, то он указывает на очередную группу.
Связанные повторения очень похожи на несвязанные, однако имеют отличие - такие группы сегментов ограничены «сверху» и «снизу» специальными сегментами - LS (Loop Start) и LE (Loop End). Такой подход используется стандартом, когда может быть невозможно определение начала и конца группы. В таких случаях начало и конец группы определяется не по стартовому сегменту собственно самой и следующей групп, а специальными сегментами LS и LE соответственно.
Как и в предыдущем случае, стандарт указывает максимальное количество повторений (Max Use) групп сегментов.
Элемент.
Элемент (element) сегмента - это «квант» информации, содержащейся в сегменте. В описании сегмента, сделанном выше, понятно, как сегмент состоит из элементов.
рис 6.
Следует отметить, что элемент вне сегмента не имеет смысла.
Элементы в сегменте имеют свой «адрес», который состоит из имени сегмента и позиции элемента в данном сегменте. Обычно обозначается как
<ИМЯ СЕГМЕНТА>-<ПОЗИЦИЯ>
Или
<ИМЯ СЕГМЕНТА><ПОЗИЦИЯ>
Например, PO101 или PO1-01 для первого (01) элемента в сегменте PO1.
<ИМЯ СЕГМЕНТА>-<ПОЗИЦИЯ>
Или
<ИМЯ СЕГМЕНТА><ПОЗИЦИЯ>
Например, PO101 или PO1-01 для первого (01) элемента в сегменте PO1.
Типы данных.
В стандарте X12 определяются такие типы данных, которые может содержать элемент:
AN (Alpha-Numeric) - строка, которая может содержать буквы, цифры, знаки препинания. Это может быть произвольная строка, например имя товара или название улицы на которую нужно доставить товар, и т.д. Примеры: «БАТОН НАРЕЗНОЙ, 1-ГО СОРТА», «САНКТ-ПЕТЕРБУРГ».
Для этого типа данных так же накладывается ограничение на длину строки, например 1/20 - от 1 до 20 символов, 2/2 - ровно 2 символа и т.д.
R (Real) - дробное число. Данный тип данных используется для информации о цене, весе продукта, расстоянии, размере скидки и т.д. Примеры: 1.23; 75.99. Начиная с версии 4010 поддерживается экспоненциальная нотация.
N[X] (Number) - специальный формат числа. [X] определяет, сколько знаков справа надо «отступить» чтобы поставить запятую. Например, для типа данных N2 для обозначения числа 1,23 значением элемента будет 123, а для 10,5 - 1050 (тоесть чтобы получить нужное значение мы берем значение элемента и делим его на 102). N0 соответствует целому числу, тоесть его значение остается как есть.
ID (Identity) - идентификатор. Об этом типе данных следует рассказать подробнее. Простейший пример идентификаторов из реальной жизни - это единицы измерения, например «ММ» (миллиметр), «СМ» (сантиметр), «РУБ» (рубль) и т.д. В X12 все идентификаторы собраны в логические группы (классификаторы), и этим группам присвоены уникальные идентификаторы - номера. Классификатор состоит из нескольких значений, и каждое значение имеет свое уникальное имя (обычно, 2-3 буквы и цифры) и расшифровку (определение).
Примеры классификаторов - единицы веса, типы валют, коды стран.
Рассмотрим, например, классификатор (группу идентификаторов) номер 90
| 90 Measurement Unit Qualifier Единицы Измерения | |
| TYPE=ID MIN=1 MAX=1 Тип - идентификатор, длина имени MIN = 1, MAX = 1 | |
| Code specifying the linear dimensional unit Код, определяющий единицу линейного размера | |
| CODE | DEFINITION & EXPLANATION |
| C | Centimeters |
| E | Feet |
| N | Inches |
| X | Meters |
Становится понятно, что если элемент сегмента у нас имеет тип ID из классификатора 90, то речь идет о длине. И если значение этого элемента, например, «N», то длина определяется в дюймах (inches).
Особо отмечу, что если элемент имеет тип данных ID, то его значение может принадлежать только одному классификатору, определенному стандартом для этого элемента в данном сегменте. Иначе говоря, не может быть ситуации, когда элемент типа ID может быть единицей измерения массы (например, классификатор 188 Weight Unit Code) и в то же время - единицей измерения длины (например, классификатор 90 Measurement Unit Qualifier).
Так же часто в классификаторе существует специальное значение - «Z», «ZZ» или «ZZZ» в зависимости от ограничений по длине значения идентификатора. Это имя имеет расшифровку (определение) «Mutually Defined» (взаимно определенное), и используется для обозначения единиц, отсутствующих в стандарте для данного классификатора, о которых участники документооборота договорились заранее. Компании, которые обмениваются документами, когда встречают подобное значение идентификатора, в большинстве случаев знают, о чем идет речь - это могут быть «(33) попугая» или «(10) спичечных коробков».
Для этого типа данных так же накладывается ограничение на длину строки, например 3/3 - от 3 до 3 символов, или (проще говоря) 3 символа ровно. Данное ограничение исходит не от стандарта сегмента документа, а от типа используемого классификатора (если классификатор 90 определяет ограничение на длину значения как 1/1, то элемент-идентификатор который использует этот классификатор, так же будет иметь ограничение на длину 1/1).
Существуют специальные справочники (например, http://www.x12.org/x12org/subcommittees/dev/pdf/V5_x123.pdf), по которым можно определить набор значений данного классификатора или по значению элемента и номеру классификатора найти определение этого значения.
DT (Date) - дата. Этот тип данных предназначен для хранения значения даты и имеет формат YYMMDD (начиная с версии 4010 - CCYYMMDD). Примеры: 20060625 (25 Июня 2006).
TM (Time) - время. Этот тип данных предназначен для хранения значения времени и имеет формат HHMM. Примеры: 1259 (12:59). Так же может включать секунды (опционально).
B (Binary) - бинарные данные, последовательность 8-ми битных байтов.
<composite> - композитный элемент. Это элемент, который содержит сразу несколько значений, разделенных специальным символом (этот символ указывается в сегменте ISA, элемент ISA-16). Примеры: 12345.67>12.55 (в данном примере разделителем является ">"). Элементы, из которых состоит композитный элемент, называются так же компонентами (component data element) или суб-элементами (sub-element).
Опциональность элементов.
Элементы сегмента имеют три типа опциональности:
M (mandatory) - обязательный элемент. Обычно обязательными элементами являются те, которые несут основную информацию сегмента. Например, в сегменте DTM (Date/Time Reference, описывает дату и/или время) элемент DTM-01 (Date/Time Qualifier, тип Даты и/или времени) обязателен, так как без него мы не могли бы определить, что именно это за дата. В нашем примере
DTM*002*20060625~
DTM*010*20060618~
DTM*010*20060618~
Элементы DTM-01 имеют значения 002 и 010. Тип данных DTM-01 - ID, классификатор - 374 (Date/Time Qualifier, Code specifying type of date or time, or both date and time). По справочнику находим значения для 002 и 010:
002 Delivery Requested (запрашиваемая доставка)
010 Requested Ship (запрашиваемая погрузка)
010 Requested Ship (запрашиваемая погрузка)
Т.о. в документе указано, что для описанного товара дата погрузки - 18 Июня 2006 года, а дата доставки - 25 Июня 2006.
Если бы DTM-01 был бы опциональным (необязательным) элементом, и он бы отсутствовал в обоих сегментах, то получатель документа не мог бы определить, что это за даты.
O (optional) - необязательный, опциональный элемент. Эти элементы обычно несут второстепенную информацию, которая не обязательна для понимания информации, заключенной в сегменте. В нашем примере
PO1*004005006*10*EA*15**BP*123456321~
Можно заметить, что между элементами PO1-04 (значение 15) и элементом PO1-06 (значение BP) идет элемент PO1-05 который не имеет значения (пропущен). PO1-05 (Basis Unit Price Code, код, идентифицирующий тип цены единицы товара) является опциональным элементом. Этот элемент описывает тип цены, например BD (Before Discount, до скидки) или HF (Per 100 Feet, за 100 футов - например, для кабеля), или HP (Price per Hundred, цена за сотню) и т.д. В данном случае нам не нужно дополнительно указывать, что цена именно за единицу товара, поэтому в сегменте этот элемент пропущен.
C (conditional) - зависимый элемент, чья опциональность зависит от условий. В нашем примере:
PO1*004005006*10*EA*15**BP*123456321~
PO1-06 (Product/Service Id Qualifier, тип идентификатора товара/услуги) и PO1-07 (Product/Service Id, идентификатор товара/услуги) - примеры подобных элементов. X12 определяет условие их опциональности так:
P0607 - If either PO1-06 or PO1-07 is present, then the other is required.
Тоесть если либо PO1-06, либо PO1-07 присутствует в сегменте, то второй - обязателен. В данном случае это очевидно - если есть идентификатор товара, то нам нужно знать его тип. И наоборот, если есть тип идентификатора, то было бы странно, если бы сам идентификатор отсутствовал.
Далее будут коротко рассмотрены основные типы правил и ограничений, которые стандарт накладывает на элементы сегмента.
Правила и ограничения
Для зависимых элементов в сегменте стандарт определяет набор правил/замечаний. Каждое правило имеет специальное имя-идентификатор. Имя-идентификатор «строится» по специальным правилам - первая буква определяет тип правила, далее идут числа, обозначающие позицию сегментов в элементе, для которых действует это правило. В зависимости от типа правила, позиции элементов так же идут в определенном порядке:
- С (Conditional) - зависимость опциональности одного элемента(ов) от существования другого (первого в описании):
- C0302 - If PO103 is present, then PO102 is required.
- C060504 - If PR106 is present, then PR105 and PR104 are required.
- P (Paired or multiple) - зависимость опциональности группы элементов (если хотя бы один из группы присутствует, то остальные обязательны):
- P0607 - If either PO106 or PO107 is present, then the other is required.
- P040506 - If either AT904, AT905 or AT906 are present, then the others are required.
- L (List Conditional) - зависимость трех и более элементов между собой, когда в случае существования первого в описании элемента обязателен как минимум один из остальных:
- L13101112 - If PO413 is present, then at least one of PO410, PO411 or PO412 is required.
- R (Required) - обязательность как минимум одного из перечисленных элементов:
- R1012 - At least one of PR110 or PR112 is required.
- R020607 - At least one of AT302, AT306 or AT307 is required.
- E (Exclusion) - только один из перечисленных элементов может присутствовать:
- E0309 - Only one of PSD03 or PSD09 may be present.
- E020607 - Only one of AT302, AT306 or AT307 may be present.
Семантические замечания
Стандарт может определять семантические правила для элементов сегмента. Эти замечания предназначены для лучшего понимания назначения элементов. Например, для сегмента PO1 существует такое семантическое замечание:
PO106 through PO125 provide for ten different product/service IDs per each item. For example: Case, Color, Drawing No., U.P.C. No., ISBN No., Model No., or SKU. (элементы, начиная с PO1-06 и заканчивая PO1-25 предоставляют 10 различных идентификаторов для каждого товара. Например: упаковка, цвет и т.д.).
Наконец, рассмотрим наш сегмент PO1 для примера, и посмотрим как стандарт X12 (версия 4010) описывает его элементы:
PO1*004005006*10*EA*15**BP*123456321~
| Элемент | Описание | Тип данных | Значение |
| PO1-01 | Assigned Identificator, присвоенный идентификатор | O AN 1/20 |
004004005 |
| PO1-02 | Quantity Ordered, количество заказанных экземпляров товара | C R 1/15 |
10 |
| PO1-03 | Unit/Basis Measurement Code, единица измерения количества товара | O ID (355) 2/2 |
EA = Each |
| PO1-04 | Unit Price, цена единицы товара | C R 1/17 |
15 |
| PO1-05 | Basis Unit Price Code, код, идентифицирующий тип цены единицы товара | O ID (639) 2/2 |
- |
| PO1-06 | Product/Service Id Qualifier, тип идентификатора товара/услуги | C ID (235) 2/2 |
BP = Buyer's Part Number |
| PO1-07 | Product/Service Id, идентификатор товара/услуги | C AN 1/48 |
123456321 |
SYNTAX NOTES
- C0302 - If PO103 is present, then PO102 is required.
- C0504 - If PO105 is present, then PO104 is required.
- P0607 - If either PO106 or PO107 is present, then the other is required.
Структура EDI документа
Как уже было сказано выше, EDI документ можно представить в виде документа/документов, вложенных в конверты, которые имеют различное назначение.
Конверты (envelopes)
Существуют три типа конвертов - ISA/IEA Envelopes, GS/GE Envelopes и ST/SE Envelopes. Начальные сегменты конвертов имеют название Header, а завершающие - Trailer:
- ISA - Interchange Control Header
- GS - Function Group Header
- ST - Transaction Set Header
- SE - Transaction Set Trailer
- GE - Function Group Trailer
- IEA - Interchange Control Trailer
Рассмотрим эти сегменты подробнее.
ISA (Interchange Control Header) - сегмент, который определяет отправителя и получателя документа.
Важно, что элементы этого сегмента имеют фиксированную длину, например ISA-06 имеет размер 15/15 и до нужной длины дополняется пробелами, в итоге, вместо *A1STORES* мы имеем *A1STORES *. Это свойство используется для определения разделительных элементов, которые используются в данном EDI документе. Символ окончания сегмента берется из позиции 106 (~), разделитель элементов - из позиции 4 (*). Разделитель суб-элементов в композитном элементе находится в позиции 105 (>).
ISA*00* *00* *ZZ*A1STORES *ZZ*LEXINGTON *020115*0900*U*00400*000000005*0*T*>~
| Элемент | Описание | Тип данных | Значение | Комментарий |
| ISA-01 | Authorization Information Qualifier | M ID (101) 2/2 |
00 | Тип авторизации (определяется в ISA-02) 00 - No Authorization present |
| ISA-02 | Authorization Information | M AN 10/10 |
" " (10 пробелов) | Информация, которая используется для дополнительной идентификации или авторизации отправителя EDI документа или данных, которые в нем находятся. |
| ISA-03 | Security Information Qualifier | M ID (103) 2/2 |
00 | Тип security информации, содержащейся в ISA-04. 00 - No Security Information present. 01 - Password. |
| ISA-04 | Security Information | M AN 10/10 |
" " (10 пробелов) | «Пароль» документа. Этот элемент почти не используется по назначению. |
| ISA-05 | Interchange ID Qualifier | M ID (105) 2/2 |
ZZ | Идентификатор типа данных элемента ISA-06. В нашем примере это ZZ - взаимно определенные значения, но часто используются также 01 - DUNS 02 - SCAC code 10 - DODAAC 16 - DUNS + 4 и другие |
| ISA-06 | Interchange Sender ID | M AN 15/15 |
"A1STORES " | Используется для определения отправителя документа |
| ISA-07 | Interchange ID Qualifier | M ID (105) 2/2 |
ZZ | Идентификатор типа данных элемента ISA-08. В нашем примере это ZZ - взаимно определенные значения, но часто используются также 01 - DUNS 02 - SCAC code 10 - DODAAC 16 - DUNS + 4 и другие |
| ISA-08 | Interchange Receiver ID | M AN 15/15 |
"LEXINGTON " | Используется для определения получателя документа |
| ISA-09 | Interchange Date | M DT 6/6 |
020115 | Дата документа |
| ISA-10 | Interchange Time | M TM 4/4 |
0900 | Время документа |
| ISA-11 | Interchange Control Standards ID | M ID (110) 1/1 |
U | Код, идентифицирующий агенство, которое отвечает за EDI стандарт, используемый в данном EDI документе. U - US EDI community |
| ISA-12 | Interchange Control Version Number | M ID (111) 5/5 |
00400 | Версия ISA/IEA Envelope |
| ISA-13 | Interchange Control Number | M N0 9/9 |
000000005 | Специальный идентификатор, который используется для проверки уникальности документа и предотвращения отправки дублицированных документов. Обычно используется целочисленное значение, и с каждым новым документом, отправленным одному и тому же партнеру, увеличивается на единицу. |
| ISA-14 | Acknowledgement Requested | M ID (113) 1/1 |
0 | Индикатор запроса сегмента TA3 (Interchange Delivery Notice Segment) в ответе принимающего сервиса. Этот сегмент (TA3) используется для определения, был ли EDI документ (interchange) доставлен конечному получателю, и некоторой другой вспомогательной информации. |
| ISA-15 | Test Indicator | M ID (114) 1/1 |
T | Имеет два возможных значения - T (Test) или P (Production), и используется для определения типа документа. Можно использовать "T" для проверки правильности формата документа. |
| ISA-16 | Subelement Separator | M (символ-разделитель) 1/1 |
> | Разделитель суб-элементов в композитном элементе. |
IEA (Interchange Control Trailer) - замыкающий Interchange сегмент.
IEA*1*000000005~
| Элемент | Описание | Тип данных | Значение | Комментарий |
| IEA-01 | Number of Function Groups Included | M N0 1/5 |
1 | Количество функциональных групп (ограниченных GS/GE сегментами), которые входят в данный Interchange. В нашем примере это 1 - одна функциональная группа (PO). |
| IEA-02 | Interchange Control Number | M N0 9/9 |
000000005 | Контрольный номер Interchange, совпадает с ISA-13 |
GS (Function Group Header) - сегмент определяет тип документа(ов), которые входят в эту группу, содержит контрольную информацию. Он может использоваться для роутинга EDI документа между различными системами и/или адресами компаний, которые обмениваются этими документами. Еще раз - GS/GE сегменты являются «конвертом» (envelope) для документов одного типа (тип определяется GS-01 сегментом).
GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~
| Элемент | Описание | Тип данных | Значение | Комментарий |
| GS-01 | Functional Identifier Code | M ID (479) 2/2 |
PO | Тип документов, включенных в данную функциональную группу. PO - ордера, IN - инвойсы и т.д. (см спецификацию). |
| GS-02 | Application Sender’s Code | M AN 14/14 |
A1STORES | Код, идентифицирующий сторону-отправителя. Данный код согласуется партнерами по документообороту. |
| GS-03 | Application Receiver’s Code | M AN 9/9 |
LEXINGTON | Код, идентифицирующий сторону-получателя. Данный код согласуется партнерами по документообороту. |
| GS-04 | Date | M DT 8/8 |
20020110 | Дата |
| GS-05 | Time | M TM 4/4 |
0900 | Время |
| GS-06 | Group Control Number | M N0 1/9 |
5 | Присвоенный отправителем номер. |
| GS-07 | Responsible Agency Code | M ID(455) 1/2 |
X | Код, используемый для определения компании, выпустившей данный стандарт. X - Accredited Standards Committee X12, T - Transportation Data Coordinating Committee (TDCC) |
| GS-08 | Version/Release/Industry Identifier Code | M AN 1/12 |
004010 | Код, идентифицирующий номер версии, релиза и суб-релиза используемого стандарта. В нашем случае это версия стандарта - 4010. |
GE (Function Group Trailer) - сегмент определяет конец данных, которые были начаты GS сегментом. В EDI-документ (Interchange) может быть включено несколько функциональных групп, сегмент GE используется для определения места, где завершается функциональная группа.
GE*1*5~
| Элемент | Описание | Тип данных | Значение | Комментарий |
| GE-01 | Number of Transaction Sets Included | M N0 1/6 |
1 | Количество документов (transaction sets), включенных в данную функциональную группу. Используется как контрольное значение. |
| GE-02 | Group Control Number | M N0 1/9 |
5 | Присвоенный отправителем номер. Используется как контрольное число при определении GS/GE конверта (GS-06 = GE-02). |
ST (Transaction Set Header) - сегмент идентифицирует тип документа. Этот сегмент начинает документ (например, ордер или инвойс). Как уже было сказано в начале, в X12 тип документа имеет трехзначный номер-идентификатор.
ST*850*50001~
| Элемент | Описание | Тип данных | Значение | Комментарий |
| ST-01 | Transaction Set Identifier Code | M ID(143) 3/3 |
850 | Трехзначный номер-идентификатор, определяющий тип документа. Примеры: 850 - Purchase Order 810 - Invoice 855 - Purchase Order Acknowledgment 889 - Promotion Announcement |
| ST-02 | Transaction Set Control Number | M AN 4/9 |
50001 | Уникальный идентификатор документа в данной функциональной группы. Обычно (часто) используется последовательность 0001, 0002,… но бывают и другие (как в нашем примере). |
SE (Transaction Set Trailer) - сегмент определяет конец документа. Этот сегмент содержит информацию об общем количестве сегментов с данными (включая ST и SE сегменты). Это число используется для верификации документа.
SE*33*50001~
| Элемент | Описание | Тип данных | Значение | Комментарий |
| SE-01 | Number of included segments | M N0 1/10 |
33 | Количество сегментов, входящих в данный документ (transaction set), ограниченный конвертом ST/SE. Сами сегменты ST/SE так же подсчитываются в этом числе. Эти данные используются для контрольной проверки целостности документа после обработки - все ли сегменты были обработаны. |
| SE-02 | Transaction Set Control Number | M AN 4/9 |
50001 | Контрольный номер, SE-02 = ST-02 для каждого ST/SE конверта. |
Header (заголовок), Details (детали) и Summary (итог).
Наконец, рассмотрим сам документ (transaction set). Как уже было сказано выше, документ (transaction set) представляет собой набор данных, представляющих в совокупности законченную информацию, ценную для сторон, участвующих в документообороте. Примеры документов - ордер, счет, документ с информацией о скидках, каталог и т.д. Каждый документ заключен в «конверт» ST/SE, в котором указан тип документа. Документ, в свою очередь, разделен на три группы - Header (заголовок), Details (детали) и Summary (Итог).
(см. рис 6.)
Заголовок документа содержит данные, общие для документа - например номер, контактная информация, даты погрузки/доставки, адреса и т.д.
В деталях документа включено содержание документа, например для ордера заказа - информация о заказанном товаре, количество, цена и скидки на данный тип товара.
Итоговые данные обычно содержат суммарную информацию - для ордера это может быть количество типов заказанных товаров, для счета - общая стоимость товара, общие скидки и т.д.
Использование EDI в реальном документообороте.
Электронный документооборот используется во многих областях деятельности, где требуется обмен данными. Это в первую очередь торговля, страхование, медицина, транспортная логистика и т.д.
Крупные розничные сети (ритейлеры), типа Wal-Mart, Kroger, K-Mart и другие используют EDI X12 для обмена электронными документами со своими торговыми партнерами. Они задают формат документов, которые они отправляют сами и которые они ожидают от поставщиков. Компании-поставщики, которые хотят работать с этими ритейлерами, обязаны использовать эти форматы - иначе они не смогут «понять», что заказывает ритейлер или в компании-ритейлере не смогут «понять» инвойс.
Обычно набор документов, которыми обменивается ритейлер с поставщиками, включает в себя следующие документы:
- PO (Purchase Order, ордер заказа) - какой товар, сколько единиц его и т.д. заказано. Отправляет ритейлер.
- ASN (Advanced Ship Notice/Manifest) - документ по комплектации и упаковке товара, например 10 паллетов, на каждом по 4 коробки, в каждой коробке по 100 единиц товара. Вес такой-то, объем - такой-то. Отправляет поставщик.
- Invoice (Инвойс или счет(-фактура)) - счет за товар. Отправляет поставщик.
- Remittance Advice - подтверждение оплаты. Отправляет ритейлер.
- FA (Functional Acknowledgement) - специальный тип документов, которые отправляются автоматически в ответ на полученный EDI документ (подтверждают получение) и содержат информацию о нераспознаных/необработанных данных (если таковые имеются)
Несмотря на то, что стандарты EDI для определенного типа документа (например, ордера или инвойса) включают в себя огромное множество возможных данных (допустимых сегментов), на практике редко кто полностью использует полный набор сегментов и элементов. Обычно компании «выбирают» из стандарта только те сегменты и элементы, которые нужны для их бизнеса.
В примере с розничными сетями EDI является связующим звеном между поставщиками товара и ритейлерами. Ритейлер, определяя версию и формат EDI документов, устанавливает строгие правила на документооборот со своими торговыми партнерами.
EDI позволяет компаниям-партнерам по электронному документообороту свести к минимуму вероятность ошибок (в первую очередь, человеческих), унифицировать свой документооборот, автоматизировать свои процессы, четко наладить коммуникации со своими партнерами и многое другое.