JPH11102399A - 部品発注システム、部品発注方法及び部品管理システム、受発注管理装置、受発注管理方法、記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】一元的な情報管理の下では、部品点数の増加に
伴いシステムが大規模化し、生産計画の変更に対する迅
速な対応が困難であった。 【解決手段】作業単位（ドメイン） ごとに、オーダー
受領、加工計画、構成展開、発注計画、オーダー発令の
処理を独立に行うことにより、部品発注、在庫管理に関
する情報処理の分散化を図り、小規模なシステムでも十
分な高速性を発揮し、リアルタイム性の高いシステムを
提供する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は部品発注システム、
部品発注方法及び部品管理システム、受発注管理装置、
受発注管理方法、記録媒体に関するものである。

【０００２】

【従来の技術】従来の部品発注システム及び在庫管理シ
ステムを図11を基に説明する。

【０００３】図11は従来の部品発注システムを示す第一
の実施形態である。操作端末133−1，133−2，133−3及
び記憶媒体（データベース）132−1，132−2，132−3，
132−4はCPU（中央演算処理装置）131に接続される。

【０００４】例えば、132−1は部品マスターデータ、13
2−2は在庫マスターデータ、132−3は単価マスターデー
タ、132−4は日程マスターデータである。使う部品の情
報は一括して各データベース132−1，2，3，4で管理し
ている。132−1，2，3，4のデータを参照更新するのは
端末133−1，2，3であり、在庫の参照を行う場合は端末
133−1，2，3のいずれかからデータベース132を参照す
る。

【０００５】扱う部品、日程等の情報が増えるとデータ
ベースの数は変えないで、データ数を増やして変化に対
応する。他方、扱う部品、日程等の情報が減少する時
は、部品マスターデータの例で説明すると、端末133−1
を置いてある部署で不要となっても、端末133−2，3で
使っているかどうかの確認に、それを削除して得られる
恩恵に比べて労苦を必要とするので不要となったデータ
の削除を行わずそのデータを残して対処し、画一的に最
終更新日等を利用してまとめて削除する。そのためデー
タ量が増大したり、必要なデータも一緒に削除してしま
うことが起こる。

【０００６】また、データベースが一元的に管理されて
いるので、どの部署のデータも容易に自分の部署のデー
タと同じように参照できる。反面、端末や参照する人単
位にデータの開示範囲を限定しようとするときには、そ
れ単位に特別な限定領域を見られるようにプログラムを
作らねばならない。

【０００７】更に、一括してデータベースを管理するこ
とは、データの量、必要なコンピュータに付随する端末
数（例えば図11の133−1，133−2，133−3）が多くなる
ため、データ保存領域（例えば図11のデータベース13
2）が大きく、処理スピードが高速な大型のコンピュー
タを使わなければ処理ができなくなる。

【０００８】処理の流れを図12で説明する。ステップ11
05−1〜1105−8は従来の部品発注の処理を示す流れ図で
ある。ステップ1105−1は生産計画を管理するデータベ
ースであり、例えば図11の端末133−1を用いて計画を入
力する。計画とは必要な部品、ユニットを何時までに、
何個作るかの指示である。

【０００９】ステップ1105−2では1105−4の構成データ
を基に構成展開を行う。ここで構成の持ち方に付いて図
13（a）,(b）を用いて説明する。実際の製品の部品、ユ
ニットの構成が図13(a)の1101の様に2階層になっている
場合、これを図13(b)の1102のように1階層組み替えても
ても手配する部品の個数は変わらない。階層ごとに部品
の員数を管理する構成展開が行われるので、図13(a)に
示される1101の構成では2階層分の構成展開が行われる
ことになる（二段階の構成展開）。これに対して図13
(b)の1102の構成を用いると1階層分の構成展開で済む
（一段階の構成展開）。

【００１０】このため従来の構成展開は展開処理を早く
する目的で図13(b)の1102の構成を用いて実施されてき
た。しかし図13(b)に示される構成展開では、図13(a)の
1101−1の部品Bと1101−2の部品Bが合算されて所要量が
算出されるため、部品Bの使用職場が異なる場合、必要
量を101−1と101−2に分割する特別の手立てが必要にな
る。

【００１１】図12に戻って説明を続ける。1105−3は構
成展開に必要な全加工工程の加工情報を管理する。加工
する日に、加工に必要な手番等のデータが管理される。
1105−2の構成展開では製品の生産計画1105−1、全工程
加工データ1105−3、全構成1105−4の情報を基に、図13
(b)の1102−1の部品A，1102−2部品C等の必要数と必要
日を算出し、データベース1105−6に保存する。

【００１２】算出された部品の必要数（1105−6）と全
部品の在庫データ（1105−5）とを比較し、購入すべき
部品数と納入日を算出し発注計画を行う（1105−7）。
発注計画データは伝票に出力され部品発注される（1105
−8）。このように対象になる部品を一括して、一般に
は工場単位に、所要量計算、並びに在庫データ等を管理
しているためその処理は大規模になり、全体のデータ更
新につながるような計算の処理は通常、夜間、月末等に
限定して行う。日中の処理はデータ参照とか、在庫入れ
とか、部分的なデータの更新だけを行っている。

【００１３】また、そのプログラムは、処理の効率性を
追及するため処理の順番を決めて行うように設計されて
いる。このため、ある部分的なデータで発注処理に即時
反映することが要求される一部のものについては、前記
プログラム以外に部分的な変動を反映するための特別の
プログラムを作り対応しなければならない。

【００１４】更に、データ管理、計算とを1つのコンピ
ュータで行うことを前提で設計されている従来のシステ
ムでは処理量が増加してくると、図11のデータベース13
2（記憶媒体）の容量を増やしたり、コンピュータの処
理能力の大きい機械に換えて対処する方法が通常用いら
れる（コンピュータの数を増やすのではない）。

【００１５】しかし、1つのコンピュータに接続できる
記憶媒体の量にも限界があり、更には処理能力の大きな
機械に換えるのも処理に耐えられる機械は非常に高価で
あったり、更には実存しない場合もある。

【００１６】

【発明が解決しようとする課題】従って、従来技術にお
ける部品発注システム及び部品管理システムは、以下の
ような課題が挙げられる。

【００１７】1．部品点数が増加するとコンピュータ処
理に長時間を要する。

【００１８】2．高速な処理を実行するために大型コン
ピュータで処理をすると、ランニングコストが高価とな
る。

【００１９】3．生産数の増減があった場合、一元的な
情報管理下では迅速な部品発注の対応が困難となる。

【００２０】4．一元的な情報管理の下では、CPU（中央
処理装置）等のシステムの一部がダウンすると部品発注
及び部品管理システム全体が停止する。

【００２１】5．部品発注及び部品管理システムの運用
が進むと、多数のセクションでデータを共用するため、
すべてのセクションの同意を取らないとデータの削除が
できない。

【００２２】6．生産計画変更から部品発注までの処理
において、すべての処理を一括して行わないとデータの
整合性が確保できず、又その処理に多大の時間を要する
ためその処理タイミングは限定され、実際の工場におけ
る在庫とシステム上の数値が一致しない。情報と物のデ
ータの整合がとれた（情物一致）管理が困難であった。

【００２３】7．オーダー指示が急激に増加し、コンピ
ュータの処理能力を超えた場合にシステムダウンが生じ
やすくなる。

【００２４】8．発注先が発注元（工場等）からの発注
部品又は部品の加工に関する情報を得るため発注元であ
る工場にわざわざ行かなくてはならない場合も生じる。

【００２５】9．発注先は発注に関する事前情報の入手
が困難なので、部品の購入、加工計画の立案が困難で、
多大のリスクを負う。

【００２６】

【課題を解決するための手段】本発明は、その内容を複
数の請求項として提示するが、それぞれの請求項は上記
課題の少なくとも１つを解決すべくなされたものであ
る。上記課題解決のために、本発明は次のような構成か
らなる。

【００２７】すなわち、木構造の関係をもって接続され
た第一のドメインと第二のドメインと第三のドメインを
備えた部品発注システムは、前記第二のドメインが、前
記第一のドメインから受けたオーダーを構成部品ごとに
展開する展開手段と、前記展開手段により展開された構
成部品ごとのオーダーを前記第三のドメインに伝達する
伝達手段とを備える。

【００２８】また、第一のネットワーク上のドメイン
と、第二のネットワーク上のドメインが公衆回線を介し
て接続される部品発注システムは、前記第二のネットワ
ーク上のドメインが前記第一のネットワーク上のドメイ
ンからオーダーを受領する手段と、前記オーダーに基づ
き加工計画を行う手段と、前記加工計画に従い構成部品
ごとに展開する手段と、前記分割された構成部品ごとの
発注計画を行う手段と、前記発注計画に従い部品単位の
オーダーを行う手段とを備える。また、特定部品の在庫
数を記憶するデータベースと、木構造の関係をもって接
続された第一のドメインと第二のドメインと第三のドメ
インとを備えた部品発注システムは、前記第二のドメイ
ンは、前記第一のドメインから受けたオーダーに基づき
構成部品ごとに展開する手段と、前記展開手段より展開
された部品単位のオーダーを前記第三のドメインに伝達
する伝達手段と、前記データベースに記録された特定部
品の在庫数と前記展開手段により展開して得られた特定
部品の必要数とを比較し、特定部品の在庫数が特定部品
の必要数よりも所定数以上多い場合は前記第三のドメイ
ンヘのオーダーの伝達を停止する停止手段とを更に備え
る。

【００２９】また、第一のドメインが内部に特定部品の
在庫数を記憶したデータベースを備えた部品発注システ
ムは、前記第一のドメインは、第二のドメインから受け
たオーダーに基づき構成部品ごとに展開する手段と、前
記展開手段より展開された部品単位のオーダーを第三の
ドメインに伝達する伝達手段と、前記第一のドメイン内
部のデータベースに記録された特定部品の在庫数と前記
展開手段により展開して得られた特定部品の必要数とを
比較し、特定部品の在庫数が特定部品の必要数よりも所
定数以上多い場合は前記第三のドメインヘのオーダーの
伝達を停止する停止手段とを備える。

【００３０】また、木構造の関係をもって接続された第
一のドメインと第二のドメインからなる部品発注システ
ムは、前記第二のドメインは前記第一のドメインから受
けたオーダーに基づき構成部品ごとに展開する展開手段
と、前記第二のドメインに接続された操作端末から前記
展開手段より展開された、部品単位のオーダーの受発注
状況を参照するための参照許可を制御する第一の制御手
段とを備える。

【００３１】また、木構造の関係をもって接続された第
一のドメインと第二のドメインからなる部品発注システ
ムは、前記第二のドメインは前記第一のドメインから受
けたオーダーを構成部品に展開する展開手段と、前記第
二のドメインに接続された操作端末から前記展開手段よ
り展開された構成部品のオーダーの参照許可を制御する
第一の制御手段と、前記第二のドメインヘのオーダーに
関連した前記第一のドメイン内の発注情報の参照許可を
制御する第二の制御手段とを備える。

【００３２】また、部品発注システムは、サーバー、ク
ライアント、ＯＳ，ＣＰＵ、記憶装置、入力装置、出力
装置、常駐プロセスプログラムからなることを特徴とす
る。

【００３３】また、ドメインが第一のネットワークと第
二のネットワークとに接続された部品発注システムは、
情報の機密性の重軽により前記第一のネットワークと、
前記第二のネットワークの情報とを分離して通信する手
段を備える。

【００３４】また、木構造の関係をもって接続された第
一のドメインと第二のドメインと第三のドメインがオー
ダーを授受する方法は、前記第二のドメインが、前記第
一のドメインから受けたオーダーを構成部品ごとに展開
する展開工程と、前記展開工程により展開された構成部
品ごとのオーダーを前記第三のドメインに伝達する伝達
工程とを備える。

【００３５】また、木構造の関係をもって接続された第
一のドメインと第二のドメインと第三のドメインが特定
部品の在庫数を記憶するデー夕ベースを介してオーダー
を授受する方法は、前記第二のドメインは、前記第一の
ドメインから受けたオーダーに基づき構成部品ごとに展
開する工程と、前記展開工程より展開された部品単位の
オーダーを前記第三のドメインに伝達する伝達工程と、
前記データベースに記録された特定部品の在庫数と前記
展開工程により展開して得られた特定部品の必要数とを
比較し、特定部品の在庫数が特定部品の必要数よりも所
定数以上多い場合は前記第三のドメインヘのオーダーの
伝達を停止する停止工程とを備える。

【００３６】また、特定部品の在庫数を記憶したデータ
ベースを内部に備えた第一のドメインが、第二のドメイ
ンからオーダーを受領し、第三のドメインにオーダーを
伝達する方法は、前記第一のドメインは、前記第二のド
メインから受けたオーダーに基づき構成部品ごとに展開
する工程と、前記展開工程より展開された部品単位のオ
ーダーを前記第三のドメインに伝達する伝達工程と、前
記第一のドメイン内部のデータベースに記録された特定
部品の在庫数と前記展開工程により展開して得られた特
定部品の必要数とを比較し、前記特定部品の在庫数が特
定部品の必要数よりも所定数以上多い場合は前記第三の
ドメインヘのオーダーの伝達を停止する停止工程とを備
えることを。

【００３７】また、特定部品の在庫数を記録するデータ
ベースと、木構造の関係をもって接続された第一のドメ
インと第二のドメインと第三のドメインを備えた部品管
理システムは、前記第二のドメインは、前記第一のドメ
インから受けたオーダーに基づき構成部品ごとに展開す
る展開手段と、前記展開手段により展開された部品単位
のオーダーを前記第三のドメインに伝達する伝達手段と
を備え、前記オーダーに従い納品された部品情報を前記
データベースに入力する入力手段とを有する。

【００３８】また、部品管理システムは、サーバー、ク
ライアント、ＯＳ，ＣＰＵ、記憶装置、入力装置、出力
装置、常駐プロセスプログラムからなる。

【００３９】また、ドメインが第一のネットワークと第
二のネットワークとに接続された部品管理システムは、
情報の機密性の重軽により前記第一のネットワークと前
記第二のネットワークの情報を分離して通信する手段を
備える。

【００４０】また、コンピュータ読み取り可能な記録媒
体はオーダーを発令する工程と、前記オーダーを受領す
る工程と、前記受領したオーダーに基づき加工計画を行
う工程と、前記加工計画に従い構成部品ごとに展開する
工程と、前記構成部品ごとに展開された部品の発注計画
を行う工程と、前記発注計画に基づき部品単位に展開さ
れた部品のオーダーを行う工程と、前記部品のオーダー
に従いデータベースからデータを読取る工程と、前記読
み取ったデータをデータベースに書込む工程とをコンピ
ュータに実行させるためのプログラムを記録する。

【００４１】また、第一のドメインから受けた自ドメイ
ンの受注と、前記自ドメインが第二のドメインに出す発
注とを管理する受発注管理装置は、データを表示するた
めの表示手段と、前記受注若しくは発注を識別させるた
めのアイコンと、前記アイコンが表す受注若しくは発注
の結果を示すデータとを、組合わせて前記表示手段に表
示させるための表示制御手段とを備える。

【００４２】また、第一のドメインから受けた自ドメイ
ンの受注と、前記自ドメインが第二のドメインに出す発
注とを管理する受発注管理方法は、データを表示するた
めの表示工程と、前記受注若しくは発注を識別させるた
めのアイコンと、前記アイコンが表す受注若しくは発注
の結果を示すデータとを組合わせて前記表示工程に出力
する表示制御工程とを備える。

【００４３】また、コンピュータ読取り可能な記録媒体
データを表示するための表示工程と、前記受注若しくは
発注を識別させるためのアイコンと、前記アイコンが表
す受注若しくは発注の結果を示すデータとを、組合わせ
て前記表示工程に出力する表示制御工程とをコンピュー
タに実行させるためのプログラムを記録する。

【００４４】

【発明の実施の形態】本発明のハードウエア構成はクラ
イアント・サーバシステムを基本とする（図14）。コン
ピュータの構成はオペレーティングシステム（OS）、CP
U、メモリーからなる標準的な構成であり、入力装置及
び出力装置と記憶装置が加わる。

【００４５】図15は本システムにおけるネットワークの
構成を示す。コンピュータ1501及びコンピュータ1502は
それぞれLAN1503及びLAN1504のように複数のネットワー
クに接続される。LAN1503は社内の通信に限定したネッ
トワークであり、LAN1504は社内及び社外まで拡張した
ネットワーク網である。機密性の高い情報と低い情報と
を選択的なネットワークの使い分けにより、秘密を保持
する。

【００４６】例えば発注計画や購買単価などの生産情報
は機密が高く、経営戦略上極めて重要なデータであるの
で社内のみの閉じたネットワーク1503を使用し、他方、
社外までデータ開示を許可できる情報の場合はネットワ
ーク1504を使用する。このような通信網の複線化は秘密
保持の他、システムがダウンした場合の冗長性に関して
も効果がある。

【００４７】図16はクライアントとドメインとサーバと
の関係を示す。「ドメイン」とは、生産ラインにおける
作業単位であり、コンピュータシステム上においてはサ
ーバーの処理単位である。

【００４８】例えば、ある製品が機械部品の加工（1601
a）、電気部品の実装（1601b）、組み立て（1601c）、
検査（1601d）という4つの工程を経て完成するとする。
サーバ上に構成された各工程に対応したドメインは独立
に工程管理の処理をする。サーバ1605に構成されるドメ
イン1620の処理（例えば加工の計画、社外への発注等）
により、「7月15日納期でa部品300個」の製作指示が、
クライアント1610aを介して機械部品の加工を担当する
工程1601aに出される。工程1601aの進捗（オーダーに対
する進行状況）はクライアント1610aを介してドメイン1
620のデータベース1660と、サーバのデータベース1650
に入力される。同様に、電気部品の実装工程1601bはク
ライアント1610bを介してドメイン1630が対応して、実
装工程の工程管理が行なわれる。組立て工程1601c（対
応するドメインは1640）、検査工程1601d（対応するド
メインは1650）に関しても同様である。

【００４９】ドメインはラインの工程単位と対応したも
ので、人間の作業区分をコンピュータの処理区分とした
ものである。人間の作業単位の概念をシステムに反映す
ることで製品の機種切り替え、部品変更、工程変更、工
程追加などの変更に対して、柔軟かつ迅速な対応が可能
となる。拡張性については以下において説明する。

【００５０】図16においてデータベース1650はドメイン
間で共有する情報を管理し、ドメインの内部データベー
ス1660、1670、1680、1690は個々のドメインの処理に必
要となる独立のデータを管理する。図示の便宜上ドメイ
ンに内部データベースが包含されているが、ドメインの
機能に関してデータベースの包含は不可欠な構成要件で
はない。

【００５１】次にドメイン間のデータ転送の考え方を図
17により説明する。

【００５２】サーバ1701とサーバ1702とは通信網1790に
より接続されている。サーバ1701にはドメイン1710と17
20が登録されている。サーバ1702にはドメイン1730と17
40とが登録されている。各サーバにはデータベース（17
03、1704）と処理待ち行列（1750、1760）、ドメインの
構成管理テーブル（1770、1780）がある。構成管理テー
ブルはサーバに登録されているドメイン情報を表示する
もので、各サーバに対して共通の内容である。このテー
ブルにはドメインのIPアドレス、パスワード、ユーザID
が定義されている。新規の製品で工程が追加となった場
合は、構成管理テーブル上（1770、1780）に新たにドメ
インを追加して定義をすればよい。

【００５３】＜サーバが異なる場合のドメイン間データ
転送＞サーバ1701上のドメイン1710が発注のオーダーを
サーバ1702上のドメイン1740に出した場合を考える。こ
のオーダーは待ち行列1750の処理1として一旦スプール
され、サーバデータベース1703に登録される（データパ
ス1791）。接続先の指定は常駐プロセスプログラムが検
索を行うキー情報となり、データ転送のポインタとな
る。接続先を複数登録した場合であっても同様で、複数
ドメインの接続が可能となる（1対多接続）。また常駐
プロセスプログラムは定義付けされた優先順位に従い、
転送先を1個所に絞り込む1対1の接続も可能とする。

【００５４】ドメイン1710が転送データと転送先をデー
タベースに登録することで、サーバ1701の常駐プロセス
プログラム（以下常駐プロセスA）が起動し、データの
転送処理が始まる（待ち行列1750の処理1）。

【００５５】 常駐プロセスAは、データベース1703
から転送先のドメインナンバーを検索し、該当するドメ
インのIPアドレス、パスワード、ユーザIDをドメイン構
成管理テーブル1770から検索する。

【００５６】 検索の結果、転送先が同一サーバ内で
なく、異なるサーバ上にあるドメインの場合は、常駐プ
ロセスAは転送データを一旦サーバ1702のデータベース1
704に書込み、待ち行列1760に処理11として登録する
（データパス1792）。

【００５７】 待ち行列1760の処理11の登録によりサ
ーバ1702の常駐プロセスプログラム（以下常駐プロセス
B）が起動してデータの再転送が始まる。

【００５８】 常駐プロセスBはデータベース1704か
ら転送先のドメインナンバーを検索し、構成管理テーブ
ル1780からそのIPアドレス、パスワード、ユーザIDを検
索する。

【００５９】 常駐プロセスBはドメインナンバーとI
Pアドレス、パスワード、ユーザIDをキー情報としてド
メイン1740を照合して内部データベース1741に転送デー
タを書込む（データパス1793）。

【００６０】＜同一サーバ内のドメイン間データ転送＞ 同一サーバの場合でもプロセスは同様である。ドメ
イン1710により発注のオーダーがドメイン1720に出され
た場合、オーダーは待ち行列1750の処理3として一旦ス
プールされ、転送データと転送先がデータベース1703に
登録される（データパス1794）。

【００６１】 転送データと転送先の登録により常駐
プロセスAが起動してデータの転送処理が始まる（待ち
行列1750の処理4）。

【００６２】 常駐プロセスAは、データベース1703
から転送先のドメインナンバーを検索し、該当するドメ
インのIPアドレス、パスワード、ユーザIDをドメイン構
成管理テーブル1770から検索する。

【００６３】 常駐プロセスAはドメインテンパーとI
Pアドレス、パスワード、ユーザIDをキー情報としてド
メイン1720を照合し、内部データベース1721に転送デー
タを書込む（データパス1795）。

【００６４】＜部品発注システム及び部品管理システム
の説明＞本発明にかかる部品発注システム及び部品管理
システムを、図1から図10を基に説明する。なお、図に
おいて同一機能を有するものは同一符号を付し説明を省
略する。図1において、101，102，103，104，105，106
はドメインと呼ぶ処理単位であり、コンピュータ上に仮
想的に割り振られたデータ処理領域を示す。この単位は
メイン組立、サブ組立等工場での職場の作業単位に対応
する。各ドメインは商品を完成させるまでの工程順と同
一な木構造で接続されており、一つのドメインはオーダ
ーを受領し、内部の処理をしてオーダーを発する同一の
機能を有している。

【００６５】各ドメインにはそのドメインのデータを参
照又は、更新するための複数の操作端末が接続され得る
が、理解を深める関係上、一つのドメインに一つの端末
の場合で説明する。各ドメインでの内部の処理は、「オ
ーダー受領、加工の計画、構成展開、発注計画、オーダ
ー発令」から構成されていて、構成展開及びオーダー発
令の機能を遂行するために、オーダーの構成を管理して
いるドメイン（110，111，112）から構成データ情報を
参照する。 このように最上流のドメインから出された
オーダーは下流のドメインに対して送られ、オーダーを
受けたドメインはそのオーダーを基に、子部品、サブア
ッセンブリ部品等に構成展開する。更に各ドメインのデ
ータベースに記憶された在庫数等のデータを基に、個々
の子部品、サブアッセンブリ部品等の注文数、納期を確
定し、それぞれの部品に関するデータを処理するドメイ
ンにオーダーを伝達する。

【００６６】そのように各ドメインにおいて、オーダー
受領、加工の計画、構成展開、発注計画、オーダー発令
の機能を完遂して最下流のドメイン106にデータが送ら
れる。この最下流のドメイン106は、工場からの個々の
子部品、サブアッセンブリ部品等の発注先に対応したド
メインであり、発注先が端末を用いてその内容を確認す
ることができるものである。

【００６７】本発明に係るドメイン101，102，103，10
4，105，106は、その機能を達成するためにプログラム
は共通としている。これにより「システム開発日程、シ
ステム費用、拡大の容易性、維持管理コスト」等で有利
な効果がある。

【００６８】さらに、部品発注及ぴ在庫管理情報をドメ
イン単位の分散処理で実行することにより、小規模なシ
ステムでも高速な処理が可能となり、部品点数の増加に
伴うコンピュータ処理の長時間化を抑制するシステム構
成が可能となる。

【００６９】また、リアルタイム性の高い処理により迅
速な部品発注等の対応、情報と物のデータの整合がとれ
た（惰物一致）管理が可能となる。

【００７０】ここで、最上流のドメイン101において
は、プログラムは共通なものがあるが、「オーダー発
令」の機能を処理する部分のプログラムを使用し、又、
最下流のドメイン106においては、「オーダー受領」の
機能を処理する部分のプログラムを使用している。

【００７１】次に、図2を基に、更に詳細に本発明に係
わるシステムを説明する。

【００７２】符号200−1，201−1，211−1，211−2，21
1−3，221−1，221−2，221−3，221−4，231−1，231
−2，231−3，231−4は製品Aの部品発注に係るドメイン
であり、符号250−1，251−1，261−1，261−2．261−
3，221−4，271−1，271−2，271−3，231−4，281−
1，281−2，281−3は製品Bの部品発注に係るドメインで
ある。

【００７３】構成管理DB200は各ドメインに接続され、
各ドメインの内部処理に必要な構成データを管理するデ
ータベースである。操作端末200−2は、ドメイン200−1
に接続され、発注すべきオーダーを入力する。操作端末
221−5はドメイン221−2に接続された端末であり、ドメ
イン221−1のデータの操作、例えば「加工計画を入れ
る、在庫数の誤差を直す、納品された品物の数量の入力
等」を行う。

【００７４】ドメイン241−1，241−2，241−3，241−4
は発注先の端末で、オーダーを参照することが可能であ
り、納品書の出力等が可能である。

【００７５】個々のドメインはLAN等の通信回線により
接続されるので、地理的に遠隔の地域にドメインが分散
しても相互にデータの授受が可能であり、同一地域のコ
ンピュータシステム上に構築されるプログラムシステム
に限定されるものではない。

【００７６】例えば、図２の場合、オーダー発令が出さ
れるドメイン200−1は本国の本社に存在し、下流の第1
ドメイン211−1、211−2、211−3は本国の子会社、さら
に第2ドメイン221−1、221−2、221−3、221−4は第2国
に存在するユニット製品メーカ、第3ドメイン231−1、2
31−2、231−3、231−4は第3国の部品製作メーカに存在
する場合でも注文の受発注と納品に関する情報授受は可
能であり、本発明にかかる部品発注システム、部品管理
システムは機能する。

【００７７】「オーダー発令」は本部品発注システムに
おいて、最上流に位置するドメインに接続する端末（20
0−1，250−1）から、生産すべき製品名又はユニット名
と台数、それが必要な納期が入力される。

【００７８】この入力により最上流のドメイン（200−
1）の内部において、「オーダー発令」処理がスタート
し、その結果、一つ下のドメイン（201−1）にオーダー
が送られる。本システムを構成するドメインで使用する
プログラム機能、即ち「オーダー受領」、「加工計画」、
「構成展開」、「発注計画」、「オーダー発令」に関する
部分は共通であり、それにより「システム開発日程、シ
ステム費用、拡大の容易性、維持管理コスト」等で有利
な効果があるが、最上流のドメインにおいては使用する
プログラムの機能はオーダー発令である。

【００７９】図3は、部品発注システムのうちLAN1上の
ドメインが公衆回線4000と接続して、さらに遠隔にある
LAN2上に構成されたドメインにオーダーを与える場合を
示す。LAN1、公衆回線4000、LAN2に接続したドメイン群
が全体として一つの部品発注システムとして機能する。

【００８０】LAN1上の第1ドメイン（1010）でオーダー
発令され、第2ドメイン（1020）から第6ドメイン（106
0）で処理が実行される。第4ドメイン（1040）は公衆回
線4000に接続されており、第4ドメインの発注計画に基
づくオーダーは第6ドメイン（1060）の他、公衆回線（4
000）を経由してLAN2上の第7ドメイン（2070）に到達す
る。

【００８１】さらに、LAN2の第7ドメイン（2070）とLAN
3の第8ドメイン（3080）がLAN4（4100）を介して接続さ
れており、LAN1上のドメインが公衆回線と接続して、き
らに遠隔にあるLAN2上に構成されたドメインを経由して
LAN3上のドメインにオーダーを与えることも可能であ
る。LAN1（1000）、公衆回線（4000）、LAN2（2000）、
LAN4（4100）と、LAN3（3000）により接続したドメイン
群が全体として一つの部品発注システムとして機能す
る。

【００８２】LAN1上の第1ドメイン（1010）のオーダー
は、第4ドメイン（1040）と公衆回線4000の接続を介し
てLAN2上の第7ドメイン（2070）に到達し、さらにLAN4
を経由してLAN3上の第8ドメイン（3080）に到達する。
第7ドメイン（2070）及び第8ドメイン（3080）ではそれ
ぞれ受領したオーダーに対する処理が実行される。オー
ダー受領による端末表示に関しては後に説明する。

【００８３】このように公衆回線およびLAN等の回線を
仲介した通信は、国内間若しくは内外国間での部品発注
システムの拡張を可能にする。例えば、LAN1を国内発注
元、LAN2，LAN3を海外調達の発注先と考えた場合におい
ても、本発明にかかる部品発注システム、部品管理シス
テムの適用は可能である。

【００８４】次に図4を基にドメイン内のデータの伝達
について説明する。ドメイン4101から出されたオーダー
はドメイン4102の4105−1で受領される。ここではすべ
ての受領されたオーダーがデータベース4106−1に保存
されており、受領されたオーダーが「新規であるの
か」、「以前に来たオーダーの変更であるか」、「同じ
オーダーを再送して来たのか」を比較して判断する。こ
れによりオーダー欠落時の回復処理を確実かつ容易に行
うことができる。

【００８５】新規や変更の場合は加工計画（4105−2）
の処理につながる。加工計画とはドメイン4102の加工現
場のスケジュール管理を行うものである。例えば、どの
ような日程で部品加工するか、毎日50個組み立てると
か、毎週の月曜日のみ10個組み立てるとか等の計画を操
作端末4107を使って入力しておき、データベース4106−
2に保管しておく。

【００８６】例えばドメイン4102が新規のオーダーであ
る「伝送部を5月20日納期で10個」の注文を受け取る
と、受け注文DB（データベース）4106−1で以前の注文
との比較を実施する。この場合新規であるので加工計画
4105−2に送られる。加工計画4105−2ではデータベース
4106−2から予定されている計画を呼び出し、この10個
の注文の引き当て日を見つける。加工計画が5月15日に5
0個、5月25日に50個設定されていたとすると、この10個
の注文は最先の加工日である5月15日の生産分に引き当
てられ生産されることになる。このような生産計画の平
準化により、生産ライン稼働率は高くなる。次の構成展
開4105−4へは「5月15日の生産分の10個」としてデータ
が渡される。4105−3の構成展開は構成データが4106−3
のデータベースに在るかどうかを判断し、存在しない場
合、構成管理データベース(DB)4104から4104−1で示す
構成データを構成DB4106−3にコピーし、それに基づき
伝送部を作るのに必要な部品、サブユニットとその員数
を算出する。この電送部の例では、操作部が10個、ネジ
が50個、プリント板10枚、そ一夕10個、5月15日必要で
あると算出される。そのデータは発注計画4105−4に送
られる。

【００８７】発注計画4105−5では、4106−4のデータベ
ースから、既に存在する「操作部、ネジ、プリント板、
モータ」の在庫と、先程送られてきた必要数の比較を行
う。例えば在庫として「操作部：0個、ネジ：25個、プリ
ント板：8枚・モータ：9個」とする。続いて、部品在庫
DB4106−4に登録してある、最小発注数から注文すべき
数を確定する。最小発注数とは梱包数等の制約のため購
入している最小個数を予め発注側と納入側で決めておく
員数であり、例えば「操作部：5個、ネジ：100個、プリ
ント板：10枚、モータ：1個」とすると、今回発生する
注文は「操作部：10個、ネジ：100個、プリント板10
枚、モータ：9個」となる。これが次のオーダー4105−5
に送られる。

【００８８】オーダー4105−5は発注履歴を注文DB4106
−5に保存した後、下流の加工区に対して「操作部10個
はドメイン4103−1、ネジ100個はドメイン4103−2、プ
リント板10枚はドメイン4103−3、モータ9個はドメイン
4103−4」にオーダーを発令する。

【００８９】このオーダーはドメイン4103−1、4103−
2、4103−3、4103−4で受領される。これらのドメイン
（4103−1、4103−2、4103−3、4103−4）でもドメイン
4102で行った処理と同様に以前に受領した全てのオーダ
ーと比較し、新規のものである等の比較を行い、新規手
配分と以前に来たものの変更分の抽出を行う。このドメ
インが最下流（最下流とは、4104のドメインに受けたオ
ーダーの構成を取得しに行ったとき構成が存在しないこ
とで分かる）であると、新規分の伝票と変更分の伝票と
を操作端末4108−1、4108−2、4108−3、4108−4に繋が
るプリンタから伝票を出力する。

【００９０】例えば、A電気工業の端末4108−8からは、
先程ドメイン4102で算出され、ドメイン4103−4に送ら
れたオーダーのうち「5月15日の納期の9個のモータ発
注」の伝票が4108−4の端末のプリンタから印刷でき
る。本発明に係る部品発注システムにおいて、操作端末
4108−4は発注先がA電気工業、操作端末4108−3は発注
先がB電子工業、操作端末4108−2は発注先がCネジ製作
所、操作端末4108−1は発注先がD電子工業になってい
る。

【００９１】このシステムにおいて、上流加工区（工
場）ドメインからのオーダーは、直近の上位あるいは下
位のドメイン間で相互に受発注するデータのみを参照す
ることができる（上位のドメインの参照は後に図5に基
づき後に説明する。）。従って、相互に受発注に関する
データの授受を行っていないドメイン間ではデータの参
照をすることはできない。例えばドメイン4103−4は、
工場からのモ一夕の発注先がA電気工業であり、A電気工
業はドメイン4103−4のオーダー発令をA電気工業に備え
られた端末4108−4から確認することができるが、他の
発注先であるB電子工業、Cネジ製作所、D電子工業はこ
の4103−4ドメインの内容を確認することはできない。

【００９２】また、上流加工区（工場）であるドメイン
4101からドメイン4102より下流の加工区ドメインの発注
情報は参照することができない（ドメイン4102の情報は
参照することができる）。

【００９３】ドメイン4103−4と端末4108−4を関係づけ
る方法は公知のセキュリティシステムをそのまま応用す
れば可能であり、例えばドメインに発注先の端末の番号
及びパスワードを記憶しておき、端末からアクセスの要
求が合った場合には、ドメインがアクセス許可を求めて
いる端末の番号及び入力されたパスワードが一致した場
合にのみ、ドメインのオーダー発令の内容を確認するこ
とができる。

【００９４】更に本発明に係る発注システムにおいて、
発注先は最下流のドメインのみならず、1つ上流のドメ
イン(直近上位のドメイン)の内容も確認することが可能
である。これについて、図5を用いて説明する。

【００９５】発注先のドメイン502、一つ上流のドメイ
ン501、ドメイン502を参照することのできる端末505，
ドメイン501の全ての注文データを501−1，ドメイン501
の注文データの中でドメイン502分として送られたデー
タを受注データ502−1，ドメイン501の加工計画のデー
タを501−2，501の加工計画501−2のコピーを加工計画2
データ502−2，ドメイン501の子部品在庫データを501−
3，501−3の在庫データでドメイン502に注文している部
品のみの在庫データを子部品在庫2データ502−3とす
る。

【００９６】受注データ502−1(503−1)は注文が発生す
る都度送られてくるが、加工計画2データ502−2(503−
2)，子部品在庫2データ502−3(503−3)については、端
末505からの要求503−4によりドメイン501から送られ、
その後ドメイン502に保存される。端末505からドメイン
502の加工計画2データ502−2，子部品在庫2データ502−
3を参照する。これにより、ドメイン501にあるデータの
うちドメイン502の使用に該当しないデータの漏洩を防
ぐことができ、且つ、発注先（この場合はドメイン50
2）はこれから発注される可能性のあるオーダー発令を
予め確認することができる。発注先は生産計画等を作成
する上で予め将来計画を知ることができるので経営上の
リスク低減等が可能となる。

【００９７】更に、ドメイン502にデータを保存してお
くためドメイン501の処理が停止していたり、データ503
−2，503−3，503−4の通信が遮断されている場合であ
っても前回に取得したデータ502−2，502−3を基に確認
が可能である。

【００９８】本発明に係る部品発注システムにおいて
は、最上流に位置するドメインが複数あり、それぞれの
最上流のドメインから、それぞれ生産を担当する製品
名、ユニット名、納期が入力され、最終的に発注先のド
メインに仕向けられる。

【００９９】例えば、図2に基づいて説明すると、ドメ
イン200−1に入ったオーダーはドメイン201−1，更にド
メイン211−2，221−1と展開され、231−4ヘモータのオ
ーダーとなり到着する。

【０１００】他方ドメイン250−1に入ったオーダーはド
メイン251−1，261−3，271−1と展開され、231−4ヘモ
ータのオーダーとして到着し、A電気工業への注文とな
る。A電気工業の端末241−4端末からは、一つ上のドメ
イン221−1電送部ドメインの注文とドメイン271−1の注
文として確認することができる。更にA電気工業はドメ
イン221−1と271−1の個々のモータの在庫とモータの使
用計画を知ることができる。以上説明したように複数の
ドメインからの注文を受けることが可能である。ここで
は注文の受注を例としているが、注文の発注の場合であ
っても複数のドメインを対象にすることは可能である。
従って、複数ドメインへの発注も可能である。

【０１０１】便宜上、最上位のドメインからのオーダー
が複数の下流のドメインにおいて、構成展開等の機能に
より最下流のドメインまで処理される例を説明をした
が、この流れに沿わない場合もある。例えば、最上流の
ドメインと最下流のドメインまでの間に4つのドメイン
があったとする。図2に示すドメインの階層構造で、ネ
ジの発注のように合計5つのドメイン(200−1、201−1、21
1−2、221−1、231−2)に拾ける処理を行わなくても、途
中のドメインから最下流のドメインにオーダーの発令を
出すことができる。その場合には、オーダー発令の伝達
を次のドメインに送らずに、最下流のドメインに送るよ
うに、データの送信先の設定を行うことによって、発注
先にオーダー発令を行うことができるので、データ発令
までの時間が短縮されるという効果がある。

【０１０２】次に、発注先から納品された場合に拾ける
着荷の処理と在庫管理を、図4を基に説明する。符号410
7、4108−1、4108−2、4108−3、4108−4はドメインに接続
された端末である。これから注文書を取り出し、納入物
に貼り付けて、注文ドメイン（一つ上流のドメイン、つ
まりドメイン4102の場合はドメイン4101、ドメイン4103
−1、4103−2、4103−3、4103−4の場合はドメイン4102
が注文ドメインにあたる）の端末4107で検収される。ド
メイン4102を例にすると、検収と同時に4106−5の注文
データに検収数を書き込み、注文に対する納入が終了す
る。

【０１０３】この検収データはドメイン4103−1、4103
−2、4103−3、4103−4に戻り、納入業者（D電子工業、
A電気工業など）が、端末4108−1、4108−2、4108−3、
4108−4で直ぐに確認ができる。更に、部品在庫データ
ベース4106−4に検収数だけ加えて各部品の在庫数を増
やす。納品ルートは、注文ドメインに限定されるもので
なく、その部品を使用する加工区あるいは業者であって
もよい。

【０１０４】図2を例にすると、注文ドメインが221−1
であるとき、プリント板が操作部に使用される場合は、
プリント板の納入業者であるB電子工業は、ドメイン221
−1でなく操作部を作る下流加工区のドメイン231−1に
納品することができる。

【０１０５】ドメイン4102でドメイン4103−1からの操
作部、ドメイン4103−2からのネジ、ドメイン4103−3か
らのプリント板、ドメイン4103−4からのモータを使っ
て組み立てが完了すると、端末4107からドメイン4102が
作っているユニット（電送部）の伝票を取り出し、ドメ
イン4101に出荷する。ドメイン4101で検収が行われる
と、同じようにドメイン4102に検収データが戻る、これ
に基づき、4104−1の構成を使って、納入ユニット（電
送部）の子部品の在庫を部品在庫データベース4106−4
から引き落とす。これにより部品在庫データベース4106
−4に記録される部品在庫数は部品の納入により増え、
ユニットの出荷により減ることになる。この様な構成に
することにより、現在の部品等の在庫数が効率的に把握
することができるという効果がある。

【０１０６】なお、本発明に係る説明において、ドメイ
ンとは「オーダー受領」「加工計画」「構成展開」「発
注計画」「オーダー」の機能に付随してデータベース、
即ち「受け注文データベース(DB)」「加工計画DB」「構
成DB」「部品在庫DB」「注文DB」も含めて説明を行った
が、ドメインの機能構成上、各データベースをドメイン
に内包した構成に限定される物でなく、各機能に付随す
るデータベースを除いたものもここで言うドメインを示
すものである。

【０１０７】図6に基づきドメインとそのデータを参照
する端末への権限の考え方について説明する。601は中
央演算装置、603は端末、602−1，602−2，602−3，602
−4はデータベースに割り振られた各ドメインのデータ
領域である。この各領域のデータを端末から参照するた
めには、各ドメインに該当するデータベースに保存して
あるドメインNo．とパスワードを入力しないと参照がで
きない。つまり、各端末からはドメイン単位に認証を取
らないとドメインのデータを参照することはできない。
これによりドメイン管理該当者以外の第三者からのデー
タ参照を防いでいる。

【０１０８】図7を用いてコンピュータにおける操作端
末、CPU、データベースの配置について説明する。符号3
03は操作端末、301はCPU，302は記憶装置（データべ一
ス）である。記憶装置302は、図2で説明したようにドメ
インに対して分けられており、記憶装置302−1は図2の
ドメイン200−1のデータ、記憶装置302−2はドメイン20
1−1のデータ、記憶装置302−3はドメイン221−1のデー
タ、記憶装置302−4はドメイン231−1のデータ用等に割
り振られている。データは各ドメイン単位の管理の下に
あり、データの削除・追加はドメイン管理者（加工区の
責任者）の権限で自由にできる。これにより、ドメイン
管理者の意向に反し、不必要なデータを置いておくこと
も必要なく、更に必要なデータは自分一人の権限で追加
できる。

【０１０９】規模が拡大した場合の対処方法は、一般的
に生産現場は生産数が拡大しても、最小の加工区の大き
さは変わらない。つまり生産数が2倍になると加工区の
要員を2倍にするが、その時には同時に加工区数も2倍程
度にして最小単位の加工区の管理要員数が極端に増大す
ることは組織管理上行わない。このシステムでは素直に
組織形態に合わせて追加された組織用に追加のドメイン
を設定すればよく、各職場の扱う部品点数が極端に増大
することは組織管理上希である。

【０１１０】もしそのようなことが生じた場合は、ドメ
インを割り当てた最小職場の定義が正しくないので、更
に小さな職場単位に再定義を行う。これにより各ドメイ
ン内のデータ数は限定された量に保たれるので処理スピ
ードがデータ量の増大で低下することが無い。

【０１１１】次に図8及び図9を用いて、ドメイン単位の
処理を行うことでデータの処理量が減ることを説明す
る。

【０１１２】製品A1（701）はユニットE、部品A、部品
B、部品C、ユニットDからなる。ユニットEは部品F、部
品G、部品Cからなる（702）。ユニットDは部品F、部品
H、部品Cから構成される（703）。

【０１１３】次に、図9を用いて製品A1の注文が10個さ
れた場合を説明する。必要な子部品数、子部品の在庫
数、手配すべき子部品数を算出すると、ユニットEのよ
うに製品A1の注文があっても、ユニットEの在庫数が必
要な子部品数を充足するためにユニットEの発注は発生
しない。従ってドメイン702に係る展開処理が不要とな
る。このように各ドメイン単位の子部品在庫に基づく発
注計画は、一つのオーダーにより必要となる総部品点数
に基づく処理を防ぎ、コンピュータ処理の負荷を軽減す
る。

【０１１４】次に、図10を用いてドメイン数が増大した
ときの対処法について述べる。CPU401，データベース40
2、操作端末403で構成されるシステムがドメインの増大
により負荷オーバーとなったときは、同様の構成のシス
テム（CPU411，データベース412，端末413）を405に示
すネットワークを使って追加すれば良い。また、処理能
力の小さいシステム（CPU421，データベース422，端末4
23）を追加して処理を行うことも可能である。処理能力
の高いマシンに、より多くのドメインの処理を設定した
り、処理能力の低いマシンでは少ないドメインを割り振
り運用することも可能である。

【０１１５】CPU間の接続405，415はオーダーの交換と
相手加工区のデータ参照等であるため通常社内に敷設さ
れているLANで可能であり、特別のデータラインは不要
である。これによりCPU401，411，421や、データベース
402，412，422は同一場所で管理する必要がなく、端末4
03，413，423で示す操作端末を設置する場所の近くにそ
れに付随するCPUとデータベースを配置すれば良い。

【０１１６】＜システムの冗長性の説明＞システムの一
部に障害が発生したときの、システム冗長度について述
べる。図7に示したファイルの持ち方、図8に示した機器
構成を基に説明する。一例として、図10のコンピュータ
システム(CPU411，データベース412，端末413からなる
中間のシステム)がダウンしたことを想定する。データ
を記録しておくドメインについてはデータ参照等全ての
業務が停止するが、上位のコンピュータシステム(CPU40
1，データベース402，端末403)、下位のコンピュータシ
ステム(CPU421，データベース422，端末423)に該当する
ドメインのデータでは、図5の様にデータを相互に保持
するため、何ら仕事上差し支えない。

【０１１７】影響があるのは、システムがダウンした中
間に接続されたコンピュータシステム（CPU411，データ
ベース412，端末413に該当するドメインであり、在庫参
照、納品の着荷業務等ができなくなる。しかし、着荷の
業務等について、図4に示す4108−1等の端末は独立に処
理をすすめることが可能であり、対象ドメイン（端末41
08−1の場合、ドメイン4102）が機能停止しても4108−1
端末自体にもっているデータで検収や参照が可能な構成
を備えている。操作端末4108−1等は検収データをドメ
イン4102の機能が回復した後に送ることが可能である。

【０１１８】また、機能を停止した該当ドメイン以下で
は、オーダーが新規に来なくなる。オーダー自体は最短
で毎日程度、通常は1回／週程度の発生であるから、2〜
3日程度のオーダー受領無しは問題にならない。次に、
図10の405，415にあたるコンピュータ間の通信回線が遮
断された場合であるが、これによる影響はオーダーの転
送ができなくなるだけであり、同様に2〜3日程度の障害
は特に生産に支障にならない。一元的な情報管理の下で
は、CPU（中央処理装置）等のシステムの一部がダウン
すると、部品発注及び部品管理システム全体が停止する
が，分散した情報管理下ではこのようなリスクを最小限
にすることができる。

【０１１９】＜操作端末の説明＞クライアント、サーバ
をそれぞれ構成するコンピュータ1801はオペレーティン
グシステム（OS）1802，CPU1803，ROM1304a，RAM1304
b、2次記憶装置1304c、ネットワークインタフェース130
5からなる構成であり、表示装置1806、表示制御部180
9、入力装置1807、及び外部記憶装置1808、出力装置181
1が接続される。

【０１２０】入力装置1807とは、画面上で座標を指示
し、対象を選択する等の操作を行うための入力装置の総
称である。具体的にはマウスの他、トラックボール、タ
ッチペン、ジョイスティック、タブレット、キーボード
等がある。画面上のカーソル（矢印や十字印が用いられ
る）により位置や対象が指定される。

【０１２１】表示装置1806とは、コンピュータ間で授受
したデータ（文字、図形、数値等）を画面に表示するた
めの装置である。表示装置の種類として、ＣＲＴディス
プレイ、液晶ディスプレイ、プラズマディスプレイ等が
ある。これらにより操作端末が構成される。

【０１２２】発注すべきオーダーの入力、加工計画、在
庫数等の部品受発注に関するデータの入力は入力装置18
07を介して行われ、コンピュータ1801のCPU1803が処理
をする。他のドメインへのオーダー発令はバス1810、ネ
ットワークインタフェース1805により下流のドメインに
発令される。ネットワークインタフェース1805は外部と
の通信に２つの通信回線(1805a，1805b)とを選択的に使
い分ける。図15の説明のように、ネットワークインタフ
ェース1805は授受するデータの機密性に応じて、接続し
ているLAN(1503、1504)を切替える。

【０１２３】また、ドメインは他のドメインに対して加
工計画、在庫情報等、自ドメインで必要となる固有のデ
ータを要求することができる。この要求も入力装置1807
からの要求に基づくものである。データの要求に対して
データ読取りモジュール(図20の2007)が起動し、特定の
ドメインに対してデータの転送要求を出力する。ドメイ
ン間で授受したデータは、ネットワークインタフェース
1805を介して2次記憶装置1804c、外部記憶装置1808、RA
M1804bのいずれかに記録される。自ドメインに必要十分
な情報を保持することにより、ネットワークの通信障害
が発生した場合でも、自己完結的な処理が遂行できる。
出力装置1811は受発注の処理結果を帳票として出力する
印刷処理装置であり、プリンタ等が含まれる。

【０１２４】＜コンピュータの画面表示＞図19は表示装
置1806の画面表示である。この画面表示は上位ドメイン
からの受注と下位ドメインへの発注を示すものである。

【０１２５】ドメイン内の管理項目ごとにアイコンで区
分けされ、区分に該当するデータの件数をアイコンと合
わせて表示する。アイコンとデータが組合わせで表示さ
れるので、項目ごとの処理状況が目視により直接的に把
握できる。アイコンによる表示はショップ内の作業単位
をシンボライズしたものであり、文字情報を解釈しなが
ら検索するということが不要となる。

【０１２６】アイコン1901は上位のドメインからの注文
の受注管理の表示であり、受注件数が組合わせ表示され
る。データ表示は受注件数が159件あることを示してい
る。

【０１２７】アイコン1909は下位のドメインへの注文の
発注管理の表示であり、発注件数が組合わせで表示され
る。データ表示は発注件数が35件あることを示してい
る。

【０１２８】アイコンとデータ件数の組合わせ処理はOS
1802の管理下により記憶装置（1808、1804c、1804a）に
記録された表示制御モジュール（図20の2009）により実
行される。表示制御モジュールはアイコンと該当するデ
ータ件数の組合わせ処理を表示制御部1809に出力し、表
示制御部1809は図19のような態様で表示装置1806上に表
示する（図19）。表示制御部1809は、表示するデータが
（a）受注と発注の両方、（b）受注のみ，（c）発注の
み、のいずれに該当するか否かを判断し表示画面の制御
を行う。

【０１２９】表示制御部1809は更に、入力装置1807から
の入力指示に基づき、オーダー受領、加工計画、構成展
開、発注計画、オーダーに関する詳細情報を表示装置18
06に表示する。画面表示のためのフローチャートを図2
1、22に示す。図２１はドメインの処理を示すフローチ
ャートである（例えば図４で説明したドメイン４１０
２）。（追加）詳細情報としては、部品あるいはユニッ
トとその数量の対応関係、日限管理情報などが個別に表
示される。図8、9に相当する画面表示である。表示制御
ステップ(S2202：図22)はドメインのデータベース(図４
及び図２１（追加）4106-1、2、3、4、5)、アイコンデータベ
ース（2204）、参照対象データベース（2205：他のドメ
インデータベース、サーバデータベース等）から必要な
情報を選択し表示装置(1806)に表示する（S2203、S220
4）。

【０１３０】＜アイコン表示の詳細＞図19は受注の管理
を7つの項目、発注の管理を6つの項目に分類して表示し
ている。

【０１３１】「予定」1902は上位ドメインからの受注予
定の表示であり、受注件数が組み合わせ表示される。図
19の場合では受注予定は130件であることを示す。尚、
発注管理（アイコン1909より下側）で「予定」表示がな
いのは自らの発注予定を表示する必要がないからであ
る。

【０１３２】「注文確定」（1903,1910）は仕様及び納
期、数量等の条件が全て確定した注文品が表示対象とな
り、前記の条件が満たされた注文の件数が組合わせ表示
される。注文が確定すると「予定表示」から削除される
ので、予定と注文確定の両方で表示されるという重複は
生じない。この処理はクライアント、サーバシステムに
おいて、データベースへの通常の読取りと書込み処理に
よりなされるものである。通常の注文品の進捗情報は
「注文確定」を見ればよい。図19の場合では、10件が注
文確定状態である。

【０１３３】「遅延」（1904、1911）は指定納期日に対
して未検収の注文品が表示対象となり、未検収の件数が
組合わせ表示される。ドメインのジョブの異常値を示す
ものである。異常値をシステム側から作業者に向けて能
動的に表示することは、計画遅れの状態を早期に知り、
作業の優先順位を変更し、他のショップに緊急発注をか
けるという対応を可能とする。図19の場合、受注品で4
件、発注品で10件が計画遅延の状態である。

【０１３４】「注文分割」（1905、1912）は注文確定後
に2以上の注文に分割された注文品、あるいは分割の申
請がされている注文品が表示対象となる。図19の場合は
分割されたものは0件である。

【０１３５】「注文変更」（1906、1913）は注文確定後
に仕様の変更等が生じた注文品が表示対象となる。図19
の場合は仕様変更された注文が6件あることを示してい
る。

【０１３６】「検査中」（108、115）は納品物が上位の
ドメインで検品中であることを示している。図19の場
合、検品中の注文品は0件であることを示している。

【０１３７】「検収」（1908、1915）は検収の終了した
注文品を表示する。図19の場合、9件が検収終了であ
る。以上説明したように、ショップ内における受注の予
定から検収まで一期通貫した情報が時系列に分類、表示
される。

【０１３８】本発明は、前述した実施形態の機能を実現
するソフトウェアのプログラムコードを記録した記憶媒
体を、システムあるいは装置に供給し、そのシステムあ
るいは装置のコンピュータ（またはCPUやMPU（マイクロ
プロセッシングユニット））が記憶媒体に格納されたプ
ログラムコードを読出し実行することによっても達成さ
れる。

【０１３９】この場合、記憶媒体から読出されたプログ
ラムコード自体が前述した実施形態の機能を実現するこ
とになり、そのプログラムコードを記憶した記憶媒体は
本発明を構成することになる。プログラムコードを供給
するための記憶媒体としては、例えば、フロッビディス
ク、ハードディスク、光ディスク、光磁気ディスク、CD
−ROM，CD−R、磁気テープ、不揮発性のメモリカ−ド、
ROMなどを用いることができる。本発明を上記記憶媒体
に適用する場合、記憶媒体には、図20のメモリマップに
示す各モジュールを記憶媒体に格納することになる。

【０１４０】すなわち、少なくとも「オーダー発令モジ
ュール2001」「オーダー受領モジュール2002」「加工計
画モジュール2003」「構成展開モジュール2004」「発注
計画モジュール2005」「データ読取りモジュール2007」
「データ更新モジュール2008」「表示制御モジュール20
09」「常駐プロセスモジュール2010」の各モジュールの
プログラムコードを記憶媒体に格納すればよい。

【０１４１】また、コンピュータが続出したプログラム
コードを実行することにより、前述した実施形態の機能
が実現されるだけでなく、そのプログラムコードの指示
に基づき、コンピュータ上で稼働しているOS（オペレー
ティングシステム）などが実際の処理の一部または全部
を行い、その処理によって前述した実施形態の機能が実
現される場合も含まれる。

【０１４２】さらに、記憶媒体から読出されたプログラ
ムコードが、コンピュータに挿入された機能拡張ボード
やコンピュータに接続された機能拡張ユニットに備わる
メモリに書込まれた後、そのプログラムコードの指示に
基づき、その機能拡張ボードや機能拡張ユニットに備わ
るCPUなどが実際の処理の一部または全部を行い、その
処理によって前述した実施形態の機能が実現される場合
も含まれる。

【０１４３】

【発明の効果】本発明により部品発注及び在庫管理に関
する情報処理の分散化が可能となり、各請求項に記述さ
れた発明は、それぞれ、以下に記載する効果の少なくと
も一つを得ることを可能とする。

【０１４４】1．部品点数が増加しても、コンピュータ
に負荷が集中しないので短時間の処理が可能となる。す
なわち、ドメインの内部処理（加工計画、構成展開、発
注計画等）はシステム全体のバッチ処理に比べて高速化
が図れる。

【０１４５】2．小型コンピュータによるシステム構成
でも処理可能なので、ランニングコストを安価にするこ
とができる。

【０１４６】3．生産数の増減があった場合、製品の構
成全体について処理を繰り返す必要がなくなり、ドメイ
ン単位に最小限の再処理をすれば足りるので迅速な部品
発注が可能となる。

【０１４７】4．一部のドメインがダウンしても、シス
テム全体は停止することがない。

【０１４８】5．データ削除又は追加は各ドメイン単位
で行えるので、システム管理が容易になる。

【０１４９】6．製品構成が変化した場合でも、ドメイ
ンの接続パターンを変更することで迅速かつ容易に対応
することが可能となる。

【０１５０】7．製造ラインの稼働率を高水準に維持し
た生産計画の実現が図れる。

【０１５１】8．オーダーが急激に増加することによ
り、システムがダウンする可能性が低下するという効果
がある。

【０１５２】9．発注先は、発注元がこれから発注しよ
うとする部品又は部品の加工に関する情報を迅速にかつ
容易に把握できるので、従来技術のように、発注先であ
る工場にわざわざ行かなくても済むという効果がある。

【０１５３】10．開示情報をドメイン単位に管理し、該
当加工区で必要十分な範囲に限定することにより、生産
情報に関する秘密を保持する。

【０１５４】11．発注先は、これから発生する発注部品
又は部品の加工に関する情報を迅速にかつ容易に把握で
きるので、発注先が更に新規な部品の購入、加工等の計
画を事前に立てやすくなるという効果がある。

【０１５５】12．リアルタイム性の高い情報管理を可能
とし、情物一致した部品管理を可能とする効果がある。

【０１５６】

【図面の簡単な説明】

【図１】本発明に係る部品発注システムを示す図であ
る。

【図２】本発明に係る部品発注システムをより詳細に説
明する図である。

【図３】本発明に係る部品発注システムがLAN網若しく
は公衆回線を利用して接続されることを示す図である。

【図４】ドメイン内のデータの伝達を説明する図であ
る。

【図５】本発明に係る部品発注システムにおいて、本シ
ステム外部の操作端末から内容の確認をすることができ
ることを示す図である。

【図６】ドメインとそのデータを参照する端末への権限
の与え方を説明する図である。

【図７】コンピュータにおける操作端末、CPU、データベ
ースの配置を説明する図である。

【図８】ドメイン単位の処理によりデータ量が軽減るこ
とを示す図である。

【図９】ドメイン単位の発注計画の例示である。

【図１０】ドメイン数が増大したときの対処法を説明す
る図である。

【図１１】従来技術における部品発注システムを説明す
るための図である。

【図１２】従来技術における処理の流れを説明する図で
ある。

【図１３】従来技術における構成展開を示す図である。

【図１４】クライアント・サーバシステムを示す図であ
る。

【図１５】本システムのネットワーク網の基本構成を示
す図である。

【図１６】クライアントとサーバとドメインと作業単位
の関係を示した図である。

【図１７】ドメイン間のデータ転送を説明する図であ
る。

【図１８】操作端末の構成を説明する図である。

【図１９】操作端末の表示例を示す図である。

【図２０】記録媒体のメモリマップを示す図である。

【図２１】受発注データ表示のフローチャートである。

【図２２】画面表示制御を説明するフローチャートであ
る。

【符号の説明】

１０１ ドメイン １１０ 構成管理データベース ４１０８−１ 操作端末 ２０８０ 操作端末 ４０００ 公衆回線。 １４１０ サーバ １４２０ クライアント １５０１ コンピュータ １５０２ コンピュータ １５０３ LAN網 １５０４ LAN網 １６２０ ドメイン １６０５ サーバ １６５０ データベース、 １６６０ ドメイン内部のデータベース １７０１ サーバ １７０２ サーバ １７１０ サーバの待ち行列 １７７０ ドメインの構成管理テーブル

Claims (36)

【特許請求の範囲】
1. 【請求項１】 木構造の関係をもって接続された第一の
   ドメインと第二のドメインと第三のドメインを備えた部
   品発注システムであって、 前記第二のドメインが、前記第一のドメインから受けた
   オーダーを構成部品ごとに展開する展開手段と、 前記展開手段により展開された構成部品ごとのオーダー
   を前記第三のドメインに伝達する伝達手段と、 を備えることを特徴とする部品発注システム。
2. 【請求項２】 前記第一のドメインと第二のドメインと
   第三のドメインは、 オーダーを発令する手段と、 前記オーダーを受領する手段と、 前記受領したオーダーに基づき加工計画を行う手段と、 前記加工計画に従い構成部品ごとに展開する手段と、 前記構成部品ごとに展開された部品の発注計画を行う手
   段と、 前記発注計画に基づき部品単位に展開された部品のオー
   ダーを行う手段と、 前記部品のオーダーに従いデータベースからデータを読
   取る手段と、 前記読み取ったデータをデータベースに書込む手段と、 を備えており、木構造の関係をもってネットワーク上で
   複数の接続を可能とすることを特徴とする請求項１記載
   の部品発注システム。
3. 【請求項３】 前記オーダーを受領する手段は、オーダ
   ーが新規であるか、変更であるか、同一オーダーの再送
   であるかを、データベースに保存されているデータと比
   較する手段を備えることを特徴とする請求項２記載の部
   品発注システム。
4. 【請求項４】 前記加工計画を行う手段は、受領したオ
   ーダーの指定納期日と、データベースに保存されている
   生産計画日とを比較する手段と、 その結果を基にして生産予定日をスケジューリングする
   手段と、を備えることを特徴とする請求項２記載の部品
   発注システム。
5. 【請求項５】 前記構成部品ごとに展開する手段は、受
   領したオーダーに基づき、製品を構成する部品単位に展
   開する手段と、 部品の員数を算出する手段と、 を備えることを特徴とする請求項２記載の部品発注シス
   テム。
6. 【請求項６】 前記発注計画を行う手段は、在庫数と必
   要となる部品の員数の比較を行う手段と、 前記比較の結果に基づき発注の最小単位を算出する手段
   と、 を備えることを特徴とする請求項２記載の部品発注シス
   テム。
7. 【請求項７】 発注の始点にあたる前記第一のドメイン
   は、オーダー入力に従いオーダー発令する手段を備え、 発注の終点にあたる前記第三のドメインは、前記オーダ
   ー発令に対するオーダー受領の手段を備えることを特徴
   とする請求項１記載の部品発注システム。
8. 【請求項８】 前記第一のドメインと第二のドメインと
   第三のドメインは節のない木構造の関係をもって接続さ
   れ、前記第一のドメインで処理された構成部品ごとのオ
   ーダーは、前記第二のドメインの展開手段で重複した処
   理がなされることなく、前記第三のドメインに伝達され
   ることを特徴とする請求項１記載の部品発注システム。
9. 【請求項９】 第一のネットワーク上のドメインと、第
   二のネットワーク上のドメインが公衆回線を介して接続
   される部品発注システムであって、前記第二のネットワ
   ーク上のドメインが前記第一のネットワーク上のドメイ
   ンからオーダーを受領する手段と、 前記オーダーに基づき加工計画を行う手段と、 前記加工計画に従い構成部品ごとに展開する手段と、 前記分割された構成部品ごとの発注計画を行う手段と、 前記発注計画に従い部品単位のオーダーを行う手段と、 を備えることを特徴とする部品発注システム。
10. 【請求項１０】 LANを介して前記第二のネットワーク
    上のドメインに接続された第三のネットワーク上のドメ
    インは、 前記第一のネットワーク上のドメインのオーダー発令
    を、公衆回線と、前記第二のネットワーク上のドメイン
    と、前記LANとを介してオーダー受領することを特徴と
    する請求項９記載の部品発注システム。
11. 【請求項１１】 特定部品の在庫数を記憶するデータベ
    ースと、木構造の関係をもって接続された第一のドメイ
    ンと第二のドメインと第三のドメインとを備えた部品発
    注システムであって、 前記第二のドメインは、前記第一のドメインから受けた
    オーダーに基づき構成部品ごとに展開する手段と、 前記展開手段より展開された部品単位のオーダーを前記
    第三のドメインに伝達する伝達手段と、 前記データベースに記録された特定部品の在庫数と前記
    展開手段により展開して得られた特定部品の必要数とを
    比較し、特定部品の在庫数が特定部品の必要数よりも所
    定数以上多い場合は前記第三のドメインヘのオーダーの
    伝達を停止する停止手段と、 を更に備えることを特徴とする部品発注システム。
12. 【請求項１２】 第一のドメインが内部に特定部品の在
    庫数を記憶したデータベースを備えた部品発注システム
    であって、 前記第一のドメインは、第二のドメインから受けたオー
    ダーに基づき構成部品ごとに展開する手段と、 前記展開手段より展開された部品単位のオーダーを第三
    のドメインに伝達する伝達手段と、 前記第一のドメイン内部のデータベースに記録された特
    定部品の在庫数と前記展開手段により展開して得られた
    特定部品の必要数とを比較し、特定部品の在庫数が特定
    部品の必要数よりも所定数以上多い場合は前記第三のド
    メインヘのオーダーの伝達を停止する停止手段と、 を備えることを特徴とする部品発注システム。
13. 【請求項１３】 木構造の関係をもって接続された第一
    のドメインと第二のドメインであって、 前記第二のドメインは前記第一のドメインから受けたオ
    ーダーに基づき構成部品ごとに展開する展開手段と、 前記第二のドメインに接続された操作端末から前記展開
    手段より展開された、部品単位のオーダーの受発注状況
    を参照するための参照許可を制御する第一の制御手段
    と、 を備えることを特徴とする部品発注システム。
14. 【請求項１４】 前記第一の制御手段は、前記第一のド
    メインの注文データと、加工計画のデータと、子部品在
    庫データの内から、前記第二のドメインで必要となるデ
    ータを限定して参照を許可することを特徴とする請求項
    １３記載の部品発注システム。
15. 【請求項１５】 前記第一の制御手段はドメインナンバ
    ーとパスワードの組合わせにより前記参照許可を与える
    ことを特徴とする請求項１４記載の部品発注システム。
16. 【請求項１６】 木構造の関係をもって接続された第一
    のドメインと第二のドメインで、 前記第二のドメインは前記第一のドメインから受けたオ
    ーダーを構成部品に展開する展開手段と、 前記第二のドメインに接続された操作端末から前記展開
    手段より展開された構成部品のオーダーの参照許可を制
    御する第一の制御手段と、 前記第二のドメインヘのオーダーに関連した前記第一の
    ドメイン内の発注情報の参照許可を制御する第二の制御
    手段と、 を備えることを特徴とする部品発注システム。
17. 【請求項１７】 オーダー発令、オーダー受領、加工計
    画、構成展開、発注計画、オーダーの各手段と、 木構造の関係をもってドメイン相互の接続を可能とする
    インタフェースと、 前記オーダーに従い納品された部品情報をデータベース
    に入力する入力手段と、 を備える単一ドメインから構成されることを特徴とする
    請求項１記載の部品発注システム。
18. 【請求項１８】 サーバー、クライアント、ＯＳ，ＣＰ
    Ｕ、記憶装置、入力装置、出力装置、常駐プロセスプロ
    グラムからなることを特徴とする部品発注システム。
19. 【請求項１９】 前記記憶装置はデータベースであるこ
    とを特徴とする請求項１８記載の部品発注システム。
20. 【請求項２０】 ドメインが第一のネットワークと第二
    のネットワークとに接続された部品発注システムであっ
    て、 情報の機密性の重軽により前記第一のネットワークと、
    前記第二のネットワークの情報とを分離して通信する手
    段を備えることを特徴とする部品発注システム。
21. 【請求項２１】 木構造の関係をもって接続された第一
    のドメインと第二のドメインと第三のドメインがオーダ
    ーを授受する方法であって、 前記第二のドメインが、前記第一のドメインから受けた
    オーダーを構成部品ごとに展開する展開工程と、 前記展開工程により展開された構成部品ごとのオーダー
    を前記第三のドメインに伝達する伝達工程と、 を備えることを特徴とする部品発注方法。
22. 【請求項２２】 木構造の関係をもって接続された第一
    のドメインと第二のドメインと第三のドメインが特定部
    品の在庫数を記憶するデー夕ベースを介してオーダーを
    授受する方法であって、 前記第二のドメインは、前記第一のドメインから受けた
    オーダーに基づき構成部品ごとに展開する工程と、 前記展開工程より展開された部品単位のオーダーを前記
    第三のドメインに伝達する伝達工程と、 前記データベースに記録された特定部品の在庫数と前記
    展開工程により展開して得られた特定部品の必要数とを
    比較し、特定部品の在庫数が特定部品の必要数よりも所
    定数以上多い場合は前記第三のドメインヘのオーダーの
    伝達を停止する停止工程と、 を備えることを特徴とする部品発注方法。
23. 【請求項２３】 特定部品の在庫数を記憶したデータベ
    ースを内部に備えた第一のドメインが、第二のドメイン
    からオーダーを受領し、第三のドメインにオーダーを伝
    達する方法であって、 前記第一のドメインは、前記第二のドメインから受けた
    オーダーに基づき構成部品ごとに展開する工程と、 前記展開工程より展開された部品単位のオーダーを前記
    第三のドメインに伝達する伝達工程と、 前記第一のドメイン内部のデータベースに記録された特
    定部品の在庫数と前記展開工程により展開して得られた
    特定部品の必要数とを比較し、前記特定部品の在庫数が
    特定部品の必要数よりも所定数以上多い場合は前記第三
    のドメインヘのオーダーの伝達を停止する停止工程と、 を備えることを特徴とする部品発注方法。
24. 【請求項２４】 特定部品の在庫数を記録するデータベ
    ースと、木構造の関係をもって接続された第一のドメイ
    ンと第二のドメインと第三のドメインを備えた部品管理
    システムであって、 前記第二のドメインは、前記第一のドメインから受けた
    オーダーに基づき構成部品ごとに展開する展開手段と、 前記展開手段により展開された部品単位のオーダーを前
    記第三のドメインに伝達する伝達手段と、 を備え、前記オーダーに従い納品された部品情報を前記
    データベースに入力する入力手段とを有することを特徴
    とする部品管理システム。
25. 【請求項２５】 オーダー発令、オーダー受領、加工計
    画、構成展開、発注計画、オーダーの手段と、 木構造の関係をもって接続を可能とするインタフェース
    と、 前記オーダーに従い納品された部品情報をデータベース
    に入力する入力手段と、 を備えた単一ドメインから構成されることを特徴とする
    請求項２４記載の部品管理システム。
26. 【請求項２６】 サーバー、クライアント、ＯＳ，ＣＰ
    Ｕ、記憶装置、入力装置、出力装置、常駐プロセスプロ
    グラムからなることを特徴とする部品管理システム。
27. 【請求項２７】 前記記憶装置はデータベースであるこ
    とを特徴とする請求項２６記載の部品管理システム。
28. 【請求項２８】 ドメインが第一のネットワークと第二
    のネットワークとに接続された部品管理システムであっ
    て、 情報の機密性の重軽により前記第一のネットワークと前
    記第二のネットワークの情報を分離して通信する手段を
    備えることを特徴とする部品管理システム。
29. 【請求項２９】 オーダーを発令する工程と、 前記オーダーを受領する工程と、 前記受領したオーダーに基づき加工計画を行う工程と、 前記加工計画に従い構成部品ごとに展開する工程と、 前記構成部品ごとに展開された部品の発注計画を行う工
    程と、 前記発注計画に基づき部品単位に展開された部品のオー
    ダーを行う工程と、 前記部品のオーダーに従いデータベースからデータを読
    取る工程と、 前記読み取ったデータをデータベースに書込む工程と、 をコンピュータに実行させるためのプログラムを記録し
    たことを特徴とするコンピュータ読み取り可能な記録媒
    体。
30. 【請求項３０】 第一のドメインから受けた自ドメイン
    の受注と、前記自ドメインが第二のドメインに出す発注
    とを管理する受発注管理装置であって、 データを表示するための表示手段と、 前記受注若しくは発注を識別させるためのアイコンと、
    前記アイコンが表す受注若しくは発注の結果を示すデー
    タとを、組合わせて前記表示手段に表示させるための表
    示制御手段と、 を備える特徴とする受発注管理装置。
31. 【請求項３１】 前記データは、前記アイコンに対応し
    た受発注の処理件数であることを特徴とする請求項３０
    記載の受発注管理装置。
32. 【請求項３２】 前記アイコン表示は、予定、注文確
    定、遅延、注文分割、注文変更、検査、検収のいずれか
    １つあるいは複数の組合わせであることを特徴とする請
    求項３０記載の受発注管理装置。
33. 【請求項３３】 第一のドメインから受けた自ドメイン
    の受注と、前記自ドメインが第二のドメインに出す発注
    とを管理する受発注管理方法であって、 データを表示するための表示工程と、 前記受注若しくは発注を識別させるためのアイコンと、
    前記アイコンが表す受注若しくは発注の結果を示すデー
    タとを、組合わせて前記表示工程に出力する表示制御工
    程と、 を備える特徴とする受発注管理方法。
34. 【請求項３４】 データを表示するための表示工程と、 前記受注若しくは発注を識別させるためのアイコンと、 前記アイコンが表す受注若しくは発注の結果を示すデー
    タとを、組合わせて前記表示工程に出力する表示制御工
    程と、 をコンピュータに実行させるためのプログラムを記録し
    たことを特徴とするコンピュータ読取り可能な記録媒
    体。
35. 【請求項３５】 前記表示制御手段は、入力手段からの
    指示に基づき、オーダー受領、加工計画、構成展開、発
    注計画、オーダーの詳細情報を前記表示手段に表示する
    ことを特徴とする請求項３０記載の受発注管理装置。
36. 【請求項３６】 前記表示制御工程は、入力工程からの
    指示に基づき、オーダー受領、加工計画、構成展開、発
    注計画、オーダーの詳細情報を前記表示工程に表示する
    ことを特徴とする請求項３３記載の受発注管理方法。