(57)【特許請求の範囲】
【請求項１】
商品の出荷先である買手側との商談によって決定された、該買手側での第１の商品コード体系に従った第１のコードによって示される商品の情報を含む商談情報に基づいて、該第１のコードによって示される商品に対して、在庫商品から対応する商品を引き当てる売手側の商品管理装置であって、
上記在庫商品の情報を上記売手側での第２の商品コード体系に従った第２のコードに対応させて記憶する在庫情報記憶手段と、
上記商談情報の上記第１のコードによって示される商品に対応する商品として選択された複数種類の在庫商品を示す複数の上記第２のコードを、上記第１のコードに対応付けて記憶する商談情報記憶手段と、
上記在庫情報記憶手段に記憶された在庫商品情報に基づいて、上記商談情報記憶手段に記憶された商談情報の上記第１のコードによって示される商品に対して、上記第１のコードに対応付けられた上記複数の第２のコードによって示される複数種類の在庫商品を、所定順で引き当てる商品引当手段とを備えることを特徴とする商品管理装置。
【請求項２】
上記所定順は、上記複数の第２のコードにそれぞれ付加された優先度の順を含むことを特徴とする請求項１記載の商品管理装置。
【請求項３】
上記商品引当手段は、上記買手側から上記第２のコードによって示される商品の本発注要求が発行された時に、該本発注要求に対応する上記商談情報記憶手段に記憶された商談情報について、上記の処理を実行することを特徴とする請求項１記載の商品管理装置。
【請求項４】
上記商品は、有効期限が限られており、上記買手側に対する供給可能量が予め決定されてた商品を含むことを特徴とする請求項１記載の商品管理装置。
【請求項５】
上記買手側に対して供給可能な商品の情報を上記第２のコードに対応させて記憶する供給可能情報記憶手段と、
所定期間内に上記商談情報記憶手段に記憶された複数の商談情報の引当処理順を、該商談情報に含まれる商品情報に基づいて決定する第１の決定手段と、
上記第１の決定手段により決定された処理順に従って、対象商談情報に対応付けられた上記複数の第２のコードの引当処理順を、上記供給可能情報記憶手段に記憶された供給可能商品情報に基づいて決定する第２の決定手段とを備えることを特徴とする請求項１記載の商品管理装置。
【請求項６】
上記供給可能商品情報は、商品の原価情報を含み、
上記商談情報の商品情報は、上記買手側との取引単価を含むことを特徴とする請求項５記載の商品管理装置。
【請求項７】
第１の商品コード体系に従った第１のコードによって商品を管理する買手側と、第２の商品コード体系に従った第２のコードによって商品を管理する売手側とを含む商品管理システムであって、
上記売手側は、請求項１〜６の何れかに記載の商品管理装置の機能を有することを特徴とする商品管理システム。
【請求項８】
第１の商品コード体系に従った第１のコードによって商品管理を行う買手側に対して供給する商品の管理を、第２の商品コード体系に従った第２のコードによって行うための売手側の商品管理方法であって、
在庫商品の情報を上記第２のコードに対応させて在庫情報メモリに記憶する在庫情報記憶ステップと、
上記買手側との商談によって決定された上記第１のコードによって示される商品の情報を含む商談情報を、その商品に対応する商品として選択された複数種類の在庫商品を示す複数の上記第２のコードと共に対応付けて商談情報メモリに記憶する商談情報記憶ステップと、
上記在庫情報メモリに記憶された在庫商品情報に基づいて、上記商談情報メモリに記憶された商談情報の上記第１のコードによって示される商品に対して、上記第１のコードに対応付けられた上記複数の第２のコードによって示される複数種類の在庫商品を、所定順で引き当てる商品引当ステップとを含むことを特徴とする商品管理方法。
【請求項９】
上記商品引当ステップは、上記所定順を、上記複数の第２のコードにそれぞれ付加された優先度の順として、上記引当処理を実行するステップを含むことを特徴とする請求項８記載の商品管理方法。
【請求項１０】
上記商品引当ステップは、上記買手側から上記第２のコードによって示される商品の本発注要求が発行された時に、該本発注要求に対応する上記商談情報メモリに記憶された商談情報について、上記の処理を実行するステップを含むことを特徴とする請求項８記載の商品管理方法。
【請求項１１】
上記商品は、有効期限が限られており、上記買手側に対する供給可能量が予め決定されてた商品を含むことを特徴とする請求項８記載の商品管理方法。
【請求項１２】
上記買手側に対して供給可能な商品の情報を上記第２のコードに対応させて供給可能情報メモリに記憶する供給可能情報記憶ステップと、所定期間内に上記商談情報記憶メモリに記憶された複数の商談情報の引当処理順を、該商談情報に含まれる商品情報に基づいて決定する第１の決定ステップと、
上記第１の決定ステップにより決定された処理順に従って、対象商談情報に対応付けられた上記複数の第２のコードの引当処理順を、上記供給可能情報メモリに記憶された供給可能商品情報に基づいて決定する第２の決定ステップとを含むことを特徴とする請求項８記載の商品管理方法。
【請求項１３】
上記供給可能商品情報は、商品の原価情報を含み、
上記商談情報の商品情報は、上記買手側との取引単価を含むことを特徴とする請求項１２記載の商品管理方法。
【請求項１４】
請求項８〜１３の何れかに記載の商品管理方法の処理ステップを、コンピュータが読み出し可能に格納したことを特徴とする記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えば、野菜や精肉等の生鮮品、航空チケット、コンサートチケットのように、有効期限が限られており且つ供給量が予め決まっている商品を管理するために用いられる商品管理装置、商品管理システム、商品管理方法、及びそれを実施するための処理ステップをコンピュータが読出可能に格納した記憶媒体に関するものである。
【０００２】
【従来の技術】
例えば、スーパーマーケット等の小売業者側では様々な商品が販売されているが、それらの商品の中の生鮮品として、”精肉”に着目してみる。
図７は、野菜や豆腐、魚介類、精肉等の生鮮商品が陳列される陳列棚において、精肉用の陳列棚の棚割の様子を具体的に示したものである。この図７に示すように、まず、「牛肉」や「豚肉」、「鶏肉」といった品目に対してそれぞれ棚割される。「牛肉」用棚では、「国産物」と「輸入物」で棚割され、さらに「国産物」の棚において「和牛」と「一般牛」で棚割される。そして、「和牛」と「一般牛」のそれぞれの棚に、モモやヒレといった部位毎の精肉が陳列される。他の「豚肉」や「鶏肉」等についても、上記の「牛肉」の場合と同様にして棚割されて精肉が陳列される。
【０００３】
上述のようにして各種の精肉を陳列して販売する小売業者は、精肉を取り扱うメーカとの商談を行うことによって、希望する精肉を該メーカから仕入れることになる。
【０００４】
ここで、メーカ側（以下、「売手側」と言う）では、小売業者側（以下、「買手側」と言う）での精肉の分類（上記図７参照）に対して、精肉の分類がさらに細かくなされている。具体的には、買手側で言う”牛肉−国産−和牛−モモ肉”に対して、さらに細かく、産地や飼育に使用した穀物や、輸入物である場合には国名やブランド名等（以下、これらの情報を「品質情報」と言う）の違いによって、モモ肉Ａ，モモ肉Ｂ，モモ肉Ｃ，・・・で分類されている。
したがって、例えば、図２に示すように、買手側と売手側とで、”牛肉−国産−和牛−モモ肉”の商品を単価Ｘ円で取引する場合、売手側は、それに対応する商品（買手側の意に添うようなモモ肉）を、モモ肉Ａ，モモ肉Ｂ，モモ肉Ｃ，・・・の中から選択して（ここでは、上記図８の黒矢印で示す”モモ肉Ｃ”を選択）、それを買手側に供給（出荷）することになる。
【０００５】
また、売手側における買手側に対する供給単位（出荷単位）は、１Ｋｇグラム相当の精肉のブロックが１０個詰められた段ボールといった、ボックス単位となる。例えば、買手側が、”牛肉−国産−和牛−モモ肉”を５００Ｋｇ希望した場合、売手側は、１Ｋｇ相当のモモ肉ブロック１０個からなる１ボックス（１０Ｋｇ相当のモモ肉）を５０箱（５０ボックス）で、買手側との商談を進める。
尚、精算については、正確なグラム数単位でなされる。また、売手側が海外との取り引きによって精肉を輸入する場合等にも、上記のボックス単位で取り引きがなされる。
【０００６】
また、このとき、当該商談と同様の商談（売手側の他の商談担当者による他の買手側との商談）が別の場所で同時に行われ、そこで同じモモ肉Ｃが他の買手側に割り当てられることで、当該商談での買手側に対して、上述のようにして選択したモモ肉Ｃを供給できなくなる場合も考えられる。これは、モモ肉Ｃについての供給総量が予め決まっているためである。そこで、売手側は、このような場合に対応するために、モモ肉Ｃの他に、それと同等の品質を有するモモ肉Ｄ及びＥ（上記図８中の白抜矢印参照）をも選択する。
したがって、この場合、売手側は、買手側が要求した商品（”牛肉−国産−和牛−モモ肉”、単価Ｘ円、Ｙボックス）に対して、モモ肉Ｃ、Ｄ、及びＥで商談を進めることになる。そして、この商談がまとまると、売手側は、買手側から指定された期日に、モモ肉Ｃ、Ｄ、及びＥの在庫量を確認し、それらのモモ肉Ｃ、Ｄ、及びＥのうちの何れかを買手側に供給する。
【０００７】
上述のような売手側と買手側間の商談は、ある一定期間のサイクル（以下、商談サイクル」と言う）で行われる。
具体的には、例えば、買手側（スーパーマーケット等）では、消費者への販売形態としてのいわゆるセールが行われる場合が多々ある。この場合、買手側は、セール期間中は消費者に対して低価格で精肉を提供することになるため、その分単価の安い精肉を売手側に希望することになる。また、他の販売形態として、高級な精肉を揃えて販売する場合もある。この場合、買手側は、高価格ではあるがその分高品質な精肉を消費者に提供することになるため、それに相当した高品質な精肉を売手側に希望することになる。このように、買手側における精肉の単価（消費者に対する販売単価）は、常に一定したものではなく、その時々の販売形態等によって変動するものである。そこで、これに対応するために、売手側と買手側間の商談に商談サイクルが設けられている。したがって、買手側は、売手側との商談の度に、次の商談サイクル期間内に行う予定の販売形態（セール等）を考慮しながら、それに対応する精肉を売手側に希望することなる。
【０００８】
【発明が解決しようとする課題】
ところで、上述したような買手側（スーパーマーケット等）では、売手側（メーカ側）に対する商品発注や在庫管理等のコンピュータ化により、精肉等の生鮮品、工業製品、及び菓子類等の様々な商品の全てに対して、それぞれ対応するバーコード（商品コード）を付加することが行われている。これにより、買手側は、それぞれの商品毎の売れ行き状態を直ぐに把握することができ、この結果欠品が出そうになれば、その商品を直ぐに売手側（メーカ側）に追加注文できるというように、商品の発注管理や在庫管理を容易に行うことができる。
【０００９】
一方、様々な商品を買手側（スーパーマーケット等）に供給する売手側（メーカ）、特に、上述したような精肉等の商品を取り扱う売手側では、買手側からの商品受注や、商品の在庫管理等がコンピュータ化されておらず、人間の手作業によって行われている。これは、次のような理由による。
【００１０】
まず、工業製品や、袋詰め或いは箱詰めされた菓子類のような商品は、買手側での商品と売手側での商品で一対一で対応している。すなわち、買手側で言う”ＡＡＡ”という商品（具体的には”ＡＡＡ”とネーミングされた菓子）は、売手側においても”ＡＡＡ”という商品そのものを示す。このような商品については、商品コードとして、比較的どの買手側（スーパーマーケット等）でも同様のものが用いられる。
したがって、例えば、買手側と売手側で商品コードを統一し、買手側が売手側に対して商品の注文を行う際にも、その商品コードを用いるようにすれば、買手側と売手側の間では、共通の商品コードによって商品の発注や受注が行われることになるため、買手側と売手側のそれぞれで商品管理を容易にできる、ということが考えられる。
【００１１】
しかしながら、精肉等の商品は、上述したような工業製品や菓子類のような商品に対して、買手側での商品と売手側での商品で一対一で対応してわけではない。具体的には、上記図８に示したように、買手側（スーパーマーケット等）での”牛肉−国産−和牛−モモ肉”といった１つの商品に対して、売手側（メーカ側）ではこれを品質情報によってさらに細かく分類したモモ肉Ａ，モモ肉Ｂ，モモ肉Ｃ，・・・といったｎ個の商品に対応している。すなわち、買手側での商品と売手側での商品は、１：ｎの関係にある。
これは、買手側での分類は、消費者のニーズに対応できれば十分であるが（一般消費者にとっては、飼育に使用した穀物が何であるか等を示す品質情報までの分類はあまり必要ない）、これに対して売手側の分類は、商品の出荷先はスーパーマーケットに限らず、様々な業種の買手側（加工工場やレストラン等）があり、それに対応するために、上記の品質情報までの分類が必要となってくるからである。
このように、買手側と売手側の分類形態が全く異なる商品について、例えば、上述した工業製品や菓子類等の商品と同様にして買手側と売手側で商品コードを統一しようとすると、商品コードを売手側の分類に対応させた場合、買手側では使用しない無駄な商品コードが多数存在してしまうという問題が生じてしまう。これとは逆に、商品コードを買手側の分類に対応させた場合、売手側では該売手側での商品（細かく分類された商品）に対応できないという問題が生じてしまう。
したがって、精肉等の商品については、買手側と売手側で商品コードを統一化することは非常に困難である。
【００１２】
上述したような理由から、特に、買手側での商品に対する分類と、売手側での商品に対する分類とが、１：ｎの関係であるような商品（精肉等）については、その商品を取り扱う売手側において、商品受注や在庫管理等の商品管理が未だ人間の手作業によって行われているのが現状である。これは非常に効率的ではない。
【００１３】
そこで、本発明は、上記の欠点を除去するために成されたもので、精肉等の生鮮品や航空チケットのように、有効期限が限られており且つ供給量が予め決まっている商品であっても、その商品管理を、売手側と買手側のそれぞれで容易に且つ効率的に行うことが可能な、商品管理装置、商品管理システム、商品管理方法、及びそれを実施するための処理ステップをコンピュータが読出可能に格納した記憶媒体を提供することを目的とする。
【００１４】
【課題を解決するための手段】
斯かる目的下において、第１の発明は、商品の出荷先である買手側との商談によって決定された、該買手側での第１の商品コード体系に従った第１のコードによって示される商品の情報を含む商談情報に基づいて、該第１のコードによって示される商品に対して、在庫商品から対応する商品を引き当てる売手側の商品管理装置であって、上記在庫商品の情報を上記売手側での第２の商品コード体系に従った第２のコードに対応させて記憶する在庫情報記憶手段と、上記商談情報の上記第１のコードによって示される商品に対応する商品として選択された複数種類の在庫商品を示す複数の上記第２のコードを、上記第１のコードに対応付けて記憶する商談情報記憶手段と、上記在庫情報記憶手段に記憶された在庫商品情報に基づいて、上記商談情報記憶手段に記憶された商談情報の上記第１のコードによって示される商品に対して、上記第１のコードに対応付けられた上記複数の第２のコードによって示される複数種類の在庫商品を、所定順で引き当てる商品引当手段とを備えることを特徴とする。
【００１５】
第２の発明は、上記第１の発明において、上記所定順は、上記複数の第２のコードにそれぞれ付加された優先度の順を含むことを特徴とする。
【００１６】
第３の発明は、上記第１の発明において、上記商品引当手段は、上記買手側から上記第２のコードによって示される商品の本発注要求が発行された時に、該本発注要求に対応する上記商談情報記憶手段に記憶された商談情報について、上記の処理を実行することを特徴とする。
【００１７】
第４の発明は、上記第１の発明において、上記商品は、有効期限が限られており、上記買手側に対する供給可能量が予め決定されてた商品を含むことを特徴とする。
【００１８】
第５の発明は、上記第１の発明において、上記買手側に対して供給可能な商品の情報を上記第２のコードに対応させて記憶する供給可能情報記憶手段と、所定期間内に上記商談情報記憶手段に記憶された複数の商談情報の引当処理順を、該商談情報に含まれる商品情報に基づいて決定する第１の決定手段と、上記第１の決定手段により決定された処理順に従って、対象商談情報に対応付けられた上記複数の第２のコードの引当処理順を、上記供給可能情報記憶手段に記憶された供給可能商品情報に基づいて決定する第２の決定手段とを備えることを特徴とする。
【００１９】
第６の発明は、上記第５の発明において、上記供給可能商品情報は、商品の原価情報を含み、上記商談情報の商品情報は、上記買手側との取引単価を含むことを特徴とする。
【００２０】
第７の発明は、第１の商品コード体系に従った第１のコードによって商品を管理する買手側と、第２の商品コード体系に従った第２のコードによって商品を管理する売手側とを含む商品管理システムであって、上記売手側は、請求項１〜６の何れかに記載の商品管理装置の機能を有することを特徴とする。
【００２１】
第８の発明は、第１の商品コード体系に従った第１のコードによって商品管理を行う買手側に対して供給する商品の管理を、第２の商品コード体系に従った第２のコードによって行うための売手側の商品管理方法であって、在庫商品の情報を上記第２のコードに対応させて在庫情報メモリに記憶する在庫情報記憶ステップと、上記買手側との商談によって決定された上記第１のコードによって示される商品の情報を含む商談情報を、その商品に対応する商品として選択された複数種類の在庫商品を示す複数の上記第２のコードと共に対応付けて商談情報メモリに記憶する商談情報記憶ステップと、上記在庫情報メモリに記憶された在庫商品情報に基づいて、上記商談情報メモリに記憶された商談情報の上記第１のコードによって示される商品に対して、上記第１のコードに対応付けられた上記複数の第２のコードによって示される複数種類の在庫商品を、所定順で引き当てる商品引当ステップとを含むことを特徴とする。
【００２２】
第９の発明は、上記第８の発明において、上記商品引当ステップは、上記所定順を、上記複数の第２のコードにそれぞれ付加された優先度の順として、上記引当処理を実行するステップを含むことを特徴とする。
【００２３】
第１０の発明は、上記第８の発明において、上記商品引当ステップは、上記買手側から上記第２のコードによって示される商品の本発注要求が発行された時に、該本発注要求に対応する上記商談情報メモリに記憶された商談情報について、上記の処理を実行するステップを含むことを特徴とする。
【００２４】
第１１の発明は、上記第８の発明において、上記商品は、有効期限が限られており、上記買手側に対する供給可能量が予め決定されてた商品を含むことを特徴とする。
【００２５】
第１２の発明は、上記第８の発明において、上記買手側に対して供給可能な商品の情報を上記第２のコードに対応させて供給可能情報メモリに記憶する供給可能情報記憶ステップと、所定期間内に上記商談情報記憶メモリに記憶された複数の商談情報の引当処理順を、該商談情報に含まれる商品情報に基づいて決定する第１の決定ステップと、上記第１の決定ステップにより決定された処理順に従って、対象商談情報に対応付けられた上記複数の第２のコードの引当処理順を、上記供給可能情報メモリに記憶された供給可能商品情報に基づいて決定する第２の決定ステップとを含むことを特徴とする。
【００２６】
第１３の発明は、上記第１２の発明において、上記供給可能商品情報は、商品の原価情報を含み、上記商談情報の商品情報は、上記買手側との取引単価を含むことを特徴とする。
【００２７】
第１４の発明は、請求項８〜１３の何れかに記載の商品管理方法の処理ステップを、コンピュータが読み出し可能に格納した記憶媒体であることを特徴とする。
【００２８】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００２９】
（第１の実施の形態）
本発明は、例えば、図１に示すような商品管理システム１０に適用される。
この商品管理システム１０は、スーパーマーケット等の小売店を含む複数の買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・を取引先とする売手側（メーカ側）３００において、商品（ここでは”精肉”とする）の受注管理や在庫管理等の商品管理を電子的に行うようになされている。このため、売手側３００には、商品管理用の端末装置が設けられており、該端末装置（以下、説明の簡単のために該端末装置を含めて「売手側３００」と言う）は、詳細は後述する商談データ３１１、在庫量データ３１２、及び供給可能量データ３１３が保存されるデータベース（ＤＢ）メモリ３１０と、商品管理処理部３２０とを含んでなる。
【００３０】
ここで、まず、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・では、買手側専用の商品コード体系に従って、消費者へ提供する様々な商品に対してそれぞれ対応する商品モードを持たせている。例えば、上記図８に示したような棚割に対応した商品の分類（消費者のニーズに応じた分類等）に従って、”牛肉−国産−和牛−モモ肉”には「ＡＢＣ００１」の商品コードを対応させ、”牛肉−国産−和牛−ヒレ肉”には「ＡＢＣ００３」の商品コードを対応させている。このような商品コード体系によって、商品の発注管理や在庫管理等の商品管理を行うようになされている。
【００３１】
一方、売手側３００では、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・での商品コード体系とは異なる売手側専用のコード体系に従って、買手側での商品の分類をさらに細かく分類した商品に対してそれぞれ対応する商品コードを持たせている。例えば、上記図７に示したような品質情報（飼育に使用した穀物の種類等の情報）の違いによって、”牛肉−国産−和牛−モモ肉”という商品をさらに細かくモモ肉Ａ、モモ肉Ｂ、モモ肉Ｃ、・・・というように分類し、これらのモモ肉Ａ、モモ肉Ｂ、モモ肉Ｃ、・・・の商品に対して、「ＲＲ０Ａ」、「ＲＲ０Ｂ」、「ＲＲ０Ｃ」、・・・といった商品コードを対応させている。
このような商品コード体系によって、売手側３００においても買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・と同様に、商品の受注管理や在庫管理等の商品管理を行うようになされている。
【００３２】
このため、売手側３００の商品管理処理部３２０は、ＤＢメモリ３１０内の情報を参照しながら、種々の商品管理のための処理を実行する。特に、商品管理処理部３２０は、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・のそれぞれで用いられている商品コードを、売手側３００にて用いている商品コードに対応付けする機能（コード変換機能）を有している。これにより、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・での商品コード体系と、売手側３００での商品コード体系とが異なる場合であっても、すなわち買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・での商品に対する分類と、売手側３００での商品に対する分類とが１：ｎの関係であっても、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・は自側専用の商品コードを用いて商品管理を行い、売手側３００も同様に自側専用の商品コードを用いて商品管理を行うことができるようになされている。
尚、商品管理処理部３２０は、例えば、ＣＰＵから構成されており、該ＣＰＵが予め用意された処理プログラムを実行することで、商品管理処理部３２０の後述する各種処理機能が実施される。
【００３３】
ＤＢメモリ３１０には、「ＲＲ０Ａ」、「ＲＲ０Ｂ」、「ＲＲ０Ｃ」、・・・といった商品コードに対応した各商品の在庫量の情報（在庫量データ）３１２が保存されており、この在庫量データ３１２の内容は、商品出荷時の出荷量等に従って更新されるようになされている。
また、精肉等の商品については、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・に対して供給できる商品の総量（供給可能量）が予め決まっているため、ＤＢメモリ３１０には、上記の商品コードに対応した各商品の供給可能量データ３１３が保存されている。
さらに、ＤＢメモリ３１０には、売手側３００と、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・との商談によって発生した商談データ（Ａ），（Ｂ），（Ｃ），・・・（以下、これらをまとめて「商談データ３１２」とも言う）をも保存されるようになされている。
【００３４】
以下、上述のような商品管理システム１０において、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・と、売手側３００との間での、商品（精肉）の商談から出荷までの流れについて具体的に説明する。
【００３５】
上記図１に示すように、先ず、売手側３００の担当者３３０は、上述した商談サイクル（２週間や１ヶ月等）に従って、例えば、買手側１００（Ａ）へ出向き、そこの担当者１０１（Ａ）と商談を行う。この商談の結果、決定した内容は、売手側３００の担当者３３０の端末装置（ノート型パーソナルコンピュータ等）３１２に入力される。
【００３６】
図２は、端末装置３４０の商談結果入力画面を示したものである。このような商談結果入力画面上にて、売手側３００の担当者３３０は、上記の商談にて決定した内容を入力することになる。
【００３７】
具体的には、先ず、”顧客コード”及び”顧客名”を入力する。このとき、”顧客コード”を入力すればそれに対応する”顧客名”が自動的に表示されるようにしても良い。
次に、”販売期間”を入力する。この”販売期間”とは、買手側１００（Ａ）が当該商談にて決定（契約）した商品（精肉）を実際に販売する期間を示す。
次に、買手側１００（Ａ）が希望した”商品名”、”商品コード”、”量”、及び”単価”を入力する。ここでの”商品コード”は、買手側１００（Ａ）での商品コード体系に従った商品コードを示す。また、”量”に設定される値は、商談時の仮の量（”販売期間”に設定された期間中に買手側１００（Ａ）が販売する予定である仮の量）である。
【００３８】
そこで、例えば、買手側１００（Ａ）との取引する商品が、
”商品名”    ＝「牛肉−国産−和牛−モモ肉」、
”商品コード”＝「ＡＢＣ００１」、
”量”        ＝「１００」（Ｋｇ）、
”単価”      ＝「５００」（円）
であるとする。
この場合、売手側３００の担当者３３０は、自側で取り扱っている牛肉−国産−和牛−モモ肉がさらに細かく分類されたモモ肉Ａ，モモ肉Ｂ，モモ肉Ｃ，・・・の中から、買手側１００（Ａ）の希望した上記の商品に対応する商品（買手側の意に添うようなモモ肉）を選択する。例えば、モモ肉Ａを選択し、それに対応する”商品コード”を入力する。ここでの”商品コード”は、売手側３００での商品コード体系に従った商品コードを示す。また、他の商談の結果によってモモ肉Ａを買手側１００（Ａ）に割り当てられない場合を考慮して、モモ肉Ａと同等の他の商品を２つ選択する。例えば、モモ肉Ｄ及びＥを選択し、それに対応する”商品コード”を入力する。したがって、商談結果入力画面の取引商品（１）〜（３）の項目には、モモ肉Ａ、Ｄ、及びＥといった売手側３００での商品が優先順に入力されることになる。
【００３９】
尚、”取引商品（１）〜（３）”の括弧内の値は優先度に対応しており、取引商品（１）の商品が一番優先度が高く、取引商品（２）、（３）の順に優先度が低くなるものとする。また、ここでは選択する取引商品を３つとしたが、この数に限られることはない。
【００４０】
上述のようにして、売手側３００の担当者３３０によって端末装置３４０に入力されたデータ（商談データ（Ａ））は、物流センタ２００を介して、売手側３００のＤＢメモリ３１０に商談データ３１１として保存される。このときの保存は、管理担当者等の端末装置上の操作によるものであってもよいし、ネットワークを介した通信によるもの（直接端末装置３４０から売手側３００のＤＢメモリ３１０に対して送信する等）であってもよい。
また、他の買手側１００（Ｂ），１００（Ｃ），・・・についても、上述した買手側１００（Ａ）と同様にして、売手側３００との商談が行われ、その結果（商談データ（Ｂ），（Ｃ），・・・）が売手側３００のＤＢメモリ３１０に商談データ３１１として保存される。
したがって、売手側３００のＤＢメモリ３１０の商談データ３１１としては、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・のそれぞれについての商談データ（Ａ），（Ｂ），（Ｃ），・・・が存在することになる。
【００４１】
次に、売手側３００と、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・との商談の後、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・から売手側３００に対して、本発注要求が発行される（上記図１の点線矢印参照）。この本発注要求の発行は、商談にて希望した販売期間（具体的には販売日）の前日等に、ＥＯＳ（エレクトリックオーダーシステム：電子発注システム）やファクシミリ（ＦＡＸ）等を用いて行われる。
例えば、買手側１００（Ａ）は、商談の後、実際の販売日の前日に、該商談にて用いた”顧客コード”及び”販売期間”（売手側３００の担当者３３０によって端末装置３４０に入力された”顧客コード”及び”販売期間”）を用いて、本発注要求を物流センタ２００を介して売手側３００に対して発行する。この本発注要求には、商談にて希望した各商品それぞれに対する、実際に入荷希望する”量”（以下、「実発注量」と言う）の情報をも含まれている。したがって、このときの実発注量分の商品が、売手側３００から買手側１００（Ａ）に対して実際に出荷されることになる。
【００４２】
上述のような本発注要求が売手側３００に対して発行されると、売手側３００の商品管理処理部３２０は、例えば、図３に示すフローチャートに従って、次のように動作する。
【００４３】
ステップＳ４００：
商品管理処理部３２０には、物流センタ２００を介して、ある買手側（ここでは買手側１００（Ａ）とする）からの本発注要求を受け取る。この本発注要求には、上述したように、”顧客コード”及び”販売期間”と共に、それぞれの商品に対する実際に入荷希望する実発注量の情報も含まれている。
【００４４】
ステップＳ４０１：
そこで、先ず、商品管理処理部３２０は、上記の本発注要求に含まれる”顧客コード”及び”販売期間”に基づいて、それに該当する商談データ（Ｘ）をＤＢメモリ３１０から取得する。
ここでは、例えば、図４に示すような、買手側１００（Ａ）についての商談データ（Ａ）が取得されるものとする。また、この商談データ（Ａ）は、上記図２や図４に示すように、買手側１００（Ａ）が希望した牛モモ肉や牛ヒレ肉といった複数の商品についてのデータ（商品データ）（Ａ−１），（Ａ−２），・・・から構成されるものとする。
【００４５】
ステップＳ４０２：
次に、商品管理処理部３２０は、処理カウンタ（内部カウンタ）Ｃ１を初期化する（Ｃ１＝１）。
この処理カウンタＣ１は、ステップＳ４０１にて取得した商談データ（Ａ）を構成する商品データ（Ａ−１），（Ａ−２），・・・の全てについて、本ステップ以降の処理を実行するために設けられたものである。
【００４６】
ステップＳ４０３：
次に、商品管理処理部３２０は、ステップＳ４０１にて取得した商談データ（Ａ）から、処理カウンタＣ１にて示される商品データ（Ａ−Ｃ１）を取得する。処理カウンタＣ１＝”１”とすれば、上記図４に示すように、
”希望商品”      ＝「ＡＢＣ００１」
（牛肉−国産−和牛−モモ肉）、
”量”            ＝「１００」、
”単価”          ＝「５００」、
”引当商品（１）”＝「ＲＲ０Ａ」（モモ肉Ａ）、
”引当商品（２）”＝「ＲＲ０Ｄ」（モモ肉Ｄ）、
”引当商品（３）”＝「ＲＲ０Ｅ」（モモ肉Ｅ）、
なる情報を含む商品データ（Ａ−１）が取得されることになる。
【００４７】
ステップＳ４０４：
次に、商品管理処理部３２０は、処理カウンタＣ２（内部カウンタ）を初期化（Ｃ２＝１）する。
この処理カウンタＣ２は、”引当商品（１）〜（３）”の商品コード（売手側３００の商品コード）にて示される商品の在庫を、優先順位の高いものから調べるために、すなわち”引当商品（１）”、”引当商品（２）”、”引当商品（３）”の順に調べるために設けられたものである。
【００４８】
ステップＳ４０５：
次に、商品管理処理部３２０は、ステップＳ４０３にて取得した商品データ（Ａ−Ｃ１）において、処理カウンタＣ２にて示される”取引商品（Ｃ２）”に設定されている商品コードを取得する。そして、その商品コードに対応する商品の在庫量を、ＤＢメモリ３１０の在庫データ３１２から取得する。
処理カウンタＣ２＝”１”とすれば、上記図４に示すように、”引当商品（１）”に設定されている商品コード「ＲＲ０Ａ」に対応した商品の”在庫量”＝「５０」が取得されることになる。
【００４９】
ステップＳ４０６：
次に、商品管理処理部３２０は、上記の本発注要求に含まれる実発注量と、ステップＳ４０５にて取得した在庫量とを比較し、実発注量が在庫量以下であるか否かを判別する。  この判別の結果、「実発注量≦在庫量」である場合にはステップＳ４０７からの処理を実行し、そうでない場合にはステップＳ４１１からの処理を実行する。
【００５０】
ステップＳ４０７：
ステップＳ４０６の判別の結果、「実発注量≦在庫量」であった場合、商品管理処理部３２０は、現在処理対象となっている商品データ（Ａ−Ｃ１）に対して、”引当商品（Ｃ２）”に設定されている商品コードに対応する商品を引き当てる。
処理カウンタＣ１＝”１”、処理カウンタＣ２＝”１”とすれば、買手側１００（Ａ）が希望した商品「ＡＢＣ００１」（牛肉−国産−和牛−モモ肉）に対して、優先順位が一番高い売手側３００の商品「ＲＲ０Ａ」（モモ肉Ａ）が引き当てられることになる。
【００５１】
ステップＳ４０８：
その後、商品管理処理部３２０は、ＤＢメモリ３１０の在庫データ３１２の内容を上記の実発注量に従って更新し（在庫量＝在庫量−実発注量）、次の商品データに対して上述したステップＳ４０３からの処理を実行するために、処理カウンタＣ１をカウントアップする（Ｃ１＝Ｃ１＋１）。
【００５２】
ステップＳ４０９：
そして、商品管理処理部３２０は、ステップＳ４０８でのカウントアップの結果、処理カウンタＣ１が商談データ（Ａ）を構成する商品データの総数ｍを越えたか否か、すなわち全ての商品データ（Ａ−１）〜（Ａ−ｍ）に対してのステップＳ４０３からの処理を実行し終えたか否かを判別する。
この判別の結果、処理終了である場合には次のステップＳ４１０に進み、そうでない場合にはステップＳ４０３に戻って以降の処理を繰り返し実行する。
【００５３】
ステップＳ４１０：
商談データ（Ａ）を構成する全ての商品データ（Ａ−１）〜（Ａ−ｍ）に対する処理が終了すると、商品管理処理部３２０は、その処理によって得られた商品データ（Ａ−１）〜（Ａ−ｍ）についての引当情報（ステップＳ４０７での引当結果情報）を、出荷指示情報として出力する。したがって、売手側３００の出荷担当者は、この出荷指示情報に基づいて、該当する商品を買手側１００（Ａ）に対して出荷するための手続きを行うことになる。
【００５４】
ステップＳ４１１：
一方、ステップＳ４０６の判別の結果、「実発注量≦在庫量」でなかった場合、商品管理処理部３２０は、次に優先度の高い引当商品の在庫量を調べるために、処理カウンタＣ２をカウントアップする（Ｃ２＝Ｃ２＋１）。
【００５５】
ステップＳ４１２：
そして、商品管理処理部３２０は、ステップＳ４１１でのカウントアップの結果、処理カウンタＣ２が”３”を越えたか否か、すなわち優先度の一番低い”引当商品（３）”まで在庫量のチェックをし終えたか否かを判別する。
この判別の結果、”引当商品（３）”まで在庫量のチェックをし終えていない場合にはステップＳ４０５に戻って以降の処理を繰り返し実行する。これにより、”取引商品（１）”の商品の在庫量が実発注量に満たない場合には、次に優先度が高い”取引商品（２）”の商品の在庫量がチェックされ、この”取引商品（２）”の商品の在庫量も実発注量に満たない場合には、次に優先度が高い”取引商品（３）”の商品の在庫量がチェックされる、というように、優先度の高い順に順次、売手側３００の該当する商品の在庫量がチェックされることになる。
また、”引当商品（３）”まで在庫量のチェックをし終えた場合、これは、”取引商品（１）〜（３）”に設定されている商品コードにより示される全ての商品の在庫量が、買手側１００（Ａ）が希望した実発注量に満たない場合である。このため、この場合には、その旨を示す情報（エラー情報）を一旦内部的に記憶しておき、ステップＳ４０８〜Ｓ４０９の処理を実行した後のステップＳ４１０の処理にて、上記のエラー情報を出荷指示情報に含ませて出力するようにする。これにより、この場合には、出荷担当者はこの状況を把握して、それに対処するための手続きを行う。
【００５６】
上述のように、本実施の形態では、買手側１００（Ｘ）と売手側３００の商談の結果（商談データ（Ｘ））に含まれる、買手側１００（Ｘ）での商品コード体系（第１の商品コード体系）によって示された商品（「ＡＢＣ００１」にて示される”牛肉−国産−和牛−モモ肉”等）に対して、売手側３００での在庫商品の中から優先度順に複数選択した商品（”モモ肉Ａ、モモ肉Ｂ、モモ肉Ｃ”等の引当商品）を、売手側３００での商品コード体系（第２の商品コード体系）による商品コード（「ＲＲ０Ａ」、「ＲＲ０Ｂ」、「ＲＲ０Ｃ」等）で対応付けてＤＢメモリ３１０に保存する。そして、買手側１００（Ｘ）から第１の商品コード体系による本発注要求が発行されると、ＤＢメモリ３１０に保存されている商談データの中から特定した本発注要求に対応した商談データ（Ｘ）において、第１の商品コード体系によって示された商品に対して、それに対応付けられた第２の商品コード体系によって示された引当商品を優先度順に引き当てる。
これにより、買手側１００（Ｘ）と売手側３００での商品コード体系が異なっていても、売手側３００において、買手側１００（Ｘ）からの本発注要求により示される希望商品（第１の商品コード体系によって示された商品）が、売手側３００における商品（第２の商品コード体系によって示される商品）に自動的に対応付けされるため（第１の商品コード体系が第２の商品コード体系で自動的に認識される、通訳的機能）、従来のように受注管理や在庫管理等の商品管理を手作業で行う必要はない。
【００５７】
（第２の実施の形態）
上述した第１の実施の形態では、買手側１００（Ｘ）と売手側３００の商談時において、売手側３００の担当者３３０が、買手側１００（Ｘ）の希望した商品に該当する売手側３００の商品として、複数の商品（引当商品（１）〜（３））を優先度の高い順に選択するようにした。
これに対して本実施の形態では、上記の複数の引当商品の優先度を、売手側３００の担当者３３０が決定するのではなく、商品管理処理部３２０によって最も有効となるように自動的に決定する。
【００５８】
このため、商品管理処理部３２０は、上記図３に示した本発注要求時の処理を実行する前に、例えば、図５に示すようなフローチャートに従って、次のように動作する。
【００５９】
ステップＳ５００：
ＤＢメモリ３００の商談データ３１１としては、第１の実施の形態にて説明した商談によって発生した、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・についての商談データ（Ａ），（Ｂ），（Ｃ），・・・が保存されているものとする。このときそれぞれの商談データに設定されている”取引商品（１）〜（２）”の商品コードは、任意の順（優先度を意識しない順）で設定されている。
【００６０】
ステップＳ５０１：
そこで、先ず、商品管理処理部３２０は、予め設定された所定期間内にＤＢメモリ３００の商談データ３１１として保存された商談データを、現在保存されている商談データ（Ａ），（Ｂ），（Ｃ），・・・の中から抽出する。
【００６１】
ステップＳ５０２：
ステップＳ５０１での抽出の結果、例えば、図６に示すように、商談データ（Ｂ），（Ｄ），（Ｆ），（Ｈ）が抽出されたものとする。
そこで、商品管理処理部３２０は、商談データ（Ｂ）の商品データ（Ｂ−１），（Ｂ−２），・・・、商談データ（Ｄ）の商品データ（Ｄ−１），（Ｄ−２），・・・、商談データ（Ｆ）の商品データ（Ｆ−１），（Ｆ−２），・・・、及び商談データ（Ｈ）の商品データ（Ｈ−１），（Ｈ−２），・・・を、取引単価の高い商品データ順にソートする。この結果、上記図６では、
取引単価＝”５５０”の（Ｂ−５），
取引単価＝”５３０”の（Ｈ−１），
取引単価＝”４００”の（Ｂ−３），
取引単価＝”３５０”の（Ｄ−２），
取引単価＝”３４０”の（Ｆ−３），
・・・の順に商品データがソート（以下、「ソート▲１▼」と言う）される。
このとき、同じ単価の商品データが存在した場合には、商品データに対して予め付けられた所定の優先度に従って処理を進めるようにする。例えば、ＤＢメモリ３１０に保存された時刻が速い方を優先する。
【００６２】
ステップＳ５０３、ステップＳ５０４：
次に、商品管理処理部３２０は、ステップＳ５０２でのソート▲１▼の順に従って、対象商品データ（Ｘ−ｎ）を取得し（ステップＳ５０３）、その対象商品データ（Ｘ−ｎ）に設定されている”取引商品（１）〜（３）”を、ＤＢメモリ３１０の供給可能量データ３１３を参照することで、原価の安い順にソートする（以下、「ソート▲２▼」と言う）（ステップＳ５０４）。
ここで、供給可能量データ３１３は、上記図６に示すように、上述した在庫量データ３１２と同様に、「ＲＲ０Ａ」、「ＲＲ０Ｂ」、「ＲＲ０Ｃ」、・・・といった売手側３００での商品コードに対応して、それぞれの商品の”原価”及び”供給可能量（可能量）”が設定されてなる。
したがって、例えば、対象となる商品データが最も取引単価が高い商品データ（Ｂ−５）である場合（上記図６参照）、この商品データには”取引商品（１）〜（３）”として商品コード「ＲＲ０Ａ」、「ＲＲ０Ｂ」、及び「ＲＲ０Ｇ」が設定され、これらの原価は「２００」、「２２０」、及び「１９０」であるため、「ＲＲ０Ｇ」，「ＲＲ０Ａ」，「ＲＲ０Ｂ」の順にソートされることになる。
【００６３】
ステップＳ５０５、ステップＳ５０６：
次に、商品管理処理部３２０は、ステップＳ５０４でのソート▲２▼の順に従って、供給可能量データ３１３を参照することで、対象商品コードの”供給可能量”を取得し（ステップＳ５０５）、その供給可能量と、対象商品データ（Ｘ−ｎ）の”量”（仮発注量）とを比較することで、対象商品データ（Ｘ−ｎ）に対して対象商品コードの商品を引き当てることが可能であるか否かを判別する（ステップＳ５０６）。
例えば、対象商品データが（Ｂ−５）であり、対象商品コードが一番原価の安い「ＲＲ０Ｇ」である場合（上記図６参照）、仮発注量（２００）＞供給可能量（１５０）であるため（引当不可）、次の取引商品（２）の供給可能量を調べるためにステップＳ５０５へ戻る。このとき引当可能（仮発注量≦供給可能量）であったならば、次のステップＳ５０７からの処理に進む。
【００６４】
ステップＳ５０７、ステップＳ５０８：
ステップＳ５０６の判別の結果、対象商品データ（Ｘ−ｎ）に対して対象商品コードの商品を引き当てることが可能であった場合、商品管理処理部３２０は、その引当を決定し（ステップＳ５０７）、対象商品コードの”供給可能量”を、対象商品データ（Ｘ−ｎ）の仮発注量に基づいて更新する（供給可能量＝供給可能量−仮発注量）（ステップＳ５０８）。
【００６５】
ステップＳ５０９：
そして、商品管理処理部３２０は、次に処理対象となる商品コードが有るか否かを判別し、有る場合にはステップＳ５０３に戻って以降の処理ステップを繰り返し実行し、無い場合には本処理終了となる。
【００６６】
上述のように、本実施の形態では、所定期間内の各商談データを構成する各商品データにおいて、先ず、それぞれの商品データを取引単価の高い順にソートし、その順に従って、対象商品データ内の取引商品（１）〜（３）により示される商品（売手側３００の商品）を原価の安い順にソートし、その順に従って、対象商品データの仮発注量を満たす商品を該対象商品データに引き当てることを決定する。
これにより、それぞれの商品データを売手側３００にとって有利な順に処理することができ、また、それぞれの商品データ内の取引商品（１）〜（３）についても売手側３００にとって有利な順で、対象商品データに引き当てることができる。すなわち、買手側から本発注要求が発行される前（実際に商品を引き当てる出荷前）に、自動的に、売手側３００にとって最も有利な取引商品（１）〜（３）の優先度を、各商談データの各商品データ毎に持たせることができ、その優先度順で商品の引当を行うことができる。
また、ＤＢメモリ３１０の供給可能量データ３１３によって、事前に買手側からの発注状況（仮発注状況）を把握することもできるため、例えば、今現在どの商品を買手側に対して提供すれば、売手側３００にとって最も有利であるかを事前に把握しておくことができる。これにより、売手側３００の担当者３３０は、そのときの状況に応じて、最も効率的な営業活動を行うことができる。
さらに、残商品を早めに予測することができるため、その残商品に対する販売形態を、最も効率の良い形態に早めに変更することができる。例えば、残商品となった精肉等の商品については、その時点で冷凍されるため、その分価格が下がってしまうが、その予測が事前にできれば、冷凍する前に、冷凍後の価格よりも高い価格で販売することができる。  さらにまた、上述した商談サイクルを速くすることができ、これは売手側にとっても買手側にとっても有利である。
【００６７】
尚、上述した第２の実施の形態の変形例として、例えば、売手側３００の商品コードを原価の高い順にソートし、また、買手側１００（Ａ），１００（Ｂ），・・・についての商談データ（Ａ），（Ｂ），・・・の各商品データを取引単価の高い順にソートして、それらの順に従って、上述したような商品の引当を行うようにしてもよい。
【００６８】
また、上述した第１及び第２の実施の形態においては、本発注要求の発行順に、上記図３に示した処理（商品の引当処理）を実行するようにしたが、これに限られることはなく、例えば、買手側に対して優先度を付け、その優先度に従って処理実行するようにしてもよい。
また、ここでは、対象商品を”精肉”としたが、これに限られることはな。例えば、野菜や精肉等の生鮮品、航空チケット、コンサートチケットのように、有効期限が限られており且つ供給量が予め決まっている商品に対して適用可能である。
【００６９】
また、本発明の目的は、上述した各実施の形態のホスト及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだして実行することによっても、達成されることは言うまでもない。  この場合、記憶媒体から読み出されたプログラムコード自体が各実施の形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することとなる。
プログラムコードを供給するための記憶媒体としては、ＲＯＭ、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード等を用いることができる。
また、コンピュータが読みだしたプログラムコードを実行することにより、各実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって各実施の形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって各実施の形態の機能が実現される場合も含まれることは言うまでもない。
【００７０】
【発明の効果】
以上説明したように本発明では、買手側での商品コード体系と、売手側での商品コード体系が異なる場合であっても、売手側において、買手側での商品コード体系によるコードを、売手側での商品コード体系によるコードに対応付けすることで、売手側での商品管理をコードによって電子的に行えるように構成した。
【００７１】
具体的には例えば、買手側と売手側の商談の結果（商談情報）に含まれる、買手側での第１のコードによって示された商品（「ＡＢＣ００１」にて示される”牛肉−国産−和牛−モモ肉”等の生鮮商品）に対して、売手側での在庫商品の中から優先度順に複数選択した商品（買手側における商品分類に対してさらに細かく分類された”モモ肉Ａ、モモ肉Ｂ、モモ肉Ｃ”等の引当商品）を、売手側での第２のコード（「ＲＲ０Ａ」、「ＲＲ０Ｂ」、「ＲＲ０Ｃ」等）で対応付けて商談情報メモリに保存する。そして、買手側から第１のコードによる本発注要求が発行されると、商談情報メモリに保存されている商談情報の中から特定した本発注要求に対応した商談情報において、第１のコードによって示された商品に対して、それに対応付けられた第２のコードによって示された引当商品を優先度順に引き当てる。
これにより、対象商品が、買手側での”牛肉−国産−和牛−モモ肉”といった１つの商品に対して、売手側ではこれを品質情報（飼育に使用した穀物の情報等）によってさらに細かく分類したモモ肉Ａ，モモ肉Ｂ，モモ肉Ｃ，・・・といったｎ個の商品に対応している商品（１：ｎの関係）であることにより、買手側と売手側で商品コード体系を統一することができなくなくても、売手側において、買手側からの本発注要求により示される希望商品（第１のコードによって示された商品）が、売手側における商品（第２のコードによって示される商品）に自動的に対応付けされるため（第１のコードが第２のコードで自動的に認識される、通訳的機能）、売手側は従来のように受注管理や在庫管理等の商品管理を手作業で行う必要はない。
【００７２】
また、所定期間内に商談情報メモリに保存された複数の商談情報において、それぞれの商談情報の商品情報（取引単価等）に基づいて引当処理順を決定し（取引単価の高い順に優先度を決定する等）、その引当処理順に従って、対象商談情報内の第１のコードに対応付けられた複数の第２のコードの引当処理順を、それぞれの第２コードに対応する供給可能商品情報（商品原価等）に基づいて決定し（商品原価の安い順に優先度を決定する等）、その引当処理順に従って、対象商談情報の第１のコードにより示される商品に対して、それに対応付けられた複数の第２のコートを順に引き当てていく。
これにより、それぞれの商談情報を売手側にとって有利な順に引当処理することができ、また、それぞれの商談情報に対して、売手側における商品（第２のコードによって示される商品）を売手側にとって有利な順に引き当てることができる。
また、供給可能情報メモリの供給可能商品情報が商談情報の内容に応じて更新されること等により、その更新結果から、事前に買手側からの発注状況（仮発注状況）を把握することもできるため、例えば、今現在どの商品を買手側に対して提供すれば、売手側にとって最も有利であるかを事前に把握しておくことができる。これにより、売手側の担当者は、そのときの状況に応じて、最も効率的な営業活動を行うことができる。
さらに、残商品を早めに予測することができるため、その残商品に対する販売形態を、最も効率の良い形態に早めに変更することができる。例えば、残商品となった精肉等の商品については、その時点で冷凍されるため、その分価格が下がってしまうが、その予測が事前にできれば、冷凍する前に、冷凍後の価格よりも高い価格で販売することができる。  さらにまた、買手側と売手側の商談サイクルを速くすることができ、これは売手側にとっても買手側にとっても有利である。
【００７３】
よって、本発明によれば、精肉等の生鮮品や航空チケットのように、有効期限が限られており且つ供給量が予め決まっている商品であっても、その商品管理を、売手側と買手側のそれぞれで容易に且つ効率的に行うことができる。
【図面の簡単な説明】
【図１】第１の実施の形態において、本発明を適用した商品管理システムの構成を示すブロック図である。
【図２】上記商品管理システムにおいて、商談時に発生する買手側についての商談データを説明するための図である。
【図３】上記商談データに含まれる買手側の商品コードによって示される商品に対して、売手側の商品コードによって示される商品を引き当てる処理を説明するためのフローチャートである。
【図４】上記引当処理の具体例を説明するための図である。
【図５】第２の実施の形態において、上記商談後に、買手側の商品コードによって示される商品に対して引き当てる、売手側の商品コードによって示される複数の商品の優先度を自動的に決定するための処理を説明するためのフローチャートである。
【図６】上記優先度決定処理の具体例を説明するための図である。
【図７】一般の買手側（スーパーマーケット等）での商品に対する分類を説明するための図である。
【図８】上記買手側での商品に対する分類に対して、その売手側（メーカ側）での商品に対する分類の違いを説明するための図である。
【符号の説明】
１０    商品管理システム
１００（Ａ），１００（Ｂ），・・・  買手側
１０１（Ａ）  買手側の担当者
２００  物流センタ
３００  売手側
３１０  データベースメモリ
３１１  商談データ
３１２  在庫量データ
３１３  供給可能量データ
３２０  商品管理処理部
３３０  売手側の担当者
３４０  端末装置
【図１】
0004153116.tif 000002
【図２】
0004153116.tif 000003
【図３】
0004153116.tif 000004
【図４】
0004153116.tif 000005
【図５】
0004153116.tif 000006
【図６】
0004153116.tif 000007
【図７】
0004153116.tif 000008
【図８】
0004153116.tif 000009