JP2000148785A - 商取引管理システム - Google Patents

Abstract

(57)【要約】 【課題】１つの事業に対して少なくとも３人以上のユー
ザ（企業、法人など）が関連しながら商取引を管理する
商取引管理システムにおいて、あるユーザにおいて問題
が発生したとしても、事業全体として混乱を招くことな
く効率的で円滑に対処できるようにすることを目的とす
る。 【解決手段】企業間取引における事務処理を電子化した
ＥＤＩを用いた商取引管理システムにおいて、商取引を
行なう１対１の当事者間で前記ＥＤＩによってやり取り
されるＥＤＩデータを、商取引管理を目的とするサーバ
内のデータベースにダウンロードする。該サーバは、商
取引を行なう複数の当事者間の中間位置に配置する。特
に、ＥＤＩデータから所定のデータを抽出してリレーシ
ョナルデータベースを構築するようにする。抽出するの
は、例えば、注文残高、受注残高、納期、在庫残高買掛
高、売掛高などの商取引に関する管理情報である。デー
タベースは、所定の権限を有する者がアクセスできるよ
うにする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、１つの事業に対し
て少なくとも３人以上のユーザ（企業、法人など）が関
連しながら商取引を円滑に管理する商取引管理システム
に関し、特に、受発注管理、納期管理、在庫管理、買掛
金管理、および売掛金管理などの各種の管理を改善する
ことが可能な商取引管理システムに関する。

【０００２】

【従来の技術】一般的に日本における製造業界の生産形
態としては、生産をできるだけ集中させることがより効
率的な生産につながるといえる。なぜなら日本国内では
地域による経済インフラ（人件費、交通機関、通信施設
など）の較差が小さいため、部品調達や生産過程等にお
ける物流コストを最小化することが重要なポイントとな
るためである。

【０００３】しかし、以前より日本国内の人件費を初め
とした生産コストの上昇により、あらゆる業界で海外進
出が盛んに行なわれるようになってきた。現在では、相
手国の経済インフラの状況や生産コストの高低などの各
種の要因に基づき、特定の国や地域での生産に固定する
ことなく複数の選択肢を備えたリスクの分散を図りつ
つ、国別や地域別での長所を組み合わせた国際分業を行
なうようになってきている。

【０００４】このように海外との取引の規模が拡大し、
また取引形態の多様性、迅速性に対する必要性が増す
と、従来のようなＴＥＬＥＸや郵送などによる伝統的な
国際取引の事務処理では効率上問題が生じる。そこで、
それらの企業間取引における事務処理を電子化したＥＤ
Ｉ（Electronic Data Interchange）が用いられるよ
うになっている。

【０００５】図２０は、従来のＥＤＩを示す概念図であ
る。同図において、２００１はＥＤＩプロバイダのサー
バ、２００２は発注者（左側）のシステム、２００３は
受注者（右側）のシステムを示す。発注者と受注者はＥ
ＤＩプロバイダ業者に申し込んでＥＤＩプロバイダに加
入する。ＥＤＩプロバイダは、発注者と受注者との間で
商取引のメッセージを１対１で交換する仕掛けを提供す
る。

【０００６】例えば、発注者が受注者に所定の部品など
を注文したいときは、発注者のシステム２００２から電
子データの注文書を受注者２００３宛のメッセージとし
て送信する。該メッセージを受信したＥＤＩプロバイダ
のサーバ２００１は、受注者２００３宛のメッセージで
あることを認識して、該受注者２００３のメールボック
スに該メッセージを格納する。受注者のシステム２００
３は、ＥＤＩプロバイダのサーバ２００１に接続して、
自分のメールボックスにメッセージが格納されているこ
とを知り、該メッセージをダウンロードする。該メッセ
ージは発注者２００２からの注文書であるので、受注者
２００３は該注文書に応じた各種のアクションを行な
う。例えば、該注文書の注文をすべて受ける場合は該注
文の受領書を発注者２００２宛に送ったり、該注文のす
べてに応じられない場合はその条件を示すメッセージを
発注者２００２宛に送ったり、社内管理システムで該注
文書に応じた生産計画を立てたりすることなどである。

【０００７】通常、発注者や受注者の側ではそれぞれ社
内管理システムを備えており、受発注管理や納期管理な
どの各種の社内管理を行なっている。上述した発注や受
注を行なう場合、各社内管理システムで発注や受注を表
現するデータ形式は各社内の独自の形式である。一方、
ＥＤＩプロバイダ２００１を介して発注者と受注者間で
送受信するメッセージのデータ形式は、発注者と受注者
の両システムで認識できる共通の形式でなければならな
い。そこで、各社内管理システムとＥＤＩプロバイダと
の間には所定のインターフェースを設け、各社内におけ
るデータフォーマットとＥＤＩプロバイダでのデータフ
ォーマットとの間でフォーマット変換を行なうようにな
っている。

【０００８】以上のような従来のＥＤＩプロバイダ２０
０１の機能は「郵便局機能」ということが出来る。すな
わち、２００４に示すように、メッセージ管理、メール
ボックス管理、および課金管理が、ＥＤＩプロバイダの
基本的な機能である。実際の郵便局に対応させると、メ
ッセージ管理は小包、速達、および普通郵便などの管
理、メールボックス管理は宛名の管理、課金管理は切手
の管理に相当する。この中で、ＥＤＩプロバイダ２００
１の仕事は、従来の郵便局が郵便物に対して行なってき
た機能を電子データに置き換えて行なっている形とな
り、ＥＤＩプロバイダ２００１は商取引そのものに関し
ては関与していない。したがって、商取引の管理主体
は、従来と同様、発注者２００２と受注者２００３とい
うことになる。

【０００９】

【発明が解決しようとする課題】上述した現在の企業間
取引に使われているＥＤＩは、基本的に注文書などの従
来より取引に使われて来た関連書類を電子化したという
域に留まっている。つまり、それぞれの売り手と買い手
が、１対１の関係でＥＤＩのメッセージを交換するもの
であり、単に「書類がデータに置き換わった」という媒
体変更に過ぎない。もちろん書類の代わりにデータでや
り取りすれば、このデータを受注システムや生産管理シ
ステムに直接利用することが出来るため、受発注の当事
者は書類に記入されている情報を手作業で自社システム
にインプットする必要がなくなる。しかし、地域間、国
際間の分業体制を構築する段階になってくると、商取引
が複数（３拠点以上）の当事者または関連拠点に有機的
に相互に関連してくる形態をとるため、現在のＥＤＩの
ような売り手と買い手が１対１で繋がる電子商取引の仕
掛けでは十分に管理することができなくなる。

【００１０】例えば、いまＸ社は、Ａ、Ｂ、Ｃの３つの
ブロックから構成される製品を難易度（該ブロックの製
造の難易度）のレベルに対応させて３個所の異なった地
域のＡＡ社、ＢＢ社、ＣＣ社にそれぞれ発注したとす
る。仮にブロックＡの製造過程で問題が起きたとすれ
ば、その問題はブロックＢ，Ｃの生産にも影響する。具
体的には、ブロックＡの問題状況をもとにブロックＢ，
Ｃの生産計画、部品調達状況、在庫内容などを細かく調
整する必要が発生する。これを怠ると、長期在庫品の発
生、キャッシュフローの悪化などの問題が発生する。例
えば、ＡＡ社の工場で事故が起こりブロックＡの生産が
できなくなった場合、ＢＢ社およびＣＣ社でのブロック
Ｂ，Ｃの生産を止めるように連絡をしないと、引き続き
ＢＢ社およびＣＣ社からブロックＢ，ＣがＸ社に次々と
送られてくる。そのため、Ｘ社ではブロックＢ，Ｃの在
庫が増え、またブロックＡが納入されないため最終製品
は生産できないのに、ＢＢ社およびＣＣ社への支払い金
額が増えることになる。

【００１１】このような場合、従来のＥＤＩでは、ブロ
ックＢ，Ｃの生産計画、部品調達状況、在庫内容などの
調整は例えば以下の様な手順になる。ＡＡ社がＸ社に
Ａ製品の生産遅延を連絡する。Ｘ社はＢＢ，ＣＣ社に
ブロックＢ，Ｃの在庫状況、部品調達状況を確認する。
Ｘ社はＢＢ，ＣＣ社からの情報を元にＡＡ社に代替案
を提示する。Ｘ社はＡＡ社の代替案を元に、ＢＢ，Ｃ
Ｃ社に対応策を指示する。

【００１２】上記のやり取りの問題点は次の２点であ
る。ＥＤＩによる情報交換が、発信と受信の１対１の
コミュニケーションで成り立っている点。分担する製
品の日程を管理する主体がそれぞれのブロックを担当す
る拠点（ＡＡ社、ＢＢ社、ＣＣ社）に分散している点。

【００１３】すなわち、従来のＥＤＩでは、１つの最終
製品を完結するための管理が複数の法人などの異なるシ
ステムに分散し、これをＥＤＩのメッセージを介して１
対１で橋渡ししている様な形となっている。このため複
数の当事者間で指示および回答のプロセスが何回も繰り
返される状況がおき、効率的とは言えないし、やり取り
される情報が正確であるという保証もない。また場合に
よっては、指示および回答する時点に時間的な差がある
ことから情報の不一致という問題も発生し当事者間で混
乱を招く恐れもある。

【００１４】本発明は、上述の従来例における問題点に
鑑み、１つの事業に対して少なくとも３人以上のユーザ
（企業、法人など）が関連しながら商取引を管理する商
取引管理システムにおいて、あるユーザにおいて問題が
発生したとしても、事業全体として混乱を招くことなく
効率的で円滑に対処できるようにすることを目的とす
る。

【００１５】

【課題を解決するための手段】上記目的を達成するた
め、請求項１に係る発明は、企業間取引における事務処
理を電子化したＥＤＩを用いた商取引管理システムにお
いて、商取引を行なう１対１の当事者間で前記ＥＤＩに
よってやり取りされるＥＤＩデータを、商取引管理を目
的とするサーバ内のデータベースにダウンロードするこ
とを特徴とする。

【００１６】請求項２に係る発明は、請求項１におい
て、前記ＥＤＩデータから商取引に関する管理情報を取
り出し、その種別ごとにリレーショナルデータベースを
構築することを特徴とする。商取引に関する管理情報と
は、例えば、注文残高、受注残高、納期、在庫残高買掛
高、売掛高などに関する情報である。

【００１７】請求項３に係る発明は、請求項１または２
において、前記データベースから、所定の条件で検索し
たデータを取り出し、該取り出したデータから前記当事
者間の商取引に関する各種管理レポートを作成すること
を特徴とする。

【００１８】請求項４に係る発明は、請求項３におい
て、前記管理レポートを前記サーバ上に蓄積し、所定の
権限を有する者に前記管理レポートを参照許可すること
を特徴とする。

【００１９】請求項５に係る発明は、請求項４におい
て、リアルタイムに発生する商取引の前記ＥＤＩデータ
に連動させて、前記サーバ上のデータベースおよび管理
レポートの内容をリアルタイムに更新することを特徴と
する。

【００２０】請求項６に係る発明は、請求項４におい
て、前記管理レポートにアクセスした者に対して課金す
る手段をさらに備えたことを特徴とする。

【００２１】請求項７に係る発明は、当事者間取引にお
ける事務処理を電子化したＥＤＩを用いた取引管理シス
テムにおいて、前記ＥＤＩに加入した複数の当事者のう
ちの任意の１組の当事者間で１対１の取引を行なうため
のＥＤＩデータをやり取りする手段と、前記１対１でや
り取りされるＥＤＩデータの送受信の経路途中で、該Ｅ
ＤＩデータから所定の商取引に関する管理情報を抽出
し、データベースに登録する手段と、前記複数の当事者
のうち所定のアクセス権限を許可された者に対し、前記
データベースへのアクセスを許可する手段とを備えたこ
とを特徴とする。

【００２２】

【発明の実施の形態】以下、図面を用いて本発明の実施
の形態を説明する。

【００２３】一般的に、ＥＤＩで伝送される情報の内容
は大きく下記の２種類に区別してとらえることが出来
る。 （１）商取引の手続きに関する情報 （２）商取引の管理に関連する情報

【００２４】従来のＥＤＩは上記の２種類の情報が混在
した形で１対１の当事者間を流通している形態としてと
らえることが出来る。これに対し、本発明では、商取引
の手続きに関する情報は従来通り１対１の当事者のみで
管理し、商取引の管理に関連する情報は取引きする者達
の間の中間に置いたサーバに集中してリアルタイムに関
連ユーザ間で情報共有しながら管理する。商取引に関す
る対外部との情報は、各ユーザが持つ社内の内部システ
ムを使って個別に管理するのではなく、１個所（サー
バ）に集中させて、これを関連ユーザが参照しながら情
報共有する形で管理することが特徴である。このために
は、生産管理などの各種管理に伴う情報（商取引の管理
に関連する情報）は、通常のＥＤＩ情報（商取引の手続
きに関する情報）とは区別し、情報の集中化を前提にし
た別個のシステムを商取引の中間地点に作成するのが効
果的である。

【００２５】図１は、本発明の実施の形態のシステムの
概要を示す。１０１はＥＤＩプロバイダのサーバ、１０
２は発注者の社内管理システム、１０３は発注者の社内
管理システム１０２とＥＤＩプロバイダのサーバ１０１
との間のインターフェース、１０４は受注者の社内管理
システム、１０５は受注者の社内管理システム１０４と
ＥＤＩプロバイダのサーバ１０１との間のインターフェ
ースである。ここでは、１人の発注者と１人の受注者と
が商取引を行なう場合に着目して図示したが、１つの製
品を製造する際には、後述するように、その製品を最終
組立するメーカ、最終組立に使う部品となるモデルを製
造するメーカ、そのモデルの部品を製造するメーカ、そ
の部品を構成する材料を製造するメーカなど、種々のメ
ーカが関与するから、それらのメーカ全ては図１のＥＤ
Ｉプロバイダに加入し、それらのメーカ間の商取引は図
１のようにＥＤＩで行なうものとする。

【００２６】ＥＤＩプロバイダのサーバ１０１は、従来
の郵便局機能に加えて、該郵便局機能でやり取りされる
商取引のＥＤＩデータを蓄積し、これを使ってそれぞれ
の商取引の当事者に取引の状態に関する管理データを提
供する機能を持つ。具体的には、ＥＤＩプロバイダのサ
ーバ１０１で、仲介するＥＤＩメッセージを蓄積し、該
ＥＤＩメッセージのデータを商取引共通管理システム１
０６で加工整理し、ユーザがインターネットやエクスト
ラネットを経由して参照できるようにする。この場合、
商取引管理の主体は、従来の発注者と受注者ではなく、
ＥＤＩプロバイダのサーバ１０１に実装されている商取
引共通管理システム１０６にある。発注者の社内管理シ
ステム１０２とインターフェース１０３、および受注者
の社内管理システム１０４とインターフェース１０５
は、従来の図２０の社内管理システムおよびインターフ
ェースと同様のものである。

【００２７】図１のシステムでの処理の流れは以下のよ
うなものである。 (1)取引の中間地点に置かれたＥＤＩプロバイダのサー
バ１０１（商取引共通管理システム１０６が実装されて
いる）は、発注者から送信された商取引のＥＤＩメッセ
ージから、生産、資金、および在庫などの取引管理に利
用できるデータを抽出し、その情報を蓄積する。ＥＤＩ
メッセージからどのデータを抽出して蓄積するかは、あ
らかじめ顧客の了解のもとに決定しておき、ＥＤＩメッ
セージ中の当該データに所定のフラグを立てておく。な
お、事前準備として、ＥＤＩプロバイダのサービスを提
供しようとする事業者は、各地の拠点新設、ＶＡＮtoＶ
ＡＮの契約、業務提携などを通じて広域なＥＤＩのサー
ビス網を作っておく必要がある。また、顧客の拠点、取
引先、事業上の顧客との間でＥＤＩをスタートしてお
く。さらに、事業の形態により情報を集中管理する場所
を決め、商取引管理を行なうサーバ１０１を設置してお
く。 (2)サーバは、蓄積した情報を元にしてリレーショナル
データベースを作成する。 (3)また、サーバ内に、このデータベースを元に、受発
注および生産管理などに関する管理シートを作成する。
管理シートの作成には、ＳＱＬなどのクエリー機能を利
用する。 (4)郵便局機能でやり取りされるＥＤＩメッセージに対
し、常に上記(1)〜(3)の処理を行なうことにより、ＥＤ
Ｉの最新データを元にサーバ上で管理シートのデータを
逐次更新する。 (5)該当プロジェクトや製品などに関連する当事者に対
して、その関与の度合いに応じて開示する情報に制限機
能を付加しておく。要するに、誰にどのデータをアクセ
ス許可するかを決定しておき、サーバにその権限を登録
しておくということである。 (6)関連する当事者がインターネットやエクストラネッ
トを経由してサーバにアクセスし、その権限に応じて、
関連する情報を管理シートで照会する。なお、ＥＤＩプ
ロバイダの業者は、顧客の利用にリンクさせて課金す
る。

【００２８】従来技術の欄で図２０を用いて説明したよ
うに、従来のＥＤＩの基本的考え方は、ＥＤＩの受発注
データを従来の注文書等の書類に置き換えるという考え
方であり、発注側と受注側が１対１の関係が前提となる
情報伝達である。そして、商取引全体の管理は、取引の
当事者がそれぞれの社内システムの中にＥＤＩデータを
取り込むことによって行なっていた。例えば、図２０で
発注者２００２が自社の生産管理システムから、手配済
み部品の納期指示情報をダウンロードし、ＥＤＩプロバ
イダ２００１経由で取引先（受注者）２００３に送る。
取引先２００３はこの指示情報を自社の出荷システム
（社内管理システム）にアップロードし、対応可能かの
チェックを行なう、というようなプロセスである。した
がって、発注者側では発注者の社内システムに、受注者
側では受注者の社内システムに、それぞれ取引の管理の
主体がある。

【００２９】これに対し、図１に示したような本発明に
係るシステムが従来のＥＤＩと大きく異なる点は、従来
それぞれの当事者が社内システムの中で行なってきた商
取引の管理を、取引の中間地点であるＥＤＩプロバイダ
のサーバ上でＥＤＩデータを利用して行なう点である。
したがって、当事者の持つ社内システムとしての受発注
管理システムは、商取引管理としての重要性がなくな
る。商取引は、社外との情報のやり取りであり、売り手
と買い手の別々のシステムで管理するのは管理手法の相
違やデータの同期性などで、複雑、迅速な管理を行うに
は無理が生じる。むしろ管理項目、業務標準まで当事者
で定義した上で、中間サーバで情報共有しながら管理し
た方がシームレスなサプライチェーンを構築するのに有
利である。

【００３０】なお、従来のインターネットの技術を使っ
たサービスとしてバンキングシステムなどがあり、これ
らも本発明と同様、情報を１個所に集中してユーザに公
開するものである。しかし、これらのシステムは、大量
の情報を保有している一方の当事者が、他方の複数の当
事者に対して情報を提供しているという形で、当事者同
士の情報交換としては「１対１」の関係が複数集まって
「１対Ｎ」の関係となっているものである。したがっ
て、従来の「１対１」で情報をやり取りしているＥＤＩ
の関係が複数集まったものと同じとなる。一方、ある製
品を生産する場合は、最終組立作業の前に、ブロック組
立品、部品、材料というそれぞれの段階があり、これら
の段階を繋ぐものとしてそれぞれ商取引が存在する。し
たがって、製品を作るための構成部品は、基礎材料に至
るまでの過程がツリーのように関連づけられているもの
であり、そのようなツリー構造の商取引の系統の中で、
各商取引の管理情報を集めて製品の生産全体を管理する
本発明のシステムは上述の「１対Ｎ」の関係で情報を提
供するシステムとは異なるものである。以下、そのよう
な本発明のシステムが対象としているツリー構造の商取
引の系統について説明する。

【００３１】図２は、ある製品を製作する際の系統図を
示す。製品組立企業２０１がある製品を製作するものと
し、該製品はモデルＡとモデルＢとを用いて最終組立す
ることにより製作するものとする。製品組立企業２０１
は、モデルＡはブロック組立を行なうメーカ２１１に、
モデルＢはブロック組立を行なうメーカ２１２に、それ
ぞれ発注する。ブロック組立を行なうメーカ２１１は、
モデルＡを組立てるための部品を、部品メーカ２２１や
２２２に発注する。部品メーカ２２１は、その部品を製
造するために必要な材料を、材料メーカ２３１や２３２
に発注する。他の部品メーカ２２２でも同様である。さ
らに、材料メーカ２３１は、その材料を製造するために
必要な原料などを別メーカに発注する。モデルＢでも同
様に、ブロック組立、部品製造、および材料製造などの
複数の製造工程が階層状の関係を形作っている。

【００３２】このような各階層間は、企業間の「商取
引」という行為によってつながっている。図２で上位の
メーカと下位のメーカとを結ぶ実線および点線がそれぞ
れ商取引を表す。そのような各商取引は、従来のＥＤＩ
では図２０のような１対１の関係である。したがって、
従来のＥＤＩでは、図２の製品組立企業２０１が管理出
来る商取引は「ブロック組立」を担当するメーカ２１
１，２１２との間の商取引（例えば、受発注情報）のみ
（図２では実線で表す）となる。「部品」や「材料」の
レベルの商取引（図２では点線で表す）については、製
品組立企業２０１は該商取引の当事者では無いため、管
理することはできない。

【００３３】したがって、例えば材料メーカ２３１で事
故などが発生し材料が提供されなくなったとしても、従
来のＥＤＩでは、製品組立企業２０１はそのことを直接
的に知ることができない。材料メーカ２３１から部品メ
ーカ２２１に１対１で連絡がいき、部品メーカ２２１か
らブロック組立メーカ２１１に１対１で連絡がいき、ブ
ロック組立メーカ２１１から製品組立企業２０１に１対
１で連絡がいくという手順で、始めて製品組立企業２０
１は材料が提供されておらず，モデルＡの供給に支障が
出ることを知ることになる。したがって、該情報を得る
までに時間的なタイムラグがあることや、該情報が材料
メーカで発生し部品メーカやブロック組立メーカを経由
してもたらされたことなどから、情報の迅速性や信頼性
が低いという問題がある。

【００３４】一方、図１に示した本発明の実施の形態の
システムによれば、先に述べた様に中間地点（ＥＤＩプ
ロバイダなど）で情報を保有し管理する。図２に示した
各メーカ２０１，２１１，２１２，２２１，２２２，２
３１，２３２，…は、図１で説明したＥＤＩプロバイダ
に加入し、サーバ１０１を介してＥＤＩメッセージのや
り取りができるようにする。これにより、中間でニュー
トラルな位置にあるサーバ１０１において、各メーカ間
の商取引のＥＤＩメッセージから各種のデータを抽出し
て蓄積し情報を集中化する形をとる。これにより、１対
１の商取引の直接当事者でない立場の者であっても、商
取引の管理主体を持つことが出来る。

【００３５】例えば、図２の製品組立企業２０１は、材
料の商取引の当事者ではないが、材料の商取引の管理情
報にアクセスすることができ、材料の供給に問題がある
ことを迅速にかつ正確に知ることができる。これによ
り、従来に無かった理想的なＳＣＭ（サプライチェーン
マネージメント）を実現することが出来る。例えば、日
本に本社を持つ商社が、従来は各拠点からの定期的報告
に頼っていた拠点別のプロジェクトの進行状況、商社全
体としての資金繰りなどが集中管理できることになる。
また、このようにすれば、直接商取引の当事者になって
いなくても、関連する情報を参照しながら、社内の在
庫、資金運用、生産などで最適な管理を行なうことがで
きる。

【００３６】本実施の形態のシステムにおける管理の対
象範囲について説明する。図３は、完成品モデルとそれ
を構成する部品との関係の一例である。ツリー構造は、
その上位に位置するものが、線で結ばれた下位に位置す
るものから作られることを示す。完成品モデル３０１を
構成する部品には、専用品（該当するモデルにしか使え
ない部品）か、標準品（カタログ品の類で、該当するモ
デル以外にも利用でき、市場に標準品として出回ってい
るもの）かの別がある。専用品は、該当モデルの生産に
対して１対１で対応するため、商取引も図２で説明した
ツリーの構造の中で管理できるが、標準品の場合はこの
ような管理は出来ない。なぜなら、標準品を担当する取
引先は、他の顧客向け、最適生産ロット等を考慮しなが
ら生産するため当該モデル向けの受注生産とはならない
ためである。したがって、標準品は、この実施の形態の
システムでの商取引の集中管理の対象にもならない。標
準品は、供給上の問題が発生しても、一般的に代替品の
調達が容易なため当該モデルと関連付ける形の管理を必
要としない。これに対して専用品は、調達ルートが１個
所に限られるため、ここでの問題発生は全体生産に対し
て致命傷になる場合が多く、当該モデルに関連付けた管
理が必要となる。

【００３７】図４は、図１のシステムにおける情報共有
の概念図である。図２で説明した最終製品に至る階層構
造は、商取引という見かたから見ると、最終取引先から
出発して、一次取引先、２次取引先、３次取引先へとつ
ながり、鎖状の形を形成する。このような鎖状の構造
が、一般にサプライチェーンと呼ばれるものである。図
４では、最終顧客（例えば図２の製品組立企業２０１）
４１１から、一時取引先（例えば図２のブロック組立メ
ーカ２１１）４１２、二次取引先（例えば図２の部品メ
ーカ２２１）４１３、三次取引先（例えば図２の材料メ
ーカ２３１）４１４につながるチェーンが、サプライチ
ェーンである。サプライチェーンの各取引は「資材」と
「営業」という窓口が一対となって構成され、そのよう
な各取引で受発注および関連情報の伝達を繰り返すこと
により、サプライチェーンが構成される。この階層、す
なわちサプライチェーンの連鎖の数が増えるにしたが
い、図中の左右の末端同士のコミュニケーションが情報
の正確性、迅速性という観点で問題を生じる。また、い
ろいろな形で人が介在するためコストが嵩む。

【００３８】そこで、本発明では、サプライチェーンの
各取引段階での取引状況を中間に位置する共通データベ
ース４００に登録し、これをアプリケーション４０１を
使って関連付ける。このアプリケーション４０１は、例
えば、あるプロジェクトに関与する取引先が、そのプロ
ジェクトに関連する企業の情報について、何を、どのよ
うなフォーマットで参照できるか、を規定するものであ
る。取引状況の共通データベース４００への登録は、図
１で説明したように、各メーカ間でやり取りされるＥＤ
Ｉメッセージから所定の情報を抽出して蓄積することに
より行なう。アプリケーション４０１により関連付けら
れた情報は、それぞれのメーカが制限に従いながら直接
この共通データベース４００にアクセスし参照する。こ
れによって、個別の商取引の直接の当事者でなくても、
関連情報を参照し情報共有することが出来る。

【００３９】図５は、本実施の形態のシステムの概念図
を示し、ＥＤＩメッセージから所定の情報を抽出して共
通データベースに登録し、該共通データベースのデータ
をアプリケーションを介して各ユーザ（メーカ）にアク
セス可能にする仕組みを示す。同図において、ＥＤＩの
メッセージ（図中、ＥＤＩデータ）はＥＤＩサーバ５０
１を通過して、発注側と受注側との間で送受信される。
このＥＤＩデータ中のユーザの了解を得たデータ（所定
のフラグが立っているデータ）、およびこのサーバ５０
１が宛先になっているデータを、商取引管理サーバ５０
２にダウンロードする。この商取引管理サーバ５０２は
図１の商取引共通管理システムが実装されたサーバであ
り、事業別および顧客別のリレーショナルデータベース
（図４の共通データベース４００）が構築されている。
ユーザのリクエストに対応して、商取引管理アプリケー
ション（図４のアプリケーション４０１）５０３が起動
し、各種の商取引管理レポートが生成される。ユーザ
は、インターネットやエクストラネットを経由して、こ
のサーバ５０２にアクセスし、制限事項にしたがいなが
ら必要な管理データを参照する。

【００４０】図６は、ＥＤＩプロバイダのサーバ（図１
の１０１や図５の５０１）において、受信したＥＤＩデ
ータを共通データベースに登録する手順を示すフローチ
ャートである。まずステップ６０１で、受信したＥＤＩ
データを、ＥＤＩのデータフォーマットからフラットフ
ォーマットへ形式変換する。ステップ６０２では、受信
したＥＤＩデータを種類別（例えば、注文書、納期指
示、売掛高、買掛高、受注残高、請求書などの種類別）
に分類する。ステップ６０３で分類フラグをチェック
し、分類フラグがオンされている場合は当該ＥＤＩデー
タを共通データベースへ登録する対象データとして抽出
する。この分類フラグは、共通データベースに登録する
対象データかどうかを判定するためのフラグであり、あ
らかじめＥＤＩデータに付しておく。ステップ６０４で
は、対象データとして抽出したＥＤＩデータ中の必要な
項目のデータを抽出する。

【００４１】ステップ６０５では、受信日時をデータ内
の指定位置に記入する。ステップ６０６では、データ分
類を行なう。これは、過去に同種のデータを受信して共
通データベースに登録しているかどうかを検索し、あっ
た場合は、今回のデータが何回目のデータであるかを指
定位置に記入する処理である。新規データである場合は
「００１」を記入する。具体的には、今回受信したＥＤ
Ｉデータ中の注文番号と同じ注文番号のデータを共通デ
ータベース中から検索し、その同じ注文番号の中で何回
目の受信データかを数える。この回数のデータにより、
例えば、あとでこのデータを参照するときに当該データ
が新規データであることや変更されていることを示すよ
うに表示したりすることができる。ステップ６０７で
は、ステップ６０１〜６０６で抽出し整理したデータを
共通データベースに登録し、処理を終了する。

【００４２】図７は、図６のステップ６０２，６０３で
分類・抽出するＥＤＩデータの項目例を示す。ここでは
注文書のＥＤＩデータを例に挙げている。図中左端の項
目番号が１３の「Ｐ／Ｏ Ｔｉｔｌｅ」が、ステップ６
０３で抽出する対象データであるかどうかを示す分類フ
ラグである。この欄にプロジェクトコードが記入されて
いるデータは抽出対象とする。

【００４３】図８は、図７のＥＤＩデータからステップ
６０４で必要な項目のみを抽出し他の項目を除いたもの
であり、データベースへの登録用のデータの項目を示
す。図７の項目から、受発注管理に必要な項目だけが抽
出されている。

【００４４】図９は、図８の項目に、さらに項目番号１
のＤａｔａ Ｃｒｅａｔｉｏｎ ｄａｔｅ（受信日時）
の欄とＶｅｒｓｉｏｎ Ｃｏｎｔｒｏｌ（何回目のデー
タかを示すバージョン）の欄を加えたものである。Ｄａ
ｔａ Ｃｒｅａｔｉｏｎ ｄａｔｅの欄には、ステップ
６０５で当該ＥＤＩデータの受信日時を記入する。Ｖｅ
ｒｓｉｏｎ Ｃｏｎｔｒｏｌの欄には、ステップ６０６
で説明した何回目かを示す値を記入する。この図９の項
目のデータが、ステップ６０７で共通データベースに登
録するデータになる。

【００４５】図１０は、上述した共通データベース（商
取引管理サーバのデータベース）の構造を示す。共通デ
ータベースは、顧客（例えば、図２の各メーカ）ごとの
情報からなり、各顧客の情報はプロジェクトごとに分類
された各ＥＤＩメッセージからなる。図１０では、各顧
客ごとにモデル名と該モデルに関するＥＤＩメッセージ
の種類（注文書、納期指示、売掛高、買掛高、受注残
高、請求書など）別に格納する例を示した。図６のステ
ップ６０７では抽出したＥＤＩデータを共通データベー
スに登録するが、具体的には、図９の項目のデータを図
１０のような構造に格納するということである。

【００４６】図１１は、ＥＤＩデータの分類フラグの仕
様例を示す。上述したように、分類フラグは共通データ
ベースに登録する対象データかどうかを判定するために
ＥＤＩデータに付されるフラグであり、例えば図７の例
では項目番号が１３の「Ｐ／Ｏ Ｔｉｔｌｅ」が分類フ
ラグである。図１１のデータは、商取引管理サーバ内に
あらかじめ用意しておく。ステップ６０３では、受信し
たＥＤＩデータの「Ｐ／Ｏ Ｔｉｔｌｅ」が図１１のプ
ロジェクトコードに登録されているか否かをチェック
し、プロジェクトコードが一致したときはさらにＥＤＩ
データの種類が図１１の種類欄に一致するか否かをチェ
ックする。これらが一致したＥＤＩデータを抽出の対象
データとし、一致しないあるいはプロジェクトコードの
記入がないＥＤＩデータは管理対象外としてサーバには
ダウンロードしない。

【００４７】また、図１１の関連法人の欄は、各プロジ
ェクトにおいて、種類欄に記載した種類のＥＤＩデータ
に対して、各関連法人でどのような権限があるかを示
す。ユーザはＥＤＩのメッセージを作成するときに、プ
ロジェクトごとにどの関連法人にデータを公開するか、
このテーブルを使って規定する。具体的には、図１１の
関連法人の欄で、「０」はこのデータをこの関連法人に
公開しないことを示し、「１」はこのデータをこの関連
法人に公開することを示し、「２」はこのデータをこの
関連法人に公開ししかも変更することを認めることを示
す。

【００４８】図１２は、上述の図６の手順でＥＤＩメッ
セージを共通データベースに登録した後、図６で説明し
たように、ユーザがブラウザを用いてインターネットあ
るいはイントラネット経由で商取引管理サーバの共通デ
ータベースにアクセスする手順を示すフローチャートで
ある。ステップ１２０１では、ユーザＩＤおよびパスワ
ードにより、アクセスしてきたユーザの本人確認を行な
う。次に、ステップ１２０２で、ユーザＩＤからアクセ
スしてきたユーザの参照できる範囲を確認し、その範囲
に応じてメニュー画面を作成し、表示する。

【００４９】各ユーザの参照できる範囲は、図１３に示
すようなアクセス制限テーブルに基づいて決定する。図
１３のテーブルにおいて、プロジェクトコードは、最終
製品など、まとまった一塊の事業にユーザが任意のコー
ドを定義したもので、ここでは７桁で「ＸＸＸＸＸＸ
Ｘ」と表す。管理項目分類は、それぞれの管理レポート
を目的別に分類したものである。対象は、それぞれの管
理レポートがどの取引を対象としたものかを定義するも
のである。例えば「Ａ，Ｂ」とは、Ａ社とＢ社との間の
取引が対象という意味である。表中の“Ｙ”は参照可、
“Ｎ”は参照不可を表わす。例えば、Ａ社とＢ社との取
引を対象とした発注管理レポートは、Ａ社とＢ社は参照
可で、Ｃ社とＤ社は参照不可で有ることを表わしてい
る。このユーザアクセス制限テーブルにより、該当モデ
ルの生産の関与の度合いにより、関連する企業は取引の
状態を監視することが出来る。

【００５０】再び図１２に戻って、ステップ１２０３で
は、表示されたメニューにしたがってユーザが必要のあ
る管理レポートをリクエストする操作を行なう。ステッ
プ１２０４では、リクエストされた管理レポートの仕様
情報を表現するクエリーを取得する。クエリーとは、デ
ータベースに対する問い合わせの条件を規定するもので
ある。

【００５１】図１４に、クエリーの処理概念を示す。同
図において、１４０１は、同一プロジェクト関連で複数
の当事者間でやり取りされるＥＤＩ情報を集めた共通デ
ータベースを示す。この共通データベースには、図６で
説明したように、注文書１４１１，１４１２や納期回答
１４１３などの各種のＥＤＩデータが格納されている。
このデータベース１４０１から、クエリーを用いて必要
なメッセージの必要な項目のみを抽出し、所定のフォー
マットに埋め込む形でクエリーレポート１４２１を形成
する。初めてユーザに参照されるデータについては表示
色を変えるなどして強調する。参照後のデータは通常の
表示色に戻す。ＥＤＩデータにより旧データの変更が行
なわれた場合（例えば、納期指示データの指定納期が変
更された場合など）は、旧データをバックグランドとし
て蓄積した上で、新データに更新し、ユーザのニーズに
対応して過去にさかのぼって参照出来るようにする。ク
エリーは、あらかじめ表示させたい管理レポートに応じ
て作成しサーバ上に用意しておくものとする。ＥＤＩデ
ータとクエリーレポートとの関連づけは、プロジェクト
内容や経営ポリシーなどによって異なる。

【００５２】再び図１２に戻って、ステップ１２０５で
は取得したクエリーを用いて共通データベースからデー
タ検索を行ない、ステップ１２０６でそのクエリーレポ
ートを表示する。このとき、新規データは強調色で表示
するものとする。プリントアウトやダウンロードなどの
オプションを付けてもよい。また、ユーザの権限に対応
して画面のデータを変更する。ステップ１２０７では、
ユーザがクエリー画面からデータ訂正した場合、データ
ベースを更新する。新規データ（強調色で表示）は、参
照後、通常表示にフラグ変更する。

【００５３】図１５〜図１８は、ステップ１２０６で表
示するクエリーレポートの例を示す。図１５は、発注管
理に関するクエリーレポートであり、個別発注案件につ
いて、見積もりや、価格決定から納入までの経緯などを
トレースしたものである。図１６は、納入管理に関する
クエリーレポートであり、個別発注案件について、分割
納入の納入実績、今後の納入予定などの情報を網羅した
ものである。図１７は、支払い管理に関するクエリーレ
ポートであり、取引先からの請求書をもとに、支払い予
定を為替別に集計したものである。また、このクエリー
レポートでは、取引先からの納入予定の情報をもとに、
今後発生する支払いを推定したものを表示している。図
１８は、資金管理に関するクエリーレポートであり、海
外に展開する企業が、ＥＤＩデータから拠点全体の商取
引の支払い情報を集計し、会社全体の資金の必要量を集
計管理するためのものである。

【００５４】図１９は、共通データベースのメンテナン
スを行なう処理手順を示す。上述したように共通データ
ベースは、ＥＤＩメッセージ別に分けられており、それ
ぞれメンテナンスすることができる。ステップ１９０１
では、メンテナンスする該当ＥＤＩデータの生産ロット
ナンバが生産終了したかどうかを確認する。次にステッ
プ１９０２で、該当データの生産ロットナンバが終了
後、所定の日数が経過したがどうかを確認する。その日
数は顧客ユーザが任意に指定する。ステップ１９０３で
は、消去対象データのバックログを作成する。ステップ
１９０４でデータベース中の消去対象データを消去し、
データベースを更新し、更新後データベース１９０５を
得る。

【００５５】

【発明の効果】以上説明したように、本発明によれば、
１対１の当事者間でＥＤＩによってやり取りされるＥＤ
Ｉデータから、その経路途中で所定の情報を取り出し
て、データベースを構築するので、例えば商社が国際分
業でＯＥＭ（顧客ブランド名を使った完成品請負受注）
事業を行なう際に、該事業に関連して発生する貿易取引
の効率化を図ることができる。具体的には、図２で説明
したような階層構造の製品製作系統の中で材料メーカに
事故があった場合などでも、最上位の製品組立企業は共
通データベースにアクセスして材料メーカに関する情報
を迅速かつ正確に知ることができ、事業全体として混乱
を招くことなく効率的で円滑な対処が可能である。ま
た、ＥＤＩデータから管理レポートを生成するため、新
たなインプットは不要である。また、取引の直接の当事
者でなくとも情報共有が可能なため、多数の拠点が関係
する取引、あるいは本社機構からの集中コントロールが
可能となる。さらに、アプリケーションがサーバ側にあ
るため、メンテナンスが容易で標準化が効率的にでき
る（クライアント側のシステムのメンテナンスが容
易）、ユーザ側に十分なシステムがなくとも社外との
取引は細かく管理できる、取引先の変更が比較的容易
である（取引先のシステムに依存しない）、生産体
系、業務体系の異なる異業種間の商取引でも共通サーバ
をベースに業務に適合した高度な管理体系を設定するこ
とが出来る、商取引データが１ヶ所に集中するため銀
行や物流などの間連業界にデータを切り出し多種多様な
改善に発展させることが出来る、などの効果がある。

【図面の簡単な説明】

【図１】本発明の実施の形態のシステム概要図

【図２】ある製品を製作する際の系統図

【図３】完成品モデルとそれを構成する部品との関係の
一例を示す図

【図４】本実施の形態のシステムにおける情報共有の概
念図

【図５】本実施の形態のシステムの概念図

【図６】受信したＥＤＩデータを共通データベースに登
録する手順を示すフローチャート図

【図７】分類・抽出するＥＤＩデータの項目例を示す図

【図８】必要な項目のみを抽出した登録用のデータの項
目を示す図

【図９】データベースへの登録用のデータの項目を示す
図

【図１０】共通データベースの構造を示す図

【図１１】ＥＤＩデータの分類フラグの仕様例を示す図

【図１２】ユーザがブラウザを用いて共通データベース
にアクセスする手順を示すフローチャート図

【図１３】ユーザアクセスの制限テーブル例を示す図

【図１４】クエリーの処理概念図

【図１５】発注管理に関するクエリーレポートの例を示
す図

【図１６】納入管理に関するクエリーレポートの例を示
す図

【図１７】支払い管理に関するクエリーレポートの例を
示す図

【図１８】資金管理に関するクエリーレポートの例を示
す図

【図１９】共通データベースのメンテナンスを行なう処
理手順を示す図

【図２０】従来のＥＤＩを示す概念図

【符号の説明】

１０１…ＥＤＩプロバイダ、１０２，１０４…社内管理
システム、１０３，１０５…インターフェース、１０６
…商取引共通管理システム。

Claims (7)

【特許請求の範囲】
1. 【請求項１】企業間取引における事務処理を電子化した
   ＥＤＩを用いた商取引管理システムにおいて、 商取引を行なう１対１の当事者間で前記ＥＤＩによって
   やり取りされるＥＤＩデータを、商取引管理を目的とす
   るサーバ内のデータベースにダウンロードすることを特
   徴とする商取引管理システム。
2. 【請求項２】前記ＥＤＩデータから商取引に関する管理
   情報を取り出し、その種別ごとにリレーショナルデータ
   ベースを構築することを特徴とする請求項１に記載の商
   取引管理システム。
3. 【請求項３】前記データベースから、所定の条件で検索
   したデータを取り出し、該取り出したデータから前記当
   事者間の商取引に関する各種管理レポートを作成するこ
   とを特徴とする請求項１または２の何れか１つに記載の
   商取引管理システム。
4. 【請求項４】前記管理レポートを前記サーバ上に蓄積
   し、所定の権限を有する者に前記管理レポートを参照許
   可することを特徴とする請求項３に記載の商取引管理シ
   ステム。
5. 【請求項５】リアルタイムに発生する商取引の前記ＥＤ
   Ｉデータに連動させて、前記サーバ上のデータベースお
   よび管理レポートの内容をリアルタイムに更新すること
   を特徴とする請求項４に記載の商取引管理システム。
6. 【請求項６】前記管理レポートにアクセスした者に対し
   て課金する手段をさらに備えたことを特徴とする請求項
   ４に記載の商取引管理システム。
7. 【請求項７】当事者間取引における事務処理を電子化し
   たＥＤＩを用いた取引管理システムにおいて、 前記ＥＤＩに加入した複数の当事者のうちの任意の１組
   の当事者間で１対１の取引を行なうためのＥＤＩデータ
   をやり取りする手段と、 前記１対１でやり取りされるＥＤＩデータの送受信の経
   路途中で、該ＥＤＩデータから所定の商取引に関する管
   理情報を抽出し、データベースに登録する手段と、 前記複数の当事者のうち所定のアクセス権限を許可され
   た者に対し、前記データベースへのアクセスを許可する
   手段とを備えたことを特徴とする商取引管理システム。