Спецификация xml для электронного обмена данными

Иллюстрации

Показать все

Изобретение относится к средствам для электронного обмена данными (ЭОД). Техническим результатом является повышение эффективности обработки ЭОД-транзакций. В способе для преобразования транзакций электронного обмена данными принимают в пакете совокупность данных ЭОД. Пакет данных ЭОД включает в себя множество документов ЭОД, и каждый из множества документов ЭОД содержит, по меньшей мере, одну ЭОД-транзакцию, соответствующую некоторому типу транзакции. Идентифицируют ЭОД-транзакции, идентифицируют множество экземпляров идентифицированных ЭОД-транзакций, идентифицируют повторяющиеся структурные элементы ЭОД-транзакций. Из документов ЭОД в пакете данных ЭОД генерируют объединенный документ ЭОД. Объединенный документ ЭОД включает в себя идентифицированные ЭОД-транзакции, организованные согласно типу транзакции. 3 н. и 16 з.п. ф-лы, 27 ил., 4 табл.

Реферат

Уровень техники

Для облегчения обработки транзакций организации часто передают данные о деловых операциях в строгом формате по обычным сетям связи. Например, одним из способов, при помощи которых организации с выгодой для себя используют получающие все большее распространение автоматизированные вычислительные системы, является электронный обмен данными (ЭОД).

В ЭОД деловая информация форматируется согласно одному или нескольким известным и утвержденным стандартам, таким как ANSI X12 или EDIFACT. Например, данные ЭОД, представляющие различные транзакции, передаются в виде пакета разграниченных документов, и каждый из разграниченных документов кодируется в соответствии со строгими правилами форматирования, обеспечивающими, чтобы приложение-получатель, принимающее документы, могло успешно выполнить синтаксический анализ и потребление информации для дальнейшей обработки.

При проведении синтаксического анализа и обработке сообщений ЭОД существующие системы передают данные ЭОД и в процессе обмена включают правила или схемы форматирования в каждый разграниченный документ. Например, данные ЭОД, представляющие транзакцию заказа на поставку, включают в себя схему для транзакции заказа на поставку. Таким образом, каждый документ ЭОД, содержащий транзакцию, включает в себя как данные ЭОД, так и конкретную схему для транзакции. Хотя такая компоновка или конфигурация облегчает синтаксический анализ данных ЭОД, она является статической и делает большим каждый транзакционный документ с точки зрения размера документа. Кроме того, включенная в него схема не является совместно используемой. Иными словами, если имеются транзакционные документы A и B с заказами на поставку, каждый транзакционный документ с заказом на поставку должен включать в себя схему заказа на поставку, даже если в каждом документе используется одинаковая схема. Кроме того, плата за ЭОД-транзакции взимается, в частности, в зависимости от числа строк в документе и требуется определенная пропускная способность для передачи данных ЭОД. Поскольку организации передают ежедневно миллионы транзакций при помощи ЭОД, такие большие документы ЭОД-транзакций, в которых дублируется информация о схеме, приводят к излишним расходам из-за наличия избыточной информации о схеме.

После приема документов ЭОД-транзакций приложение-получатель обычно хранит документы ЭОД-транзакций в области памяти. Затем приложение-получатель передает подтверждение приема источнику с указанием, что транзакции приняты. Затем сохраненные ЭОД-транзакции проверяются приложениями, которые проверяют, соответствуют ли ЭОД-данные, содержащиеся в документах транзакции, правилам форматирования схем для этих типов транзакций. Во время этой проверки источнику (например, торговцу или заказчику) необходимо подождать подтверждения проверки правильности, указывающей, что данные транзакции соответствуют формату. Если установлено, что одна или более транзакций сформатированы неправильно, для обработки необходимо повторно передать заменяющие документы ЭОД-транзакций. Эта задержка на ожидание проверки подлинности еще более снижает эффективность обработки ЭОД-транзакций.

Сущность изобретения

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

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

Настоящее описание краткой сущности приведено для ознакомления с некоторыми идеями в упрощенном виде, которые будут описаны далее в подробном описании. Настоящее описание краткой сущности не предназначено для выявления основных или существенных характерных особенностей заявленного изобретения и не предназначено для использования в качестве вспомогательного средства для определения объема заявленного изобретения.

Другие характерные особенности будут отчасти очевидны и отчасти указаны ниже.

Краткое описание чертежей

Фиг.1 - блок-схема, иллюстрирующая реализацию обработки ЭОД-транзакций.

Фиг.2A-2C - диаграммы, иллюстрирующие структуру транзакционных данных, использующих электронный обмен данными (ЭОД) согласно варианту осуществления изобретения.

Фиг.3 - пример блок-схемы, иллюстрирующей систему для преобразования ЭОД-транзакций согласно варианту осуществления изобретения.

Фиг.4A и 4B - блок-схемы последовательности действий, иллюстрирующие преобразование ЭОД-транзакций согласно варианту осуществления изобретения.

Фиг.5A - блок-схема, иллюстрирующая вложение ЭОД-транзакции согласно варианту осуществления изобретения.

Фиг.5B и 5C - блок-схемы, иллюстрирующие преобразование ЭОД-транзакций в последовательный вид согласно варианту осуществления изобретения.

Фиг.6A и 6B - "снимки экрана", иллюстрирующие преобразованные ЭОД-транзакции, включенные в объединенный документ ЭОД в формате документа расширяемого языка разметки (XML) согласно варианту осуществления изобретения.

Фиг.7A-7D - "снимки экрана", иллюстрирующие автоматически идентифицирующие схемы ЭОД согласно варианту осуществления изобретения.

Фиг.8A - блок-схема последовательности действий, иллюстрирующая подтверждение правильности ЭОД-транзакций согласно варианту осуществления изобретения.

Фиг.8B - диаграмма, иллюстрирующая обнаружение ошибок в ЭОД-транзакциях согласно варианту осуществления изобретения.

Фиг.9A и 9B - диаграммы, иллюстрирующие структуры подтверждения проверки правильности ЭОД согласно варианту осуществления изобретения.

Фиг.10 - "снимок экрана", иллюстрирующий единую метасхему для модификации множества схем ЭОД согласно варианту осуществления изобретения.

Фиг.10A - блок-схема последовательности действий, иллюстрирующая способ модификации множества ЭОД-схем с использованием единой метасхемы согласно варианту осуществления изобретения.

Фиг.11A и 11B - блок-схема, иллюстрирующая пример машиночитаемого носителя, на котором могут храниться аспекты изобретения.

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

В Приложении A полностью описывается схема XML, приведенная на фиг.10A.

В Приложении B приведен пример единой метасхемы в формате XML, представляющий схему заказа на покупку.

На всех чертежах соответствующие обозначения позиций указывают на соответствующие детали.

Подробное описание

На фиг.1 приведена блок-схема, иллюстрирующая обработку ЭОД-транзакций. Вначале, как показано на фиг.1, источник (например, деловой партнер) 102 передает сообщение ЭОД 106, которое может включать в себя счет-фактуру 202, получателю (например, компании-заказчику) 104 через обычную сеть 108 связи.

Источник 102 передает сообщение ЭОД 106, включающее в себя схемы и данные ЭОД-транзакций, получателю 104 по общей сети 108 связи. В одном примере сообщение ЭОД 106 включает в себя множество данных ЭОД-транзакций в пакете для экономии затрат на передачу или пропускную способность. В другом примере обычная сеть связи 108 может быть частной, специализированной сетью, такой как интрасеть, или общедоступной сетью, такой как Интернет. В другом примере обычная сеть 108 связи включает в себя один или несколько протоколов, таких как FTP, HTTP, Kermit, Xmodem, с задержкой кадров, EDIINT, 3780 Bisync® или аналогичные, для облегчения передачи сообщений ЭОД между партнерами.

Источник 102 инициирует передачу сообщения ЭОД 106 посредством открытия сеанса соединения (например, сеанса безопасного соединения через сокет) с получателем 104 через обычную сеть 108 связи. После открытия сеанса соединения источник 102 передает сообщение ЭОД 106 получателю 104. Набор систем 110 трансляторов ЭОД, имеющийся у получателя 104, принимает сообщение ЭОД 106, и системы 110 трансляторов ЭОД передают подтверждение 112 приема источнику 102 через обычную сеть 108 связи, указывающее, что сообщение ЭОД было получено. Обычно подтверждение приема передается или возвращается источнику 102 до того, как источник 102 закроет сеанс связи.

После получения сообщения ЭОД 106 данные ЭОД, связанные с ЭОД-транзакцией, подвергаются синтаксическому анализу и обрабатываются системами 110 трансляторов ЭОД. Как известно специалистам в данной области техники, синтаксический анализ и декодирование ЭОД-транзакции включает в себя один или несколько этапов идентификации различных стандартов ЭОД, спецификаций схем и т.п. При этом системы 110 трансляторов ЭОД передают данные ЭОД, подвергшиеся синтаксическому анализу или декодированию, нижележащему приложению 114 для обработки данных ЭОД, подвергшихся синтаксическому анализу или декодированию. Например, нижележащее приложение 114 может быть бухгалтерским приложением для обработки счетов-фактур или программным обеспечением для обработки данных о заказах на поставку. Таким образом, нижележащее приложение 114 может проверить, соответствуют ли принятые данные ЭОД после синтаксического анализа или декодирования правилам форматирования, задаваемым схемами. Если принятые данные ЭОД соответствуют правилам схем, нижележащее приложение 114 передает подтверждение 116 правильности источнику 102. Если же принятые данные ЭОД включают в себя ошибки или являются неправильными, нижележащее приложение 114 может передать источнику уведомление об ошибке с указанием ошибки в принятых данных ЭОД.

Подтверждение 116 правильности обычно передается источнику 102 через некоторое время после передачи подтверждения приема. В других вариантах осуществления данные ЭОД, подвергшиеся синтаксическому анализу, хранятся в базе данных или хранилище данных (не показано) в ожидании проверки правильности. Таким образом, источнику 102 часто требуется ждать подтверждения 116 правильности, чтобы быть уверенным, что данные ЭОД могут быть надлежащим образом обработаны получателем.

На фиг.2A-2C приведены диаграммы, иллюстрирующие структуры транзакционных данных, использующие электронный обмен данными (ЭОД), согласно варианту осуществления изобретения. На фиг.2A приведен пример представления документа 202 ЭОД-транзакции счета фактуры с использованием формата ANSI X12. В этом примере счет-фактура 202 включает в себя ряд сегментов или разделов (об общем представлении о структуре 218 ЭОД-обмена X12 см. фиг.2C), таких как секция функциональной группы 204, которая может содержать дополнительную информацию о счете-фактуре 202. Например, специалистам в данной области техники известно, что в сфере цепочек поставок информация и значения в функциональной группе 204 идентичны информации и значениям в секции обмена данными (например, в заголовке управления обменом данными), как показано на фиг.2C. В другом примере информация или значения в функциональной группе 204 включают в себя значения или идентификаторы для идентификации коммерческого или структурного подразделения более крупного предприятия.

Счет-фактура 202 также включает в себя заголовочную часть 206, которая содержит такую информацию, как информация о компании-заказчике. В данном примере заголовочная часть 206 включает в себя название компании-заказчика "Компания ABC" и адрес "0887 Шестая улица, Сент-Луис, штат Миссури 63101." В одном варианте осуществления заголовочная часть 206 включает в себя информацию о том, где принимать подтверждения правильности, см. описание, связанное с фиг.8, 9A и 9B. Счет-фактура 202 также включает в себя раздел (секцию) 208 таблицы отдельных позиций, содержащий один или несколько сегментов 212 данных, которые организованы в цикл 210. Например, цикл 210 включает в себя группу сегментов семантически связанных данных, и для специалистов в данной области техники эти сегменты могут быть либо ограниченными, либо неограниченными согласно ANSI X12.6.

Не выходя за рамки объема изобретения, в документ ЭОД-транзакции в соответствии с форматом ANSI X12 или EDIFACT можно включить дополнительные типы и разделы сегментов и соответствующую информацию. Например, на фиг.2B приведены одна или более типов транзакций, включенных в одно сообщение ЭОД 106, которое подлежит обработке получателем 104. Документы ЭОД-транзакций счета-фактуры 214 и заказа 216 на поставку включаются в сообщение ЭОД 106, поскольку счет-фактура 214 и заказ 216 на поставку относятся к одном заказчику - "Компании ABC". В обмен данными в виде сообщения ЭОД 106 могут быть включены дополнительные группы связанных транзакционных документов. В одном варианте осуществления документы ЭОД для одного получателя или заказчика могут направляться в пакете.

Должно быть также понятно, что каждый тип ЭОД-транзакции должен соответствовать схеме, связанной с данным типом транзакции. Например, схема транзакции счета-фактуры может требовать, в частности, некоторых ограничений на максимальную или минимальную длину символов для названия торговца или покупателя. Транзакция заказа на поставку может требовать максимального числа цифр после запятой. В другом примере схема для различных типов транзакций может указывать, что некоторые графы являются обязательными, а другие - необязательными.

Существующие варианты реализации включают схемы транзакций в документы ЭОД-транзакций при передаче ЭОД-транзакций заказчику, такому как получатель 104. Хотя эти варианты реализации облегчают декодирование ЭОД-транзакций, они требуют от разработчиков схем значительных временных затрат на разработку и конфигурирование схем перед передачей ЭОД-транзакций деловым партнерам. Кроме того, для переконструирования схемы требуется внести последующие модификации в схемы вследствие изменения деловых соглашений между партнерами.

Таким образом, варианты осуществления настоящего изобретения преодолевают недостатки существующих вариантов реализации посредством преобразования сообщения ЭОД в объединенный документ ЭОД с вложенными структурами или поддокументами, организующими одну или несколько ЭОД-транзакций согласно типам транзакций. ЭОД-документ также включает в себя надсхему для представления множества схем, связанных с типами транзакций. В другом варианте осуществления множество схем преобразуются картой отображения схем во время выполнения для обработки во время выполнения в адресате (получателе) 104.

Блок-схема, приведенная на фиг.3, иллюстрирует систему 302 для преобразования ЭОД-транзакций согласно варианту осуществления изобретения. Система 302 включает в себя источник 304, который может быть торговым предприятием, совершающим деловые операции с получателем 306 или заказчиком. Например, источником 304 может быть торговое предприятие, такое как розничный магазин бытовой электроники, продающий большое количество товаров корпоративному заказчику, приобретающему вычислительное оборудование. В другом примере источником может быть организация здравоохранения, такая как больница или аптека, которая передает данные ЭОД страховой компании или расчетной палате для подачи заявок или с целью выполнения положений, предусмотренных Законом по обеспечению доступности и подотчетности в медицинском страховании (HIPAA).

В одном варианте осуществления источник 304 и получатель 306 включают в себя одно или несколько вычислительных устройств, таких как компьютер 130 на фиг.12, для отправки документов ЭОД в пакете. Вначале источник 304 передает сообщение 310 ЭОД, содержащее множество документов ЭОД. Каждый из документов ЭОД содержит по меньшей мере одну ЭОД-транзакцию, соответствующую некоторому типу транзакции (например, счету-фактуре, заказу на поставку, счету к оплате и т.п.)

Если обратиться также к фиг.4A, то на ней изображена блок-схема последовательности действий по преобразованию ЭОД-транзакции согласно варианту осуществления изобретения. После того как источник 304 открывает сеанс связи в сети 308 связи для установления связи с получателем 306, источник 304 передает сообщение 310 ЭОД ЭОД-механизму 312 получателя 306. В одном варианте осуществления ЭОД-механизм 312 включает в себя одно или несколько вычислительных устройств (например, компьютер 130), выполняющих машиноисполняемые команды, программы или функции. На этапе 402 ЭОД-механизм 312 принимает сообщение 310 ЭОД, содержащее множество документов ЭОД. На этапе 404 ЭОД-механизм 312 идентифицирует ЭОД-транзакции, включенные в множество документов ЭОД. При помощи вышеприведенного примера ANSI X12 ЭОД-механизм 312 декодирует и осуществляет синтаксический анализ счета-фактуры X12 посредством идентификации различных заголовков данных и сегментов данных (например, ISA, GS и т.п.), приведенных на фиг.2C, для обнаружения данных ЭОД в транзакции. В другом варианте осуществления ЭОД-механизм 312 идентифицирует также различные схемы, включенные в множество документов ЭОД, для определения конкретных правил форматирования для данных типов транзакций.

На этапе 406 ЭОД-механизм 312 создает объединенный документ 314 ЭОД из множества документов ЭОД в пакете. В одном примере на этапе 410 ЭОД-механизм 312 создает объединенный документ 314 ЭОД в виде документа XML с тегами разметки структуры XML. Например, в отличие от существующих вариантов реализации, когда каждая транзакция организуется в виде одного документа, варианты осуществления изобретения организуют ЭОД-транзакции во множестве документов ЭОД в виде одного документа XML, который не только определяет отдельные наборы транзакций, но также предназначен для определения обменов данными посредством охвата всех аспектов данных ЭОД, в том числе сегментов, циклов, полей, разделителей и т. д. В одном примере, приведенном на фиг.6A, пример объединенного документа XML включает в себя одну или несколько ЭОД-транзакций, таких как "заказ на поставку".

В еще одном варианте осуществления изобретения объединенный документ 314 ЭОД содержит надсхему, представляющую множество схем, на которые ссылаются ЭОД-транзакции. Например, надсхема включается в набор ЭОД-транзакций и встраивается или вшивается внутрь функциональных групп или охватывающих сегментов каждых ЭОД-транзакций, так что конечному пользователю не требуется создавать конкретную схему для каждого набора транзакций, которые предполагается включить в сообщение 310 ЭОД. В качестве примера на фиг.6B приведен "снимок экрана" с изображением надсхемы в формате XML в объединенном документе 314 ЭОД согласно варианту осуществления изобретения. При такой модели обмен объединенным документом 314 ЭОД в меньшей степени требует включения в себя одной или более схем, соответствующих типу транзакции в документах ЭОД. Варианты осуществления изобретения также сокращают время на разработку и конструирование схемы перед передачей.

В другом варианте осуществления на этапе 412, приведенном на фиг.4B, ЭОД-механизм 312 преобразует объединенный документ ЭОД при помощи карты отображения схем во время выполнения или схемы полезной информации. На этапе 414 ЭОД-механизм 312 создает поддокументы или вложенные структуры для ЭОД-транзакций в объединенном документе 314 ЭОД (для более подробного описания см. таблицы 1 и 2). В альтернативном варианте осуществления объединенный документ 314 ЭОД преобразуется посредством схемы полезной информации (например, карты отображения схем во время выполнения) и может также быть структурно преобразован на этапе 416. Альтернативно, на этапе 418 объединенный документ 314 ЭОД может быть передан нижележащему приложению 316 на обработку без структурной информации. На этапе 420 объединенный документ 314 ЭОД с поддокументами или вложенной структурой также передается нижележащему приложению 316 на обработку.

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

В другом варианте осуществления машиночитаемый носитель 1102 (на фиг.11A), на котором могут храниться описанные выше аспекты изобретения. Например, интерфейсный компонент 1104, идентифицирующий компонент 1106 и преобразующий компонент 1108 могут содержаться в ЭОД-механизме 312, выполняющем одну или несколько рассмотренных выше операций.

Должно быть также понятно, что способ, приведенный на фиг.4A, может выполняться источником 304, так что источник 304 сокращает объем обмена данными до передачи. Таким образом, вложенная структура и поддокументы объединенного документа 314 ЭОД сокращают число строк, что может также сократить стоимость передачи данных ЭОД, когда плата взимается за число строк.

Например, в таблице 1 приведены три ЭОД-транзакции во вложенной структуре в объединенном документе ЭОД и три соответствующих первоначальных документа ЭОД, каждый из которых включает в себя одну из трех транзакций ЭОД.

Таблица 1
Три ЭОД-транзакции во вложенной структуре (левый столбец) и в трех документах ЭОД (правый столбец)
ЭОД-транзации во вложенной структуре Развернутые ЭОД-транзации для последующей обработки
BeginOfTransaction#1POHeaderSegmentPOLine1POSchedule1.1POSchedule1.2POLine1TotalsPOLine2POSchedule2.1POLine2TotalsPOTotalsEndOfTransaction#1 BeginOfTransaction#1aPOHeaderSegmentPOLine1POSchedule1.1POLine1TotalsPOTotalsEndOfTransaction#1aBeginOfTransaction#1bPOHeaderSegmentPOLine1POSchedule1.1POLine1TotalsPOTotalsEndOfTransaction#1bBeginOfTransaction#1cPOHeaderSegmentPOLine1POSchedule1.1POLine1TotalsPOTotalsEndOfTransaction#1c

Предположим, что в процессе работы лицу, финансирующему услуги здравоохранения, например работодателю A, необходимо послать сообщение ЭОД, такое как документ HIPAA 834, плательщику, такому как организация здравоохранения B. Схема такого обмена требует, чтобы Работодатель A представил сведения о пособиях, предоставленных получателям услуг здравоохранения (например, сотрудникам или их иждивенцам). Поэтому Работодатель A обычно включает подробные сведения о реквизитах финансирующего лица и плательщика. Эти подробные сведения о реквизитах финансирующего лица и плательщика являются общими для всех получателей пособий и повторяются для каждого сотрудника или иждивенца, который получает пособие, финансируемое Работодателем A. Вместо того чтобы повторять одинаковые сведения о финансирующем лице и плательщике для тысяч сотрудников и иждивенцев, как делается в существующих реализациях ЭОД, варианты осуществления изобретения создают вложенную структуру, так что каждый элемент можно создать вместе с копией сведений о реквизитах спонсора и плательщика посредством циклообразной логики в одном документе ЭОД.

На фиг.5 приведена блок-схема, иллюстрирующая вложение ЭОД-транзакции согласно варианту осуществления изобретения. Например, на этапе 502 сообщение ЭОД (например, сообщение 310 ЭОД) принимается от источника (например, от источника 304) получателем (например, получателем 306). На этапе 504 создается объединенный документ ЭОД с ЭОД-транзакциями, включенными во вложенную структуру или в виде поддокументов. В одном примере охватывающие/управляющие сегменты (например, сегменты ISA/GS/GE/IEA в формате ANSI X12) удаляются, и транзакционный набор подвергается синтаксическому разбору приемным конвейером для генерации множества поддокументов XML в расчете на каждый транзакционный набор. В одном варианте осуществления множество поддокументов XML хранится в хранилище сообщений. На этапе 506 приемный конвейер у получателя осуществляет проверку правильности поступившего обмена и генерирует соответствующее подтверждение правильности (что подробно рассмотрено на фиг.8, 9A и 9B). В одном варианте осуществления приемный конвейер также обновляет контрольную сумму и итоговые данные экономической деятельности.

Как описано выше, объединенный документ 314 ЭОД может быть обработан нижележащим приложением 316. В этом случае объединенный документ ЭОД отправляется в порт отправки, и на этапе 508 порт отправки передает ЭОД-транзакции в поддокументах ЭОД. В одном варианте осуществления конвейер отправки, связанный с портом отправки, преобразует поддокументы XML в последовательную форму и отправляет "n" обменов данными с числом сегментов, обновляемых конвейером отправки.

В одном варианте осуществления при приеме обмена ЭОД он подвергается проверке на правильность. Если при проверке на правильность ошибок не обнаружено, каждый транзакционный набор преобразуется в формат XML в соответствии со своей схемой. Таким образом, обмен ЭОД может содержать документы с заказами на поставки и счетами-фактурами. Заказы на поставки преобразуются в XML, который согласуется со схемой заказа на поставку. Аналогично, счет-фактура преобразуется в счет-фактуру XML.

На фиг.5B приведен пример заказа на поставку из обмена ЭОД в формате XML. Когда документ заказа на поставку обрабатывается отправляющей стороной на фиг.5 A, он преобразуется в формат 514 ЭОД после обработки охватывающих сегментов. На фиг.5C приведен пример документа, создаваемого портом отправки из формата XML на фиг.5B. В одном варианте осуществления формат 514 ЭОД включает в себя два охватывающих сегмента (например, строки, которые начинаются с ISA и GS). Аналогично, формат 514 ЭОД включает в себя два охватывающих сегмента, GE и IEA, в конце документа. Как показано на чертеже, данные, включенные между сегментами ST и SE, представляют собой данные первоначального транзакционного набора.

В вышеприведенном примере, проиллюстрированном фиг.5B и 5C, значение SE0l (см. стрелку 512) равно "14" и вычисляется динамически портом отправки. При преобразовании документа ЭОД в последовательную форму отправляющая сторона отправки ЭОД-механизма (например, ЭОД-механизма 312) отслеживает число сегментов, имеющихся в транзакционном наборе. На основе этого значения определяется значение SE01.

Когда источник 304 создает объединенный документ 314 ЭОД для включения в него ЭОД-транзакций из множества ЭОД-документов, варианты осуществления изобретения включают в себя организацию включенных ЭОД-транзакций во вложенную структуру. В другом примере варианты осуществления изобретения дают возможность получателю 306, который принимает от источника объединенный документ 314 ЭОД, восстановить множество документов ЭОД из объединенного документа 314 ЭОД с целью обратной совместимости или обеспечения возможности использования нижележащего приложения 316, которое может обрабатывать только такие документы ЭОД, которые содержат одну транзакцию на документ. Альтернативные варианты осуществления изобретения позволяют отслеживать или коррелировать объединенный документ ЭОД с ЭОД-транзакциями во вложенных структурах с первоначальным множеством документов ЭОД.

Например, в таблице 2 приведено преобразование ЭОД-транзакций из объединенного документа 314 ЭОД в множество документов ЭОД.

Таблица 2
Преобразование объединенного документа ЭОД
A0 A1 A2 A3 A4
Схема (мин. происходит и макс. происходит) Первоначальный экземпляр Расщепление №1 Расщепление №2 Расщепление №3
ST(1,0)AA(1,1)BB loop (1,n)-sub doc break = yesBB1(1,1)BB2(0,1)CC(1,n)DD(0,n)SE STAA BB1*1 BB2*1 BB1*2 BB1*3 BB2*3 CCCCDDSE STAA BB1*1 BB2*1 CCCCDDSE STAA BB1*2 CCCCDDSE STAA BB1*3 BB2*3 CCCCDDSE

В примере, приведенном в таблице 2, обработка ЭОД-транзакций во вложенной структуре начинается с идентификации заданной SubDocumentCreationBreakPoint (например, метки "\", которая описывает, где внутри материнского документа начинается дочерний документ) для генерации множества поддокументов.

Согласно таблице 2 объединенный документ ЭОД, приведенный в столбце A1, может быть расщеплен на три транзакции в соответствии с разбиением на поддокументы, определенным в цикле BB схемы: BB1*1-BB2*1, BB1*2 и BB1*3-BB2*3. В столбце A2 транзакционный набор BB1*1-BB2*1 (обозначенный полужирным шрифтом) организуется или выделяется в отдельный документ, в столбце A3 транзакция BB1*2 организуется во второй документ (обозначенный подчеркнутым шрифтом). Аналогично транзакционный набор BB1*3-BB2*3 организуется в третий документ ЭОД (обозначенный курсивным шрифтом), который затем подлежит обработке нижележащим приложением 316.

Преобразуя ЭОД-транзакции, включенные в множество документов ЭОД, в объединенный документ 314 ЭОД, варианты осуществления изобретения позволяют получателю 306 или источнику 304 эффективно идентифицировать множество схем, включенных в каждый документ ЭОД в процессе преобразования. Кроме того, по меньшей мере один аспект изобретения позволяет получателю 306 после преобразования объединенного документа ЭОД сгенерировать подтверждение правильности, которое должно вернуться источнику 304 в течение времени, когда сеанс связи еще открыт. Иными словами, аспекты изобретения обеспечивают получателю 306 возможность автоматически идентифицировать множество схем и проверять правильность ЭОД-транзакций во время получения ЭОД-транзакций.

На фиг.7A-7D изображен ряд "снимков экрана", иллюстрирующих автоматическую идентификацию схем ЭОД согласно варианту осуществления изобретения. На фиг.7A изображена типичная схема ANSI X12 заказа на покупку. Схема идентифицируется посредством связанного с ним DocType. DocType представляет собой сочетание пунктов конфигурации, таких как область имен, и имени корневого узла. Как показано на фиг.7A, левый столбец 702 "снимка экрана" показывает иерархическую структуру схемы. В данном примере в левом столбце 702 приведена структура схемы. Средний столбец 704 показывает XML-код схемы. В правом столбце 706 показаны свойства или целевое пространство имен, включенных в схему.

В одном варианте осуществления DocType имеет следующий формат: "DocType = TargetNamespace '#' RootNodeName" в формате X12, который более подробно описан ниже. Должно быть понятно, что, хотя на фиг.7A описана схема X12, в рамках объема изобретения можно использовать и другие форматы схем, например схемы EDIFACT.

Корневой узел DocType имеет в X12 один из следующих форматов: "X12_{Version}_{TsId}". В данном примере значение пункта конфигурации "root node" равно "X12_00401_850", как показано рамкой 708. Иными словами, "00401" является версией документа, и это - динамическая информация, которая определяет конфигурацию или экземпляр обработки во время выполнения. Аналогично, "850" - это TsId, что представляет собой идентификационные данные (ID) транзакции для схемы, которая подвергается обработке и определяется по входному экземпляру. В данном примере транзакция с ID "850" представляет заказ на поставку, как показано в рамке 710. Кроме того, целевая область имен указана в рамке 712 в правом столбце 706.

В другом примере для декодирования или идентификации схем в формате EDIFACT схемы EDIFACT в настоящее время имеют следующий формат: "Efact_{Version}_{Tsid}". Иными словами, у всех схем EDIFACT имя корневого узла начинается с "Efact," а определения для Version и Tsid те же, что и для формата X12.

Если воспользоваться фиг.3 в качестве примера, то, когда получатель 306 принимает документ ЭОД от источника 304, ЭОД-транзакции могут включать в документ ID транзакции "850". Однако информация о версии или информация о целевой области имен определяется во время выполнения, и значения этих пунктов конфигурации могут конфигурироваться на различных уровнях. Поэтому после применения правил в соответствии со стандартами ЭОД (например, X12 или EDIFACT) для декодирования ЭОД-транзакции в соответствии с соответствующими типами транзакций (например, заказом на поставку, счетом-фактурой и т.п.) ЭОД-механизм 312 идентифицирует пункты конфигурации в декодированных ЭОД-транзакциях. В одном варианте осуществления ЭОД-механизм 312 идентифицирует пункты конфигурации из одного или нескольких уровней конфигурации, таких как партнерский уровень и уровень отправляющего приложения, глобальный уровень, конвейерный уровень или стандартный уровень.

Например, на фиг.7B приведен "снимок экрана" с изображением пунктов конфигурации в конфигурации на уровне сторон. В данном примере ID 850 транзакции для вышеуказанного партнера, приведенной на фиг.7A, сконфигурирован для использования целевой области имен и информации о версии, приведенных выше. Для всех других типов документов используются стандартные значения, поскольку указан флаг или параметр "стандартный" (default), как показано в рамке 714. В другом примере другой торговый партнер может установить другие конкретные пункты конфигурации при конфигурации на уровне сторон на основе деловых соглашений, установленных между деловыми торговыми партнерами. Вместо статического определения значения пунктов конфигурации варианты осуществления изобретения при автоматической идентификации схем идентифицируют значения пунктов конфигурации посредством определения конкретных значений, которые установлены торговыми партнерами из одного или нескольких уровней конфигурации.

В одном варианте осуществления значения пунктов конфигурации при конфигурации на уровне сторон могут быть сконфигурированы равными значениям, отличным от тех, что приведены в DocType на фиг.7A, вследствие конкретного сочетания Id отправителя и Id транзакции. Например, в X12 каждый Id отправителя может представлять некоторый отдел на предприятии. Поэтому ID отправителя на одном предприятии может означать отдел "товаров аппаратного обеспечения", тогда как другой ID отправителя может означать отдел "товаров программного обеспечения" на том же предприятии. Таким образом, варианты осуществления изобретения распознают эти различные конфигурации и идентифицируют схемы соответствующим образом. В результате, один и тот же заказ на поставку от одного предприятия может подвергаться идентификационному процессу по различным схемам, так чтобы генерировались соответствующие и различные данные ЭОД в XML, например, в объединенном документе 314 ЭОД в соответствии со значениями пунктов конфигурации.

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

На фиг.7C приведен "снимок экрана", иллюстрирующий схему EDIFACT с ее конфигурацией на уровне сторон. В этом примере в отличие от схем X12 целевая область имен может быть сконфигурирована на основе конкретного сочетания ID приложения отправителя (необязательно) (такого как UNG2.1 в 716 и UNG2.2 в 718), версии 720 (UNG8) и ID транзакционного набора 722. Иными словами, можно иметь множество конфигураций для документа ЭОД со счетом-фактурой, каждая из которых имеет уникальный ID приложения. В данном примере во время выполнения будет использоваться целевая область имен, соответствующая конкретному приложению. В ситуации, когда никакой ID приложения отправителя не сконфигурирован, значение ID приложения отправителя может сопоставляться с любым значением из имеющихся записей (например, регистрационных файлов), которые содержат тот же самый ID транзакции. В случае обнаружения множества соответствий используется стандартная целевая область имен, чтобы обеспечить использование подходящего стандартного значения в случае, когда имеется неоднозначность.

На фиг.7D приведен снимок экрана, иллюстрирующий конфигурацию глобального уровня для схемы X12. В данном примере в случае, когда пункты конфигурации, такие как целевая область имен или версия, не заданы торговыми партнерами, используются значения пунктов конфигурации в конфигурации глобального уровня. В данном примере рамка 724 указывает, что значения для версии и целевой области имен не сконфигурированы. Поэтому значения пунктов конфигурации не меняются во время выполнения.

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