(57)【要約】【課題】複数種類の半導体装置製品における在庫の管理、出荷作業、および製品出荷に伴う伝票処理などの事務処理の効率を大幅に向上させる。【解決手段】販社営業が受注した受注情報を入力すると、販社受発注／出荷システム６は、実績データを本社受発注／出荷システム９へ送信すると該本社受発注／出荷システム９が販社ＳＯに基づき本社の受注を登録し、本社ＴＯの納期に従い、本社倉庫管理システム１０に出荷指示する。その出荷指示により、本社倉庫管理システム１０は出荷作業を指示し、直送出荷後に出荷実績を本社倉庫管理システム１０へ計上する。本社在庫管理システム８は出荷実績情報に基づき、在庫の差し引き及び本社ＴＯの売上計上を実施する。販社受発注／出荷システム６は出荷実績情報により、販社の発注を登録する。販社受発注／出荷システム６は、前プロセスの販社ＰＯに対して入庫を自動的に計上する。【選択図】図１
2009193389.tif 000002
【特許請求の範囲】
【請求項１】
入力された販社からの販社受注情報に基づいて、本社受発注出荷システムが、１対１で本社受注情報を自動的に受注登録するステップと、
前記本社受注情報の納期にしたがって、前記本社受発注出荷システムが本社倉庫管理システムに対して該当する製品を顧客への直送出荷指示を行うステップと、
前記本社倉庫管理システムが、前記出荷指示に基づいて、顧客への直送出荷が終了した際に、前記製品の出荷が完了した出荷実績情報を送信するステップと、
前記出荷実績情報に基づいて、販社受発注／出荷システムが、販社発注情報を発注登録するステップと、
前記販社受発注／出荷システムが、前記販社発注情報に対して入庫を計上するステップとを有することを特徴とする半導体装置の流通管理方法。
【請求項２】
販社受注情報に基づいて、需要予測／回答システムが需要予測を修正し、需要予測データ、および在庫、仕掛情報などによりネッティング処理を行うステップと、
前記需要予測／回答システムによるネッティング処理の結果から、前記需要予測／回答システムが確定オーダを生成するステップと、
本社受発注出荷システムが、前記確定オーダに基づいて本社受注情報として受注されるステップと、
前記本社受発注出荷システムが、本社受注情報の納期に従って、該当する製品を販社倉庫へ出荷する出荷指示を本社倉庫管理システムに対して行うステップと、
前記販社倉庫への製品出荷が完了した際に出荷実績情報を前記本社倉庫管理システムに計上するステップと、
前記出荷実績情報に基づいて、本社在庫管理システムが、在庫の差し引き、および本社受注の売上計上を実施するステップと、
販社受発注／出荷システムが、前記出荷実績情報に基づいて、販社発注情報を発注登録するステップとを有することを特徴とする半導体装置の流通管理方法。
【請求項３】
本社倉庫に入庫された製品を、本社倉庫管理システムが入庫計上するステップと、
本社在庫管理システムが、確定オーダの納期、および顧客情報に基づいて、製品別管理在庫から、顧客別論理在庫に向けて在庫を移送するステップと、
本社受発注出荷システムが、本社受注情報の納期、および回答納期に基づいて、本社受注の出荷指示を前記本社倉庫管理システムに行うステップと、
前記出荷指示に基づいて、製品の顧客への出荷が完了した際に、前記本社受発注出荷システム出力する出荷実績情報に基づいて、前記本社在庫管理システムが、在庫の差し引き、および本社受注情報の売上を計上するステップと、
前記出荷実績情報に基づいて、販社受発注／出荷システムが、販社発注情報を発注登録するステップと、
前記販社発注情報に対して、販社在庫管理システムが入庫を計上するステップとを有することを特徴とする半導体装置の流通管理方法。
【請求項４】
本社倉庫に入庫された製品を、本社倉庫管理システムが入庫計上するステップと、
本社在庫管理システムが、確定オーダの納期、および顧客情報に基づいて、製品別管理在庫から顧客別論理在庫に向けて在庫を移送するステップと、
本社受発注出荷システムが、オーダ確定による在庫移送にリンクして出荷指示を行うステップと、
本社受注情報の出荷指示に基づいて、前記本社倉庫管理システムが、該当する製品を販社倉庫へ出荷する出荷指示を行うステップと、
出荷指示に基づいて、前記販社倉庫への製品の出荷が完了した際に、前記本社倉庫管理システムが、出荷実績情報を計上するステップと、
前記出荷実績情報に基づいて、前記本社在庫管理システムが、在庫の差し引き、および本社受注情報の売上を計上するステップと、
前記出荷実績情報に基づいて、販社受発注／出荷システムが、販社発注情報を発注登録するステップと、
前記販社倉庫に製品が到着した際に、販社倉庫管理システムが入庫計上データを処理し、前記入庫計上データに基づいて、販社の顧客別論理在庫として計上するステップと、
前記入庫計上データに基づいて、販社受発注／出荷システムが、販社発注として入庫計上するステップと、
販社受注情報の納期、および回答納期に基づいて、前記販社受発注／出荷システムが販社受注の出荷指示を行うステップと、
前記販社受発注／出荷システムの出荷指示に基づいて、販社倉庫管理システムが、販社倉庫の前記販社倉庫管理システムへ出荷指示を行うステップと、
顧客への製品出荷が終了した際に、出荷実績情報を出力するステップと、
前記出荷実績情報に基づいて、販社在庫管理システムが、在庫の差し引き、および販社受注の売上計上するステップとを有することを特徴とする半導体装置の流通管理方法。
【請求項５】
受信した顧客オーダ実績、顧客オーダ注残、出荷実績、および在庫などからなる購販在データを累計データへ反映させ、需要予測／回答システムが処理に使用するデータを抽出するステップと、
前記需要予測／回答システムが、入力された需要予測に対して購販在データの顧客オーダの補正、または購販在データの出荷データより先行納入があった際の補正を実施し、補正後需要予測データを作成するステップと、
前記需要予測／回答システムが、本社倉庫管理システムより本社倉庫における在庫を受信し、前記在庫を本社管理と販社管理在庫へ分離するステップと、
前記需要予測／回答システムが、前記補正後需要予測データに対して、販社管理在庫、購販在データの在庫を加味してネッティング処理を行うステップと、
未確定オーダ生成期間マスタに基づいて、前記需要予測／回答システムが、本社出荷要求を未確定オーダ生成期間の内外に分離するステップと、
購販在データの顧客オーダに基づいて、前記需要予測／回答システムが、未確定オーダにて顧客オーダの裏づけがあるものについては確定オーダとするステップと、
前記需要予測／回答システムが、確定オーダ、未確定オーダ、および本社出荷要求残をマージしてＦｉｎａｌＳＦとし、そのＦｉｎａｌＳＦに対して、分離した前記本社管理在庫の引き当てを実施するステップと、
前記本社管理在庫に引き当たったＦｉｎａｌＳＦに対して、前記需要予測／回答システムが、本社発出荷回答の付与を実施するステップと、
需給調整システムが、前記ＦｉｎａｌＳＦで本社管理在庫に引き当たっていない生産要求数について工程別仕掛かりデータに基づいて、仕掛の引当を実施するステップと、
前記需給調整システムが入庫予定日が付与されたＦｉｎａｌＳＦを送信し、前記需要予測／回答システムが、入庫ベースの回答について、本社倉庫作業工期マスタより倉庫作業工期を取得して出荷ベースに焼き直すステップとを有するを特徴とする半導体装置の流通管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、半導体装置の在庫管理技術に関し、特に、半導体装置の在庫管理、出荷作業、ならびに伝票処理の効率化に有効な技術に関する。
【背景技術】
【０００２】
近年、インターネットなどのネットワークを用いて、半導体装置などの発注や流通管理などを行う製品流通管理システムが広く普及している。
【０００３】
以下に、本発明者の検討によるこの種のシステムを用いた半導体装置の流通パターンの一例について説明する。
【０００４】
この種のシステムは、たとえば、各半導体装置を販売する会社（以下「販社」と称する）などに設けられた販社受発注／出荷システムと半導体装置を製造する会社（以下「本社」と称する）などに設けられた本社受発注／出荷システムなどから構成されている。そして、顧客から販社への発注があると、販社から販社受発注／出荷システムに受注情報を登録する。
【０００５】
この受注情報は、インターネット回線、あるいは専用回線などを介して本社受発注／出荷システムに送信される。これにより、本社受注の登録が行われ、出荷指示を行い、出荷伝票が作成される。
【０００６】
この出荷指示に基づいて、本社の倉庫では、出荷作業が実施される。出荷が完了すると、本社受発注／出荷システムによる出庫確認が行われ、本社受注が売り上げられる。また、本社受発注／出荷システムは、出庫確認した後、出庫確認の情報を販社受発注／出荷システムに送信する。
【０００７】
販社受発注／出荷システムは、本社の出庫確認の情報を受け取ると、販社発注を生成する。本社の倉庫から出庫された製品は、販社の倉庫を経由して顧客に送付され、顧客に入庫（納入）と同時に売り上げが実地されることになる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところが、上記のような製品流通管理システムなどによる製品の在庫や物流などの管理技術では、次のような問題点があることが本発明者により見い出された。
【０００９】
すなわち、本社の工場出荷から、顧客納入に至るまで在庫を一時保管する’在庫ポイント’が、製品単位で管理をする本社倉庫と、同様の単位で管理する販社の倉庫との少なくとも２箇所あり、その’在庫ポイント’に存在する在庫は、需要予測を元に生産されて製品単位で在庫保管され、最終的に納入する’何れの顧客’のための在庫なのかが不明となっており、そのため、各顧客別の需要予測を行う営業担当が不要な在庫を生成しても、在庫が生成された理由が明確にできないという問題がある。
【００１０】
また、顧客の需要減が発生した場合や、他の顧客の需要予測に対して在庫不足が発生した場合、余剰在庫が発生するが、余剰在庫を配分する場合に、当該在庫が‘何れの顧客’の為に生成された在庫なのかが不明なため当該販社に紐付く全ての商流の需要予測と在庫を加味して配分することが困難となってしまうことになる。
【００１１】
さらに、各’在庫ポイント’の管理者が安全在庫を各々保持するため、各‘在庫ポイント’で安全在庫を２重に保持してしまい、在庫効率が低下してしまうという問題がある。
【００１２】
また、各‘在庫ポイント’の出荷作業において、’在庫ポイント’における在庫が、何れの顧客（もしくは販社）から需要予測に基づいて生成されているのか管理されていないために、出荷指示作業時に確認が困難である。
【００１３】
そのため、在庫の生成の基となっている本来の顧客（もしくは販社）の需要予測に基づいた在庫を、他社の需要のために使用してしまうことになり、本来の顧客（もしくは販売会社）に対する在庫が不足し、納期が守れない可能性がある。
【００１４】
それを回避するために、在庫不足が生じないように各’在庫ポイント’管理者が各顧客の需要予測を立てる際、安全在庫を余分に生成する心理が働き、余剰の流通在庫が生じる原因となる。
【００１５】
また、本来の顧客の需要予測に基づいた在庫を他社の需要のために使用して出荷する際、各担当者間での調整作業を経て出荷する必要がある。
【００１６】
さらに、伝票処理作業では、市況の変化等により受注時の価格の変更が必要な場合、変更後の価格で販社に出荷することになるが、この場合、販売会社にて初期の受注に対して価格訂正の発注を行い、本社で受注受付を再度行う業務が発生してしまうことになる。
【００１７】
本発明の目的は、複数種類の半導体装置製品における在庫の管理、出荷作業、および製品出荷に伴う伝票処理などの事務処理の効率を大幅に向上させることのできる技術を提供することにある。
【００１８】
本発明の前記ならびにそのほかの目的と新規な特徴については、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１９】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。
【００２０】
本発明による半導体装置の流通管理方法は、入力された販社からの販社受注情報に基づいて、本社受発注出荷システムが、１対１で本社受注情報を自動的に受注登録するステップと、本社受注情報の納期にしたがって、本社受発注出荷システムが本社倉庫管理システムに対して該当する製品を顧客への直送出荷指示を行うステップと、本社倉庫管理システムが、出荷指示に基づいて、顧客への直送出荷が終了した際に、製品の出荷が完了した出荷実績情報を送信するステップと、出荷実績情報に基づいて、販社受発注／出荷システムが、販社発注情報を発注登録するステップと、販社受発注／出荷システムが、販社発注情報に対して入庫を計上するステップとを有するものである。
【００２１】
また、本願のその他の発明の概要を簡単に示す。
【００２２】
本発明による半導体装置の流通管理方法は、販社受注情報に基づいて、需要予測／回答システムが需要予測を修正し、需要予測データ、および在庫、仕掛情報などによりネッティング処理を行うステップと、需要予測／回答システムによるネッティング処理の結果から、需要予測／回答システムが確定オーダを生成するステップと、本社受発注出荷システムが、確定オーダに基づいて本社受注情報として受注されるステップと、本社受発注出荷システムが、本社受注情報の納期に従って、該当する製品を販社倉庫へ出荷する出荷指示を本社倉庫管理システムに対して行うステップと、販社倉庫への製品出荷が完了した際に出荷実績情報を本社倉庫管理システムに計上するステップと、出荷実績情報に基づいて、本社在庫管理システムが、在庫の差し引き、および本社受注の売上計上を実施するステップと、販社受発注／出荷システムが、出荷実績情報に基づいて、販社発注情報を発注登録するステップとを有するものである。
【００２３】
また、本発明による半導体装置の流通管理方法は、本社倉庫に入庫された製品を、本社倉庫管理システムが入庫計上するステップと、本社在庫管理システムが、確定オーダの納期、および顧客情報に基づいて、製品別管理在庫から、顧客別論理在庫に向けて在庫を移送するステップと、本社受発注出荷システムが、本社受注情報の納期、および回答納期に基づいて、本社受注の出荷指示を本社倉庫管理システムに行うステップと、出荷指示に基づいて、製品の顧客への出荷が完了した際に、本社受発注出荷システム出力する出荷実績情報に基づいて、本社在庫管理システムが、在庫の差し引き、および本社受注情報の売上を計上するステップと、出荷実績情報に基づいて、販社受発注／出荷システムが、販社発注情報を発注登録するステップと、販社発注情報に対して、販社在庫管理システムが入庫を計上するステップとを有するものである。
【００２４】
さらに、本発明による半導体装置の流通管理方法は、本社倉庫に入庫された製品を、本社倉庫管理システムが入庫計上するステップと、本社在庫管理システムが、確定オーダの納期、および顧客情報に基づいて、製品別管理在庫から顧客別論理在庫に向けて在庫を移送するステップと、本社受発注出荷システムが、オーダ確定による在庫移送にリンクして出荷指示を行うステップと、本社受注情報の出荷指示に基づいて、本社倉庫管理システムが、該当する製品を販社倉庫へ出荷する出荷指示を行うステップと、出荷指示に基づいて、販社倉庫への製品の出荷が完了した際に、本社倉庫管理システムが、出荷実績情報を計上するステップと、出荷実績情報に基づいて、本社在庫管理システムが、在庫の差し引き、および本社受注情報の売上を計上するステップと、出荷実績情報に基づいて、販社受発注／出荷システムが、販社発注情報を発注登録するステップと、販社倉庫に製品が到着した際に、販社倉庫管理システムが入庫計上データを処理し、入庫計上データに基づいて、販社の顧客別論理在庫として計上するステップと、入庫計上データに基づいて、販社受発注／出荷システムが、販社発注として入庫計上するステップと、販社受注情報の納期、および回答納期に基づいて、販社受発注／出荷システムが販社受注の出荷指示を行うステップと、販社受発注／出荷システムの出荷指示に基づいて、販社倉庫管理システムが、販社倉庫の販社倉庫管理システムへ出荷指示を行うステップと、顧客への製品出荷が終了した際に、出荷実績情報を出力するステップと、出荷実績情報に基づいて、販社在庫管理システムが、在庫の差し引き、および販社受注の売上計上するステップとを有するものである。
【００２５】
また、本発明による半導体装置の流通管理方法は、受信した顧客オーダ実績、顧客オーダ注残、出荷実績、および在庫などからなる購販在データを累計データへ反映させ、需要予測／回答システムが処理に使用するデータを抽出するステップと、需要予測／回答システムが、入力された需要予測に対して購販在データの顧客オーダの補正、または購販在データの出荷データより先行納入があった際の補正を実施し、補正後需要予測データを作成するステップと、需要予測／回答システムが、本社倉庫管理システムより本社倉庫における在庫を受信し、在庫を本社管理と販社管理在庫へ分離するステップと、需要予測／回答システムが、補正後需要予測データに対して、販社管理在庫、購販在データの在庫を加味してネッティング処理を行うステップと、未確定オーダ生成期間マスタに基づいて、需要予測／回答システムが、本社出荷要求を未確定オーダ生成期間の内外に分離するステップと、購販在データの顧客オーダに基づいて、需要予測／回答システムが、未確定オーダにて顧客オーダの裏づけがあるものについては確定オーダとするステップと、需要予測／回答システムが、確定オーダ、未確定オーダ、および本社出荷要求残をマージしてＦｉｎａｌＳＦ（最終需要予測）とし、そのＦｉｎａｌＳＦに対して、分離した本社管理在庫の引き当てを実施するステップと、本社管理在庫に引き当たったＦｉｎａｌＳＦに対して、需要予測／回答システムが、本社発出荷回答の付与を実施するステップと、需給調整システムが、ＦｉｎａｌＳＦで本社管理在庫に引き当たっていない生産要求数について工程別仕掛かりデータに基づいて、仕掛の引当を実施するステップと、需給調整システムが入庫予定日が付与されたＦｉｎａｌＳＦを送信し、需要予測／回答システムが、入庫ベースの回答について、本社倉庫作業工期マスタより倉庫作業工期を取得して出荷ベースに焼き直すステップとを有するものである。
【発明の効果】
【００２６】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００２７】
（１）本社倉庫内や、本社倉庫と販社倉庫間などで物理的な製品の移動を行うことなく、販社在庫の管理を行うことができる。
【００２８】
（２）また、需要予測により在庫が生成された本来の顧客にのみ出荷指示作業を自動的に行うことができる。
【００２９】
（３）さらに、販社などにおける発注伝票登録業務と価格訂正に伴う発注と受注側の伝票修正作業を削減することができる。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００３１】
図１は、本発明の一実施の形態による製品流通管理システムの構成を示すブロック図、図２は、図１の製品流通管理システムによるパターン１における伝票処理の簡素化処理例を示すフローチャート、図３は、図１の製品流通管理システムによるパターン２における伝票処理の簡素化処理の一例を示すフローチャート、図４は、図１の製品流通管理システムによるパターン３における伝票処理の簡素化処理例を示すフローチャート、図５は、図１の製品流通管理システムによる本社の伝票処理における説明図、図６は、図１の製品流通管理システムによる販社の伝票処理における説明図、図７は、図１の製品流通管理システムによる流通在庫の削減の一例を示すフローチャート、図８は、図１の製品流通管理システムによる本社在庫の在庫管理の概要を示す説明図、図９は、図７のステップＳ４１７の処理における自動出荷の説明図、図１０は、図１の製品流通管理システムによるＣＯの出荷の一例を示す説明図、図１１は、図１の製品流通管理システムによるパターン１における製品の出荷業務の効率化の例を示すフローチャート、図１２は、図１の製品流通管理システムによるパターン２における製品の出荷業務の効率化の例を示すフローチャート、図１３は、図１の製品流通管理システムによるパターン３における製品の出荷業務の効率化の例を示すフローチャート、図１４は、図１の製品流通管理システムによる顧客別論理在庫の出荷手順を示した説明図、図１５は、図１の製品流通管理システムによる在庫・仕掛かりの最適配分の処理例を示すフローチャート、図１６は、図１の製品流通管理システムによる販社管理在庫の顧客間融通の一例を示すフローチャート、図１７は、図１の製品流通管理システムによる販社管理在庫と出荷枠の顧客間融通の処理例を示すフローチャート、図１８は、図１の製品流通管理システムによる在庫融通後の出荷枠を交換する顧客別出荷枠融通の説明図である。
【００３２】
本実施の形態において、製品流通管理システム１は、図１に示すように、受注／出荷部２、需要予測／納期回答部３、および需要予測／回答システム４から構成されている。受注／出荷部２は、販社在庫管理システム５、販社受発注／出荷システム６、販社倉庫管理システム７、本社在庫管理システム８、本社受発注／出荷システム９、ならびに本社倉庫管理システム１０からなり、半導体装置などの製品の受注、および製品出荷の管理を行う。
【００３３】
販社在庫管理システム５、販社受発注／出荷システム６、および販社倉庫管理システム７は、販売会社（販社）毎に備えられており、インターネット回線や専用回線などを介して、各販売会社の端末とそれぞれ接続されている。
【００３４】
需要予測／納期回答部３は、需給調整システム１１、生産指示／回答システム１２、および仕掛かり管理システム１３からなり、受注／出荷部２からの受注情報や出荷情報などから需要を予測し、納期の回答などを行う。また、需要予測／回答システム４は、製品流通管理システム１におけるすべての制御を司る。
【００３５】
また、商物流パターンには、以下の３つのパターンがある。
【００３６】
パターン１は、顧客から、販社、本社に伝票が流れ、製品は、本社から顧客に搬送（直送）されるパターンである。
【００３７】
パターン２は、顧客から、販社、本社に伝票が流れ、製品は、本社から販社に搬送された後、顧客に納品されるパターンである。
【００３８】
パターン３は、顧客から、特約店、および販社を経由した後に本社に伝票が流れ、製品は、本社から特約店に搬送され、その後、特約店から顧客に納品されるパターンである。
【００３９】
次に、本実施の形態による製品流通管理システム１の動作について説明する。
【００４０】
始めに、伝票処理の簡素化技術について、図２〜図４にフローチャートを用いて説明する。
【００４１】
図２は、パターン１による伝票処理の簡素化処理の例を示すフローチャートである。
【００４２】
まず、販社営業が顧客から受注した注文書に基づき、販社受発注／出荷システム６に対して販社が受注した受注情報（以下、販社ＳＯ（Ｓａｌｅｓ  Ｏｒｄｅｒ）という）を入力する（ステップＳ１０１）。
【００４３】
販社ＳＯが入力されると、販社受発注／出荷システム６は、実績データ（受発注残や売上実績情報など）を本社受発注／出荷システム９へ送信する（ステップＳ１０２）。ここでは、パターン１の物流が顧客直送であるため、本社受発注／出荷システム９にて、販社ＳＯに基づき１対１で本社の受注（以下、本社ＴＯ（Ｔｒａｎｓｆｅｒ  Ｏｒｄｅｒ）という）を自動的に受注登録する（ステップＳ１０３）。
【００４４】
このように、販社ＳＯと本社ＴＯを１対１で生成することにより、本社から顧客への、販社ＳＯと同等の内容による直送出荷が可能となる。
【００４５】
続いて、本社受発注／出荷システム９にて、本社ＴＯの納期（＝販社ＳＯの納期）に従い、本社倉庫管理システム１０に出荷指示を行う（ステップＳ１０４）。本社倉庫管理システム１０では、本社受発注／出荷システム９からの出荷指示に基づき、本社倉庫ワーカーへの出荷作業の指示を行う。
【００４６】
本社倉庫ワーカーは出荷作業指示に基づき、保管棚からの出庫、梱包作業、顧客への直送出荷を行い、完了後に出荷実績を本社倉庫管理システム１０へと計上する。本社倉庫管理システム１０は、本社在庫管理システム８へと出荷実績情報を伝送する。
【００４７】
本社在庫管理システム８では出荷実績情報に基づき、在庫の差し引き及び本社ＴＯの売上計上を実施した後、出荷実績情報を販社受発注／出荷システム６へと伝送する。
【００４８】
そして、本社受発注／出荷システム９から販社受発注／出荷システム６へと、出荷実績情報を送信する（ステップＳ１０５）。
【００４９】
販社受発注／出荷システム６にて、本社受発注／出荷システム９から伝送された出荷実績情報に基づき、販社の発注（以下、販社ＰＯ（Ｐｕｒｃｈａｓｅ  Ｏｒｄｅｒ））という）を自動的に発注登録する（ステップＳ１０６）。
【００５０】
前述したように、物流が顧客直送であるため、製品は販社倉庫を経由しない。従って、販社受発注／出荷システム６にて、前プロセスにて発注された販社ＰＯに対して入庫を自動的に計上する（ステップＳ１０７）。また、同時に本社からの出荷に紐付く販社ＳＯ上を自動的に計上する。
【００５１】
図３は、パターン２による伝票処理の簡素化処理の例を示すフローチャートである。
【００５２】
このパターン２では、始めに、販社営業が、顧客から受注した注文書に基づき販社受発注／出荷システム６に対して販社ＳＯを入力し（ステップＳ２０１）、販社受発注／出荷システム６から実績データ（受発注残、売上実績情報）が需要予測／回答システム４へ送信される（ステップＳ２０２）。
【００５３】
続いて、需要予測／回答システム４は販社ＳＯを取り込み（ステップＳ２０３）、該販社ＳＯにより自動的に需要予測を修正する。販社営業が需要予測／回答システム４で需要予測を修正する（ステップＳ２０４）。
【００５４】
需要予測／回答システム４は、需要予測データ、および在庫・仕掛情報などに基づいてネッティング（需要と供給の相殺）処理を行い（ステップＳ２０５）、前プロセスでのネッティング処理の結果、確定オーダ（以下、ＣＯ（Ｃｏｍｍｉｔｔｅｄ  Ｏｒｄｅｒ））が生成される（ステップＳ２０６）。
【００５５】
その後、需要予測／回答システム４から、本社受発注／出荷システム９へとＣＯデータが伝送され、本社ＴＯがＣＯに基づき自動的に受注される（ステップＳ２０７）。本社受発注／出荷システム９は、本社ＴＯの納期（＝ＣＯの納期）に従い、本社倉庫管理システム１０へ出荷指示を行う（ステップＳ２０８）。
【００５６】
本社倉庫管理システム１０では、出荷指示に基づき、本社倉庫ワーカーへの出荷作業の指示が行われる。本社倉庫ワーカーは出荷作業指示に基づき、保管棚からの出庫、梱包作業、販社倉庫への出荷を行い、完了後に出荷実績を本社倉庫管理システム１０へと計上する。
【００５７】
本社倉庫管理システム１０は、本社在庫管理システム８へと出荷実績情報を伝送する。本社在庫管理システム８では出荷実績情報に基づき、在庫の差し引き、および本社ＴＯの売上計上を実施した後、出荷実績情報を販社受発注／出荷システム６へと伝送する。
【００５８】
そして、本社受発注／出荷システム９から、販社受発注／出荷システム６へと前プロセスで行った出荷の出荷実績情報を送信する（ステップＳ２０９）。販社受発注／出荷システム６は、前プロセスの出荷実績情報に基づき、販社ＰＯを自動的に発注登録する。
【００５９】
図４は、パターン３による伝票処理の簡素化処理の例を示すフローチャートである。
【００６０】
特約店に於いて、顧客から受注した注文書に基づき特約店受発注／出荷システム（図示せず）に対して特約店の受注（以下、特約店ＳＯ）を入力する（ステップＳ３０１）。続いて、特約店受発注／出荷システムから実績データ（受発注残、売上実績情報）を需要予測／回答システム４へ送信する（ステップＳ３０２）。
【００６１】
需要予測／回答システム４で、特約店ＳＯを取り込む（ステップＳ３０３）。また、このとき、特約店ＳＯにより自動的に需要予測を修正する。そして、特約店に於いて需要予測／回答システム４で需要予測を修正する（ステップＳ３０４）。
【００６２】
需要予測／回答システム４は、需要予測データ、および在庫・仕掛情報などによりネッティング（需要と供給の相殺）処理を行い（ステップＳ３０５）前プロセスでのネッティング処理の結果、ＣＯを生成する（ステップＳ３０６）。
【００６３】
続いて、需要予測／回答システム４から、本社受発注／出荷システム９へとＣＯデータが伝送され、本社ＴＯがＣＯに基づき自動的に受注される（ステップＳ３０７）。前プロセスにて本社ＴＯが受注されると、ＴＯ受注結果データが本社受発注／出荷システム９から販社受発注／出荷システム６へと伝送され、このデータを基に販社受発注／出荷システムで販社ＳＯが自動的に受注される（ステップＳ３０８）。
【００６４】
前プロセスにて本社ＴＯが受注されると、ＴＯ受注結果データが本社受発注／出荷システム９から特約店受発注／出荷システムへと伝送され、このデータを基に特約店ＰＯが自動的に登録される（ステップＳ３０９）。
【００６５】
本社受発注／出荷システム９は、本社ＴＯの納期（＝ＣＯの納期）に従い、本社倉庫管理システム１０へ出荷指示を行う（ステップＳ３１０）。本社倉庫管理システム１０では、出荷指示に基づき、本社倉庫ワーカーへの出荷作業の指示が行われる。
【００６６】
本社倉庫ワーカーは出荷作業指示に基づき、保管棚からの出庫、梱包作業、特約店への出荷を行い、完了後に出荷実績を本社倉庫管理システム１０へと計上する。本社倉庫管理システム１０は本社在庫管理システム８へと出荷実績情報を伝送する。
【００６７】
本社在庫管理システム８では出荷実績情報に基づき、在庫の差し引き、および本社ＴＯの売上計上を実施した後、出荷実績情報を販社受発注／出荷システム６へと伝送する。本社受発注／出荷システム９から、販社受発注／出荷システム６へと、前プロセスで行った出荷の出荷実績情報を送信する（ステップＳ３１１）。
【００６８】
販社受発注／出荷システム６は、前プロセスの出荷実績情報に基づき、販社ＰＯを自動的に発注登録する（ステップＳ３１２）。パターン３では、物流が特約店直送であるため、製品は販社倉庫を経由しない。
【００６９】
従って、販社受発注／出荷システム６にて、前プロセスにて発注された販社ＰＯに対して入庫を自動的に計上する。また、同時に本社からの出荷に対応した販社ＳＯの売り上げを自動的に計上する（ステップＳ３１３）。
【００７０】
前プロセスにて特約店POが発注された後、製品が特約店に到着すると、特約店受発注システムにて特約店POに対して入庫処理を計上する（ステップＳ３１４）。
【００７１】
以上のことにより、本社の伝票処理において、図５に示すように、パターン１では、販社ＳＯから本社ＴＯを自動的に作成することができ、パターン２、およびパターン３においては、需要予測から作成されるＣＯから本社ＴＯが１：１で自動的に作成することができる。
【００７２】
それにより、本社ＴＯと需要予測（ＣＯ）、もしくは販社ＳＯをリンクさせることにより、本社ＴＯの登録、および修正・作業などを削減することができる。
【００７３】
また、販社の伝票処理において、図６に示すように、パターン１〜３で、本社の出荷実績を販社受発注／出荷システム６が自動連携して販社ＰＯを作成することができる。それによって、本社の出荷実績により、販社ＰＯを自動的に作成することができるので、販社の伝票処理業務を削減することができる。
【００７４】
次に、製品流通管理システム１による流通在庫の削減技術について、図７のフローチャートを用いて説明する。
【００７５】
始めに、本社在庫の在庫管理の概要について、図８を用いて説明する。
【００７６】
本社倉庫では、物理的に型名単位に在庫が管理されている。しかしながら、製品流通管理システム１では、図８に示すように、顧客・型名別に論理的に区分けして管理を行っている。
【００７７】
この論理的な区分けを行うことによって、ＣＯラインの導入が可能となる、本社在庫と販社在庫とが明確に切り分けて管理できるようになる。このように、本社在庫から販売会社在庫に論理的に出荷するポイントをＣＯラインとして新たに定義し、販売会社の在庫を本社の在庫に取り込むことでストックポイントの削減を行うことができる。
【００７８】
これにより、本社倉庫内や、本社倉庫と販社倉庫間などで物理的な製品の移動を行うことなく販社在庫の管理を行うことができる。
【００７９】
まず、図７において、販社・特約店において顧客からの需要予測を例えば２６週間分、需要予測／回答システム４に客先コードを製品名別に入力する（ステップＳ４０１）。続いて、販社・特約店の各拠点よりデイリーにて購販在データ（たとえば、顧客オーダ実績・顧客オーダ注残・出荷実績・販社の倉庫に存在する在庫など）を需要予測／回答システム４が受信する（ステップＳ４０２）。
【００８０】
需要予測／回答システム４は、受信した受信件数をチェックし、販社にて独自に使用している客先コード・製品名を標準のものに変換する（ステップＳ４０３）。受信した購販在データを累計データへ各種反映させ、当日処理に使用するデータを抽出する（ステップＳ４０４）。
【００８１】
営業が入力した需要予測に対して購販在データの顧客オーダにて補正を実施する。また、購販在データの出荷データより先行納入があった場合は補正を実施する。これにより補正後需要予測データが作成される（ステップＳ４０５）。
【００８２】
また、需要予測／回答システム４は、本社倉庫管理システム１０より本社在庫（本社管理・販社管理）を受信する（ステップＳ４０６）。需要予測／回答システム４は、本社在庫を本社管理と販社管理在庫へ分類する（ステップＳ４０７）。
【００８３】
そして、ステップＳ４０５の処理における補正後需要予測データに対して販社管理在庫と購販在データの在庫（販社倉庫に存在する在庫）とを加味してネッティング（在庫引去り）処理を実施する（ステップＳ４０８）。
【００８４】
この際、本社→販社→顧客間の物流工期を加味して１Ｗの納期前倒しを実施する。販社にて在庫を保持してオペレーションしたい場合は在庫水準値が設定されているためこれを加味する。これにより本社出荷要求データが作成される。
【００８５】
ＵＯ生成期間マスタ（製品名別に設定）をもとに本社出荷要求をＵＯ生成期間の内外に分離する。ＵＯ生成期間内に本社出荷要求についてはＵＯ化を実施する。ＵＯ生成期間外の本社出荷要求は信頼度係数マスタをもとに信頼度補正が行われて本社出荷要求残となる（ステップＳ４０９）。
【００８６】
ここで、ＵＯについて説明する。
【００８７】
需要予測に対して流通在庫・顧客までの物流工期を加味してネッティングして作成された本社出荷要求から設定した週分だけ手前よりオーダ扱いとし、このオーダ扱いする週数がＵＯ（Ｕｎｃｏｍｍｉｔｔｅｄ  Ｏｒｄｅｒ）生成期間であり、これにより発生したオーダがＵＯである。
【００８８】
続いて、購販在データの顧客オーダをもとに、ＵＯにて顧客オーダの裏づけがあるものについてはＣＯ化を実施する（ステップＳＳ４１０）。ＣＯ＋ＵＯ＋本社出荷要求残をマージする（ステップＳ４１１）。これを最終需要予測（図中ではＦｉｎａｌＳＦ）と呼ぶ。
【００８９】
最終需要予測に対して、ステップＳ４０３の処理で分離した本社管理在庫の引き当てを実施する（ステップＳ４１２）。本社管理在庫に引き当たった最終需要予測に対して本社発出荷回答の付与を実施する（ステップＳ４１３）。基本的には、本社管理在庫に引き当たっているので納期＝出荷回答となる。最終需要予測の中で出荷回答が付与されたＣＯを分離する（ステップＳ４１４）。
【００９０】
続いて、 需要予測／回答システム４は、本社受発注／出荷システム９に出荷回答が付与されたＣＯを送信する（ステップＳ４１５）。本社受発注／出荷システム９は、ＣＯの要求納期（例えば需要予測が週バケットの場合は月曜日に設定）、および出荷回答をもとに出荷日が来たものを抽出する（ステップＳ４１６）。この際、自動出荷指示マスタの参照を行い対象の抽出を行う。
【００９１】
本社受発注／出荷システム９は、抽出されたＣＯに対して出荷を実施する。これによりＣＯの出荷が自動で行われる（ステップＳ４１７）。
【００９２】
ＣＯの出荷にあわせて、本社在庫管理システム８は、本社管理在庫から販社管理在庫へ客先コード別に在庫の論理移動を実施する（ステップＳ４１８）。本社在庫ではあるが、ＣＯライン（図１０に示す）を超えた在庫については本社在庫管理システムの中では販社管理在庫として表示される（ステップＳ４１９）。顧客オーダに販社管理在庫を引当てて実際の製品の出荷を実施する（ステップＳ４２０）。
【００９３】
図９は、ステップＳ４１７の処理における自動出荷の説明図である。
【００９４】
在庫生成の基ともなる需要予測の単位である’顧客’毎に本社倉庫内部を論理的に顧客別に区分けし、需要予測が立てられた在庫が生成された顧客にのみ出荷し時差行が行えるようにし、各種情報の確認作業を削減する。
【００９５】
また、在庫生成の需要予測の単位とすることによって、出荷指示作業の自動化を可能とすることができ、出荷指示作業の削減を可能にすることができる。
【００９６】
図１０は、ＣＯの出荷の一例を示す説明図である。
【００９７】
図示するように、向上からの入庫品は、一旦本社の在庫となる。ＣＯを利用して出荷が行われると、本社在庫から客先別在庫へ口座が移動する。この場合、ＣＯラインを境に本社が管理する在庫と販社が管理する在庫とに分かれる。但し、実際の製品は本社の倉庫に存在したままとなっている。
【００９８】
顧客への出荷は、販社のオーダ（ＳＯ）にリンクした本社オーダより客先別管理在庫からのみ可能である。
【００９９】
このように、ＣＯの出荷を行うことにより、本社の倉庫に存在する在庫であっても、販社などは、顧客別の在庫を販社の在庫として意識可能にすることができる。
【０１００】
次に、製品流通管理システム１による出荷業務の効率化技術について、図１１〜図１３のフローチャートを用いて説明する。
【０１０１】
図１１は、パターン１による製品の出荷業務の効率化の例を示すフローチャートである。
【０１０２】
まず、工場での製造／出荷後、本社倉庫に入庫する（ステップＳ５０１）。本社倉庫管理システム１０により入庫計上を行う。本社在庫管理システム８では、本社倉庫管理システム１０での入庫計上に従い、在庫の計上を行う。この際、在庫は製品別管理在庫として扱われる。
【０１０３】
本社在庫管理システム８では、ＣＯの納期、顧客情報に基づき、製品別管理在庫から顧客別論理在庫に向けてに在庫を分類する（ステップＳ５０２）。このＣＯによる在庫分類は、ＣＯの納期、および回答納期により自動的に行われる。また、ＣＯによる在庫分類は手動によって行うようにしてもよい。
【０１０４】
続いて、本社受発注／出荷システム９は、ＴＯの納期、および回答納期に基づいて、ＴＯの出荷指示を行う（ステップＳ５０３）。これにより、ＣＯによって移送された顧客別論理在庫に対して出荷指示が行われる。この場合も、手動での出荷指示を行うようにしてもよい。
【０１０５】
そして、本社倉庫管理システム１０では、ＴＯの出荷指示に基づき、本社倉庫ワーカーへの出荷作業の指示が行われる。本社倉庫ワーカーは出荷作業指示に基づき、保管棚からの出庫、梱包作業、顧客への直送出荷を行い、完了後に出荷実績を本社倉庫管理システム１０へと計上する（ステップＳ５０４）。
【０１０６】
本社倉庫管理システム１０は、本社在庫管理システム８へと出荷実績情報を伝送する。本社在庫管理システム８は、出荷実績情報に基づき、在庫の差し引き、および本社ＴＯの売上計上を実施した後、出荷実績情報を販社受発注／出荷システム６へ伝送する。
【０１０７】
本社受発注／出荷システム９から、販社受発注／出荷システム６へと、前プロセスで行った出荷の出荷実績情報を送信する（ステップＳ５０５）。販社受発注／出荷システム６は、前プロセスの出荷実績情報に基づき、販社ＰＯを自動的に発注登録する（ステップＳ５０６）。
【０１０８】
パターン１では、物流が顧客直送であるため、製品は販社倉庫を経由しない。従って、販社受発注／出荷システム６にて、前プロセスにて発注された販社ＰＯに対して入庫を自動的にに計上する（ステップＳ５０７）。また、同時に本社からの出荷に紐付く販社ＳＯの売り上げを自動的に計上する。
【０１０９】
図１２は、パターン２による製品の出荷業務の効率化の例を示すフローチャートである。
【０１１０】
まず、工場での製造／出荷後、製品が本社倉庫に入庫されると（ステップＳ６０１）、本社倉庫管理システム１０で入庫計上を行う。本社在庫管理システム８では、本社倉庫管理システム１０での入庫計上に従い、在庫の計上を行う。この際、在庫は製品別管理在庫として扱われる。
【０１１１】
本社在庫管理システム８では、ＣＯの納期、顧客情報に基づき、製品別管理在庫から顧客別論理在庫に向けてに在庫を分類する（ステップＳ６０２）。このＣＯによる在庫移送は、ＣＯの納期、および回答納期により自動的に行われる（設定により手動での移送も可能）。
【０１１２】
続いて、本社受発注／出荷システム９では、ＣＯによる在庫移送にリンクして，ＴＯの出荷指示を行う（ステップＳ６０３）。これにより、ＣＯによって移送された顧客別論理在庫に対して出荷指示が行われる。
【０１１３】
本社倉庫管理システム１０は、ＴＯの出荷指示に基づき、本社倉庫ワーカーへの出荷作業の指示を行う（ステップＳ６０４）。本社倉庫ワーカーは出荷作業指示に基づき、保管棚からの出庫、梱包作業、販社倉庫への出荷を行い、完了後に出荷実績を本社倉庫管理システム１０へと計上する。
【０１１４】
本社倉庫管理システム１０は、本社在庫管理システム８へと出荷実績情報を伝送する。本社在庫管理システム８は、出荷実績情報に基づき、在庫の差し引き、および本社ＴＯの売上計上を実施した後、出荷実績情報を本社受発注／出荷システム９へと伝送する。
【０１１５】
本社受発注／出荷システム９から、販社受発注／出荷システム６へと、前プロセスで行った出荷の出荷実績情報を送信する（ステップＳ６０５）。販社受発注／出荷システム６にて、前プロセスの出荷実績情報に基づき、販社ＰＯを自動的に発注登録する（ステップＳ６０６）。
【０１１６】
販社倉庫に製品が到着した後、販社倉庫管理システム７で入庫処理を行い、入庫計上される（ステップＳ６０７）。販社倉庫管理システム７から販社在庫管理システム５へと入庫計上データが伝送され、販社の顧客別論理在庫として計上される。
【０１１７】
販社在庫管理システム５から、販社受発注／出荷システム６へと入庫計上データが伝送され、販社ＰＯが入庫計上される。販社受発注／出荷システム６では、販社ＳＯの納期、ならびに回答納期に基づいて販社ＳＯの出荷指示を行う（ステップＳ６０８）。
【０１１８】
この販社ＳＯに対する出荷指示は、販社ＳＯの納期、ならびに回答納期により自動的に行われる（設定により手動も可能）。
【０１１９】
販社倉庫管理システム７では、販社ＳＯの出荷指示に基づき、販社倉庫ワーカーへの出荷作業の指示が行われる（ステップＳ６０９）。販社倉庫ワーカーは出荷作業指示に基づき、保管棚からの出庫、梱包作業、顧客への出荷を行い、完了後に出荷実績を販社倉庫管理システム７へと計上する。
【０１２０】
販社倉庫管理システム７は、販社在庫管理システム５へと出荷実績情報を伝送する。販社在庫管理システム５では出荷実績情報に基づき、在庫の差し引き、および販社ＳＯの売上計上を実施する。
【０１２１】
図１３は、パターン３による製品の出荷業務の効率化の例を示すフローチャートである。
【０１２２】
まず、工場での製造／出荷後、本社倉庫に入庫する。本社倉庫管理システム１０で入庫計上を行う。本社在庫管理システム８では、本社倉庫管理システム１０での入庫計上に従い、在庫の計上を行う。この際、在庫は製品別管理在庫として扱われる（ステップＳ７０１）。
【０１２３】
そして、本社在庫管理システム８では、ＣＯの納期、ならびに顧客情報に基づき、製品別管理在庫から顧客別論理在庫に向けてに在庫を分類する（ステップＳ７０２）。このＣＯによる在庫分類は、ＣＯの納期、および回答納期により自動的に行われる（設定により手動での分類も可能）。
【０１２４】
続いて、本社受発注／出荷システム９では、ＴＯの納期、および回答納期に基づいてＴＯの出荷指示を行う（ステップＳ７０３）。これにより、ＣＯによって移送された顧客別論理在庫に対して出荷指示が行われる（設定により手動での出荷指示も可能）。
【０１２５】
その後、本社倉庫管理システム１０では、ＴＯの出荷指示に基づき、本社倉庫ワーカーへの出荷作業の指示が行われる（ステップＳ７０４）。本社倉庫ワーカーは出荷作業指示に基づき、保管棚からの出庫、梱包作業、特約店への直送出荷を行い、完了後に出荷実績を本社倉庫管理システム１０へと計上する。
【０１２６】
本社倉庫管理システム１０は、本社在庫管理システム８へと出荷実績情報を伝送する。本社在庫管理システム８では出荷実績情報に基づき、在庫の差し引き及び本社ＴＯの売上計上を実施した後、出荷実績情報を販社受発注／出荷システム６へと伝送する。
【０１２７】
本社受発注／出荷システム９から、販社受発注／出荷システム６へと、前プロセスで行った出荷の出荷実績情報を送信する（ステップＳ７０５）。販社受発注／出荷システム６にて、前プロセスの出荷実績情報に基づき、販社ＰＯを自動的に発注登録する（ステップＳ７０６）。
【０１２８】
パターン３では、物流が特約店直送であるため、製品は販社倉庫を経由しない。従って、販社受発注／出荷システム６にて、前プロセスにて発注された販社ＰＯに対して入庫を自動的に計上する（ステップＳ７０７）。また、同時に本社からの出荷に対応する販社ＳＯの売り上げを自動的に計上する。
【０１２９】
並行して特約店では、製品が特約店に到着すると、特約店受発注システムにて特約店POに対して入庫処理を計上する（ステップＳ７０８）。
【０１３０】
図１４は、顧客別論理在庫の出荷手順を示した説明図である。
【０１３１】
顧客在庫は、製品別管理在庫から入庫し、ＴＯにより顧客、販社倉庫、特約店へと出荷する。在庫は論理的に顧客別となっており、ＴＯより目的地に出荷される、出荷手順は、ＣＯにより製品別管理在庫が顧客在庫口座へと出庫され、顧客在庫口座からＴＯにより物理的に目的地へと出荷がされる。
【０１３２】
次に、製品流通管理システム１による在庫・仕掛かりの最適配分技術について、図１５のフローチャートを用いて説明する。
【０１３３】
まず、販社、特約店に於いて顧客からの需要予測を、たとえば先行２６週間分、需要予測／回答システム４に客先コード、および品名別に入力する（ステップＳ８０１）。
【０１３４】
販社・特約店の各拠点よりデイリーにて購販在データ（顧客オーダ実績・顧客オーダ注残・出荷実績・販社や特約店の倉庫に存在する在庫）を需要予測／回答システム４が受信する（ステップＳ８０２）。
【０１３５】
需要予測／回答システム４は、受信件数のチェック（２重送信のチェック）を行い、販社にて独自に使用している客先コード・品名を標準のものに変換する（ステップＳ８０３）。
【０１３６】
需要予測／回答システム４は、受信した購販在データを累計データへ各種反映させ、当日処理に使用するデータを抽出し（ステップＳ８０４）、営業が入力した需要予測に対して購販在データの顧客オーダにて補正を実施する。また、購販在データの出荷データより先行納入があった場合は補正を実施する。これにより補正後需要予測データが作成される（ステップＳ８０５）。
【０１３７】
続いて、需要予測／回答システム４は、本社倉庫管理システム８より本社在庫（本社管理・販社管理）を受信し（ステップＳ８０６）、本社在庫を本社管理在庫と販社管理在庫へ分類する（ステップＳ８０７）。
【０１３８】
ステップＳ８０５の補正後需要予測データに対して、販社管理在庫と購販在データの在庫（販社の倉庫に存在する在庫）とを加味してネッティング（在庫引去り）処理を実施する（ステップＳ８０８）。この際に本社→販社→顧客間の物流工期を加味して１Ｗの納期前倒しを実施する。販社にて在庫を保持してオペレーションしたい場合は在庫水準値が設定されているためこれを加味する。これにより本社出荷要求データが作成される。
【０１３９】
そして、需要予測／回答システム４は、ＵＯ生成期間マスタ（製品名別に設定）をもとに本社出荷要求をＵＯ生成期間の内外に分離する（ステップＳ８０９）。ＵＯ生成期間内に本社出荷要求についてはＵＯ化を実施する。ＵＯ生成期間外の本社出荷要求は信頼度係数マスタをもとに信頼度補正が行われて本社出荷要求残となる。
【０１４０】
続いて、需要予測／回答システム４は、購販在データの顧客オーダをもとに、ＵＯにて顧客オーダの裏づけがあるものについてはＣＯ化を実施し（ステップＳ８１０）ＣＯ＋ＵＯ＋本社出荷要求残をマージして最終需要予測（図中ではＦｉｎａｌＳＦと記載）とする（ステップＳ８１１）。
【０１４１】
そして、需要予測／回答システム４は、最終需要予測に対して、ステップＳ８０７で分離した本社管理在庫の引き当てを実施し（ステップＳ８１２）、本社管理在庫に引き当たった最終需要予測に対して本社発出荷回答の付与（基本的には、本社管理在庫に引き当たっているので納期＝出荷回答となる）を実施した後（ステップＳ８１３）、最終需要予測を需給調整システム１１に送信する（ステップＳ８１４）。
【０１４２】
需給調整システム１１は、仕掛管理システムより各生産工場拠点の工程別仕掛情報を受信し（ステップＳ８１５）、入庫（出荷）製品名より各工程の仕掛を引当てるための情報（ＢＯＭ）を受信する（仕掛の製品名は入庫の品名と異なるケースあり）。
【０１４３】
需給調整システム１１は、最終需要予測で本社管理在庫に引き当たっていない分（生産要求数）についてＢＯＭデータをもとに仕掛の引当を実施する（ステップＳ８１６）。引きあたった仕掛の工程より入庫までの工期・工程の能力（需給調整システム１１に登録）を加味して本社倉庫への入庫予定日を算出する。
【０１４４】
入庫予定日が付与された最終需要予測を需給調整システム１１が需要予測／回答システム４へ送信する（ステップＳ８１７）。需要予測／回答システム４は、入庫ベースの回答について、本社倉庫作業工期マスタより倉庫作業工期を取得して出荷ベースに焼き直す（ステップＳ８１８）。
【０１４５】
次に、製品流通管理システム１による各種権利（在庫・出荷回答）融通の流れについて、図１６、および図１７を用いて説明する。
【０１４６】
図１６は、販社管理在庫の顧客間融通一例を示すフローチャートである。
【０１４７】
まず、本社在庫である客先別の販社管理在庫を検索する。融通を依頼する客先の選定を行い、需要予測／回答システム４の販社在庫のスワップリクエスト（出荷枠交換要求）画面に必要情報を入力する（ステップＳ９０１）。
【０１４８】
入力された情報を元に、需要予測／回答システム４は、スワップリクエストデータを生成する。客先担当者マスタをもとに依頼先の担当営業者へリクエスト情報をメールで自動配信する（ステップＳ９０２）。
【０１４９】
依頼先の担当営業者はメールの内容を確認後、需要予測／回答システム４の販社在庫スワップ承認画面より承認を入力する（ステップＳ９０３）。
【０１５０】
次に、需要予測／回答システム４において客先別の在庫について依頼元から依頼先へ在庫付け替えを行い（ステップＳ９０４）、需要予測／回答システム４より、スワップ情報を本社在庫管理システム８へ送信する（ステップＳ９０５）。
【０１５１】
そして、本社在庫管理システム８は、スワップ情報をもとに本社在庫である販社管理在庫の客先の付け替えを行う（ステップＳ９０６）。
【０１５２】
図１７は、販社管理在庫と出荷枠の顧客間融通の一例を示すフローチャートである。
【０１５３】
まず、本社在庫である客先別の販社管理在庫を検索する。融通を依頼する客先の選定を行い、需要予測／回答システム４の販社在庫スワップリクエスト画面に必要情報を入力する（ステップＳ１００１）。
【０１５４】
入力された情報を元に、需要予測／回答システム４は、スワップリクエストデータを生成する。客先担当者マスタをもとに依頼先の担当営業者へＲｅｑｕｅｓｔ情報を例えばメール等で自動配信する（ステップＳ１００２）。
【０１５５】
依頼先の担当営業者はメールの内容を確認後、需要予測／回答システム４の販社在庫スワップ承認画面より承認を入力する（ステップＳ１００３）。需要予測／回答システム４内にある客先別の在庫について依頼元から依頼先へ在庫付け替えを行う（ステップＳ１００４）。
【０１５６】
需要予測／回答システム４よりスワップ情報を本社在庫管理システム８へ送信する（ステップＳ１００５）。本社在庫管理システム８は、スワップ情報をもとに本社在庫である販社管理在庫の客先の付け替えを行う（ステップＳ１００６）。
【０１５７】
在庫の融通を承認した後、この先の需要予測がある場合は依頼元に対して出荷枠（権利）の融通を依頼する（ステップＳ１００７）。需要予測／回答システム４は、在庫融通の依頼元の出荷回答を検索する（ステップＳ１００８）。在庫融通の依頼元である客先に対して、需要予測／回答システム４の出荷枠スワップリクエスト画面に必要情報を入力する。
【０１５８】
そして、入力された情報を元に、需要予測／回答システム４は、スワップリクエストデータを生成する。客先担当者マスタをもとに依頼先の担当営業者へリクエスト情報を例えばメール等で自動配信する（ステップＳ１００９）。
【０１５９】
依頼先の担当営業者はメールの内容を確認後、需要予測／回答システム４の出荷枠スワップ認証画面より承認を入力し（ステップＳ１０１０）、需要予測／回答システム４内にある客先別の出荷枠について依頼元から依頼先へ在庫付け替えを行う（ステップＳ１０１１）。
【０１６０】
図１８は、在庫融通後の出荷枠を交換（スワップ）する顧客別出荷枠融通の説明図である。
【０１６１】
顧客別在庫は、基本的にごく少量であり、ＳＯの裏付けがあるものだけとなっている。一方的に融通して欲しいという要求に対してはＮＧとなる場合が多い。在庫を融通するか否かを決める条件としては、いつ返してくれるかが重要な判断材料となる。
【０１６２】
よって、ある顧客Ａの在庫を顧客Ｂに融通する場合で考えると、図１８に示すように、（１）顧客Ａの在庫を顧客Ｂに切り換える、（２）顧客Ｂの出荷枠を顧客Ａに切り換える、という２つの処理が必要となる。
【０１６３】
上記した（２）の通り、同じ型名で顧客Ｂの持っている出荷枠を同じ週で顧客Ａへ切り換える。製造から見た場合、影響はないので、販売同士の合意が成立していれば、無条件で認められるべき内容である。そこで、同じ型名の同じ週での出荷枠交換については販売の意志で行うことができることになる。
【０１６４】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【０１６５】
本発明は、半導体装置における在庫管理、出荷作業、および伝票処理の効率化に適している。
【図面の簡単な説明】
【０１６６】
【図１】本発明の一実施の形態による製品流通管理システムの構成を示すブロック図である。
【図２】図１の製品流通管理システムによるパターン１における伝票処理の簡素化処理例を示すフローチャートである。
【図３】図１の製品流通管理システムによるパターン２における伝票処理の簡素化処理の一例を示すフローチャートである。
【図４】図１の製品流通管理システムによるパターン３における伝票処理の簡素化処理例を示すフローチャートである。
【図５】図１の製品流通管理システムによる本社の伝票処理における説明図である。
【図６】図１の製品流通管理システムによる販社の伝票処理における説明図である。
【図７】図１の製品流通管理システムによる流通在庫の削減の一例を示すフローチャートである。
【図８】図１の製品流通管理システムによる本社在庫での在庫管理の概要を示す説明図である。
【図９】図７のステップＳ４１７の処理における自動出荷の説明図である。
【図１０】図１の製品流通管理システムによるＣＯの出荷の一例を示す説明図である。
【図１１】図１の製品流通管理システムによるパターン１における製品の出荷業務の効率化の例を示すフローチャートである。
【図１２】図１の製品流通管理システムによるパターン２における製品の出荷業務の効率化の例を示すフローチャートである。
【図１３】図１の製品流通管理システムによるパターン３における製品の出荷業務の効率化の例を示すフローチャートである。
【図１４】図１の製品流通管理システムによる顧客別論理在庫の出荷手順を示した説明図である。
【図１５】図１の製品流通管理システムによる在庫・仕掛かりの最適配分の処理例を示すフローチャートである。
【図１６】図１の製品流通管理システムによる販社管理在庫の顧客間融通の一例を示すフローチャートである。
【図１７】図１の製品流通管理システムによる販社管理在庫と出荷枠の顧客間融通の処理例を示すフローチャートである。
【図１８】図１の製品流通管理システムによる在庫融通後の出荷枠を交換する顧客別出荷枠融通の説明図である。
【符号の説明】
【０１６７】
１  製品流通管理システム
２  受注／出荷部
３  需要予測／納期回答部
４  需要予測／回答システム
５  販社在庫管理システム
６  販社受発注／出荷システム
７  販社倉庫管理システム
８  本社在庫管理システム
９  本社受発注／出荷システム
１０  本社倉庫管理システム
１１  需給調整システム
１２  生産指示／回答システム
１３  仕掛かり管理システム
【図１】
2009193389.tif 000003
【図２】
2009193389.tif 000004
【図３】
2009193389.tif 000005
【図４】
2009193389.tif 000006
【図５】
2009193389.tif 000007
【図６】
2009193389.tif 000008
【図７】
2009193389.tif 000009
【図８】
2009193389.tif 000010
【図９】
2009193389.tif 000011
【図１０】
2009193389.tif 000012
【図１１】
2009193389.tif 000013
【図１２】
2009193389.tif 000014
【図１３】
2009193389.tif 000015
【図１４】
2009193389.tif 000016
【図１５】
2009193389.tif 000017
【図１６】
2009193389.tif 000018
【図１７】
2009193389.tif 000019
【図１８】
2009193389.tif 000020