Подключение торговых партнеров к EDI сопровождается, в том числе, и подписанием «Соглашения» , в котором отражаются применяемые стандарты и наборы сервисов.
Договор об электронном обмене документами между двумя партнерами содержит описание EDI-документов, которые участвуют в обмене и способы их передачи. Так же в Спецификации требуется описать какие поля и какие сегменты партнер будет отправлять или ожидает получить для выполнения транзакции. В данном случае, не имеет значения какой EDI-документ (отчет, инвойс, каталог, проверка достоверности страхового полиса и т.д.) планируется передавать. Таким образом оба торговых партнера знают какого рода и в каком формате они получат данные. Не существует строго заданного требования того, как должен выглядеть этот документ, который часто называют «Соглашение между торговыми партнерами». Это может быть как специально набранный документ, так и файл, формат которого будет рассмотрен ниже.
Что же является «опциональным», а что «требуемым» в этом документе? Луше всего это излагает гуру EDI Харольд ДеВайнт (Harold DeWayne):
«По моему опыту, «обязательным» является выполнение положений стандартов (X12, EDIFACT,..) и как, следствие, провайдеров и трансляторов. «Требования» же, в основном, задаются одним из партнеров и означают: «Мы требуем это для нашего собственного использования.»
Спецификации EDI.
По большому счету, EDI-спецификация – это набор правил, определяющих каждый тип документа, сегментов, которые он содержи, размер и тип данных элементов. Когда мы говорим о стандартной EDI-спецификации, то имеем ввиду полный набор допустимых типов EDI-документов. Если какие-то данные являются EDI документом, то они описаны в стандартной EDI-спецификации. Однако, эта огромная, всеохватывающая спецификация — не самый полезный документ в деле координации обмена документами между двумя партнерами.
Что происходит в пользовательской EDI-спецификации?
Таким образом, мы берем Стандартную спецификацию и уменьшаем ее, убирая неиспользуемые элементы и закодированные значения в сегментах, которые будут использоваться. В этот момент создается Пользовательская EDI-спецификация (Договор между торговыми партнерами). К этой спецификации можно добавлять необходимые значения. Например, создать опциональное значение или идентификатор, который требует одна из сторон, и определить тип этих параметров.
Как применяется Пользовательская спецификация?
Созданная Пользовательская спецификация, призвана выполнять следующие базовые функции:
- Служит источником информации для интеграции процессов EDI-обмена документами;
- Является критерием, по которому сверяется формат EDI-документов с тем, чтобы выполнить корректную транзакцию;
- Определяет источник данных и интеграционных документов.
Важно, чтобы варианты использования и информация о работе EDI-интерфейса была отмечена в Пользовательской спецификации.
Помимо визуализированного представления, многие спецификации могут представлены в виде SEF-файла, который будет использован специальным проверяющим EDI-приложением. Таким образом могут быть созданы огромные файлы, обеспечивающие соответствие требованиям клиентов и корректность данных. SEF (Standards Exchange Format)– формат обмена стандартами. Некоторые приложения используют SEF-файлы при создании своих документов и процессов проверки данных. Как же устроен SEF-файл? В действительности это обычный текстовый файл! Она содержит «разделы»: типы документов, сегменты, элементы, закодированные данные. Также могут быть включены номер версии и название. SEF был создан в ответ на возникшую потребность автоматического анализа EDI-файла компьютерным приложением.
SEF используется только тогда, когда происходит обмен стандартами применения формата. Он может быть создан в виде PDF или электронной таблицы.
Существует множество полезных разработок. После создания Пользовательской спецификации, может потребоваться инструмент для проверки выполнения новым партнером всех указанных в нем требований.