Elektroniczna wymiana danych - Electronic data interchange

Elektroniczna wymiana danych ( EDI ) to koncepcja firm przekazujących elektronicznie informacje, które tradycyjnie były przekazywane na papierze, takie jak zamówienia i faktury. Istnieją standardy techniczne dla EDI, aby ułatwić stronom przeprowadzanie transakcji takimi instrumentami bez konieczności dokonywania specjalnych ustaleń.

EDI istnieje co najmniej od wczesnych lat 70-tych i istnieje wiele standardów EDI (w tym X12 , EDIFACT , ODETTE , itp.), z których niektóre odpowiadają na potrzeby konkretnych branż lub regionów. Odnosi się również konkretnie do rodziny norm. W 1996 roku Narodowy Instytut Standardów i Technologii zdefiniował elektroniczną wymianę danych jako „wymianę między komputerami ściśle sformatowanych komunikatów, które reprezentują dokumenty inne niż instrumenty pieniężne. EDI oznacza sekwencję komunikatów między dwiema stronami, z których każda może służyć jako nadawca lub odbiorca. Sformatowane dane reprezentujące dokumenty mogą być przekazywane od nadawcy do odbiorcy za pomocą telekomunikacji lub fizycznie transportowane na elektronicznych nośnikach pamięci." Wyróżnia on zwykłą komunikację elektroniczną lub wymianę danych, stwierdzając, że „w EDI zwykłe przetwarzanie otrzymanych wiadomości odbywa się wyłącznie za pomocą komputera. sytuacji. Na przykład transmisja danych binarnych lub tekstowych nie jest EDI, jak zdefiniowano tutaj, chyba że dane są traktowane jako jeden lub więcej elementów danych komunikatu EDI i nie są zwykle przeznaczone do interpretacji przez człowieka w ramach przetwarzania danych online. Krótko mówiąc, EDI można zdefiniować jako transfer danych strukturalnych, zgodnie z uzgodnionymi standardami komunikatów, z jednego systemu komputerowego do drugiego bez interwencji człowieka.

Historia

Podobnie jak wiele innych wczesnych technologii informatycznych, EDI zostało zainspirowane rozwojem logistyki wojskowej . Złożoność berlińskiego transportu powietrznego z 1948 r. wymagała opracowania koncepcji i metod wymiany, czasem ponad 300 bodów modemu dalekopisowego , ogromnych ilości danych i informacji o przewożonych towarach. Te początkowe koncepcje ukształtowały później pierwsze standardy TDCC (Komitetu Koordynacji Danych Transportowych) w USA. Wśród pierwszych zintegrowanych systemów wykorzystujących EDI były Freight Control Systems. Jednym z takich systemów czasu rzeczywistego był London Airport Cargo EDP Scheme (LACES) na lotnisku Heathrow w Londynie w Wielkiej Brytanii w 1971 r. Wdrożenie metody bezpośredniego wprowadzania danych handlowca (DTI) umożliwiło spedytorom wprowadzanie informacji bezpośrednio do systemu przetwarzania celnego , skracając czas odprawy. Wzrost ruchu morskiego i problemy celne podobne do tych, które miały miejsce na lotnisku Heathrow doprowadziły do ​​wdrożenia systemów DTI w poszczególnych portach lub grupach portów w latach 80-tych.

Normy

EDI zapewnia techniczną podstawę dla zautomatyzowanych handlowych „rozmów” między dwoma podmiotami, wewnętrznymi lub zewnętrznymi. Termin EDI obejmuje cały proces elektronicznej wymiany danych, w tym transmisję, przepływ komunikatów, format dokumentu i oprogramowanie używane do interpretacji dokumentów. Jednak standardy EDI opisują rygorystyczny format dokumentów elektronicznych, a standardy EDI zostały zaprojektowane, początkowo w przemyśle motoryzacyjnym, jako niezależne od technologii komunikacyjnych i oprogramowania.

Dokumenty EDI zazwyczaj zawierają te same informacje, które normalnie można znaleźć w dokumencie papierowym używanym do tej samej funkcji organizacyjnej. Na przykład zamówienie EDI 940 wysyłka z magazynu jest używane przez producenta, aby poinformować magazyn, aby wysłał produkt do sprzedawcy. Zazwyczaj zawiera adres „dostawy”, adres odbiorcy płatności oraz listę numerów produktów (zwykle UPC ) i ilości. Innym przykładem jest zestaw wiadomości między sprzedającymi a kupującymi, takich jak zapytanie ofertowe (RFQ), oferta w odpowiedzi na ZO, zamówienie zakupu, potwierdzenie zamówienia zakupu, powiadomienie o wysyłce, awiza o odbiorze, faktura i awiza płatności. Jednak EDI nie ogranicza się tylko do danych biznesowych związanych z handlem, ale obejmuje wszystkie dziedziny, takie jak medycyna (np. rejestry pacjentów i wyniki laboratoryjne), transport (np. informacje o kontenerach i modalnych), inżynieria i budownictwo itp. W niektórych przypadkach EDI zostanie wykorzystany do stworzenia nowego przepływu informacji biznesowych (który wcześniej nie był przepływem papieru). Tak jest w przypadku zaawansowanego powiadomienia o wysyłce (ASN), które zostało zaprojektowane w celu poinformowania odbiorcy przesyłki, towarów, które mają zostać odebrane oraz sposobu ich pakowania. Jest to dodatkowo uzupełnione wykorzystaniem przez przesyłkę etykiet wysyłkowych zawierających kod kreskowy GS1-128 odnoszący się do numeru śledzenia przesyłki.

Niektóre główne zestawy standardów EDI:

  • ONZ -recommended UN / EDIFACT jest jedynym międzynarodowym standardem i jest dominującym poza Ameryką Północną.
  • W Ameryce Północnej dominuje amerykański standard ANSI ASC X12 (X12).
  • Zestaw standardów GS1 EDI opracował GS1 dominujący w globalnym łańcuchu dostaw
  • Standard TRADACOMS opracowany przez stowarzyszenie ANA (artykuł numeryczny obecnie znany jako GS1 UK ) dominuje w branży detalicznej w Wielkiej Brytanii .
  • Standard ODETTE stosowany w europejskim przemyśle motoryzacyjnym
  • Standard VDA stosowany w europejskim przemyśle motoryzacyjnym głównie w Niemczech
  • HL7 , standard interoperacyjności semantycznej stosowany do danych dotyczących opieki zdrowotnej.
  • HIPAA , ustawa o przenośności i odpowiedzialności w ubezpieczeniach zdrowotnych (HIPAA), wymaga od milionów podmiotów opieki zdrowotnej, które elektronicznie przesyłają dane, do korzystania z EDI w standardowym formacie HIPAA.
  • IATA Cargo-IMP , IATA Cargo-IMP to skrót od International Air Transport Association Cargo Interchange Message Procedures. Jest to standard EDI oparty na EDIFACT stworzony w celu automatyzacji i standaryzacji wymiany danych pomiędzy liniami lotniczymi i innymi podmiotami.
  • Skrypt NCPDP , SCRIPT to standard opracowany i utrzymywany przez Krajową Radę Programów Leków na Receptę (NCPDP). Norma definiuje dokumenty do elektronicznego przesyłania recept lekarskich w Stanach Zjednoczonych.
  • Standard telekomunikacyjny NCPDP obejmuje transakcje weryfikacji uprawnień, rozliczanie roszczeń i usług, wstępne ustalanie świadczeń, uprzednią autoryzację oraz raportowanie informacji i jest stosowany głównie w Stanach Zjednoczonych.
  • Edig@s (EDIGAS) to standard zajmujący się handlem, transportem (gazociągiem lub kontenerem) i magazynowaniem gazu.

Wiele z tych standardów pojawiło się po raz pierwszy na początku do połowy lat 80-tych. Standardy określają formaty, zestawy znaków i elementy danych używane w wymianie dokumentów i formularzy biznesowych. Pełna lista dokumentów X12 zawiera wszystkie główne dokumenty biznesowe, w tym zamówienia zakupu i faktury.

Standard EDI określa obowiązkowe i opcjonalne informacje dla konkretnego dokumentu oraz podaje zasady struktury dokumentu. Normy są jak przepisy budowlane. Tak jak dwie kuchnie można zbudować „ według kodu ”, ale wyglądają zupełnie inaczej, tak dwa dokumenty EDI mogą być zgodne z tym samym standardem i zawierać różne zestawy informacji. Na przykład firma spożywcza może wskazać datę ważności produktu, podczas gdy producent odzieży prześle informacje o kolorze i rozmiarze.

Protokoły transmisji

EDI może być przesyłany przy użyciu dowolnej metodologii uzgodnionej przez nadawcę i odbiorcę, ale ponieważ coraz więcej partnerów handlowych zaczęło używać Internetu do transmisji, pojawiły się standaryzowane protokoły.

Obejmuje to różne technologie, w tym:

Kiedy niektórzy porównywali modemy protokołu synchronicznego 2400 bit/s, urządzenia CLEO i sieci o wartości dodanej używane do przesyłania dokumentów EDI z przesyłaniem przez Internet, utożsamiali technologie nieinternetowe z EDI i błędnie przewidywali, że samo EDI zostanie zastąpione wraz z technologiami nieinternetowymi. W większości przypadków te nieinternetowe metody transmisji są po prostu zastępowane protokołami internetowymi , takimi jak FTP, HTTP, telnet i e-mail, ale same dokumenty EDI nadal pozostają.

W 2002 roku IETF opublikował RFC 3335, oferując ustandaryzowaną, bezpieczną metodę przesyłania danych EDI za pośrednictwem poczty e-mail. 12 lipca 2005 r. grupa robocza IETF ratyfikowała dokument RFC4130 dla transferów HTTP EDIINT opartych na MIME (aka AS2 ), a IETF przygotował podobny dokument RFC dla transferów FTP (aka AS3 ). EDI za pośrednictwem usług internetowych (aka AS4 ) zostało również ustandaryzowane przez organ normalizacyjny OASIS. Podczas gdy część transmisji EDI została przeniesiona na te nowsze protokoły, dostawcy sieci o wartości dodanej pozostają aktywni.

Internet

W miarę jak coraz więcej organizacji łączyło się z Internetem, w końcu większość lub całość EDI została zepchnięta na niego. Początkowo odbywało się to za pomocą konwencji ad hoc, takich jak niezaszyfrowany FTP plików tekstowych ASCII do określonego folderu na określonym hoście, dozwolony tylko z określonych adresów IP. Jednak IETF opublikowała kilka dokumentów informacyjnych („Oświadczenia dotyczące stosowania”; patrz poniżej w części Protokoły ) opisujących sposoby wykorzystania standardowych protokołów internetowych dla EDI.

Od 2002 roku Walmart promuje AS2 dla EDI. Ze względu na swoją znaczącą obecność w globalnym łańcuchu dostaw, AS2 stało się powszechnie przyjętym podejściem dla EDI.

Specyfikacje

Organizacje, które wysyłają lub odbierają dokumenty między sobą, są określane jako „partnerzy handlowi” w terminologii EDI. Partnerzy handlowi uzgadniają, jakie konkretne informacje mają być przekazywane i jak powinny być wykorzystywane. Odbywa się to w specyfikacjach czytelnych dla człowieka (zwanych również wytycznymi dotyczącymi implementacji wiadomości). Chociaż normy są analogiczne do przepisów budowlanych, specyfikacje są analogiczne do planów. (Specyfikacja może być również nazywana „mapowanie”, ale odwzorowanie termin jest zazwyczaj zarezerwowane dla konkretnych instrukcji odczytu maszynowego danych do oprogramowania tłumaczenia.) Większe handlu „piasty” już istniejące wytyczne Wiadomość wdrożenia, które odzwierciedlają ich procesów biznesowych do przetwarzania EDI i zazwyczaj nie chcą modyfikować swoich praktyk biznesowych EDI w celu zaspokojenia potrzeb swoich partnerów handlowych. Często w dużej firmie wytyczne EDI są napisane tak, aby były wystarczająco ogólne, aby mogły być używane przez różne oddziały lub oddziały, a zatem będą zawierać informacje, które nie są potrzebne do konkretnej wymiany dokumentów biznesowych. W przypadku innych dużych firm mogą tworzyć osobne wytyczne EDI dla każdego oddziału/oddziału.

Transmisja: bezpośredni EDI i VAN

Partnerzy handlowi mogą swobodnie korzystać z dowolnej metody przesyłania dokumentów (jak opisano powyżej w sekcji Protokoły transmisji). Ponadto mogą wchodzić w interakcje bezpośrednio lub za pośrednictwem pośrednika.

Bezpośredni EDI: peer-to-peer

Partnerzy handlowi mogą łączyć się bezpośrednio ze sobą. Na przykład producent samochodów może utrzymywać pulę modemów, z którą wszystkie setki dostawców muszą się połączyć, aby przeprowadzić EDI. Jeśli jednak dostawca prowadzi interesy z kilkoma producentami, może być zmuszony nabyć inny modem (lub urządzenie VPN itp.) i inne oprogramowanie dla każdego z nich.

Wraz z rozwojem technologii EDI i sieci web, pojawiły się nowe technologie oprogramowania EDI, aby ułatwić bezpośredni (znany również jako punkt-punkt) EDI między partnerami handlowymi . Nowoczesne oprogramowanie EDI może ułatwić wymianę przy użyciu dowolnej liczby różnych protokołów transmisji plików i standardów dokumentów EDI, zmniejszając koszty i bariery wejścia.

Sieci o wartości dodanej

Aby rozwiązać ograniczenia w stosowaniu EDI w sieciach peer-to-peer, dziesiątki lat temu ustanowiono sieci VAN (sieci z wartością dodaną) . VAN działa jako regionalny urząd pocztowy. Odbiera transakcje, analizuje informacje „od” i „do” i kieruje transakcję do końcowego odbiorcy. VANy mogą świadczyć szereg usług dodatkowych, np. retransmisję dokumentów, dostarczanie informacji audytowych stron trzecich, pełnienie roli bramy dla różnych metod transmisji oraz obsługę wsparcia telekomunikacyjnego. Ze względu na te i inne usługi oferowane przez sieci VAN firmy często korzystają z sieci VAN, nawet jeśli obaj partnerzy handlowi korzystają z protokołów internetowych. Biura rozliczeniowe opieki zdrowotnej pełnią wiele takich samych funkcji jak VAN, ale mają dodatkowe ograniczenia prawne.

VANy mogą być obsługiwane przez różne podmioty:

  • firmy telekomunikacyjne;
  • konsorcja grup branżowych;
  • duża firma współpracująca ze swoimi dostawcami/sprzedawcami;
  • dostawcy usług zarządzanych.

Koszty, kompromisy i wdrożenie

Należy zauważyć, że istnieją kluczowe kompromisy między sieciami VAN i Direct EDI, aw wielu przypadkach organizacje wymieniające dokumenty EDI mogą w rzeczywistości używać obu razem, dla różnych aspektów ich implementacji EDI. Na przykład w Stanach Zjednoczonych większość wymiany dokumentów EDI korzysta z AS2, więc bezpośrednia konfiguracja EDI dla AS2 może mieć sens dla organizacji z siedzibą w USA. Jednak dodanie funkcji OFTP2 do komunikacji z europejskim partnerem może być trudne, więc VAN może mieć sens do obsługi tych konkretnych transakcji, podczas gdy bezpośredni EDI jest używany do transakcji AS2.  

Pod wieloma względami VAN działa jako dostawca usług, upraszczając wiele konfiguracji dla organizacji, które chcą zainicjować EDI. Ze względu na fakt, że wiele organizacji zaczynających od EDI często robi to, aby spełnić wymagania klienta lub partnera, a zatem brakuje im własnego doświadczenia w zakresie EDI, VAN może być cennym zasobem.

Jednak sieci VAN mogą wiązać się z wysokimi kosztami. Sieci VAN zazwyczaj pobierają opłatę transakcyjną za dokument lub nawet za pozycję w celu przetwarzania transakcji EDI jako usługi w imieniu swoich klientów. Jest to główny powód, dla którego wiele organizacji wdraża również oprogramowanie EDI lub ostatecznie migruje do niego dla części lub całości swojego EDI.

Z drugiej strony, wdrożenie oprogramowania EDI może być trudnym procesem, w zależności od złożoności przypadku użycia, zaangażowanych technologii i dostępności wiedzy eksperckiej EDI. Ponadto należy wziąć pod uwagę bieżące wymagania konserwacyjne i aktualizacje. Na przykład mapowanie EDI jest jednym z najtrudniejszych zadań zarządzania EDI. Firmy muszą opracowywać i utrzymywać mapy EDI dla każdego ze swoich partnerów handlowych (a czasami wiele map EDI dla każdego partnera handlowego w oparciu o ich wymagania dotyczące realizacji zamówień). Wymagania EDI mogą zmieniać się wiele razy w roku. Za każdym razem, gdy zmienia się wymóg EDI, zespół wewnętrzny musi aktualizować mapy.

Inne czasochłonne zadania EDI obejmują komunikację z partnerami handlowymi, rozwiązywanie błędów EDI i testowanie EDI.

Aby rozwiązać te problemy, wiele organizacji z mniej sprawnymi zespołami IT – lub bez specjalistów IT – współpracuje z dostawcą pełnego zakresu usług EDI. Dostawcy pełnego zakresu usług EDI przejmują odpowiedzialność za zarządzanie wymaganiami EDI i zapewnienie ciągłej zgodności.

Interpretacja danych

Oprogramowanie do tłumaczenia EDI zapewnia interfejs między systemami wewnętrznymi a wysyłanym/odbieranym formatem EDI. W przypadku dokumentu „przychodzącego” rozwiązanie EDI odbierze plik (za pośrednictwem sieci z wartością dodaną lub bezpośrednio przy użyciu protokołów takich jak FTP lub AS2), pobierze odebrany plik EDI (powszechnie nazywany „kopertą”) oraz sprawdzić, czy partner handlowy wysyłający plik jest ważnym partnerem handlowym, struktura pliku spełnia standardy EDI oraz czy poszczególne pola informacji są zgodne z uzgodnionymi standardami. Zazwyczaj tłumacz albo tworzy plik o stałej długości, zmiennej długości lub w formacie ze znacznikami XML, albo „wydrukowuje” otrzymany dokument EDI (dla niezintegrowanych środowisk EDI). Następnym krokiem jest przekonwertowanie/przekształcenie pliku tworzonego przez tłumacza do formatu, który można zaimportować do wewnętrznych systemów biznesowych, aplikacji lub ERP firmy. Można to osiągnąć za pomocą niestandardowego programu, zintegrowanego, zastrzeżonego „mappera” lub zintegrowanego graficznego „mappera” opartego na standardach, używając standardowego języka transformacji danych, takiego jak XSLT . Ostatnim krokiem jest zaimportowanie przekształconego pliku (lub bazy danych) do systemu zaplecza firmy.

W przypadku dokumentu „wychodzącego” proces zintegrowanego EDI polega na wyeksportowaniu pliku (lub odczytaniu bazy danych) z systemów informatycznych firmy i przekształceniu pliku do formatu odpowiedniego dla tłumacza. Oprogramowanie do tłumaczenia następnie "sprawdzi" wysłany plik EDI, aby upewnić się, że spełnia on standard uzgodniony przez partnerów handlowych, przekonwertuje plik do formatu "EDI" (dodając odpowiednie identyfikatory i struktury kontrolne) i wyśle ​​plik do biura handlowego partner (przy użyciu odpowiedniego protokołu komunikacyjnego).

Innym krytycznym elementem każdego oprogramowania do tłumaczenia EDI jest kompletny „audyt” wszystkich etapów przenoszenia dokumentów biznesowych między partnerami handlowymi. Audyt zapewnia, że ​​każda transakcja (która w rzeczywistości jest dokumentem biznesowym) może być śledzona w celu zapewnienia, że ​​nie zostaną utracone. W przypadku sprzedawcy detalicznego wysyłającego Zamówienie zakupu do dostawcy, jeśli Zamówienie zakupu zostanie „utracone” w dowolnym miejscu procesu biznesowego, skutki są druzgocące dla obu firm. Dostawcy nie realizują zamówienia, ponieważ nie otrzymali go, tracąc w ten sposób interesy i niszcząc relacje biznesowe z klientem detalicznym. Sprzedawcy mają przestoje w magazynie, co skutkuje utratą sprzedaży, gorszą obsługą klienta i ostatecznie niższymi zyskami.

W terminologii EDI „przychodzące” i „wychodzące” odnoszą się do kierunku transmisji dokumentu EDI w odniesieniu do konkretnego systemu, a nie kierunku towarów, pieniędzy lub innych rzeczy reprezentowanych przez dokument. Na przykład dokument EDI, który nakazuje magazynowi wykonanie wysyłki wychodzącej, jest dokumentem przychodzącym w odniesieniu do systemu komputerowego magazynu. Jest to dokument wychodzący w odniesieniu do producenta lub sprzedawcy, który przesłał dokument.

Przewaga nad systemami papierowymi

EDI i inne podobne technologie oszczędzają pieniądze firmy, zapewniając alternatywę dla lub zastępując przepływy informacji, które wymagają dużej interakcji międzyludzkiej i dokumentów papierowych. Nawet gdy dokumenty papierowe są utrzymywane równolegle z wymianą EDI, np. drukowane manifesty wysyłkowe, wymiana elektroniczna i wykorzystanie danych z tej wymiany zmniejszają koszty obsługi sortowania, dystrybucji, organizowania i przeszukiwania dokumentów papierowych. EDI i podobne technologie pozwalają firmie czerpać korzyści z elektronicznego przechowywania i manipulowania danymi bez kosztów ręcznego wprowadzania danych. Kolejną zaletą EDI jest możliwość ograniczenia lub wyeliminowania błędów ręcznego wprowadzania danych, takich jak błędy wysyłki i fakturowania, ponieważ EDI eliminuje potrzebę ponownego wprowadzania dokumentów po stronie docelowej. Bardzo ważną zaletą EDI nad dokumentami papierowymi jest szybkość, z jaką partner handlowy otrzymuje i włącza informacje do swojego systemu, co znacznie skraca czas cyklu. Z tego powodu EDI może być ważnym elementem systemów produkcyjnych just-in-time.

Według raportu Aberdeen z 2008 r. „Porównanie możliwości dostawców na całym świecie”, tylko 34% zamówień jest przesyłanych elektronicznie w Ameryce Północnej. W regionie EMEA 36% zamówień jest przesyłanych drogą elektroniczną, aw regionie Azji i Pacyfiku 41% zamówień jest przesyłanych drogą elektroniczną. Podają również, że średnie zapotrzebowanie na papier do zamówienia kosztuje firmę 37,45 USD w Ameryce Północnej, 42,90 USD w regionie EMEA i 23,90 USD w regionie Azji i Pacyfiku. Przy zamówieniu EDI koszty są zredukowane do 23,83 USD w Ameryce Północnej, 34,05 USD w regionie EMEA i 14,78 USD w regionie Azji i Pacyfiku.

Bariery we wdrażaniu

Istnieje kilka barier w przyjęciu elektronicznej wymiany danych. Jedną z najważniejszych barier jest towarzysząca temu zmiana procesów biznesowych. Istniejące procesy biznesowe zbudowane wokół obsługi papieru mogą nie być odpowiednie dla EDI i wymagają zmian w celu dostosowania do automatycznego przetwarzania dokumentów biznesowych. Na przykład firma może otrzymać większość swoich towarów w ciągu 1 lub 2 dni, a wszystkie faktury pocztą. Istniejący proces może zatem zakładać, że towar zazwyczaj odbierany jest przed wystawieniem faktury. Dzięki EDI faktura jest zazwyczaj wysyłana w momencie wysyłki towarów i dlatego będzie wymagać procesu, który obsługuje dużą liczbę faktur, których odpowiednie towary nie zostały jeszcze odebrane.

Kolejną istotną barierą jest koszt czasu i pieniędzy w początkowej konfiguracji. Wstępne wydatki i czas związane z wdrożeniem, dostosowaniem i szkoleniem mogą być kosztowne. Ważne jest, aby wybrać odpowiedni poziom integracji, aby pasował do wymagań biznesowych. W przypadku firmy, która ma stosunkowo niewiele transakcji z partnerami opartymi na EDI, może mieć sens wdrożenie niedrogich rozwiązań typu „zgrywaj i czytaj”, w których format EDI jest drukowany w formie czytelnej dla człowieka , a ludzie — a nie komputery — odpowiadają do transakcji. Inną alternatywą są outsourcingowe rozwiązania EDI dostarczane przez "Biura Serwisu" EDI. W przypadku innych firm wdrożenie zintegrowanego rozwiązania EDI może być konieczne, ponieważ wzrost wolumenu obrotu spowodowany przez EDI zmusza je do ponownego wdrożenia procesów biznesowych związanych z przetwarzaniem zamówień.

Kluczową przeszkodą w udanym wdrożeniu EDI jest postrzeganie przez wiele firm charakteru EDI. Wielu postrzega EDI z technicznego punktu widzenia, że ​​EDI jest formatem danych; trafniejsze byłoby przyjęcie biznesowego punktu widzenia, że ​​EDI jest systemem wymiany dokumentów biznesowych z podmiotami zewnętrznymi i integracji danych z tych dokumentów z systemami wewnętrznymi firmy. Pomyślne wdrożenia EDI uwzględniają wpływ informacji generowanych zewnętrznie na ich systemy wewnętrzne i weryfikują otrzymane informacje biznesowe. Na przykład umożliwienie dostawcy aktualizacji systemu rozliczeń sprzedawcy detalicznego bez odpowiednich kontroli i sald naraziłoby firmę na znaczne ryzyko. Firmy, które dopiero zaczynają wdrażać EDI, muszą rozumieć leżący u podstaw proces biznesowy i stosować właściwy osąd.

Potwierdzenie

Poniżej znajdują się wspólne potwierdzenia EDI

  • Status komunikacji – wskazuje, że transmisja została zakończona
  • MDN (Message Disposition Notification) – Tylko w AS2 wskaż, że wiadomość jest czytelna
  • Potwierdzenie funkcjonalne — zwykle „997” w ANSI lub „CONTRL” w EDIFACT, które wskazują, że treść wiadomości jest weryfikowana w odniesieniu do jej szablonu i informuje, czy transakcja jest księgowana w systemie elektronicznym odbiorcy.
  • Potwierdzenie poziomu biznesowego – końcowy wskaźnik pokazuje, czy transakcja została zaakceptowana przez odbiorcę, czy nie.

Zobacz też

Protokoły
Formaty
Formaty o stałej długości
  • EURITMO
Formaty separatora

Bibliografia

Dalsza lektura

  • Gengeswari, K. i Abu Bakar Abdul Hamid (2010). „Integracja elektronicznej wymiany danych: przegląd”, Jurnal Kemanusiaan , ISSN  1675-1930

Linki zewnętrzne