JP2004005119A

JP2004005119A - 受発注支援方法、受発注支援サーバ、受発注支援システム、受発注支援プログラム

Info

Publication number: JP2004005119A
Application number: JP2002159010A
Authority: JP
Inventors: Shinobu Hosoyama; 細山　忍; Takami Tanaka; 田中　隆美; Takao Miyoshi; 三好　隆生
Original assignee: Fujitsu FIP Corp
Current assignee: Fujitsu FIP Corp
Priority date: 2002-05-31
Filing date: 2002-05-31
Publication date: 2004-01-08

Abstract

【課題】初期投資やＩＴスキルの要員を不要にして、各店舗の商品発注ノウハウを自動的に蓄積、利用することを可能とする（各店舗の仕入れ担当者の経験等による店舗の売上への影響をなくする）と共に、大手小売店並の取引条件で商品提供を可能とする受発注支援方法、受発注支援サーバ、受発注支援システム、受発注支援プログラムを提供する
【解決手段】店舗本部（６２）が各店舗クライアント（６４Ａ、６４Ｍ）との発注に関する情報を設定するとともに、各取引先（６８Ａ、６８Ｎ）との取引に関する情報を設定する情報設定段階と、前記受発注支援サーバ（１２）が保持する発注に関する前記店舗毎の発注情報を前記店舗クライアントに送信する発注情報送信段階と、前記店舗クライアントに発注処理を行わせる発注蓄積処理段階とを有する。
【選択図】図３

Description

【０００１】
【発明の属する技術分野】
【従来の技術】
スーパーやコンビニエンスストア等の小売り店舗販売では、各店舗の立地環境に合った商品を品揃えをし、適当な価格で、継続的（品切れのない）に販売することで、顧客に安心して買い物をして貰うことが重要である。
【０００２】
このため、大手スーパー等では、商品種別に複数の担当者が、過去の販売情報や在庫情報等のＤＢ等の情報をもとに、商品の発注を行っている。
【０００３】
また、コンビニエンスストアでは、本部で各店舗の商品構成や発注のマニュアルを定め、各店舗で、マニュアルで指定された時刻に、店長の指導を受けたアルバイト等の店員が店舗の売り棚にある商品数が、指定された数量以下になった商品を、指定された数量の発注を行っていた。
【０００４】
【発明が解決しようとする課題】
しかしながら、中小のチェーンストアのスーパー等では、販売情報や過去の発注情報を基に発注を決める支援システムの構築、その運用等のＩＴスキルを持った要員の確保や初期投資等が難しいと言う問題がありシステム化ができない。
【０００５】
その結果、各店舗の売上が、仕入れ担当の個々人の経験等に依存すると言う問題があった。
【０００６】
商品発注担当者の病気、事故等や他店舗等への異動等があった場合、各店舗の販売成績に直接影響すると言う問題があった。また、大手の取引先の受注の方法が既にコンピュータ化されており、電子データ以外の方法であるＦＡＸや電話での発注を受け付けてくれないため、商品を直接仕入れることができず、問屋等を経由して仕入れることになり他社店舗と競合できないと言う問題があった。
【０００７】
更に、中小のチェーンストアのスーパー等では、店舗数も少なく、各店舗の販売量も少ないため、商品を納入する業者から見れば、小口の取引者となり、取引条件上、不利になると言う問題もあった。
【０００８】
本発明は、このような問題点に鑑み、初期投資やＩＴスキルの要員を不要にして、各店舗の商品発注ノウハウを自動的に蓄積、利用することを可能とする（各店舗の仕入れ担当者の経験等による店舗の売上への影響をなくする）と共に、サーバ（ＡＳＰサービスで提供）に多くの複数のチェーンストアが参加することにより、商品を当該サーバを通じて提供する取引社から見れば、大手小売店並の取引条件で商品提供を可能とする、受発注支援方法、受発注支援サーバ、受発注支援システム、受発注支援プログラムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
請求項１に記載の発明は、商品を発注する店舗クライアントと、商品を受注する取引先クライアントとが受発注をするための支援を行う受発注支援サーバで、受発注の支援をする受発注支援方法であって、店舗本部が各店舗クライアントとの発注に関する情報を設定するとともに、各取引先との取引に関する情報を設定する情報設定段階と、前記受発注支援サーバが保持する発注に関する前記店舗毎の発注情報を前記店舗クライアントに送信する発注情報送信段階と、前記店舗クライアントに発注処理を行わせる発注蓄積処理段階とを有することを特徴とする。
【００１０】
請求項１によれば、初期投資やＩＴスキルの要員を不要にして、各店舗の商品発注ノウハウを自動的に蓄積、利用することを可能とする（各店舗の仕入れ担当者の経験等による店舗の売上への影響をなくする）と共に、大手小売店並の取引条件で商品提供を可能とする受発注支援方法が提供できる。
【００１１】
請求項２に記載の発明は、さらに、前記取引先クライアントに受注処理を行わせる受注処理段階を有することを特徴とする。
【００１２】
請求項２によれば、発注だけではなく、取引先の受注も可能とする受発注支援方法が提供できる。
【００１３】
請求項３に記載の発明は、前記発注情報送信段階は、前記発注情報として、予め定められた日時と、前記商品の送信日時とが一致した場合、所定の商品情報を送信することを特徴とする。
【００１４】
請求項３によれば、発注者は、周期的に発注する商品を、日々絶えず考慮しながら商品一覧表から探して、商品情報を送信する必要が無くなる。また不慣れな発注者でも周期的に発注する商品情報が素早く表示されるので、簡易な操作で発注業務を行うことが可能な受発注支援方法が提供できる。
【００１５】
請求項４に記載の発明は、前記発注情報送信段階は、前記発注情報として、該クライアントが以前に発注した商品情報を送信することを特徴とする。
【００１６】
請求項４によれば、発注者は、過去に発注した商品を再度、商品情報一覧表から探して、商品情報を送信する必要が無くなる。また、不慣れな発注者でも、過去に発注した商品情報が素早く表示されるので、簡易な操作で発注業務を行うことが可能となる。
【００１７】
請求項５に記載の発明は、前記受注処理段階は、前記店舗クライアントが、所定のグループに属する場合、該グループには無関係に、該取引先クライアントが所望する店舗クライアントの発注情報を送信することを特徴とする。
【００１８】
請求項５によれば、従来は、店舗クライアントの発注情報を確認する際に、店舗クライアントのグループが異なるごとに、サーバにログオンしなければならなかったが、店舗の属するグループが異なっても、改めてサーバにログオンする必要のない受発注支援方法を提供することができる。
【００１９】
請求項６に記載の発明は、前記受注処理段階は、複数の店舗クライアントから受注した商品の受注量が、該商品の在庫量を上回った場合、前記店舗クライアントごとに予め定められた店舗重要度情報に応じて、前記商品を在庫量の範囲で割り当てることを特徴とする。
【００２０】
請求項６によれば、在庫商品が不足した場合、店舗クライアントに応じて最適な配分を行い、調整することが可能な受発注支援方法を提供することができる。
【００２１】
請求項７に記載の発明は、商品を発注する店舗クライアントと、商品を受注する取引先クライアントとが受発注をするための支援を行う受発注支援サーバであって、店舗本部が各店舗クライアントとの発注に関する情報を設定するとともに、各取引先との取引に関する情報を設定する情報設定手段と、前記店舗毎の発注に関する発注情報を前記店舗クライアントに送信する発注情報送信手段と、前記店舗クライアントに発注処理を行わせる発注蓄積処理手段と、前記取引先クライアントに受注処理を行わせる受注処理手段とを有することを特徴とする。
【００２２】
請求項７によれば、初期投資やＩＴスキルの要員を不要にして、各店舗の商品発注ノウハウを自動的に蓄積、利用することを可能とする（各店舗の仕入れ担当者の経験等による店舗の売上への影響をなくする）と共に、大手小売店並の取引条件で商品提供を可能とする受発注支援サーバが提供できる。
【００２３】
請求項８に記載の発明は、商品を発注する店舗クライアントと、商品を受注する取引先クライアントとが受発注をするための支援を行う受発注支援サーバとを有する受発注支援システムにおいて、店舗本部が各店舗クライアントとの発注に関する情報を設定するとともに、各取引先との取引に関する情報を設定する情報設定手段と、前記受発注支援サーバは、保持する前記店舗毎の発注に関する発注情報を前記店舗クライアントに送信する発注情報送信手段と、前記店舗クライアントから発注を、発注情報として保持・蓄積する手段と、該発注情報を前記取引先クライアントに通知する手段とを有し、前記店舗クライアントは、前記取引先に対する発注を、前記発注支援サーバに発注する手段を有し、前記取引先クライアントは、前記発注情報を前記発注支援サーバから受信する手段とを有することを特徴とする。
【００２４】
請求項８によれば、初期投資やＩＴスキルの要員を不要にして、各店舗の商品発注ノウハウを自動的に蓄積、利用することを可能とする（各店舗の仕入れ担当者の経験等による店舗の売上への影響をなくする）と共に、大手小売店並の取引条件で商品提供を可能とする受発注支援システムが提供できる。
【００２５】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
【００２６】
本発明の実施の形態における受発注支援システムの全体構成を図１に示す。図１に示されるように、受発注支援システム１０は、受発注支援サーバ１２と、店舗クライアント１４と、受発注支援サーバを管理するセンタクライアント１５と、取引先クライアント１６と、それらを接続するネットワーク１８とを含むように構成される。
【００２７】
この図１はシステム構成を分かりやすくするために店舗クライアントと取引先クライアントは一つずつしか描いていないが、通常の取引では、いずれのクライアントも複数であることが多い。複数の場合の構成および詳細な説明は図３の説明で行う。
【００２８】
次に、上記クライアント１４、１５、１６や受発注支援サーバ１２のコンピュータのハードウェア構成図を図２に示す。
【００２９】
図２に示されるハードウェア構成は、それぞれバスＢで相互に接続されている入力装置２２と，表示装置２３と，ドライブ装置２４と，記録媒体２５と，補助記憶装置２６と，メモリ装置２７と，演算処理装置２０と，インタフェース装置２１とを含むように構成される。
【００３０】
入力装置２２は、コンピュータの利用者が操作するキーボード及びマウスなどで構成され、コンピュータに各種操作信号を入力するために用いられる。表示装置２３は、コンピュータを操作するのに必要な各種ウインドウやデータ等を表示する。インタフェース装置２１は、コンピュータをネットワークに接続する為のインタフェースであり、例えばＮＩＣ（Ｎｅｔｗｏｒｋ　Ｉｎｔｅｒｆａｃｅ　Ｃａｒｄ）やモデム等で構成される。
【００３１】
そして、上記コンピュータを動作させるためのプログラムは、ＣＤ−ＲＯＭ等の記録媒体２５によって提供されるか、ネットワーク１８を通じてダウンロードされる。また、記録媒体２５は、ドライブ装置２４にセットされ、データやプログラムが記録媒体２５からドライブ装置２４を介して補助記憶装置２６にインストールされる。
【００３２】
補助記憶装置２６は、データやプログラムを格納すると共に、必要なファイル等を格納する。メモリ装置２７は、コンピュータの起動時に補助記憶装置２６からプログラムを読み出して格納する。演算処理装置２０は、メモリ装置２７に読み出され格納されたプログラムに従って処理を実行する。
【００３３】
次に、図３を用いて、受発注支援システム１０の詳細な説明を行う。図３に示される受発注支援システム１０は、図の左から順に本部と店舗からなる複数のチェーンストア６６Ａ、…、６６Ｌ、次にネットワーク１８、受発注支援サーバ１２、ネットワーク１８、複数の取引先グループ７０Ａ、…、７０Ｌとなっている。
【００３４】
以下、チェーンストア６６Ａ、…、６６Ｌ、取引先グループ７０Ａ、…、７０Ｌ、受発注支援サーバ１２の順に説明する。
【００３５】
ここでのチェーンストアとは、例えば、Ａスーパーという商号をもち、東京に本部があるスーパーで、大阪と仙台に店舗をもつチェーン店のように、本部と店舗のグループを示している。図の場合のチェーンストア６６Ａは、本部６２と店舗６４Ａと店舗６４Ｍからなる。また、チェーンストア６６Ｌも同様に本部と店舗からなるチェーン店である。
【００３６】
次に取引先の説明をする。取引先７０Ａ、７０Ｌのうち、取引先グループ７０Ａは、取引先６８Ａから取引先６８Ｎを含む取引先の集合である。
【００３７】
また、この取引先グループは、各チェーン店に対応して作られたグループである。これを具体的に説明する。あるチェーン店Ａは、取引先として、取引先Ａ、取引先Ｂ、取引先Ｃと取引しているとする。また他のチェーン店Ｂは、取引先として、取引先Ａ、取引先Ｃ、取引先Ｄと取引しているとする。このような場合、取引先グループは、チェーン店Ａに対応した（取引先Ａ、取引先Ｂ、取引先Ｃ）と、チェーン店Ｂに対応した（取引先Ａ、取引先Ｃ、取引先Ｄ）という２つの取引先グループとなる。図の場合、取引先グループ７０Ａは、取引先６８Ａ、…、６８Ｎからなり、チェーン店６６Ａに対応した取引先グループである。また、同様に取引先グループ７０Ｌは、チェーン店６６Ｌに対応した取引先グループである。
【００３８】
次に、受発注支援サーバ１２の説明をする。受発注支援サーバ１２は、図に示されるように、大きく分けて、制御や処理を行うソフトウェアブロック７２とマスタやデータベース（以下ＤＢと記す）からなるデータ群で構成される。このうち、まずソフトウェアブロック７２から説明する。ソフトウェアブロック７２は、ユーザ制御部３０と、サイクル発注処理部３２と、実績発注処理部３４と、取引状況照会処理部３６と、出荷訂正処理部３８とを有する。このうち、ユーザ制御部３０は、受発注支援サーバ１２に接続するユーザの制御を行う。サイクル発注処理部３２と実績発注処理部３４は、後述する発注処理を行う。取引状況照会処理部３６は、取引先とチェーン店の取引状況を照会する処理を行う。出荷訂正処理部３８は、発注と在庫を調整し出荷するための処理を行う。
【００３９】
次に、データ群について説明する。受発注支援サーバ１２は、チェーンストア識別マスタ４０と、取引先管理テーブル４２と、取引先データ５０Ａ、…、５０Ｎと、リンクデータ６０Ａ、…、６０Ｌを有する。
【００４０】
このうち、取引先データ５０Ａ、…、５０Ｎは、それぞれ在庫ＤＢと重要度テーブルと重みテーブルとを有する。特に、取引先データ５０Ａは、在庫ＤＢ４４と重要度テーブル４６と重みテーブル４８とを有する。
【００４１】
また、リンクデータ６０Ａ、…、６０Ｌは、それぞれサイクル発注マスタと、発注実績ＤＢと取引先マスタと商品マスタとを有する。特にリンクデータ６０Ａは、サイクル発注マスタ５４と、発注実績ＤＢ５２と取引先マスタ５６と商品マスタ５８とを有する。
【００４２】
以上説明したデータのうち、チェーンストア識別マスタ４０と、取引先マスタ５６と商品マスタ５８の基本的なデータの説明をし、その他のデータは後に詳しく説明する。
【００４３】
まずチェーンストア識別マスタ４０について図４を用いて説明する。チェーンストア識別マスタ４０は、チェーンストア識別コードと、それに対応したチェーンストア名とを含むマスタであり、チェーンストアの管理に用いる。
【００４４】
次に、取引先マスタ５６について図５を用いて説明する。取引先マスタ５６は、チェーンストア識別コードと、取引先コードと、それに対応した取引先名とを含むマスタであり、取引先の管理に用いるマスタである。また、チェーンストア識別コードを含むのは、取引先マスタ５６は、図３に示されるようにチェーンストア別に管理されることによる。
【００４５】
次に、商品マスタ５８について、図６を用いて説明する。商品マスタ５８は、チェーンストア識別コードと、取引先コードと、商品コードと、それに対応した商品名と、商品の仕入れ価格と、商品の販売価格とを含むマスタであり、商品の管理に用いるマスタである。また、商品マスタ５８がチェーンストア識別コードを含むのは、商品マスタ５８が、図３に示されるようにチェーンストア別に管理されることによる。また、取引先コードを含むのは、商品を取り扱っている取引先と関連付けるためである。
【００４６】
以上で受発注支援システム１０の構成の説明を終え、次に、実際の発注処理についてフローチャートを用いながら説明する。
【００４７】
図７は、受発注支援サーバ１２へ店舗あるいは取引先のクライアントから接続された時のフローチャートである。クライアントが受発注支援サーバ１２へアクセスすると、受発注支援サーバ１２は、ユーザＩＤ／パスワード入力画面をクライアントに表示し、ユーザＩＤとパスワードの入力を促す。ステップＳ１０２で、受発注支援サーバ１２は、ユーザＩＤとパスワードにより正規のユーザではないと判断した場合、ステップＳ１０１に処理を戻し、再びユーザ名とパスワードの入力を促す。ステップＳ１０２で、受発注支援サーバ１２は、正規のユーザであると判断した場合、ステップＳ１０３のユーザ属性の判断を行う。この処理は、接続されたユーザが、店舗クライアントか、取引先クライアントであるかを判断し、更に、ユーザが属する店舗または、取引先を特定する処理である。
【００４８】
ユーザがチェーンストアの場合、受発注支援サーバ１２は、ステップＳ１０４で、選択されたチェーンストアのメニューにより、ステップＳ１０５、ステップＳ１０６、ステップＳ１０７、ステップＳ１０８のいずれかの処理を実行する。
【００４９】
ユーザが取引先の場合、受発注支援サーバ１２は、図２０のステップＳ１０９で、選択された取引先のメニューにより、ステップＳ１１０の取引状況照会処理、ステップＳ１１１の出荷報告訂正処理、ステップＳ１１２の取引先登録処理、ステップＳ１１１その他の処理のいずれかの処理を実行する。このうちステップＳ１１０の取引先登録処理は、初めての取引先が自らを登録するための処理である。
【００５０】
図７のフローチャートにおいて、ユーザが、受発注支援サーバ１２を管理するセンタの場合、図２１のステップＳ１１４で、選択されたセンタのメニューにより、ステップＳ１１５のチェーンストア登録管理処理、ステップＳ１１６の取引先登録管理処理、ステップＳ１１７の課金管理処理、ステップＳ１１１その他の処理のいずれかの処理を実行する。
【００５１】
これら３つのユーザに対応した処理のうち、まずチェーンストアの場合のステップＳ１０５の発注処理について説明する。従来の発注処理において、発注者が発注対象の商品の一覧を表示する場合、分類コードによって、一覧表内に表示される商品をある程度絞ることができる。しかし、発注しようとする商品が、一覧表内で散在していることが多く不便であった。また、陳列棚の商品を見ながら発注するコンビニエンスストアと違い、多くの商品アイテムの中から、分類コード等で抽出表示した商品一覧を見ながら発注を行う小売業者では、発注対象の商品を素早く抽出表示する必要があった。
【００５２】
そのため、本実施の形態におけるチェーンストアの発注処理は、通常の発注処理の他に、サイクル発注処理と実績発注処理の２つの発注処理を行うことができる。サイクル発注処理とは、所定の期間ごとに発注する処理であり、実績発注処理とは、以前に発注した実績に基づき発注する処理である。
【００５３】
図８にサイクル発注マスタ３４を示す。サイクル発注マスタ３４は、図に示すように、３階層構造である。第１階層は、図４で説明したチェーンストア識別マスタ４０である。第２階層は、チェーンストア識別コード、パターンコード、パターン名、起点日、サイクルを有する構造となっている。このうち、パターンコードとは、第２階層に示されるように、例えば「牛乳特売デー」というパターン名に対応するコードである。また、第２階層に示されるサイクルとは、サイクルに示された日数の期間ごとに発注を行うためのデータである。そして、起点日とは、そのパターンで発注を行う最初の日付である。このサイクル発注の例を挙げると、４月１日を起点日とし、サイクルを７日とすると、発注日は、４月１日、４月８日、４月１５日、４月２２日…というように、発注日は（起点日＋サイクル×自然数）となる。
【００５４】
第３階層は、パターンコードと商品コードと商品名からなる構造となっている。このように、サイクル発注マスタ３４は、第１階層と第２階層が、チェーンストア識別コードで、第２階層と第３階層が、パターンコードで対応付けられる。そして「上位レコード数：下位レコード数＝１：ｎ」の階層構造を取る。
【００５５】
次に、実績発注処理について説明する。図９は、発注実績ＤＢ５２を示している。発注実績ＤＢ５２は、チェーンストア識別コードと、店舗コードと、発注年月日と、曜日と、商品コードと、便と、商品名と、取引先コードと、発注数量とを有するＤＢとなっている。このうち、便とは、第何便で入荷したかを示しており、この図では、全て第１便となっている。
【００５６】
このように、発注実績ＤＢ５２は、いつ、どの商品を、いくつ入荷したかが一目で分かるＤＢとなっている。このＤＢに基づき発注を行うのが、実績発注処理である。
【００５７】
受発注支援サーバ１２は、これら２種類の情報を発注情報として店舗クライアントに送信する。
【００５８】
次に、２種類の発注を行うための処理を、図１０のフローチャートを用いて説明する。受発注支援サーバ１２は、ステップＳ２０１で、処理に必要な日付を得るために、実行日付を取得する。次に、受発注支援サーバ１２は、ステップＳ２０２で、サイクル発注マスタ５４を１レコードずつ読み込む。そしてステップＳ２０３で、受発注支援サーバ１２は、サイクル発注マスタ５４のレコード全ての読み込みが終了したかどうか判断し、終了であればステップＳ２０６へ処理を進める。読み込みが終了でなければ、受発注支援サーバ１２は、ステップＳ２０４へ処理を進め、読み込んだ１レコードの発注日が当日であるかどうか判断する。もし、当日であれば、受発注支援サーバ１２は、ステップＳ２０５でサイクル発注商品情報を取得し、再びステップＳ２０２へ処理を進める。ステップＳ２０４で、受発注支援サーバ１２は、発注日の当日ではないと判断した場合、再びステップＳ２０２へ処理を進める。
【００５９】
このようにして、受発注支援サーバ１２はサイクル発注に関する処理を終え、次にステップＳ２０６から発注実績ＤＢ５２を用いた発注処理を行う。ステップＳ２０６で、受発注支援サーバ１２は、ユーザに過去の実績で参照する範囲を前週あるいは前月から選択させる。ステップＳ２０７で、受発注支援サーバ１２は、選択された範囲に基づき、発注実績ＤＢ５２を読み込む。そしてステップＳ２０８で、受発注支援サーバ１２は、発注実績ＤＢ５２の全ての読み込みが終了したかどうか判断し、終了であればステップＳ２１１へ処理を進める。読み込みが終了でなければ、受発注支援サーバ１２は、ステップＳ２０９へ処理を進め、読み込んだ１レコードの発注日が当日であるかどうか判断する。もし、当日であれば、受発注支援サーバ１２は、ステップＳ２１０で実績発注商品情報を取得し、再びステップＳ２０６へ処理を進める。ステップＳ２０９で、受発注支援サーバ１２は、発注日が当日ではないと判断した場合、再びステップＳ２０７へ処理を進める。
【００６０】
以上の処理により、ステップＳ２０８で終了と判断され、実績発注商品情報に関する処理を終えると、受発注支援サーバ１２は、サイクル発注商品情報または実績発注商品情報があったかどうかステップＳ２１１で判定する。サイクル発注商品情報または実績発注商品情報があった場合、受発注支援サーバ１２は、ステップＳ２１２に処理を進め、後述する発注画面を表示する。サイクル発注商品情報または実績発注商品情報がなかった場合、受発注支援サーバ１２は、ステップＳ２１３に処理を進め、発注該当商品がなかったことを表示する。そして、受発注支援サーバ１２は、ステップＳ２１４で今回の発注数量の入力をユーザにより行われることで処理を終了する。
【００６１】
図１１に発注画面を示し、▲１▼〜▲４▼を用いて説明する。▲１▼は、サイクル発注マスタ、および発注実績ＤＢ（累積分）からのデータによる、「サイクル」〜「実績数量」の表示を示している。この時、サイクル該当日でなく通常の実績発注の場合は、「サイクル」、および「起点日からの期間」は、「−」（ハイフン）で表示される。（図の３行目）
次に、発注者は、サイクル発注実績や通常の発注実績を比較しながら、今回の発注数量▲２▼を入力する。
【００６２】
なお、前回発注が、どちらか一方の場合は、片方のみの表示となり、両方有りの場合は、▲３▼のように、サイクル発注の発注情報が優先的に表示される。また、▲４▼の前回実績日付を変更し、検索ボタンを押下すると、指定日付の発注実績が表示される。このとき、サイクル発注マスタ３４より読込んだ内容の再表示は行なわない。
【００６３】
このように、サイクル発注商品情報または実績発注商品情報に基づく発注方法を用いることにより、商品の発注担当者が、発注対象の商品の一覧を、素早く表示でき、発注作業の効率を上げることができる。また、必ずしも発注作業経験の豊かな担当者でなくても、発注作業が実施可能となる。
【００６４】
以上で発注処理の説明を終え、次に、ステップＳ１０６（図７参照）の取引先マスタ更新処理について図２２を用いて説明をする。
【００６５】
ステップＳ５０１で、受発注支援サーバ１２は、取引先を登録／変更／削除のいずれかを行うかで処理を分岐する。登録の場合、受発注支援サーバ１２は、ステップＳ５０２で取引先のコードをセットする。次にステップＳ５０３で、受発注支援サーバ１２は、登録内容をセットする。そして、ステップＳ５０４で、受発注支援サーバ１２は、取引先マスタを登録し、処理を終える。
【００６６】
ステップＳ５０１の処理で、変更が選択された場合、受発注支援サーバ１２は、ステップＳ５０５で、取引先のコードをセットする。次に、受発注支援サーバ１２は、ステップＳ５０６で取引先マスタを読み込む。ステップＳ５０７で、受発注支援サーバ１２は、変更した修正内容をセットする。そして、ステップＳ５０８で、受発注支援サーバ１２は、取引先マスタの変更を行い処理を終了する。
【００６７】
ステップＳ５０１の処理で、削除が選択された場合、受発注支援サーバ１２は、ステップＳ５０９で取引先コードをセットする。次に、受発注支援サーバ１２は、ステップＳ５１０で、取引先マスタを読み込む。ステップＳ５１１で、受発注支援サーバ１２は、取引先コードに「ＨＩＧＨ−ＶＡＬＵＥ」を書き込む。この「ＨＩＧＨ−ＶＡＬＵＥ」は、データが無効であることを示す。ステップＳ５１２で、受発注支援サーバ１２は、取引先マスタを削除し、処理を終了する。なお、ステップＳ５１０とステップＳ５１１の処理は、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ　Ｄａｔａ　Ｂａｓｅ）では不要である。
【００６８】
以上で取引先マスタ更新処理の説明を終え、次に、ステップＳ１０７（図７参照）の商品マスタ更新処理について図２３を用いて説明をする。
【００６９】
ステップＳ６０１で、受発注支援サーバ１２は、商品を登録／変更／削除のいずれかを行うかで処理を分岐する。登録の場合、受発注支援サーバ１２は、ステップＳ６０２で商品のコードをセットする。次にステップＳ６０３で、受発注支援サーバ１２は、登録内容をセットする。そして、ステップＳ６０４で、受発注支援サーバ１２は、商品マスタを登録し、処理を終える。
【００７０】
ステップＳ６０１の処理で、変更が選択された場合、受発注支援サーバ１２は、ステップＳ６０５で、商品のコードをセットする。次に、受発注支援サーバ１２は、ステップＳ６０６で商品マスタを読み込む。ステップＳ６０７で、受発注支援サーバ１２は、変更した修正内容をセットする。そして、ステップＳ６０８で、受発注支援サーバ１２は、商品マスタの変更を行い処理を終了する。
【００７１】
ステップＳ６０１の処理で、削除が選択された場合、受発注支援サーバ１２は、ステップＳ６０９で商品コードをセットする。次に、受発注支援サーバ１２は、ステップＳ６１０で、商品マスタを読み込む。ステップＳ６１１で、受発注支援サーバ１２は、商品コードに「ＨＩＧＨ−ＶＡＬＵＥ」を書き込む。ステップＳ６１２で、受発注支援サーバ１２は、商品マスタを削除し、処理を終了する。なお、ステップＳ６１０とステップＳ６１１の処理は、ＲＤＢでは不要である。
【００７２】
次に図７のステップＳ１０８の処理について説明する。その他の処理であるステップＳ１０８の処理として、「一覧発注」、「定番発注」、「商品コード指定発注」、「特売発注」、「イベント実績発注」、「特定日実績発注」などが挙げられる。以下、上記発注方法について説明する。
【００７３】
「一覧発注」は、「分類」を指定し、商品コード順の商品を一覧表示し、商品毎に数量入力する発注方法である。「定番発注」は、定番商品を一覧表示し、商品毎に数量入力する発注方法である。「商品コード指定発注」は、スキャナにより、商品コードを入力し、商品毎に数量入力する発注方法である。「特売発注」は、特売商品を一覧表示し、商品毎に納品先店舗を指定して数量入力する本部が行う発注方法である。「イベント実績発注」は、前回のイベントの前後１週間に発注された商品を一覧表示し、商品毎に数量入力する発注方法である。「特定日実績発注」は、特定日（例えば、店固有の開店記念日、キャンペーン）に、発注された商品を一覧表示し、商品毎に数量入力する発注方法である。
以上で図７におけるチェーンストアの処理についての説明を終え、次に、図７の「取引先Ａ」から続く、図２０の取引先メニューについて説明する。図２０に示される処理のうち、最初に、ステップＳ１１０の取引状況照会処理の説明をする。
【００７４】
一般的に、チェーンストアが主体のシステムでの取引状況照会処理において、チェーンストアが取引先を登録するシステムでは、チェーンストアが主体となるため、同じ取引先でも、チェーンストア毎に別ユーザとして登録される。
【００７５】
その為、取引先から複数のチェーンストア内の店舗の取引状況を確認するには、チェーンストア毎に、それぞれの登録されたユーザ名で、ネットワーク接続をやり直さなければならなくなり、効率よく取引状況が確認できない。すなわち、取引先から、単一のチェーンストア内の店舗の商品発注数量しか参照することができなかった。
【００７６】
そこで、本実施の形態に設けられた取引先管理テーブル４２を、図１２を用いて説明する。この取引先管理テーブル４２は、取引先別ユーザＩＤをキーとして、チェーンストア識別コードと取引先コードが対になったテーブルである。
【００７７】
このテーブルを用いて行う取引状況照会処理を図１３のフローチャートを用いて説明する。まず、ステップＳ３０１で、受発注支援サーバ１２は、ユーザによって表示対象のチェーンストアが選択される。次に、ステップＳ３０２で、受発注支援サーバ１２は、取引先管理テーブル４２を読み込む。この処理により、受発注支援サーバ１２は、表示対象チェーンストア別取引先コードを取得する。そして、ステップＳ３０４で、受発注支援サーバ１２は、発注実績ＤＢ５２（図９参照）の読み込みを行う。そして、ステップＳ３０５で、受発注支援サーバ１２は、読み込みが全て終了したかどうか判断し、終了していなければ該当発注実績レコードをステップＳ３０６で取得する。読み込みが終了すると、ステップＳ３０７で、受発注支援サーバ１２は、表示対象店舗別チェーンストア別発注実績レコードを表示し、処理を終了する。
【００７８】
これにより、一度の接続で、単一取引先から複数チェーンストアのアクセスが可能となる。また、チェーンストア毎にアクセスし、取引状況を確認する従来の方法に比べ、格段に使い易さが向上する。
【００７９】
以上で取引状況照会処理の説明を終え、次に、ステップＳ１１１（図２０参照）の出荷報告訂正処理の説明をする。
【００８０】
出荷報告訂正処理は、発注数量を訂正する処理である。商品別の発注数量合計が在庫数量より大きい場合、限られた在庫を店舗の重要度に応じて、分配する。これは、従来のような、重要度の低い店舗に商品別の発注数量合計を出荷し、重要度の高い店舗に発注数量以下の数量を出荷してしまうケースを防ぐための処理である。なお、商品別の発注数量合計が在庫数量より小さい場合でも、当処理にて発注数量を訂正することが可能である。
【００８１】
この出荷報告訂正処理の説明のため、まず最初に在庫ＤＢ４４、重要度テーブル４６、重みテーブル４８について説明する。
【００８２】
図１４は、在庫ＤＢ４４を示す図である。在庫ＤＢ４４は、取引先別ユーザＩＤと、商品コードと、商品名と、在庫数量を含む構成となっている。このように在庫ＤＢ４４は、商品の在庫が取引先に何個あるかが示されるＤＢである。
【００８３】
次に、図１５を用いて重要度テーブル４６について説明する。重要度テーブル４６は、取引先別ユーザＩＤと、チェーンストア識別コードと、店舗コードと重要度を含む構成となっている。この重要度テーブル４６により、店舗コードごとの重要度情報が示される。
【００８４】
次に、図１６を用いて重みテーブル４８の説明をする。重みテーブル４６は、取引先ユーザＩＤと、重要度と、重みを含む構成となっている。このテーブルは重要度に対する重みが示されている。
【００８５】
以上説明したテーブルやＤＢを用いた出荷報告訂正処理について、図１７のフローチャートを用いて説明する。ステップＳ４０１で、受発注支援サーバ１２は、取引先から納品日の指定を入力される。次に、ステップＳ４０２で、受発注支援サーバ１２は、発注実績ＤＢの分類を商品コードの昇順に行う。そしてステップＳ４０３で、受発注支援サーバ１２は、取引先管理テーブル４２（図１２参照）を参照しながら、複数のチェーンストアにまたがった商品コードごとに発注数量を集計する。そして、受発注支援サーバ１２は、ステップＳ４０４で、在庫ＤＢ４４（図１４参照）を読み込む。
【００８６】
以上の処理で得られた結果をもとに、ステップＳ４０５で受発注支援サーバ１２は、図１８に示す出荷報告訂正画面を表示する。この出荷報告訂正画面は、納品日を指定する入力欄を有する。また、Ｎｏ．、訂正、訂正前数量、出荷可能数量、商品コード、商品名の項目からなる表を有する。この出荷報告訂正画面の項目である「訂正」により、納品数の訂正が必要かどうか確認することができる。例えば、「Ｎｏ．」が「００１」の発注数量は訂正が必要となっているが、それは、隣の項目である「訂正前数量」の３９０が、「出荷可能数量」の３００を上回っているためである。
【００８７】
フローチャートの説明に戻り、ステップＳ４０６で、受発注支援サーバ１２は、ユーザが在庫不足の商品を選択したかどうか判断する。このユーザの選択は、例えば画面上の「Ｎｏ．」を押下することで選択することができる。ユーザが在庫不足の商品を選択した場合、受発注支援サーバ１２は、ステップＳ４０７で重要度テーブル４６を読み込む。さらにステップＳ４０８で、受発注支援サーバ１２は、重みテーブル４８を読み込む。次に、受発注支援サーバ１２は、ステップＳ４０９で読み込んだ重要度、重みテーブルにしたがって計算する。そして、ステップＳ４１０で、受発注支援サーバ１２は、後述する計算により求まった数量を算出数量とする。
【００８８】
次に、受発注支援サーバ１２は、図１９の出荷報告訂正画面に示されるように、求まった算出数量をユーザに対して表示する。この出荷報告訂正画面は、訂正ボタンと、Ｎｏ．、チェーンストア識別コード、店舗コード、算出数量、訂正数量の項目からなる表を有する。ステップＳ４１３で、ユーザはこの表の算出数量を目安に、訂正数量を入力する。そしてユーザが、ステップＳ４１４で訂正ボタンを押下することにより処理は終了する。なお、ステップＳ４０６の処理において、ユーザが在庫不足の商品を選択しなかった場合、算出数量を求める処理であるステップＳ４０７から、ステップＳ４１０の計算処理をスキップし、ステップＳ４１１で、発注数量をそのまま算出数量としてステップＳ４１２の処理を行う。
【００８９】
次に、上記計算方法を説明する。Ａ牛乳の発注数量が、店舗Ａ（Ｓ０１０）＝２３０、店舗Ｂ（Ｓ０３０）＝１００、店舗Ｃ（Ｓ０４０）＝６０であり、重みが、店舗Ａ＝３、店舗Ｂ＝２、店舗Ｃ＝１、在庫数量＝３００としたとき、分母＝２３０×３＋１００×２＋６０×１＝９５０とする。但し、小数点以下は切り捨てる。
【００９０】
次に、求まった分母を用いて、重みと発注数量に応じて次のように計算する。
店舗Ａ＝３００×（２３０×３）／９５０＝２１７、店舗Ｂ＝３００×（１００×２）／９５０＝６３、店舗Ｃ＝３００×（６０×１）／９５０＝１８。
【００９１】
この計算の結果、余った在庫＝在庫数量−（店舗Ａ数量＋店舗Ｂ数量＋店舗Ｃ数量）＝２であるので、余った在庫は重みが高い店舗から加算の対象とすると、店舗Ａ数量＝２１７＋２＝２１９となる。
【００９２】
このようにすることにより、在庫不足の場合、重要店舗と一般的な店舗とで、店舗の重要度に応じた商品の配分を行うことで、商品不足の場合の影響度を最小限に抑えることができる。また、在庫商品が不足の場合、伝票単位でなく、全ての伝票を集計した商品単位で最適な配分を行っており、たとえ、不足の商品が同一チェーンストア内の複数店舗を跨ったり、複数チェーンストアの複数店舗を跨ったりしても、一括して、調整後の数量を訂正可能となる。
【００９３】
次に、図２０におけるステップＳ１１３のその他の処理であるが、この処理は、例えば、発送した商品の発送状況を確認する処理などがある。
【００９４】
以上で図７における取引先の処理についての説明を終え、次に、図７の「センタＢ」から続く、図２１のセンタメニューについて説明する。
【００９５】
ステップＳ１１５の処理は、チェーンストア登録管理処理であり、上記受発注支援システムに新たに利用するチェーンストアをセンタが登録する処理である。ステップＳ１１６の処理は、取引先登録管理処理であり、上記受発注支援システムに新たに利用する取引先をセンタが登録する処理である。ステップＳ１１７の処理は、課金管理処理である。この課金は、受発注支援システムを利用している取引先やチェーンストアに対して、利用料を徴収するための課金処理である。なお、この課金方法は、図２１に示されるように、伝票の量に応じて課金される伝票単位、明細の内容に応じて課金される明細単位、ユーザＩＤごとに課金されるＩＤ単位、月額固定などの方法がある。
【００９６】
ステップＳ１１８のその他の処理は、受発注支援サーバのメンテナンス処理などがある。
【００９７】
【発明の効果】
以上説明したように、初期投資やＩＴスキルの要員を不要にして、各店舗の商品発注ノウハウを自動的に蓄積、利用することを可能とする（各店舗の仕入れ担当者の経験等による店舗の売上への影響をなくする）と共に、大手小売店並の取引条件で商品提供を可能とする受発注支援方法、受発注支援サーバ、受発注支援システムを提供することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態における受発注支援システムの全体構成図である。
【図２】コンピュータのハードウェア構成図である。
【図３】受発注支援システムの詳細を示す図である。
【図４】チェーンストア識別マスタを示す図である。
【図５】取引先マスタを示す図である。
【図６】商品マスタを示す図である。
【図７】クライアント接続時の処理を示すフローチャートである。
【図８】サイクル発注マスタを示す図である。
【図９】発注実績ＤＢを示す図である。
【図１０】発注処理を示すフローチャートである。
【図１１】発注画面を示す図である。
【図１２】取引先管理テーブルを示す図である。
【図１３】取引状況照会処理を示すフローチャートである。
【図１４】在庫ＤＢを示す図である。
【図１５】重要度テーブルを示す図である。
【図１６】重みテーブルを示す図である。
【図１７】出荷報告訂正処理を示すフローチャートである。
【図１８】出荷報告訂正画面を示す図である。
【図１９】出荷報告訂正画面を示す図である。
【図２０】取引先クライアントに対する処理を示すフローチャートである。
【図２１】センタクライアントに対する処理を示すフローチャートである。
【図２２】取引先の登録／変更／削除処理を示すフローチャートである。
【図２３】商品の登録／変更／削除処理を示すフローチャートである。
【符号の説明】
１０…受発注支援システム
１２…受発注支援サーバ
１５…センタクライアント
１４…店舗クライアント
１６…取引先クライアント
１８…ネットワーク
２０…演算処理装置
２１…インタフェース装置
２２…入力装置
２３…表示装置
２４…ドライブ装置
２５…記録媒体
２６…補助記憶装置
２７…メモリ装置
３０…ユーザ制御部
３２…サイクル発注処理部
３４…実績発注処理部
３６…取引状態照会処理部
３８…出荷訂正処理部
４０…チェーンストア識別マスタ
４２…取引先管理テーブル
４４…在庫ＤＢ
４６…重要度テーブル
４８…重みテーブル
５０Ａ、５０Ｎ…取引先データ
５２…発注実績ＤＢ
５４…サイクル発注マスタ
５６…取引先マスタ
５８…商品マスタ
６０Ａ、６０Ｌ…リンクデータ
６２…本部
６４Ａ、６４Ｍ…店舗
６６Ａ、６６Ｌ…チェーンストア
６８Ａ、６８Ｎ…取引先
７０Ａ、７０Ｌ…取引先グループ
７２…ソフトウェアブロック

Claims

商品を発注する店舗クライアントと、商品を受注する取引先クライアントとが受発注をするための支援を行う受発注支援サーバで、受発注の支援をする受発注支援方法であって、
店舗本部が各店舗クライアントとの発注に関する情報を設定するとともに、各取引先との取引に関する情報を設定する情報設定段階と、
前記受発注支援サーバが保持する発注に関する前記店舗毎の発注情報を前記店舗クライアントに送信する発注情報送信段階と、
前記店舗クライアントに発注処理を行わせる発注蓄積処理段階とを有することを特徴とする受発注支援方法。
さらに、前記取引先クライアントに受注処理を行わせる受注処理段階を有することを特徴とする請求項１に記載の受発注支援方法。
前記発注情報送信段階は、
前記発注情報として、予め定められた日時と、前記商品の送信日時とが一致した場合、所定の商品情報を送信することを特徴とする請求項１または２に記載の受発注支援方法。
前記発注情報送信段階は、
前記発注情報として、該クライアントが以前に発注した商品情報を送信することを特徴とする請求項１または２に記載の受発注支援方法。
前記受注処理段階は、
前記店舗クライアントが、所定のグループに属する場合、該グループには無関係に、該取引先クライアントが所望する店舗クライアントの発注情報を送信することを特徴とする請求項２に記載の受発注支援方法。
前記受注処理段階は、
複数の店舗クライアントから受注した商品の受注量が、該商品の在庫量を上回った場合、前記店舗クライアントごとに予め定められた店舗重要度情報に応じて、前記商品を在庫量の範囲で割り当てることを特徴とする請求項２に記載の受発注支援方法。
商品を発注する店舗クライアントと、商品を受注する取引先クライアントとが受発注をするための支援を行う受発注支援サーバであって、
店舗本部が各店舗クライアントとの発注に関する情報を設定するとともに、各取引先との取引に関する情報を設定する情報設定手段と、
前記店舗毎の発注に関する発注情報を前記店舗クライアントに送信する発注情報送信手段と、
前記店舗クライアントに発注処理を行わせる発注蓄積処理手段と、
前記取引先クライアントに受注処理を行わせる受注処理手段とを有することを特徴とする受発注支援サーバ。
商品を発注する店舗クライアントと、商品を受注する取引先クライアントとが受発注をするための支援を行う受発注支援サーバとを有する受発注支援システムにおいて、
店舗本部が各店舗クライアントとの発注に関する情報を設定するとともに、各取引先との取引に関する情報を設定する情報設定手段と、
前記受発注支援サーバは、保持する前記店舗毎の発注に関する発注情報を前記店舗クライアントに送信する発注情報送信手段と、
前記店舗クライアントから発注を、発注情報として保持・蓄積する手段と、該発注情報を前記取引先クライアントに通知する手段とを有し、
前記店舗クライアントは、前記取引先に対する発注を、前記発注支援サーバに発注する手段を有し、
前記取引先クライアントは、前記発注情報を前記発注支援サーバから受信する手段とを有することを特徴とする受発注支援システム。
コンピュータに、
店舗本部が各店舗クライアントとの発注に関する情報を設定するとともに、各取引先との取引に関する情報を設定する情報設定手段と、
前記店舗毎の発注に関する発注情報を店舗クライアントに送信する発注情報送信手順と、
前記店舗クライアントに発注処理を行わせる発注蓄積処理手順と、
前記取引先クライアントに受注処理を行わせる受注処理手順とを実行させるための受発注支援プログラム。