(57)【要約】【課題】需要が少なく予測の難しい補修部品の発注を効果的に行うことができるようにする。【解決手段】現行ＤＢ群４からまとめ発注の対象となるギャランティ対象口座を抽出し、ギャラＤＢ５に口座を新設し、整合明細リスト（取引先用）６および整合サマリーリスト（取引先用）７と、整合明細リスト（内部用）８および整合サマリーリスト（内部用）９を作成する。取引先では、この整合明細リスト（取引先用）６および整合サマリーリスト（取引先用）７に基づいて、口座および数量の検討を行い、ユーザ部門では、この整合明細リスト（内部用）８および整合サマリーリスト（内部用）９に基づいて、口座・数量の検討を行い、取引先での検討結果と整合を取り、ギャラＤＢを適宜更新する。【選択図】      図１
2004185120.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが部品メーカに対して所定期間分の需要予測数に基づいてまとめ発注を行うまとめ発注手段と、
前記部品メーカが前記ユーザからの注文に応じて前記まとめ発注の対象となる部品を前記ユーザに対して不定期に納品する納品手段と、
前記所定期間において前記ユーザが前記部品メーカに発注し、前記部品メーカが前記ユーザに納品した前記部品の累計数が、前記ユーザが前記部品メーカにまとめ発注した前記部品の前記需要予測数を越えるか否かを判定する判定手段と、前記判定手段による判定の結果、前記累計数が前記需要予測数を越えないと判定されたとき、前記ユーザは前記部品メーカに対して前記部品を前記需要予測数と前記累計数の差で表される残数分だけ発注し、買い取る買い取り手段と
を備えることを特徴とする部品発注システム。
【請求項２】
少なくとも、前記部品に対応する販売口座と、前記部品の発注開始日および終了日と、他の部品の販売口座を記憶する記憶手段をさらに備え、
前記記憶手段に記憶されている前記まとめ発注の対象となる前記部品に対応する前記販売口座に対して所定のマークが付される
ことを特徴とする請求項１に記載の部品発注システム。
【請求項３】
前記買い取り手段によって買い取られた前記部品に対応する、前記記憶手段に記憶されている前記販売口座に対して、所定のマークが付される
ことを特徴とする請求項２に記載の部品発注システム。
【請求項４】
前記買い取り手段による買い取りは月初日中に行われ、買い取りの対象となる販売口座は、処理月が終了月の販売口座であり、かつ在庫買い取りフラグが立っている販売口座である
ことを特徴とする請求項１乃至３のいずれかに記載の部品発注システム。
【請求項５】
前記判定手段による判定の結果、前記累計数が前記需要予測数を越えたと判定されたとき、前記部品が前記まとめ発注の対象から外され、一般発注の対象とされる
ことを特徴とする請求項１に記載の部品発注システム。
【請求項６】
ユーザが部品メーカに対して所定期間分の需要予測数に基づいてまとめ発注を行うまとめ発注ステップと、
前記部品メーカが前記ユーザからの注文に応じて前記まとめ発注の対象となる部品を前記ユーザに対して不定期に納品する納品ステップと、
前記所定期間において前記ユーザが前記部品メーカに発注し、前記部品メーカが前記ユーザに納品した前記部品の累計数が、前記ユーザが前記部品メーカにまとめ発注した前記部品の前記需要予測数を越えるか否かを判定する判定ステップと、
前記判定ステップにおける判定の結果、前記累計数が前記需要予測数を越えないと判定されたとき、前記ユーザは前記部品メーカに対して前記部品を前記需要予測数と前記累計数の差で表される残数分だけ発注し、買い取る買い取りステップと
を備えることを特徴とする部品発注方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、部品発注システムおよび部品発注方法に関し、特に、需要予測に基づいて部品をまとめて発注する部品発注システムおよび部品発注方法に関する。
【０００２】
【従来の技術】
従来、補修部品における部品メーカへの発注は、まとめて定期的に発注できるものと、量産打ち切りから数年経過した旧型部品のように需要が少なく、しかも予測が難しいため、まとめて定期的に発注できないものとがある。ブランドメーカ（発注者側）にとっては、旧型部品の管理点数のしめる割合が高いため、ブランドメーカは、ブランドメーカの在庫負担を軽減する目的で、可能な限り部品メーカに対して少量でも短期間に納品するよう部品メーカに要望している。
また、特許文献１に記載の発注情報提供システムは、処理日現在の在庫数量が補充点を下回っている場合に発注ロットに基づく補充要求数量を発注情報として出力する発注情報出力部と、過去および当年直近一定期間の出荷実績から算出した１日当りの平均出荷予測数量に基づいて、在庫数量が補充点を下回ると予測される次回補充要求予測日および当該予測日における次回補充要求予測数量を発注予測情報として出力する発注予測情報出力部と、それら発注情報および発注予測情報を仕入先に対して一定期間毎に自動送信する発注情報送信部とを具備し、仕入先に対し、定期的な発注情報とともに将来的な発注予測情報を提供することにより、特に仕入先側における生産計画の精度を高め、自社の在庫管理効率を向上させるものである（例えば、特許文献１参照）。
【０００３】
【特許文献１】
特開２００１−２５００７３号公報（図１）
【０００４】
【発明が解決しようとする課題】
しかしながら、需要の少ない部品を短期間で納品するためには、部品メーカ側で需要予測に基づいた生産を行い、在庫負担を行う必要があった。このため、段取りロスや材料ロスが発生し、それが価格に反映され、ブランドメーカにとっても購入単価の上昇となり、同様に負担が増加するという問題点があった。
また、特許文献１に記載のシステムにおいては、需要が少なく、しかも需要予測が難しいため、通常はまとめて定期的に発注できないものには適用できないという問題点があった。
【０００５】
本発明はこのような状況に鑑みてなされたものであり、需要が少なく需要予測が難しい部品でも、部品メーカ側の段取りロスや材料ロスを削減するとともに、ブランドメーカ側の購入単価も抑えることができるようにするものである。
【０００６】
【課題を解決するための手段】
請求項１に記載の部品発注システムは、ユーザが部品メーカに対して所定期間分の需要予測数に基づいてまとめ発注を行うまとめ発注手段と、部品メーカがユーザからの注文に応じてまとめ発注の対象となる部品をユーザに対して不定期に納品する納品手段と、所定期間においてユーザが部品メーカに発注し、部品メーカがユーザに納品した部品の累計数が、ユーザが部品メーカにまとめ発注した部品の需要予測数を越えるか否かを判定する判定手段と、判定手段による判定の結果、累計数が需要予測数を越えないと判定されたとき、ユーザは部品メーカに対して部品を需要予測数と累計数の差で表される残数分だけ発注し、買い取る買い取り手段とを備えることを特徴とする。
また、少なくとも、部品に対応する販売口座と、部品の発注開始日および終了日と、他の部品の販売口座を記憶する記憶手段をさらに備え、記憶手段に記憶されているまとめ発注の対象となる部品に対応する販売口座に対して所定のマークが付されるようにすることができる。
また、買い取り手段によって買い取られた部品に対応する、記憶手段に記憶されている販売口座に対して、所定のマークが付されるようにすることができる。
また、買い取り手段による買い取りは月初日中に行われ、買い取りの対象となる販売口座は、処理月が終了月の販売口座であり、かつ在庫買い取りフラグが立っている販売口座であるようにすることができる。
また、買い取り手段によって買い取られた部品の次年度のまとめ発注数は、需要予測数から買い取り手段によって買い取られた部品の数量を差し引いた数とされるようにすることができる。
また、判定手段による判定の結果、累計数が需要予測数を越えたと判定されたとき、部品がまとめ発注の対象から外され、一般発注の対象とされるようにすることができる。
請求項６に記載の部品発注方法は、ユーザが部品メーカに対して所定期間分の需要予測数に基づいてまとめ発注を行うまとめ発注ステップと、部品メーカがユーザからの注文に応じてまとめ発注の対象となる部品をユーザに対して不定期に納品する納品ステップと、所定期間においてユーザが部品メーカに発注し、部品メーカがユーザに納品した部品の累計数が、ユーザが部品メーカにまとめ発注した部品の需要予測数を越えるか否かを判定する判定ステップと、判定ステップにおける判定の結果、累計数が需要予測数を越えないと判定されたとき、ユーザは部品メーカに対して部品を需要予測数と累計数の差で表される残数分だけ発注し、買い取る買い取りステップとを備えることを特徴とする。
【０００７】
【発明の効果】
以上の如く、本発明に係る部品発注システムおよび部品発注方法によれば、ユーザが部品メーカに対して所定期間分の需要予測数に基づいてまとめ発注を行い、部品メーカがユーザからの注文に応じてまとめ発注の対象となる部品をユーザに対して不定期に納品し、所定期間においてユーザが部品メーカに発注し、部品メーカがユーザに納品した部品の累計数が、ユーザが部品メーカにまとめ発注した部品の需要予測数を越えるか否かを判定し、判定の結果、累計数が需要予測数を越えないと判定されたとき、ユーザは部品メーカに対して部品を需要予測数と累計数の差で表される残数分だけ発注し、買い取るようにしたので、需要が少ない部品でも計画ロット生産ができ、生産効率が上がるため、部品メーカ側の段取りロスや材料ロスを削減するとともに、ブランドメーカ側の購入単価も抑えることができる。
【０００８】
【発明の実施の形態】
以下、本発明の部品発注システムの一実施の形態の構成および動作について説明する。図１は、本実施の形態の構成および動作を示すジョブフローである。
【０００９】
同図に示すように、本実施の形態は、ユーザ部門に設置されている端末１００および端末２００と、システム側に設置されている処理対象データを記憶するギャラロットデータベース（Ｄ／Ｂ）３と、全部品の口座情報（販売口座情報）を記憶する現行データベース（Ｄ／Ｂ）群４と、まとめ部品（以降、ギャランティ部品と言う）として指定された部品の口座情報を記憶するギャラデータベース（ＤＢ）５と、部品に関する情報を記憶する部品データベース（Ｄ／Ｂ）１０と、発注情報を記憶する発注データベース（Ｄ／Ｂ）１３と、調達情報を記憶する調達データベース（Ｄ／Ｂ）１４と、受付〜包装〜保管までの工程をオンラインで見ることができる入庫オンラインシステム（ＮＳＱ）１８とから構成されている。
【００１０】
各データベースは、図示せぬパーソナルコンピュータやワークステーションの記憶装置内に構築されており、ネットワークによって接続され、データを送受信することができるようになっているものとする。
【００１１】
次に、図１および図２を参照して、本実施の形態の段取り（口座選定）管理処理の手順について説明する。まず最初に、ステップＳ１において、端末１００より、ギャランティ登録申請書に基づいたロット申請内容が入力され、ギャラロットＤＢ３に記憶される。ロット申請内容は、取引先、既存条件、開始月、終了月、資料発行希望日等の項目からなる。
【００１２】
次に、ステップＳ２において、新規口座作成処理が実行される。新規口座作成処理は、月末日中に行われ、処理対象データは、ロット申請内容に該当する口座であり、処理概要は、現行ＤＢ群４から該当口座を抽出し、ギャラＤＢ５に口座を新設し、検討用リスト（整合明細リスト（取引先用）６および整合サマリーリスト（取引先用）７と、整合明細リスト（内部用）８および整合サマリーリスト（内部用）９）を発行することである。
【００１３】
また、ステップＳ３において、口座拡大処理が実行される。口座拡大処理は、月末日中に行われ、処理対象データは、新規ロット申請から１年を経過したロット、或いは、拡大要求登録されたロットであり、処理概要は、新規口座を作成し、出力情報およびユーザ対応を新規口座作成処理と同様に行うことである。即ち、次年度になると初年度に設定した条件に基づいて対象口座を自動的に提示することである。
【００１４】
次に、ステップＳ４において、端末２００により、ギャラＤＢ５から、整合明細リスト（取引先用）６および整合明細リスト（内部用）８に合わせて、抽出処理が行われる。即ち、メーカーコード、検討開始日、グループを指定して整合明細リスト（取引先用）６および整合明細リスト（内部用）８と同じ口座情報が抽出される。抽出されたデータは、所定の記録媒体に保存されて取引先に送られる。
【００１５】
また、ステップＳ２およびステップＳ３において発行された整合明細リスト（取引先用）６および整合サマリーリスト（取引先用）７はユーザ部門を介して取引先に提供され、整合明細リスト（内部用）８および整合サマリーリスト（内部用）９はユーザ部門に提供される。ユーザ部門では、ステップＳ５において、整合明細リスト（内部用）８および整合サマリーリスト（内部用）９に基づいて、口座および数量の検討が行われる。取引先においては、ステップＳ６において、整合明細リスト（取引先用）６および整合サマリーリスト（取引先用）７に基づいて口座および数量の検討が行われる。
【００１６】
次に、ユーザ部門では、ステップＳ７において、取引先における検討結果とユーザ部門における検討結果に対して部番単位に整合処理が実行され、ステップＳ８において、整合結果反映処理が行われ、適宜、ギャラＤＢ５が更新される。整合結果反映処理によって得られる口座新規登録データは、部品番号、品名、取引先、年代、登録日、開始月、終了月、ステータス、ギャラ数、搬入リードタイム（Ｌ／Ｔ）等のデータからなる。また、整合結果反映処理によって得られる口座明細更新予測見直し数更新データは、部品番号、検討開始日、開始月、終了月、ギャラ数、搬入リードタイム等のデータからなる。従って、これらのデータによりギャラＤＢ５が適宜更新される。
【００１７】
次に、ユーザ部門では、ステップＳ９において、整合完了処理が実行され、次に、ステップＳ１０において、端末１００から決定リスト発行要求がギャラロットＤＢ３に対して行われる。
【００１８】
次に、ステップＳ１１において、決定リスト発行処理が実行される。決定リスト発行処理は、月末日中に行われ、処理対象データは、ギャラロットＤＢ３に登録されたＫＥＹの対象データ（ＫＥＹとしているデータであり、「旧型」、「年間需要数」、「発注回数」、「開始年月」、「終了年月」、「部番」等である。なお、発注回数は年２回が目安とされ、年間需要数は数字を区切ってグループ分けされている）、および、ギャラ数（ギャランティ締結数（ただし、０ではなく、継続数も加味する））であり、処理概要は、ギャラロットＤＢ３から処理対象データを抽出し、ギャラＤＢ５の対応する口座のステータスをＡからＢに更新し、部品ＤＢ１０の識別区分設定データを作成し、ギャランティ口座決定リスト（口座決定リスト）１１を発行することである。このとき、ギャランティ口座に対してギャランティ適用マーク「Ｇ」が付与される。
【００１９】
また、ステップＳ１２においては、決定リスト発行チェック処理が実行される。決定リスト発行チェック処理は、毎月２５日（会計締め日）に行われ、処理対象データは、翌月開始月の口座が存在するロット情報であり、処理概要は、翌月に搬入開始となっている口座のロットが決定リストの発行要求がされているか否かをチェックするための決定リスト未発行リスト１２を発行することであり、決定リストの発行を行うか、開始年月を遅らせるかの対応をとるために使用される。
【００２０】
決定リスト未発行リスト１２は、ユーザ部門に供給され、ステップＳ１３においてデータ整合処理が行われる。一方、口座決定リスト１１は、ユーザ部門に提供され、覚え書きが添付されて保存される。また、取引先にも提供され、取引先では、ステップＳ１４において、口座決定リスト１１が保存されるとともに、これに基づいて、部品先行生産が行われる。
【００２１】
また、ステップＳ１５において、調達ＤＢ更新処理が実行される。調達ＤＢ更新処理は、月初日中に行われ、処理対象データは、翌月または当月開始年月でかつ決定リスト発行済みデータであり、処理概要は、調達ＤＢ１４上の申請手番、申請最低ロット、申請発注タイプを初期化するデータの作成である。
【００２２】
また、ステップＳ１６においては、開始日前既発注抽出処理が実行される。開始日前既発注抽出処理は、月初日中に行われ、処理対象データは、当月より開始となった口座の一般発注情報であり、処理概要は、ギャランティとは別に扱うべき発注データを発注ＤＢ１３から抽出して既発注抽出リスト１５として発行し、ギャランティとは別に搬入推進を行うことである。この既発注抽出リスト１５には、発注ＤＢ１３から抽出された、ギャランティ開始年月の時点で前月以前の指定日で注残がある発注情報が印字されている。この既発注抽出リスト１５は、ユーザ部門に提供され、ステップＳ１８において搬入推進処理が行われる。
【００２３】
また、ステップＳ１７においては、開始月処理が実行される。開始月処理は、月末日中に行われ、処理対象データは、翌月より搬入開始となるデータであり、処理概要は、ギャラＤＢ５の対応する口座のステータスを「Ｂ」から「Ｃ」に進める更新データを作成し、ギャラＤＢ５に供給し、ステータスを「Ｂ」から「Ｃ」に更新することである。
【００２４】
次に、図３および図４を参照して、本実施の形態の搬入管理処理の手順について説明する。まず最初に、ステップＳ２１において、現行ＤＢ群４のデータに基づいて、各種現行発注処理が実行される。この処理は、後述するステップＳ２３において行われる発注時在庫チェックを組み込む処理を含む。また、ステップＳ２２においては、新Ｄ／Ｗ（Ｄａｉｌｙ／Ｗｅｅｋｌｙ）発注処理が実行される。
【００２５】
次に、ステップＳ２３において、発注時在庫チェックが実行される。発注時在庫チェックは、各種発注処理時に行われ、処理対象データは、ギャランティ適用マーク「Ｇ」が付与された口座に対応するギャランティ部品の発注データであり、処理概要は、ギャランティ部品の発注数に対してギャランティ部品の在庫数が上回っているか否かの判断を行い、在庫不足時（ギャランティ部品の発注数＞ギャランティ部品の在庫数）には発注不足リスト１６を作成し、在庫が有るときは、ギャラＤＢ５のギャランティ部品の発注数の累計を更新することである。発注不足リスト１６には、注文数に対して在庫数が不足している口座のリストが印刷されている。この発注不足リスト１６は、ユーザ部門に提供される。
【００２６】
ステップＳ２３において、在庫が有ると判断された場合、ステップＳ２４に進み、現行と同様の処理が実行される。即ち、ギャランティ部品の注文書１７を発行し、ユーザ部門を介して取引先に提供するとともに、発注情報をギャランティ発注明細ワーク１９に供給する。
【００２７】
ユーザ部門では、ステップＳ２５において、発注不足リスト１６に基づいて在庫確認処理が行われ、ステップＳ２６において、緊急補充必要時緊急発注処理が実行される。即ち、在庫数が不足している部品の発注データが通常部品の発注データとして発注ＤＢ１３に供給され、ステップＳ２８において現行発注処理が実行される。
【００２８】
また、ステップＳ２７においては、発注不足リスト１６に基づいて、次年度対応（ハンド）処理または一般発注に戻す処理を行うか否かの検討が行われる。次年度対応（ハンド）処理とは、次年度のスタート月を初年度と異なる月とすることであり、一般発注に戻す処理とは、ギャランティ期間中に需要が当初予測を上回るときに、ギャランティから外して一般発注とする処理である。
【００２９】
取引先では、ステップＳ２９において、注文書１７に基づいて、ギャランティ在庫からギャランティ部品が出庫され、ステップＳ３０においてユーザ部門に納品される。ユーザ部門では、ステップＳ３１において、端末２００により現行入庫処理が実行され、入庫オンラインシステム（ＮＳＱ）１８に入庫情報が供給され、記憶される。
【００３０】
次に、ステップＳ３２において、搬入情報抽出処理が実行される。搬入情報抽出処理は、毎日行われ、処理対象データは、当日搬入されたギャランティ発注データであり、処理概要は、入庫情報が反映されたギャランティの発注データをギャランティ発注明細ワーク１９に保存することである。
【００３１】
次に、ステップＳ３３において、搬入考課処理が実行される。搬入考課処理は、月初日中に行われ、処理対象データは、前月発注明細データであり、処理概要は、ギャランティ発注明細ワーク１９より前月の搬入率レポート２０、および搬入異常明細リスト２１を発行することである。搬入率レポート２０は、前月の搬入状況を示すリストであり、搬入異常明細リスト２１は、前月搬入指定日の発注の中で指定日通りに入庫されなかった発注の一覧リストである。
【００３２】
ステップＳ３３において発行された搬入率レポート２０はユーザ部門に提供され、ユーザ部門では、ステップＳ３４において、搬入結果の確認処理が行われる。また、ステップＳ３３において発行された搬入異常明細リスト２１もユーザ部門に提供され、ユーザ部門では、ステップＳ３５において、異常結果の確認処理が行われる。
【００３３】
ステップＳ３６においては、設変・Ｍ／Ｌ（Ｍａｋｅｒ  Ｌａｙ−ｏｕｔ）チェック処理が実行される。設変・Ｍ／Ｌチェック処理は、毎週行われ、処理対象データは、設変・Ｍ／Ｌが発生した口座であり、処理概要は、部品ＤＢ１０上で、設変・Ｍ／Ｌチェック処理を行い、設変・Ｍ／Ｌ抽出リスト２２を発行することである。ここで、設変とは、対象販売口座が販売中止となること、または別の口座に統合されること等であり、Ｍ／Ｌとは、部品メーカを変更することである。設変・Ｍ／Ｌ抽出リスト２２は、ユーザ部門に提供され、ユーザ部門では、ステップＳ３８において、買い取りおよび口座抹消処理が実行される。
【００３４】
また、ステップＳ３７においては、在庫動向レポート処理が実行される。在庫動向レポート処理は、月初日中に行われ、処理対象データは、ギャラＤＢ５に記憶されているギャランティ対象口座全点であり、処理概要は、ギャランティの検討を開始した年月より現在の在庫がどのように変化したかを確認するためのリストである在庫動向レポート２３を発行することである。在庫動向レポート２３は、ユーザ部門に提供され、ユーザ部門では、ステップＳ３９において、在庫の監視が行われる。
【００３５】
次に、図５を参照して、本実施の形態の残材管理処理の手順について説明する。まず最初に、ステップＳ４１において、在庫不足警告処理が実行される。在庫不足警告処理は、ギャランティ確定数（例えば１年間の需要予測数）と残数の比率（＝残数／ギャランティ確定数）を求め、ある一定値を下回ったときに不足警告リスト２４および不足警告サマリー２５を発行することである。
【００３６】
不足警告リスト２４および不足警告サマリー２５は、ユーザ部門に提供され、ユーザ部門では、ステップＳ４２において、不足警告リスト２４および不足警告サマリー２５に基づいて、今後の在庫予測が行われる。次に、ステップＳ４３において、次年度対応（ハンド）処理、または一般発注に戻す処理を行うか否かが検討される。次年度対応（ハンド）処理とは、初年度のスタート月を初年度と異なる月とすることであり、一般発注に戻す処理とは、ギャランティ期間中に需要が当初予測を上回るときに、ギャランティから外して一般発注とすることである。
【００３７】
次に、図６および図７を参照して、本実施の形態の買い取り管理処理の手順について説明する。まず最初に、ステップＳ５１において、現行ＤＢ群４に記憶されているデータに基づいて、次年度口座チェック処理が実行される。次年度口座チェック処理は、月末日中に行われ、処理対象データは、終了月−先行Ｌ／Ｔ（リードタイム）−１月（整合期間）が、処理月と一致している口座で、ステータスが「Ｃ」の口座であり、処理概要は、先行Ｌ／Ｔ（ギャランティ部品生産までの月数）および整合期間（いまの場合、１月）を加味した時期に翌年度もギャランティを継続して行うか否かを口座単位で決定することである。決定された結果はギャラＤＢ５に記憶される。また、整合明細リスト（取引先用）２６および整合サマリーリスト（取引先用）２７と、整合明細リスト（内部用）２８および整合サマリーリスト（内部用）２９と、口座終了チェックリスト３０が発行される。
【００３８】
次に、ユーザ部門では、ステップＳ５２において、ギャラＤＢ５からメーカコード、検討開始日、グループを指定して整合明細リスト（取引先用）２６および整合明細リスト（内部用）２８と同じ口座情報を抽出する処理が実行される。また、ステップＳ５１において発行された整合明細リスト（取引先用）２６および整合サマリーリスト（取引先用）２７は、ユーザ部門を介して取引先に提供される。また、ステップＳ５１において発行された整合明細リスト（内部用）２８および整合サマリーリスト（内部用）２９はユーザ部門に提供される。
【００３９】
ユーザ部門では、ステップＳ５３において、整合明細リスト（内部用）２８および整合サマリーリスト（内部用）２９に基づいて、在庫の買取・継続判断処理が行われる。また、取引先では、ステップＳ５４において、整合明細リスト（取引先用）２６および整合サマリーリスト（取引先用）２７に基づいて、在庫の買取・継続判断処理が行われる。ユーザ部門では、ステップＳ５５において、ユーザ部門におけるステップＳ５３の判断の結果と、取引先におけるステップＳ５４の判断の結果から整合処理を行い、整合結果を出力する。
【００４０】
ユーザ部門では、ステップＳ６０において、端末２００より整合結果が入力される。入力された整合結果を示すデータは、ギャラＤＢ５に供給されて記憶される。次に、ステップＳ６１において、終了月月初処理が実行される。終了月月初処理は、月末日中に行われ、処理対象データは、ギャラＤＢ５に記憶されている翌月が終了月の口座であり、処理概要は、ステータスを「Ｃ」から「Ｄ」に更新することである。
【００４１】
また、ステップＳ６２においては、買い取り処理が実行される。買い取り処理は、月初日中に行われ、処理対象データは、ギャラＤＢ５に記憶されている処理月が終了月のデータ、かつ在庫買い取りＦＬＧ（フラグ）の立っているデータであり、処理概要は、上記処理対象データより所定のデータ形式のデータを作成し、ＢＧＩＮ３１に登録するとともに、終了月買取サマリー３２を発行することである。このとき、在庫買い取り対象口座に対して在庫買い取りＦＬＧが立てられる。
【００４２】
この終了月買い取りサマリー３２は、ユーザ部門に提供され、ユーザ部門では、ステップＳ６３において、この終了月買い取りサマリー３２に基づいて在庫量検討処理が実行される。また、ステップＳ６４においては、ＢＧＩＮ３１のデータに基づいて現行の注文処理が実行される。
【００４３】
ステップＳ６５においては、買い取り残数チェック処理が実行される。買い取り残数チェック処理は、毎月２５日（会計締め日）に行われ、処理対象データは、処理月が終了月のデータであり、かつ在庫買い取りＦＬＧの立っているデータであり、処理概要は、上記データの残材の有無を確認し、残材が有る場合は買い取り残数有りリスト３３を発行することである。この買い取り残数有りリスト３３は、ユーザ部門に提供され、ユーザ部門では、ステップＳ６７において、この買い取り残数有りリスト３３に基づいて買い取り発注が行われる。この買い取り発注処理は、買い取り残数有りリスト３３に印刷された口座の在庫を買い取るために発注をかける処理であり、月初買い取り処理に行われる発注ＮＧの対応漏れ時に発生する処理である。
【００４４】
また、ステップＳ６６においては、在庫継続チェック処理が実行される。在庫継続チェック処理は、毎月２５日に行われ、処理対象データは、処理月が終了月のデータであり、かつ在庫継続ＦＬＧの立っているデータである。この在庫継続ＦＬＧは、１２ヶ月目の１日の午後に立てられる。処理概要は、基本的には発生しないはずであるが、例えば、在庫継続データだが新規口座が作成されていないデータを在庫継続エラーリスト３４として発行することである。即ち、部品メーカ（取引先）の都合で残数を買い取らなくてもよい場合の処理である。在庫継続エラーリスト３４には、在庫を次年度に継続対象とした部品の中で次年度口座が作成されていない口座の一覧リストが印刷されている。
【００４５】
この在庫継続エラーリスト３４は、ユーザ部門に提供される。ユーザ部門では、ステップＳ６８において、この在庫継続エラーリスト３４に基づいて、継続ＮＧ対応処理が実行される。即ち、在庫継続エラーリスト３４に記載されている口座は次年度については口座が作成されない。
【００４６】
また、ステップＳ６９においては、終了月月末処理が実行される。終了月月末処理は、月末日中に行われ、処理対象データは、ギャラＤＢ５に記憶されている処理月が終了月のデータであり、処理概要は、ステータスを「Ｄ」から「Ｅ」に更新することである。
【００４７】
また、ステップＳ７０においては、適用マーク整合処理が実行される。適用マーク整合処理は、月末日中に行われ、処理対象データは、ギャラＤＢ５に記憶されているギャランティ登録口座全点であり、処理概要は、終了口座および決定リスト発行口座より部品ＤＢ１０上のギャランティ適用マークの更新データを作成することである。この更新データに基づいて、部品ＤＢ１０のデータが更新される。
【００４８】
また、ステップＳ７１においては、在庫継続処理が実行される。在庫継続処理は、月次処理として行われ、処理対象データは、処理月が終了月のデータであり、かつ在庫継続ＦＬＧの立っているデータであり、処理概要は、基本的に上記データ（口座）に対応する部品に対しては翌月より開始されるデータが作成されており、現時点での残数を新データに反映させることである。
【００４９】
なお、上記実施の形態の構成および動作は例であって、本発明の趣旨を逸脱しない範囲で適宜変更することができることは言うまでもない。
【図面の簡単な説明】
【図１】本発明の部品発注システムの一実施の形態の段取り管理処理を説明するためのジョブフローである。
【図２】本発明の部品発注システムの一実施の形態の段取り管理処理を説明するためのジョブフローである。
【図３】本発明の部品発注システムの一実施の形態の搬入管理処理を説明するためのジョブフローである。
【図４】本発明の部品発注システムの一実施の形態の搬入管理処理を説明するためのジョブフローである。
【図５】本発明の部品発注システムの一実施の形態の残材管理処理を説明するためのジョブフローである。
【図６】本発明の部品発注システムの一実施の形態の買い取り処理を説明するためのジョブフローである。
【図７】本発明の部品発注システムの一実施の形態の買い取り処理を説明するためのジョブフローである。
【符号の説明】
１  ギャランティ登録申請書
３  ギャラロットＤＢ
４  現行ＤＢ群
５  ギャラＤＢ
６  整合明細リスト（取引先用）
７  整合サマリーリスト（取り先用）
８  整合明細リスト（内部用）
９  整合サマリーリスト（内部用）
１０  部品ＤＢ
１１  口座決定リスト
１２  決定リスト未発行リスト
１３  発注ＤＢ
１４  調達ＤＢ
１５  既発注抽出リスト
１６  発注不足リスト
１７  注文書
１８  ＮＳＱ
１９  ギャランティ発注明細ワーク
２０  搬入率レポート
２１  搬入異常明細リスト
２２  設変・Ｍ／Ｌ抽出リスト
２３  在庫動向レポート
２４  不足警告リスト
２５  不足警告サマリー
２６  整合明細リスト（取引先用）
２７  整合サマリーリスト（取引先用）
２８  整合明細リスト（内部用）
２９  整合サマリーリスト（内部用）
３０  口座終了チェックリスト
３１  ＢＧＩＮ
３２  終了月買い取りサマリー
３３  買い取り残数有りリスト
３４  在庫継続エラーリスト
１００，２００  端末
【図１】
2004185120.tif 000003
【図２】
2004185120.tif 000004
【図３】
2004185120.tif 000005
【図４】
2004185120.tif 000006
【図５】
2004185120.tif 000007
【図６】
2004185120.tif 000008
【図７】
2004185120.tif 000009