電子データ交換

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

電子データ交換EDI)は、発注書や請求書など、従来は紙で伝達されていた情報を電子的に伝達する企業の概念です。EDIの技術基準は、特別な取り決めをすることなく、そのような商品を取引する当事者を容易にするために存在します。

EDIは少なくとも70年代初頭から存在しており、多くのEDI標準(X12EDIFACTODETTEなどを含む)があり、その一部は特定の業界または地域のニーズに対応しています。また、特に一連の標準を指します。1996年、米国国立標準技術研究所電子データ交換を「データ交換のための標準化されたフォーマットのコンピュータ間交換。EDIは、発信者または受信者として機能する可能性のある2者間の一連のメッセージを意味します。ドキュメントを表すフォーマットされたデータは送信される可能性があります。発信者から受信者まで、電気通信を介して、または電子ストレージメディアで物理的に転送されます。」これは単なる電子通信またはデータ交換を区別し、「EDIでは、受信メッセージの通常の処理はコンピューターのみによるものです。受信メッセージの処理への人間の介入は、通常、エラー状態、品質レビュー、および特別な目的でのみ意図されています。状況。たとえば、[1]要するに、EDIは、合意されたメッセージ標準によって、人間の介入なしに、あるコンピュータシステムから別のコンピュータシステムに構造化データを転送することとして定義できます。

歴史

他の多くの初期の情報技術と同様に、EDIは兵站の発展に触発されました。1948年のベルリン空輸の複雑さは、時には300ボーのテレタイプモデムを超える、輸送された商品に関する膨大な量のデータと情報を交換するための概念と方法の開発を必要としました。これらの初期の概念は、後に米国で最初のTDCC(輸送データ調整委員会)標準を形成しました。[2]EDIを使用した最初の統合システムには、貨物管理システムがありました。そのようなリアルタイムシステムの1つは、1971年に英国ロンドンのヒースロー空港で開催されたロンドン空港貨物EDPスキーム(LACES)でした。直接トレーダー入力(DTI)方式を実装することで、転送エージェントは税関処理システムに直接情報を入力できました。 、クリアランスの時間を短縮します。海上交通の増加とヒースロー空港で経験したのと同様の税関での問題により、1980年代に個々のまたは港のグループにDTIシステムが導入されました。[3]

標準

EDIは、内部または外部の2つのエンティティ間の自動化された商用「会話」の技術的基盤を提供します。EDIという用語は、送信、メッセージフロー、ドキュメント形式、およびドキュメントの解釈に使用されるソフトウェアを含む、電子データ交換プロセス全体を含みます。ただし、EDI標準は、電子ドキュメントの厳密な形式を記述しており、EDI標準は、当初は自動車業界で、通信およびソフトウェアテクノロジから独立するように設計されていました。

EDIドキュメントには通常、同じ組織機能に使用される紙のドキュメントに通常見られるのと同じ情報が含まれています。たとえば、EDI 940の倉庫からの出荷注文は、製品を小売業者に出荷するように倉庫に指示するために製造業者によって使用されます。通常、「出荷先」住所、「請求先」住所、および製品番号(通常はUPC)と数量のリストがあります。もう1つの例は、見積もりの​​リクエストなど、売り手と買い手の間の一連のメッセージです。(RFQ)、RFQに応じた入札、発注書、発注書の確認、出荷通知、アドバイスの受け取り、請求書、および支払いのアドバイス。ただし、EDIは貿易に関連するビジネスデータだけに限定されるものではなく、医学(患者の記録や検査結果など)、輸送(コンテナやモーダル情報など)、エンジニアリングや建設などのすべての分野を網羅しています。 EDIは、新しいビジネス情報フローを作成するために使用されます(以前は紙のフローではありませんでした)。これは、出荷の受領者、受領する商品、および商品の梱包方法を通知するように設計されたAdvanced Shipment Notification(ASN)の場合です。これは、貨物の追跡番号を参照するGS1-128バーコードを含む貨物ラベルの貨物の使用によってさらに補完されます。[4]

EDI標準のいくつかの主要なセット:[5]

  • 国連が推奨するUN/EDIFACTは唯一の国際基準であり、北米以外で優勢です。
  • 米国標準ANSIASCX12(X12)は、北米で優勢です。
  • GS1 EDIの一連の標準は、グローバルサプライチェーンで優勢なGS1を開発しました
  • ANA(現在GS1UKとして知られているArticleNumber Association)によって開発されたTRADACOMS標準英国の小売業界で支配的です。
  • 欧州の自動車業界で使用されているODETTE規格
  • 主にドイツのヨーロッパの自動車産業で使用されているVDA規格
  • HL7、ヘルスケアデータに使用されるセマンティック相互運用性標準。
  • HIPAA(医療保険の相互運用性と説明責任に関するACT(HIPAA))では、データを電子的に送信する何百万もの医療機関が、標準のHIPAA形式でEDIを使用する必要があります。
  • IATA Cargo-IMP、IATA Cargo-IMPは、International Air Transport Association Cargo InterchangeMes​​sageProceduresの略です。これは、航空会社と他の関係者との間のデータ交換を自動化および標準化するために作成されたEDIFACTに基づくEDI標準です。
  • NCPDPスクリプト、SCRIPTは、National Council for Prescription Drug Program(NCPDP)によって開発および保守されている標準です。この規格は、米国で処方箋を電子的に送信するための文書を定義しています。
  • NCPDP Telecommunications標準には、適格性の検証、請求とサービスの請求、特典の事前決定、事前承認、および情報レポートのトランザクションが含まれており、主に米国で使用されています。
  • Edig @ s(EDIGAS)は、商取引、輸送(パイプラインまたはコンテナ経由)、およびガスの貯蔵を扱う標準です。

これらの規格の多くは、1980年代初頭から中期に最初に登場しました。この規格では、ビジネスドキュメントやフォームの交換に使用される形式、文字セット、およびデータ要素が規定されています。完全なX12ドキュメントリストには、発注書や請求書を含むすべての主要なビジネスドキュメントが含まれています。

EDI標準は、特定のドキュメントの必須およびオプションの情報を規定し、ドキュメントの構造に関する規則を示しています。標準は建築基準法のようなものです。2つのキッチンを「コード化」して構築できるが、外観が完全に異なるのと同じように、2つのEDIドキュメントは同じ標準に従い、異なる情報セットを含むことができます。たとえば、食品会社が製品の有効期限を示し、衣料品メーカーが色とサイズの情報を送信することを選択する場合があります。

伝送プロトコル

EDIは、送信者と受信者が合意した任意の方法を使用して送信できますが、送信にインターネットを使用するトレーディングパートナが増えるにつれて、標準化されたプロトコルが登場しました。

これには、次のようなさまざまなテクノロジーが含まれます。

一部の人々がEDIドキュメントの送信に使用される同期プロトコル2400ビット/秒モデム、CLEOデバイス、および付加価値通信網をインターネット経由の送信と比較したとき、彼らは非インターネット技術をEDIと同一視し、EDI自体が置き換えられると誤って予測しました非インターネット技術と一緒に。ほとんどの場合、これらの非インターネット送信方法は、FTP、HTTP、telnet、電子メール などのインターネットプロトコルに置き換えられているだけですが、EDIドキュメント自体はまだ残っています。

2002年に、IETFはRFC 3335を公開し、電子メールを介してEDIデータを転送する標準化された安全な方法を提供しました。2005年7月12日、IETFワーキンググループはMIMEベースのHTTP EDIINT(別名AS2 )転送用にRFC4130を承認し、IETFはFTP転送(別名AS3 )用に同様のRFCを準備しましたWebサービス(別名AS4)を介したEDIも、OASIS標準化団体によって標準化されています。一部のEDI送信はこれらの新しいプロトコルに移行しましたが、付加価値通信網のプロバイダーは引き続きアクティブです。

インターネット

インターネットに接続する組織が増えるにつれ、最終的にはほとんどまたはすべてのEDIがインターネットにプッシュされました。当初、これは、特定のIPアドレスからのみ許可された、特定のホスト上の特定のフォルダーへのASCIIテキストファイルの暗号化されていないFTPなどのアドホックな規則によるものでした。ただし、IETFは、EDIに標準のインターネットプロトコルを使用する方法を説明する いくつかの情報ドキュメント(「適用性ステートメント」。以下のプロトコルを参照)を公開しています。

2002年の時点で、ウォルマートはEDI用にAS2をプッシュしています。[6]グローバルサプライチェーンにおけるその重要な存在のために、AS2はEDIに一般的に採用されているアプローチになっています。

仕様

相互にドキュメントを送受信する組織は、EDI用語では「トレーディングパートナ」と呼ばれます。トレーディングパートナは、送信される特定の情報とその使用方法について合意します。これは、人間が読める形式の仕様(メッセージ実装ガイドラインとも呼ばれます)で行われます。標準は建築基準法に類似していますが、仕様は青写真に類似しています。(仕様は「マッピング」と呼ばれることもありますが、マッピングという用語は通常、翻訳ソフトウェアに与えられる特定の機械可読命令用に予約されています[7]。)大規模な取引「ハブ」には、ビジネスプロセスを反映した既存のメッセージ実装ガイドラインがあります。EDIを処理するためであり、通常、取引先のニーズを満たすためにEDIビジネス慣行を変更することを望んでいません。多くの場合、大企業では、これらのEDIガイドラインは、さまざまな支店や部門で使用できるほど一般的であるように作成されているため、特定のビジネスドキュメント交換に必要のない情報が含まれています。他の大企業の場合、支店/部門ごとに個別のEDIガイドラインを作成する場合があります。

送信:直接EDIおよびVAN

トレーディングパートナは、ドキュメントの送信に任意の方法を自由に使用できます(上記の送信プロトコルのセクションで説明されています)。さらに、それらは直接または仲介者を介して相互作用することができます。

直接EDI:ピアツーピア

トレーディングパートナは互いに直接接続できます。たとえば、自動車メーカーは、EDIを実行するために数百のサプライヤすべてがダイヤルインする必要があるモデムプールを維持している場合があります。ただし、サプライヤが複数のメーカーと取引をしている場合は、それぞれに異なるモデム(またはVPNデバイスなど)と異なるソフトウェアを入手する必要があります。

EDIとWebテクノロジーが進化するにつれて、トレーディングパートナ間の直接(ポイントツーポイントとも呼ばれる)EDIを容易にする新しいEDIソフトウェアテクノロジーが登場しました。最新のEDIソフトウェアは、さまざまなファイル送信プロトコルとEDIドキュメント標準を使用して交換を容易にし、コストと参入障壁を削減します。

付加価値通信網

EDIのピアツーピア採用の制限に対処するために、VAN(付加価値通信網)が数十年前に設立されました。VANは地域の郵便局として機能します。トランザクションを受信し、「from」および「to」情報を調べて、トランザクションを最終的な受信者にルーティングします。VANは、ドキュメントの再送信、サードパーティの監査情報の提供、さまざまな送信方法のゲートウェイとしての機能、通信サポートの処理など、いくつかの追加サービスを提供する場合があります。VANが提供するこれらのサービスやその他のサービスのために、両方の取引先がインターネットベースのプロトコルを使用している場合でも、企業はVANを頻繁に使用します。ヘルスケアクリアリングハウスは、VANと同じ機能の多くを実行しますが、追加の法的制限があります。

VANは、さまざまなエンティティによって運用される場合があります。

  • 電気通信会社;
  • 業界グループコンソーシアム;
  • サプライヤー/ベンダーとやり取りする大企業。
  • マネージドサービスプロバイダー。

コスト、トレードオフ、および実装

VANとダイレクトEDIの間には重要なトレードオフがあることに注意することが重要です[8]。多くの場合、EDIドキュメントを交換する組織は、実際には、EDI実装のさまざまな側面で両方を連携して使用できます。たとえば、米国では、EDIドキュメント交換の大部分がAS2を使用しているため、AS2の直接EDIセットアップは、米国を拠点とする組織にとって意味がある場合があります。ただし、ヨーロッパのパートナーと通信するためにOFTP2機能を追加するのは難しい場合があるため、AS2トランザクションには直接EDIが使用されているのに対し、VANはこれらの特定のトランザクションを処理するのに意味がある場合があります。  

多くの点で、VANはサービスプロバイダーとして機能し、EDIの開始を検討している組織のセットアップの多くを簡素化します。EDIを最初に開始する多くの組織は、顧客またはパートナーの要件を満たすためにそうすることが多く、したがって社内のEDIの専門知識が不足しているため、VANは貴重な資産になる可能性があります。

ただし、VANには高額な費用がかかる場合があります。VANは通常、顧客に代わってEDIトランザクションをサービスとして処理するために、ドキュメントごと、またはラインアイテムごとのトランザクション料金を請求します[9]これが、多くの組織がEDIソフトウェアソリューションを実装したり、最終的にEDIの一部またはすべてを1つに移行したりする主な理由です。

一方、EDIソフトウェアの実装は、ユースケースの複雑さ、関連するテクノロジー、およびEDIの専門知識の可用性によっては、困難なプロセスになる可能性があります。さらに、考慮すべき継続的なメンテナンス要件と更新があります。たとえば、EDIマッピングは最も困難なEDI管理タスクの1つです。企業は、各トレーディングパートナのEDIマップを開発および維持する必要があります(注文処理の要件に基づいて、各トレーディングパートナの複数のEDIマップを作成する場合もあります)。

データの解釈

EDI翻訳ソフトウェア内部システムと送受信されるEDIフォーマット間のインターフェースを提供します。「インバウンド」ドキュメントの場合、EDIソリューションはファイルを受信し(付加価値通信網を介して、またはFTPやAS2などのプロトコルを直接使用して)、受信したEDIファイル(一般に「エンベロープ」と呼ばれます)を取得し、ファイルを送信しているトレーディングパートナが有効なトレーディングパートナであること、ファイルの構造がEDI標準を満たしていること、および個々の情報フィールドが合意された標準に準拠していることを検証します。通常、トランスレータは、固定長、可変長、またはXMLタグ付き形式のファイルを作成するか、受信したEDIドキュメントを「印刷」します(統合されていないEDI環境の場合)。次のステップは、翻訳者が作成したファイルを、会社のバックエンドビジネスシステム、アプリケーション、またはERPにインポートできる形式に変換/変換することです。これは、カスタムプログラム、統合された独自の「マッパー」、または統合された標準ベースのグラフィカルな「マッパー」を使用して、次のような標準のデータ変換言語を使用することで実現できます。XSLT最後のステップは、変換されたファイル(またはデータベース)を会社のバックエンドシステムにインポートすることです。

「アウトバウンド」ドキュメントの場合、統合EDIのプロセスは、企業の情報システムからファイルをエクスポート(またはデータベースを読み取る)し、ファイルを翻訳者に適した形式に変換することです。次に、翻訳ソフトウェアは、送信されたEDIファイルを「検証」して、トレーディングパートナが合意した基準を満たしていることを確認し、ファイルを「EDI」形式に変換して(適切な識別子と制御構造を追加)、ファイルをトレーディングに送信します。パートナー(適切な通信プロトコルを使用)。

EDI翻訳ソフトウェアのもう1つの重要なコンポーネントは、トレーディングパートナ間でビジネスドキュメントを移動するためのすべてのステップの完全な「監査」です。監査により、トランザクション(実際にはビジネスドキュメント)を追跡して、トランザクションが失われないようにすることができます。小売業者が発注書をサプライヤに送信する場合、発注書がビジネスプロセスのどこかで「失われた」場合、その影響は両方のビジネスに壊滅的な影響を及ぼします。サプライヤにとっては、注文を受け取っていないために注文を履行できず、それによってビジネスが失われ、小売クライアントとのビジネス関係が損なわれます。小売業者にとって、彼らは在庫切れを抱えており、その影響は売上の損失、顧客サービスの低下、そして最終的には利益の低下につながります。

EDIの用語では、「インバウンド」および「アウトバウンド」は、特定のシステムに関連するEDIドキュメントの送信方向を指し、ドキュメントによって表される商品、お金、またはその他のものの方向ではありません。たとえば、倉庫に出荷を実行するように指示するEDI伝票は、倉庫コンピュータシステムに関連する入庫伝票です。これは、ドキュメントを送信したメーカーまたはディーラーに関連するアウトバウンドドキュメントです。

紙のシステムに対する利点

EDIおよびその他の同様のテクノロジーは、大量の人的介入と紙の文書を必要とする情報フローの代替または代替を提供することにより、会社のコストを節約します。紙の文書がEDI交換と並行して維持されている場合でも、たとえば、印刷された出荷マニフェスト、電子交換、およびその交換からのデータの使用により、紙の文書の並べ替え、配布、整理、および検索の処理コストが削減されます。EDIおよび同様のテクノロジーにより、企業は、手動入力のコストをかけずに、データを電子的に保存および操作するという利点を活用できます。EDIのもう1つの利点は、配送や請求のエラーなどの手動のデータ入力エラーを削減または排除できることです。これは、EDIにより、宛先側でドキュメントのキーを再入力する必要がなくなるためです。紙の文書に対するEDIの非常に重要な利点の1つは、トレーディングパートナが情報を受信して​​システムに組み込む速度が、サイクルタイムを大幅に短縮することです。このため、EDIはジャストインタイム生産システムの重要なコンポーネントになる可能性があります。[10]

2008年のアバディーンレポート「世界中のサプライヤーの有効性の比較」によると、北米では発注書の34%のみが電子的に送信されます。EMEAでは、注文の36%が電子的に送信され、APACでは、注文の41%が電子的に送信されます。彼らはまた、注文するための平均的な紙の要求は、北米で37.45ドル、EMEAで42.90ドル、APACで23.90ドルかかると報告しています。注文するEDI要求により、コストは北米で23.83ドル、EMEAで34.05ドル、APACで14.78ドルに削減されます。

実装の障壁

電子データ交換を採用することにはいくつかの障壁があります。最も重要な障壁の1つは、付随するビジネスプロセスの変更です。紙の取り扱いを中心に構築された既存のビジネスプロセスはEDIに適していない可能性があり、ビジネスドキュメントの自動処理に対応するために変更が必要になります。たとえば、企業は商品の大部分を1日または2日の配送で受け取り、すべての請求書を郵送で受け取る場合があります。したがって、既存のプロセスでは、通常、商品は請求書の前に受け取られると想定する場合があります。EDIを使用すると、請求書は通常、商品の出荷時に送信されるため、対応する商品がまだ受け取られていない多数の請求書を処理するプロセスが必要になります。

もう1つの重要な障壁は、初期設定の時間と費用のコストです。実装、カスタマイズ、およびトレーニングから生じる予備的な費用と時間は、コストがかかる可能性があります。ビジネス要件に一致する正しい統合レベルを選択することが重要です。EDIベースのパートナーとの取引が比較的少ない企業の場合、EDI形式が人間が読める形式で印刷される安価な「リップアンドリード」ソリューションを実装することは、企業にとって理にかなっている場合があります。フォーム、およびコンピュータではなく人がトランザクションに応答します。もう1つの代替手段は、EDI「サービスビューロー」が提供するアウトソーシングされたEDIソリューションです。他のビジネスでは、EDIによってもたらされる取引量の増加により、注文処理ビジネスプロセスを再実装する必要があるため、統合EDIソリューションの実装が必要になる場合があります。

EDIの実装を成功させるための主な障害は、多くの企業がEDIの性質を認識していることです。多くの人がEDIをデータ形式であるという技術的な観点から見ています。EDIは、ビジネスドキュメントを外部エンティティと交換し、それらのドキュメントのデータを企業の内部システムに統合するためのシステムであるというビジネスビューをとる方が正確です。EDIの実装を成功させるには、外部で生成された情報が内部システムに与える影響を考慮し、受け取ったビジネス情報を検証します。たとえば、サプライヤが適切なチェックと残高なしで小売業者の買掛金システムを更新できるようにすると、会社は重大なリスクにさらされます。

謝辞

以下は一般的なEDI確認応答です[11]

  • 通信ステータス–送信が完了したことを示します
  • MDN(メッセージ処理通知)– AS2のみで、メッセージが読み取り可能であることを示します
  • 機能確認–通常、ANSIでは「997」、EDIFACTでは「CONTRL」。メッセージの内容がテンプレートに対して検証され、トランザクションが受信者の電子システムに送信されているかどうかを示します。
  • ビジネスレベルの確認–最後のインジケーターは、トランザクションが受信者によって受け入れられたかどうかを示します。

も参照してください

プロトコル
  • HTTP / HTTPS
  • POP3 / SMTP
  • OFTP / OFTP2
  • 石鹸
  • WebDAV
  • X.400
  • EDIINTワーキンググループ:
    • EDIINT AS1(メールトランスポートへの拡張)
    • EDIINT AS2(HTTPトランスポートに基づく)
    • EDIINT AS3(FTPトランスポートに基づく)
    • EDIINT AS4(Webサービスに基づく)
フォーマット
固定長フォーマット
  • EURITMO
セパレーターフォーマット

参照

  1. ^ 「FIPSPUB161-2:電子データ交換(EDI)」米国国立標準技術研究所1996-04-29。2008年5月11日にオリジナルからアーカイブされました。標準撤回:2008-09-02。
  2. ^ ギフキンス、マイク; ヒッチコック、デビッド(1988)。EDIハンドブックロンドン:ブレナムオンライン。
  3. ^ Tweddle、Douglas(1988)、「EDI in International Trade:a Customs View」、Gifkins、Mike; ヒッチコック、デビッド(編)、EDIハンドブック、ロンドン:ブレナムオンライン
  4. ^ 「EDI856事前出荷通知(ASN)」2019年11月6日取得
  5. ^ 「EDIリソースセンター:EDI標準」
  6. ^ 「AS2およびインターネットEDI–9年後–OpenTextブログ」2011年9月9日。
  7. ^ 「無料のオンラインEDI仕様ライブラリ」
  8. ^ 「EDI:完全なガイドおよびリソースセンター」
  9. ^ アンダーソン、モリー(2019年6月29日)。「オンラインマネー」装飾2019年6月29日取得 {{cite web}}:値を確認|url=する(ヘルプ[永続的なデッドリンク]
  10. ^ 「eコマース-EDIフォーマットの利点」2012年5月30日にオリジナルからアーカイブされました2012年5月3日取得
  11. ^ 「4種類のEDI確認応答の違いは何ですか?-OpenTextブログ」2013年10月21日。

さらに読む

  • Gengeswari、K.およびAbu Bakar Abdul Hamid(2010)。「電子データ交換の統合:レビュー」、Jurnal KemanusiaanISSN 1675-1930 

外部リンク