JP7218026B1 - 販売管理装置、ユーザ装置及びプログラム - Google Patents

Abstract

【課題】商品の購入者の商品購入のための費用を抑えつつ、かつ商品販売側での、商品販売のための作業を効率化することを目的とする。
【解決手段】商品の販売単位数よりも少ない注文数での購入希望を、購入希望者が利用するユーザ装置から取得する取得部と、購入希望者が購入を希望する注文数の合計が販売単位数に達した場合に、支払要求を購入希望者のユーザ装置に送信する決済管理部と、支払いが完了した販売単位数の商品を、購入希望者により指定された１つの配送先へ配送する旨の、商品の発注先への発注票を、出力部から出力させる発注管理部と、を備える。
【選択図】図１

Description

本発明は、販売管理装置、ユーザ装置及びプログラムに関する。

従来、商品の購入数が多くなるほど、より安い単価で商品を購入できる仕組みが知られている。特許文献１には、利用者が商品の購入を希望する単価を指定し、指定された単価で購入するために必要な総購入数の申し込みがなされた場合に、取引が成立する仕組みが開示されている。この仕組みにおいては、利用者が指定した単価に応じて、当該単価で購入するために必要な総購入数が異なる。具体的には、単価が安い程、総購入数が多くなっている。

特開２００２－７７５８号公報

しかしながら、従来技術においては、商品の総購入数が多くとも、複数の購入者それぞれに対して商品を配送する必要があり、利用者は送料を負担する必要があるという問題があった。

本発明は、このような問題点に鑑みなされたもので、商品の購入者の商品購入のための費用を抑えつつ、かつ商品販売側での、商品販売のための作業を効率化することを目的とする。

本発明は、販売管理装置であって、商品の販売単位数よりも少ない注文数での購入希望を、購入希望者が利用するユーザ装置から取得する取得部と、前記購入希望者が購入を希望する前記注文数の合計が前記販売単位数に達した場合に、支払要求を前記購入希望者の前記ユーザ装置に送信する決済管理部と、支払いが完了した前記販売単位数の前記商品を、前記購入希望者により指定された１つの配送先へ配送する旨の、前記商品の発注先への発注票を、出力部から出力させる発注管理部とを備える。

本発明の他の形態は、ユーザ装置であって、商品の販売単位数での販売を管理する販売管理システムから、前記商品と、複数の購入希望者をメンバーとする購入希望グループの識別情報と、前記購入希望グループに対して定められた、前記商品の配送先と、を受信する通信処理部と、前記商品と、前記購入希望グループと、前記配送先と、を対応付けて、表示部に表示させる表示処理部とを備える。

本発明の他の形態は、プログラムであって、コンピュータを、商品の販売単位数よりも少ない注文数での購入希望を、購入希望者が利用するユーザ装置から取得する取得部、前記購入希望者が購入を希望する前記注文数の合計が前記販売単位数に達した場合に、支払要求を前記購入希望者の前記ユーザ装置に送信する決済管理部、及び支払いが完了した前記販売単位数の前記商品を、前記購入希望者により指定された１つの配送先へ配送する旨の、前記商品の発注先への発注票を、出力部から出力させる発注管理部として機能させるためのプログラムである。

本発明の他の形態は、プログラムであって、コンピュータを、商品の販売単位数での販売を管理する販売管理システムから、前記商品と、複数の購入希望者をメンバーとする購入希望グループの識別情報と、前記購入希望グループに対して定められた、前記商品の配送先と、を受信する通信処理部、及び前記商品と、前記購入希望グループと、前記配送先と、を対応付けて、表示部に表示させる表示処理部として機能させるためのプログラムである。

本発明によれば、商品の購入者の商品購入のための費用を抑えつつ、かつ商品販売側での、商品販売のための作業を効率化することができる。

販売管理システムの全体構成図である。 商品販売の流れを説明するための図である。 商品ＤＢのデータ構成例を示す図である。 発注先ＤＢのデータ構成例を示す図である。 ユーザＤＢのデータ構成例を示す図である。 グループＤＢのデータ構成例を示す図である。 購入管理処理を示すフローチャートである。 購入管理処理を示すフローチャートである。 商品紹介画面の一例を示す図である。 グループ紹介画面の一例を示す図である。 配送管理処理を示すフローチャートである。 発注票の一例を示す図である。

図１は、本実施形態に係る販売管理システム１の全体構成図である。販売管理システム１は、販売管理装置１０と、ユーザ装置２０と、問屋装置３０と、メーカー装置４０と、を備えている。販売管理装置１０、ユーザ装置２０及び問屋装置３０は、ネットワーク５０を介して接続している。

販売管理装置１０は、複数のメーカーが提供する商品の販売を管理するサーバ装置である。販売管理装置１０は、例えば１梱などまとまった単位の商品を、複数のユーザで購入し、各自が希望数の商品シェアするシェアリング購入の仕組みにおける、商品販売を管理する。ユーザ装置２０は、商品の購入希望者が利用する情報処理装置である。ユーザ装置２０は、ＰＣの他、スマートフォン、タブレット端末等、携帯型の情報処理装置であってもよい。販売管理システム１は、複数のユーザそれぞれが利用する複数のユーザ装置２０を備える。問屋装置３０は、問屋の授業員等が利用する情報処理装置である。販売管理システム１は、複数の問屋それぞれに設置された複数の問屋装置３０を備える。メーカー装置４０は、メーカーの従業員などが利用する情報処理装置である。販売管理システム１は、複数のメーカーそれぞれに設置された複数のメーカー装置４０を備える。なお、販売管理システム１が備える問屋装置３０及びメーカー装置４０の数は、いずれも少なくとも１つであればよい。

図２は、販売管理システム１を用いた商品販売の流れの概要を説明するための図である。ここでは、商品「新鮮スープ」を販売する場合を例に説明する。商品「新鮮スープ」は１梱の入数が１００個であり、メーカーは、５梱以上を条件に受注するものとする。

販売管理装置１０は、ユーザ装置２０を介して、複数の購入希望者（例えば、購入希望者Ｐ１、Ｐ２、Ｐ３）をメンバーとする購入希望グループＧ１により、合計１００個の商品のシェアリング購入の申し込みが行われ、これらの支払いが完了した場合に、取引成立と判断する。さらに、例えば、「新鮮スープ」は、前述の通り、５梱以上で発注が可能である。そこで、販売管理装置１０は、「新鮮スープ」１００個（１梱）の申し込みが他の購入希望グループからも行われ、申し込み総数が５になった場合に、５梱の発注票を問屋へ送信する。そして、問屋からメーカーに５梱以上の発注が行われる。メーカーでは、５梱の「新鮮スープ」が問屋へ送られる。問屋では、５梱の「新鮮スープ」を１梱単位で、各購入希望グループに対して指定された１か所の配送先へ送信する。すなわち、５梱の商品は、５か所の配送先へ送信される。購入希望グループの各メンバーは、配送先において、１梱の商品のうち、自身が注文した数の商品を受け取る。このように、本実施形態のシェアリング購入の仕組みにおいては、各購入希望グループのメンバーは、例えば、グループのリーダーとして設定されたメンバーの自宅や、その近くに位置する、宅配業者の配送センターなど、所定の場所で商品を受け取る。

このように、本実施形態においては、商品は梱単位で問屋から１か所の配送先に配送される。したがって、購入希望グループの各メンバー（購入希望者）の指定する複数の配送先に配送される場合に比べて、配送料を安くすることができる。さらに、問屋などにおいて、各メンバーの購入単位に分けて配送する作業も不要であるため、作業に係る費用を価格に反映させる必要がなく、したがって商品購入のための費用を抑えることができる。

説明を図１に戻す。販売管理装置１０は、制御部１１と、記録媒体１２と、通信部１３とを備える。制御部１１は、ＣＰＵ、ＲＯＭ、ＲＡＭ等を備え、ＣＰＵが記録媒体１２やＲＯＭに記録されたプログラムを実行する。記録媒体１２は、各種情報及び各種プログラムを記憶する。通信部１３は、外部装置と有線又は無線で通信を行うための装置である。制御部１１は、通信部１３を介してユーザ装置２０、問屋装置３０及びメーカー装置４０と通信することができる。

記録媒体１２は、商品ＤＢ１２１と、発注先ＤＢ１２２と、ユーザＤＢ１２３と、グループＤＢ１２４と、を格納している。図３は、商品ＤＢ１２１のデータ構成例を示す図である。商品ＤＢ１２１は、販売管理装置１０が販売する商品の情報を格納する。商品ＤＢ１２１のレコードは、商品ＩＤと、商品名と、発注先ＩＤと、販売単位と、販売単位数と、を含んでいる。商品ＩＤは、商品の識別情報である。商品名は、商品の名称である。発注先ＩＤは、商品の発注先（商品の提供元）のメーカーの識別情報である。販売単位は、１つの購入希望グループが購入する商品の数を１単位とする量である。商品は、販売単位を１単位として配送される。配送される商品の単位としては、梱やケース、ボールが指定され得る。例えば、図２を参照しつつ説明した「新鮮スープ」の例では、１梱が販売単位として登録され、販売単位である１梱の入数である１００個が販売単位数として登録される。

図４は、発注先ＤＢ１２２のデータ構成例を示す図である。発注先ＤＢ１２２は、商品の発注先の各メーカーの情報を格納している。発注先ＤＢ１２２のレコードは、発注先ＩＤと、発注先名と、発注単位と、を含んでいる。発注先ＩＤにより、商品ＤＢ１２１の各商品は、発注先と紐付けられている。発注先名は、発注先の名称である。発注単位は、発注先への発注が可能な単位である。例えば、「５梱以上」は、５梱以上の場合に発注が可能であり、４梱での発注は行えない（発注先において受注しない）ことを意味する。また、発注単位は、梱など、配送される商品の単位に限らず、商品の購入金額で指定される場合もある。

図５は、ユーザＤＢ１２３のデータ構成例を示す図である。ユーザＤＢ１２３は、販売管理システム１に登録されたユーザに関する情報を格納している。ユーザＤＢ１２３のレコードは、ユーザＩＤと、ユーザ情報と、シェアリング購入希望地域と、利用履歴と、優先ユーザと、排除ユーザと、を含んでいる。

ユーザＩＤは、ユーザの識別情報である。ユーザ情報は、ユーザの氏名、住所を含む。なお、ユーザ情報は、例えば、性別などこれ以外の情報を含んでもよい。シェアリング購入希望地域は、シェアリング購入において商品の受け取りを希望する地域である。なお、地域の指定方法は特に限定されるものではない。例えば、市町村単位での指定のみが可能としてもよく、またユーザの指定に応じて、市町村単位、またはそれよりも狭い単位（例えば番地等）や、それよりも広い単位（例えば、複数の市等）で指定可能としてもよい。利用履歴には、当該ユーザが、販売管理システム１におけるシェアリング購入で過去に購入した実績が記録される。実績には、購入日、購入商品、購入数、グループのメンバーなどが含まれるものとする。

優先ユーザ及び排除ユーザは、ユーザが購入希望グループに参加してシェアリング購入を行うか否かを判断する際に参照する情報である。優先ユーザには、ユーザがお気に入りとして登録したユーザのユーザＩＤが登録される。排除ユーザには、ユーザが排除すべきとして登録したユーザのユーザＩＤが登録される。ユーザは、過去のシェアリング購入において、同じ購入希望グループのメンバーについて、購入についてのやり取り等に基づいて、再度同じメンバーとシェアリング購入を行いたい、行いたくない、といった希望に応じて、適宜、優先ユーザ及び排除ユーザを設定することができる。

図６は、グループＤＢ１２４のデータ構成例を示す図である。グループＤＢ１２４は、購入希望グループに関する情報を格納する。購入希望グループが生成されると、新たに生成された購入希望グループのレコードが、グループＤＢ１２４に生成される。

グループＤＢ１２４のレコードは、グループＩＤと、商品ＩＤと、リーダーと、メンバーと、メンバー注文数と、残数と、配送先と、グループ状態と、を含んでいる。グループＩＤは、グループの識別情報である。商品ＩＤは、当該購入希望グループにおいて購入希望の商品の商品ＩＤである。リーダーには、購入希望グループのリーダーとして設定されたユーザのユーザＩＤが登録される。本実施形態においては、新たに購入希望グループを生成したユーザがリーダーとして設定されるものとする。

メンバーには、購入希望グループのメンバーのユーザＩＤが登録される。なお、リーダーもメンバーとして登録される。メンバー注文数は、メンバーによる商品の注文数である。なお、購入希望グループに複数のメンバーが属する場合には、各メンバーについてのメンバー、メンバー注文数が１つのレコードに含まれる。残数は、当該購入希望グループにおいて購入可能な商品の残りの数である。残数は、メンバー注文数の合計を商品の販売単位数から減じることで得られる。

グループ状態は、購入希望グループの、取引に関する状態を示す情報である。グループ状態としては、購入希望者募集中、購入処理中、決済処理中、発注待ち、発送待ち、終了、の６つの状態があり、グループ状態は、この順に遷移する。購入希望者募集中は、注文数の合計が販売単位数に達しておらず、さらに購入希望者を募っている状態である。購入処理中は、注文数の合計が販売単位数に達し、リーダーからの購入の指示待ちの状態である。決済処理中は、購入希望グループに参加中のすべての購入希望者（リーダー及びメンバー）による支払い待ちの状態である。発注待ちは、メーカーへの発注待ちの状態である。発送待ちは、メーカーによる商品の発送待ちの状態である。終了は、商品の配送が完了した状態である。

説明を図１に戻す。制御部１１は、機能構成として、通信処理部１１１、取得部１１２、ＤＢ管理部１１３、決済管理部１１４、発注管理部１１５及び検索管理部１１６を備える。通信処理部１１１、取得部１１２、ＤＢ管理部１１３、決済管理部１１４、発注管理部１１５及び検索管理部１１６は、ＣＰＵがプログラムを実行することにより実現される機能部である。すなわち、以下において、通信処理部１１１、取得部１１２、ＤＢ管理部１１３、決済管理部１１４、発注管理部１１５及び検索管理部１１６が実行するものとして記載する処理は、制御部１１（ＣＰＵ）が実行する処理である。

通信処理部１１１は、通信部１３を介してユーザ装置２０と情報の送受信を行う。取得部１１２は、通信処理部１１１を介して、ユーザ装置２０から商品の購入希望を取得する。ＤＢ管理部１１３は、ユーザＤＢ１２３へのレコードの登録、更新及び削除を行う。ＤＢ管理部１１３はまた、グループＤＢ１２４へのレコードの登録、更新及び削除を行う。決済管理部１１４は、商品の購入のための決済に係る処理を行う。発注管理部１１５は、商品を問屋に発注するための処理を行う。検索管理部１１６は、ユーザ装置２０による、購入希望グループの検索のための処理を行う。なお、各部の処理の詳細については後述する。

ユーザ装置２０は、制御部２１と、記録媒体２２と、通信部２３と、入力部２４と、表示部２５と、を備える。制御部２１は、ＣＰＵ、ＲＯＭ、ＲＡＭ等を備え、ＣＰＵが記録媒体２２やＲＯＭに記録されたプログラムを実行する。記録媒体２２は、各種情報及び各種プログラムを記憶する。通信部２３は、外部装置と有線又は無線で通信を行うための装置である。制御部２１は、通信部２３を介して販売管理装置１０と通信することができる。表示部２５は、各種情報を表示する表示装置である。入力部２４は、ユーザによる指示の入力を受け付けるためのユーザインタフェースである。入力部２４は、例えばマウスやキーボード等である。また、表示部２５と入力部２４は、タッチパネルとして一体に設けられてもよい。

制御部２１は、機能構成として、通信処理部２１１、受付部２１２及び表示処理部２１３を備える。通信処理部２１１、受付部２１２及び表示処理部２１３は、制御部２１のＣＰＵがプログラムを実行することにより実現される機能部である。すなわち、以下において、通信処理部２１１、受付部２１２及び表示処理部２１３が実行するものとして記載する処理は、制御部２１（ＣＰＵ）が実行する処理である。通信処理部２１１は、通信部２３を介して販売管理装置１０と情報の送受信を行う。受付部２１２は、入力部２４を介して各種情報の入力を受け付ける。表示処理部２１３は、表示部２５に各種情報を表示させる。

次に、販売管理装置１０による販売管理処理について説明する。販売管理処理は、図７及び図８に示す購入管理処理と、図１１に示す配送管理処理と、を含む。

図７及び図８は、購入管理処理を示すフローチャートである。ステップＳ１００において、販売管理装置１０の取得部１１２は、通信処理部１１１を介して、ユーザ装置２０から商品の購入希望を取得するまで待機する（ステップＳ１００でＮ）。そして、取得部１１２は、購入希望を取得すると（ステップＳ１００でＹ）、処理をステップＳ１０２へ進める。ここで、購入希望は、購入希望の商品の商品ＩＤと、注文数と、ユーザＩＤと、を含む。さらに、新たに購入希望グループを生成した上で商品を購入することを希望する場合の購入希望には、新規グループ生成要求が含まれる。既に生成されている購入希望グループでの購入を希望する場合の購入希望には、参加を希望する購入希望グループのグループＩＤが含まれる。

ユーザ装置２０においては、表示部２５に商品検索画面が表示され、商品検索画面において、購入希望の商品が選択され、注文数が入力された場合に、購入希望がユーザ装置２０から販売管理装置１０に送信される。ここで、ユーザが商品の購入を希望する場合の、ユーザ装置２０におけるユーザ操作について説明する。まず、販売管理装置１０の検索管理部１１６は、ユーザ装置２０からの指示に応じて、商品検索画面をユーザ装置２０の表示部２５に表示させる。そして、ユーザ装置２０において、購入希望の商品が選択されると、選択された商品についての商品紹介画面が表示される。

また、他の例としては、検索管理部１１６は、まず、地域を選択する地域選択画面を表示させ、ユーザ（検索者）により地域が指定された場合に、選択された地域を配送先とする購入希望グループの一覧画面を表示させてもよい。なお、地域の指定方法は特に限定されるものではない。例えば、市町村単位での指定のみが可能としてもよく、またユーザの指定に応じて、市町村単位、またはそれよりも狭い単位（例えば番地等）や、それよりも広い単位（例えば、複数の市等）で指定可能としてもよい。そして、選択された地域の一覧画面において、購入希望グループが選択されると、当該購入希望グループが購入対象とする商品の商品紹介画面が表示される。

他の例としては、検索管理部１１６は、ユーザＤＢ１２３において、ユーザ毎に設定されたシェアリング購入希望地域を配送先とする商品の購入希望グループを表示させてもよい。

さらに、上記の検索を組み合わせてもよい。例えば、検索管理部１１６は、初期状態において、シェアリング購入希望地域の購入希望グループを表示させ、さらに、地域選択画面の表示指示を受け付けた場合に、地域選択画面を表示させてもよい。また、検索管理部１１６は、地域を絞り込んだ上で、商品の絞り込みを行ってもよく、逆に、商品の絞り込みを行った上で、地域の絞り込みを行ってもよい。

図９は、商品紹介画面の一例を示す図である。商品紹介画面３００には、商品の情報と、販売単位数（グループ購入数）とが表示される。なお、販売単位数は、商品ＤＢ１２１に登録されている数である。グループで購入すべき商品の個数（販売単位数）は、メーカーが配送する際の商品の個数（梱の入数等）に応じて定まるものである。このため、ある商品は、１０個である一方で、他の商品は５０個、というように、販売単位数は、商品や商品提供元に応じて異なる。しかしながら、ユーザがこのような単位を考えてシェアリング購入を行うのは面倒である。これに対し、本実施形態においては、上述の通り、商品ＤＢ１２１において、商品毎の販売単位数が登録されており、この数が、商品紹介画面３００において、グループ購入数（グループで購入すべき数）として表示される。したがって、ユーザは、グループで購入すべき数を容易に把握することができる。

商品紹介画面３００には、さらに、この商品を対象とする購入希望グループが生成されている場合には、１又は２以上のグループボタンが表示される。図９の例では、２つの購入希望グループ（Ｇ１，Ｇ２）それぞれに対応したグループボタン３２１ａ，３２１ｂが表示されている。いずれかのグループボタン３２１ａ，３２１ｂが選択されると、対応する購入希望グループについてのグループ紹介画面が表示される。

図１０は、グループ紹介画面の一例を示す図である。グループ紹介画面４００においては、グループ情報欄４１０に購入希望グループについての情報が表示される。購入希望グループの情報には、グループＩＤ、対象商品、リーダーの氏名、リーダーのコメント、グループ購入数、現在の合計注文数、注文可能数（残数）が含まれ、これらの情報が１つの画面内において対応付けて表示される。なお、リーダーのコメントは、グループＤＢ１２４において、グループＩＤに対応付けて格納されているものとする。グループの情報には、リーダーだけでなく、他のメンバーの氏名やコメントが含まれてもよい。なお、グループＩＤは、グループ名であってもよい。また、コメントは、例えば、「Ｔ市でシェアできる人を募集しています」、「すぐに購入できる人求む！」など、リーダーが自由に記入できる。

販売管理装置１０の検索管理部１１６は、ユーザ装置２０のユーザ操作に応じて、これら購入希望グループの情報をユーザ装置２０に送信することで、これらの情報をユーザ装置２０の表示部２５に表示させる。一方で、ユーザ装置２０では、通信処理部２１１がこれらの情報を受信すると、表示処理部２１３が、これらの情報を対応付けて商品紹介画面に表示させる。

さらに、ユーザＤＢ１２３において、商品やグループを検索する検索者（ユーザ）の優先ユーザ及び排除ユーザが登録されており、いずれかのユーザが、リーダー又はメンバーとして、グループ情報欄４１０における表示対象になっているとする。この場合には、検索管理部１１６は、優先ユーザ及び排除ユーザを識別可能に表示させる。具体的には、検索管理部１１６は、例えば、優先メンバーの氏名を赤色で表示し、排除ユーザの氏名を青色で表示する。また、他の例としては、検索管理部１１６は、「購入希望グループには、優先ユーザが含まれます。」というようなテキスト情報を表示させてもよい。これにより、検索者は、購入希望グループのメンバーが誰であるかを参照して、購入希望グループに参加するか否かを決定することができる。これにより、各ユーザは、より安心して、シェアリング購入の相手を選ぶことができる。また、他の例としては、グループ情報欄４１０には、合計注文数に加えて、または合計注文数に替えて、各メンバーの氏名と、注文数が表示されてもよい。

ユーザは、いずれかの購入希望グループに参加して商品を購入したい場合には、注文数欄４１２に希望の注文数を入力し、「グループへの参加申請」と記載された参加ボタン４１４を選択する。これにより、ユーザ装置２０の受付部２１２は、購入希望の入力を受け付ける。そして、通信処理部２１１は、指定された購入希望グループへの参加要求と、当該購入希望グループのグループＩＤと、商品ＩＤと、注文数と、ユーザＩＤと、を含む購入希望を販売管理装置１０へ送信する。

なお、グループへの参加に先立ち、購入希望グループのリーダーやメンバーとメッセージ交換を行うこともできる。この場合には、メッセージ交換ボタン４１６を選択すればよい。これにより、メッセージ記入欄と送信ボタンを含むメッセージ画面が表示される。メッセージ記入欄に記入された情報は、販売管理装置１０に送信され、販売管理装置１０から、購入希望グループのメンバーのユーザ装置２０に送信される。そして、購入希望グループのメンバーにより入力された情報が、ユーザ装置２０のメッセージ画面に表示される。これにより、メッセージの送受信が可能となる。

また、新たに購入希望グループを生成し、生成した購入希望グループ（新規グループ）で商品を購入したい場合には、ユーザは、図９に示す商品紹介画面３００の「新しいグループを作成して購入する」と記載されたグループ作成ボタン３２３を選択する。なお、この場合には、ユーザはさらに、配送先及び注文数を入力する。これにより、受付部２１２は、購入希望の入力を受け付ける。そして、この場合には、通信処理部２１１は、新規グループの生成要求と、商品ＩＤと、注文数と、ユーザＩＤと、配送先と、を含む購入希望を販売管理装置１０へ送信する。

図７に戻り、ステップＳ１０２において、取得部１１２は、購入希望に新規グループの生成要求が含まれているか否かを確認する。取得部１１２は、新規グループの生成要求が含まれている場合には（ステップＳ１０２でＹ）、処理をステップＳ１０４へ進める。取得部１１２は、新規グループの生成要求が含まれていない場合には（ステップＳ１０２でＮ）、処理を図８に示すステップＳ２００へ進める。

ステップＳ１０４において、ＤＢ管理部１１３は、購入希望に含まれる新規グループ生成要求に応じて、新規グループを生成する。具体的には、ＤＢ管理部１１３は、グループＤＢ１２４に、新規に購入希望グループのレコードを生成する。そして、ＤＢ管理部１１３は、グループＩＤを新たに発行し、これを登録し、グループＩＤに対応付けて、購入希望に含まれるユーザＩＤ及び注文数を、それぞれメンバー及びメンバー注文数として登録する。ここえ、ユーザＩＤは、購入希望の送信元の購入希望者のユーザＩＤである。さらに、ＤＢ管理部１１３は、ユーザＩＤを、リーダーとして登録する。このように、新規に購入希望グループを生成したユーザが、当該購入希望グループのリーダーに設定される。そして、ＤＢ管理部１１３は、商品ＤＢ１２１に登録されている、登録商品の販売単位数からメンバー注文数を減じた値を、残数として登録する。さらに、ＤＢ管理部１１３は、購入希望に含まれる配送先を登録し、グループ状態に、初期状態である「購入希望者募集中」を設定する。このように、ＤＢ管理部１１３は、グループＩＤに対応付けて、商品ＩＤ及び注文数、配送先、リーダー（購入希望者）のユーザＩＤをグループＤＢ１２４に登録する登録部として機能する。ここで、グループＤＢ１２４が格納される記録媒体１２は、記憶部の一例である。

一方、ステップＳ２００において、ＤＢ管理部１１３は、購入希望グループへの参加要求を含む購入希望に基づいて、既存の購入希望グループ（既存グループ）の情報を更新する。具体的には、ＤＢ管理部１１３は、グループＤＢ１２４において、購入希望に示されるグループＩＤに対応付けて、購入希望に示されるユーザＩＤ及び注文数を、それぞれメンバー及びメンバー注文数として登録する。そして、メンバー注文数に応じて、残数を更新する。

次に、ステップＳ２０２において、通信処理部１１１は、既存の購入希望グループのリーダーのユーザ装置２０に対し、購入希望グループへの参加希望があった旨の参加希望通知を送信する。ここで、参加希望通知には、購入希望を送信したユーザのユーザＩＤが含まれる。リーダーのユーザ装置２０は、参加希望通知を受信すると、これを表示部２５に表示させる。これにより、リーダーは、参加希望があった旨と、そのユーザ（購入希望者）を確認することができる。ここで、リーダーは、例えば、当該ユーザとのシェアリング購入を希望しない場合には、参加を却下することができる。これにより、リーダーは、後述するように、過去に同じ購入希望グループに参加し、支払を行わなかったユーザ等の購入希望グループへの参加を拒否することができる。リーダーは、入力部２４を介して、参加希望通知に対して、参加の承認又は却下を入力する。参加の承認又は却下が入力されると、承認又は却下を示す情報が参加希望通知に対する応答として、通信処理部２１１から販売管理装置１０に送信される。

これに対応し、販売管理装置１０の通信処理部１１１は、ステップＳ２０４において、参加希望通知に対して、承認の応答を受信した場合には（ステップＳ２０４でＹ）、処理をステップＳ２０６へ進める。ステップＳ２０６において、通信処理部１１１は、購入希望を送信したユーザ装置２０に対して、承認通知を送信し、その後処理をステップＳ１０６へ進める。一方、通信処理部１１１は、ステップＳ２０４において、参加希望通知に対して、却下の応答を受信した場合には（ステップＳ２０４でＮ）、購入希望を送信したユーザ装置２０に対して、却下通知を送信し（ステップＳ２０８）、処理を終了する。

なお、却下の応答を受信した場合には、さらに、ＤＢ管理部１１３は、ステップＳ２００において、グループＤＢ１２４において、参加希望の購入希望グループのレコードに追加した、購入希望のユーザのメンバー及びメンバー注文数を削除し、残数を更新する。

なお、他の例としては、ＤＢ管理部１１３は、ステップＳ２０４において、承認通知を受信した場合に（ステップＳ２０４でＹ）、ステップＳ２００の処理を行うこととしてもよい。すなわち、ＤＢ管理部１１３は、参加希望通知を受信した時点では、グループＤＢ１２４へのメンバー、メンバー注文数の登録及び残数の更新を行わず、承認通知を受信した時点で、これらの処理を行うこととしてもよい。また、この場合には、承認通知を受信するまでに受信した参加希望通知における注文数とリーダーの注文数の合計が、販売単位数を超える場合があるが、販売単位数を超えないように、リーダーが参加希望通知の承認を行えばよい。

ステップＳ１０４の処理の後、ステップＳ１０６において、決済管理部１１４は、処理対象の購入希望グループの残数を確認する。ここで、処理対象の購入希望グループは、ステップＳ１０４において新たに生成した購入希望グループまたはステップＳ２００において更新した購入希望グループである。以下、処理対象の購入希望グループを対象購入希望グループと称する。決済管理部１１４は、残数がゼロの場合、すなわち対象購入希望グループにおける注文数の合計が、当該購入希望グループの購入対象の商品の販売単位数に達した場合には（ステップＳ１０６でＹ）、処理をステップＳ１０８へ進める。決済管理部１１４は、残数がゼロでない場合、すなわち対象購入希望グループにおける注文数の合計が、当該購入希望グループの購入対象の商品の販売単位数に達していない場合には（ステップＳ１０６でＮ）、処理をＳ１００へ進める。

ステップＳ１０８において、ＤＢ管理部１１３は、グループＤＢ１２４において、対象購入希望グループのグループ状態を「購入処理中」に設定（更新）する。このように、注文数の合計が販売単位数に達すると、注文確定となり、グループ状態は「購入処理中」に遷移する。次に、ステップＳ１１０において、決済管理部１１４は、購入希望グループのリーダーのユーザ装置２０に対し、決済依頼を送信する。

リーダーのユーザ装置２０の制御部２１は、決済依頼を受信すると、表示部２５には、購入処理の案内画面が表示される。この案内画面において、リーダーにより、購入処理へ進むためのボタンが選択されるなどにより購入指示が入力されると、通信処理部２１１は、決済依頼に対応した応答を販売管理装置１０へ送信する。

これに対し、販売管理装置１０においては、通信処理部１１１は、リーダーのユーザ装置２０から応答を受信するまで待機し（ステップＳ１１２でＮ）、応答を受信した場合に（ステップＳ１１２でＹ）、処理をステップＳ１１４へ進める。なお、通信処理部１１１は、一定期間の間に応答を受信しない場合には、注文を取り消して処理を終了することとしてもよい。また、この場合には、リーダーのユーザ装置２０に対して、一定期間が経過する前に、１回、または複数回リマインダを送信してもよい。

ステップＳ１１４において、ＤＢ管理部１１３は、対象購入希望グループのグループ状態を「決済処理中」に設定（更新）する。このように、リーダーから応答が得られると、決済処理が開始され、グループ状態は、「決済処理中」に遷移する。なお、グループ状態が「購入処理中」の間は、購入希望グループに参加中の購入希望者は、参加の取りやめ、及び、注文数の変更を行うことができるが、「決済処理中」に遷移した後は、これらを行うことはできない。

次に、ステップＳ１１６において、決済管理部１１４は、通信処理部１１１を介して、対象購入希望グループに参加中のすべての購入希望者（メンバー）のユーザ装置２０に支払い要求を送信する。具体的には、決済管理部１１４は、決済を行うための画面のＵＲＬを送信する。このように、決済管理部１１４は、注文数の合計が販売単位数に達した場合に、支払要求を送信する。なお、決済を行うための画面は、決済サービスを行う決済会社から提供されるものであり、各メンバーは、当該決済会社において、各自の負担額（請求額）の支払いを行う。各メンバーによる支払いが完了すると、決済会社の情報処理装置から、販売管理装置１０に、メンバーのユーザＩＤを含む決済完了通知が送信される。

なお、各自の負担額は、例えば、商品のメーカーからの提供価格（１個当たりの価格）と、配送料を商品の販売単位数（入数）で除した額を加算した額に、各自の注文数を乗じた額とする。このように、配送先を１か所に定めていることから、各ユーザの配送料の負担額を安価に抑えることができる。さらに、購入希望グループのメンバーにより、販売単位数をシェアリング購入することから、商品の単価を問屋がメーカーから仕入れる価格と同等に抑えることができる。なお、各自の負担額の決定方法は、これに限定されるものではなく、任意に定めることができる。

次に、ステップＳ１１８において、決済管理部１１４は、対象購入希望グループのメンバーの全員分の支払いが完了したか否かを判断する。決済管理部１１４は、通信処理部１１１がすべてのメンバーの決済完了通知を受信した場合に、全員分の支払いが完了したと判断する。決済管理部１１４は、全員分の支払いが完了した場合には（ステップＳ１１８でＹ）、処理をステップＳ１２８へ進める。決済管理部１１４は、予め設定された支払期間内に全員分の支払いが完了しない場合、すなわち、少なくとも一部のメンバー（第１購入希望者）が支払いを完了していない場合には（ステップＳ１１８でＮ）、処理をステップＳ１２０へ進める。ステップＳ１２０において、決済管理部１１４は、対象購入希望グループのリーダーのユーザ装置２０に対し、未払通知を送信する。

これにより、リーダーは、未払いのメンバーが存在していることを把握することができる。そして、リーダーは、支払いメンバーを購入希望グループから除外し、未払い分の請求額をリーダーが未払いのメンバーに代わって支払うことで、取引を成立させることができる。この場合、リーダー（第２購入希望者）は、ユーザ装置２０へのユーザ操作により、販売管理装置１０に代理支払い要求を送信する。リーダーは、ユーザ装置２０において、販売管理装置１０から、未払いメンバー分の支払いのための支払い要求を受信することで、決済会社への手続きを完了させる。

これに対し、販売管理装置１０においては、ステップＳ１２２において、決済管理部１１４は、代理支払い要求を受信し、その後、ステップＳ１２４において、決済管理部１１４は、ＤＢ管理部１１３を介して、対象購入希望グループのメンバーから未払いメンバーを除外する。具体的には、決済管理部１１４は、ＤＢ管理部１１３に、グループＤＢ１２４の、対象購入希望グループのレコードにおいて、未払いメンバーのメンバーＩＤと、メンバー注文数を削除し、削除した未払いメンバーの注文数をリーダーの注文数に加算する。このように、未払いメンバーが存在する場合に、リーダーが代わりに支払いを行うことで、取引を維持することができる。これにより、安定的な取引を行うことができる。次に、ステップＳ１２６において、決済管理部１１４は、全員分の支払いが完了していない場合には（ステップＳ１２６でＮ）、処理をＳ１２２へ進める。一方、決済管理部１１４は、全員分の支払いが完了すると（ステップＳ１２６でＹ）、処理をステップＳ１２８へ進める。上述のように、リーダーにより、未払いメンバーに対する請求分の支払いが完了すると、決済管理部１１４は、全員分の支払いが完了したと判断する。

ステップＳ１２８において、ＤＢ管理部１１３は、対象購入希望グループのグループ状態を「発注待ち」に設定（更新）する。このように、対象購入希望グループのすべてのメンバーによる支払いが完了すると、グループ状態は、「発注待ち」に遷移する。

図１１は、配送管理処理を示すフローチャートである。ステップＳ３００において、販売管理装置１０の発注管理部１１５は、所定のタイミングまで待機し（ステップＳ３００でＮ）、所定のタイミングになると（ステップＳ３００でＹ）、処理をステップＳ３０２へ進める。ここで、所定のタイミングは、例えば、毎朝９時とする。ただし、所定のタイミングは任意であり、半日毎でもよい。また、所定のタイミングは一定間隔のタイミングでなくてよく、例えば、毎週火曜と、木曜、などでもよい。

ステップＳ３０２において、発注管理部１１５は、グループＤＢ１２４と、発注先ＤＢ１２２と、を参照し、購入希望の商品が、発注先に対して定められた発注単位に達している発注先が存在するか否かを確認する。具体的には、発注管理部１１５は、グループ状態が「発注待ち」の購入希望グループを抽出する。そして、発注管理部１１５は、購入希望グループの商品の発注先毎に、販売単位を１セットとし、セットの数をカウントする。セットの数が、発注先ＤＢ１２２に示される発注単位数に達している発注先が存在しない場合には（ステップＳ３０２でＮ）、処理をステップＳ３００へ進める。発注管理部１１５は、セットの数が発注単位数に達している発注先が存在する場合には（ステップＳ３０２でＹ）、処理をステップＳ３０４へ進める。例えば、図４に示すように、ＡＢ食品は、発注単位として５梱以上が定められている。したがって、グループ状態「発注待ち」に対応する、ＡＢ食品の商品の梱の合計が５梱以上である場合には、セットの数が発注単位に達していると判断される。なお、この場合に、５梱とは、同一商品のみでの５梱でもよく、ＡＢ食品が提供する異なる種類の商品を含む５梱でもよい。

ステップＳ３０４において、発注管理部１１５は、セットの数が発注単位数に達している発注先への発注票を、ネットワーク５０を介して問屋装置３０へ送信する。発注管理部１１５は、例えば、発注票をメールに添付して送信する。本処理は、発注票を送信する通信部１３は、出力部の一例である。

図１２は、発注票の一例を示す図である。発注票５００には、購入希望グループ毎に配送Ｎｏが付与された、商品の発注内容が示されている。発注内容は、配送Ｎｏ、発注先、商品名、単価、注文数、ケース数（セット数）が含まれている。ケース数さらに、各商品の配送先が示されている。ステップＳ３０２において、発注単位数に達した発注先が複数存在する場合には、複数の発注先それぞれに対する商品の発注内容が示される。

図１１において、ステップＳ３０４の処理の後、ステップＳ３０６において、ＤＢ管理部１１３は、発注された商品に対応する購入希望グループのグループ状態を「発送待ち」に設定（更新）する。このように、購入希望グループの購入希望の商品についての発注票が出力されると、グループ状態は、「発送待ち」に遷移する。

次に、ステップＳ３０８において、通信処理部１１１は、問屋装置３０から発送連絡を受信するまで待機し（ステップＳ３０８でＮ）、発送連絡を受信すると（ステップＳ３０８でＹ）、処理をステップＳ３１０へ進める。なお、問屋では、発注票を受信すると、発注された商品を、商品提供元のメーカーに注文する。そして、メーカーから問屋宛に注文された商品が配送される。問屋にて、配送先への商品の配送処理が完了すると、ユーザ操作に応じて、問屋装置３０は、販売管理装置１０に対して、発送連絡を送信する。ステップＳ３１０において、ＤＢ管理部１１３は、発送連絡に係る商品に対応する購入希望グループのグループ状態を「終了」に設定する。以上で、配送管理処理が完了する。

なお、その後、商品は、リーダーにより指定された配送先に配達される。配送先においては、例えば、リーダーがまとめ役となって、各メンバーに対して、各メンバーの注文数の商品を分配する。なお、このとき、ユーザ装置２０には、販売管理装置１０からグループＤＢ１２４に登録されている、購入希望グループに参加する各メンバーの注文数が送信され、表示部２５に表示される。これにより、メンバーは、それぞれの注文数を確認できる。

以上のように、本実施形態の販売管理システム１においては、１つの配送先に対して、メーカーが定めた配送単位の商品を配送する。したがって、商品の購入者の商品購入のための費用を抑えつつ、かつ商品販売側での、商品販売のための作業を効率化することができる。

以上の実施形態は本発明を実施するための一例であり、他にも種々の実施形態を採用可能である。例えばある変形例を他の変形例に適用するなど、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。例えば、販売管理装置１０を構成する各部の少なくとも一部が複数の装置やシステムに分かれて存在していてもよい。また、上述の実施形態の一部の構成が省略されてもよいし、処理の順序が変動または省略されてもよい。

そうした第１の変形例について説明する。本実施形態においては、販売管理装置１０の決済管理部１１４は、購入希望グループにおける残数がゼロに達した場合に、決済依頼を購入希望グループのリーダーのみに送信した。ただし、これに替えて、決済管理部１１４は、購入希望グループに参加中の購入希望者全員に決済依頼を送信し、すべての購入希望者から応答を受信した場合にステップＳ１１４へ進めることとしてもよい。これにより、一部の購入希望者による未払いが生じるのを防ぐことができる。

第２の変形例について説明する。本実施形態においては、発注管理部１１５は、発注票を問屋の情報処理装置に送信するものとしたが、これに替えて、発注管理部１１５は、発注票を、出力部としてのプリンタから紙媒体に印刷（出力）させてもよい。そして、販売管理装置１０の管理者等のユーザが紙媒体に印刷された発注票を問屋に郵送してもよい。これにより、問屋の希望に応じた方法で発注票を送ることができる。

第３の変形例としては、各ユーザに対して、安心して取引ができる人物であるかどうかを評価する安心度数を割り当ててもよい。そして、購入希望グループのリーダーやメンバーを表示する際に、リーダーやメンバーに対応付けて、安心度数を表示してもよい。

安心度数は、例えば、過去に参加した購入希望グループの成約（取引完了まで進んだ）率や成約数、購入希望グループに参加した後でのキャンセル数、決済処理中になってから決済日までの期間の長さ、に応じて決定される。安心度数はまた、当該ユーザに対するクレームや問題の発生頻度に応じて決定される。さらに安心度数は、当該ユーザが、購入希望グループのリーダーを担当した回数、リーダーとして、他のメンバーの参加希望通知に対する承認又は却下を判断するまでの期間の長さ等に応じて決定されてもよい。

第４の変形例としては、検索管理部１１６は、実施形態において説明したパラメータ以外のパラメータでの、購入希望グループの検索結果をユーザ装置２０に表示させてもよい。例えば、検索管理部１１６は、リーダーの過去の成約率、商品の仮引き受けが可能か否か、安心度数、等をパラメータとした検索結果を表示させてもよい。なお、この場合には、グループＤＢ１２４には、成約率がグループ毎に登録され、ユーザＤＢ１２３には、各ユーザの安心度数、荷物の仮引き受け可否がユーザ毎に登録されているものとする。

第５の変形例としては、検索管理部１１６は、複数のグループを一覧表示させる場合において、優先ユーザが含まれる購入希望グループを、優先ユーザが含まれない購入希望グループよりも優先的に表示させてもよい。具体的には、検索管理部１１６は、優先ユーザが含まれる購入希望グループを、優先ユーザが含まれない購入希望グループよりも上部に表示させる。また、他の例としては、検索管理部１１６は、優先ユーザが含まれる購入希望グループを赤色で表示させ、それ以外の購入希望グループを黒色で表示させてもよい。

第６の変形例としては、発注単位の商品を販売単位に分けて、各配送先に配送する配送作業を行う施設は問屋に限定されるものではない。他の例としては、メーカーから問屋を介して販売管理装置１０を備える施設に、発注単位の商品が配送され、当該施設において商品の配送作業が行われてもよい。また、他の例としては、メーカーから問屋とは別の事業者が運営する倉庫に発注単位の商品が配送され、当該倉庫において商品の配送作業が行われてもよい。なお、これらの場合には、販売管理装置１０から施設や倉庫に発注票が送られるものとする。これにより、施設や倉庫において、配送先を確認することができる。また、他の例としては、問屋が商品を保有している場合には、メーカーへの発注が行われずに、問屋において、保有する商品の配送作業が行われてもよい。

第７の変形例としては、発注票の送信先は、問屋装置ではなく、メーカー装置であってもよい。すなわち、問屋を介さずに、商品の発注が行われてもよい。この場合には、商品を配送先に送信する作業は、所定の業者の倉庫等で行われるようにしてもよい。倉庫等で購入希望グループの配送先への商品の配送作業が行われ、倉庫等を管理する業者の情報処理装置から販売管理装置１０へ配送連絡が送信される。

さらに、本発明は、プログラムや方法としても適用可能である。また、以上のようなシステム、プログラム、方法は、単独の装置として実現される場合もあれば、共有の部品を利用して実現される場合もあり、各種の態様を含むものである。例えば、以上のようなシステムで実現される方法、プログラムを提供することが可能である。また、一部がソフトウェアであり一部がハードウェアであったりするなど、適宜、変更可能である。さらに、装置を制御するプログラムの記録媒体としても発明は成立する。むろん、そのソフトウェアの記録媒体は、磁気記録媒体であってもよいし半導体メモリであってもよいし、今後開発されるいかなる記録媒体においても全く同様に考えることができる。

１ 販売管理システム
１０ 販売管理装置
１１ 制御部
１２ 記録媒体
１３ 通信部
２０ ユーザ装置
２１ 制御部
２２ 記録媒体
２３ 通信部
３０ 問屋装置
４０ メーカー装置
５０ ネットワーク
１１１ 通信処理部
１１２ 取得部
１１３ ＤＢ管理部
１１４ 決済管理部
１１５ 発注管理部
１１６ 検索管理部
１２１ 商品ＤＢ
１２２ 発注先ＤＢ
１２３ ユーザＤＢ
１２４ グループＤＢ

Claims (9)

1. 商品の提供元から配送される商品の単位の数である販売単位数よりも少ない注文数での前記商品の購入希望を、複数の購入希望者それぞれが利用する複数のユーザ装置から取得する取得部と、
   前記複数の購入希望者それぞれが購入を希望する前記注文数の合計が前記販売単位数に達した場合に、支払要求を前記複数の購入希望者それぞれのユーザ装置に送信する決済管理部と、
   支払いが完了した前記販売単位数の前記商品を、前記複数の購入希望者のうち一の購入希望者により指定された１つの配送先へ配送する旨の、前記商品の発注先への発注票を、出力部から出力させる発注管理部と、
   を備え、
   前記発注管理部は、
   前記販売単位数の商品の支払いが完了した前記販売単位数の商品のセットで、かつ前記発注先が同一の前記セットの数をカウントし、
   前記セットの数が、前記発注先が受注可能な単位の数として、前記発注先毎に予め定められた発注単位数に達した場合に、前記発注単位数の商品についての前記発注票を出力部から出力させる、販売管理装置。
2. 前記販売単位数の前記商品を購入する、前記複数の購入希望者をメンバーとする購入希望グループの生成要求と、購入希望の前記商品及び前記注文数と、前記配送先と、を前記一の購入希望者のユーザ装置から受信した場合に、前記購入希望グループを生成し、前記購入希望グループの識別情報に対応付けて、前記商品及び前記注文数と、前記配送先と、前記生成要求の送信元の購入希望者の識別情報と、を記憶部に登録する登録部と、
   前記記憶部に登録された前記購入希望グループと、前記購入希望グループにおける購入希望の前記商品と、前記配送先と、を対応付けて、前記購入希望グループを検索する検索者のユーザ装置に表示させる検索管理部と
   を備える、請求項１に記載の販売管理装置。
3. 前記検索管理部は、さらに、前記購入希望グループに参加中の購入希望者による前記注文数の合計、及び、前記販売単位数までの残数、の少なくとも一方を、前記商品に対応付けて表示させる、請求項２に記載の販売管理装置。
4. 前記登録部は、前記記憶部に登録されている前記購入希望グループへの参加要求と、前記購入希望グループにおける前記注文数と、を、前記ユーザ装置から受信した場合に、前記購入希望グループの識別情報に対応付けて、前記注文数と、前記参加要求の送信元の購入希望者の識別情報と、を登録する、請求項２に記載の販売管理装置。
5. 前記決済管理部は、前記販売単位数の商品の料金のうち、前記購入希望グループに参加中の各購入希望者の負担額についての前記支払要求を、各購入希望者のユーザ装置に送信し、
   前記発注管理部は、前記購入希望グループに参加中の第１購入希望者からの支払いが完了せず、かつ前記購入希望グループの前記生成要求の送信元の第２購入希望者により前記第１購入希望者への請求分の支払いが完了した場合には、当該購入希望グループによる支払いが完了したと判断する、請求項２に記載の販売管理装置。
6. 前記検索管理部は、前記検索者により指定された地域を前記配送先とする前記購入希望グループを前記検索者の前記ユーザ装置に表示させる対象とする、請求項２に記載の販売管理装置。
7. 前記検索管理部は、前記購入希望グループに、優先的に選択すべきとして登録された優先ユーザ及び排除すべきとして登録された排除ユーザの少なくとも一方が含まれる場合に、前記少なくとも一方が含まれることを識別可能に、前記購入希望グループを表示させる、請求項２に記載の販売管理装置。
8. 前記検索管理部は、優先的に選択すべきとして登録された優先ユーザが含まれる前記購入希望グループを、前記優先ユーザが含まれない前記購入希望グループよりも優先的に表示させる、請求項２に記載の販売管理装置。
9. コンピュータを、
   商品の提供元から配送される商品の単位の数である販売単位数よりも少ない注文数での前記商品の購入希望を、複数の購入希望者それぞれが利用する複数のユーザ装置から取得する取得部、
   前記複数の購入希望者それぞれが購入を希望する前記注文数の合計が前記販売単位数に達した場合に、支払要求を前記複数の購入希望者それぞれの記ユーザ装置に送信する決済管理部、及び
   支払いが完了した前記販売単位数の前記商品を、前記複数の購入希望者のうち一の購入希望者により指定された１つの配送先へ配送する旨の、前記商品の発注先への発注票を、出力部から出力させる発注管理部として機能させるためのプログラムで、
   前記発注管理部は、
   前記販売単位数の商品の支払いが完了した前記販売単位数の商品のセットで、かつ前記発注先が同一の前記セットの数をカウントし、
   前記セットの数が、前記発注先が受注可能な単位の数として、前記発注先毎に予め定められた発注単位数に達した場合に、前記発注単位数の商品についての前記発注票を出力部から出力させる、プログラム。

Images