JP2001344485A - 電子取引システムと方法およびその処理プログラムを記録した記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 従来は、受発注に係わる情報の管理および処
理の電子化を、発注側および受注側のそれぞれで、各取
引先毎に個別に行わなければならない。 【解決手段】 例えばＥＤＩシステムにおいて、従来機
能のＥＤＩデータ処理部１ａだけでなく、新たに、出荷
情報処理部１ｃ、契約残処理部１ｄ、在庫情報処理部１
ｅ、使用予定算出処理部１ｆ、使用予定調整処理部１
ｇ、発注調整処理部１ｈ、注文情報処理部１ｉからなる
注文支援システム１ｂを設け、取引先である発注者と受
注者間の生産計画や使用予定に基づき、適正発注量決
定、注文情報通知、出荷情報通知、検収結果取り込み、
契約残情報の管理、および、在庫管理までの受発注に関
連するサイクルの各業務作業を電子化して処理する構成
とし、各作業に係わる情報をデータベース化して格納
し、それぞれの情報を共通なキー項目で連結することに
より、発注者と受注者間の取引コード体系の整合性を確
保する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、インターネット
（INTERNET）等のコンピュータネットワークを介して受
発注を行う電子取引技術に係わり、特に、発注側システ
ムでの発注操作および受注側システムでの受注操作の負
荷を効率的に軽減するのに好適な電子取引システムと方
法およびその処理プログラムを記録した記録媒体に関す
るものである。

【０００２】

【従来の技術】従来、コンピュータネットワークを介し
て電子的に、受発注や輸送、決済などのビジネス文書を
企業間でやりとりするものとして、ＥＤＩ（Electronic
DataInterchange、電子データ交換）システムがある。

【０００３】このＥＤＩシステムは、発注者側の情報処
理システムと受注者側の情報処理システムの間に位置
し、発注者側情報処理システムと受注者側情報処理シス
テムで相互に情報を交換する手段を提供している。

【０００４】しかし、このＥＤＩシステムによる情報の
交換は、発注者情報処理システムと、受注者情報処理シ
ステムの違いを吸収するための、各種変換機能が中心で
あり、通信プロトコルなど、通信レベルでの変換や、Ｅ
ＤＩで相互に交換される電子伝票のフォーマットレベル
の変換が、主なものである。尚、電子伝票のフォーマッ
トとしては、例えばＥＩＡＪ（Electronic Industry As
sociation of Japan）のような業界標準のものもあれ
ば、各社で独自に使用しているフォーマットもある。

【０００５】近年、インターネットの普及に伴い、ＷＷ
Ｗ（World Wide Web）を用いたＷＥＢ型ＥＤＩの推進が
図られている。このＷＥＢ型ＥＤＩは、発注者情報処理
システムあるいは受注者情報処理システムとして、ＷＷ
Ｗサーバの情報の表示やＷＷＷサーバへの情報の入力を
行うＷＥＢブラウザとＷＷＷサーバに接続するための通
信機能とを設けたパーソナルコンピュータのような簡易
な情報処理システムを用いることでＥＤＩが可能である
という点を特徴としている。

【０００６】このような特徴により、ＷＥＢ型ＥＤＩは
導入が容易であり、従来の電話やファクシミリ装置を用
いた取引情報のやりとりをしている発注者あるいは受注
者に対して、ＥＤＩを普及させるという観点から展開が
図られている。

【０００７】このＷＥＢ型ＥＤＩでは、発注者側あるい
は受注者側で、ＷＥＢブラウザを使用して入力された発
注情報や出荷情報が、ＥＤＩシステムであるＷＷＷサー
バに格納され、受注者あるいは発注者のＷＥＢブラウザ
で表示されるか、または、ホストコンピュータやサーバ
などに、通信プロトコルレベル、フォーマットレベルの
変換が施されて出力されるというのが通例である。

【０００８】また、このようなＷＥＢ型ＥＤＩも含め、
ＥＤＩシステム全般として、注文番号や部品番号等、フ
ォーマットレベルでは同じ意味合いでも、発注者情報処
理システムと受注者情報処理システムのそれぞれで使用
されている電子伝票の情報内容（以下、「取引コード体
系」と記載する）は、それぞれ異なっていることが多
い。

【０００９】そのため、電子取引においては、発注者情
報処理システム、ＥＤＩシステム、受注者情報処理シス
テム間での、取引コード体系の整合性の確保が必要であ
り、この整合性を確保するための処理は、発注者情報処
理システムや受注者情報処理システム、あるいは、それ
らの利用者が人手により（人間系で）行っている。

【００１０】また、このようなＷＥＢ型ＥＤＩを含む従
来のＥＤＩシステムにおいては、発注者側と受注者側の
双方に次のような問題がある。

【００１１】Ａ）発注者側の問題 ＷＥＢ型ＥＤＩのような導入の容易性を持つＥＤＩシス
テムが展開されている中で、発注者側でのＥＤＩ普及が
進まない現状がある。その要因として、例えば、発注者
から発注情報を受注者に送り、受注者から発注者に出荷
情報を送ることができ、また、受注者側の発注を受けて
から出荷されるまでの進捗状況情報を発注者側で参照で
きるといった範囲でのＥＤＩシステムにおいては、ＥＤ
Ｉを実施するメリットが受注者側に偏ってしまう傾向が
あることが考えられる。

【００１２】すなわち、発注情報に関しては、発注者側
から見ると、発注情報の自社情報処理システムへの入力
が不要となるのは、受注者側である。また、出荷情報に
ついても、一般的には、受注者からの納品伝票の発注者
情報処理システムへの入力が不要になるという発注者側
のメリットが上げられているが、実際には、出荷情報だ
けでは、検収とはならず、結局、納品伝票は必要とされ
る。

【００１３】この納品伝票に関しては、一般に、発注者
は受注者に対し、発注者側で決めた納品伝票での納入を
指定することが多く、このような指定納品伝票には、こ
の伝票の発行元となる発注者情報処理システムで作成し
た発注情報と照合するためのキー項目、あるいは、この
キー項目情報を示すバーコードが付与されている場合が
多い。そのため、発注者側の納品伝票の発注者情報処理
システムへの入力は、このようなキー項目と数量のみを
入力する、あるいは、バーコードを読み取り装置で読む
程度の煩雑性でしかない。従って、発注者側の出荷情報
を受け取るメリットが薄れがちになる。

【００１４】また、進捗状況情報についても、発注者側
では、発注したものは納期通りに納められるのが当然と
いう意識もあり、有効に活用されていない。尚、受注側
にしてみても、進捗状況情報により発注者側に手配状況
を知らせることで、発注者側から必要以上にこと細かく
進捗状況を詮索されるという危惧もあり、有効に活用さ
れていない現状がある。

【００１５】さらに、製造業を中心に見てみると、発注
者側は、作業の外注化が進む中で、一次外注先、二次外
注先というように、多くの外注先（以下、「協力会社」
という）を伴った発注者グループを形成している。この
ような場合、実際に発注あるいは納品検収を行うのは、
協力会社であることが多い。

【００１６】協力会社としては中小企業が多いので、こ
のような協力会社では、情報処理システムを利用した発
注業務管理の導入率、および、それを使用したＥＤＩの
実施率は、まだ高くはない。すなわち、協力会社では、
発注業務を管理する指標である契約残や在庫、生産計
画、使用予定などが、紙の台帳で管理され、かつ、これ
らの指標より算出される発注量も人間系で人手を介して
計算し、紙の上で管理されていることが多い。

【００１７】発注者が発注書を受注者に渡す場合、手書
きの発注書であればファクシミリで送付したほうが楽で
あり、導入が容易なＷＥＢ型ＥＤＩであっても、この情
報処理システムに発注情報を入力するのは、負担であ
る。また、その発注情報を導き出す指標が紙で管理され
ている以上、情報処理システムを利用して、受注者のた
めに発注情報を入力するのは、発注者にとってメリット
が少ないという判断となる。

【００１８】さらに、協力会社などにおいては、情報処
理システムに不慣れな場合もあり、情報処理システムの
操作が煩雑と感じる状況がある。ＷＥＢ型ＥＤＩでは、
入力項目を極力減らして操作負荷を軽減する工夫がなさ
れているが、例えば、納期をベースとした管理指標は、
月別や日別に使用予定を入力する必要があり、操作が煩
雑である。

【００１９】また、前述した一次外注先、二次外注先等
の各協力会社からなる発注者グループで、発注という業
務を考えた場合、発注を取りまとめる親発注者にとって
は、自社の生産計画や使用予定に基づいて適正発注量を
導き出す過程で、協力会社にある自社取り扱い分の契約
残や在庫といった財源の把握が必要となる。しかし、各
協力会社は、紙の台帳で、財源を管理しているため、親
発注者は、電話やファクシミリを利用して情報を入手
し、その情報を基に把握しなければなず、タイムリーで
効率的な把握ができない。

【００２０】さらに、各協力会社によって、それぞれの
財源の管理の仕方が異なる場合がある。この場合、親発
注者側は、把握した数値の定義が異なるので、各協力会
社毎に一つ一つ調整をしていかなくてはならない。ま
た、各協力会社によって管理精度に差が生じる。これ
は、入出庫管理精度や在庫棚卸の頻度にも影響される
が、人間系の要素も強く、発注者グループ全体の業務の
標準化を図るのは難しい。

【００２１】このような各協力会社側の状況を改善する
ことを目的として、親発注者が、各協力会社への情報処
理システムの導入を推進する場合、紙の台帳で業務を管
理している協力会社では、親発注者のために管理情報を
わざわざ情報処理システムにインプットしなければなら
ず、負担となる。

【００２２】Ｂ）受注者側の問題 ＥＤＩにおける発注者と受注者間での、取引コード体系
の整合性という点を考えると、インターネットの普及、
あるいは、企業間ＥＤＩの普及に伴うＥＤＩフォーマッ
トの標準化推進という状況の中で、発注者情報処理シス
テムと受注者情報処理システム間での通信レベルの整合
性の確保やフォーマットレベルの整合性の確保が図られ
ている。

【００２３】しかし、取引コード体系の整合性の確保に
関しては、ＥＤＩの普及に伴うシステムの接続先数の増
加に従って、発注者情報処理システムや受注者情報処理
システム、あるいは、それらの利用者においての整合性
処理が増大している。特に、発注者は、発注をするとい
う強みがあり、この整合性確保は、受注者側で行われる
ことが多い。そのため、受注者側企業での人件費負担の
増大、あるいは、受注者情報処理システムの整合性に対
応するための開発費用や処理負荷の増大が発生する。

【００２４】このような問題に対する、従来の一般的な
解決技術としては、標準というものを制定して、発注者
と受注者間で共通言語的なものを持ち、それを利用する
ものである。しかし、部品の一つ一つを定義付ける情報
までは標準化できない。また、業界により標準が違うな
どの理由で、取引コード体系にまで標準化が及ばない。

【００２５】近年、商社として、取引の電子化が進めら
れているが、このような受発注システムを商社に適用す
る場合、以下のような問題がある。

【００２６】商社は、発注者と受注社の間に位置し、発
注者から見ると受注の代行を、また、受注者から見ると
発注者の代行を行うものであり、電子化における位置づ
けとしては、ＥＤＩシステムそのものが商社の機能とな
る。その商社においてＥＤＩ化を図る場合、二つのケー
スに分けられる。一つは、発注者や受注者といった取引
先とのＥＤＩ化であり、もう一つは、商社内部における
取引業務の電子化である。

【００２７】取引先とのＥＤＩ化は、商社としてのＥＤ
Ｉシステムの付加価値が求められ、通信レベルの変換や
フォーマットレベルの変換という従来のＥＤＩシステム
で提供される付加価値だけにとどまることができない。
例えば、前述した発注者や受注者あるいは発注者グルー
プでの問題を踏まえた上でのＥＤＩシステムが求められ
る。

【００２８】また、商社内部における取引業務の電子化
では、インターネットによるメールの普及、あるいは、
個人ベースで利用できるパーソナルコンピュータ上の表
計算ソフトに代表される簡易電子台帳の普及などによ
り、商社の取引オペレータが、発注者からメールで注文
を受けて簡易電子台帳に登録し、受注者にメールで注文
を送るという処理がなされている。

【００２９】この処理システムは、どのような取引にも
適用できるといった柔軟性があるが、取引毎に取引オペ
レータが情報処理化しなければならず、また、発注者か
らの注文メールと受注者への注文メールとの取引コード
体系の変換を取引オペレータが人間系で行わなければな
らず、部分的な情報処理システムの利用でしかない。

【００３０】また、商社で扱う取引には、リピート性の
高いものとスポット性の高いものがある。スポット性の
高いもの（リピート性の高い取引に成長する過程にある
ものも含む）に関しては、柔軟性の高い形態での電子化
が望まれるが、リピート性の高い取引に関しては、極
力、業務の標準化を行って人間系の部分を情報処理シス
テムに置き換え、取引に係わる各処理を連結して処理で
きるＥＤＩシステムに置き換えていく事が望まれる。

【００３１】従来、以上のような各発注者や受注者なら
びに商社における問題を解消するために、各発注者や受
注者ならびに商社のそれぞれにおいて、個別に、かつ部
分的な情報処理システム化による対応が行われている。

【００３２】

【発明が解決しようとする課題】解決しようとする問題
点は、従来の技術では、受発注に係わる情報の管理およ
び処理の電子化を、発注側および受注側のそれぞれで、
各取引先毎に個別に行わなければならない点である。

【００３３】本発明の目的は、これら従来技術の課題を
解決し、発注側と受注側のそれぞれにおける、受発注処
理に係わる作業負荷およびその受発注に関連する情報の
管理に係わる作業負荷を軽減することを可能とする電子
取引システムと方法およびその処理プログラムを記録し
た記録媒体を提供することである。

【００３４】

【課題を解決するための手段】上記目的を達成するた
め、本発明の電子取引システムと方法は、例えばＥＤＩ
システムにおいて、従来のＥＤＩ（データ交換）機能だ
けでなく、新たに、取引先である発注者と受注者間の生
産計画や使用予定の算出から、適正発注量決定、注文情
報通知、出荷情報通知、検収結果取り込み、契約残情報
の管理、および、在庫管理までの受発注に関連するサイ
クルの各業務作業を電子化して処理する機能を持たせ
る。例えばＥＤＩシステム上に、各作業に係わる情報を
データベース化して格納し、それぞれの情報を共通なキ
ー項目で連結することにより、発注者と受注者間の取引
コード体系の整合性を確保する。これにより、発注者と
受注者間、ならびに、ＥＤＩシステムを運営する商社等
の企業体において、一貫性のある各情報を共有できる仕
組みが形成される。

【００３５】

【発明の実施の形態】以下、本発明の実施の形態を、図
面により詳細に説明する。まず、図１と図４を用いて本
例の電子取引システムによる取引形態の説明を行う。

【００３６】図１は、本発明の電子取引システムによる
取引形態例を示すブロック図であり、図４は、図１にお
ける発注者Ａ社の製造する製品の部品構成例を示す説明
図である。

【００３７】図１に示すように、本例の電子取引システ
ムは、ＥＤＩシステム１０をベースに構築されたもので
あり、このＥＤＩシステム１０には、図３で詳細を示す
ように、注文支援システム１ｂが設けられ、従来のデー
タ変換のみならず、複数の発注者側（発注者Ａ社２ａ、
発注者Ｂ社２ｂ）と複数の受注者側（受注者Ｃ社３ａ、
受注者Ｄ社３ｂ、受注者Ｅ社３ｃ、受注者Ｆ社３ｄ）間
での受発注処理や、その受発注に係わる情報の管理処理
等を、発注者および受注者に代行して行う。

【００３８】このように、本例の電子取引システムは、
ＥＤＩシステム１０に、注文支援システム１ｂという一
種の商社機能を搭載したものである。

【００３９】発注者Ａ社２ａ、発注者Ｂ社２ｂなどの各
発注者から見た場合、発注の対象部品全ての受注先が、
ＥＤＩシステム１０に接続されていることが望ましい
し、反対に、受注者Ｃ社３ａ、受注者Ｄ社３ｂ、受注者
Ｅ社３ｃ、受注者Ｆ社３ｄなどの受注者は、自社の取扱
い商品である部品を発注してくれる全発注者がＥＤＩシ
ステム１０に接続されていることが望ましい。

【００４０】これを実現していくには、従来のＥＤＩシ
ステムが持つ機能だけでは、取引の場という意味合いに
おいて、付加価値が不充分であり、そこに注文支援シス
テムのような商社機能を搭載し、付加価値を提供し、商
社の幅広い取引チャネルを活かして、発注者、受注者の
ＥＤＩ接続をカバーしていくことが重要である。以下、
このような注文支援システムを具備したＥＤＩシステム
について説明する。

【００４１】図１における発注者Ａ社２ａでは、図４に
例として示すように、部品定義（１）テーブル４３で定
義され部品定義（１）４１として図示されているよう
に、部品（１）４１ｂと部品（２）４２ａからなる製品
（１）４１ａを製造している。尚、部品（２）４２ａ
は、部品定義（２）テーブル４４で定義され部品定義
（２）４２として図示されているように、部品（３）４
２ｂと部品（４）４２ｃからなる。

【００４２】この発注者Ａ社２ａの製品である製品
（１）４１ａに対し、部品（１）４１ｂ、部品（３）４
２ｂ、部品（４）４２ｃという３種類の発注部品があ
り、部品（１）４１ｂは、図１における受注者Ｃ社３ａ
または受注者Ｄ社３ｂに発注され、部品（３）４２ｂは
受注者Ｅ社３ｃへ、部品（４）４２ｃは受注者Ｆ社３ｄ
へ発注されるという前提で以降の説明を行う。

【００４３】尚、発注部品である部品（１）４１ｂ、部
品（３）４２ｂ、部品（４）４２ｃには、それぞれ異な
る発注者部品番号がキー項目として付与され、かつ、発
注される際には、各部品毎に異なる発注者注文番号が、
各部品を識別して特定するために用いられるキー項目と
して付与される。

【００４４】このような発注処理における発注者部品番
号や発注者注文番号を含め、ＥＤＩシステム１０におけ
る各処理で用いられるキー項目と、各キー項目で対応付
けられ検索等される各情報（情報区分、その他の項目）
の一覧を図１２におけるテーブル（１）１２１に示す。

【００４５】図１２は、図１におけるＥＤＩシステムで
用いるテーブルの構成例を示す説明図である。本例のテ
ーブル（１）１２１は、「情報区分」と「キー項目」お
よび「その他の項目」の各項目欄が設けられ、以降で説
明する、図１におけるＥＤＩシステム１０での各処理で
参照され、その詳細は、以降のＥＤＩシステム１０の各
処理の説明と合わせて説明する。

【００４６】尚、本図１２においては、「情報区分」に
おける各情報の出力先や入力先を示す発注者と受注者に
関する情報は、全ての「情報区分」に含まれるものとす
る。また、この発注者と受注者に関する情報には、工場
などを示す発注者拠点や受注者拠点という概念の情報項
目も含まれる。

【００４７】次に、図２を用いて、ＥＤＩシステム１０
を用いて電子取引システムのハードウェア構成を説明す
る。

【００４８】図２は、本発明に係わる電子取引システム
のハードウェア構成例を示すブロック図である。ＥＤＩ
システム１０は、サーバ４内にデータベース５と共に構
成されており、サーバ４と複数台の発注者情報処理シス
テム２ｃ〜２ｅおよび複数台の受注者情報処理システム
３ｅ〜３ｇとが、インターネット等のネットワーク６を
介して接続されている。

【００４９】サーバ４と各発注者情報処理システム２ｃ
〜２ｅ、また、サーバ４と受注者情報処理システム３ｅ
〜３ｇは、相互に情報を交換する通信手段を有してい
る。また、発注者情報処理システム２ｃ〜２ｅと受注者
情報処理システム３ｅ〜３ｇは、ＥＤＩシステム１０か
ら出力される情報を表示および格納する手段と、ＥＤＩ
システム１０に情報を入力するための入力手段を有す
る。

【００５０】さらに、発注者情報処理システム２ｃ〜２
ｅと受注者情報処理システム３ｅ〜３ｇは、図１２に示
すテーブル（１）１２１における「情報区分」の情報に
対して、「キー項目」を設定して、「情報区分」で示さ
れる「その他の項目」、他の「キー項目」に関する情報
を、ＥＤＩシステム１０を介してデータベース５を参照
して抽出・入手し、この情報を表示および格納する手段
を有する。

【００５１】尚、「情報区分」における各情報に関する
発注者や受注者のデータベース５へのアクセス権限は、
ＥＤＩシステム１０において、発注者毎、受注者毎、お
よび情報区分毎に、個別に定義することが可能である。

【００５２】次に、図１４を用いて、サーバ４および発
注者情報処理システム２ｃ〜２ｅと受注者情報処理シス
テム３ｅ〜３ｇに用いられるコンピュータ装置のハード
ウェア構成を説明する。

【００５３】図１４は、図２におけるサーバおよび発注
者情報処理システムと受注者情報処理システムのハード
ウェア構成例を示すブロック図である。

【００５４】本図１４において、１４１はＣＲＴ（Cath
ode Ray Tube）やＬＣＤ(Liquid Crystal Display)等か
らなる表示装置、１４２はキーボードやマウス等からな
る入力装置、１４３はＨＤＤ（Hard Disk Drive）等か
らなる外部記憶装置、１４４はＣＰＵ（Central Proces
sing Unit）１４４ａや主メモリ１４４ｂ等を具備して
コンピュータ処理を行う情報処理装置、１４５は本発明
に係わるプログラムやデータを記録したＣＤ−ＲＯＭ
（Compact Disc-Read Only Memory）もしくはＤＶＤ（D
igital Video Disc/Digital Versatile Disc）等からな
る光ディスク、１４６は光ディスク１４５に記録された
プログラムおよびデータを読み出すための駆動装置、１
４７はＬＡＮ（Local Area Network）接続装置やモデム
等からなる通信装置である。

【００５５】光ディスク１４５に格納されたプログラム
およびデータを情報処理装置１４４により駆動装置１４
６を介して外部記憶装置１４３内にインストールした
後、外部記憶装置１４３から主メモリ１４４ｂに読み込
みＣＰＵ１４４ａで処理することにより、情報処理装置
１４４内に次に説明する図３に示す構成のＥＤＩシステ
ム１０が構成される。

【００５６】図３は、本発明に係わる電子取引システム
の構成例を示すブロック図である。本例の電子取引シス
テムとしてのＥＤＩシステム１０は、従来のＥＤＩデー
タ処理部１ａのみからなるＥＤＩシステムに、新たに注
文支援システム１ｂを設けて構成されている。

【００５７】ＥＤＩシステム１０は、図１２に示すテー
ブル（１）１２１における「情報区分」に含まれる、出
力先や入力先を示す発注者と受注者に関する情報に基づ
いて、適切に、各情報区分に指定された発注者や受注者
に、テーブル（１）１２１に示す各情報を入出力する手
段を有する。尚、発注者、受注者に関する情報には、工
場などを示す、発注者拠点、受注者拠点という概念の情
報項目も含まれている。

【００５８】ＥＤＩデータ処理部１ａは、発注者情報処
理システム２ｃと、受注者情報処理システムの違いを吸
収するための、通信レベルでの変換や、ＥＤＩで相互に
交換される電子伝票のフォーマットレベルの変換機能を
有する。

【００５９】注文支援システム１ｂには、出荷情報処理
部１ｃ、契約残処理部１ｄ、在庫情報処理部１ｅ、使用
予定算出処理部１ｆ、使用予定調整処理部１ｇ、発注調
整処理部１ｈ、注文情報処理部１ｉが設けられている。

【００６０】この内の契約残処理部１ｄと在庫情報処理
部１ｅとにより、発注者の契約残や在庫といった財源
を把握する処理を行い、使用予定算出処理部１ｆと使用
予定調整処理部１ｇとにより、発注者の使用予定を把
握する処理を行う。

【００６１】さらに、これらの財源を把握する処理処
理と発注者の使用予定を把握する処理とに基づき、注
文支援システム１ｂでは、発注量の算出処理と注文
情報の処理および出荷情報の処理を行う。

【００６２】以下、財源を把握する処理、発注者の
使用予定を把握する処理、発注量の算出処理を順に説
明する。尚、，の処理に関しては後述の図９を使用
して説明する。

【００６３】財源の把握：注文情報処理部１ｉによ
り、受注者情報処理システム３ｅに対して、注文情報が
出力される。この注文情報は、図１２のテーブル（１）
１２１に示すように、「キー項目」として発注者部品番
号、発注者注文番号、受注者注文番号などを、また、
「その他の項目」として数量、納期、納入先、属性情
報、受注者部品番号などを有し、同時に、図５における
データベース５に格納され、契約残処理部１ｄに、注文
情報の出力が通知される。

【００６４】この注文情報は、ネットワークを介して受
注者情報処理システム３で受信され、その表示装置の画
面上に表示される。受注者は、その注文情報の内容に基
づき納入、あるいは、加工の指示を行う、

【００６５】受注者側において、注文情報で指定された
部品を納入できる状態になると、納入に関する出荷情
報、すなわち、図１２のテーブル（１）１２１に示すよ
うに、「キー項目」としての発注者部品番号、発注者注
文番号、受注者注文番号と、「その他の項目」としての
数量、納期、納入先、属性情報、契約完了マーク、およ
び受注者部品番号からなる情報が、受注者情報処理シス
テム３ｅより、ＥＤＩシステム１０の出荷情報処理部１
ｃに入力される。

【００６６】尚、出荷情報の数量、納期、納入先につい
ては、納入時、注文情報で受けた内容と異なる場合は、
その内容が変更された形で、受注者情報処理システム３
ｅより、ＥＤＩシステム１０の出荷情報処理部１ｃに入
力される。

【００６７】ＥＤＩシステム１０の出荷情報処理部１ｃ
では、受注者情報処理システム３ｅから入力された出荷
情報を、発注者情報処理システム２ｃに出力する。また
同時に、出荷情報処理部１ｃにおいては、この出荷情報
をデータベース５に格納すると共に、契約残処理部１ｄ
と在庫情報処理部１ｅに対して、受注者情報処理システ
ム３ｅからの出荷情報の入力を通知する。尚、出荷情報
処理部１ｃでの処理の詳細は、図９において、「出荷
情報の処理」として説明する。

【００６８】契約残処理部１ｄでは、注文情報処理部１
ｉからの注文情報の出力通知を基に、注文情報処理部１
ｉによりデータベース５に格納された注文情報を、発注
者部品番号および発注者注文番号をキー項目として参照
し、その注文情報の数量を契約残情報としてデータベー
ス５に格納する。すなわち、図１２のテーブル（１）１
２１に示すように、「キー項目」としての発注者部品番
号と発注者注文番号、および、「その他の項目」として
の契約残、納期、納入先、属性情報、契約完了マークか
らなる契約残情報を生成してデータベース５に格納す
る。

【００６９】また、契約残処理部１ｄでは、出荷情報処
理部１ｃからの、出荷情報の入力通知を基に、出荷情報
処理部１ｃによりデータべース５に格納された出荷情報
を、発注者部品番号および発注者注文番号をキー項目と
して参照し、その契約残情報の数量から出荷情報の数量
を減算したものを契約残とし、そして、出荷情報の契約
完了マークを識別して、契約完了マークが有る場合は、
契約完了として取扱い、契約残情報の契約完了マークを
有りにして、データベース５に格納する。

【００７０】発注者情報処理システム２ｃでは、注文支
援システム１ｂの出荷情報処理部１ｃから出力された出
荷情報を格納する。発注者側では、発注者情報処理シス
テム２ｃにおいてこの出荷情報を受けるのとは別に、こ
の出荷情報に示された発注部品が納品される。

【００７１】この納品時、発注情報処理システム２ｃに
おいて、先に格納した当該出荷情報を表示する。発注者
は、この表示内容と発注部品とを比較し、納入に問題が
ない発注部品については、この出荷情報を元に、検収情
報、すなわち、図１２のテーブル（１）１２１に示すよ
うに、「キー項目」としての発注者部品番号と発注者注
文番号、および、「その他の項目」としての数量、納
期、納入先、属性情報からなる検収情報を作成して、Ｅ
ＤＩシステム１０における注文支援システム１ｂの在庫
情報処理部１ｅに入力する。

【００７２】また、発注者側では、発注対象の図４に示
す部品構成の製品（１）の数量を引当情報（図１２のテ
ーブル（１）１２１においては、「キー項目」としての
発注者製品番号、および「その他の項目」としての数量
からなる）として、発注者情報処理システム２ｃから、
ＥＤＩシステム１０における在庫情報処理部１ｅに入力
する。

【００７３】さらに、発注者側では、発注対象の図４に
示す製品（１）を構成する部品（１）４１ｂ、部品
（３）４２ｂ、部品（４）４２ｃについての在庫量を個
々に把握し、棚卸情報（図１２のテーブル（１）１２１
においては、「キー項目」としての発注者部品番号、お
よび「その他の項目」としての数量と棚卸日付からな
る）として、発注者情報処理システム２ｃから、ＥＤＩ
システム１０における在庫情報処理部１ｅに入力する。

【００７４】尚、引当情報の入力は、図４に示す部品構
成の製品（１）を発注者が出庫あるいは製造するため
に、各部品（１）４１ｂ、部品（３）４２ｂ、部品
（４）４２ｄを引当した際に行われ、また、棚卸情報の
入力は、任意の一定期間毎に行われる。

【００７５】このような発注者情報処理システム２ｃか
らの引当情報や棚卸情報や、出荷情報処理部１ｃからの
出荷情報などを受け取った在庫情報処理部１ｅでは、以
下の処理を行う。

【００７６】まず、出荷情報処理部１ｃからの出荷情報
の入力通知を基に、出荷情報処理部１ｃがデータべース
５に格納した出荷情報を、発注者部品番号および発注者
注文番号をキー項目として参照し、次に、この出荷情報
の発注者部品番号をキー項目として、データベース５か
ら在庫情報（図１２のテーブル（１）１２１において
は、「キー項目」としての発注者部品番号、および「そ
の他の項目」としての流通在庫数量と発注者在庫数量か
らなる）を参照し、この出荷情報の数量を、当該在庫情
報の流通在庫数量として加算し、新たな在庫情報として
データベース５に格納する。

【００７７】また、在庫情報処理部１ｅでは、発注者情
報処理システム２ｃから入力された検収情報を基に、発
注者部品番号をキー項目として、データベース５から在
庫情報を参照し、この在庫情報の発注者在庫数量に、検
収情報の数量を加算し、また、流通在庫数量から検収情
報の数量を減算し、新たな在庫情報としてデータベース
５に格納する。

【００７８】さらに、在庫情報処理部１ｅでは、発注者
情報処理システム２ｃから入力された引当情報を基に、
この引当情報の発注者製品番号が示す数量を算出し、デ
ータベース５から発注者部品番号毎に在庫情報を参照
し、発注者在庫数量から、部品の使用された数量を減算
し、新たな在庫情報としてデータベース５に格納する。

【００７９】例えば、図４に示す例では、引当情報の発
注者製品番号が示す数量として、製品（１）の数量が相
当するが、この製品（１）の数量から部品（１）、部品
（３）、部品（４）の使用された量を算出し、発注者在
庫数量から減算する。

【００８０】この在庫情報処理部１ｅでの、製品（１）
の数量から部品（１）、部品（３）、部品（４）の使用
された数量の算出は、図４における部品定義（１）テー
ブル４３や部品定義（２）テーブル４４等からなる構成
マスタを参照することにより行う。このような構成マス
タについて、図５を用いて説明する。

【００８１】図５は、図３における注文支援システムの
第１の詳細構成例を示すブロック図である。図５に示す
ように、構成マスタは、発注者情報システム２ｃから注
文支援システム１ｂに入力され、構成情報部品情報登録
処理部１ｊによりデータベース５に格納される。

【００８２】構成マスタは、図４に示すように、製品番
号（１）と部品番号（１〜４）、および、部品番号
（２）と部品番号（３，４）の階層関係を、親と子とい
う形の１階層（図４では、部品定義（１）４１，（２）
４２として記載された破線で囲まれた部分）で定義さ
れ、親１単位に対する子の必要数量を定義する。

【００８３】従って、１つの製品は、この１階層毎の定
義の集合とチェインで定義される。図４の例では、製品
（１）４１ａ、部品（１）４１ｂ、部品（２）４２ａの
構成関係を部品定義（１）テーブル４３として、また、
部品（２）４２ａ、部品（３）４２ｂ、部品（４）４２
ｃの構成関係を部品定義（２）テーブル４４としてい
る。

【００８４】このような部品定義テーブルを構成マスタ
として、図１２に示すテーブル（１）１２１の内容
（「キー項目」として発注者製品番号と発注者部品番
号、および「その他の項目」としてキー項目の製品また
は、部品を構成する全部品番号、数量および非発注部品
マークからなる）で、発注者情報処理システム２ｃか
ら、注文支援システム１ｂの構成情報部品情報登録処理
部１ｊに入力される。

【００８５】尚、図１２のテーブル（１）１２１に示す
構成マスタの「その他の項目」における「非発注部品マ
ーク」とは、図４で示す部品（２）４２ａに対して付け
られるもので、構成過程の中間部品に相当するものに対
するマークであり、この「非発注部品マーク」が付けら
れた部品は発注の対象とはならない。

【００８６】このような構成マスタから、図３における
在庫情報処理部１ｅでは、引当情報の発注者製品番号、
例えば、図４の製品（１）をキー項目として、製品
（１）の１単位に対する各発注者部品番号（部品
（１）、部品（３）、部品（４））毎の必要数量を求
め、そして、引当情報の数量を掛け合わせることで、各
発注部品番号毎の在庫から引当てられた量を求める。

【００８７】また、在庫情報処理部１ｅでは、発注者情
報処理システム２ｃより入力された棚卸情報を基に、発
注者部品番号をキー項目としてデータベース５から在庫
情報を参照し、この在庫情報の発注者在庫数量を棚卸情
報の数量に変更し、新たな在庫情報としてデータベース
５に格納する。

【００８８】尚、在庫情報処理部１ｅでは、発注者から
図５に示す構成マスタの入手ができず、その結果とし
て、発注者からの引当情報による発注者部品番号単位の
発注者在庫引当数量の算出が実施できない場合には、棚
卸期間を短くした棚卸情報を入手することで在庫量の把
握を可能としている。

【００８９】このような在庫や契約残等の財源の把握全
体において、その契約残や在庫の例外的要因として、発
注の取り消しや打切、または、納入時の返品等があり、
以下、このような例外的要因について説明する。

【００９０】発注の取り消しに関しては、受注者からの
出荷前であれば、当該発注者注文番号の契約残情報を、
見かけ上、契約完了とするなどの措置が必要である。

【００９１】また、発注の打切に関しては、１つの発注
者注文番号に対して、複数回に分けて納品がされた場合
に、１回目の納品以降の納品を打切るケースが想定さ
れ、この場合も、当該発注者注文番号の契約残情報を、
見かけ上、契約完了とするなどの措置が必要である。こ
のような措置に係わる本例の電子取引システムの構成と
動作を図６を用いて説明する。

【００９２】図６は、図３における注文支援システムの
第２の詳細構成例を示すブロック図である。発注の取り
消しや打ち切りに対応する措置のために、本例の電子取
引システムでは、本図６で示すように、注文支援システ
ム１ｂに契約残処理部１ｄを設け、この契約残処理部１
ｄに対して、受注者情報処理システム３ｅから、契約完
了情報を入力することで対応する。

【００９３】本例では、この契約完了情報は、図１２の
テーブル（１）１２１に示すように、発注者注文番号が
「キー項目」として用いられる。契約残処理部１ｄで
は、受注者情報処理システム３ｅから入力された契約完
了情報を基に、発注者部品番号をキー項目としてデータ
ベース５から契約残情報を参照し、当該契約残情報の契
約完了マークを有りにしてデータベース５に格納する。

【００９４】尚、契約残や在庫の他の例外的要因とし
て、納入時の返品がある。この納入時の返品では、受注
者側から製品が既に出荷され、受注者情報処理システム
３ｅから出荷情報が、注文支援システム１ｂにおける出
荷情報処理部１ｃに入力されているので、在庫情報の流
通在庫数量に当該返品分の数量がカウントされている。

【００９５】このような納入時の返品に対応するための
処理を、本例の電子取引システムでは、図６で示すよう
に、注文支援システム１ｂの在庫情報処理部１ｅに持た
せている。すなわち、受注者情報処理システム３ｅから
注文支援システム１ｂの在庫情報処理部１ｅに、流通在
庫変更情報を入力することで対応している。

【００９６】この流通在庫変更情報は、本例では、図１
２のテーブル（１）１２１で示すように、「キー項目」
としての発注者部品番号と、「その他の項目」としての
数量および棚卸日付からなり、このような流通在庫変更
情報を基に、図３および図６の在庫情報処理部１ｅは、
発注者部品番号をキー項目として、データベース５から
在庫情報を参照し、当該在庫情報の流通在庫数量を流通
在庫変更情報の数量に変更してデータベース５に格納す
る。

【００９７】尚、このような納入品の返品時の契約残に
ついては、注文情報の数量と出荷情報の数量が同一であ
る場合は問題無いが、分納などにより異なっている場合
は契約残が残ってしまうため、契約完了情報により、見
かけ上、契約完了にすることが必要な場合もある。

【００９８】以上の説明で示すようにして、注文支援シ
ステム１ｂにおける契約残処理部１ｄと在庫情報処理部
１ｅによる財源の把握に関する処理が行われる。次
に、注文支援システム１ｂにおける使用予定算出処理部
１ｆと使用予定調整処理部１ｇによる発注者の使用予
定を把握する処理について説明する。

【００９９】使用予定の把握：まず、使用予定算出処
理部１ｆの処理について説明する。発注者の使用予定の
把握には、次の（イ）と（ロ）の方法を用いる。

【０１００】（イ）例えば、図４で示す部品構成の製品
（１）の生産計画を基に、部品（１）、部品（３）、部
品（４）の使用予定を注文支援システム１ｂで算出し、
その算出結果を基に、発注者側の発注者情報処理システ
ム２ｃにおいて、使用予定の見直しを入力して最終使用
予定を決める。

【０１０１】（ロ）発注者側で、発注者情報処理システ
ム２ｃにより、直接、部品（１）、部品（３）、部品
（４）の使用予定を求め、注文支援システム１ｂに入力
する。

【０１０２】（ロ）の方法は、（イ）の方法においての
使用予定の見直し入力に含めることができるので、以
下、（イ）の例についてのみ説明する。

【０１０３】注文支援システム１ｂの使用予定算出処理
部１ｆに入力される生産計画情報は、図１２のテーブル
（１）１２１で示されるように、発注者製品番号をキー
項目とした、（日付、数量）の一定期間分の情報、例え
ば、向う３ヶ月分等の情報の集合である。

【０１０４】発注者が、図４の部品（１）４１ｂ、部品
（３）４２ｂ、部品（４）４２ｃの発注を行う際、発注
者情報処理システム２ｃでの操作により、製品（１）４
１ａの発注者製品番号をキー項目として、注文支援シス
テム１ｂの使用予定算出処理部１ｆを介して、データベ
ース５を参照して生産計画情報を読み出し、発注者情報
処理システム２ｃの表示装置の画面に表示する。

【０１０５】このようにして表示された生産計画情報の
内容を基に、発注者は、製品（１）の生産計画の既存期
間分を見直し、あるいは、新規期間分の生産計画を決
め、発注者情報処理システム２ｃから、支援システム１
ｂの使用予定算出処理部１ｆに対して、同見直情報とい
う形で入力する。

【０１０６】使用予定算出処理部１ｆでは、発注者情報
処理システム２ｃからの同見直情報を生産計画情報とし
てデータベース５に格納する。すなわち、使用予定算出
処理部１ｆでは、生産計画情報の同見直情報を基に、使
用予定情報を算出し、データベース５に格納する。

【０１０７】本例では、この使用予定情報は、図１２の
テーブル（１）１２１で示すように、「キー項目」とし
ての発注者部品番号、「その他の項目」としての（納
期、数量、日割パターン番号、充当区分）の一定期間分
の情報、発注量算出指示マークからなる。

【０１０８】このような使用予定算出処理部１ｆによる
使用予定情報の算出は、構成マスタおよび部品マスタを
参照することにより行われる。尚、この構成マスタにつ
いては、在庫情報処理部１ｅの処理で説明したとおりの
ものである。

【０１０９】また、部品マスタは、図５に示すとおり、
発注者情報処理システム２ｃ、および、受注者情報処理
システム３ｅから、注文支援システム１ｂにおける構成
情報部品情報登録処理部１ｊに入力されてデータベース
５に格納される。この部品マスタは、構成マスタ内で非
発注部品マークの無い部品全てに対して定義され、図１
３のテーブル（２）１３１で示す情報項目が定義されて
いる。

【０１１０】図１３は、図１におけるＥＤＩシステムで
用いる他のテーブルの構成例を示す説明図である。本例
のテーブル（２）１３１は、「部品マスタ項目」と「発
注者側項目」および「受注者側項目」の各項目欄が設け
られ、次に説明する、図３における注文支援システム１
ｂの使用予定算出処理部１ｆでの処理で参照される。

【０１１１】図３における注文支援システム１ｂの使用
予定算出処理部１ｆでは、生産計画情報の発注者製品番
号、例えば、図４の製品（１）をキー項目として、構成
マスタより、製品（１）の１単位に対する各発注部品番
号（図４の部品（１）、部品（３）、部品（４））毎の
必要数量を求め、各必要数量に生産計画情報の数量を掛
け合わせることで、各発注部品番号毎の使用予定数量を
求める。

【０１１２】さらに、使用予定算出処理部１ｆは、各発
注部品番号毎の使用予定日、すなわち発注者側に対する
納期を、生産計画情報の日付の項目から、部品マスタの
発注者先行日数に示される日数分だけ前倒しにした日付
を算出し、その日付を納期候補として求める。

【０１１３】尚、このような納期の設定については、発
注者、受注者の営業日を考慮し、休日にならないよう設
定する必要がある。そのため、使用予定算出処理部１ｆ
では、求めた納期候補から休日をはずした納期を求め、
使用予定情報として、図１２に示すように、（納期、数
量）という形で、データベース５に格納する。

【０１１４】このように発注者や受注者の営業日を考慮
して納期を設定するための仕組みを、本例では、図７に
示すようにして、注文支援システム１ｂに設ける。

【０１１５】図７は、図３における注文支援システムの
第３の詳細構成例を示すブロック図である。発注者や受
注者の営業日を考慮して納期を設定するために、本例の
電子取引システムでは、本図７で示すように、注文支援
システム１ｂにカレンダ登録処理部１ｋを設け、このカ
レンダ登録処理部１ｋに対して、発注者情報システム２
ｃや受注者情報処理システム３ｅから、発注者カレンダ
マスタや受注者カレンダマスタを入力することで対応す
る。

【０１１６】本例では、発注者カレンダマスタは、図１
２のテーブル（１）１２１に示すように、発注者拠点が
「キー項目」として、営業日の一定期間の情報が「その
他の項目」として用いられ、また、受注者カレンダマス
タは、同様に、受注者拠点が「キー項目」として、営業
日の一定期間の情報が「その他の項目」として用いられ
ている。

【０１１７】カレンダ登録処理部１ｋでは、発注者情報
処理システム２ｃや受注者情報処理システム３ｅから入
力された発注者カレンダマスタや受注者カレンダマスタ
をデータベース５に格納する。

【０１１８】図３における使用予定算出処理部１ｆで
は、データベース５に格納された発注者カレンダマスタ
や受注者カレンダマスタを、発注者や受注者を示す情報
に含まれている発注者拠点や受注者拠点をキー項目とし
て参照し、納期候補の日付が休日に当たらないかをチェ
ックし、休日である場合は、休日明けの営業日を納期と
するよう設定する。

【０１１９】このようにすることにより、発注者や受注
者の営業日を考慮して納期を設定することができる。
尚、発注部品によっては納入先が発注者と異なる場合が
あり、発注者カレンダマスタは納入先も含めた形で登録
されているものとする。 また、納入先の扱いは発注者
でも良く、発注者拠点という扱いでも良い。

【０１２０】次に、使用予定調整処理部１ｇの処理を説
明する。図４に示す部品構成の製品（１）４１ａの生産
計画を入力とする場合、部品（１）４１ｂ、部品（３）
４２ｂ、部品（４）４２ｃのそれぞれの使用予定が、使
用予定算出処理部１ｆで自動的に算出されることになる
が、発注者が発注を行う際、自動算出された結果を見直
す場合がある。

【０１２１】また、先に説明したように、発注者によっ
ては発注の際、製品（１）４１ｂの生産計画を入力とす
るのではなく、部品（１）４１ｂ、部品（３）４２ｂ、
部品（４）４２ｃのそれぞれの使用予定を直接、発注者
情報処理システム２ｃから注文支援システム１ｂに入力
する場合がある。

【０１２２】これらのケースに対応するために、使用予
定調整処理部１ｇが設けられている。すなわち、発注者
は、発注を行う際、発注者情報処理システム２ｃから、
部品（１）４１ｂ、部品（３）４２ｂ、部品（４）４２
ｃのそれぞれの発注者部品番号をキー項目とした使用予
定情報を、注文支援システム１ｂに入力する。

【０１２３】これに伴い、注文支援システム１ｂは、使
用予定調整処理部１ｇにより、受け取った発注者部品番
号をキー項目として、データベース５を参照し、当該情
報を抽出して、発注者情報処理システム２ｃに返す。

【０１２４】発注者情報処理システム２ｃでは、注文支
援システム１ｂからの情報を表示装置の画面上に表示す
る。このようにして表示された内容を基に、発注者は、
先に使用予定算出処理部１ｆで自動的に算出された結果
を確認する。

【０１２５】確認内容に問題がなければ、この情報を同
見直情報として使用予定調整処理部１ｇに入力するが、
内容に変更がある場合は、変更内容を同見直情報として
使用予定調整処理部１ｇに入力する。

【０１２６】発注者が生産計画に基づく発注を行わない
場合、すなわち、使用予定算出処理１ｆを利用しない発
注を行う場合、あるいは、発注者からの図５に示す構成
マスタの入力がなく、その結果として、発注に使用予定
算出処理部１ｆを利用できない場合にも、上述した使用
予定調整処理部１ｇの処理により、発注者情報処理シス
テム２ｃにおいて、前回入力された使用予定情報が表示
されるので、発注者は、それを参考に、今回分を新たな
同見直情報として使用予定調整処理部１ｇを介して入力
できる。

【０１２７】このような使用予定調整処理部１ｇでの数
量に関する処理には、月別処理と日別処理に分類され、
使用予定調整処理部１ｇにおいて、（I）日別処理した
ものを月別処理にまとめる場合と、（II）月別処理した
ものを日別に展開する場合がある。

【０１２８】その際、（II）における日別展開を発注者
が行い、発注者情報処理システム２ｃから、注文支援シ
ステム１ｂの使用予定調整処理部１ｇに入力することも
できるが、日別展開自体、入力項目も多く作業が煩雑で
ある。

【０１２９】月別処理の場合、使用予定情報の納期は、
月指定であり、それに対して数量が設定されている。従
って、それを日別展開する場合、日別の納期と数量割振
りは発注者が判断する必要がある。発注者は、発注部品
と受注者により個別にその判断をしているが、経験的に
幾つかのパターンに別けられることが多い。

【０１３０】そこで、一ヶ月の数量を、当月内で、何日
に、何％を割り振るかを指定した日割パターンを予め設
定しておく。そして、発注者情報処理システム２ｃか
ら、同見直情報として日割パターン番号を、注文支援シ
ステム１ｂの使用予定調整処理部１ｇに入力すると、使
用予定調整処理部１ｇにおいて、月合計数量を、そのパ
ターンに従って日別に展開し、使用予定情報としてデー
タベース５に格納する。

【０１３１】この日割パターンを設定するための仕組み
を、本例では、図８に示すようにして注文支援システム
１ｂに設ける。

【０１３２】図８は、図３における注文支援システムの
第４の詳細構成例を示すブロック図である。日割パター
ンを設定するために、本例の電子取引システムでは、本
図８で示すように、注文支援システム１ｂに日割パター
ン登録処理部１ｌを設け、この日割パターン登録処理部
１ｌに対して、発注者が発注者情報システム２ｃから、
日割パターンマスタを入力することで対応する。

【０１３３】本例では、日割パターンマスタは、図１２
のテーブル（１）１２１に示すように、日割パターン番
号が「キー項目」として、また、１日から３１日までの
配分割合（％）が「その他の項目」として用いられてい
る。

【０１３４】日割パターン登録処理部１ｌでは、発注者
情報処理システム２ｃから入力された日割パターンマス
タをデータベース５に格納する。そして、発注者情報処
理システム２ｃより日割パターン番号が入力されると、
図３における使用予定調整処理部１ｇは、この日割パタ
ーン番号をキー項目としてデータベース５の日割パター
ンマスタを参照し、１日から３１日の月合計からの配分
割合を求め、その割合に従い日別に展開する。

【０１３５】さらに、使用予定調整処理部１ｇは、発注
者カレンダマスタと受注者カレンダマスタを、発注者お
よび受注者を示す情報に含まれている発注者拠点と受注
者拠点をキー項目として参照し、配分日が休日に当たら
ないかをチェックし、休日である場合は休日明けの営業
日を配分日とするよう設定する。

【０１３６】尚、この日割パターンによる月別の日別展
開は、使用予定算出処理部１ｆにおいて算出された使用
予定情報にも適用できる。つまり、生産計画の入力が月
別である場合、使用予定調整処理部１ｇにおいて、日割
の使用予定を日割パターンに従い自動算出することが可
能となる。

【０１３７】以上の説明で示すようにして、図３の注文
支援システム１ｂにおける使用予定算出処理部１ｆと使
用予定調整処理部１ｇによる発注者の使用予定の把握
に関する処理が行われる。次に、図３の注文支援システ
ム１ｂにおける発注調整処理部１ｈによる発注量の算
出処理について説明する。

【０１３８】発注量の算出：以下、図３を用いて、発
注調整処理部１ｈによる処理について説明する。発注調
整処理部１ｈは、使用予定から、財源を加味して発注の
過不足量を算出し、それにロット数を加味して発注量
を、また受注者リードタイムと発注チャンスを加味して
発注日付を決定するものである。

【０１３９】発注量の算出は、発注者情報処理システム
２ｃから、使用予定情報の発注量算出指示マークを有り
にした使用予定情報が、発注支援システム１ｂの使用予
定調整処理部１ｇに入力されることで行われる。

【０１４０】発注調整処理部１ｈでは、使用予定調整処
理部１ｇに入力された発注量算出指示マークの有る使用
予定情報の発注部品番号をキー項目としてデータベース
５を参照して、契約残情報の当該発注者部品番号の全発
注者注文番号分に該当する契約残と納期を、また、在庫
情報の当該発注者部品番号の流通在庫数量と発注者在庫
数量を、さらに、使用予定情報の当該発注者部品番号の
数量と納期を、それぞれ抽出する。

【０１４１】そして、発注調整処理部１ｈは、抽出した
使用予定情報の納期を軸として、流通在庫数量と発注者
在庫数量でカバーできる使用予定情報の（納期・数量）
の組を求め（以降、「在庫充当」という）、さらに、在
庫充当できないものの内、契約残でカバーできる使用予
定情報の（納期・数量）の組を求め（以降、「契約残充
当」という）、最後に、在庫充当および契約残充当でカ
バーできない使用予定情報の（納期・数量）の組を求め
る（以降、「使用予定不足」という）。

【０１４２】さらに、発注調整処理部１ｈでは、発注者
部品番号をキー項目として、部品マスタを参照し、当該
発注部品に関する受注者を求める。求めた受注者が複数
の場合は、部品マスタの受注者配分比率により発注量を
案分する。本例では、図４に示す部品（１）４１ａの場
合、図１における受注者Ｃ社３ａと受注者Ｄ社３ｂに発
注されるので、この案分を適用する。

【０１４３】そして、発注調整処理部１ｈでは、部品マ
スタから、受注者毎の受注者リードタイムと発注チャン
スを求め、使用予定不足となっている使用予定情報の
（納期・数量）の組の、納期から受注者リードタイム分
の日数を前倒しにした発注日候補を算出する。

【０１４４】受注者側では、発注を受けることができる
タイミングがある。例えば、月Ｎ回、週１回、毎日等々
であるが、部品マスタより求めた発注チャンスが、これ
らの情報に該当する。そこで、先に求めた発注候補日
を、前倒しをルールとして、発注チャンスに合わせる。

【０１４５】次に、発注調整処理部１ｈでは、発注者カ
レンダマスタおよび受注者カレンダマスタを、発注者や
受注者を示す情報に含まれている発注拠点および受注拠
点をキー項目として参照し、当該発注候補日の日付が、
休日にあたらないかをチェックし、休日である場合は、
休日明けの営業日を発注日付とし、その発注日付にまと
めた使用予定不足の総数量を、発注情報の数量、発注日
付としてデータベース５に格納する。尚、この発注情報
では、図１２のテーブル（１）１２１に示されるよう
に、発注者注文番号と発注者部品番号を「キー項目」、
（納期、数量、発注日付）の一定期間分の情報、発注指
示マークを「その他の項目」としている。

【０１４６】また、発注調整処理部１ｈでは、発注量算
出指示マークが有る使用予定情報に、在庫充当、契約残
充当、使用予定不足の３種類が、どの使用予定情報の
（納期・数量）の組に該当するかを示す充当区分を付加
し、この使用予定情報をデータベース５に格納すると共
に、この使用予定情報および発注情報を発注者情報処理
システム２ｃに出力する。

【０１４７】発注者情報処理システム２ｃでは、発注調
整処理部１ｈから送られてきた使用予定情報および発注
情報を、表示装置の画面上に表示する。これにより、発
注者は、使用予定に対する充当状況を確認できると同時
に、発注者リードタイムと発注チャンスを考慮した、使
用予定不足分の発注すべき内容を、発注情報として確認
できる。

【０１４８】さらに、発注者側で、この発注情報を見直
した結果を、同見直情報として、発注者情報処理システ
ム２ｃから、発注支援システム１ｂの発注調整処理部１
ｈに入力することができ、発注調整処理部１ｈにおいて
は、その同見直情報をデータベース５に格納する。

【０１４９】また、発注者は、生産計画を変更して、充
当状況や発注量の再計算をしたい、あるいは、使用予定
を変更して、充当状況や発注量の再計算をしたい場合
は、それぞれ、生産計画情報の同見直情報、および、使
用予定情報の同見直情報を、発注者情報処理システム２
ｃから注文支援システム１ｂに入力すれば良く、結果が
好適と確認できるまで、繰り返し行うことができる。

【０１５０】発注調整処理部１から注文情報処理部１ｉ
に発注情報が渡され、注文情報処理部１ｉにおいて注文
情報が作成されるのは、発注者が、発注情報の内容を確
認して、発注指示マークを有りにした同見直情報を、発
注者情報処理システム２ｃから注文支援システム１ｂの
発注調整処理部１ｈに入力することで行われる。

【０１５１】発注調整処理部１ｈは、発注指示マークを
有りにした同見直情報をデータベース５に格納すると同
時に、注文情報処理部１ｉに対して、発注情報の出力指
示を通知する。

【０１５２】以上の説明で示すようにして、図３の注文
支援システム１ｂにおける発注調整処理部１ｈによる
発注量の算出処理に関する処理が行われる。次に、図９
を用いて、図３の注文支援システム１ｂにおける注文情
報処理部１ｉおよび出荷情報処理部１ｃの処理動作につ
いて説明する。

【０１５３】図９は、図３における注文支援システムの
第５の詳細構成例を示すブロック図である。この図９を
用いて、まず、注文支援システム１ｂにおける注文情報
処理部１ｉによる注文情報の処理について説明し、そ
の後、注文支援システム１ｂにおける出荷情報処理部１
ｃによる出荷情報の処理について説明する。

【０１５４】注文情報の処理：まず、注文に先立ち、
図５でも説明したように、発注者情報処理システム２ｃ
および受注者情報処理システム３ｅから注文支援システ
ム１ｂに部品マスタを入力する。

【０１５５】注文支援システム１ｂは、入力された部品
マスタ（５ａ）を、構成情報部品情報登録処理部１ｊに
より、データベース５に格納する。この部品マスタ５ａ
に蓄積される情報を図１３におけるテーブル（２）１３
１に示す。

【０１５６】図１３は、図９における部品マスタに蓄積
された情報の構成例を示す説明図である。本図のテーブ
ル（２）１３１に示す内容の情報が、図９における部品
マスタ５ａに蓄積されている。

【０１５７】本テーブル（２）１３１では、発注者と受
注者に項目を対応させて（発注者側項目、受注者側項
目）記載してあるが、実際は、図９の部品マスタ５ａに
おける情報は、発注者部品番号をキーとした１つのレコ
ードである。

【０１５８】図９において、注文情報の作成は、注文情
報処理部１ｉが、図３における発注調整処理部１ｈから
発注情報の出力指示の通知をもらうか、または、発注者
情報処理システム２ｃにおいて作成された発注情報が注
文情報処理部１ｉに入力されたことを契機に行う。尚、
発注情報は、発注者の取引コード体系であり、発注者部
品番号、数量、納期が含まれているものとする。

【０１５９】注文情報処理部１ｉでは、具備した発注確
認処理部１ｍにより、発注者の発注情報から発注者部品
番号を取り出し、この情報（発注者部品番号）をキー項
目として部品マスタ５ａを参照し、部品マスタ５ａに登
録された発注か未登録の発注かを確認する。

【０１６０】未登録の発注の場合は、注文情報処理部１
ｉは、発注者情報処理システム２ｃに対して、未登録通
知（図１２のテーブル（１）１２１に示すように、発注
情報と同一の「キー項目」と「その他の項目」からな
る）を出力する。

【０１６１】尚、図３の発注調整処理部１ｈからの発注
は、この発注調整処理部１ｈにおいて既に部品マスタを
参照した結果の発注であるため、発注確認処理は省かれ
る。

【０１６２】このような発注確認処理部１ｍによる発注
確認処理を実施する目的は、次の処理である受注者の取
引コード体系への変換可否を判断することは当然のこと
として、発注者情報処理システム２ｃからの発注の正当
性を確認することも兼ねている。例えば、本例のＥＤＩ
システム１０が、商社のＥＤＩシステムとして利用され
る場合、商社は発注の代行業務を行っており、発注者か
らの発注の正当性を確認する必要がある。

【０１６３】発注が、部品マスタ５ａに登録された発注
である場合、注文情報処理部１ｉでは、具備した取引コ
ード変換処理部１ｎにより、部品マスタ５ａから得られ
る受注者側項目（受注者取引コード体系）で、受注者が
必要とする項目（予め受注者と取り決めておく）を、注
文情報に埋め込み、発注情報の数量を、部品マスタ５ａ
を使用して単位を変換して、納期を加え、注文情報を作
成する。

【０１６４】次に、注文情報処理部１ｉでは、具備した
受注者注文番号自動採番処理部１ｏにより、取引コード
変換処理部１ｎで作成された注文情報に対し、受注者注
文番号の自動採番処理を施す。尚、発注情報に発注者注
文番号があり、この情報を注文情報に埋め込み受注者情
報処理システム３ｅに出力し、出荷情報として受注者情
報処理システム３ｅから入力される時に、この発注者注
文番号が埋め込まれてくる場合は、本処理を必要としな
い。

【０１６５】しかし、受注者情報処理システム３ｅの都
合で、発注者注文番号を出荷情報まで保持できない場
合、あるいは、発注情報に発注者注文番号が無い場合、
または、本例のＥＤＩシステムが、商社のＥＤＩシステ
ムとして利用される場合には、商社として、改めて受注
者に発注するという観点で、受注者注文番号を受注者と
の間で取り決めた体系で採番し注文情報に加える必要が
ある。従って、本例の注文情報処理部１ｉでは、全ての
注文情報に受注者注文番号を加える処理を行う。

【０１６６】受注者注文番号自動採番処理部１ｏにおけ
る受注者注文番号の採番は、発注者部品番号をキー項目
として、部品マスタ５ａを参照し、受注者側項目の注文
番号マスタ番号を取得し、この注文番号マスタ番号をキ
ー項目として、図１２のテーブル（１）１２１に示す注
文番号マスタ（テーブル（１）１２１においては、「キ
ー項目」として注文番号とマスタ番号が、「その他の項
目」として番号体系（固定項目と連番の範囲）が設けら
れている）を参照し、注文番号の番号体系（固定項目と
連番の範囲）を確認し、最終使用連番の次の番号を採番
した受注者注文番号を作成することで行う。

【０１６７】注文情報処理部１ｉでは、このように作成
された注文情報を、受注者情報処理システム３ｅに向け
て出力する。

【０１６８】このように、注文情報処理部１ｉにおい
て、部品マスタ５ａを参照し、そこから受注者の取引コ
ード体系で記載された受注者側項目を取り出し、注文情
報にセットすることで、発注者の取引コード体系は、受
注者の取引コード体系に変換され、発注者情報処理シス
テム２ｃと受注者情報処理システム３ｅ間での取引コー
ド体系の整合性が確保できることとなる。

【０１６９】次に、出荷情報処理部１ｃにおける出荷
情報の処理について説明する。

【０１７０】出荷情報の処理：出荷情報処理部１ｃの
概要は、財源の把握での処理において説明したが、こ
こでは注文番号と取引コード体系の整合性について説明
する。

【０１７１】出荷情報が、受注者情報処理システム３ｅ
から注文支援システム１ｂの出荷情報処理部１ｃに入力
されると、出荷情報処理部１ｃは、具備した注文番号確
認処理部１ｐにより、受注者注文番号と発注者注文番号
の対応を確認する。この確認は、出荷情報の受注者注文
番号をキー項目として、データベース５内の注文情報の
発注者部品番号を参照して行う。

【０１７２】受注者情報処理システム３ｅの都合で、発
注者注文番号を、出荷情報まで保持できない場合、出荷
情報には、この発注者注文番号が無いため、注文情報か
ら参照した発注者注文番号を、出荷情報の発注者注文番
号に加える。

【０１７３】出荷情報処理部１ｃでは、出荷情報に対応
する注文情報から、発注者部品番号を取り出し、この情
報（発注者部品番号）をキー項目として部品マスタ５ａ
を参照し、具備した取引コード変換処理部１ｑにより、
部品マスタ５ａから得られる発注者側項目（発注者取引
コード体系）で、発注者が必要とする項目（予め発注者
と決めておく）を出荷情報に埋め込み、出荷情報の数
量、納期、納入先を加え、出荷情報を作成する。

【０１７４】そして、出荷情報処理部１ｃでは、このよ
うにして作成された出荷情報を、受注者情報処理システ
ム３ｅに向けて出力する。

【０１７５】このようにして、部品マスタ５ａを参照
し、そこから発注者の取引コード体系で記載された発注
者側項目を取り出し、出荷情報にセットすることで、受
注者の取引コード体系は、発注者の取引コード体系に変
換され、受注者情報処理システム３ｅと発注者情報処理
システム２ｃ間の取引コード体系の整合性が確保できる
こととなる。

【０１７６】尚、従来のＥＤＩシステムにおいて良くあ
る問題の一つに、発注者情報処理システム（２ｃ）と受
注者情報処理システム（３ｅ）との違いによる、電子伝
票フォーマットの項目桁数や属性の不一致がある。

【０１７７】例えば、発注者情報処理システム（２ｃ）
においては発注者部品番号は２５桁を使っているが、受
注者情報処理システム（３ｅ）では２０桁しかない場
合、従来のＥＤＩシステムでは、発注者部品番号は、発
注者から受注者に運べない。あるいは、フォーマットの
予備エリアを使用して（空きがあれば）受注者情報処理
システム（３ｅ）に出力し、受注者側で自社のコードに
変換しなければならない。

【０１７８】この問題に対し、本例の注文支援システム
１ｂにおける変換技術は、図１３のテーブル（２）１３
１の内容で示す部品マスタにおいて、発注者側項目と受
注者側項目との対応付けがなされているので、桁数や属
性の違いに影響されない変換が可能となる。

【０１７９】具体的には、発注者部品番号が２５桁で、
受注者部品番号が２０桁であったとしても、図１３のテ
ーブル（２）１３１において、部品マスタ上、この発注
者部品番号は、どの受注者部品番号に対応しているかが
既知であるため、桁数や属性に関係なくテーブル変換す
れば、対応が付くことになる。

【０１８０】また、図１２のテーブル（１）１２１に示
すように、発注者部品番号はキー項目であるため、本
来、注文情報と出荷情報の両方に付与されていなければ
ならない。その為には、注文情報処理部１ｉから受注者
情報処理システム３ｅに注文情報を出力した後、出荷情
報として受注者情報処理システム３ｅから出荷情報処理
部１ｃに入力されるまで、受注者情報処理システム３ｅ
内において当該情報は保持されていなければならない。
もし、受注者情報処理システム３ｅの都合により、その
保持ができない場合には問題となる。

【０１８１】しかし、本例の電子取引システムでは、こ
のように、受注者情報処理システム３ｅの都合により、
発注者部品番号が保持できない場合にも問題は発生しな
い。

【０１８２】すなわち、本例の注文支援システム１ｂで
は、受注者情報処理システム３ｅに注文情報を出力する
時は、部品マスタを参照し、受注者情報処理システム３
ｅが処理できる受注者部品番号に変換して出力し、か
つ、受注者部品番号で受注者情報処理システム３ｅから
出荷情報処理部１ｃに入力された出荷情報を、再度、部
品マスタを参照することにより発注者部品番号を得るこ
とができる。

【０１８３】このように、本例の電子取引システムで
は、注文支援システム１ｂ内において、キー項目である
発注者部品番号を保持でき、受注者情報処理システム３
ｅでは、発注側の取引コード体系を受け入れるための新
たな処理を開発する必要がない。

【０１８４】以上の図３〜図９、図１２〜１３を用いた
説明においては、１社の発注者情報処理システム２ｃと
複数の受注者情報処理システム（３ｅ）との受発注取引
であったが、以下、図１０と図１１を用いて、それぞれ
複数の発注者情報処理システム２ｃ〜２ｅと受注者情報
処理システム（３ｅ）との受発注取引に関して説明す
る。

【０１８５】図１０は、図３における注文支援システム
の第６の詳細構成例を示すブロック図である。本例で
は、発注者が、親子関係にある複数の発注者で形成され
た発注者グループでの電子取引システムの利用例を示
し、特に、発注者（親発注者）が、使用予定や発注量算
出を行う場合の例を示す。

【０１８６】図１０に示す例では、親発注者Ａ社があ
り、その子発注者（以下、「協力会社」という）として
のＧ社とＨ社があり、図４に示す製品（１）の生産計画
は、親発注者Ａ社から供給されるが、部品（３）、部品
（４）は受注者から協力会社Ｇ社、協力会社Ｈ社に納入
され、それぞれで部品（２）として組み立てられて、親
発注者Ａ社に納入される。

【０１８７】本例の注文支援システム１ｂを具備したＥ
ＤＩシステムでは、以下に説明するようにして、このよ
うな複数の発注者で形成された発注者グループでの発注
業務を、相互に情報を共有しながら効率よく実施するこ
とができる。

【０１８８】尚、注文支援システム１ｂ（ＥＤＩシステ
ム）で使用するデータベースのアクセス権限、すなわち
参照権限や更新権限は、ＥＤＩシステムを利用する複数
の発注者または受注者に付与でき、発注者毎、受注者
毎、情報区分毎に、個別に定義することが可能である。

【０１８９】本図１０における例は、使用予定・発注量
算出を、発注者情報処理システム２ｃ〜２ｅ側で実施す
る場合を示すものである。すなわち、親発注者Ａ社が、
協力会社Ｇ社、Ｈ社の注文支援システム１ｂにおいて管
理している契約残情報や在庫情報を参照し、自社で使用
予定・発注量算出を行い発注を実施する場合の例であ
る。

【０１９０】親発注者Ａ社側の発注者情報処理システム
２ｃは、図３で説明したＥＤＩシステムにおける注文支
援システム１ｂと同様の、契約残処理部１Ｄ、在庫情報
処理部１Ｅ、使用予定算出部１Ｆ、使用予定調整処理部
１Ｇ、発注調整処理部１Ｈを具備しており、契約残や在
庫の管理ができ、自社の生産計画から、使用予定を算出
し、契約残や在庫を加味して発注量を算出することがで
きる。

【０１９１】また、本例のＥＤＩシステムにおける注文
支援システム１ｂには、Ｇ社とＨ社のそれぞれに対応し
て、出荷情報処理部１ｓ，１ｗ、契約残処理部１ｔ，１
ｘ、在庫情報処理部１ｕ，１ｙからなるＧ社分処理部１
ｒとＨ社分処理部１ｖが設けられ、Ｇ社とＨ社のそれぞ
れの契約残情報や在庫情報が、図３の例で説明したよう
にして管理される。

【０１９２】また、Ｇ社は、自社分の注文支援システム
に係わるデータベースのみに対する参照権限や更新権限
を持ち、他社（Ｈ社）の分に関する参照権限や更新権限
は無い。Ｈ社についても、Ｇ社と同様である。Ａ社は、
Ｇ社とＨ社の両方の注文支援システム１ｂにおける契約
残情報や在庫情報に係わるデータベースに対する参照権
限を持つ。

【０１９３】発注は、Ｇ社、Ｈ社の分も含め、Ａ社の発
注者情報処理システム２ｃから行われ、例えば、受注者
情報処理システム３ｅからＧ社、Ｈ社に納入される。そ
して、その納入タイミングで、出荷情報が、注文支援シ
ステム１ｂにおけるＧ社分処理部１ｒとＨ社社分処理部
１ｖのそれぞれの出荷情報処理部１ｓ，１ｗから、Ｇ
社、Ｈ社のそれぞれの発注者情報処理システム２ｄ，２
ｅに出力される。

【０１９４】これらの発注者情報処理システム２ｄ，２
ｅでの検収の結果が、検収情報として、Ｇ社分処理部１
ｒとＨ社社分処理部１ｖのそれぞれの在庫情報処理部１
ｕ，１ｙに反映される。そして、Ａ社は、このようなＧ
社、Ｈ社の在庫情報を在庫情報処理部１Ｅを介して確認
することにより、自社発注分の検収を確認する。

【０１９５】さらに、Ａ社は、自社の生産計画から発注
量を算出する際、注文支援システム１ｂにおけるＧ社分
処理部１ｒとＨ社社分処理部１ｖのそれぞれの契約残処
理部１ｔ，１ｘと在庫情報処理部１ｕ，１ｙから、Ｇ
社、Ｈ社のそれぞれの契約残情報と在庫情報を参照し、
それに自社の在庫と契約残を加え、発注者グループ全体
の契約残と在庫を把握した上で、使用予定および発注量
の算出をする。

【０１９６】以上、図１０では、親子関係にある複数の
発注者で形成された発注者グループにおいて、発注者
（親発注者Ａ社）が、使用予定や発注量算出を行う場合
の例を示したが、以下、図１１を用いて、同様の発注者
グループにおいて、ＥＤＩシステム側で、使用予定や発
注量算出を行う場合の例を説明する。

【０１９７】図１１は、図３における注文支援システム
の第７の詳細構成例を示すブロック図である。本例で
は、ＥＤＩシステムに設けられた注文支援システムが、
親子関係にある複数の発注者で形成された発注者グルー
プでの電子取引システムの利用例を示す。

【０１９８】特に、本例では、親発注者Ａ社と、その協
力会社であるＧ社とＨ社のそれぞれが、発注者情報処理
システム２ｃ〜２ｅを介して、ＥＤＩシステムの注文支
援システム１ｂにおける契約残情報や在庫情報、使用予
定情報、および、発注情報等を共有して、共同作業とし
て発注を行う。

【０１９９】本例の注文支援システム１ｂにおいては、
Ｇ社、Ｈ社のそれぞれに対応して、契約残処理部１ｔ，
１ｘ、在庫情報処理部１ｕ，１ｙ、使用予定算出処理部
１ｆ、使用予定調整処理部１ｇ、発注調整処理部１ｈか
らなるＧ社分処理部１ＲとＨ社分処理部１Ｖとが設けら
れている。

【０２００】このため、Ｇ社は、注文支援システム１ｂ
における自社に係わるデータベースのみに対する参照権
限や更新権限を持ち、他社（Ｈ社等）に係わるデータベ
ースに対する参照権限や更新権限は無い。Ｈ社について
も、Ｇ社と同様である。尚、Ａ社は、Ｇ社、Ｈ社のそれ
ぞれに係わるデータベースに対する参照権限と更新権限
を持つ。

【０２０１】このように、本例においては、Ａ社は、Ｇ
社、Ｈ社の使用予定情報の更新権限を持つので、図４に
おける製品（１）の生産計画情報が、Ａ社の発注者情報
処理システム２ｃから、注文支援システム１ｂのＧ社分
処理部１ＲとＨ社分処理部１Ｖにおける使用予定算出処
理部１ｆに入力され、各使用予定算出処理部１ｆからそ
れぞれの更新権限のあるデータベースに格納される。
尚、ここでのＡ社からのＧ社、Ｈ社に対する製品（１）
の生産計画は、Ｇ社、Ｈ社の能力に応じて異なった量が
入力されるものとする。

【０２０２】このようにして生産計画情報が入力される
と、Ｇ社分処理部１ＲとＨ社分処理部１Ｖのそれぞれの
使用予定算出処理部１ｆは、それぞれの部品（３）、部
品（４）のＧ社、Ｈ社分の使用予定情報を求めてデータ
ベースに格納する。

【０２０３】さらに、Ｇ社、Ｈ社は、このようにして注
文支援システム１ｂ側のデータベースに格納されたＧ社
分、Ｈ社分の使用予定情報を、注文支援システム１ｂの
Ｇ社分処理部１ＲとＨ社分処理部１Ｖのそれぞれに設け
られた使用予定調整処理部１ｇを介して、各発注者情報
処理システム２ｄ，２ｅに取り込み、表示装置の画面上
に表示する。

【０２０４】Ｇ社、Ｈ社の各操作担当者は、表示された
情報を参照して、自社の状況を確認の上、算出された部
品（３）、部品（４）の使用予定情報の見直しを実施
し、その見直し結果を、使用予定情報の同見直情報（発
注量算出指示マーク有り）として、各発注者情報処理シ
ステム２ｄ，２ｅから注文支援システム１ｂのＧ社分処
理部１ＲとＨ社分処理部１Ｖにおける使用予定調整処理
部１ｇに入力する。

【０２０５】注文支援システム１ｂのＧ社分処理部１Ｒ
とＨ社分処理部１Ｖにおける発注調整処理部１ｈでは、
使用予定調整処理部１ｇを介して、発注量算出指示マー
ク有りとなっている使用予定情報が入力されると、発注
量の算出を行う。

【０２０６】その結果、Ｇ社またはＨ社の各使用予定情
報に、在庫充当と契約残充当および使用予定不足の３種
類が、どの使用予定情報の（納期・数量）の組に該当す
るかを示す充当区分を付加され、発注情報（見直し）と
して、Ｇ社分処理部１ＲとＨ社分処理部１Ｖにおける発
注調整処理部１ｈから、Ｇ社またはＨ社の発注者情報処
理システム２ｄ，２ｅに出力され、同時に、Ａ社の発注
者情報処理システム２ｃにも出力される。

【０２０７】Ｇ社またはＨ社の発注者情報処理システム
２ｄ，２ｅ、および、Ａ社の発注者情報処理システム２
ｃにおいては、発注情報（見直し）を、表示装置の画面
上に表示する。

【０２０８】このようにして、Ａ社が提供した生産計画
に基づき、Ｇ社、またはＨ社の契約残や在庫情報を加味
し、さらに、Ｇ社、Ｈ社の使用予定情報の見直し分を加
味した形の情報が、Ａ社とＧ社、またはＡ社とＨ社の間
で共有する。

【０２０９】各表示結果を見て、Ａ社とＧ社の各担当
者、またはＡ社とＨ社の各担当者が、それぞれ、まだ調
整が必要だと判断した場合、Ａ社は、生産計画を、ま
た、Ｇ社とＨ社は、使用予定情報の見直しを修正する。
あるいは、その両方を、注文支援システム１ｂによる情
報共有を利用して実施し、使用予定情報と発注情報を共
同で作成する。

【０２１０】このようにして、使用予定情報と発注情報
の作成が終了すると、発注を行うこととなるが、その
際、本例では、Ａ社とＧ社の間では、発注権限はＡ社に
あり、Ａ社とＨ社の間では、発注権限はＨ社にあるの
で、Ａ社とＧ社の間では、Ａ社の発注者情報処理システ
ム２ｃから発注指示マークが有りになった発注情報を、
注文支援システム１ｂのＧ社分処理部１Ｒにおける発注
調整処理部１ｈに入力し、また、Ａ社とＨ社の間では、
Ｈ社の発注者情報処理システム２ｅから、発注指示マー
クが有りになった発注情報を、注文支援システム１ｂの
Ｈ社分処理部１Ｖにおける発注調整処理部１ｈに入力す
ることで、発注を行う。

【０２１１】以上、図１〜図１４を用いて説明したよう
に、本例の電子取引システムと方法では、（１）従来の
ＥＤＩ処理を行うＥＤＩシステムに、新たに注文支援シ
ステムを設け、このＥＤＩシステムに、発注者側および
受注者側の情報処理システムからネットワークを介し
て、注文を受けた部品の内容を示す注文情報と、部品の
出荷の内容を示す出荷情報、部品が納入されたことを示
す検収情報、部品で構成される製品を出庫あるいは製造
するために当該部品を引当した際の製品の数量を示す引
当情報、部品の棚卸在庫数量を示す棚卸情報、製品と部
品の構成関係を示す構成マスタを入力し、注文支援シス
テムにおいて、これらの注文情報、出荷情報、検収情
報、引当情報、棚卸情報、および、構成マスタをデータ
ベースの形態で記憶する。

【０２１２】そして、注文支援システムは、発注者側お
よび受注者側の情報処理システムで入力されたキー項目
をネットワークを介して受け付け、このキー項目に関連
する情報（契約残情報や在庫情報）をデータベースから
抽出して、発注者側および受注者側の情報処理システム
に出力する。

【０２１３】これにより、発注者は、ＥＤＩシステムに
注文した部品について、自情報処理システムにおけるキ
ー項目入力操作により、ネットワークで接続されたＥＤ
Ｉシステムのデータベースから、キー項目に対応する契
約残情報や在庫情報を入手して、表示出力することがで
き、当該部品の契約残や在庫に関する情報を容易に知る
ことができる。

【０２１４】また、発注者は、協力会社分の発注者関連
部品についても、同様にして、当該データベースから協
力会社の契約残情報や在庫情報を入手して、当該部品の
協力会社分の契約残や在庫に関する情報を知ることがで
きる。

【０２１５】（２）さらに、本例の電子取引システムと
方法では、注文を受けた部品の契約残を示す契約残情
報、部品の在庫を示す在庫情報、部品で構成される製品
の生産計画を示す生産計画情報、部品の使用予定を示す
使用予定情報、部品の発注の内容を示す発注情報、部品
の発注条件や受注条件を発注者取引コード体系および受
注者取引コード体系で記載された部品マスタ、発注者の
営業日を示す発注者カレンダマスタ、受注者の営業日を
示す受注者カレンダマスタに関しても、注文支援システ
ムにおいてデータベースに記録して管理し、各情報を、
ネットワークを介して発注者側および受注者側の情報処
理システムに提供する。

【０２１６】これにより、発注者は、ネットワークを介
してＥＤＩシステムに、製品の生産計画情報を入力し、
かつ、ＥＤＩシステムのデータベースからキー項目によ
り使用予定情報を読み出すことができ、当該製品から展
開される注文の対象となる部品の使用予定を容易に知る
ことができる。

【０２１７】さらに、発注者は、ネットワークを介して
ＥＤＩシステムのデータベースに、使用予定情報の見直
しも含め、部品の使用予定を入力し、かつ、ＥＤＩシス
テムのデータベースからキー項目により使用予定情報お
よび発注情報を読み出すことができ、使用予定に対し、
契約残で充当される分と在庫で充当される分、および注
文の対象となる部品の発注内容を容易に知ることができ
る。

【０２１８】そして、発注者は、生産計画から使用予定
を求めて発注内容を求めるまでの処理操作において、生
産計画の変更あるいは使用予定の変更を繰り返し行うこ
とで、発注者に好適な発注内容を求めることができる。

【０２１９】また、発注者は、生産計画無しで、使用予
定だけの入力でも、発注内容を求めることができる。さ
らに、発注者は、ＥＤＩシステムに対して、一度出力さ
れた発注情報の見直しも含め、注文の対象となる部品の
発注内容を入力し、ＥＤＩシステムのデータベースから
発注情報を読み出して表示し、当該発注情報の内容の確
認をした後、発注指示を行うことにより、この発注情報
の発注を容易に行うことができる。

【０２２０】また、各情報の管理を発注者グループの共
同作業として行うことができ、この場合、親会社の発注
者が、協力会社分の発注者製品の生産計画情報を入力
し、そして、その結果である使用予定情報の見直しを協
力会社で入力し、さらに、その結果である使用予定情報
と発注情報を、発注者と協力会社両方で確認する処理サ
イクルを、好適な発注内容になるまで繰り返し行い、発
注内容が決定されると、発注権限を持つ側が発注指示を
行うことにより、各社に好適な発注内容での発注を行う
ことができる。

【０２２１】（３）また、本例の電子取引システムと方
法では、受注者注文番号の番号体系を示す注文番号マス
タに関しても、注文支援システムにおいてデータベース
に記録して管理し、各情報を処理して、ネットワークを
介して発注者側および受注者側の情報処理システムに提
供する。

【０２２２】例えば、注文支援システムから、部品マス
タと発注情報との照合結果を提供することができ、発注
者は、発注情報の正当性を確認することができる。ま
た、注文支援システムにおいて、部品マスタと発注情報
および注文番号マスタに基づき、受注者注文番号を自動
採番した注文情報を出力することができ、受注者は、自
社の注文体系で処理を行うことができる。

【０２２３】また、注文支援システムにおいて、部品マ
スタと注文情報、出荷情報に基づき、受注者注文番号と
発信者注文番号との対応付けを行い、発注者注文番号を
埋め込んだ出荷情報を出力することにより、発注者と受
注者間の注文番号を対応付けることができる。

【０２２４】さらに、注文支援システムにおいて、発注
者取引コード体系の発注情報から受注者取引コード体系
に変換した注文情報を出力することにより、あるいは、
受注者取引コード体系の出荷情報から発注者取引コード
体系に変換した出荷情報を出力することにより、発注
者、および、受注者の取引コード体系の整合性を確保で
き、発注者は発注者の取引コード体系で、受注者は受注
者の取引コード体系でそれぞれの処理が可能となる。

【０２２５】（４）また、本例の電子取引システムと方
法では、使用予定情報や部品マスタ、発注者カレンダマ
スタ、受注者カレンダマスタと共に、一ヶ月分の使用予
定情報の数量を、当月内で、何日に、何％を割り振るか
を指定した日割パターンマスタに関しても、注文支援シ
ステムにおいてデータベースに記録して管理し、各情報
を処理して、ネットワークを介して発注者側および受注
者側の情報処理システムに提供する。

【０２２６】例えば、注文支援システムでは、発注者か
ら、月別の使用予定情報を日割パータン番号と共に入力
されると、データベースの各情報を参照して、日割に展
開した使用予定情報を出力する。尚、使用予定情報にお
ける納期は、発注者、受注者の休日に当たらないよう決
定する。これにより、発注者の、月別使用予定情報から
日別への展開操作が簡略化される。

【０２２７】尚、本発明は、図１〜図１４を用いて説明
した例に限定されるものではなく、その要旨を逸脱しな
い範囲において種々変更可能である。例えば、本例で
は、注文支援システムを設けたＥＤＩシステムを例とし
て説明したが、ＥＤＩシステムに限定されることなく、
インターネットなどのコンピュータネットワークに接続
されたクライアント・サーバモデルのコンピュータシス
テムでの電子取引システムに係わるものである。

【０２２８】また、本例では、光ディスク１４５を記録
媒体として用いているが、ＦＤを記録媒体として用いる
ことでも良い。また、プログラムのインストールに関し
ても、通信装置１４７を介してネットワーク経由でプロ
グラムをダウンロードしてインストールすることでも良
い。

【０２２９】

【発明の効果】本発明によれば、電子取引システムでの
発注側と受注側のそれぞれにおける、受発注処理に係わ
る作業負荷およびその受発注に関連する情報の管理に係
わる作業負荷を軽減すること、および、電子取引システ
ムの利用の促進を図ることが可能である。

【０２３０】例えば、発明により、発注者は、発注した
部品の契約残や在庫を、ＥＤＩシステムなどを利用して
管理することができる。このことは、単に発注情報を入
力するだけではメリットが少ないと判断していた発注者
に対し、発注者の発注業務に役立つ情報が提供されるの
で、発注者側のＥＤＩ化の促進が図れる。

【０２３１】具体的には、紙の台帳と人間系で発注業務
を管理している発注者にとっては、精度の高い契約残や
在庫に関する管理指標が迅速に提供されることになり、
発注用の情報処理システムを持つ発注者においても、Ｅ
ＤＩシステムから出力される各情報を取り込み、活用す
ることにより、発注管理業務のシステム化において開発
負担を軽減できる。また、精度を向上させるための照合
情報として活用できる。

【０２３２】また、発注者グループにおける発注管理業
務で見た場合、親発注者は、各協力会社毎の精度の高い
契約残や在庫が迅速に把握できるだけでなく、各協力会
社とも、同一のＥＤＩシステムを利用して、各情報の管
理を行うため管理手法が統一され、発注者グループ全体
の発注管理業務の標準化が図れる。

【０２３３】さらに、本発明では、発注者は、生産計
画、使用予定、適正発注量、注文、出荷、検収、契約
残、在庫までの、発注業務に関する全サイクルを例えば
ＥＤＩシステムを利用して行うことが可能となり、発注
者に対する効果をさらに高めることが可能となる。

【０２３４】特に大きな効果は、発注者グループにおけ
る発注管理業務で本発明を利用した場合であり、この場
合、ネットワーク上のＥＤＩシステムにある発注者グル
ープ全員に共通な注文支援システムを利用するので、親
発注者と各協力会社が発注に関する諸情報を共有して、
生産計画から適正発注量を算出する作業を共同作業とし
て実施できるので、発注者グループ全体の作業の迅速化
が図れ、共通のシステム利用による業務の標準化と、管
理指標精度の向上が図れる。そして、その結果として、
発注グループ全体の在庫の圧縮、生産工程の短縮、人件
費削減が図れる。

【０２３５】また、本発明では、例えば、ＥＤＩの普及
に伴い、発注者接続数が増加した場合、従来は通例とし
て、受注者側に負担がかかっていた取引コード体系の整
合性確保を、ＥＤＩシステムが行うことにより、受注者
の人件費負担、あるいは受注者情報処理システム側の整
合性に関する開発費用や処理負荷を軽減することができ
る。

【０２３６】また、事前に部品マスタに登録することに
より、リピート性の高い取引の電子化への利用が促進さ
れる。すなわち、事前に部品マスタに登録しておけば、
発注操作は、発注者部品番号と、納期、数量の入力のみ
となる。このことは、何度も入力されるリピート性の高
い発注において、発注者側の情報処理システムの入力項
目を極力減らし、操作性向上も含め、処理負荷を軽減で
き、かつ発注情報の伝送量も軽減することができる。

【０２３７】さらに、商社ＥＤＩシステムという観点で
見ても、取引オペレータが人間系で行っていた、取引コ
ード体系の変換、受注者注文番号の採番なども自動化が
可能となり、リピート性の高い取引については、部品マ
スタを登録し、注文支援システムを利用することで、業
務の標準化を可能とし、取引毎の部分的情報処理化を、
一貫性のある情報処理システムに置きかえていくことを
可能とする。

【０２３８】また、本発明によれば、発注者の発注管理
業務において、納期をベースとした発注管理における例
えばＥＤＩシステムの操作性を向上させることができ
る。また、本発明によれば、例えば商社のＥＤＩシステ
ムとして利用される場合に必要な、発注者からの発注の
正当性を自動的に確認することができる。

【図面の簡単な説明】

【図１】本発明の電子取引システムによる取引形態例を
示すブロック図である。

【図２】本発明に係わる電子取引システムのハードウェ
ア構成例を示すブロック図である。

【図３】本発明に係わる電子取引システムの構成例を示
すブロック図である。

【図４】図１における発注者Ａ社の製造する製品の部品
構成例を示す説明図である。

【図５】図３における注文支援システムの第１の詳細構
成例を示すブロック図である。

【図６】図３における注文支援システムの第２の詳細構
成例を示すブロック図である。

【図７】図３における注文支援システムの第３の詳細構
成例を示すブロック図である。

【図８】図３における注文支援システムの第４の詳細構
成例を示すブロック図である。

【図９】図３における注文支援システムの第５の詳細構
成例を示すブロック図である。

【図１０】図３における注文支援システムの第６の詳細
構成例を示すブロック図である。

【図１１】図３における注文支援システムの第７の詳細
構成例を示すブロック図である。

【図１２】図１におけるＥＤＩシステムで用いるテーブ
ルの構成例を示す説明図である。

【図１３】図１におけるＥＤＩシステムで用いる他のテ
ーブルの構成例を示す説明図である。

【図１４】図２におけるサーバおよび発注者情報処理シ
ステムと受注者情報処理システムのハードウェア構成例
を示すブロック図である。

【符号の説明】

１ａ：ＥＤＩデータ処理部、１ｂ：注文支援システム、
１ｃ：出荷情報処理部、１ｄ：契約残処理部、１ｅ：在
庫情報処理部、１ｆ：使用予定算出処理部、１ｇ：使用
予定調整処理部、１ｈ：発注調整処理部、１ｉ：注文情
報処理部、１ｊ：構成情報部品情報登録処理部、１ｋ：
カレンダ登録処理部、１ｌ：日割パターン登録処理部、
１ｍ：発注確認処理部、１ｎ：取引コード変換処理部、
１ｏ：受注者注文番号自動採番処理部、１ｐ：注文番号
確認処理部、１ｑ：取引コード変換処理部、１ｒ：Ｇ社
分処理部、１ｓ，１ｗ：出荷情報処理部、１ｔ，１ｘ：
契約残処理部、１ｕ，１ｙ：在庫情報処理部、１ｖ：Ｈ
社分処理部、１Ｄ：契約残処理部、１Ｅ：在庫情報処理
部、１Ｆ：使用予定算出部、１Ｇ：使用予定調整処理
部、１Ｈ：発注調整処理部、１Ｒ：Ｇ社分処理部、１
Ｖ：Ｈ社分処理部、２ａ：発注者Ａ社、２ｂ：発注者Ｂ
社、２ｃ〜２ｅ：発注者情報処理システム、３ａ：受注
者Ｃ社、３ｂ：受注者Ｄ社、３ｃ：受注者Ｅ社、３ｄ：
受注者Ｆ社、３ｅ〜３ｇ：受注者情報処理システム、
４：サーバ、５：データベース、５ａ：部品マスタ、
６：ネットワーク、１０：ＥＤＩシステム、４１：部品
定義（１）、４１ａ：製品（１）、４１ｂ：部品
（１）、４２：部品定義（２）、４２ａ：部品（２）、
４２ｂ：部品（３）、４２ｃ：部品（４）、４３：部品
定義（１）テーブル、４４：部品定義（２）テーブル、
１２１：テーブル（１）、１３１：テーブル（２）、１
４１：表示装置、１４２：入力装置、１４３：外部記憶
装置、１４４：情報処理装置、１４４ａ：ＣＰＵ、１４
４ｂ：主メモリ、１４５：光ディスク、１４６：駆動装
置、１４７：通信装置。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 加古 史明 東京都千代田区丸の内二丁目６番３号 三 菱商事株式会社内 (72)発明者 三山 裕司 東京都大田区仲六郷４−32−５ 株式会社 ベル・インフォ・テック内 (72)発明者 衛藤 知彦 東京都渋谷区道玄坂一丁目16番５号 株式 会社日立情報システムズ内 Ｆターム(参考） 5B049 BB07 CC05 CC08 CC27 EE05 FF01 GG02

Claims (11)

【特許請求の範囲】
1. 【請求項１】 発注側のコンピュータシステム（発コン
   ピュータ）と、受注側のコンピュータシステム（受コン
   ピュータ）、および、該受コンピュータと上記発コンピ
   ュータにネットワークで接続された注文支援コンピュー
   タシステムとからなり、該注文支援コンピュータシステ
   ムにより、上記発コンピュータと上記受コンピュータ間
   での各種情報の送受信を行い両システム間での受発注処
   理を行う電子取引システムであって、上記注文支援コン
   ピュータシステムは、上記発コンピュータから受信した
   発注情報を、予め記憶装置に記録されている第１の変換
   テーブル情報を読み出し参照して、上記受コンピュータ
   に対応した注文情報に変換し、記憶装置に記録すると共
   に発注先の上記受コンピュータに送信する注文情報処理
   手段と、上記受コンピュータから受信した上記注文情報
   に対応する出荷情報を、予め記憶装置に記録されている
   第２の変換テーブル情報を読み出し参照して、上記発コ
   ンピュータに対応した内容に変換し、記憶装置に記録す
   ると共に発注元の上記発コンピュータに送信する出荷情
   報処理手段と、上記発コンピュータから受信した納品検
   収情報と引当情報および棚卸情報のそれぞれに基づき、
   記憶装置に記録されている対応する品物の在庫量を変更
   して記録する在庫情報処理手段とを有することを特徴と
   する電子取引システム。
2. 【請求項２】 発注側のコンピュータシステム（発コン
   ピュータ）と、受注側のコンピュータシステム（受コン
   ピュータ）、および、該受コンピュータと上記発コンピ
   ュータにネットワークで接続された注文支援コンピュー
   タシステムとからなり、該注文支援コンピュータシステ
   ムにより、上記発コンピュータと上記受コンピュータ間
   での各種情報の送受信を行い両システム間での受発注処
   理を行う電子取引システムであって、上記注文支援コン
   ピュータシステムは、上記発コンピュータから受信した
   発注情報を、予め記憶装置に記録されている第１の変換
   テーブル情報を読み出し参照して、上記受コンピュータ
   に対応した注文情報に変換し、記憶装置に記録すると共
   に発注先の上記受コンピュータに送信する注文情報処理
   手段と、上記受コンピュータから受信した上記注文情報
   に対応する出荷情報を、予め記憶装置に記録されている
   第２の変換テーブル情報を読み出し参照して、上記発コ
   ンピュータに対応した内容に変換し、記憶装置に記録す
   ると共に発注元の上記発コンピュータに送信する出荷情
   報処理手段と、上記発コンピュータから受信した納品検
   収情報と引当情報および棚卸情報のそれぞれに基づき、
   記憶装置に記録されている対応する品物の発注者在庫量
   を変更して記録する第１の在庫情報処理手段と、上記出
   荷情報処理手段で変換された上記出荷情報に基づき、記
   憶装置に記録されている対応する品物の流通在庫量を加
   算して記録しておき当該品物に対する上記納品検収情報
   に基づき減算する第２の在庫情報処理手段と、上記記憶
   装置から上記注文情報処理手段で変換した注文情報と該
   注文情報に対応する上記出荷情報処理手段で変換した出
   荷情報とを読み出し、該出荷情報と上記注文情報とに基
   づき、契約残情報を生成して記憶装置に記録する契約残
   処理手段と、上記発コンピュータから製品の生産計画情
   報を受信すると、予め記憶装置に記録された当該製品の
   構成マスタ情報を読み出し参照して、上記製品を構成す
   る各部品を抽出し、該各部品それぞれの上記製品の生産
   に必要な使用量を算出して記憶装置に記録する第１の使
   用予定処理手段と、上記記憶装置から上記第１の使用予
   定処理手段で算出した上記各部品の使用量と該各部品の
   上記在庫管理情報処理手段で記録した発注者在庫量とを
   読み出して、上記製品の生産量に対応する上記各部品の
   発注量を算出すると共に、予め記憶装置に記録されたカ
   レンダ情報と納品日割配分パターン情報とを読み出して
   参照し、上記製品の生産計画日程に対応する各部品の納
   品期日を特定して、上記生産する製品に対応する各部品
   の発注情報を生成し、記憶装置に記録する第２の使用予
   定処理手段と、上記記憶装置から上記第２の使用予定処
   理手段で生成した上記各部品の発注情報と上記契約残処
   理手段で生成した対応する各部品の契約残情報とを読み
   出し、該契約残情報に基づき上記各部品の発注情報を変
   更して記憶装置に記録すると共に上記注文情報処理手段
   に出力する発注調整処理手段とを有することを特徴とす
   る電子取引システム。
3. 【請求項３】 請求項１、もしくは、請求項２のいずれ
   かに記載の電子取引システムであって、上記注文支援コ
   ンピュータシステムをＥＤＩシステムに設け、該ＥＤＩ
   システムで、複数の上記発コンピュータと複数の上記受
   コンピュータそれぞれの発注情報処理と出荷情報処理お
   よび在庫情報管理処理を代行することを特徴とする電子
   取引システム。
4. 【請求項４】 発注側のコンピュータシステム（発コン
   ピュータ）と、受注側のコンピュータシステム（受コン
   ピュータ）、および、該受コンピュータと上記発コンピ
   ュータにネットワークで接続された注文支援コンピュー
   タシステムとからなり、該注文支援コンピュータシステ
   ムにより、上記発コンピュータと上記受コンピュータ間
   での各種情報の送受信を行い両システム間での受発注処
   理を行う電子取引方法であって、上記注文支援コンピュ
   ータシステムは、上記発コンピュータから受信した発注
   情報を、予め記憶装置に記録されている第１の変換テー
   ブル情報を読み出し参照して、上記受コンピュータに対
   応した注文情報に変換し、記憶装置に記録すると共に発
   注先の上記受コンピュータに送信する第１のステップ
   と、上記受コンピュータから受信した上記注文情報に対
   応する出荷情報を、予め記憶装置に記録されている第２
   の変換テーブル情報を読み出し参照して、上記発コンピ
   ュータに対応した内容に変換し、記憶装置に記録すると
   共に発注元の上記発コンピュータに送信する第２のステ
   ップと、上記発コンピュータから受信した納品検収情報
   と引当情報および棚卸情報のそれぞれに基づき、記憶装
   置に記録されている対応する品物の在庫量を変更して記
   録する第３のステップとを有することを特徴とする電子
   取引方法。
5. 【請求項５】 請求項４に記載の電子取引方法であっ
   て、上記注文支援コンピュータシステムは、上記発コン
   ピュータから製品の生産計画情報を受信すると、予め記
   憶装置に記録された当該製品の構成マスタ情報を読み出
   し参照して、上記製品を構成する各部品を抽出する第４
   のステップと、該抽出した各部品それぞれの上記製品の
   生産に必要な使用量を算出して記憶装置に記録する第５
   のステップと、上記記憶装置から上記第５のステップで
   算出した上記各部品の使用量と該各部品の上記第３のス
   テップで記録した発注者在庫量とを読み出して、上記製
   品の生産量に対応する上記各部品の発注量を算出し、該
   各部品の発注情報を生成する第６のステップとを有し、
   該第６のステップで生成した上記各部品の発注情報を上
   記第１のテーブルを参照して変換し、発注先の上記受コ
   ンピュータに送信することを特徴とする電子取引方法。
6. 【請求項６】 請求項５に記載の電子取引方法であっ
   て、上記注文支援コンピュータシステムは、予め記憶装
   置に記録された発注元および発注先のカレンダ情報と納
   品日割配分パターン情報を読み出し参照して上記製品の
   生産計画日程に対応する各部品の納品期日を特定する第
   ７のステップと、該第７のステップで特定した上記各部
   品の納品期日と上記第６のステップで算出した各部品の
   発注量とに基づき、上記生産する製品に対応する各部品
   の発注情報を生成する第８のステップとを有し、該第８
   のステップで生成した上記各部品の発注情報を上記第１
   のテーブルを参照して変換し、発注先の上記受コンピュ
   ータに送信することを特徴とする電子取引方法。
7. 【請求項７】 請求項４から請求項６のいずれかに記載
   の電子取引方法であって、上記注文支援コンピュータシ
   ステムは、上記記憶装置から上記第１のステップで変換
   した注文情報と該注文情報に対応する上記第２のステッ
   プで変換した出荷情報とを読み出し、該出荷情報と上記
   注文情報とに基づき、契約残情報を生成して記憶装置に
   記録する第９のステップと、上記記憶装置から上記第９
   のステップで生成した対応する各部品の契約残情報を読
   み出し、該契約残情報に基づき、上記各部品の発注情報
   を変更する第１０のステップとを有し、該第１０のステ
   ップで生成した上記各部品の発注情報を上記第１のテー
   ブルを参照して変換し、発注先の上記受コンピュータに
   送信することを特徴とする電子取引方法。
8. 【請求項８】 請求項４から請求項７のいずれかに記載
   の電子取引方法であって、上記注文支援コンピュータシ
   ステムは、上記第２のステップで変換した上記出荷情報
   に基づき、記憶装置に記録されている対応する品物の流
   通在庫量を加算して記録しておき当該品物に対する上記
   納品検収情報に基づき減算する第１１のステップを有す
   ることを特徴とする電子取引方法。
9. 【請求項９】 発注側のコンピュータシステム（発コン
   ピュータ）と、受注側のコンピュータシステム（受コン
   ピュータ）、および、該受コンピュータと上記発コンピ
   ュータにネットワークで接続された注文支援コンピュー
   タシステムとからなり、該注文支援コンピュータシステ
   ムにより、上記発コンピュータと上記受コンピュータ間
   での各種情報の送受信を行い両システム間での受発注処
   理を行う電子取引方法であって、上記注文支援コンピュ
   ータシステムは、上記発コンピュータから受信した発注
   情報を、予め記憶装置に記録されている第１の変換テー
   ブル情報を読み出し参照して、上記受コンピュータに対
   応した注文情報に変換し、記憶装置に記録すると共に発
   注先の上記受コンピュータに送信する第１のステップ
   と、上記受コンピュータから受信した上記注文情報に対
   応する出荷情報を、予め記憶装置に記録されている第２
   の変換テーブル情報を読み出し参照して、上記発コンピ
   ュータに対応した内容に変換して記憶装置に記録すると
   共に発注元の上記発コンピュータに送信する第２のステ
   ップと、上記発コンピュータから受信した納品検収情報
   と引当情報および棚卸情報のそれぞれに基づき、記憶装
   置に記録されている対応する品物の発注者在庫量を変更
   して記録する第３のステップと、上記発コンピュータか
   ら製品の生産計画情報を受信すると、予め記憶装置に記
   録された当該製品の構成マスタ情報を読み出し参照し
   て、上記製品を構成する各部品を抽出する第４のステッ
   プと、該抽出した各部品それぞれの上記製品の生産に必
   要な使用量を算出して記憶装置に記録する第５のステッ
   プと、上記記憶装置から上記第５のステップで算出した
   上記各部品の使用量と該各部品の上記第３のステップで
   記録した発注者在庫量とを読み出して、上記製品の生産
   量に対応する上記各部品の発注量を算出して記憶装置に
   記録する第６のステップと、予め記憶装置に記録された
   発注元および発注先のカレンダ情報と納品日割配分パタ
   ーン情報を読み出し参照して上記製品の生産計画日程に
   対応する各部品の納品期日を特定する第７のステップ
   と、該第７のステップで特定した上記各部品の納品期日
   と上記第６のステップで算出した上記各部品の発注量と
   に基づき、上記生産する製品に対応する各部品の発注情
   報を生成して記憶装置に記録する第８のステップと、上
   記記憶装置から上記第１のステップで変換した注文情報
   と該注文情報に対応する上記第２のステップで変換した
   出荷情報とを読み出し、該出荷情報と上記注文情報とに
   基づき契約残情報を生成して記憶装置に記録する第９の
   ステップと、上記記憶装置から上記第８のステップで生
   成した上記各部品の発注情報と上記第９のステップで生
   成した対応する各部品の契約残情報とを読み出し、該契
   約残情報に基づき上記各部品の発注情報を変更して記憶
   装置に記録する第１０のステップと、該第１０のステッ
   プで生成した上記各部品の発注情報を上記第１のテーブ
   ルを参照して変換し、発注先の上記受コンピュータに送
   信する第１１のステップと、上記第２のステップで変換
   した上記出荷情報に基づき、記憶装置に記録されている
   対応する品物の流通在庫量を加算して記録しておき当該
   品物に対する上記納品検収情報に基づき減算する第１２
   のステップとを有することを特徴とする電子取引方法。
10. 【請求項１０】 請求項４から請求項９のいずれかに記
    載の電子取引方法であって、上記注文支援システムは、
    上記各ステップを、複数の上記発コンピュータと複数の
    上記受コンピュータに対して行うことを特徴とする電子
    取引方法。
11. 【請求項１１】 発注側のコンピュータシステム（発コ
    ンピュータ）と、受注側のコンピュータシステム（受コ
    ンピュータ）、および、該受コンピュータと上記発コン
    ピュータにネットワークで接続された注文支援コンピュ
    ータシステムとからなり、該注文支援コンピュータシス
    テムにより、上記発コンピュータと上記受コンピュータ
    間での各種情報の送受信を行い両システム間での受発注
    処理を行う電子取引方法の処理手順を既述したプログラ
    ムをコンピュータに読み取り可能に記録する記録媒体で
    あって、請求項４から請求項１０のいずれかに記載の電
    子取引方法における各ステップを、上記コンピュータに
    実行させるための処理プログラムを記録したことを特徴
    とする記録媒体。