Електронен обмен на данни (EDI)
Какво представлява електронният обмен на данни (EDI)?
Електронният обмен на данни (EDI) представлява обмен между компютри на структурирани бизнес документи между организации чрез използване на договорени стандарти. В логистиката, електронната търговия и международната търговия той позволява на системи, управлявани от купувачи, доставчици, складове, превозвачи и други търговски партньори, да обменят информация като поръчки за покупка, известия за изпращане, транспортни инструкции и фактури, без да е необходимо хората да въвеждат повторно всеки документ.
Определящата характеристика на EDI не е просто това, че информацията се изпраща по електронен път. Информацията е организирана в полета, сегменти и съобщения, които получаващият софтуер може да интерпретира съгласно договорена спецификация. Следователно фактура, прикрепена към имейл като PDF, сама по себе си не е EDI фактура: все още може да е необходимо лице или инструмент за обработка на документи да извлече съдържанието ѝ, преди бизнес системата да може да го използва.
EDI описва метод за обмен на бизнес информация, а не един конкретен софтуерен продукт, мрежа или файлов формат. Работещото споразумение зависи от съвместими дефиниции на документи, методи за комуникация, идентификатори и бизнес правила.
EDI в логистиката и електронната търговия
EDI свързва дейности, които преминават границите на организациите. Системата за покупки на търговец може да генерира поръчка, системата на доставчик може да я потвърди, а складът може да получи инструкции за подготовка на стоките. След това информацията за пратката и фактурите могат да се прехвърлят между съответните системи като отделни съобщения.
В електронната търговия EDI може да поддържа бизнес процесите между организации, които стоят зад витрина, ориентирана към крайни потребители. Например онлайн търговец може да го използва, за да поръчва наличности от доставчик или да обменя информация за изпълнение на поръчки със склад. Транзакцията при плащане на потребителя и последващите EDI съобщения на търговеца са свързани бизнес събития, но не са непременно една и съща транзакция и не използват непременно един и същ технически интерфейс.
При трансгранична търговия EDI може да пренася необходимата информация за международен транспорт и търговска документация. Митническите администрации също могат да използват структурирани електронни съобщения съгласно собствените си спецификации. Обменът на EDI съобщение с доставчик или превозвач обаче сам по себе си не представлява митническа декларация, не установява съответствие с нормативните изисквания и не разрешава освобождаването на стоките.
Често срещани бизнес документи
Следващите примери илюстрират функциите на документите, а не задължителна последователност. Използваните съобщения зависят от търговските отношения и приложимото ръководство за внедряване.
| Документ или съобщение | Бизнес цел | Пример от логистиката или електронната търговия |
|---|---|---|
| Поръчка за покупка | Съобщава поръчка на купувача за стоки или услуги. | Търговец поръчва стоки за попълване на наличностите от доставчик. |
| Отговор или потвърждение на поръчка | Съобщава отговора на доставчика на дадена поръчка. | Доставчик потвърждава количествата или предлага промени, когато договореното съобщение ги поддържа. |
| Предварително известие за изпращане или съвет за експедиция | Описва пратка, преди тя да пристигне. | Складът получава информация за очакваните кашони, артикули и количества. |
| Транспортна инструкция | Съобщава инструкции за транспортна услуга. | Изпращач изпраща договорени подробности за превоза до транспортен партньор. |
| Съобщение за статуса на пратката | Съобщава транспортно събитие или статус. | Превозвач съобщава събитие, свързано с пратка. |
| Фактура | Съобщава информация за таксуване. | Доставчик таксува търговец за доставени стоки. |
Предварителното известие за изпращане, често съкращавано като ASN, описва очаквана пратка; то не доказва, че стоките са пристигнали. По същия начин съобщението за статуса на пратката не е автоматично доказателство за доставка. Значението му зависи от съобщеното събитие и съпътстващата информация.
Стандарти, формати и методи за комуникация
EDI стандартите определят как са структурирани бизнес съобщенията и какво означават техните елементи от данни. Две утвърдени семейства стандарти са X12 и правилата на ООН за електронен обмен на данни за администрация, търговия и транспорт, известни като UN/EDIFACT. GS1 също поддържа EDI стандарти, включително EANCOM, който се основава на UN/EDIFACT, както и GS1 XML.
В рамките на X12 примерите включват 850 Purchase Order, 856 Ship Notice/Manifest и 810 Invoice. UN/EDIFACT предоставя съобщения като ORDERS за поръчки за покупка, DESADV за съвети за експедиция и INVOIC за фактури. Тези примери имат сходни бизнес цели в различните стандарти, но структурите и изискванията за внедряване не са взаимозаменяеми.
Сам по себе си един стандарт не определя всеки детайл от търговските отношения. Партньорите трябва също да се договорят за приложимата версия и ръководството за внедряване, задължителните полета, разрешените кодове, идентификаторите и правилата за валидиране. Две организации могат да поддържат едно и също семейство стандарти и въпреки това да се нуждаят от работа по съпоставянето, преди системите им да могат да обменят използваеми съобщения.
| Компонент | Какво определя | Пример |
|---|---|---|
| Стандарт за съобщения | Структурата и значението на бизнес съобщението. | X12 фактура или UN/EDIFACT съвет за експедиция. |
| Ръководство за внедряване | Как конкретно съобщение се използва в търговските отношения. | Задължителни идентификатори на пратката и разрешени мерни единици за количество. |
| Метод за комуникация | Как съобщението се прехвърля между системите. | AS2 или договорено сигурно прехвърляне на файлове. |
| Превод и съпоставяне | Как полетата от външното съобщение съответстват на вътрешните данни на приложението. | Съпоставяне на входящ ред от поръчка със запис в системата за управление на поръчки. |
AS2 е комуникационна спецификация за обмен на бизнес данни чрез HTTP, с механизми за сигурност и потвърждения за получаване. Той не е формат за поръчки за покупка или фактури. Мрежа с добавена стойност, или VAN, може да предоставя посреднически услуги за обмен на съобщения; тя също се различава от стандарта за бизнес документи.
Как работи един EDI обмен
- Бизнес събитие създава данни. Например купувач одобрява поръчка за покупка в система за планиране на ресурсите на предприятието или система за управление на поръчки.
- Данните се съпоставят в съобщение. Софтуерът за превод преобразува вътрешните полета в структурата, изисквана от договорения стандарт и ръководството за внедряване.
- Изходящото съобщение се проверява. Валидирането може да проверява синтаксиса, задължителните полета, стойностите на кодовете и специфичните изисквания на партньора.
- Съобщението се предава. То преминава по договорения комуникационен канал до получателя или посредник.
- Получателят го валидира и превежда. Получаващата система проверява съобщението и съпоставя приетата информация с вътрешния формат на приложението.
- Следва бизнес обработка. Получаващото приложение може да създаде поръчка, да запише очаквано получаване или да насочи изключение за преглед.
- Отговорите се съгласуват. Техническите потвърждения, потвържденията за получаване и бизнес отговорите помагат на подателя да определи какво се е случило с обмена.
Тези стъпки не гарантират, че всяка транзакция ще бъде обработена автоматично. Неизвестен идентификатор на продукт, невалидно място за доставка, дублиран номер на документ или неподдържана мерна единица могат да изискват намеса дори когато съобщението е структурно валидно.
Получаване, валидиране и бизнес приемане
EDI потвържденията функционират на различни нива. Потвърждението за транспорт може да покаже, че съобщението е достигнало комуникационна крайна точка. Функционалното потвърждение или потвърждението за внедряване може да съобщи резултатите от структурните проверки. Бизнес отговорът може да съобщи дали поръчка или друго искане е прието, отхвърлено или променено.
Тези сигнали не трябва да се приемат за еквивалентни. Успешното предаване не означава непременно, че поръчката е приета или че стоките ще бъдат изпратени. Конкретното значение на потвърждението трябва да се тълкува съгласно съответната спецификация и споразумението с търговския партньор.
Илюстративен пример от поръчка до изпращане
Търговец може да изпрати поръчка за покупка до чуждестранен доставчик чрез EDI. Системата на доставчика проверява идентификаторите на продуктите, количествата и поисканата информация за доставка. Ако търговското споразумение включва отговор на поръчка, доставчикът може да съобщи приемането или предложените промени чрез отделно съобщение.
Когато стоките са подготвени, доставчикът може да издаде предварително известие за изпращане, идентифициращо пратката и нейното съдържание. Получаващият склад може да използва тази информация, за да се подготви за получаването и да сравни очакваните количества с действително получените стоки. Доставчикът може също да изпрати фактура за обработка във финансовата система на търговеца.
Този пример показва как EDI свързва записите между организациите. Той не означава, че всяка страна използва един и същ софтуер, че всяко съобщение се доставя в реално време или че търговските документи заменят транспортните и митническите изисквания. Съпоставянето на поръчки за покупка, референции на пратки и фактури все още изисква последователни идентификатори и договорена бизнес логика.
EDI и свързани технологии
| Свързана концепция | Връзка с EDI | Важно разграничение |
|---|---|---|
| Интерфейс за програмиране на приложения (API) | Интерфейс, чрез който софтуерът обменя заявки и данни. | EDI поставя акцент върху стандартизирани бизнес съобщения; API определя взаимодействието със софтуерна услуга. Двете могат да съществуват едновременно. |
| XML | Език за маркиране, използван за структуриране на данни. | Самият XML синтаксис не установява договорен стандарт за бизнес съобщения. |
| Електронно фактуриране | Електронно издаване и обмен на фактури. | EDI може да поддържа електронно фактуриране, но правните и техническите изисквания се различават според юрисдикцията. |
| ERP или система за управление на склад | Приложение, което създава или използва бизнес информация. | Тези системи управляват операциите; EDI предоставя начин за обмен на информация с други организации. |
| Проследяване на пратки | Съобщаване и интерпретиране на събитията по пратката. | EDI може да пренася информация за статус, но сам по себе си не е уебсайт за проследяване или цялостна услуга за проследяване. |
EDI и API не са взаимно изключващи се алтернативи във всяка архитектура. Организация може да използва EDI съобщения за транзакции с партньори и API за свързване на тези транзакции с вътрешни приложения. Подходящото решение зависи от изискванията към документите, възможностите на партньорите, нуждите от своевременност и оперативния контрол, а не само от названието на технологията.
Съображения и ограничения при внедряване
EDI може да намали многократното ръчно въвеждане на данни, когато системите успешно обменят и обработват съвместими съобщения. Той не коригира неточни изходни данни, не разрешава търговски спорове и не премахва необходимостта от обработка на изключения. Автоматизацията зависи както от техническата съвместимост, така и от качеството на обменяната бизнес информация.
Преди установяване на EDI връзка търговските партньори трябва да изяснят следните оперативни въпроси:
- Обхват на документите: Кои съобщения са задължителни и кои бизнес събития ги задействат?
- Идентификатори: Как ще бъдат идентифицирани и съпоставяни продуктите, местата, страните, поръчките и пратките?
- Изисквания към съобщенията: Кои версии, задължителни полета, списъци с кодове и правила за съпоставяне се прилагат?
- Комуникация и сигурност: Кой метод за свързване, механизми за удостоверяване и контроли за достъп са необходими?
- Потвърждения: Кои отговори показват доставяне, валидиране и бизнес приемане?
- Обработка на изключения: Кой разследва отхвърлени съобщения, липсващи отговори и несъответстващи данни?
- Предотвратяване на дублирания: Как повторните изпращания ще бъдат разграничавани от новите бизнес транзакции?
- Тестване и контрол на промените: Как ще бъдат тествани съпоставянията и изискванията на партньорите, преди промените да влязат в продукция?
Оперативното наблюдение трябва да различава комуникационните грешки от грешките при валидиране на данни и бизнес изключенията. Повторното изпращане на съобщение може да отстрани неуспешно предаване, но няма да поправи невалиден продуктов код. Без контрол на дублиранията повторното изпращане на успешно обработена поръчка може също да създаде нежелана втора транзакция.
Въпроси и отговори
Какво означава EDI в логистиката?
EDI означава електронен обмен на данни: структуриран обмен на бизнес документи между системи. В логистиката тези документи могат да включват известия за изпращане, транспортни инструкции, фактури и съобщения за статуса на пратката.
Имейл PDF документ ли е EDI документ?
Не сам по себе си. PDF може да представя бизнес документ по електронен път, но EDI изисква структурирана информация, която получаващите системи могат да интерпретират съгласно договорена спецификация.
EDI същото ли е като API?
Не. EDI се отнася до стандартизиран обмен на бизнес документи, докато API определя как софтуерът взаимодейства с друга услуга. Една интеграция може да използва и двете.
Означава ли потвърждението за EDI, че поръчката е приета?
Не непременно. Потвържденията могат да потвърждават предаването или структурното валидиране, а не бизнес приемането. Типът на съобщението и споразумението с търговския партньор определят значението му.
Източници
- UNECE: UN/EDIFACT — Официална рамка за структуриран електронен обмен на административни, търговски и транспортни данни.
- X12: Transaction Sets — Официални описания на наборите от бизнес транзакции, включително поръчки за покупка, фактури, известия за изпращане и потвърждения.
- GS1: Electronic Data Interchange — Стандарти за бизнес съобщения и връзката между GS1 EDI, EANCOM и GS1 XML.
- RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 — Транспорт на AS2, механизми за сигурност и известия за получаване.
