JP6779771B2 - 商取引支援システム - Google Patents

Description

本発明は、商品の提供者から販売店を経由して料飲店に至る商取引を支援するシステムに関する。

コンピュータシステムを利用して商取引を支援するシステムとして、例えば、顧客から複数種カテゴリの商品の注文を一括して受け付けた場合、商品のカテゴリに応じて担当販売店を特定してその担当販売店に注文を自動発注するとともに、商品の提供者（サプライヤ）に顧客への商品の配送を自動的に指示することにより、実際の商品が提供者から販売店を経由して顧客へと流通しなくとも、それと同様に商取引が行われたかのように取引を支援して、商取引の効率化、省力化を図るようにしたシステムが知られている（例えば特許文献１及び２参照）。

特許第３５６２４１８号公報 特開２００４−２３４６９０号公報

酒類等の飲料をその提供者から各地の料飲店に流通させる場合、各料飲店と継続的な取引関係を構築している販売店（酒販店とも呼ばれる。）を経由して商品を提供することが一般的である。上述した従来のシステムは、提供者と顧客との間に販売店が介在することを前提としているため、料飲店を対象とした商取引形態にも通用し得る。しかしながら、従来のシステムは、顧客と販売店との間の商品の受発注、商品の配送指示といった商品の取引過程で発生する業務を支援するのみである。商品の在庫はシステムが管理せず、提供者による自己管理に委ねられている。そのため、商品の注文の受け付けや配送の指示といった処理が行われても、その後に在庫不足あるいは欠品といった提供者側の都合により取引が不成立となるおそれがある。一方、料飲店では、取引関係のある販売店が取り扱っている商品以外の商品を購入したい事情が生じることがある。その場合、上記のシステムでは、顧客が当該商品を取り扱っている販売店を探して担当販売店として登録した上で、その商品を発注する必要があり、取引ルートを新たに構築する手間と時間がかかる。既に取引関係がある販売店に新たな商品の取り扱いを求めた上でシステムを利用することも可能であるが、その場合、顧客は商品が確実に届くであろうかといった不安を抱えつつ発注せざるを得ないし、販売店にしても、取引経験が少ないか又は全くない提供者との間で確実に商取引が履行されるか否かの不安を抱えることになる。

そこで、本発明は料飲店が商品を購入する際の取引の安全性、信頼性を高めることが可能な商取引支援システムを提供することを目的とする。

本発明の一態様に係る商取引支援システム（１）は、複数の料飲店（３）と、各料飲店にて販売されるべき複数種類の商品を提供する少なくとも一の提供者（２Ａ、２Ｂ）との間に複数の販売店（４）が介在し、各料飲店が少なくとも一の販売店に対して取引関係を有している商取引形態に適用され、各料飲店からの商品の注文に対応して、当該商品が保管された物流拠点（５Ａ、５Ｂ）に前記商品の出荷を指示し、かつ各料飲店からの注文を、当該注文に含まれる商品の提供者、各料飲店と前記取引関係のある販売店、及び各料飲店の間における商品の取引として処理するための商取引支援システムであって、各料飲店、各販売店、前記提供者、及び前記物流拠点のそれぞれに対応したコンピュータ機器（１２、１３、１４、１５）と所定の通信回線を介して接続されたコンピュータシステム（１０）を具備し、前記コンピュータシステムには、前記提供者から提供可能な商品を各料飲店が選択するために必要な商品ごとの商品データ（２１）と、前記商品ごとの在庫量を記録した在庫データ（３３）と、各料飲店と各販売店との取引関係を記録した帳合データ（２５）とを記憶する記憶手段（ＤＳ）と、前記商品データに基づいて各料飲店のコンピュータ機器に前記商品の注文の内容を選択させるための商品選択情報を提供し、前記在庫データに記録された在庫量からみて販売可能な範囲で注文が成立するように各料飲店のコンピュータ機器からの前記商品の注文の受け付けを制御する受注処理手段（４１）と、前記受注処理手段が受け付けた注文の内容に基づいて、各料飲店が注文した商品の出荷を前記物流拠点のコンピュータ機器に指示する出荷指示手段（４２）と、前記物流拠点における各商品の在庫量の変動に関する情報を前記物流拠点のコンピュータ機器から取得し、得られた情報に基づいて前記在庫データを管理する在庫管理手段（４３）と、各料飲店からの注文を前記受注処理手段が受け付けた場合、前記帳合データに基づいて、各料飲店の注文に対応して売上を計上すべき販売店を判別する販売店判別手段（４１、Ｓ１２９）と、前記受注処理手段が受け付けた注文に対応する商品の販売の実績を示す情報を前記料飲店、前記販売店及び前記物流拠点の少なくともいずれか一つのコンピュータ機器から取得し、得られた情報に基づいて、前記販売店判別手段にて判別された販売店が前記料飲店の注文した商品を前記提供者から仕入れて当該料飲店に販売したとみなした場合に発生すべき前記提供者及び前記販売店のそれぞれの売上代金の処理に必要な情報を生成し、前記販売店における売上代金の処理に必要な情報を前記販売店のコンピュータ機器に提供し、かつ前記提供者における売上代金の処理に必要な情報を前記提供者のコンピュータ機器に提供する売上処理手段（４４）と、を備えたものである。

上記態様の商取引支援システムによれば、料飲店が商品を注文すると、その注文に対応した商品の出荷が物流拠点に指示されるとともに、注文主の料飲店と取引関係がある販売店が判別され、その販売店が料飲店の注文に対応する商品を提供者から仕入れて料飲店に販売したものとして、提供者及び販売店のそれぞれにて発生すべき売上代金の処理に必要な情報が生成されて提供者及び販売店にそれぞれ提供される。これにより、商品を提供者から販売店を経由して料飲店へと実際に流通させなくとも、それと同様に取引を成立させて提供者や販売店の手間を軽減することができる。提供者の商品の在庫が在庫管理手段にて管理され、在庫データに記録された在庫量からみて販売可能な範囲で注文が成立するように受注処理手段が注文の受け付けを制御しているので、料飲店からみれば頻繁に購入する商品でも、希に、あるいは初めて購入する商品でも、どのような提供者かを意識することなく安心して注文することができる。それにより、取引に関する信頼性、安全性を高めることができる。ちなみに、従来のシステムでは、料飲店が販売店に商品の取り扱いを確認し、販売店において取り扱った経験がない商品であればその販売店に取引開始を依頼するといった手間をかける必要がある。販売店にしても、取引経験が少ないか又は全くない提供者との間で新規な商品を売買開始する手続が必要であり、手間と時間を要するし、提供者にしてもその販売店が確実に商取引を履行するかといった不安を抱えながら取引を開始する必要がある。さらに、料飲店は、提供者と販売店との間に新規の商品の取引を開始する手続が完了するまで待ってから商品を発注する必要がある。これに対して、上記態様の商取引システムによれば、料飲店は販売店への確認や依頼といった手間を要せず、かつ提供者と販売店との間の手続を待つことなく受注処理手段を介して新規な商品を発注することができるので、商品を早く確実に入手することができる。提供者や販売店にしても、商品を提供者から販売店を経由して料飲店へと実際に流通させた場合と同様に取引が成立するので、取引に関する手間や時間といった負担、あるいは不安を抱えることなく商取引を進めることができる。

上記態様の商取引支援システムにおいて、前記少なくとも一の提供者として複数の提供者が存在し、前記在庫管理手段は、前記複数の提供者のそれぞれが提供する商品の前記物流拠点における在庫量が前記在庫データに反映されるようにして前記在庫データを管理してもよい。これによれば、複数の提供者のそれぞれの商品の在庫量が在庫管理手段により一元的に、あるいは横断的に管理される。したがって、提供者間における在庫管理の品質のばらつきを排除し、安定した取引を実現することができる。

前記複数の提供者には、前記商品の取引に関する委託関係が存在する委託者（２Ｂ）及び受託者（２Ａ）が含まれ、前記売上処理手段は、前記受注処理手段が受け付けた注文に対応した商品に前記委託者の商品が含まれている場合、前記販売店が当該商品を前記受託者から仕入れて前記料飲店に販売したとみなして前記販売店及び前記受託者のそれぞれの売上代金の処理に必要な情報を前記販売店のコンピュータ機器及び前記受託者のコンピュータ機器に提供するとともに、前記受注処理手段が受け付けた注文に対応する商品に含まれている前記委託者の商品を当該委託者が前記受託者に販売したとみなした場合に発生すべき前記委託者の売上代金の処理に必要な情報を前記商品の販売の実績を示す情報に基づいて生成し、当該情報を前記委託者のコンピュータ機器に提供してもよい。これによれば、委託者が受託者に商品の取引を委託すると、その後は受託者から販売店を経由して料飲店へと商品が流通した場合と同様にして取引が処理される。委託者は自己が委託した商品の売上に伴う代金決済を受託者との間で処理すれば足り、自ら販売店と直接的に取引を行う必要がない。そのため、小規模の業者のように多数の販売店と取引関係を構築することに困難な提供者であっても、上記態様の取引支援システムを利用して多数の販売店に商品を販売する機会を獲得することができる。それにより、多くの提供者の参入を促し、かつ料飲店からみれば稀少な商品でも比較的容易にかつ安心して購入することが可能となる。

前記コンピュータシステムには、前記委託者が提供する商品に関する在庫データを当該委託者のコンピュータ機器から閲覧させる閲覧制御手段（４６）がさらに設けられてもよい。これによれば、委託者が自己の商品に関する在庫データを閲覧して、その商品の製造や補充を検討するための参考情報を取得することができる。

上記態様の商取引支援システムにおいて、前記記憶手段は、前記販売店が前記料飲店に対して設定した与信条件を特定する与信情報（２８）をさらに記憶し、前記受注処理手段は、前記与信条件に反する注文が成立することがないように、前記料飲店からの注文の受け付けを前記与信情報に基づいて制御してもよい。これによれば、販売店が設定した与信条件に反する注文を料飲店が発し、その注文に基づく取引が料飲店の知らない間に実行されるおそれを排除することができる。

上記態様の商取引支援システムにおいて、前記コンピュータシステムには、前記提供者からの要求に基づいて前記商品データを設定する商品情報設定手段（４５、Ｓ３０４、Ｓ３０６）がさらに設けられてもよい。これによれば、提供者が新たに商品を登録し、あるいは既に登録されている商品の情報を変更するといったように、商品データの内容を適宜に設定することができる。なお、ここでいう設定は、新規の登録、登録内容の追加修正、あるいは登録の削除といった各種の操作を含む概念である。

上記態様の商取引支援システムにおいて、前記記憶手段は、各販売店の取引範囲を規定する取引範囲情報（２９）をさらに記憶し、前記コンピュータシステムには、前記取引範囲情報に基づいて、前記取引範囲外の関係にある料飲店と販売店との間における取引の発生を防止する取引制限手段（４５、Ｓ３３５、Ｓ３３６、Ｓ３４３；Ｓ３５７、Ｓ３５８、Ｓ３６４）がさらに設けられてもよい。これによれば、販売店の取引範囲に関して法令上又は行政上の要請、あるいは自己の発意により何らかの制限が設定されている場合において、その制限を取引範囲情報に設定しておくことにより、取引範囲外の取引がなされるおそれを未然に防止することができる。

上記態様の商取引支援システムにおいて、前記コンピュータシステムには、前記販売店からの要求に基づいて前記帳合データを設定する帳合データ設定手段（４５、Ｓ３３８；Ｓ３５９）がさらに設けられてもよい。これによれば、販売店からの要求に基づいて帳合データを設定しているので、販売店が承知していない状態で料飲店と販売店との取引関係が帳合データに記録されるおそれを排除することができる。なお、ここでいう設定も、新規の登録、登録内容の追加修正、あるいは登録の削除といった各種の操作を含む概念である。

さらに、前記記憶手段は、各販売店の取引範囲を規定する取引範囲情報（２９）をさらに記憶し、前記コンピュータシステムには、前記取引範囲情報に基づいて、前記販売店に対して取引範囲外にある料飲店が当該販売店と前記取引関係のある料飲店として前記帳合データに記録されないように前記帳合データ設定手段による前記帳合データの設定を制限する取引制限手段（４５、Ｓ３３５、Ｓ３３６、Ｓ３４３；Ｓ３５７、Ｓ３５８、Ｓ３６４）がさらに設けられてもよい。これによれば、帳合データが設定される際に、取引範囲外にある料飲店と販売店とが帳合データに記録され、それにより取引範囲外の取引が行われる可能性を排除することができる。

上記態様の商取引支援システムにおいて、前記記憶手段は、前記提供者から各販売店への商品の卸価格、及び各販売店から各料飲店への商品の小売価格を記録した価格情報（２７）をさらに記憶し、前記受注処理手段は前記小売価格を含めるようにして前記商品選択情報を提供し、前記売上処理手段は、前記小売価格に基づいて前記販売店における売上代金の処理に必要な情報を生成し、かつ前記卸価格に基づいて前記提供者の売上代金の処理に必要な情報を生成するものとしてもよい。これによれば、価格情報に記録された小売価格を料飲店に提示するのみならず、販売店に提供される売上代金の処理に必要な情報、及び提供者に提供される売上代金の処理に必要な情報に小売価格又は卸価格を反映させて提供者及び販売店の売上処理に伴う負担の軽減を図ることができる。

前記コンピュータシステムには、前記卸価格を前記提供者の指示に基づいて設定し、設定された前記卸価格に基づいて前記小売価格を演算して設定する価格設定手段（４５、Ｓ３０５）がさらに設けられてもよい。これによれば、提供者が卸価格を指示すると、その卸価格が価格情報に設定されるとともに、卸価格に基づいて演算された小売価格も価格情報に反映される。従って、価格の新規設定、あるいは価格の変更に伴う処理の負担が軽減される。

なお、以上の説明では本発明の理解を容易にするために添付図面の参照符号を括弧書きにて付記したが、それにより本発明が図示の形態に限定されるものではない。

本発明の一形態に係る商取引支援システムの概略構成を示す図。 商取引システムを形成するコンピュータシステムの具体的構成の一例を示す図。 製造者が物流拠点に商品を納入する場合に行われる入荷処理の手順の一例を示すフローチャート。 料飲店から商品が注文された場合に行われる受注処理の手順の一例を示すフローチャート。 与信エラーが生じた場合に行われる処理の手順の一例を示すフローチャート。 図４に続くフローチャート。 出荷処理の手順の一例を示すフローチャート。 図７に続くフローチャート。 物流拠点にて商品が廃棄処分された場合に行われる在庫調整処理の手順の一例を示すフローチャート。 商品の販売に伴う売上処理のうち、販売店に対する製造者の売上代金を処理するために行われる処理の手順の一例を示すフローチャート。 商品の販売に伴う売上処理のうち、料飲店に対する販売店の売上代金を処理するために行われる処理の手順の一例を示すフローチャート。 商品の販売に伴う売上処理のうち、受託者としての製造者に対する委託者としての製造者の売上代金を処理するために行われる処理の手順の一例を示すフローチャート。 商品マスタに商品情報を登録するために行われる処理の手順の一例を示すフローチャート。 製造者マスタに製造者の情報を登録するために行われる処理の手順の一例を示すフローチャート。 料飲店マスタに料飲店のの情報を登録するために行われる処理の手順の一例を示すフローチャート。 帳合マスタに登録された料飲店と販売店との関係を変更するために行われる処理の手順の一例を示すフローチャート。

以下、図面を参照して本発明の一形態に係る商取引支援システムを説明する。図１に示すように、本形態の商取引支援システム（以下、支援システムと略称することがある。）１は、複数種類の商品の提供者の一例としての複数の製造者２Ａ、２Ｂと、複数の料飲店３との間に複数の販売店４が介在する商取引形態に適用される。ただし、図１では料飲店３及び販売店４をそれぞれ一店舗のみ例示している。以下では、製造者２Ａ、２Ｂを区別することなく製造者２と表記することがある。

製造者２は、商品の一例としてのビール等の飲料を製造し、市場に提供する。製造者２は、数多くの種類の商品を市場に大量かつ継続的に提供する大手ビール会社のような大規模な企業体、限られた種類の商品を限られた規模で提供するクラフトブルワリーのような小規模の醸造所、あるいはそれらの中間的な規模の企業等を適宜に含むことができる。図１では、大規模な製造者として製造者２Ａを、小規模な製造者として製造者２Ｂを例示しているが、支援システム１における提供者はそれらの者に限られるものではない。製造者２Ａは、少なくとも製造部門２ａと管理部門２ｂとを含み、各地の販売店４との間に継続的な取引関係を有している。支援システム１は、一例として、製造者２Ａの管理部門２ｂによりその運営が管理されるものとする。つまり、製造者２Ａは、商品の提供者のみならず支援システム１を構築してこれを運営する事業者を兼ねる。ただし、製造者２Ａ、２Ｂとは異なる第三者により支援システム１が運営されてもよい。製造者２Ｂは、支援システム１を利用した商品の販売を製造者２Ａに委託し、製造者２Ａはこれを受託している。つまり、製造者２Ａ、２Ｂ間には、商品の取引に関して製造者２Ｂを委託者、製造者２Ａを受託者とする委託関係が存在する。なお、複数の製造者２のうち、いずれか一の製造者２が支援システム１の運営事業者を兼ねる場合、その運営事業者の製造者２を受託者として、他の全ての製造者２が運営事業者の製造者２に販売を委託することを支援システム１の利用条件としてもよい。「委託」は、製造者２間で取引を仲介する契約等の取り決めが具体的に存在するような形態に限られず、一の製造者２が提供する商品を他の製造者２が購入してこれを販売店４に販売するといったように、製造者２と販売店４との間に他の製造者２が介在する場合を含む広義の概念である。

料飲店３は各地で顧客に飲食物を提供する商業店舗である。料飲店３は、営業主体が法人によるか個人によるかを問わず、その規模の大小も問わない。複数の系列店をひとまとめに料飲店３として扱ってもよい。販売店４は、製造者２から商品を仕入れて料飲店３に販売する中間業者である。販売店４は酒販店と呼ばれることもある。料飲店３は、一般に製造者２から直接商品を仕入れることはなく、料飲店３が営業している地域の特定の販売店４と継続的な取引関係を構築し、その販売店４から日常的に酒類等の商品を仕入れることが通例である。図１に示された料飲店３と販売店４との間にはそうした取引関係が既に構築されているものとする。

製造者２Ａ、２Ｂにて製造された商品は所定の物流拠点５Ａ、５Ｂ（以下では、参照符号５で代表することがある。）に保管され、注文の発生に応じて適宜に出荷される。図１の例では、一点鎖線の矢印で示したように、製造者２Ａの商品が物流拠点５Ａに、製造者２Ｂの商品が物流拠点５Ａ及び５Ｂにそれぞれ保管され、それらの物流拠点５Ａ、５Ｂから料飲店３に商品が配送される。図１では２箇所の物流拠点５のみを例示するが、物流拠点５は全国各地に適宜に設けられてよく、物流拠点５ごとに担当する地域が設定されてもよい。物流拠点５は製造者２、又はその関連企業が運営するものでもよいし、製造者２とは別の第三者としての保管業者等が運営するものでもよい。以下では、一例として、物流拠点５Ａが製造者２Ａの関連企業の運営によるもので、物流拠点５Ｂは製造者２Ｂが例えば醸造施設と一体で運営する保管場所であるものとする。なお、一つの物流拠点５にて複数の製造者２の商品が保管されてもよいし、一つの物流拠点５にて単一の製造者２の商品のみが保管されてもよい。図１の例では、物流拠点５Ａに複数の製造者２Ａ、２Ｂのそれぞれの商品が保管されているため、物流拠点５Ａからは、製造者２Ａが提供する商品と製造者２Ｂが提供する商品とを同梱して料飲店３に商品を配送することが可能である。それにより、製造者２Ａ、２Ｂごとに別梱包で商品が届けられることによる手間を省くことが可能である。

支援システム１は、サーバＳＶ及びそのサーバＳＶがアクセス可能な記憶手段の一例としてのデータストレージＤＳ等を含んだコンピュータシステム１０上に構築されている。サーバＳＶは、単一のサーバユニット、又は複数のサーバユニットを組み合わせて構成される。クラウドコンピューティング技術を利用してサーバＳＶが構築されてもよい。一方、製造者２、料飲店３、販売店４及び物流拠点５のそれぞれには、支援システム１との間で所定の通信回線（一例としてインターネット）を介して情報交換するためのコンピュータ機器の一例としての端末装置１２、１３、１４、１５が設けられている。ただし、例えば製造者２Ｂの端末装置１２と物流拠点５Ｂの端末装置１５とが兼用されるといったように、コンピュータ機器は適宜に兼用されてもよい。

端末装置１２〜１５のそれぞれは、サーバＳＶに対するクライアントとして機能するパーソナルコンピュータ等の端末装置として設けられている。ただし、コンピュータ機器は、クライアント・サーバ型の業務処理システムを構成するように設けられてもよい。それらの業務処理システムが支援システム１と接続される場合には、例えば、ＥＤＩ（Electronic Data Interchange（電子データ交換）の略）を利用して支援システム１のサーバＳＶと製造者２等の業務処理システムとがデータ交換可能に接続される。あるいは、サーバＳＶと端末装置１２〜１５とは、電子メールの送受信により情報を交換するように接続されてもよい。その場合、電子メールは自動的に送受信されてもよいし、端末装置１２〜１５のオペレータの操作により適宜に送受信されるものとしてもよい。製造者２Ａに関しては、製造部門２ａに設置される端末装置１２ａと、管理部門２ｂに設置される端末装置１２ｂとがコンピュータ機器の一例として含まれている。管理部門２ｂの端末装置１２ｂは、支援システム１を運営するための部署に設置され、支援システム１に対する管理者用の端末装置として機能する。

次に、支援システム１による商取引の概要を説明する。図１の実線の矢印は支援システム１と端末装置１２〜１５との間における情報の流れを、破線の矢印は取引に伴う売上代金の決済処理の流れをそれぞれ示している。一点鎖線の矢印は、既に述べたように実際の商品の流通を示す。料飲店３が商品を購入する場合、まず支援システム１が提供するＷｅｂサイトに料飲店３が端末装置１３を利用してアクセスし、購入を希望する商品及びその数量を選択して商品を注文する（Ｐ１）。ここでいう数量は、一例として、樽、壜、缶といった容器に収容された商品であれば「個数」、「本数」といった単位で計数することができる。

料飲店３から商品が注文されると、支援システム１は、注文された商品を保管している物流拠点５へと商品の配送を指示する（Ｐ２）。指示を受けた物流拠点５では、注文された商品の在庫が引き当てられ、引き当てられた商品がピッキング、検品、梱包といった作業を経て出荷される。出荷された商品は適宜の配送業者又は物流業者により料飲店３が指定する配送先へと配送される。支援システム１では、全ての物流拠点５における商品の在庫を一元的に管理している。物流拠点５から商品が出荷され、製造者２から商品が納入され、あるいは商品の破損や賞味期限切れ等の理由で在庫が破棄されるといったように、物流拠点５における商品の在庫量に変動が生じると、その変動を示す情報が支援システム１に通知される（Ｐ３）。支援システム１は物流拠点５から得た情報に基づいて在庫量を把握し、料飲店３が商品を注文する際に、出荷が不可能な注文が生じないように料飲店３の商品選択を制御する。製造者２は支援システム１に対して商品の在庫量を適宜に照会し、商品の製造や物流拠点５への商品の補充を検討するための参考情報を取得することができる。

支援システム１は、料飲店３から注文を受けると、その料飲店３と取引関係がある販売店４を判別する。そして、支援システム１は、料飲店３に対する商品の取引を、判別された販売店４における商品の仕入及び売上として処理するために必要な情報をその販売店４に提供する（Ｐ４）。また、支援システム１は、製造者２に対しても、料飲店３に対する商品の取引を、自己の商品の売上として処理するために必要な情報を提供する（Ｐ５）。支援システム１では、料飲店３からの注文に応じて物流拠点５に配送が指示されて商品が配送されるので、販売店４は自己と取引関係がある料飲店３における商品の発注を知り得ない状態にある。そこで、料飲店３が商品を注文した場合、注文された商品を販売店４が製造者２から仕入れて料飲店３に販売したものとみなし、それらの仕入及び売上の処理に必要な情報を販売店４に提供することとした。支援システム１から提供される情報に基づいて、販売店４は料飲店３に販売代金を請求し、料飲店３は請求された代金を販売店４に支払う（Ｐ６）。この決済処理は、販売店４と料飲店３との間における通常の取引、つまり実際に商品を仕入れて販売する場合と同様に行えばよい。また、製造者２と販売店４との間においても、製造者２が料飲店３に売上代金を直接請求するのではなく、製造者２が販売店４に商品を販売したものとみなして、その売上処理に必要な情報を製造者２に提供することとした。製造者２は、支援システム１から提供される情報に基づいて販売店４に売上代金を請求し、販売店４は請求された代金を製造者２に支払う（Ｐ７）。

なお、製造者２Ａの商品に関しては、製造者２Ａから販売店４に対する商品の販売として扱われるが、製造者２Ｂの商品については委託関係にある製造者２Ａに対する商品の販売として扱われる。すなわち、製造者２Ｂの商品を料飲店３が購入すると、その購入分に相当する商品を受託者の製造者２Ａが委託者である製造者２Ｂから仕入れて販売店４に販売したものとして取引が取り扱われる。したがって、製造者２Ｂの商品に関しては、支援システム１から提供される情報に基づいて、製造者２Ａと販売店４との間で販売代金の請求及び支払いが行われるとともに、それに対応して製造者２Ｂが製造者２Ａに販売代金を請求し、製造者２Ａが製造者２Ｂに代金を支払うことになる（Ｐ８）。したがって、小規模な製造者２Ｂは、数多くの販売店４との間で取引関係を構築する手間をかけなくとも、既にそのような取引関係を構築している製造者２Ａに販売を委託することにより、支援システム１を利用して各地の料飲店３に商品を販売する機会を獲得することができる。それにより、小規模の製造者２Ｂが市場に参入する際の負担が軽減され、かつ料飲店３からみれば小規模の製造者２Ｂが製造する商品を容易かつ安全に入手することが可能となる。

図２は、支援システム１の具体的構成を示している。サーバＳＶには、コンピュータハードウエア資源とソフトウエア資源との組み合わせによって実現される各種の論理的装置が設けられる。詳細は後述する。一方、データストレージＤＳにはマスターデータ２０が保存されている。マスターデータ２０は、支援システム１の運営にあたって参照されるべき基本的な情報を記録したデータである。マスターデータ２０には、商品マスタ２１、製造者マスタ２２、料飲店マスタ２３、販売店マスタ２４、帳合マスタ２５及び運営マスタ２６が含まれている。

商品マスタ２１は、製造者２から提供可能な商品を各料飲店３が選択するために必要な商品の情報を商品ごとに記録したデータであって、商品データの一例に相当する。商品マスタ２１には、例えば商品の名称、画像、特徴といった商品の選択に必要な情報が商品コードと対応付けて記録される。商品マスタ２１に記録される情報は、製造者２の申請に基づいて決定される。商品コードは、支援システム１にて商品を一意に判別するために設定される識別情報である。支援システム１にて用いられる商品コードに加えて、販売店４が自社における取引の管理等のために独自の商品コードを付番することも可能である。その場合、支援システム１の商品コードと販売店４における商品コードとの対応関係を記録したデータを設けることにより、いずれか一方の商品コードから他方の商品コードを特定可能としてもよい。また、商品マスタ２１には、商品の価格情報２７も記録される。価格情報２７は製造者２が販売店４に商品を販売する際の卸価格、及び販売店４が料飲店３に商品を販売する際の小売価格が記録される。委託者の製造者２Ｂの商品に関しては、製造者２Ｂから製造者２Ａへの卸価格、受託者の製造者２Ａから販売店４への卸価格の両者が価格情報２７に記録される。なお、価格情報２７は商品マスタ２１の一部としてデータストレージＤＳに保存される例に限らず、商品マスタ２１とは区別して価格マスタとして保存されてもよい。その場合、商品コードと卸価格及び小売価格とを対応付けて価格マスタに記録することにより、商品コードを介して商品の情報と価格とを相互に結び付けることができる。

製造者マスタ２２は、商品マスタ２１に登録されている商品の製造者２に関する情報を記録したデータである。製造者マスタ２２には、製造者の名称、所在地といった製造者２の詳細を判別するために必要な情報が製造者２ごとにユニークな識別情報としての製造者コードと対応付けて記録される。製造者マスタ２２に記録される情報は、製造者２の申請に基づいて決定される。製造者２が支援システム１の各種の機能を利用する場合に、その製造者２を認証するために必要な認証情報（一例としてＩＤ及びパスワード）も製造者マスタ２２に記録される。支援システム１を利用して商品を販売する場合、製造者マスタ２２への登録が必須である。なお、支援システム１の運営事業者を兼ねる製造者２については自社の情報となるので、製造者マスタ２２への登録が省略されてもよい。

料飲店マスタ２３は、料飲店３に関する情報を記録したデータである。料飲店マスタ２３には、料飲店３の名称、所在地といった料飲店３の詳細を判別するために必要な情報が料飲店３ごとにユニークな識別情報としての料飲店コードと対応付けて記録される。支援システム１にて用いられる料飲店コードに加えて、販売店４が自社における取引の管理等のために独自の料飲店コードを付番することも可能である。その場合、支援システム１の料飲店コードと販売店４における料飲店コードとの対応関係を記録したデータを設けることにより、いずれか一方の料飲店コードから他方の料飲店コードを特定可能としてもよい。料飲店マスタ２３に記録される情報は、料飲店３から提供される情報に基づいて決定されるが、支援システム１における料飲店マスタ２３への登録や更新は販売店４からの申請に基づいて行われる。料飲店３が支援システム１の各種の機能を利用する場合に、その料飲店３を認証するために必要な認証情報（一例としてＩＤ及びパスワード）も料飲店マスタ２３に記録される。さらに、料飲店マスタ２３には与信情報２８も記録される。与信情報２８は、料飲店３が支援システム１を利用して購入可能な商品の上限額（与信限度額）を定めた情報である。与信情報２８の与信限度額は料飲店３と取引関係を有する販売店４の申請に基づいて設定される。与信情報２８は、例えば販売店４が設定した与信限度額を超えて料飲店３が支援システム１を通じて商品を購入する不都合の発生を防止するといった用途に利用される。

販売店マスタ２４は、販売店４に関する情報を記録したデータである。販売店マスタ２４には、販売店４の名称、所在地といった販売店４の詳細を判別するために必要な情報が販売店４ごとにユニークな識別情報としての販売店コードと対応付けて記録される。販売店マスタ２４に記録される情報は、販売店４の申請に基づいて決定される。販売店４が支援システム１の各種の機能を利用する場合に、その販売店４を認証するために必要な認証情報（一例としてＩＤ及びパスワード）も販売店マスタ２４に記録される。さらに、販売店マスタ２４には、取引範囲情報の一例としての免許情報２９も記録される。免許情報２９は、酒類の販売にあたっては、法令上又は行政上の要請により、販売店４が販売可能な地域、販売可能な商品の種類といった取引範囲を定めた販売免許の取得が義務付けられることがある。免許情報２９は、販売店４がどのような免許を取得しているかを判別するための情報であって、例えば料飲店３と販売店４との取引関係が販売免許に照らして適当か否かを判別するといった用途に利用される。

帳合マスタ２５は、取引関係を有する料飲店３の料飲店コードと販売店４の販売店コードとを対応付けて記録したデータであって、帳合データの一例に相当する。帳合マスタ２５に記録される対応関係は、料飲店３の意思に基づいて決定されるが、支援システム１における帳合マスタ２５への登録や更新は販売店４からの申請に基づいて行われる。帳合マスタ２５を参照することにより、料飲店３が商品を購入した際に、その商品の販売をいずれの販売店４の仕入及び売上として計上すべきかを判別することができる。運営マスタ２６は、支援システム１を運営するために必要なその他の情報、例えば酒類の製造販売に関して設定される税率、料飲店３等の所在地に対応する郵便番号といった情報が運営マスタ２６に記録される。運営マスタ２６の情報は支援システム１の管理者としての管理部門２ｂにより管理される。

データストレージＤＳには、マスターデータ２０の他に、支援システム１の運営に伴って逐次更新されるデータとして、入荷データ３１、出荷データ３２、在庫データ３３、受注データ３４、売上データ３５、発注データ３６及び請求データ３７が記録される。入荷データ３１は物流拠点５における商品の入荷実績を記録したデータである。例えば、入荷した商品に関する製造者の製造者コード、入荷した商品の商品コード及び数量、入荷日といった情報が入荷データ３１に記録される。出荷データ３２は物流拠点５における商品の出荷実績を記録したデータである。例えば、出荷した商品に関する製造者コード、商品コード、出荷先となる料飲店３の料飲店コード、その料飲店３に対応する販売店４の販売店コード、出荷数量、出荷日といった情報が出荷データ３２に記録される。

在庫データ３３は、物流拠点５における商品の在庫量を商品ごとに記録したデータである。在庫データ３３には全ての物流拠点５における商品の在庫量を一元的に管理するために利用される。各商品がどの物流拠点５に保管されているかを判別するため、在庫データ３３には、例えば物流拠点５と商品の在庫量とが商品コードに対応付けて記録される。受注データ３４は、支援システム１を利用した料飲店３からの注文を受け付けた実績（受注実績）を記録したデータである。受注データには、注文主の料飲店３の料飲店コード、注文日時、注文された商品の商品コード及び注文の数量、注文額といった商品の注文内容を判別するために必要な情報が記録される。

売上データ３５は、支援システム１を利用した商品の売上実績を記録したデータである。売上データ３５には、購入された商品の商品コード、商品を購入した料飲店３の料飲店コード、その料飲店３と対応する販売店４の販売店コード、購入された商品の製造者２の製造者コード、売上数量、売上額、売上日時といったように、支援システム１における商品の売上の内容を判別するために必要な情報が記録される。発注データ３６は、料飲店３における商品の購入に対応する販売店４の仕入実績を記録したデータである。発注データ３６には、販売店４が仕入れた商品の製造者コード、商品コード、仕入数量、仕入額、仕入日時といった商品の仕入内容を判別するために必要な情報が記録される。請求データ３７は、販売店４の仕入実績に対応して製造者２が販売店４に請求すべき売上の明細（あるいは請求書）を記録したデータである。請求データ３７には、請求書の発行元となるべき製造者２の製造者コード、請求書の発行先となるべき販売店４の販売店コード、請求期間内に販売店４が仕入れた商品の商品コード、仕入数量、仕入日時、商品ごとの請求額、合計請求額といった仕入代金（製造者２からみれば売上代金）の請求内容を判別するために必要な情報が記録される。

サーバＳＶには、上述した論理的装置として、受注処理部４１、出荷指示部４２、在庫管理部４３、売上処理部４４、マスタ管理部４５、及び閲覧制御部４６が設けられている。受注処理部４１は、商品マスタ２１及び在庫データ３３に基づいて各料飲店３の端末装置１３に注文内容を選択させるための商品選択情報を提供し、各料飲店３の端末装置１３から各料飲店３の商品に関する注文を受け付けることにより、受注処理手段の一例として機能する。出荷指示部４２は、受注処理部４１が受け付けた注文の内容に基づいて、各料飲店３が注文した商品の出荷を物流拠点５の端末装置１５に指示することにより、出荷指示手段の一例として機能する。在庫管理部４３は、物流拠点５における各商品の在庫量の変動に関する情報を物流拠点５の端末装置１５から取得し、得られた情報に基づいて在庫データ３３を管理することにより、在庫管理手段の一例として機能する。

売上処理部４４は、支援システム１を利用した料飲店３への商品の販売を、その料飲店３と取引関係を有する販売店４が料飲店３の注文した商品を製造者２から仕入れて料飲店３に販売した取引とみなし、その取引に伴って発生すべき製造者２及び販売店４のそれぞれの売上代金の処理に必要な情報を生成し、その情報を製造者２及び販売店４の端末装置１２、１４に適宜に提供する。それにより、売上処理部４４は売上処理手段の一例として機能する。マスタ管理部４５は、管理部門２ｂの端末装置１２ｂからの指示に基づいて、マスターデータ２０に含まれている各種のマスタ２１〜２６に新規のデータを登録し、あるいは既に登録されているデータを変更又は修正し、あるいはデータを削除するといったマスタ２１〜２６の管理に関連した処理を担当する。閲覧制御部４６は、製造者２、料飲店３、販売店４及び物流拠点５のそれぞれの端末装置１２〜１５からの求めに応じて、データストレージＤＳに記録されている各種の情報を端末装置１２〜１５に提供して端末装置１２〜１５のオペレータに閲覧させる。特に、閲覧制御部４６は、委託者である製造者２Ｂの端末装置１２からの求めに応じ、その製造者２Ｂが提供する商品に関する在庫データ３３を閲覧させることにより、閲覧制御手段の一例として機能する。

なお、支援システム１において、データストレージＤＳに記録されるデータ、あるいはサーバＳＶに設けられる論理的装置は図２に示した例に限定されず、各種のデータがデータストレージＤＳに記録され、あるいは各種の論理的装置がサーバＳＶに構成されてよい。

次に、図３〜図１６を参照して、支援システム１における各種の処理を順次説明する。なお、図３〜図１６において、「製造者」は製造者２Ａの製造部門２ａにおける端末装置１２ａ又は製造者２Ｂにおける端末装置１２を、「料飲店」は料飲店３における端末装置１３を、「販売店」は販売店４における端末装置１４を、「物流拠点」は物流拠点５における端末装置１５をそれぞれ意味し、「システム」は支援システム１におけるコンピュータシステム１０を意味する。図３〜図１６に示した処理は支援システム１のサーバＳＶ及び端末装置１２〜１５間における情報の送受信を利用して実現される処理であるが、以下では、便宜上、支援システム１、製造者２、料飲店３、販売店４及び物流拠点５のそれぞれにおける処理又は手続として説明する。また、図３〜図１６における「管理者」は、管理部門２ｂにおける端末装置１２ｂを意味し、製造者２Ａにおける管理部門２ｂにて支援システム１の運営を担当する部署又は者が本来の管理者に相当するが、以下では便宜上管理者を参照符号２ｂで示す。

（入荷処理）
図３は、製造者２が物流拠点５に商品を納入した場合に行われる入荷処理の手順の一例を示している。入荷処理は、在庫データの管理に必要な処理の一部として行われるものである。なお、図３における支援システム１の処理は、在庫管理部４３が担当する処理である。製造者２が物流拠点５に商品を納入する場合、まず製造者２から入荷予定が通知され（ステップＳ１０１）、その入荷予定は管理者２ｂ、物流拠点５及び支援システム１に適時送信される（ステップＳ１０２、Ｓ１０３）。支援システム１は、入荷予定を受け取ると、その内容を入荷データ３１に記録する（ステップＳ１０４）。物流拠点５に商品が納入され、検品といった作業を経て入荷が確認されると、物流拠点５から支援システム１及び管理者２ｂに対し、在庫量の変動に関する情報として入荷実績の情報が通知される（ステップＳ１０５）。支援システム１は入荷実績を入荷データ３１に登録し（ステップＳ１０６）、管理者２ｂからの入荷実績の照会に応じて入荷データ３１に登録された入荷実績の情報を管理者２ｂに提供する（ステップＳ１０７）。

管理者２ｂにおいては、物流拠点５からの入荷実績の通知が取得される（ステップＳ１０８）。その後、支援システム１に入荷実績を照会してこれを確認する処理が行われる（ステップＳ１０９）。その確認は、一例として物流拠点５から通知される入荷実績と、支援システム１から送られる情報との整合性のチェック、あるいは端末装置１２ｂのオペレータによる目視確認を利用して行われてよい。入荷実績が確認されると、管理者２ｂから支援システム１に対して入荷実績の登録確定が指示される（ステップＳ１１０）。その指示を受けて支援システム１は入荷実績の登録を確定し、入荷された商品の数量が入荷数量に応じて加算されるように在庫データ３３を更新する（ステップＳ１１１）。その後、支援システム１は、製造者２からの入荷実績の照会に応じて入荷実績の登録情報を製造者２に提供する（ステップＳ１１２）。製造者２は、その情報を受け取ることにより、自己の商品が物流拠点５に入荷されて入荷データ３１に正しく反映されていることを確認することができる（ステップＳ１１３）。なお、図３において、入荷予定に関連するステップＳ１０１〜Ｓ１０４の処理は省略されてもよい。

（受注処理）
図４〜図６は、料飲店３から商品が注文された場合に行われる受注処理の手順の一例を示している。なお、図４〜図６における支援システム１の処理は支援システム１の受注処理部４１が担当する処理である。料飲店３が商品を注文する場合、まず料飲店３から支援システム１に対して商品選択情報の提供が要求される（ステップＳ１２１）。これを受けて支援システム１は商品マスタ２１及び在庫データ３３を取得し（ステップＳ１２２）、料飲店３に商品及びその数量を選択させるための商品選択情報を料飲店３に提供する（ステップＳ１２３）。この場合、支援システム１は、商品（ただし、商品マスタ２１に登録されているもの。）の在庫量を在庫データ３３から取得し、料飲店３に対して販売することが可能な商品の名称、画像、価格、特徴といった各種の属性、及びその商品の販売可能な数量を商品選択情報に含めるようにして料飲店３に商品選択情報を提供する。ここでいう価格は、料飲店３に対する販売価格であり、いわゆる小売価格に相当する。料飲店３では、例えばＷｅｂブラウザ等を利用して商品選択情報が端末装置１３のオペレータにより閲覧される（ステップＳ１２４）。料飲店３ではその商品選択情報を利用して購入を希望する商品及び数量が選択される（ステップＳ１２５）。その選択の間、支援システム１には選択状況を判別するための情報が適時送信され、支援システム１はその情報に従って販売不可能な商品の選択、あるいは販売可能な数量を超える数量の選択が不可能となるように料飲店３における選択を制御する（ステップＳ１２６）。なお、販売可能な数量は、商品の在庫量に基づいて適宜に定めることができる。例えば、在庫量を販売可能な数量の上限として設定してもよいし、在庫量から一定の余裕値を減算した数量を販売可能な数量の上限値として設定してもよい。近日中に入荷予定がある場合には、在庫量にその入荷予定量を加えた値を販売可能な数量の上限値として設定してもよい。

料飲店３にて商品及び数量の選択が終了すると、注文確定が支援システム１に通知される（ステップＳ１２７）。なお、注文確定に先立って、支援システム１では、不正な注文を防止するために、料飲店３に認証情報を利用したログインを要求し、ログインが完了していることを条件として注文確定の通知を受け付ける。支援システム１は、注文確定が通知されると、料飲店３の注文内容、つまり商品及びその数量を判別し（ステップＳ１２８）、続いて注文した料飲店３と取引関係を有する販売店４を帳合マスタ２５に基づいて判別する（ステップＳ１２９）。受注処理部４１は、ステップＳ１２９の処理を行うことにより、販売店判別手段の一例として機能する。

さらに、支援システム１は与信チェックを実行する（ステップＳ１３０）。与信チェックは、料飲店３の注文内容に基づいて購入額を計算し、その購入額と、請求データ３７に記録されている料飲店３の購入額を所定期間内にて合計した金額が、与信情報に記録されている料飲店３の与信限度額以内か否かを判別する処理である。与信限度額内であれば与信承認と判断され、与信限度額を超えていれば与信が不承認と判断される。ここまでの処理では販売店４が料飲店３による商品の注文を知り得ず、販売店４が知らないうちに与信限度額を超えた取引が成立する可能性があるため、そのような不都合を防止するために支援システム１にて自動的に与信チェックが行われる。

与信チェックが終わると、支援システム１は受注結果を料飲店３に通知する（ステップＳ１３１）。ここでは、料飲店３の注文内容と与信チェックの結果とが受注結果として通知される。料飲店３では支援システム１から受注結果が取得され（ステップＳ１３２）、与信が承認されたか否かが判断される（ステップＳ１３３）。与信が承認されている場合、料飲店３から支援システム１に受注確認が通知される（ステップＳ１３４）。その通知を受けて支援システム１は料飲店３からの受注を一旦確定させ、その注文内容、すなわち注文された商品のコード、数量、注文日時、注文元の料飲店３、注文先の販売店４といった注文内容を記録した受注情報を受注データ３４に登録する（ステップＳ１３５）。一方、与信が不承認であった場合、料飲店３では所定のエラー処理が行われる（ステップＳ１３６）。エラー処理としては、例えば購入額が与信限度額内に収まるように注文内容を修正する機会を料飲店３に付与し、料飲店３からの指示に応じて支援システム１が注文を修正するといった処理を設定することができる。あるいは、与信の不承認が生じた場合、与信限度額を修正（引き上げ）する機会を与えることも可能である。その場合の処理の一例を図５に示す。

図５の処理において、まず支援システム１は図４のステップＳ１３０の与信チェックにて与信が不承認と判断されたことをトリガとして、料飲店３に対応する販売店４に対して与信エラーの発生を通知する（ステップＳ１４１）。その通知は、与信が不承認となった料飲店３を特定する情報を少なくとも含む。販売店４では、支援システム１からの通知を受けて与信エラーの発生が確認される（ステップＳ１４２）。一方、料飲店３では、図４のステップＳ１３２、Ｓ１３３の処理により料飲店３では与信の不承認が生じたことを確認することができる。料飲店３が与信限度額の引き上げを希望し、料飲店３と販売店４との間で合意が形成された場合に図５の処理が続行される。その場合、販売店４にて与信限度額の修正内容が入力され（ステップＳ１４３）、その修正が支援システム１に対して指示される（ステップＳ１４４）。これを受けて支援システム１は料飲店３に関する与信限度額が修正されるように与信情報を修正する（ステップＳ１４５）。なお、与信限度額の修正は期間を限ることにより、一時的に引き上げられるようにしてもよいし、新たな指示がない限り、修正後の与信限度額が適用されるものとしてもよい。

以上のように、支援システム１では、与信の不承認が生じた場合、注文内容が修正され、あるいは与信限度額が引き上げられるといった措置により、注文内容が与信限度額の範囲内に収まらない限り、ステップＳ１３５にて受注が登録されることがないように注文の受け付けが制御される。

図６は、図４の処理に続く受注処理の手順を示している。図４のステップＳ１３５で受注を確定させた後、支援システム１は受注内容を所定の規則に従ってチェックする（ステップＳ１５１）。ここで行われるチェックは、注文の重複のチェック、あるいは数量の異常値の有無のチェックといったように、料飲店３における操作ミス等に起因して誤った注文がなされていないか否かを確認するものである。続いて、支援システム１はチェック結果にエラーが存在するか否かを判別する（ステップＳ１５２）。エラーがあった場合、支援システム１は、管理者２ｂに受注情報を通知する（ステップＳ１５３）。受注情報は、ステップＳ１３５で一旦確定した受注内容を記録した情報である。管理者２ｂでは支援システム１からの通知により、エラーが生じている受注情報が確認される（ステップＳ１５４）。この場合、管理部門２ｂの担当者は料飲店３に電話その他の連絡手段で連絡して受注情報をどのように修正すべきか料飲店３の意思を確認する。

料飲店３からの修正指示を受けて担当者が端末装置１２ｂに修正内容を入力すると、その入力した修正内容が管理者２ｂから支援システム１に通知され（ステップＳ１５５）、これを受けて支援システム１は、管理者２ｂからの指示がステップＳ１３５で一旦登録した受注情報に反映されるように受注データ３４を修正する（ステップＳ１５６）。受注データ３４が修正され、又はステップＳ１５２でエラーがないと判断された場合に注文が成立し、支援システム１は、料飲店３からの注文に応じて登録された受注情報を、図４のステップＳ１２９で判別した販売店４に提供する（ステップＳ１５７）。販売店４では、支援システム１から提供された受注情報が取得される（ステップＳ１５８）。それにより、販売店４は、自己と取引関係を有する料飲店３の注文内容を把握し、料飲店３が注文した商品を自らの売上として処理し、あるいは料飲店３が注文した商品を自らの仕入として処理することができる。なお、ステップＳ１５７で提供する情報は、販売店４の求めに応じて適宜に設定されてよい。例えば、販売店４が売上及び仕入を管理するシステムを導入している場合、そのシステムが必要とする情報が受注情報として販売店４に提供されてよい。ステップＳ１５７にて受注情報を提供した後、支援システム１は、注文された商品を出荷するための処理を開始する（ステップＳ１５８）。なお、図６において、受注チェックに関連するステップＳ１５１〜ステップＳ１５６の処理は適宜に省略されてもよい。

（出荷処理）
図７及び図８は、図６のステップＳ１５８を受けて行われる出荷処理の手順の一例を示している。これらの処理は、図４〜図６の処理で確定された受注情報に対応した商品を注文主である料飲店３が指定する配送先に向けて出荷するための処理であり、注文された商品を保管する物流拠点５が在庫データ３３を参照して選択される。複数の商品が複数の物流拠点５に分散して保管されている場合には、受注情報が物流拠点５ごとに分割されて図７の処理が行われる。また、注文された商品が複数の物流拠点５に保管されている場合には、料飲店３の所在地等、物流コスト等に応じて最適の物流拠点５が選択される。商品の配送先は、例えば料飲店マスタ２３に記録されている所在地であってもよいし、商品を注文する際に料飲店３が指定した場所でもよい。なお、図７及び図８の支援システム１の処理は、特に断りがない限り出荷指示部４２が担当する処理である。

出荷処理では、まず管理者２ｂからの指示に従って支援システム１が物流拠点５に対して出荷を指示するための出荷指示データを作成し（ステップＳ１６１、Ｓ１６２）、続いて管理者２ｂからの指示に従って支援システム１が配送業者に配送を依頼するための送り状のデータを作成する（ステップＳ１６３、Ｓ１６４）。出荷指示データ及び送り状データの作成時には、受注データ３４に記録されている受注データのうち、今回の処理で出荷の対象となる受注情報が適宜に参照される。管理者２ｂにて出荷指示及び送り状のデータが確認されると、管理者２ｂから支援システム１にデータの確定が指示される（ステップＳ１６５）。これを受けて支援システム１は出荷指示及び送り状のデータを確定し（ステップＳ１６６）、確定したデータを物流拠点５に提供する（ステップＳ１６７）。物流拠点５では、支援システム１から提供されたデータに基づいて出荷作業が指示される（ステップＳ１６８）。出荷作業としては、注文された商品の在庫の引当、ピッキング、梱包、検品、荷札発行、配送業者の手配といった各種の作業が順次進められる。なお、図７における支援システム１の処理は出荷指示部４２が担当する処理である。

出荷が完了すると、図８に示すように物流拠点５から支援システム１に在庫量の変動に関する情報として、出荷実績が通知される（ステップＳ１７１）。支援システム１は、出荷実績が通知されるとその実績を出荷データ３２に登録し、かつ出荷された商品の数量が出荷数量に応じて減算されるように在庫データ３３を更新する（ステップＳ１７２）。この処理は支援システム１の在庫管理部４３が担当する処理である。続いて、支援システム１は出荷実績を管理者２ｂに通知する（ステップＳ１７３）。管理者２ｂにおいては、支援システム１から通知された出荷実績が確認され（ステップＳ１７４）、問題がなければ支援システム１に対して出荷通知が指示される（ステップＳ１７５）。支援システム１では、出荷通知が指示されると、出荷実績に基づいて料飲店３に出荷を案内するための出荷通知を作成し（ステップＳ１７６）、作成された出荷通知を料飲店３に送る（ステップＳ１７７）。出荷通知には、例えば出荷日時、配送予定日時、配送業者といった情報が含まれてよい。料飲店３では、支援システム１からの通知が取得されることにより、注文した商品の出荷を確認することができる（ステップＳ１７８）。続いて、支援システム１は出荷情報を販売店４に提供する（ステップＳ１７９）。出荷情報は、販売店４が料飲店３への商品の出荷を自らが管理するために必要な情報である。出荷情報のフォーマットや内容は、販売店４の都合に合わせて適宜に選択されてよい。販売店４では、支援システム１からの出荷情報が取得される（ステップＳ１８０）。それにより、販売店４は、自らが商品を仕入れて販売した場合と同様にして、料飲店３が注文した商品の出荷を管理することができる。

出荷された商品の配達が完了すると、配送業者から配達完了の情報が管理者２ｂに提供される。管理者２ｂが配達完了を確認すると、その旨が管理者２ｂから支援システム１に通知される（ステップＳ１８１）。支援システム１は、配達完了の通知を受けて出荷データ３２に配達完了を示す情報を登録する（ステップＳ１８２）。さらに、支援システム１は配達情報を販売店４に提供する（ステップＳ１８３）。配達情報は、販売店４が料飲店３への商品の配達を自らが管理するために必要な情報である。配達情報のフォーマットや内容は、販売店４の都合に合わせて適宜に選択されてよい。販売店４では、支援システム１からの配達情報が取得される（ステップＳ１８４）。それにより、販売店４は、自らが商品を仕入れて販売した場合と同様にして、料飲店３が注文した商品の配達を管理することができる。なお、商品が注文され、出荷され、あるいは配達された場合、それらに併せて支援システム１から商品の製造者２に対して注文、出荷、又は配達があったことを示す情報が提供されてもよい。

（在庫調整処理）
図９は、物流拠点５にて商品が廃棄処分された場合に行われる在庫調整処理の手順の一例を示している。例えば、物流拠点５にて保管中の商品が何らかの理由で破損、あるいは汚損した場合、賞味期限又は消費期限のある商品が、それらの期限に余裕を見込んで設定された出荷期限までに出荷されなかった場合等には物流拠点５にて商品が廃棄処分されることがある。そのような場合、商品の在庫量が変動するため、商品の廃棄に合わせて図９の処理が行われる。なお、図９における支援システム１の処理は在庫管理部４３が担当する処理である。

図９の処理において、物流拠点５で商品の廃棄が発生すると、物流拠点５から管理者２ｂに廃棄発生が通知される（ステップＳ１９１）。その通知により、管理者２ｂにて商品の廃棄が発生したことが確認され（ステップＳ１９２）、管理者２ｂから物流拠点５に廃棄が指示される（ステップＳ１９３）。その指示に従って物流拠点５では廃棄作業が指示され（ステップＳ１９４）、廃棄作業に応じた在庫修正の情報が在庫量の変動に関する情報として支援システム１に通知される（ステップＳ１９５）。ここでの通知には、廃棄された商品及びその廃棄した数量が含まれる。なお、ステップＳ１９５において在庫修正を管理者２ｂに通知し、管理者２ｂが支援システム１に在庫データの更新を指示するものとしてもよい。つまり、在庫データは物流拠点５からの情報に基づいて更新される限りにおいて、その指示は管理者２ｂ等の物流拠点５以外の者が行ってもよい。在庫データの更新は、支援システム１は、物流拠点５からの通知に従って、在庫データ３３に記録されている商品の在庫量が廃棄量に応じて減算されるように在庫データ３３を更新する（ステップＳ１９６）。その後、支援システム１は、廃棄された商品の製造者２に対して在庫変動を通知する（ステップＳ１９７）。製造者２においては、その通知により、自己の商品の在庫量が変動したことが確認される（ステップＳ１９８）。製造者２は在庫変動を確認することにより、損金計上といった経理処理を行い、あるいは変動に対応した製造計画の修正等を検討することができる。なお、在庫量は、廃棄以外にも、例えば料飲店３からの返品、配達不能に伴う配送業者からの返却といった事態が生じた場合にも生じ得る。そのような場合は、図９と同様にして在庫量の増減を示す情報を支援システム１に通知して在庫データ３３に反映させればよい。

（売上処理）
次に、図１０〜図１２を参照して、支援システム１を利用した商品の販売に伴う売上計上、代金請求といった代金決済に関連して行われる売上処理の手順の一例を説明する。支援システム１を利用した代金決済では、図１で示したように、料飲店３と販売店４との間の代金決済（Ｐ６）と、製造者２Ａと販売店４との間の代金決済（Ｐ７）と、製造者２Ａ、２Ｂ間の代金決済（Ｐ８）とが存在する。以下、それらの決済に伴う処理を順に説明する。なお、図１０〜図１２における支援システム１の処理は、売上処理部４４が担当する処理である。

図１０は、製造者２Ａと販売店４との間における売上代金の決済のために実行される売上処理の手順の一例を示している。図１０の処理において、支援システム１は、まず所定の集計期間、例えば所定の締め日から過去に一か月の期間における出荷実績を出荷データ３２から取得する（ステップＳ２０１）。ここで取得される出荷実績の情報は、集計期間における商品の販売実績を示す情報の一例に相当する。次に、支援システム１は、取得された出荷実績の情報に基づいて、販売店４別に発注データ３６を作成する（ステップＳ２０２）。

続いて、支援システム１は、発注データ３６に基づいて、製造者２Ａが販売する商品に関する販売店４ごとの売上データ３５を作成する（ステップＳ２０３）。さらに、支援システム１は、ステップＳ２０３で生成した売上データ３５に基づいて、製造者２Ａから各販売店４に対して請求すべき代金（販売店４からみれば仕入代金である。）を記録した請求データ３７を作成する（ステップＳ２０４）。請求データ３７を作成する際の商品の価格は、製造者２Ａから販売店４に販売される際の卸価格であり、価格情報２７から取得される。その後、支援システム１は請求データ３７に基づいて請求書を発行し、これを管理者２ｂに提供する（ステップＳ２０５）。この段階の請求書は電子データである。その請求書のデータは、製造者２Ａにおける売上代金の処理に必要な情報の一種に相当する。管理者２ｂに請求書が提供されると、管理者２ｂから販売店４に請求書が発行され（ステップＳ２０６）、その請求書が販売店４にて受領される（ステップＳ２０７）。なお、請求書の発行及び受領は、端末装置１２ｂ、１４を利用した送受に限らず、郵送その他の手段により行われてもよい。販売店４が請求書に従って仕入代金を支払うと、管理者２ｂにおいて所定の消し込み処理が行われて支援システム１における請求データ３７に反映されるが、その手順は図示を省略した。

図１１は、販売店４と料飲店３との間における代金決済のために実行される売上処理の手順の一例を示している。販売店４が料飲店３に対して売上代金を請求する場合、まず販売店４から支援システム１に対して所定の集計期間内における売上明細が要求される（ステップＳ２１１）。その要求に対して、支援システム１は集計期間内における出荷データ３２に基づいて、販売店４が出荷元となっている出荷実績をその販売店４における売上明細として抽出し（ステップＳ２１２）、得られた売上明細を、販売店４における売上代金の処理に必要な情報の一例として販売店４に提供する（ステップＳ２１３）。ここで抽出される売上明細の情報は、集計期間内における商品の販売の実績を示す情報の一例に相当する。ただし、売上明細は、出荷データ３２に代えて受注データ３４から抽出されてもよい。料飲店３に対する商品の配達実績が記録されている場合には、その配達実績の情報が商品の販売の実績を示す情報の一例として利用されてもよい。売上明細は、集計期間内に販売された商品及びその数量、販売日時、販売代金が販売先の料飲店３と対応付けて記録された情報である。販売代金は、価格情報２７に記録された小売価格（単価）に商品の数量を乗算して得られる金額である。

支援システム１から提供される売上明細が販売店４にて取得されると（ステップＳ２１４）、販売店４ではその売上明細に基づいて料飲店３ごとの請求書が作成される（ステップＳ２１５）。その後、販売店４から料飲店３に請求書が発行され（ステップＳ２１６）、その請求書が料飲店３にて受領される（ステップＳ２１７）。なお、請求書の発行及び受領は、端末装置１４、１３を利用した送受に限らず、郵送その他の手段により行われてもよい。販売店４が売上明細を取得した後の処理は販売店４が適宜に定めて実行すればよい。例えば、販売店４から料飲店３に対する請求書の発行を、現実の商品の仕入及び販売を伴った販売店４と料飲店３との間の商取引における代金決済と一括して行うようにしてもよい。販売店４が料飲店３に対する取引を処理するシステムを保有している場合には、そのシステムに適合した売上明細を支援システム１から取得し、あるいは支援システム１から取得した売上明細を販売店４のシステムに適合した内容に加工することにより、販売店４の既存システムにて代金決済を処理するようにしてもよい。

図１２は、委託関係にある製造者２Ａ、２Ｂ間における代金決済のために実行される売上処理の手順の一例を示している。なお、図１２における「製造者」は委託者の製造者２Ｂであり、「管理者」が受託者の製造者２Ａに相当する。製造者２Ａが製造者２Ｂに対して商品の仕入代金を支払う場合、まず管理者２ｂから支援システム１に対して所定の集計期間内における出荷実績の提供が要求される（ステップＳ２２１）。これを受けて支援システム１は、集計期間内に製造者２Ｂの商品に関する出荷実績を出荷データ３２から抽出し（ステップＳ２２２）、得られた出荷実績を管理者２ｂに提供する（ステップＳ２２３）。管理者２ｂにおいては、支援システム１から提供された出荷実績に基づいて、製造者２Ａが製造者２Ｂから商品を仕入れた実績、その実績に対応して製造者２Ｂが製造者２Ａに請求すべき代金、製造者２Ａの支払い予定といった代金決済に必要な事項が決定される（ステップＳ２２４）。なお、ここで計算される代金は、製造者２Ｂが製造者２Ａに商品を販売する価格から、支援システム１を利用して商品を販売する製造者２Ａの手数料を差し引いた額として決定される。その後、管理者２ｂから製造者２Ｂに対してステップＳ２２４で決定した仕入実績等の情報が提供される（ステップＳ２２５）。ここで提供される情報は、委託者における売上代金の処理に必要な情報の一例に相当する。

製造者２Ｂにおいては、管理者２ｂから提供された情報に従って仕入実績等が確認され（ステップＳ２２６）、その情報に基づいて製造者２Ａに対する請求書が発行され（ステップＳ２２７）、その請求書が管理者２ｂにて受領される（ステップＳ２２８）。なお、図１２の処理においても、請求書の発行及び受領は、端末装置１２を利用した送受に限らず、郵送その他の手段により行われてもよい。管理者２ｂが請求書を受領した後の処理は製造者２Ａ、２Ｂ間の取り決めに従って進められてよい。

なお、製造者２Ｂは商品の販売を製造者２Ａに委託しているため、製造者２Ｂと販売店４との間の代金決済は存在しない。製造者２Ａ以外にも各販売店４と取引関係を構築している他の製造者が支援システム１の利用者に含まれている場合には、その製造者２に関して図１０の処理が行われてよい。

（マスタ管理処理）
図１３〜図１６はマスターデータ２０を管理するために実行される処理の手順の一例を示している。以下では、商品マスタ２１、製造者マスタ２２、料飲店マスタ２３、及び帳合マスタ２５の登録、修正又は更新を管理するための処理を順に説明する。なお、図１３〜図１６における支援システム１の処理はマスタ管理部４５が担当する処理である。

図１３は商品マスタ２１に新たな商品を登録するために行われる処理の手順の一例を示している。この処理は支援システム１を利用して商品を販売しようとする製造者２の申請に基づいて行われる。製造者２は、支援システム１の運営主体である製造者２Ａ、委託者である製造者２Ｂのいずれでもよいが、ここでは委託者である製造者２Ｂの商品を登録する場合を例にして説明する。商品マスタ２１への登録にあたっては、まず、製造者２Ｂから管理者２ｂに対して商品マスタ２１への商品の登録が申請され（ステップＳ３０１）、その申請が管理者２ｂにて確認される（ステップＳ３０２）。製造者２からの申請は、商品マスタ２１に登録されるべき各種の情報、例えば商品の名称、価格、画像、特徴等の情報を含む。価格は、製造者２Ｂから製造者２Ａへの販売する際に設定される卸価格である。管理者２ｂの確認において、申請内容の適否がチェックされてもよい。例えば、商品名称に関する法的妥当性等が管理者２ｂにてチェックされ、適当でない場合には製造者２にその修正が求められてもよい。

管理者２ｂによるチェックが終わると、管理者２ｂから支援システム１に対して商品マスタ２１への情報の登録が指示される（ステップＳ３０３）。これを受けて支援システム１では管理者２ｂから指示された内容に従って商品マスタ２１に製造者２Ｂの商品を登録する（ステップＳ３０４）。ただし、この段階では、商品が販売不可能であることを示す情報が併せて登録される。その登録に併せて、支援システム１は商品マスタ２１に登録された卸価格に基づいて、製造者２Ａから販売店４への卸価格、販売店４から料飲店３への小売価格を予め設定された条件に従って計算し、これを商品マスタ２１の価格情報２７に設定する（ステップＳ３０５）。ステップＳ３０５の処理を行うことにより、マスタ管理部４５は価格設定手段の一例として機能する。

商品マスタ２１への登録指示の後、管理者２ｂからは製造者２Ｂに対して登録が通知される（ステップＳ３０６）。製造者２Ｂはその通知を取得することにより、自己の商品が登録されたことを確認する（ステップＳ３０７）。その後、製造者２Ｂが出荷に備えて物流拠点５に商品を納入するといった作業を適宜に進めるが、これと並行して管理者２ｂと物流拠点５との間では、登録された商品の入荷を確認する処理が行われる（ステップＳ３０８、Ｓ３０９）。入荷が確認されると管理者２ｂから支援システム１に入荷が確認されたことが通知される。これを受けて、支援システム１では、今回登録された商品が販売不可能な商品から販売可能な商品へと変更されるように商品マスタ２１を更新する（ステップＳ３１０）。なお、新たに登録された商品が入庫された場合、図３の処理によりその商品の入荷データ３１及び在庫データ３３が生成される。

図１３の処理では、マスタ管理部４５がステップＳ３０４及びステップＳ３０６の処理を行うことにより、商品情報設定手段の一例として機能する。なお、マスタ管理部４５は、新規に商品を登録する場合に限らず、商品マスタ２１の各種の情報、例えば価格情報２７を変更し、あるいは商品マスタ２１から商品を削除するといったように、商品マスタ２１に登録されている各種の情報を変更し、あるいは削除する必要が生じた場合にも、図１３と同様の手順で商品マスタ２１を更新することができる。

図１４は製造者マスタ２２に新規の製造者２を登録するために実行される処理の手順の一例を示している。まず、製造者２が製造者マスタ２２への自己の登録を申請すると（ステップＳ３２１）、その申請が管理者２ｂにて確認される（ステップＳ３２２）。この場合、管理者２ｂにて、製造者２の登録適否が審査されてもよい。登録が不適当と判断された場合には管理者２ｂから製造者２にその旨が通知されてもよい。その確認後に管理者２ｂから支援システム１に対して製造者マスタ２２への情報の登録が指示される（ステップＳ３２３）。これを受けて支援システム１では管理者２ｂから指示された内容に従って製造者マスタ２２に製造者２Ｂの情報を登録する（ステップＳ３２４）。製造者マスタ２２への登録指示の後、管理者２ｂからは製造者２に対して登録が通知される（ステップＳ３２５）。製造者２はその通知を取得することにより、自己が支援システム１に登録されたことを確認する（ステップＳ３２６）。

図１５は料飲店３が支援システム１を利用して商品を購入するためにその料飲店３を料飲店マスタ２３に登録すべく行われる処理の手順の一例を示している。料飲店３を登録する場合には、まず料飲店３から販売店４に登録が依頼され（ステップＳ３３１）、その依頼を受けた販売店４から管理者２ｂに登録が申請される（ステップＳ３３２）。その申請は料飲店マスタ２３に登録するために必要な情報を含む。この場合、料飲店３と販売店４との間には既に取引関係が構築されているか、あるいは新たに取引関係が形成されることが好ましい。その理由は、支援システム１が料飲店３と販売店４との間に取引関係が存在することを前提とするためである。また、料飲店３の登録を販売店４からの申請によるものとした理由は、料飲店３が販売店４の承諾なく自由に販売店４を選択して登録するおそれを排除するためである。

販売店４からの申請を受けた管理者２ｂにおいては、その申請内容が確認される（ステップＳ３３３）。この段階で申請内容がチェックされ、不適当な申請が管理者２ｂにて排除されてもよい。申請内容の確認が完了すると、管理者２ｂから支援システム１に対して料飲店マスタ２３への申請内容の登録が指示される（ステップＳ３３４）。これを受けて支援システム１は販売店４に関する取引条件をチェックし（ステップＳ３３５）、登録の申請がその取引条件に適合するか否かを判別する（ステップＳ３３６）。この処理は、料飲店３と販売店４との間の取引関係が販売店マスタ２４に登録されている販売店４の免許情報２９に照らして適正であるか否か、言い換えれば販売店４に対して許可された取引範囲内における料飲店３の登録であるか否かを判別する処理である。

取引条件に適合する料飲店３の登録であると判断された場合、支援システム１は申請内容に従って料飲店３の情報を料飲店マスタ２３に登録し（ステップＳ３３７）、その後、料飲店３とその登録を申請した販売店４とが取引関係があることを示す情報を帳合マスタ２５に登録する（ステップＳ３３８）。ステップＳ３３８の処理を行うことにより、マスタ管理部４５は帳合データ設定手段の一例として機能する。その後、支援システム１は管理者２ｂに対して登録を通知する（ステップＳ３３９）。登録通知はさらに管理者２ｂから販売店４、販売店４から料飲店３へと順次通知され（ステップＳ３４０、Ｓ３４１）、料飲店３は販売店４からの通知により登録完了を確認する（ステップＳ３４２）。

支援システム１は、ステップＳ３３６にて料飲店３が販売店４に関する取引条件に適合しないと判断された場合、所定のエラー処理を実行し（ステップＳ３４３）、その後に図１５の処理を終える。ステップＳ３３５、Ｓ３３６及びＳ３４３の処理を実行することにより、マスタ管理部４５は取引制限手段の一例として機能する。なお、エラー処理としては、例えば管理者２ｂに対して取引条件に適合しない登録申請であることを通知し、管理者２ｂから販売店４又は料飲店３に申請内容を修正し、あるいは再申請を検討することを連絡するように指示する、といった処理が適用可能である。このように、料飲店３の登録時に免許情報に照らして販売店４が販売可能な範囲内の料飲店３か否かを判別することにより、支援システム１を通じて販売免許に適合しない取引が販売店４と料飲店３との間で行われる不都合を未然に防止することができる。

図１６は料飲店マスタ２３に登録されている料飲店３が帳合マスタ２５に登録されている販売店４を変更したい場合に行われる処理の手順の一例を示している。料飲店３が販売店４を変更する場合には、まず料飲店３から新たな販売店４に対して取引関係を変更する意思表示がなされる（ステップＳ３５１）。その意思表示を販売店４が承諾した場合、販売店４から管理者２ｂに帳合マスタ２５の登録変更が申請される（ステップＳ３５３）。その申請は、料飲店３及び新たな販売店４の両者を特定する情報が含まれる。管理者２ｂにおいては、帳合マスタ２５の登録変更が申請されると、その申請内容が確認され（ステップＳ３５３）、料飲店３と管理者２ｂとの間で取引関係の変更に関する意思確認の手続が行われる（ステップＳ３５４、Ｓ３５５）。これは、料飲店３の意思によることなく、帳合マスタ２５が変更される不都合を未然に防止するための手続である。

料飲店３の意思確認がなされると、管理者２ｂは申請内容に従って帳合マスタ２５の変更を支援システム１に指示する（ステップＳ３５６）。これを受けて支援システム１は申請内容が販売店４に関する取引条件をチェックし（ステップＳ３５７）、変更の申請がその取引条件に適合するか否かを判別する（ステップＳ３５８）。この処理は、図１５のステップＳ３３６の処理と同様に、販売店マスタ２４に登録されている料飲店３と販売店４との間の取引関係が、販売店４の免許情報に照らして適正であるか否かを判別する処理である。帳合マスタ２５の変更時にも取引条件をチェックする理由は、帳合マスタ２５の変更によって料飲店３と販売店４との関係が販売店４の販売免許に照らして不適切な関係になるリスクが存在するためである。

ステップＳ３５８にて取引条件に適合する変更申請であると判断された場合、支援システム１は申請内容に従って帳合マスタ２５の料飲店３と販売店４との取引関係が変更されるように帳合マスタ２５を更新する（ステップＳ３５９）。ステップＳ３５９の処理を行うことにより、マスタ管理部４５は帳合データ設定手段の一例として機能する。その後、帳合マスタ２５が更新されたことを管理者２ｂに対して通知する（ステップＳ３６０）。更新の通知はさらに管理者２ｂから販売店４、販売店４から料飲店３へと順次通知され（ステップＳ３６１、３６２）、料飲店３は販売店４からの通知により登録完了を確認する（ステップＳ３６３）。この場合、取引関係が解消された販売店４に対しても帳合マスタ２５の更新が通知されてもよい。

支援システム１はステップＳ３５８にて変更申請が取引条件に適合しないと判断した場合には、所定のエラー処理を実行し（ステップＳ３６４）、その後に図１６の処理を終える。ステップＳ３５７、Ｓ３５８及びＳ３６４の処理を行うことにより、マスタ管理部４５は取引制限手段の一例として機能する。エラー処理としては、例えば管理者２ｂに対して取引条件に適合しない登録変更の申請であることを通知し、変更を取り消し、あるいは適切な販売店４を選択するように料飲店３に通知するといった処理が適用可能である。

なお、販売店マスタ２４に対する販売店４の登録に関しては、図１４の処理における「製造者」を「販売店」に読み替えた処理により実現することが可能である。ただし、販売店４の登録にあたっては、その販売店４が所有する販売免許の情報を申告させ、その申告に基づいて免許情報２９を販売店マスタ２４に登録することが必要である。販売店４に関する情報が変更された場合（免許情報２９が変更された場合も含む）においても、図１４と同様の手順にて販売店マスタ２４の登録内容を適宜に修正すればよい。運営マスタ２６の登録内容に関しては、管理者２ｂからの指示で適宜に修正されてよい。

本発明は上述した形態に限定されず、適宜の変形又は変更が施された形態にて実施されてよい。例えば、販売店や提供者が売上代金を処理するために必要な情報は、上記の形態に限定されない。例えば販売店と提供者とが売上代金の処理のために別途の業務処理システムあるいは決済処理システムを共有している場合には、そのシステムが必要とする情報が支援システムから提供されるものとすれば足りる。販売店と料飲店との間、提供者同士の間に関しても同様である。

在庫データの管理に関して、上記の形態では、在庫の変動に関する情報として、物流拠点から入荷実績の情報、出荷実績の情報、及び在庫破棄等の在庫変動の情報の３種類の情報を取得し、支援システムにて在庫量を増減させるものとしたが、物流拠点が実在庫量を管理している場合には、物流拠点における実在庫量を適宜のタイミングで物流拠点のコンピュータ機器から取得し、得られた情報に従って在庫データを更新するものとしてもよい。

図１３〜図１５の例では、商品マスタ等の更新に関して管理者を経由して支援システムのデータを設定するものとしたが、例えば商品マスタはその商品の提供者が支援システムに直接アクセスして情報を設定でき、料飲店マスタや帳合マスタは販売店が支援システムに直接アクセスして情報を設定できるようにしてもよい。

売上処理のために必要な販売実績の情報は、物流拠点５から得られる出荷実績の情報に限られない。例えば、料飲店のコンピュータ機器から取得した注文内容が受注データ３４に記録された場合において、その注文内容自身を販売実績の情報として利用してもよい。あるいは料飲店が受領した商品の明細（商品及びその数量）を、例えば、納品確認のＩＣタグを読み込むといった処理を通じて料飲店のコンピュータ機器が取得可能な場合には、支援システムがその料飲店のコンピュータ機器から販売実績の情報を取得するものとしてもよい。料飲店が注文した内容を販売店に通知した後、販売店と料飲店との間で売上内容を確認させ、確認された販売実績の情報を販売店のコンピュータ機器から支援システムが取得するものとしてもよい。

上記の形態では、一つの料飲店が一つの販売店と帳合データにて対応付けられるものとしたが、一つの料飲店が複数の販売店と帳合データにて対応付けられてもよい。その場合、例えば商品の種類、提供者その他の属性、注文日時、注文金額の大小といった情報を販売店の選択情報として利用し、その選択情報に基づいて、商品を売り上げたものと見なされる一の販売店が選択されるように販売店判別手段の処理を追加してもよい。あるいは、一の料飲店が複数の販売店との間で取引を行う場合には、販売店ごとに異なるアカウントを料飲店３に発行し、アカウントごとに帳合データに料飲店と販売店との取引関係を記録することにより、いずれのアカウントで料飲店３がシステムを利用したかに応じて販売店４を一意に特定するようにしてもよい。上記の形態では複数の提供者が存在することを前提としたが、単一の提供者に対応付けて支援システムが運営されてもよい。複数の提供者が存在する場合において、委託関係が存在する提供者の有無は任意である。提供者は、商品を自ら製造又は生産する者に限定されない。例えば、商品を輸入して市場に提供する輸入業者、他人からの委託を受けて市場に提供する代理業者など、支援システムを介して料飲店に商品を提供し得る限りにおいて各種の者が提供者として取り扱われてよい。

上記の形態では、図４のステップＳ１２６にて商品の購入量の選択が在庫量からみて販売可能な範囲を超えないように制御することにより、販売可能な範囲を超える注文が成立しないように注文の受け付けを制御したが、注文の制御はそのような形態に限定されない。例えば、商品選択の過程で料飲店からの注文を一旦仮注文として受け付け、その後に在庫量に照らして受注可能な数量か否かを判断して受注不可能な場合には数量の修正を求め、その修正を経て注文が成立するように注文の受け付けが制御されてもよい。

商品としての飲料はビールに限定されず、日本酒、焼酎、ウイスキー、ワインその他の各種のアルコール飲料、アルコール分を含まないソフトドリンク、蒸留水、炭酸水といった飲用水、その他、料飲店３にて顧客に提供される各種の飲料が支援システムの取り扱い商品に含まれてよい。さらに、料飲店が販売店から購入する限りにおいて、商品は飲料に限定されず、食料品その他の各種の商品が支援システムにて取り扱われてよい。

１ 商取引支援システム
２Ａ 製造者（提供者、受託者）
２Ｂ 製造者（提供者、委託者）
２ａ 製造部門
２ｂ 管理部門（商取引支援システムの管理者）
３ 料飲店
４ 販売店
５Ａ、５Ｂ 物流拠点
１０ コンピュータシステム
１２、１２ａ、１２ｂ 製造者の端末装置（コンピュータ機器）
１３ 料飲店の端末装置（コンピュータ機器）
１４ 販売店の端末装置（コンピュータ機器）
１５ 物流拠点の端末装置（コンピュータ機器）
２０ マスターデータ
２１ 商品マスタ（商品データ）
２２ 製造者マスタ
２３ 料飲店マスタ
２４ 販売店マスタ
２５ 帳合マスタ（帳合データ）
２６ 運営マスタ
２７ 価格情報
２８ 与信情報
２９ 免許情報（取引範囲情報）
３３ 在庫データ
４１ 受注処理部（受注処理手段、販売店判別手段）
４２ 出荷指示部（出荷指示手段）
４３ 在庫管理部（在庫管理手段）
４４ 売上処理部（売上処理手段）
４５ マスタ管理部（商品情報設定手段、取引制限手段、帳合データ設定手段、価格設定手段）
４６ 閲覧制御部（閲覧制御手段）

Claims (11)

1. 複数の料飲店と、各料飲店にて販売されるべき複数種類の商品を提供する少なくとも一の提供者との間に複数の販売店が介在し、各料飲店が少なくとも一の販売店に対して取引関係を有している商取引形態に適用され、各料飲店からの商品の注文に対応して、当該商品が保管された物流拠点に前記商品の出荷を指示し、かつ各料飲店からの注文を、当該注文に含まれる商品の提供者、各料飲店と前記取引関係のある販売店、及び各料飲店の間における商品の取引として処理するための商取引支援システムであって、
   各料飲店、各販売店、前記提供者、及び前記物流拠点のそれぞれに対応したコンピュータ機器と所定の通信回線を介して接続されたコンピュータシステムを具備し、
   前記コンピュータシステムには、
   前記提供者から提供可能な商品を各料飲店が選択するために必要な商品ごとの商品データと、前記商品ごとの在庫量を記録した在庫データと、各料飲店と各販売店との取引関係を記録した帳合データとを記憶する記憶手段と、
   前記商品データに基づいて各料飲店のコンピュータ機器に前記商品の注文の内容を選択させるための商品選択情報を提供し、前記在庫データに記録された在庫量からみて販売可能な範囲で注文が成立するように各料飲店のコンピュータ機器からの前記商品の注文の受け付けを制御する受注処理手段と、
   前記受注処理手段が受け付けた注文の内容に基づいて、各料飲店が注文した商品の出荷を前記物流拠点のコンピュータ機器に指示する出荷指示手段と、
   前記物流拠点における各商品の在庫量の変動に関する情報を前記物流拠点のコンピュータ機器から取得し、得られた情報に基づいて前記在庫データを管理する在庫管理手段と、
   各料飲店からの注文を前記受注処理手段が受け付けた場合、前記帳合データに基づいて、各料飲店の注文に対応して売上を計上すべき販売店を判別する販売店判別手段と、
   前記受注処理手段が受け付けた注文に対応する商品の販売の実績を示す情報を前記料飲店、前記販売店及び前記物流拠点の少なくともいずれか一つのコンピュータ機器から取得し、得られた情報に基づいて、前記販売店判別手段にて判別された販売店が前記料飲店の注文した商品を前記提供者から仕入れて当該料飲店に販売したとみなした場合に発生すべき前記提供者及び前記販売店のそれぞれの売上代金の処理に必要な情報を生成し、前記販売店における売上代金の処理に必要な情報を前記販売店のコンピュータ機器に提供し、かつ前記提供者における売上代金の処理に必要な情報を前記提供者のコンピュータ機器に提供する売上処理手段と、
   を備えた商取引支援システム。
2. 前記少なくとも一の提供者として複数の提供者が存在し、
   前記在庫管理手段は、前記複数の提供者のそれぞれが提供する商品の前記物流拠点における在庫量が前記在庫データに反映されるようにして前記在庫データを管理する請求項１に記載の商取引支援システム。
3. 前記複数の提供者には、前記商品の取引に関する委託関係が存在する委託者及び受託者が含まれ、
   前記売上処理手段は、前記受注処理手段が受け付けた注文に対応した商品に前記委託者の商品が含まれている場合、前記販売店が当該商品を前記受託者から仕入れて前記料飲店に販売したとみなして前記販売店及び前記受託者のそれぞれの売上代金の処理に必要な情報を前記販売店のコンピュータ機器及び前記受託者のコンピュータ機器に提供するとともに、前記受注処理手段が受け付けた注文に対応する商品に含まれている前記委託者の商品を当該委託者が前記受託者に販売したとみなした場合に発生すべき前記委託者の売上代金の処理に必要な情報を前記商品の販売の実績を示す情報に基づいて生成し、当該情報を前記委託者のコンピュータ機器に提供する、請求項２に記載の商取引支援システム。
4. 前記コンピュータシステムには、前記委託者が提供する商品に関する在庫データを当該委託者のコンピュータ機器から閲覧させる閲覧制御手段がさらに設けられている請求項３に記載の商取引支援システム。
5. 前記記憶手段は、前記販売店が前記料飲店に対して設定した与信条件を特定する与信情報をさらに記憶し、
   前記受注処理手段は、前記与信条件に反する注文が成立することがないように、前記料飲店からの注文の受け付けを前記与信情報に基づいて制御する請求項１〜４のいずれか一項に記載の商取引支援システム。
6. 前記コンピュータシステムには、前記提供者からの要求に基づいて前記商品データを設定する商品情報設定手段がさらに設けられている請求項１〜５のいずれか一項に記載の商取引支援システム。
7. 前記記憶手段は、各販売店の取引範囲を規定する取引範囲情報をさらに記憶し、
   前記コンピュータシステムには、前記取引範囲情報に基づいて、前記取引範囲外の関係にある料飲店と販売店との間における取引の発生を防止する取引制限手段がさらに設けられている請求項１〜６のいずれか一項に記載の商取引支援システム。
8. 前記コンピュータシステムには、前記販売店からの要求に基づいて前記帳合データを設定する帳合データ設定手段がさらに設けられている請求項１〜６のいずれか一項に記載の商取引支援システム。
9. 前記記憶手段は、各販売店の取引範囲を規定する取引範囲情報をさらに記憶し、
   前記コンピュータシステムには、前記取引範囲情報に基づいて、前記販売店に対して取引範囲外にある料飲店が当該販売店と前記取引関係のある料飲店として前記帳合データに記録されないように前記帳合データ設定手段による前記帳合データの設定を制限する取引制限手段がさらに設けられている請求項８に記載の商取引支援システム。
10. 前記記憶手段は、前記提供者から各販売店への商品の卸価格、及び各販売店から各料飲店への商品の小売価格を記録した価格情報をさらに記憶し、
    前記受注処理手段は前記小売価格を含めるようにして前記商品選択情報を提供し、
    前記売上処理手段は、前記小売価格に基づいて前記販売店における売上代金の処理に必要な情報を生成し、かつ前記卸価格に基づいて前記提供者の売上代金の処理に必要な情報を生成する請求項１〜９のいずれか一項に記載の商取引支援システム。
11. 前記コンピュータシステムには、前記卸価格を前記提供者の指示に基づいて設定し、設定された前記卸価格に基づいて前記小売価格を演算して設定する価格設定手段がさらに設けられている請求項１０に記載の商取引支援システム。

Images