JP4153116B2

JP4153116B2 - Product management apparatus, product management system, product management method, and storage medium

Info

Publication number: JP4153116B2
Application number: JP01462499A
Authority: JP
Inventors: 健嘉二宮; 裕宮辺
Original assignee: NS Solutions Corp
Current assignee: NS Solutions Corp
Priority date: 1999-01-22
Filing date: 1999-01-22
Publication date: 2008-09-17
Anticipated expiration: 2019-01-22
Also published as: JP2000215233A

Description

【０００１】
【発明の属する技術分野】
本発明は、例えば、野菜や精肉等の生鮮品、航空チケット、コンサートチケットのように、有効期限が限られており且つ供給量が予め決まっている商品を管理するために用いられる商品管理装置、商品管理システム、商品管理方法、及びそれを実施するための処理ステップをコンピュータが読出可能に格納した記憶媒体に関するものである。
【０００２】
【従来の技術】
例えば、スーパーマーケット等の小売業者側では様々な商品が販売されているが、それらの商品の中の生鮮品として、”精肉”に着目してみる。
図７は、野菜や豆腐、魚介類、精肉等の生鮮商品が陳列される陳列棚において、精肉用の陳列棚の棚割の様子を具体的に示したものである。この図７に示すように、まず、「牛肉」や「豚肉」、「鶏肉」といった品目に対してそれぞれ棚割される。「牛肉」用棚では、「国産物」と「輸入物」で棚割され、さらに「国産物」の棚において「和牛」と「一般牛」で棚割される。そして、「和牛」と「一般牛」のそれぞれの棚に、モモやヒレといった部位毎の精肉が陳列される。他の「豚肉」や「鶏肉」等についても、上記の「牛肉」の場合と同様にして棚割されて精肉が陳列される。
【０００３】
上述のようにして各種の精肉を陳列して販売する小売業者は、精肉を取り扱うメーカとの商談を行うことによって、希望する精肉を該メーカから仕入れることになる。
【０００４】
ここで、メーカ側（以下、「売手側」と言う）では、小売業者側（以下、「買手側」と言う）での精肉の分類（上記図７参照）に対して、精肉の分類がさらに細かくなされている。具体的には、買手側で言う”牛肉−国産−和牛−モモ肉”に対して、さらに細かく、産地や飼育に使用した穀物や、輸入物である場合には国名やブランド名等（以下、これらの情報を「品質情報」と言う）の違いによって、モモ肉Ａ，モモ肉Ｂ，モモ肉Ｃ，・・・で分類されている。
したがって、例えば、図２に示すように、買手側と売手側とで、”牛肉−国産−和牛−モモ肉”の商品を単価Ｘ円で取引する場合、売手側は、それに対応する商品（買手側の意に添うようなモモ肉）を、モモ肉Ａ，モモ肉Ｂ，モモ肉Ｃ，・・・の中から選択して（ここでは、上記図８の黒矢印で示す”モモ肉Ｃ”を選択）、それを買手側に供給（出荷）することになる。
【０００５】
また、売手側における買手側に対する供給単位（出荷単位）は、１Ｋｇグラム相当の精肉のブロックが１０個詰められた段ボールといった、ボックス単位となる。例えば、買手側が、”牛肉−国産−和牛−モモ肉”を５００Ｋｇ希望した場合、売手側は、１Ｋｇ相当のモモ肉ブロック１０個からなる１ボックス（１０Ｋｇ相当のモモ肉）を５０箱（５０ボックス）で、買手側との商談を進める。
尚、精算については、正確なグラム数単位でなされる。また、売手側が海外との取り引きによって精肉を輸入する場合等にも、上記のボックス単位で取り引きがなされる。
【０００６】
また、このとき、当該商談と同様の商談（売手側の他の商談担当者による他の買手側との商談）が別の場所で同時に行われ、そこで同じモモ肉Ｃが他の買手側に割り当てられることで、当該商談での買手側に対して、上述のようにして選択したモモ肉Ｃを供給できなくなる場合も考えられる。これは、モモ肉Ｃについての供給総量が予め決まっているためである。そこで、売手側は、このような場合に対応するために、モモ肉Ｃの他に、それと同等の品質を有するモモ肉Ｄ及びＥ（上記図８中の白抜矢印参照）をも選択する。
したがって、この場合、売手側は、買手側が要求した商品（”牛肉−国産−和牛−モモ肉”、単価Ｘ円、Ｙボックス）に対して、モモ肉Ｃ、Ｄ、及びＥで商談を進めることになる。そして、この商談がまとまると、売手側は、買手側から指定された期日に、モモ肉Ｃ、Ｄ、及びＥの在庫量を確認し、それらのモモ肉Ｃ、Ｄ、及びＥのうちの何れかを買手側に供給する。
【０００７】
上述のような売手側と買手側間の商談は、ある一定期間のサイクル（以下、商談サイクル」と言う）で行われる。
具体的には、例えば、買手側（スーパーマーケット等）では、消費者への販売形態としてのいわゆるセールが行われる場合が多々ある。この場合、買手側は、セール期間中は消費者に対して低価格で精肉を提供することになるため、その分単価の安い精肉を売手側に希望することになる。また、他の販売形態として、高級な精肉を揃えて販売する場合もある。この場合、買手側は、高価格ではあるがその分高品質な精肉を消費者に提供することになるため、それに相当した高品質な精肉を売手側に希望することになる。このように、買手側における精肉の単価（消費者に対する販売単価）は、常に一定したものではなく、その時々の販売形態等によって変動するものである。そこで、これに対応するために、売手側と買手側間の商談に商談サイクルが設けられている。したがって、買手側は、売手側との商談の度に、次の商談サイクル期間内に行う予定の販売形態（セール等）を考慮しながら、それに対応する精肉を売手側に希望することなる。
【０００８】
【発明が解決しようとする課題】
ところで、上述したような買手側（スーパーマーケット等）では、売手側（メーカ側）に対する商品発注や在庫管理等のコンピュータ化により、精肉等の生鮮品、工業製品、及び菓子類等の様々な商品の全てに対して、それぞれ対応するバーコード（商品コード）を付加することが行われている。これにより、買手側は、それぞれの商品毎の売れ行き状態を直ぐに把握することができ、この結果欠品が出そうになれば、その商品を直ぐに売手側（メーカ側）に追加注文できるというように、商品の発注管理や在庫管理を容易に行うことができる。
【０００９】
一方、様々な商品を買手側（スーパーマーケット等）に供給する売手側（メーカ）、特に、上述したような精肉等の商品を取り扱う売手側では、買手側からの商品受注や、商品の在庫管理等がコンピュータ化されておらず、人間の手作業によって行われている。これは、次のような理由による。
【００１０】
まず、工業製品や、袋詰め或いは箱詰めされた菓子類のような商品は、買手側での商品と売手側での商品で一対一で対応している。すなわち、買手側で言う”ＡＡＡ”という商品（具体的には”ＡＡＡ”とネーミングされた菓子）は、売手側においても”ＡＡＡ”という商品そのものを示す。このような商品については、商品コードとして、比較的どの買手側（スーパーマーケット等）でも同様のものが用いられる。
したがって、例えば、買手側と売手側で商品コードを統一し、買手側が売手側に対して商品の注文を行う際にも、その商品コードを用いるようにすれば、買手側と売手側の間では、共通の商品コードによって商品の発注や受注が行われることになるため、買手側と売手側のそれぞれで商品管理を容易にできる、ということが考えられる。
【００１１】
しかしながら、精肉等の商品は、上述したような工業製品や菓子類のような商品に対して、買手側での商品と売手側での商品で一対一で対応してわけではない。具体的には、上記図８に示したように、買手側（スーパーマーケット等）での”牛肉−国産−和牛−モモ肉”といった１つの商品に対して、売手側（メーカ側）ではこれを品質情報によってさらに細かく分類したモモ肉Ａ，モモ肉Ｂ，モモ肉Ｃ，・・・といったｎ個の商品に対応している。すなわち、買手側での商品と売手側での商品は、１：ｎの関係にある。
これは、買手側での分類は、消費者のニーズに対応できれば十分であるが（一般消費者にとっては、飼育に使用した穀物が何であるか等を示す品質情報までの分類はあまり必要ない）、これに対して売手側の分類は、商品の出荷先はスーパーマーケットに限らず、様々な業種の買手側（加工工場やレストラン等）があり、それに対応するために、上記の品質情報までの分類が必要となってくるからである。
このように、買手側と売手側の分類形態が全く異なる商品について、例えば、上述した工業製品や菓子類等の商品と同様にして買手側と売手側で商品コードを統一しようとすると、商品コードを売手側の分類に対応させた場合、買手側では使用しない無駄な商品コードが多数存在してしまうという問題が生じてしまう。これとは逆に、商品コードを買手側の分類に対応させた場合、売手側では該売手側での商品（細かく分類された商品）に対応できないという問題が生じてしまう。
したがって、精肉等の商品については、買手側と売手側で商品コードを統一化することは非常に困難である。
【００１２】
上述したような理由から、特に、買手側での商品に対する分類と、売手側での商品に対する分類とが、１：ｎの関係であるような商品（精肉等）については、その商品を取り扱う売手側において、商品受注や在庫管理等の商品管理が未だ人間の手作業によって行われているのが現状である。これは非常に効率的ではない。
【００１３】
そこで、本発明は、上記の欠点を除去するために成されたもので、精肉等の生鮮品や航空チケットのように、有効期限が限られており且つ供給量が予め決まっている商品であっても、その商品管理を、売手側と買手側のそれぞれで容易に且つ効率的に行うことが可能な、商品管理装置、商品管理システム、商品管理方法、及びそれを実施するための処理ステップをコンピュータが読出可能に格納した記憶媒体を提供することを目的とする。
【００１４】
【課題を解決するための手段】
斯かる目的下において、第１の発明は、商品の出荷先である買手側との商談によって決定された、該買手側での第１の商品コード体系に従った第１のコードによって示される商品の情報を含む商談情報に基づいて、該第１のコードによって示される商品に対して、在庫商品から対応する商品を引き当てる売手側の商品管理装置であって、上記在庫商品の情報を上記売手側での第２の商品コード体系に従った第２のコードに対応させて記憶する在庫情報記憶手段と、上記商談情報の上記第１のコードによって示される商品に対応する商品として選択された複数種類の在庫商品を示す複数の上記第２のコードを、上記第１のコードに対応付けて記憶する商談情報記憶手段と、上記在庫情報記憶手段に記憶された在庫商品情報に基づいて、上記商談情報記憶手段に記憶された商談情報の上記第１のコードによって示される商品に対して、上記第１のコードに対応付けられた上記複数の第２のコードによって示される複数種類の在庫商品を、所定順で引き当てる商品引当手段とを備えることを特徴とする。
【００１５】
第２の発明は、上記第１の発明において、上記所定順は、上記複数の第２のコードにそれぞれ付加された優先度の順を含むことを特徴とする。
【００１６】
第３の発明は、上記第１の発明において、上記商品引当手段は、上記買手側から上記第２のコードによって示される商品の本発注要求が発行された時に、該本発注要求に対応する上記商談情報記憶手段に記憶された商談情報について、上記の処理を実行することを特徴とする。
【００１７】
第４の発明は、上記第１の発明において、上記商品は、有効期限が限られており、上記買手側に対する供給可能量が予め決定されてた商品を含むことを特徴とする。
【００１８】
第５の発明は、上記第１の発明において、上記買手側に対して供給可能な商品の情報を上記第２のコードに対応させて記憶する供給可能情報記憶手段と、所定期間内に上記商談情報記憶手段に記憶された複数の商談情報の引当処理順を、該商談情報に含まれる商品情報に基づいて決定する第１の決定手段と、上記第１の決定手段により決定された処理順に従って、対象商談情報に対応付けられた上記複数の第２のコードの引当処理順を、上記供給可能情報記憶手段に記憶された供給可能商品情報に基づいて決定する第２の決定手段とを備えることを特徴とする。
【００１９】
第６の発明は、上記第５の発明において、上記供給可能商品情報は、商品の原価情報を含み、上記商談情報の商品情報は、上記買手側との取引単価を含むことを特徴とする。
【００２０】
第７の発明は、第１の商品コード体系に従った第１のコードによって商品を管理する買手側と、第２の商品コード体系に従った第２のコードによって商品を管理する売手側とを含む商品管理システムであって、上記売手側は、請求項１〜６の何れかに記載の商品管理装置の機能を有することを特徴とする。
【００２１】
第８の発明は、第１の商品コード体系に従った第１のコードによって商品管理を行う買手側に対して供給する商品の管理を、第２の商品コード体系に従った第２のコードによって行うための売手側の商品管理方法であって、在庫商品の情報を上記第２のコードに対応させて在庫情報メモリに記憶する在庫情報記憶ステップと、上記買手側との商談によって決定された上記第１のコードによって示される商品の情報を含む商談情報を、その商品に対応する商品として選択された複数種類の在庫商品を示す複数の上記第２のコードと共に対応付けて商談情報メモリに記憶する商談情報記憶ステップと、上記在庫情報メモリに記憶された在庫商品情報に基づいて、上記商談情報メモリに記憶された商談情報の上記第１のコードによって示される商品に対して、上記第１のコードに対応付けられた上記複数の第２のコードによって示される複数種類の在庫商品を、所定順で引き当てる商品引当ステップとを含むことを特徴とする。
【００２２】
第９の発明は、上記第８の発明において、上記商品引当ステップは、上記所定順を、上記複数の第２のコードにそれぞれ付加された優先度の順として、上記引当処理を実行するステップを含むことを特徴とする。
【００２３】
第１０の発明は、上記第８の発明において、上記商品引当ステップは、上記買手側から上記第２のコードによって示される商品の本発注要求が発行された時に、該本発注要求に対応する上記商談情報メモリに記憶された商談情報について、上記の処理を実行するステップを含むことを特徴とする。
【００２４】
第１１の発明は、上記第８の発明において、上記商品は、有効期限が限られており、上記買手側に対する供給可能量が予め決定されてた商品を含むことを特徴とする。
【００２５】
第１２の発明は、上記第８の発明において、上記買手側に対して供給可能な商品の情報を上記第２のコードに対応させて供給可能情報メモリに記憶する供給可能情報記憶ステップと、所定期間内に上記商談情報記憶メモリに記憶された複数の商談情報の引当処理順を、該商談情報に含まれる商品情報に基づいて決定する第１の決定ステップと、上記第１の決定ステップにより決定された処理順に従って、対象商談情報に対応付けられた上記複数の第２のコードの引当処理順を、上記供給可能情報メモリに記憶された供給可能商品情報に基づいて決定する第２の決定ステップとを含むことを特徴とする。
【００２６】
第１３の発明は、上記第１２の発明において、上記供給可能商品情報は、商品の原価情報を含み、上記商談情報の商品情報は、上記買手側との取引単価を含むことを特徴とする。
【００２７】
第１４の発明は、請求項８〜１３の何れかに記載の商品管理方法の処理ステップを、コンピュータが読み出し可能に格納した記憶媒体であることを特徴とする。
【００２８】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００２９】
（第１の実施の形態）
本発明は、例えば、図１に示すような商品管理システム１０に適用される。
この商品管理システム１０は、スーパーマーケット等の小売店を含む複数の買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・を取引先とする売手側（メーカ側）３００において、商品（ここでは”精肉”とする）の受注管理や在庫管理等の商品管理を電子的に行うようになされている。このため、売手側３００には、商品管理用の端末装置が設けられており、該端末装置（以下、説明の簡単のために該端末装置を含めて「売手側３００」と言う）は、詳細は後述する商談データ３１１、在庫量データ３１２、及び供給可能量データ３１３が保存されるデータベース（ＤＢ）メモリ３１０と、商品管理処理部３２０とを含んでなる。
【００３０】
ここで、まず、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・では、買手側専用の商品コード体系に従って、消費者へ提供する様々な商品に対してそれぞれ対応する商品モードを持たせている。例えば、上記図８に示したような棚割に対応した商品の分類（消費者のニーズに応じた分類等）に従って、”牛肉−国産−和牛−モモ肉”には「ＡＢＣ００１」の商品コードを対応させ、”牛肉−国産−和牛−ヒレ肉”には「ＡＢＣ００３」の商品コードを対応させている。このような商品コード体系によって、商品の発注管理や在庫管理等の商品管理を行うようになされている。
【００３１】
一方、売手側３００では、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・での商品コード体系とは異なる売手側専用のコード体系に従って、買手側での商品の分類をさらに細かく分類した商品に対してそれぞれ対応する商品コードを持たせている。例えば、上記図７に示したような品質情報（飼育に使用した穀物の種類等の情報）の違いによって、”牛肉−国産−和牛−モモ肉”という商品をさらに細かくモモ肉Ａ、モモ肉Ｂ、モモ肉Ｃ、・・・というように分類し、これらのモモ肉Ａ、モモ肉Ｂ、モモ肉Ｃ、・・・の商品に対して、「ＲＲ０Ａ」、「ＲＲ０Ｂ」、「ＲＲ０Ｃ」、・・・といった商品コードを対応させている。
このような商品コード体系によって、売手側３００においても買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・と同様に、商品の受注管理や在庫管理等の商品管理を行うようになされている。
【００３２】
このため、売手側３００の商品管理処理部３２０は、ＤＢメモリ３１０内の情報を参照しながら、種々の商品管理のための処理を実行する。特に、商品管理処理部３２０は、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・のそれぞれで用いられている商品コードを、売手側３００にて用いている商品コードに対応付けする機能（コード変換機能）を有している。これにより、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・での商品コード体系と、売手側３００での商品コード体系とが異なる場合であっても、すなわち買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・での商品に対する分類と、売手側３００での商品に対する分類とが１：ｎの関係であっても、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・は自側専用の商品コードを用いて商品管理を行い、売手側３００も同様に自側専用の商品コードを用いて商品管理を行うことができるようになされている。
尚、商品管理処理部３２０は、例えば、ＣＰＵから構成されており、該ＣＰＵが予め用意された処理プログラムを実行することで、商品管理処理部３２０の後述する各種処理機能が実施される。
【００３３】
ＤＢメモリ３１０には、「ＲＲ０Ａ」、「ＲＲ０Ｂ」、「ＲＲ０Ｃ」、・・・といった商品コードに対応した各商品の在庫量の情報（在庫量データ）３１２が保存されており、この在庫量データ３１２の内容は、商品出荷時の出荷量等に従って更新されるようになされている。
また、精肉等の商品については、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・に対して供給できる商品の総量（供給可能量）が予め決まっているため、ＤＢメモリ３１０には、上記の商品コードに対応した各商品の供給可能量データ３１３が保存されている。
さらに、ＤＢメモリ３１０には、売手側３００と、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・との商談によって発生した商談データ（Ａ），（Ｂ），（Ｃ），・・・（以下、これらをまとめて「商談データ３１２」とも言う）をも保存されるようになされている。
【００３４】
以下、上述のような商品管理システム１０において、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・と、売手側３００との間での、商品（精肉）の商談から出荷までの流れについて具体的に説明する。
【００３５】
上記図１に示すように、先ず、売手側３００の担当者３３０は、上述した商談サイクル（２週間や１ヶ月等）に従って、例えば、買手側１００（Ａ）へ出向き、そこの担当者１０１（Ａ）と商談を行う。この商談の結果、決定した内容は、売手側３００の担当者３３０の端末装置（ノート型パーソナルコンピュータ等）３１２に入力される。
【００３６】
図２は、端末装置３４０の商談結果入力画面を示したものである。このような商談結果入力画面上にて、売手側３００の担当者３３０は、上記の商談にて決定した内容を入力することになる。
【００３７】
具体的には、先ず、”顧客コード”及び”顧客名”を入力する。このとき、”顧客コード”を入力すればそれに対応する”顧客名”が自動的に表示されるようにしても良い。
次に、”販売期間”を入力する。この”販売期間”とは、買手側１００（Ａ）が当該商談にて決定（契約）した商品（精肉）を実際に販売する期間を示す。
次に、買手側１００（Ａ）が希望した”商品名”、”商品コード”、”量”、及び”単価”を入力する。ここでの”商品コード”は、買手側１００（Ａ）での商品コード体系に従った商品コードを示す。また、”量”に設定される値は、商談時の仮の量（”販売期間”に設定された期間中に買手側１００（Ａ）が販売する予定である仮の量）である。
【００３８】
そこで、例えば、買手側１００（Ａ）との取引する商品が、
”商品名” ＝「牛肉−国産−和牛−モモ肉」、
”商品コード”＝「ＡＢＣ００１」、
”量” ＝「１００」（Ｋｇ）、
”単価” ＝「５００」（円）
であるとする。
この場合、売手側３００の担当者３３０は、自側で取り扱っている牛肉−国産−和牛−モモ肉がさらに細かく分類されたモモ肉Ａ，モモ肉Ｂ，モモ肉Ｃ，・・・の中から、買手側１００（Ａ）の希望した上記の商品に対応する商品（買手側の意に添うようなモモ肉）を選択する。例えば、モモ肉Ａを選択し、それに対応する”商品コード”を入力する。ここでの”商品コード”は、売手側３００での商品コード体系に従った商品コードを示す。また、他の商談の結果によってモモ肉Ａを買手側１００（Ａ）に割り当てられない場合を考慮して、モモ肉Ａと同等の他の商品を２つ選択する。例えば、モモ肉Ｄ及びＥを選択し、それに対応する”商品コード”を入力する。したがって、商談結果入力画面の取引商品（１）〜（３）の項目には、モモ肉Ａ、Ｄ、及びＥといった売手側３００での商品が優先順に入力されることになる。
【００３９】
尚、”取引商品（１）〜（３）”の括弧内の値は優先度に対応しており、取引商品（１）の商品が一番優先度が高く、取引商品（２）、（３）の順に優先度が低くなるものとする。また、ここでは選択する取引商品を３つとしたが、この数に限られることはない。
【００４０】
上述のようにして、売手側３００の担当者３３０によって端末装置３４０に入力されたデータ（商談データ（Ａ））は、物流センタ２００を介して、売手側３００のＤＢメモリ３１０に商談データ３１１として保存される。このときの保存は、管理担当者等の端末装置上の操作によるものであってもよいし、ネットワークを介した通信によるもの（直接端末装置３４０から売手側３００のＤＢメモリ３１０に対して送信する等）であってもよい。
また、他の買手側１００（Ｂ），１００（Ｃ），・・・についても、上述した買手側１００（Ａ）と同様にして、売手側３００との商談が行われ、その結果（商談データ（Ｂ），（Ｃ），・・・）が売手側３００のＤＢメモリ３１０に商談データ３１１として保存される。
したがって、売手側３００のＤＢメモリ３１０の商談データ３１１としては、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・のそれぞれについての商談データ（Ａ），（Ｂ），（Ｃ），・・・が存在することになる。
【００４１】
次に、売手側３００と、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・との商談の後、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・から売手側３００に対して、本発注要求が発行される（上記図１の点線矢印参照）。この本発注要求の発行は、商談にて希望した販売期間（具体的には販売日）の前日等に、ＥＯＳ（エレクトリックオーダーシステム：電子発注システム）やファクシミリ（ＦＡＸ）等を用いて行われる。
例えば、買手側１００（Ａ）は、商談の後、実際の販売日の前日に、該商談にて用いた”顧客コード”及び”販売期間”（売手側３００の担当者３３０によって端末装置３４０に入力された”顧客コード”及び”販売期間”）を用いて、本発注要求を物流センタ２００を介して売手側３００に対して発行する。この本発注要求には、商談にて希望した各商品それぞれに対する、実際に入荷希望する”量”（以下、「実発注量」と言う）の情報をも含まれている。したがって、このときの実発注量分の商品が、売手側３００から買手側１００（Ａ）に対して実際に出荷されることになる。
【００４２】
上述のような本発注要求が売手側３００に対して発行されると、売手側３００の商品管理処理部３２０は、例えば、図３に示すフローチャートに従って、次のように動作する。
【００４３】
ステップＳ４００：
商品管理処理部３２０には、物流センタ２００を介して、ある買手側（ここでは買手側１００（Ａ）とする）からの本発注要求を受け取る。この本発注要求には、上述したように、”顧客コード”及び”販売期間”と共に、それぞれの商品に対する実際に入荷希望する実発注量の情報も含まれている。
【００４４】
ステップＳ４０１：
そこで、先ず、商品管理処理部３２０は、上記の本発注要求に含まれる”顧客コード”及び”販売期間”に基づいて、それに該当する商談データ（Ｘ）をＤＢメモリ３１０から取得する。
ここでは、例えば、図４に示すような、買手側１００（Ａ）についての商談データ（Ａ）が取得されるものとする。また、この商談データ（Ａ）は、上記図２や図４に示すように、買手側１００（Ａ）が希望した牛モモ肉や牛ヒレ肉といった複数の商品についてのデータ（商品データ）（Ａ−１），（Ａ−２），・・・から構成されるものとする。
【００４５】
ステップＳ４０２：
次に、商品管理処理部３２０は、処理カウンタ（内部カウンタ）Ｃ１を初期化する（Ｃ１＝１）。
この処理カウンタＣ１は、ステップＳ４０１にて取得した商談データ（Ａ）を構成する商品データ（Ａ−１），（Ａ−２），・・・の全てについて、本ステップ以降の処理を実行するために設けられたものである。
【００４６】
ステップＳ４０３：
次に、商品管理処理部３２０は、ステップＳ４０１にて取得した商談データ（Ａ）から、処理カウンタＣ１にて示される商品データ（Ａ−Ｃ１）を取得する。処理カウンタＣ１＝”１”とすれば、上記図４に示すように、
”希望商品” ＝「ＡＢＣ００１」
（牛肉−国産−和牛−モモ肉）、
”量” ＝「１００」、
”単価” ＝「５００」、
”引当商品（１）”＝「ＲＲ０Ａ」（モモ肉Ａ）、
”引当商品（２）”＝「ＲＲ０Ｄ」（モモ肉Ｄ）、
”引当商品（３）”＝「ＲＲ０Ｅ」（モモ肉Ｅ）、
なる情報を含む商品データ（Ａ−１）が取得されることになる。
【００４７】
ステップＳ４０４：
次に、商品管理処理部３２０は、処理カウンタＣ２（内部カウンタ）を初期化（Ｃ２＝１）する。
この処理カウンタＣ２は、”引当商品（１）〜（３）”の商品コード（売手側３００の商品コード）にて示される商品の在庫を、優先順位の高いものから調べるために、すなわち”引当商品（１）”、”引当商品（２）”、”引当商品（３）”の順に調べるために設けられたものである。
【００４８】
ステップＳ４０５：
次に、商品管理処理部３２０は、ステップＳ４０３にて取得した商品データ（Ａ−Ｃ１）において、処理カウンタＣ２にて示される”取引商品（Ｃ２）”に設定されている商品コードを取得する。そして、その商品コードに対応する商品の在庫量を、ＤＢメモリ３１０の在庫データ３１２から取得する。
処理カウンタＣ２＝”１”とすれば、上記図４に示すように、”引当商品（１）”に設定されている商品コード「ＲＲ０Ａ」に対応した商品の”在庫量”＝「５０」が取得されることになる。
【００４９】
ステップＳ４０６：
次に、商品管理処理部３２０は、上記の本発注要求に含まれる実発注量と、ステップＳ４０５にて取得した在庫量とを比較し、実発注量が在庫量以下であるか否かを判別する。この判別の結果、「実発注量≦在庫量」である場合にはステップＳ４０７からの処理を実行し、そうでない場合にはステップＳ４１１からの処理を実行する。
【００５０】
ステップＳ４０７：
ステップＳ４０６の判別の結果、「実発注量≦在庫量」であった場合、商品管理処理部３２０は、現在処理対象となっている商品データ（Ａ−Ｃ１）に対して、”引当商品（Ｃ２）”に設定されている商品コードに対応する商品を引き当てる。
処理カウンタＣ１＝”１”、処理カウンタＣ２＝”１”とすれば、買手側１００（Ａ）が希望した商品「ＡＢＣ００１」（牛肉−国産−和牛−モモ肉）に対して、優先順位が一番高い売手側３００の商品「ＲＲ０Ａ」（モモ肉Ａ）が引き当てられることになる。
【００５１】
ステップＳ４０８：
その後、商品管理処理部３２０は、ＤＢメモリ３１０の在庫データ３１２の内容を上記の実発注量に従って更新し（在庫量＝在庫量−実発注量）、次の商品データに対して上述したステップＳ４０３からの処理を実行するために、処理カウンタＣ１をカウントアップする（Ｃ１＝Ｃ１＋１）。
【００５２】
ステップＳ４０９：
そして、商品管理処理部３２０は、ステップＳ４０８でのカウントアップの結果、処理カウンタＣ１が商談データ（Ａ）を構成する商品データの総数ｍを越えたか否か、すなわち全ての商品データ（Ａ−１）〜（Ａ−ｍ）に対してのステップＳ４０３からの処理を実行し終えたか否かを判別する。
この判別の結果、処理終了である場合には次のステップＳ４１０に進み、そうでない場合にはステップＳ４０３に戻って以降の処理を繰り返し実行する。
【００５３】
ステップＳ４１０：
商談データ（Ａ）を構成する全ての商品データ（Ａ−１）〜（Ａ−ｍ）に対する処理が終了すると、商品管理処理部３２０は、その処理によって得られた商品データ（Ａ−１）〜（Ａ−ｍ）についての引当情報（ステップＳ４０７での引当結果情報）を、出荷指示情報として出力する。したがって、売手側３００の出荷担当者は、この出荷指示情報に基づいて、該当する商品を買手側１００（Ａ）に対して出荷するための手続きを行うことになる。
【００５４】
ステップＳ４１１：
一方、ステップＳ４０６の判別の結果、「実発注量≦在庫量」でなかった場合、商品管理処理部３２０は、次に優先度の高い引当商品の在庫量を調べるために、処理カウンタＣ２をカウントアップする（Ｃ２＝Ｃ２＋１）。
【００５５】
ステップＳ４１２：
そして、商品管理処理部３２０は、ステップＳ４１１でのカウントアップの結果、処理カウンタＣ２が”３”を越えたか否か、すなわち優先度の一番低い”引当商品（３）”まで在庫量のチェックをし終えたか否かを判別する。
この判別の結果、”引当商品（３）”まで在庫量のチェックをし終えていない場合にはステップＳ４０５に戻って以降の処理を繰り返し実行する。これにより、”取引商品（１）”の商品の在庫量が実発注量に満たない場合には、次に優先度が高い”取引商品（２）”の商品の在庫量がチェックされ、この”取引商品（２）”の商品の在庫量も実発注量に満たない場合には、次に優先度が高い”取引商品（３）”の商品の在庫量がチェックされる、というように、優先度の高い順に順次、売手側３００の該当する商品の在庫量がチェックされることになる。
また、”引当商品（３）”まで在庫量のチェックをし終えた場合、これは、”取引商品（１）〜（３）”に設定されている商品コードにより示される全ての商品の在庫量が、買手側１００（Ａ）が希望した実発注量に満たない場合である。このため、この場合には、その旨を示す情報（エラー情報）を一旦内部的に記憶しておき、ステップＳ４０８〜Ｓ４０９の処理を実行した後のステップＳ４１０の処理にて、上記のエラー情報を出荷指示情報に含ませて出力するようにする。これにより、この場合には、出荷担当者はこの状況を把握して、それに対処するための手続きを行う。
【００５６】
上述のように、本実施の形態では、買手側１００（Ｘ）と売手側３００の商談の結果（商談データ（Ｘ））に含まれる、買手側１００（Ｘ）での商品コード体系（第１の商品コード体系）によって示された商品（「ＡＢＣ００１」にて示される”牛肉−国産−和牛−モモ肉”等）に対して、売手側３００での在庫商品の中から優先度順に複数選択した商品（”モモ肉Ａ、モモ肉Ｂ、モモ肉Ｃ”等の引当商品）を、売手側３００での商品コード体系（第２の商品コード体系）による商品コード（「ＲＲ０Ａ」、「ＲＲ０Ｂ」、「ＲＲ０Ｃ」等）で対応付けてＤＢメモリ３１０に保存する。そして、買手側１００（Ｘ）から第１の商品コード体系による本発注要求が発行されると、ＤＢメモリ３１０に保存されている商談データの中から特定した本発注要求に対応した商談データ（Ｘ）において、第１の商品コード体系によって示された商品に対して、それに対応付けられた第２の商品コード体系によって示された引当商品を優先度順に引き当てる。
これにより、買手側１００（Ｘ）と売手側３００での商品コード体系が異なっていても、売手側３００において、買手側１００（Ｘ）からの本発注要求により示される希望商品（第１の商品コード体系によって示された商品）が、売手側３００における商品（第２の商品コード体系によって示される商品）に自動的に対応付けされるため（第１の商品コード体系が第２の商品コード体系で自動的に認識される、通訳的機能）、従来のように受注管理や在庫管理等の商品管理を手作業で行う必要はない。
【００５７】
（第２の実施の形態）
上述した第１の実施の形態では、買手側１００（Ｘ）と売手側３００の商談時において、売手側３００の担当者３３０が、買手側１００（Ｘ）の希望した商品に該当する売手側３００の商品として、複数の商品（引当商品（１）〜（３））を優先度の高い順に選択するようにした。
これに対して本実施の形態では、上記の複数の引当商品の優先度を、売手側３００の担当者３３０が決定するのではなく、商品管理処理部３２０によって最も有効となるように自動的に決定する。
【００５８】
このため、商品管理処理部３２０は、上記図３に示した本発注要求時の処理を実行する前に、例えば、図５に示すようなフローチャートに従って、次のように動作する。
【００５９】
ステップＳ５００：
ＤＢメモリ３００の商談データ３１１としては、第１の実施の形態にて説明した商談によって発生した、買手側１００（Ａ），１００（Ｂ），１００（Ｃ），・・・についての商談データ（Ａ），（Ｂ），（Ｃ），・・・が保存されているものとする。このときそれぞれの商談データに設定されている”取引商品（１）〜（２）”の商品コードは、任意の順（優先度を意識しない順）で設定されている。
【００６０】
ステップＳ５０１：
そこで、先ず、商品管理処理部３２０は、予め設定された所定期間内にＤＢメモリ３００の商談データ３１１として保存された商談データを、現在保存されている商談データ（Ａ），（Ｂ），（Ｃ），・・・の中から抽出する。
【００６１】
ステップＳ５０２：
ステップＳ５０１での抽出の結果、例えば、図６に示すように、商談データ（Ｂ），（Ｄ），（Ｆ），（Ｈ）が抽出されたものとする。
そこで、商品管理処理部３２０は、商談データ（Ｂ）の商品データ（Ｂ−１），（Ｂ−２），・・・、商談データ（Ｄ）の商品データ（Ｄ−１），（Ｄ−２），・・・、商談データ（Ｆ）の商品データ（Ｆ−１），（Ｆ−２），・・・、及び商談データ（Ｈ）の商品データ（Ｈ−１），（Ｈ−２），・・・を、取引単価の高い商品データ順にソートする。この結果、上記図６では、
取引単価＝”５５０”の（Ｂ−５），
取引単価＝”５３０”の（Ｈ−１），
取引単価＝”４００”の（Ｂ−３），
取引単価＝”３５０”の（Ｄ−２），
取引単価＝”３４０”の（Ｆ−３），
・・・の順に商品データがソート（以下、「ソート▲１▼」と言う）される。
このとき、同じ単価の商品データが存在した場合には、商品データに対して予め付けられた所定の優先度に従って処理を進めるようにする。例えば、ＤＢメモリ３１０に保存された時刻が速い方を優先する。
【００６２】
ステップＳ５０３、ステップＳ５０４：
次に、商品管理処理部３２０は、ステップＳ５０２でのソート▲１▼の順に従って、対象商品データ（Ｘ−ｎ）を取得し（ステップＳ５０３）、その対象商品データ（Ｘ−ｎ）に設定されている”取引商品（１）〜（３）”を、ＤＢメモリ３１０の供給可能量データ３１３を参照することで、原価の安い順にソートする（以下、「ソート▲２▼」と言う）（ステップＳ５０４）。
ここで、供給可能量データ３１３は、上記図６に示すように、上述した在庫量データ３１２と同様に、「ＲＲ０Ａ」、「ＲＲ０Ｂ」、「ＲＲ０Ｃ」、・・・といった売手側３００での商品コードに対応して、それぞれの商品の”原価”及び”供給可能量（可能量）”が設定されてなる。
したがって、例えば、対象となる商品データが最も取引単価が高い商品データ（Ｂ−５）である場合（上記図６参照）、この商品データには”取引商品（１）〜（３）”として商品コード「ＲＲ０Ａ」、「ＲＲ０Ｂ」、及び「ＲＲ０Ｇ」が設定され、これらの原価は「２００」、「２２０」、及び「１９０」であるため、「ＲＲ０Ｇ」，「ＲＲ０Ａ」，「ＲＲ０Ｂ」の順にソートされることになる。
【００６３】
ステップＳ５０５、ステップＳ５０６：
次に、商品管理処理部３２０は、ステップＳ５０４でのソート▲２▼の順に従って、供給可能量データ３１３を参照することで、対象商品コードの”供給可能量”を取得し（ステップＳ５０５）、その供給可能量と、対象商品データ（Ｘ−ｎ）の”量”（仮発注量）とを比較することで、対象商品データ（Ｘ−ｎ）に対して対象商品コードの商品を引き当てることが可能であるか否かを判別する（ステップＳ５０６）。
例えば、対象商品データが（Ｂ−５）であり、対象商品コードが一番原価の安い「ＲＲ０Ｇ」である場合（上記図６参照）、仮発注量（２００）＞供給可能量（１５０）であるため（引当不可）、次の取引商品（２）の供給可能量を調べるためにステップＳ５０５へ戻る。このとき引当可能（仮発注量≦供給可能量）であったならば、次のステップＳ５０７からの処理に進む。
【００６４】
ステップＳ５０７、ステップＳ５０８：
ステップＳ５０６の判別の結果、対象商品データ（Ｘ−ｎ）に対して対象商品コードの商品を引き当てることが可能であった場合、商品管理処理部３２０は、その引当を決定し（ステップＳ５０７）、対象商品コードの”供給可能量”を、対象商品データ（Ｘ−ｎ）の仮発注量に基づいて更新する（供給可能量＝供給可能量−仮発注量）（ステップＳ５０８）。
【００６５】
ステップＳ５０９：
そして、商品管理処理部３２０は、次に処理対象となる商品コードが有るか否かを判別し、有る場合にはステップＳ５０３に戻って以降の処理ステップを繰り返し実行し、無い場合には本処理終了となる。
【００６６】
上述のように、本実施の形態では、所定期間内の各商談データを構成する各商品データにおいて、先ず、それぞれの商品データを取引単価の高い順にソートし、その順に従って、対象商品データ内の取引商品（１）〜（３）により示される商品（売手側３００の商品）を原価の安い順にソートし、その順に従って、対象商品データの仮発注量を満たす商品を該対象商品データに引き当てることを決定する。
これにより、それぞれの商品データを売手側３００にとって有利な順に処理することができ、また、それぞれの商品データ内の取引商品（１）〜（３）についても売手側３００にとって有利な順で、対象商品データに引き当てることができる。すなわち、買手側から本発注要求が発行される前（実際に商品を引き当てる出荷前）に、自動的に、売手側３００にとって最も有利な取引商品（１）〜（３）の優先度を、各商談データの各商品データ毎に持たせることができ、その優先度順で商品の引当を行うことができる。
また、ＤＢメモリ３１０の供給可能量データ３１３によって、事前に買手側からの発注状況（仮発注状況）を把握することもできるため、例えば、今現在どの商品を買手側に対して提供すれば、売手側３００にとって最も有利であるかを事前に把握しておくことができる。これにより、売手側３００の担当者３３０は、そのときの状況に応じて、最も効率的な営業活動を行うことができる。
さらに、残商品を早めに予測することができるため、その残商品に対する販売形態を、最も効率の良い形態に早めに変更することができる。例えば、残商品となった精肉等の商品については、その時点で冷凍されるため、その分価格が下がってしまうが、その予測が事前にできれば、冷凍する前に、冷凍後の価格よりも高い価格で販売することができる。さらにまた、上述した商談サイクルを速くすることができ、これは売手側にとっても買手側にとっても有利である。
【００６７】
尚、上述した第２の実施の形態の変形例として、例えば、売手側３００の商品コードを原価の高い順にソートし、また、買手側１００（Ａ），１００（Ｂ），・・・についての商談データ（Ａ），（Ｂ），・・・の各商品データを取引単価の高い順にソートして、それらの順に従って、上述したような商品の引当を行うようにしてもよい。
【００６８】
また、上述した第１及び第２の実施の形態においては、本発注要求の発行順に、上記図３に示した処理（商品の引当処理）を実行するようにしたが、これに限られることはなく、例えば、買手側に対して優先度を付け、その優先度に従って処理実行するようにしてもよい。
また、ここでは、対象商品を”精肉”としたが、これに限られることはな。例えば、野菜や精肉等の生鮮品、航空チケット、コンサートチケットのように、有効期限が限られており且つ供給量が予め決まっている商品に対して適用可能である。
【００６９】
また、本発明の目的は、上述した各実施の形態のホスト及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだして実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が各実施の形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することとなる。
プログラムコードを供給するための記憶媒体としては、ＲＯＭ、フロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード等を用いることができる。
また、コンピュータが読みだしたプログラムコードを実行することにより、各実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって各実施の形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって各実施の形態の機能が実現される場合も含まれることは言うまでもない。
【００７０】
【発明の効果】
以上説明したように本発明では、買手側での商品コード体系と、売手側での商品コード体系が異なる場合であっても、売手側において、買手側での商品コード体系によるコードを、売手側での商品コード体系によるコードに対応付けすることで、売手側での商品管理をコードによって電子的に行えるように構成した。
【００７１】
具体的には例えば、買手側と売手側の商談の結果（商談情報）に含まれる、買手側での第１のコードによって示された商品（「ＡＢＣ００１」にて示される”牛肉−国産−和牛−モモ肉”等の生鮮商品）に対して、売手側での在庫商品の中から優先度順に複数選択した商品（買手側における商品分類に対してさらに細かく分類された”モモ肉Ａ、モモ肉Ｂ、モモ肉Ｃ”等の引当商品）を、売手側での第２のコード（「ＲＲ０Ａ」、「ＲＲ０Ｂ」、「ＲＲ０Ｃ」等）で対応付けて商談情報メモリに保存する。そして、買手側から第１のコードによる本発注要求が発行されると、商談情報メモリに保存されている商談情報の中から特定した本発注要求に対応した商談情報において、第１のコードによって示された商品に対して、それに対応付けられた第２のコードによって示された引当商品を優先度順に引き当てる。
これにより、対象商品が、買手側での”牛肉−国産−和牛−モモ肉”といった１つの商品に対して、売手側ではこれを品質情報（飼育に使用した穀物の情報等）によってさらに細かく分類したモモ肉Ａ，モモ肉Ｂ，モモ肉Ｃ，・・・といったｎ個の商品に対応している商品（１：ｎの関係）であることにより、買手側と売手側で商品コード体系を統一することができなくなくても、売手側において、買手側からの本発注要求により示される希望商品（第１のコードによって示された商品）が、売手側における商品（第２のコードによって示される商品）に自動的に対応付けされるため（第１のコードが第２のコードで自動的に認識される、通訳的機能）、売手側は従来のように受注管理や在庫管理等の商品管理を手作業で行う必要はない。
【００７２】
また、所定期間内に商談情報メモリに保存された複数の商談情報において、それぞれの商談情報の商品情報（取引単価等）に基づいて引当処理順を決定し（取引単価の高い順に優先度を決定する等）、その引当処理順に従って、対象商談情報内の第１のコードに対応付けられた複数の第２のコードの引当処理順を、それぞれの第２コードに対応する供給可能商品情報（商品原価等）に基づいて決定し（商品原価の安い順に優先度を決定する等）、その引当処理順に従って、対象商談情報の第１のコードにより示される商品に対して、それに対応付けられた複数の第２のコートを順に引き当てていく。
これにより、それぞれの商談情報を売手側にとって有利な順に引当処理することができ、また、それぞれの商談情報に対して、売手側における商品（第２のコードによって示される商品）を売手側にとって有利な順に引き当てることができる。
また、供給可能情報メモリの供給可能商品情報が商談情報の内容に応じて更新されること等により、その更新結果から、事前に買手側からの発注状況（仮発注状況）を把握することもできるため、例えば、今現在どの商品を買手側に対して提供すれば、売手側にとって最も有利であるかを事前に把握しておくことができる。これにより、売手側の担当者は、そのときの状況に応じて、最も効率的な営業活動を行うことができる。
さらに、残商品を早めに予測することができるため、その残商品に対する販売形態を、最も効率の良い形態に早めに変更することができる。例えば、残商品となった精肉等の商品については、その時点で冷凍されるため、その分価格が下がってしまうが、その予測が事前にできれば、冷凍する前に、冷凍後の価格よりも高い価格で販売することができる。さらにまた、買手側と売手側の商談サイクルを速くすることができ、これは売手側にとっても買手側にとっても有利である。
【００７３】
よって、本発明によれば、精肉等の生鮮品や航空チケットのように、有効期限が限られており且つ供給量が予め決まっている商品であっても、その商品管理を、売手側と買手側のそれぞれで容易に且つ効率的に行うことができる。
【図面の簡単な説明】
【図１】第１の実施の形態において、本発明を適用した商品管理システムの構成を示すブロック図である。
【図２】上記商品管理システムにおいて、商談時に発生する買手側についての商談データを説明するための図である。
【図３】上記商談データに含まれる買手側の商品コードによって示される商品に対して、売手側の商品コードによって示される商品を引き当てる処理を説明するためのフローチャートである。
【図４】上記引当処理の具体例を説明するための図である。
【図５】第２の実施の形態において、上記商談後に、買手側の商品コードによって示される商品に対して引き当てる、売手側の商品コードによって示される複数の商品の優先度を自動的に決定するための処理を説明するためのフローチャートである。
【図６】上記優先度決定処理の具体例を説明するための図である。
【図７】一般の買手側（スーパーマーケット等）での商品に対する分類を説明するための図である。
【図８】上記買手側での商品に対する分類に対して、その売手側（メーカ側）での商品に対する分類の違いを説明するための図である。
【符号の説明】
１０商品管理システム
１００（Ａ），１００（Ｂ），・・・買手側
１０１（Ａ）買手側の担当者
２００物流センタ
３００売手側
３１０データベースメモリ
３１１商談データ
３１２在庫量データ
３１３供給可能量データ
３２０商品管理処理部
３３０売手側の担当者
３４０端末装置[0001]
BACKGROUND OF THE INVENTION
The present invention is, for example, a merchandise management apparatus used to manage merchandise with a limited expiration date and a predetermined supply amount, such as fresh products such as vegetables and meat, air tickets, concert tickets, The present invention relates to a product management system, a product management method, and a storage medium in which processing steps for carrying out the product are stored in a computer-readable manner.
[0002]
[Prior art]
For example, retailers such as supermarkets sell various products. Let's focus on “Meat” as a fresh product among these products.
FIG. 7 specifically shows the state of the shelf division of the display shelf for meat in the display shelf on which fresh products such as vegetables, tofu, seafood, and meat are displayed. As shown in FIG. 7, items such as “beef”, “pork”, and “chicken” are first shelved. In the “beef” shelf, “Japanese products” and “imported products” are divided into shelves, and in “domestic products” shelves are divided into “Japanese beef” and “general beef”. Then, the meat of each part such as peach and fin is displayed on each shelf of “Wagyu” and “General beef”. Other “pork”, “chicken” and the like are also divided into shelves in the same manner as in the case of “beef”, and the meat is displayed.
[0003]
A retailer that displays and sells various kinds of meat as described above purchases the desired meat from the manufacturer by conducting a business talk with the manufacturer that handles the meat.
[0004]
Here, on the manufacturer side (hereinafter referred to as “seller side”), the classification of meat is further compared to the classification of meat on the retailer side (hereinafter referred to as “buyer side”) (see FIG. 7 above). It has been made fine. Specifically, in contrast to the “beef-domestic-Japanese beef-peach meat” said on the buyer side, the grain used for the production area and breeding, or the country name, brand name, etc. ( These pieces of information are referred to as “quality information”) and are classified into thigh meat A, thigh meat B, thigh meat C,.
Therefore, for example, as shown in FIG. 2, when a product of “beef-domestic-Japanese beef-peach meat” is traded at the unit price X yen on the buyer side and the seller side, the seller side Peach meat A, peach meat B, peach meat C,... (Here, “peach meat C” indicated by the black arrow in FIG. 8 above) is selected. And supply (ship) it to the buyer.
[0005]
Further, the supply unit (shipment unit) to the buyer side on the seller side is a box unit such as a cardboard packed with 10 meat blocks equivalent to 1 Kg gram. For example, if the buyer wants 500 kg of “beef-domestic-Japanese beef-peach meat”, the seller will make 50 boxes (50 boxes) of 1 box (10 kg equivalent of peach meat) consisting of 10 blocks of 1 kg equivalent of peach meat. ) And proceed with business negotiations with the buyer.
It should be noted that the settlement is made in the correct gram unit. In addition, when the seller imports meat from overseas, the transaction is done in units of boxes.
[0006]
Also, at this time, the same business negotiation as the business negotiation (the business negotiation with the other buyer side by the other business person in charge of the seller) is performed simultaneously in another place, where the same thigh meat C is allocated to the other buyer side. As a result, there may be a case where the peach meat C selected as described above cannot be supplied to the buyer side in the negotiation. This is because the total supply amount for the peach meat C is determined in advance. Therefore, in order to cope with such a case, the seller side selects not only the peach meat C but also the peach meat D and E (see the white arrow in FIG. 8) having the same quality as the peach meat C.
Therefore, in this case, the seller side will proceed with the negotiations with the peach meat C, D, and E for the product requested by the buyer ("beef-domestic-Japanese beef-peach meat", unit price X yen, Y box). become. When the negotiation is completed, the seller confirms the stock quantity of the peach meats C, D, and E on the date designated by the buyer, and any of the peach meats C, D, and E is confirmed. To the buyer.
[0007]
The business negotiation between the seller side and the buyer side as described above is performed in a cycle of a certain period (hereinafter referred to as a business negotiation cycle).
Specifically, for example, on the buyer side (supermarket or the like), there are many cases where a so-called sale is performed as a form of sale to consumers. In this case, since the buyer side provides the meat at a low price to the consumer during the sale period, the buyer side desires the meat side at a lower unit price. In addition, as another sales form, high-quality meat is sometimes sold. In this case, the buyer side provides the consumer with high-quality meat at a high price, but the seller desires a high-quality meat equivalent to that. Thus, the unit price of meat on the buyer side (unit price for sales to consumers) is not always constant, but varies depending on the sales form at that time. Therefore, in order to cope with this, a business negotiation cycle is provided for business negotiations between the seller side and the buyer side. Therefore, each time a business negotiation with the seller is made, the buyer side requests the seller side for meat corresponding to the sales form (sale or the like) scheduled to be performed within the next business negotiation cycle period.
[0008]
[Problems to be solved by the invention]
By the way, on the buyer side (supermarket etc.) as described above, various products such as fresh products such as meat, industrial products, and confectionery can be obtained by computerization of merchandise ordering and inventory management to the seller side (manufacturer side). A barcode (product code) corresponding to each is added to all. As a result, the buyer can immediately grasp the sales status of each product, and if this results in a shortage, the product can be immediately ordered to the seller (manufacturer). , Product order management and inventory management can be easily performed.
[0009]
On the other hand, on the seller side (manufacturer) that supplies various products to the buyer side (supermarket, etc.), especially on the seller side that handles products such as meat as described above, product orders from the buyer side, product inventory management, etc. Is not computerized and is done manually by humans. This is due to the following reason.
[0010]
First, industrial products and products such as confectionery packed in a bag or box have a one-to-one correspondence between products on the buyer side and products on the seller side. That is, a product called “AAA” (specifically, a confection named “AAA”) on the buyer side indicates the product itself called “AAA” on the seller side. For such merchandise, the same merchandise code is used on relatively any buyer side (supermarket or the like).
Therefore, for example, if the product code is unified on the buyer side and the seller side, and the buyer side orders the product to the seller side, the product code is used between the buyer side and the seller side. Since a common product code is used for ordering and receiving orders, it can be considered that product management can be facilitated on both the buyer side and the seller side.
[0011]
However, products such as meat are not in one-to-one correspondence between products on the buyer side and products on the seller side with respect to products such as industrial products and confectionery as described above. Specifically, as shown in FIG. 8 above, the seller side (manufacturer's side) is responsible for the quality of one product such as “beef-domestic-Japanese beef-peach meat” on the buyer side (supermarket, etc.). It corresponds to n products such as peach meat A, peach meat B, peach meat C,. That is, the product on the buyer side and the product on the seller side have a 1: n relationship.
This is sufficient if the classification on the buyer side can meet the needs of consumers (for general consumers, it is not necessary to classify up to quality information indicating what grains are used for breeding, etc.) On the other hand, the seller side is not limited to supermarkets, but there are buyers (processing factories, restaurants, etc.) in various industries. Because it becomes necessary.
In this way, for products with completely different classifications on the buyer side and the seller side, for example, when trying to unify the product code on the buyer side and the seller side in the same manner as the above-mentioned products such as industrial products and confectionery, the product code Is associated with the classification on the seller side, there arises a problem that there are many useless product codes that are not used on the buyer side. On the other hand, when the product code is made to correspond to the classification on the buyer side, there arises a problem that the seller side cannot cope with the product on the seller side (a finely classified product).
Therefore, for products such as meat, it is very difficult to unify the product codes on the buyer side and the seller side.
[0012]
For the reasons described above, in particular, for a product (such as meat) in which the classification for the product on the buyer side and the classification for the product on the seller side have a 1: n relationship, the seller handling the product On the other hand, at present, product management such as product ordering and inventory management is still performed manually by humans. This is not very efficient.
[0013]
Therefore, the present invention has been made to eliminate the above-mentioned drawbacks, and is a product with a limited expiration date and a predetermined supply amount, such as fresh products such as meat and air tickets. However, the merchandise management apparatus, merchandise management system, merchandise management method, and processing steps for carrying out the merchandise management can be performed easily and efficiently on the seller side and the buyer side respectively. It is an object of the present invention to provide a storage medium readable by a computer.
[0014]
[Means for Solving the Problems]
Under such a purpose, the first invention relates to a product indicated by a first code according to a first product code system on the buyer side, which is determined by a business negotiation with the buyer side to whom the product is shipped. A seller-side product management apparatus that allocates a corresponding product from a stock product to the product indicated by the first code based on the business negotiation information including the information on the stock Inventory information storage means for storing in correspondence with the second code according to the second product code system in, and a plurality of types selected as products corresponding to the product indicated by the first code of the negotiation information The negotiation information storage means for storing a plurality of the second codes indicating the inventory products in association with the first code, and the negotiation based on the inventory product information stored in the inventory information storage means With respect to the product indicated by the first code of the negotiation information stored in the information storage means, a plurality of types of inventory products indicated by the plurality of second codes associated with the first code, The product provision means which allocates in a predetermined order is provided.
[0015]
According to a second aspect, in the first aspect, the predetermined order includes an order of priority added to each of the plurality of second codes.
[0016]
According to a third invention, in the first invention, the merchandise allocating means responds to the main order request when the main order request for the merchandise indicated by the second code is issued from the buyer side. The above processing is executed for the negotiation information stored in the negotiation information storage means.
[0017]
According to a fourth invention, in the first invention, the product includes a product whose expiration date is limited and whose supplyable amount to the buyer side is determined in advance.
[0018]
According to a fifth invention, in the first invention, supplyable information storage means for storing information on commodities that can be supplied to the buyer side in association with the second code, and the negotiation within a predetermined period of time. According to the first determining means for determining the allocation processing order of the plurality of negotiation information stored in the information storage means based on the product information included in the negotiation information, and the processing order determined by the first determining means And a second determining means for determining the allocation processing order of the plurality of second codes associated with the target negotiation information based on the supplyable product information stored in the supplyable information storage means. It is characterized by.
[0019]
According to a sixth aspect, in the fifth aspect, the supplyable product information includes cost information of the product, and the product information of the negotiation information includes a transaction unit price with the buyer.
[0020]
According to a seventh aspect of the present invention, there is provided a buyer side that manages a product by a first code according to a first product code system, and a seller side that manages a product by a second code according to a second product code system. In the commodity management system, the seller side has the function of the commodity management apparatus according to any one of claims 1 to 6.
[0021]
According to an eighth aspect of the present invention, the management of the product supplied to the buyer who manages the product with the first code according to the first product code system is managed by the second code according to the second product code system. A seller-side merchandise management method for performing inventory information storage step for storing inventory product information in the inventory information memory in association with the second code, and the above-mentioned decision made by a negotiation with the buyer The negotiation information including the information on the product indicated by the first code is stored in the negotiation information memory in association with the plurality of second codes indicating a plurality of types of stock products selected as the product corresponding to the product. A product indicated by the first code of the negotiation information stored in the negotiation information memory based on the negotiation information storage step and the inventory product information stored in the inventory information memory In contrast, characterized in that it comprises a plurality of types of items that are represented by the plurality of second code associated with the first code, and a goods provision step Hikiateru in a prescribed order.
[0022]
In a ninth aspect based on the eighth aspect, the product allocation step includes the step of executing the allocation process with the predetermined order as the order of priority added to the plurality of second codes. It is characterized by including.
[0023]
In a tenth aspect based on the eighth aspect, the merchandise allocation step corresponds to the main order request when the main order request for the merchandise indicated by the second code is issued from the buyer side. It includes a step of executing the above-described processing for the negotiation information stored in the negotiation information memory.
[0024]
According to an eleventh aspect, in the eighth aspect, the product includes a product having a limited expiration date and a predetermined amount of supply available to the buyer.
[0025]
In a twelfth aspect based on the eighth aspect, a suppliable information storage step of storing, in the suppliable information memory, information on commodities that can be supplied to the buyer side in association with the second code; A first determination step for determining an allocation processing order of a plurality of negotiation information stored in the negotiation information storage memory within a period based on product information included in the negotiation information, and the first determination step. A second determination step of determining the allocation processing order of the plurality of second codes associated with the target negotiation information based on the supplyable product information stored in the supplyable information memory in accordance with the processed processing order It is characterized by including.
[0026]
In a thirteenth aspect based on the twelfth aspect, the suppliable commodity information includes cost information on the commodity, and the commodity information on the negotiation information includes a transaction unit price with the buyer.
[0027]
The fourteenth invention is a storage medium storing the processing steps of the merchandise management method according to any one of claims 8 to 13 in a computer-readable manner.
[0028]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0029]
(First embodiment)
The present invention is applied to, for example, a merchandise management system 10 as shown in FIG.
The merchandise management system 10 includes a plurality of buyers 100 (A), 100 (B), 100 (C), etc. including retail stores such as supermarkets. Product management such as order management and inventory management of merchandise (herein “meat”) is performed electronically. For this reason, the seller side 300 is provided with a terminal device for product management, and the terminal device (hereinafter referred to as the “seller side 300” including the terminal device for the sake of simplicity) is detailed. Includes a database (DB) memory 310 that stores business negotiation data 311, inventory data 312, and supplyable data 313, which will be described later, and a merchandise management processing unit 320.
[0030]
Here, first, the buyer side 100 (A), 100 (B), 100 (C),... Responds to various products provided to consumers according to the product code system dedicated to the buyer side. Has a product mode. For example, according to the product classification corresponding to the shelf allocation as shown in FIG. 8 (classification according to consumer needs, etc.), the product code “ABC001” is assigned to “beef-domestic-Japanese beef-peach meat”. Correspondingly, the product code “ABC003” is associated with “beef-domestic-Japanese beef-fillet”. With such a product code system, product management such as product order management and inventory management is performed.
[0031]
On the other hand, the seller side 300 classifies the product on the buyer side according to a code system dedicated to the seller side, which is different from the product code system on the buyer side 100 (A), 100 (B), 100 (C),. The product code corresponding to each of the products that are further classified is provided. For example, depending on the quality information (information such as the type of grain used for breeding) as shown in FIG. 7 above, the product “beef-domestic-Japanese beef-peach meat” is further divided into the meat A and the meat B , Peach meat C,..., RR0A, RR0B, RR0C, etc. for the products of peach meat A, peach meat B, peach meat C,.・ Product codes such as
With such a product code system, on the seller side 300 as well as the buyer side 100 (A), 100 (B), 100 (C),..., Product management such as product order management and inventory management is performed. It is made like that.
[0032]
Therefore, the merchandise management processing unit 320 on the seller side 300 executes various merchandise management processes while referring to information in the DB memory 310. In particular, the merchandise management processing unit 320 uses merchandise codes used on the buyer side 100 (A), 100 (B), 100 (C),. (Corresponding to a code conversion function). Thus, even if the product code system on the buyer side 100 (A), 100 (B), 100 (C),... And the product code system on the seller side 300 are different, that is, on the buyer side. 100 (A), 100 (B), 100 (C),... And the classification of the product on the seller side 300 are in a 1: n relationship, the buyer side 100 (A ), 100 (B), 100 (C),..., Manage products using their own product codes, and seller 300 also manages products using their own product codes. It is made to be able to.
Note that the merchandise management processing unit 320 includes, for example, a CPU, and various processing functions described later of the merchandise management processing unit 320 are performed by the CPU executing a processing program prepared in advance.
[0033]
In the DB memory 310, information (inventory amount data) 312 of the inventory amount of each product corresponding to the product code such as “RR0A”, “RR0B”, “RR0C”,... Is stored. The contents of 312 are updated according to the shipping amount at the time of shipping the product.
For products such as meat, the total amount (suppliable amount) of products that can be supplied to the buyer side 100 (A), 100 (B), 100 (C),. The memory 310 stores suppliable amount data 313 for each product corresponding to the product code.
Further, in the DB memory 310, the negotiation data (A), (B), () generated by the negotiation between the seller side 300 and the buyer side 100 (A), 100 (B), 100 (C),. C),... (Hereinafter collectively referred to as “business negotiation data 312”) are also stored.
[0034]
Hereinafter, in the product management system 10 as described above, from the negotiation of the product (meat) between the buyer side 100 (A), 100 (B), 100 (C),. The flow up to shipment will be specifically described.
[0035]
As shown in FIG. 1, first, the person in charge 330 on the seller side 300 goes to the buyer side 100 (A), for example, according to the above-described negotiation cycle (two weeks, one month, etc.), and the person in charge 101 ( Hold a business talk with A). The content determined as a result of the negotiation is input to the terminal device (notebook personal computer or the like) 312 of the person in charge 330 on the seller side 300.
[0036]
FIG. 2 shows a negotiation result input screen of the terminal device 340. On such a business negotiation result input screen, the person in charge 330 on the seller side 300 inputs the content determined in the business negotiation.
[0037]
Specifically, first, “customer code” and “customer name” are input. At this time, if a “customer code” is input, the corresponding “customer name” may be automatically displayed.
Next, enter the “sales period”. This “sales period” indicates a period during which the product (meat) determined (contracted) by the buyer 100 (A) is actually sold.
Next, the “product name”, “product code”, “quantity”, and “unit price” desired by the buyer 100 (A) are input. The “product code” here indicates a product code according to the product code system on the buyer side 100 (A). Further, the value set in “amount” is a provisional amount at the time of negotiation (a provisional amount that the buyer side 100 (A) plans to sell during the period set in the “sales period”).
[0038]
Therefore, for example, a product to be traded with the buyer side 100 (A)
"Product name" = "Beef-Domestic-Wagyu beef-Thigh meat"
“Product code” = “ABC001”,
“Amount” = “100” (Kg),
"Unit price" = "500" (yen)
Suppose that
In this case, the person in charge 330 of the seller side 300 is selected from among the peach meat A, the peach meat B, the peach meat C,... Then, a product corresponding to the above-mentioned product desired by the buyer side 100 (A) (a peach meat that conforms to the buyer's intention) is selected. For example, thigh meat A is selected and the “product code” corresponding to it is input. The “product code” here indicates a product code according to the product code system on the seller side 300. In addition, considering the case where peach meat A cannot be allocated to buyer 100 (A) due to the result of another business negotiation, two other products equivalent to peach meat A are selected. For example, the thigh meats D and E are selected, and the “product code” corresponding thereto is input. Accordingly, in the items of transaction products (1) to (3) on the negotiation result input screen, products on the seller side 300 such as peach meat A, D, and E are input in order of priority.
[0039]
The values in parentheses of “transaction products (1) to (3)” correspond to the priority, and the product of the transaction product (1) has the highest priority, and the transaction products (2), (3 ) In order of priority. Although the number of transaction products to be selected is three here, the number is not limited to this.
[0040]
As described above, the data (the negotiation data (A)) input to the terminal device 340 by the person in charge 330 on the seller side 300 is stored as the negotiation data 311 in the DB memory 310 on the seller side 300 via the distribution center 200. Saved. The storage at this time may be by operation on a terminal device such as a manager or by communication via a network (directly transmitted from the terminal device 340 to the DB memory 310 on the seller side 300). Etc.).
Further, with respect to the other buyers 100 (B), 100 (C),..., Negotiations with the seller 300 are performed in the same manner as the buyer 100 (A) described above, and the result (consultation data) (B), (C),...) Are stored as negotiation data 311 in the DB memory 310 of the seller side 300.
Therefore, as the negotiation data 311 of the DB memory 310 on the seller side 300, the negotiation data (A), (B),... For the buyer side 100 (A), 100 (B), 100 (C),. (C), ... exist.
[0041]
Next, after the negotiation between the seller side 300 and the buyer side 100 (A), 100 (B), 100 (C),..., The buyer side 100 (A), 100 (B), 100 (C) ,... Are issued to the seller side 300 (see the dotted arrows in FIG. 1 above). This issuance of this order request is performed using the EOS (Electric Order System: Electronic Ordering System), facsimile (FAX), etc. on the day before the sales period (specifically, the sales date) desired in the negotiation.
For example, after the negotiation, the buyer side 100 (A) sends the “customer code” and the “sales period” used in the negotiation to the terminal device 340 by the person in charge 330 of the seller side 300 on the day before the actual sale date. The order request is issued to the seller side 300 via the distribution center 200 using the inputted “customer code” and “sales period”). This actual order request includes information on the “quantity” (hereinafter referred to as “actual order quantity”) that is actually desired to be received for each product desired in the negotiation. Accordingly, the products for the actual order quantity at this time are actually shipped from the seller side 300 to the buyer side 100 (A).
[0042]
When the main order request as described above is issued to the seller side 300, the merchandise management processing unit 320 of the seller side 300 operates as follows, for example, according to the flowchart shown in FIG.
[0043]
Step S400:
The merchandise management processing unit 320 receives a main order request from a certain buyer side (in this case, the buyer side 100 (A)) via the distribution center 200. As described above, the main order request includes information on the actual order quantity desired to be received for each product as well as the “customer code” and the “sales period”.
[0044]
Step S401:
Therefore, first, the merchandise management processing unit 320 acquires the negotiation data (X) corresponding to the “customer code” and “sales period” included in the main order request from the DB memory 310.
Here, for example, the negotiation data (A) for the buyer side 100 (A) as shown in FIG. 4 is acquired. Further, as shown in FIG. 2 and FIG. 4, this negotiation data (A) is data (product data) (A -1), (A-2),...
[0045]
Step S402:
Next, the merchandise management processing unit 320 initializes a processing counter (internal counter) C1 (C1 = 1).
This processing counter C1 executes the processing after this step for all of the product data (A-1), (A-2),... Constituting the negotiation data (A) acquired in step S401. Is provided.
[0046]
Step S403:
Next, the product management processing unit 320 acquires the product data (A-C1) indicated by the processing counter C1 from the negotiation data (A) acquired in step S401. If the processing counter C1 = "1", as shown in FIG.
"Preferred product" = "ABC001"
(Beef-domestic-Japanese beef-peach meat),
“Amount” = “100”,
"Unit price" = "500"
"Allowed product (1)" = "RR0A" (peach meat A),
"Allowed product (2)" = "RR0D" (peach meat D),
"Allowed product (3)" = "RR0E" (peach meat E),
Product data (A-1) including the following information is acquired.
[0047]
Step S404:
Next, the merchandise management processing unit 320 initializes the processing counter C2 (internal counter) (C2 = 1).
This processing counter C2 is used to check the inventory of the products indicated by the product codes of “allocated products (1) to (3)” (product codes of the seller side 300) from the highest priority, that is, “reserve” This is provided for checking in order of “product (1)”, “allocated product (2)”, and “allocated product (3)”.
[0048]
Step S405:
Next, the product management processing unit 320 acquires the product code set in the “transaction product (C2)” indicated by the processing counter C2 in the product data (A-C1) acquired in step S403. Then, the stock quantity of the product corresponding to the product code is acquired from the stock data 312 in the DB memory 310.
If the processing counter C2 = “1”, as shown in FIG. 4, the “stock quantity” = “50” of the product corresponding to the product code “RR0A” set in “allocated product (1)” is set. Will be acquired.
[0049]
Step S406:
Next, the merchandise management processing unit 320 compares the actual order quantity included in the main order request with the inventory quantity acquired in step S405, and determines whether or not the actual order quantity is less than the inventory quantity. To do. As a result of the determination, if “actual order quantity ≦ stock quantity”, the process from step S407 is executed, and if not, the process from step S411 is executed.
[0050]
Step S407:
As a result of the determination in step S406, if “actual order quantity ≦ stock quantity”, the merchandise management processing unit 320 sets “allocated merchandise (C2) for the merchandise data (A-C1) currently being processed. ) Assign a product corresponding to the product code set to “”.
If the processing counter C1 = “1” and the processing counter C2 = “1”, the priority is one for the product “ABC001” (beef-domestic-Japanese beef-peach meat) desired by the buyer 100 (A). The product “RR0A” (peach meat A) of the highest seller side 300 will be allocated.
[0051]
Step S408:
Thereafter, the merchandise management processing unit 320 updates the contents of the stock data 312 in the DB memory 310 according to the actual order quantity (stock quantity = stock quantity-actual order quantity), and the above-described step S403 is performed for the next merchandise data. In order to execute the processing from the above, the processing counter C1 is counted up (C1 = C1 + 1).
[0052]
Step S409:
Then, the merchandise management processing unit 320 determines whether or not the processing counter C1 exceeds the total number m of merchandise data constituting the negotiation data (A) as a result of the count-up in step S408, that is, all merchandise data (A-1 ) To (Am), it is determined whether or not the processing from step S403 has been completed.
As a result of the determination, if the process is completed, the process proceeds to the next step S410, and if not, the process returns to step S403 to repeat the subsequent processes.
[0053]
Step S410:
When the processing for all the product data (A-1) to (Am) constituting the negotiation data (A) is completed, the product management processing unit 320 obtains the product data (A-1) to (A-1) to The allocation information (allocation result information in step S407) for (Am) is output as shipping instruction information. Therefore, the person in charge of shipping on the seller side 300 performs a procedure for shipping the corresponding product to the buyer side 100 (A) based on the shipping instruction information.
[0054]
Step S411:
On the other hand, if “actual order quantity ≦ stock quantity” is not satisfied as a result of the determination in step S406, the merchandise management processing unit 320 counts the process counter C2 in order to check the inventory quantity of the allocated product with the next highest priority. Up (C2 = C2 + 1).
[0055]
Step S412:
Then, the merchandise management processing unit 320 checks the stock quantity as to whether or not the process counter C2 has exceeded “3” as a result of the count-up in step S411, that is, the “priority product (3)” having the lowest priority. It is determined whether or not it has been completed.
As a result of the determination, if the inventory quantity has not been checked until “allocated product (3)”, the process returns to step S405 and the subsequent processing is repeatedly executed. As a result, when the stock amount of the product of “transaction product (1)” is less than the actual order quantity, the stock amount of the product of “transaction product (2)” having the next highest priority is checked. Priority is given, such as when the stock quantity of the product of “trade product (2)” is less than the actual order quantity, the stock quantity of the product of “trade product (3)” having the next highest priority is checked. The stock quantity of the corresponding product on the seller side 300 is checked sequentially in descending order.
In addition, when the inventory amount is checked up to “Allocated product (3)”, this is the inventory amount of all the products indicated by the product codes set in “Transaction products (1) to (3)”. However, this is a case where the actual order quantity desired by the buyer 100 (A) is not satisfied. Therefore, in this case, information (error information) indicating that fact is temporarily stored internally, and the above error information is stored in the process of step S410 after the processes of steps S408 to S409 are executed. Output in shipping instruction information. Thereby, in this case, the person in charge of shipping grasps this situation and performs a procedure for dealing with it.
[0056]
As described above, in the present embodiment, the product code system (first) on the buyer side 100 (X) included in the result of the negotiation between the buyer side 100 (X) and the seller side 300 (negotiation data (X)). For the products indicated by the product code system ("ABC001", etc. "Beef-Domestic-Wagyu Beef-Thigh Meat" etc.), multiple items were selected from the inventory at the seller side 300 in order of priority. A product code ("RR0A", "RR0B"), a product code system (second product code system) on the seller side 300 is assigned to a product ("tread meat A, thigh meat B, thigh meat C", etc.) “RR0C” and the like are stored in the DB memory 310 in association with each other. When the purchase order 100 (X) issues a final order request using the first product code system, the negotiation data (X) corresponding to the final order request specified from the negotiation data stored in the DB memory 310 is stored. ), The allocated product indicated by the second product code system associated with the product indicated by the first product code system is assigned in order of priority.
As a result, even if the product code system on the buyer side 100 (X) is different from that on the seller side 300, the desired product (first product) indicated on the seller side 300 by the main order request from the buyer side 100 (X). Since the product indicated by the code system is automatically associated with the product at the seller side 300 (the product indicated by the second product code system) (the first product code system is the second product code system) It is not necessary to manually manage products such as order management and inventory management as in the past.
[0057]
(Second Embodiment)
In the first embodiment described above, at the time of negotiation between the buyer side 100 (X) and the seller side 300, the person in charge 330 on the seller side 300 corresponds to the seller side 300 corresponding to the product desired by the buyer side 100 (X). As the products, a plurality of products (allocated products (1) to (3)) are selected in descending order of priority.
On the other hand, in the present embodiment, the priority of the plurality of provisioned products is not determined by the person in charge 330 on the seller side 300 but automatically so as to be most effective by the product management processing unit 320. decide.
[0058]
For this reason, the merchandise management processing unit 320 operates as follows, for example, according to the flowchart shown in FIG. 5 before executing the processing at the time of the main order request shown in FIG.
[0059]
Step S500:
As the negotiation data 311 of the DB memory 300, the negotiation data about the buyers 100 (A), 100 (B), 100 (C),... Generated by the negotiation described in the first embodiment ( Assume that A), (B), (C),... Are stored. At this time, the product codes of “transaction products (1) to (2)” set in the respective negotiation data are set in an arbitrary order (order not conscious of the priority).
[0060]
Step S501:
Therefore, first, the product management processing unit 320 converts the negotiation data stored as the negotiation data 311 in the DB memory 300 within a predetermined period set in advance into the currently stored negotiation data (A), (B), ( C)...
[0061]
Step S502:
As a result of the extraction in step S501, for example, as shown in FIG. 6, it is assumed that the negotiation data (B), (D), (F), and (H) are extracted.
Therefore, the merchandise management processing unit 320 has the merchandise data (B-1), (B-2),... Of the negotiation data (B), the merchandise data (D-1), (D- 2), ..., product data (F-1), (F-2), ... of negotiation data (F), and product data (H-1), (H-2) of negotiation data (H) ),... Are sorted in order of product data having a high transaction unit price. As a result, in FIG.
Transaction unit price = "550" (B-5),
Transaction unit price = "530" (H-1),
Transaction unit price = "400" (B-3),
Transaction unit price = "350" (D-2),
Transaction unit price = "340" (F-3),
The product data is sorted in the order of... (Hereinafter referred to as “Sort 1”).
At this time, if product data having the same unit price exists, the process proceeds according to a predetermined priority assigned in advance to the product data. For example, priority is given to the earlier time stored in the DB memory 310.
[0062]
Step S503, Step S504:
Next, the merchandise management processing unit 320 acquires the target merchandise data (Xn) according to the order of the sorting (1) in step S502 (step S503), and is set in the target merchandise data (Xn). “Transaction products (1) to (3)” are sorted in ascending order of cost by referring to the supplyable amount data 313 of the DB memory 310 (hereinafter referred to as “sort 2”) (steps) S504).
Here, as shown in FIG. 6, the supplyable amount data 313 is a product on the seller side 300 such as “RR0A”, “RR0B”, “RR0C”,. Corresponding to the code, “cost” and “suppliable amount (possible amount)” of each product are set.
Therefore, for example, when the target product data is the product data (B-5) having the highest transaction unit price (see FIG. 6 above), the product data includes “transaction products (1) to (3)” as products. Codes “RR0A”, “RR0B”, and “RR0G” are set, and their costs are “200”, “220”, and “190”, so “RR0G”, “RR0A”, and “RR0B” Will be sorted.
[0063]
Step S505, Step S506:
Next, the merchandise management processing unit 320 obtains the “suppliable quantity” of the target merchandise code by referring to the suppliable quantity data 313 in the order of the sorting (2) in step S504 (step S505), By comparing the suppliable amount with the “quantity” (provisional order quantity) of the target product data (Xn), the product of the target product code can be allocated to the target product data (Xn). It is determined whether or not it is possible (step S506).
For example, when the target product data is (B-5) and the target product code is “RR0G” with the lowest cost (see FIG. 6 above), provisional order quantity (200)> suppliable quantity (150) Since there is (cannot be allocated), the process returns to step S505 to check the supplyable amount of the next transaction product (2). At this time, if the allocation is possible (provisional order quantity ≦ suppliable quantity), the process proceeds to the next step S507.
[0064]
Step S507, Step S508:
As a result of the determination in step S506, if it is possible to allocate the product of the target product code to the target product data (Xn), the product management processing unit 320 determines the provision (step S507), The “suppliable quantity” of the target product code is updated based on the provisional order quantity of the target product data (X−n) (suppliable quantity = suppliable quantity−provisional order quantity) (step S508).
[0065]
Step S509:
Then, the merchandise management processing unit 320 determines whether or not there is a merchandise code to be processed next. If there is a merchandise code, the process returns to step S503 and repeats the subsequent processing steps. End.
[0066]
As described above, in the present embodiment, in each product data constituting each negotiation data within a predetermined period, first, each product data is sorted in descending order of transaction unit price, and according to the order, Sorting the products indicated by the transaction products (1) to (3) (items on the seller side 300) in ascending order of cost, and assigning products satisfying the provisional order quantity of the target product data to the target product data according to the order. To decide.
Thereby, each product data can be processed in the order advantageous to the seller side 300, and the transaction products (1) to (3) in the respective product data are also processed in the order advantageous to the seller side 300. Can be allocated to product data. That is, before the purchase order is issued from the buyer side (before the shipment for actually allocating the product), the priority of the transaction products (1) to (3) most advantageous to the seller side 300 is automatically set to Each product data of the negotiation data can be provided, and products can be allocated in the order of priority.
Further, since the order status (provisional order status) from the buyer side can be grasped in advance by the suppliable amount data 313 of the DB memory 310, for example, what product is currently provided to the buyer side, It is possible to know in advance whether the seller side 300 is most advantageous. Thereby, the person in charge 330 of the seller side 300 can perform the most efficient sales activity according to the situation at that time.
Furthermore, since the remaining product can be predicted early, the sales form for the remaining product can be changed to the most efficient form early. For example, products such as meat that have become a residual product will be frozen at that time, so the price will drop, but if the prediction can be made in advance, it will be higher than the price after freezing before freezing Can be sold at a price. Furthermore, the aforementioned negotiation cycle can be accelerated, which is advantageous for both the seller and the buyer.
[0067]
As a modification of the above-described second embodiment, for example, the product codes of the seller side 300 are sorted in descending order of cost, and the buyer side 100 (A), 100 (B),. The product data of the negotiation data (A), (B),... May be sorted in descending order of transaction unit price, and the above-described product allocation may be performed in accordance with the order.
[0068]
Further, in the first and second embodiments described above, the processing shown in FIG. 3 (product allocation processing) is executed in the order in which the order request is issued. However, the present invention is not limited to this. For example, priority may be given to the buyer side, and processing may be executed according to the priority.
In addition, although the target product is “Meat” here, it is not limited to this. For example, the present invention can be applied to products with a limited expiration date and a predetermined supply amount, such as fresh products such as vegetables and meat, air tickets, and concert tickets.
[0069]
Another object of the present invention is to supply a storage medium storing software program codes for realizing the functions of the host and terminal of each of the above-described embodiments to a system or apparatus, and the computer (or CPU) of the system or apparatus. Needless to say, this can also be achieved by reading and executing the program code stored in the storage medium. In this case, the program code itself read from the storage medium implements the functions of the respective embodiments, and the storage medium storing the program code constitutes the present invention.
A ROM, floppy disk, hard disk, optical disk, magneto-optical disk, CD-ROM, CD-R, magnetic tape, nonvolatile memory card, or the like can be used as a storage medium for supplying the program code.
Further, by executing the program code read by the computer, not only the functions of the respective embodiments are realized, but also the OS or the like running on the computer based on the instruction of the program code performs the actual processing. It goes without saying that a case where the functions of the respective embodiments are realized by performing part or all of the above and the processing thereof is included.
Further, after the program code read from the storage medium is written to the memory provided in the extension function board inserted in the computer or the function extension unit connected to the computer, the function extension is performed based on the instruction of the program code. It goes without saying that the case where the CPU or the like provided in the board or function expansion unit performs part or all of the actual processing and the functions of the respective embodiments are realized by the processing.
[0070]
【The invention's effect】
As described above, in the present invention, even if the product code system on the buyer side and the product code system on the seller side are different, the seller side uses the product code system on the buyer side to By associating with a code based on the product code system, the merchandise management on the seller side can be electronically performed with the code.
[0071]
Specifically, for example, the product indicated by the first code on the buyer side included in the result of the negotiation between the buyer side and the seller side (negotiation information) ("Beef-Domestic-Wagyu beef indicated by" ABC001 ") -Fresh products such as “thigh meat”, etc., a plurality of products selected in order of priority from stock products on the seller's side (“peach meat A, thigh meat further classified with respect to the product classification on the buyer side” B, provisional products such as peach meat C ") are stored in the negotiation information memory in association with the second code (" RR0A "," RR0B "," RR0C ", etc.) on the seller side. Then, when the main order request with the first code is issued from the buyer side, it is indicated by the first code in the negotiation information corresponding to the main order request specified from the negotiation information stored in the negotiation information memory. The allocated product indicated by the second code associated with the assigned product is assigned in order of priority.
As a result, for the target product, one product such as “beef-domestic-Japanese beef-thigh meat” on the buyer side is further classified on the seller side by quality information (such as information on the grains used for breeding). The product code system is unified on the buyer side and the seller side because it is a product corresponding to n products such as peach meat A, peach meat B, peach meat C, ... Even if it is not possible to do so, on the seller side, the desired product (the product indicated by the first code) indicated by the purchase order request from the buyer side is indicated by the second side code (the product indicated by the first code). Merchandise) automatically (interpretation function in which the first code is automatically recognized by the second code), so that the seller can manage products such as order management and inventory management as before. There is no need to do this manually.
[0072]
In addition, in a plurality of negotiation information stored in the negotiation information memory within a predetermined period, the allocation processing order is determined based on the product information (transaction unit price, etc.) of each negotiation information (priority is determined in descending order of transaction unit price) In accordance with the allocation process order, the allocation process order of a plurality of second codes associated with the first code in the target negotiation information is changed to the supplyable product information corresponding to each second code (product Cost, etc.) (priorities are determined in descending order of product cost, etc.), and in accordance with the order of allocation processing, a plurality of products associated with the product indicated by the first code of the target negotiation information The second coats are allocated in order.
Accordingly, the respective negotiation information can be allocated in an order that is advantageous to the seller, and the merchandise on the seller (the product indicated by the second code) is advantageous to the seller for each of the negotiation information. Can be allocated in any order.
Further, by updating the suppliable product information in the suppliable information memory according to the contents of the negotiation information, it is possible to grasp the order status (provisional order status) from the buyer in advance from the update result. Therefore, for example, it is possible to grasp in advance which product is currently most advantageous to the seller if it is provided to the buyer. Thereby, the person in charge on the seller side can perform the most efficient business activity according to the situation at that time.
Furthermore, since the remaining product can be predicted early, the sales form for the remaining product can be changed to the most efficient form early. For example, products such as meat that has become a residual product will be frozen at that time, so the price will drop, but if the prediction can be made in advance, the price after freezing will be higher Can be sold at a price. Furthermore, the negotiation cycle between the buyer side and the seller side can be accelerated, which is advantageous for both the seller side and the buyer side.
[0073]
Therefore, according to the present invention, even if the expiration date is limited and the supply amount is determined in advance, such as fresh products such as meat and air tickets, the product management is performed between the seller side and the buyer. Can be done easily and efficiently on each of the sides.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration of a product management system to which the present invention is applied in a first embodiment.
FIG. 2 is a diagram for explaining negotiation data on a buyer side generated at the time of negotiation in the commodity management system.
FIG. 3 is a flowchart for explaining processing for assigning a product indicated by a seller-side product code to a product indicated by a buyer-side product code included in the negotiation data.
FIG. 4 is a diagram for explaining a specific example of the allocation process;
FIG. 5 automatically determines priorities of a plurality of products indicated by a seller-side product code to be allocated to a product indicated by a buyer-side product code after the negotiation in the second embodiment; It is a flowchart for demonstrating the process for this.
FIG. 6 is a diagram for explaining a specific example of the priority determination process.
FIG. 7 is a diagram for explaining classification of commodities on a general buyer side (supermarket or the like).
FIG. 8 is a diagram for explaining a difference in classification for merchandise on the seller side (manufacturer side) with respect to classification for merchandise on the buyer side.
[Explanation of symbols]
10 Product management system
100 (A), 100 (B), ... Buyer side
101 (A) Buyer's person in charge
200 Distribution center
300 Seller side
310 Database memory
311 Business data
312 Inventory data
313 Supplyable amount data
320 Product management processing unit
330 Seller's representative
340 terminal device

Claims

Based on the negotiation information including the information of the commodity indicated by the first code according to the first commodity code system on the buyer side, which is determined by the negotiation with the buyer side which is the shipping destination of the commodity, A merchandise management device on the seller side that allocates a corresponding product from a stock product to the product indicated by the code of 1;
Stock information storage means for storing information on the stock products in correspondence with a second code according to a second product code system on the seller side;
The negotiation information that stores a plurality of the second codes indicating a plurality of types of inventory products selected as the products corresponding to the products indicated by the first code of the negotiation information in association with the first code. Storage means;
Based on the inventory product information stored in the inventory information storage means, the product indicated by the first code of the negotiation information stored in the negotiation information storage means is associated with the first code. A merchandise management device comprising merchandise allocation means for allocating a plurality of types of inventory merchandise indicated by the plurality of second codes in a predetermined order.

The commodity management apparatus according to claim 1, wherein the predetermined order includes a priority order added to each of the plurality of second codes.

When the purchase order side issues a final order request for the product indicated by the second code, the product allocation unit is configured to store the negotiation information stored in the negotiation information storage unit corresponding to the final order request. The merchandise management apparatus according to claim 1, wherein the process is executed.

The merchandise management apparatus according to claim 1, wherein the merchandise includes a merchandise having a limited expiration date and a predetermined amount that can be supplied to the buyer.

Supplyable information storage means for storing information on products that can be supplied to the buyer side in association with the second code;
First determining means for determining an order for allocating a plurality of negotiation information stored in the negotiation information storage means within a predetermined period based on product information included in the negotiation information;
According to the processing order determined by the first determining means, the allocation processing order of the plurality of second codes associated with the target negotiation information is added to the supplyable product information stored in the supplyable information storage means. The merchandise management apparatus according to claim 1, further comprising: a second determination unit that determines based on the second determination unit.

The supply available product information includes cost information of the product,
6. The merchandise management apparatus according to claim 5, wherein the merchandise information of the negotiation information includes a transaction unit price with the buyer.

A merchandise management system including a buyer side that manages merchandise with a first code according to a first merchandise code system and a seller side that manages merchandise with a second code according to a second merchandise code system. And
The merchandise management system, wherein the seller side has the function of the merchandise management apparatus according to any one of claims 1 to 6.

The seller side for managing the product supplied to the buyer who manages the product with the first code according to the first product code system by the second code according to the second product code system A product management method,
A stock information storage step for storing stock product information in a stock information memory in association with the second code;
The negotiation information including the information of the commodity indicated by the first code determined by the negotiation with the buyer side is a plurality of the second items indicating a plurality of types of inventory products selected as the commodity corresponding to the commodity. A negotiation information storage step for storing the information in the negotiation information memory in association with the code;
Based on the inventory product information stored in the inventory information memory, the product associated with the first code for the product indicated by the first code of the negotiation information stored in the negotiation information memory. A merchandise management method comprising a merchandise allocation step of allocating a plurality of types of stock merchandise indicated by a plurality of second codes in a predetermined order.

9. The product management according to claim 8, wherein the product allocation step includes a step of executing the allocation process with the predetermined order as the order of priority added to each of the plurality of second codes. Method.

In the product allocation step, when the final order request for the product indicated by the second code is issued from the buyer side, the negotiation information stored in the negotiation information memory corresponding to the final order request is The product management method according to claim 8, further comprising a step of executing a process.

9. The merchandise management method according to claim 8, wherein the merchandise has a limited expiry date and includes merchandise for which a supplyable amount for the buyer is determined in advance.

A supplyable information storage step for storing information on products that can be supplied to the buyer in the supplyable information memory in association with the second code, and a plurality of information stored in the negotiation information storage memory within a predetermined period A first determination step for determining the order of allocation processing of the negotiation information based on the product information included in the negotiation information;
In accordance with the processing order determined in the first determination step, the allocation processing order of the plurality of second codes associated with the target negotiation information is based on the supplyable product information stored in the supplyable information memory. The merchandise management method according to claim 8, further comprising a second determination step of determining by the following.

The supply available product information includes cost information of the product,
13. The merchandise management method according to claim 12, wherein the merchandise information of the negotiation information includes a transaction unit price with the buyer.

14. A storage medium in which processing steps of the merchandise management method according to claim 8 are stored in a computer-readable manner.