JP3941358B2 - 受発注システム、記憶媒体、及び流通支援システム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、受発注システムに係り、特に、所属ユーザ数の多い顧客とその顧客のユーザへ商品やサービス等の品目を提供する販売店（顧客フロント）との間の受発注を制御する受発注システムに関する。
【０００２】
【従来の技術】
従来より、文具・工具などの消耗品（MRO: Maintenance, Repair and Operationsとも呼ばれる）や家具類などは企業等の組織で多種大量に消耗されている。これらの消耗品は、組織の事業運営に必要なものであり、その購入は予算や会計との関係で管理されている。消耗品や工具・家具類などは、事業活動や生産活動に間接的に必要となるものであるから、間接財や副資材とも呼ばれる。
【０００３】
間接材の購買は少額で多頻度且つ多種膨大であり、購買先や購買条件も品目や地域ごとに異なっている場合が多く、その購買管理が煩雑である。従来より、従業員が数百人に及ぶ大規模な組織では、一定期間で行われた見積合わせなどによって、販売店（顧客フロント）と顧客（企業などの組織）との間で取扱商品及び価格を定めておき、その取り決めに従った購買活動を行うことで、購買管理を簡略化することが図られている。
【０００４】
一方、近年、インターネットを介して商品やサービスの注文及び販売が行われている。これは、商品の提供者がＷｅｂサイトを構築し、商品の購入希望者が種々のＷｅｂサイトを電子的に訪問しつつ購入する商品を選択するものである。Ｗｅｂサイトを用いて提供されている商品やサービスには、書籍や、食料品や、自動車や、文房具や、コンピュータや、輸送サービスや、生花等のギフトサービスなどがある。このようなＷｅｂサイトを用いた商品及びサービスの提供は、現実の世界でのショッピングモールや、商店街と近似している。すなわち、購入者は、購入すべき商品を取り扱っているＷｅｂサイトを探索し、続いて、そのＷｅｂサイトに対して発注を行う。そして、クレジットカードや銀行振込等を用いて商品又はサービスの決済を行う。多くの場合、商品等は購入者の所在地へ直送される。また、生花のギフトサービスや、ギフトなどの場合には、ギフトの受取人へ直送する例が多い。
【０００５】
また、インターネットを活用した商用のプラットフォームも徐々に実現しつつある。これは、事業活動や生産活動に直接使用する資材（直接財）の調達（資材調達）を主として開発されている。多くのプラットフォームでは、価格条件等に応じた資材及びその発注先の選択作業を支援する。
【０００６】
【発明が解決しようとする課題】
しかしながら、上記顧客と販売店とで予め取り決められた取扱品目及び価格での購買活動では、取り決められた条件に基づいた発注を行うために一又は複数の販売店毎に取り決めた条件を参照しながら、その販売店へ発注を行わなければならず、発注及び申請業務に一定の知識が必要となり、このため、その品目の入手を希望するユーザ本人が発注処理を行うことが難しい、という不都合があった。この場合、ユーザ本人の依頼に応じて発注を担当する間接業務が必要となり、膨大な人的コストを生じさせている。特に、少額で多種類の場合には、組織の総購買額よりも、その購買に必要な管理費の方が多い場合もある。また、組織内のユーザ本人による発注を行うためには、契約発注先（販売店）を組織内のユーザ本人が知る必要があり、これによっても、人的コストが増加してしまう。
また、予算管理や、品目の購入の承認や、品目の購入に関連する会計管理などの購買活動の管理については、組織内にて購買条件や購買方法を統一しておくと、承認や会計に関する人的コストの削減を図ることができる。しかし、間接材の購買は多頻度で且つ多種膨大であることから、手書き伝票で処理される膨大な購買内容が誤りなく組織内の購買規定や販売店との取り決めに従っているか否かのチェックは、実質的に不可能であった。
【０００７】
すなわち、手書き伝票による購買活動では、統一された購買条件や購買方法を徹底することが実質的に不可能で、購買方法の統一を維持しようとするために多大な人的コストを要してしまい、一方、会計管理等の購買活動の管理についても、統一的な購買活動が困難であることから、人的コストの削減が難しくなっている。特に、多数の販売店と取引がある場合に、この傾向が顕著となる。
このように、間接材及び副資材の購買活動及び管理については、事業活動及び生産活動に対して間接的な業務であるため、低コストで実施すべきであるが、従来例では、組織内での多大な人的コストを要している、という不都合があった。これは、間接材等の購買や、その会計処理は、間接的な業務ではありながら、各種の税の納付のために必要な書類や、会計報告で必要な書類は必ず作成しなければならないため、企業にとって必須の活動であり、この必須の活動である点が、間接材の購買に関する「見えないコスト」削減をより一層困難にしている。すなわち、間接材の購買及びその会計処理等を一切廃止することはできず、従って、いかにしてコストを削減するかについての検討が必要となる。
【０００８】
また、商用プラットフォームや、Ｗｅｂサイトでの品目の販売を利用する場合には、必要な品目を提供する販売店を探索しなければならない。また、単に品目を必要とするユーザであっても、その品目をいくらで購入するかという問題を解決しなければならなくなるため、各ユーザが所属組織の購買条件や購買方法を熟知しなければならなくなってしまう。すなわち、組織内の人的コストの削減という点からは、品目を提供する販売店の探索や、価格の比較や、組織内の購買条件等の学習についても、コストであると考えられる。
従来より、組織が多数の販売店と取引を行っている場合に、この購買に関する人的コストは多大となる。
【０００９】
【発明の目的】
本発明は、係る従来例の有する不都合を改善し、特に、間接財の購買を低コストで実行及び管理することのできる受発注システムを提供することを、その目的とする。
【００１０】
【課題を解決するための手段】
本発明に係る構成は、販売店等の顧客フロントから顧客へ提供される商品又はサービス等の品目に関する情報を当該品目を識別する品番を単位として登録した商品マスタと、顧客フロント運営単位ＩＤにより運営単位が示される顧客フロントが顧客運営単位ＩＤにより示される顧客の購買単位に対して提案し顧客によって選定された品揃えを示す品揃え単位ＩＤ、前記顧客運営単位ＩＤ、前記顧客フロント運営単位ＩＤ、品番、商品又はサービスを前記ユーザに提供又は配送するデリバを示すデリバ運営単位ＩＤ、及び商品又はサービスをユーザに提供するサプライヤを示すサプライヤ運営単位ＩＤを対応付けて記憶している品揃え関連マスタとを記憶したデータベースと、ネットワークを介して所定の端末と接続され当該端末とのデータ送受信を制御すると共に前記端末からの要求に応じて前記各種マスタに対するデータの抽出又は登録をするサーバとを備え、前記品揃え関連マスタが、前記顧客の購買単位にて購入する品番が顧客フロント運営単位ＩＤで示される顧客フロント毎に重複しない状態で登録されたものであって、前記サーバが、前記購買単位に属するユーザによって使用される端末から一又は複数の品目を発注するための発注要求を受信したときに受信した顧客運営単位ＩＤ及び品番をキーとして前記品揃え関連マスタを参照することにより該顧客運営単位ＩＤ及び品番に対応する品揃え単位ＩＤを特定し、特定された品揃え単位ＩＤ及び受信した品番をキーとして前記品揃え関連マスタを参照することにより当該発注要求の各品番に対応する品目を提供する顧客フロントを顧客運営単位ＩＤで識別される顧客運営単位に所属するユーザへ品目の提供を契約した一又は複数の顧客フロントすなわち顧客フロント群のうちから唯一に特定する品目発注制御部と、受信した顧客運営単位ＩＤをキーとして前記品揃え関連マスタを参照することにより該購買単位に対応する品揃え単位ＩＤを特定し、特定された品揃え単位ＩＤ及び各品番に対応付けられたデリバ運営単位ＩＤ及びサプライヤ運営単位ＩＤを前記品揃え関連マスタ中から検索することによりデリバ及びサプライヤを特定するサプライヤ／デリバ特定部とを備えた、というものである。これにより前述した目的を達成しようとするものである。
【００１１】
本発明では、まず、顧客（例えば、企業）と、この顧客に商品やサービス等の品目を提供する顧客フロントとの間の受発注を制御する。そして、顧客は、商品の種類や顧客のユーザ所在地に応じて、複数の顧客フロントと取引を行う。取扱品目としては、種々の商品又は種々のサービスが該当する。好ましい実施形態では、取引を行う顧客フロントが特定されており、且つ、提供価格を発注時に自動的に特定でき、そして、顧客として同一品目に関して複数の顧客フロントの選択作業を行わないと定めている品目が該当する。例えば、消耗品や、家具や、生花配送サービスや、印鑑の作成サービスや、チケットの購入や、書籍などのうち、購入時に価格に関する交渉や条件に応じた顧客フロントの選択を行わない商品又はサービスが該当する。例えば、購入時に選別や選定やオークションを行わない非選定品目や、定期的に更新される購買契約に基づく購入条件設定済品目などを中心に取り扱うようにすると良い。
本発明では、顧客（実際には、その顧客の購買単位に属するユーザ）と取引する複数の顧客フロントを予め特定する。そして、各顧客フロント毎に、取扱品目を定めておく。一方、複数のサプライヤから提供され、顧客フロントによって取り扱われる品目の仕様や所属カテゴリー等は、１つの商品マスタで管理する。このため、本発明では、顧客フロントと顧客のユーザ群（購買単位）の組み合わせ毎に、品揃え関連情報を生成する。そして、この品揃え関連情報を用いることで、顧客に所属するユーザは、どの顧客フロントに発注するのかを意識することなく、個々の品目を発注することができ、さらに、必要な品目を一括して選択し、複数の顧客フロントへの発注を一度の発注手続で発注することができる。
【００１２】
具体的には、本発明では、データベースに、商品マスタに登録された品目のうち顧客の購買単位毎で且つ当該顧客へ品目を提供する顧客フロント毎に予め取り決められた取扱品目の一覧である品揃え関連情報を登録した品揃え関連マスタを格納する。顧客の購買単位（ユーザ群）は、例えば事業部や部署などの組織単位でも良いし、また、同一地区に所在するユーザ群でも良いし、さらに、各ユーザ別であっても良い。好ましい実施例では、ユーザＩＤが特定されると、品揃え関連情報群が特定され、さらに発注しようとする品目が特定され品番が定まると、唯一の品揃え関連情報が特定される。
品別発注制御部は、購買単位に属するユーザによって使用される端末から一又は複数の品目を発注するための発注要求を受信したときに、当該ユーザが属する購買単位毎（ユーザ又はユーザ群）の品揃え関連情報に基づいて当該発注要求の各品目を提供する顧客フロントを特定する。すなわち、本発明では、商品マスタに登録された全ての品目を顧客に提供するのではなく、顧客フロントと顧客との間で予め定められた取扱品目のみを顧客に提供する。この顧客フロントと顧客の関係を、品揃え関連情報で管理する。この品揃え関連情報は、顧客の購買単位と、顧客フロントの組み合わせ毎に定義される。例えば、購買単位（１）と取引を行う顧客フロントが三社ある場合には、この購買単位と関連する品揃え関連情報は３つである。
顧客フロントが特定されると、このユーザと顧客フロントとの組み合わせによるデリバの指定や、顧客から顧客フロントへの提供価格等を唯一に特定することができる。これにより、異なる顧客フロントが取り扱う複数種類の品目から同一の発注手続きで必要な品目を選択して発注することができ、さらには、種々の分野の複数種類の品目を一括して選択し、発注処理することが可能となる。
従って、例えば、手書き伝票で発注する場合には組織内の事務効率から組織に所属するユーザの直接の発注を行わずに、購買管理部門にて発注処理を行っていることと比較して、本発明によると、複数の顧客フロントから提供され、予め購買管理部門によって価格等が設定された多種類の品目の発注を、ユーザが直接作業することができる。しかも、ユーザ側からは、品目を特定するのみで顧客フロントが特定され、発注を行うことができる。品揃え関連情報に、提供価格や、配送方式などを設定しておく実施例では、発注に応じて、さらに他の処理を自動化することができる。この品揃え関連情報を用いて品目に応じて複数の顧客フロントへ自動的に発注する仕組みにより、顧客の購買に関連する総費用をより少なくすることができる。
本発明では、受発注管理システムの内部の商品データと、他の提携したサプライヤ等の外部サーバにて管理される商品データとに品目識別用の品番を付する。外部サーバ（他サイト）で管理される商品データに関しては、その他サイトでの品番を用いるようにしても良い。商品マスタには、商品又はサービスの仕様や、説明のための画像ファイルの格納位置や、サプライヤ名等の品目自体の属性情報を格納し、一方、品揃え関連情報には、顧客フロントと顧客との間で締結される契約等に従って、各品目の流通に関する属性情報を格納すると良い。例えば、顧客と顧客フロント間で受発注を行う取扱品目の一覧や、各品目のデリバや、顧客への提供価格又は提供価格の算出方式や、その品目のサプライヤなどは、品揃え関連情報に格納される。
【００１３】
この商品マスタと品揃え関連マスタとの使い分けにより、品目自体の属性に変更があった場合には１つの商品マスタを更新するのみで全ての取引に変更が反映される。一方、品揃え関連情報を顧客フロントと顧客の購買単位との組み合わせ毎に生成することで、顧客から複数の顧客フロントへの柔軟な発注を制御することができる。
【００１４】
さらに、本発明の構成では、発注用に選択した品番と当該品目を受注する顧客フロントとの関係に基づいて、自動的にサプライヤ及びデリバを特定する。品番とサプライヤとは一対一で対応する。同一の商品であっても、サプライヤが異なる場合には異なる品番とする。顧客フロント自身が封筒の印刷サービス等を行う場合には、顧客フロント自身がサプライヤとなる。また、商品に関しても、顧客フロントが自ら在庫を有し、自ら配送する場合にも、顧客フロントがサプライヤとなる。そして、在庫を有すべき主体をサプライヤとし、この前提でシステム化する例では、商品はサプライヤから顧客へ、顧客フロントの名義で直送される。顧客フロントと品番とが定まると、顧客フロントとサプライヤとデリバとが定まる。さらに、顧客と品番とが定まると、顧客フロントを唯一のものとして特定する。すなわち、同一の商品又はサービスについては、唯一の顧客フロントと定期購買契約を締結する。そして、好ましい実施形態では、顧客フロントとサプライヤとが定まると、卸等の中間商流プレイヤを唯一のものとして特定することとした。これにより、個別の発注時に商流を特定するための人の判断が不要となる。この中間商流プレイヤを特定する実施例では、各プレイヤ間での仕入及び売上の管理機能を提供することができる。顧客と顧客フロントと品目との関係は、予め定められた契約による。
【００１５】
【発明の実施の形態】
次に、本発明の一実施形態を図面を参照して説明する。図１は、本発明の一実施形態の構成を示すブロック図である。本実施例による受発注システムは、各種マスタを記憶したデータベース（ＤＢ）９と、インターネット等のネットワーク２を介して所定の端末１と接続されたサーバ１０とを備えている。サーバ１０は、端末１とのデータ送受信を制御すると共に端末からの要求に応じて各種マスタに対するデータの抽出又は登録をする。ネットワークをインターネットとする場合には、サーバ１０は、ｈｔｔｐプロトコルに従って端末のブラウザと通信するＷｅｂサーバと、このＷｅｂサーバからの要求に応じてデータベースを駆動するデータベースサーバとを備えると良い。本実施形態による構成では、複数の顧客（顧客運営単位）と複数の顧客フロントとの間の受発注を単一のサーバにて実行することができる。顧客フロントは、例えば文具消耗品の販売店や、オフィス家具の販売店や、理化学機器の販売店である。顧客としては、例えば購買に関する決定を行う総務部と、事業に従事する事業部等を有し、ユーザ数が一定規模以上の会社等の組織を想定している。
【００１６】
図１に示す例では、データベース９が、販売店等の顧客フロントから顧客へ提供される商品又はサービス等の品目に関する情報を当該品目を識別する品番を単位として登録した商品マスタ３と、この商品マスタに登録された品目のうち顧客の購買単位毎で且つ当該顧客へ品目を提供する顧客フロント毎に予め取り決められた当該顧客と顧客フロント間で受発注する取扱品目の一覧である品揃え関連情報を登録した品揃え関連マスタ４とを備えている。受発注する品目は、間接財や副資材等の商品や、各種のサービスである。受発注する品目というとき、顧客（顧客の購買単位に属するユーザ）が顧客フロントへ発注を行い、顧客フロントが顧客から受注する品目という意味である。予め取り決められた品目は、一般的には、顧客の購買管理担当者と顧客フロントとの商談に応じて定められる。
商品マスタ３は、受発注システム内部で管理する商品データのみならず、提携したサプライヤ等のＷｅｂサイトにて管理される商品データに関する情報を登録するようにしても良い。また、より好ましくは、他サイトにて管理される品目に関する情報は発注がある毎に連携処理により取得するとよい。本実施形態では、説明を容易とするために顧客フロントが取り扱う商品は全て商品マスタ３に登録されているものとする。また、顧客と顧客フロントとの間の面談で、商品マスタに登録されていない品目を扱う場合には、品揃えを作成する前に、まず商品マスタに新たな品目を登録する。本実施形態では、複数の顧客フロントが同一の商品を取り扱う場合であっても、その商品の説明画像やサプライヤに関する情報等は、単一の商品マスタ３で管理する。このため、顧客フロントは、個別の品目自体に関する情報の登録やメンテナンスを行う必要がない。
【００１７】
そして、サーバ１０は、購買単位に属するユーザによって使用される端末から一又は複数の品目を発注するための発注要求を受信したときに当該ユーザが属する購買単位毎の品揃え関連情報に基づいて当該発注要求の各品目を提供する顧客フロントを特定する品目発注制御部１４を備えている。購買単位は、例えば部門や、所在地や、そのユーザが有する権限などに応じてほぼ同一の条件で同一の顧客フロントから購買を行うユーザ群である。顧客の購買態様によっては、購買単位を各ユーザ別とする場合や、所在地別の部門群ごととなる場合などがある。
【００１８】
図２に示すように、顧客のユーザ群（購買単位）と、顧客フロントとは、品揃え関連情報で結びつけられている。そして、品揃え関連情報での品揃えに含まれる品目は、商品マスタ３に登録されている品目である。商品マスタと、ユーザ群及び顧客フロント別に登録する品揃え関連情報とを用いることで、各品目に関する情報の登録及び更新は商品マスタにて一度のみ行うこととした。図２に示す例では、顧客フロント（０１）は、顧客（０１）に対して、ユーザ群別に２つの品揃え関連情報（０１，０２）を有している。顧客フロント（０２）は、顧客（０１）に対して、一つの品揃え関連情報（０３）を有している。
【００１９】
顧客（０１）のユーザ群（０１）は、顧客フロント（０１）の品揃え関連情報（０１）で品揃えされている品目と、顧客フロント（０２）の品揃え関連情報（０３）で品揃えされている品目とについて受発注システムによる購入を行うことができる。同一のユーザ群（０１）に対する２つの品揃え関連情報（０１，０３）にて、同一品目が重複しないように品揃え関連情報を定義すると良い。同一ユーザ群に対する複数の品揃えにて品目の重複が存在しないと、ユーザが品目を特定したときにその品目を品揃えしている顧客フロントを唯一に特定できる。本実施形態では、このユーザ群と品目とが特定されたときに、顧客フロントを自動的に特定できる構成とすることで、品目毎の発注先や商流の切り分けを行う。このため、品揃え関連マスタ４は、顧客の購買単位にて購入する品番が顧客フロント毎に重複しない状態で登録されることが好ましい。
このように、本実施形態では、商用プラットフォームや一般的なＷｅｂサイトと異なり、価格比較や条件比較による販売店（顧客フロント）の特定を行わず、予め定められた取り決めに従って、発注時には自動的に且つ強制的に顧客フロントを特定する点に、その特徴を有する。これにより、企業等の組織の購買管理部門が予め定めた購買先や購買条件や購買方法に従って、その組織の各ユーザが手元の端末（例えば、ＨＴＭＬ等のマークアップランゲージで記述されるページを表示するブラウザソフトウエアが導入されたコンピュータ）を用いて直接に発注を行うことができる。ユーザが直接品目を発注できると、購買担当部門等での在庫量を減少させ、必要に応じて必要な分を発注することができる。そして、この購買の単価や在庫削減によるコスト低減のみならず、購買管理に必要な直接的及び間接的な人件費を削減することができる。本実施例による受発注システムを採用すると、実際には、この人件費の削減によるコスト低減が最も大きいと想定できる。例えば、ある組織の年間の消耗品の総購入額が「１００」であるとき、この「１００」を管理するための人員の人件費が「３００」であることもある。しかし、消耗品は必ず業務に必要であるから手配を行わなければならず、また、税務関連の報告や会計処理なども必須作業であるため、この「３００」のコスト（見えないコスト）の削減は容易ではなかった。
しかし、本実施形態による受発注システムを採用することで、購買管理部門の作業は数年に一度品揃えを顧客フロント毎に定めることとなり、実際の発注はユーザが直接行う。そして、好ましい実施例では、発注額や請求額等を電子的に取得することができるため、従来手書きの伝票管理と比較して、承認プロセスや会計処理に要する人員の時間を大幅に縮減することができる。これらにより、本実施形態では、見えないコストまでを削減し、低コストで必須作業である間接財の受発注を制御することができる。
【００２０】
同一のユーザ群（顧客の購買単位）について複数の顧客フロントの品揃えがある場合に、顧客フロント間で品目の重複があり、品目の発注時に複数の顧客フロントのうち一つの顧客フロントを特定しなければならない状態の場合には、所定の条件に基づいて顧客フロントを自動的に特定する構成を採用すると良い。例えば、品揃え関連マスタ４が、顧客の購買単位にて購入する品番が顧客フロント毎に重複する場合には当該品番に応じて顧客フロントを特定するための納期、価格又は顧客フロントの優先順位等の顧客フロント決定項目を有し、そして、品別発注制御部１４が、購買単位に属するユーザから発注要求を受信したときに当該発注要求された品目の品番について顧客フロントが重複している場合には当該品番の各顧客フロント別の納期、価格又は顧客フロントの優先順位等の顧客フロント決定項目に基づいて当該品番の顧客フロントを特定する顧客フロント重複時特定機能（図示せず）を備える。顧客フロント重複時特定機能は、発注要求された品番について顧客フロントが重複している場合には、予め顧客フロント間に対して顧客によって定められた優先順位に基づいて顧客フロントを特定するようにしても良いし、また、当該品番の各顧客フロント別の発注時点での納期や価格に基づいて当該品番の顧客フロントを自動的、強制的に特定するようにしても良い。この顧客フロント重複時特定機能によっても、ユーザは品目発注時に顧客フロントの取扱品目等を意識することなく品目の発注を行うことができる。すなわち、どの品目はどの顧客フロントに注文するかという組織内での運用に従った発注を維持することができる。
【００２１】
図２に示す例では、顧客フロント（０２）は、顧客（０２）との間でも取引が存在する。このとき、顧客（０１）のユーザ群（０１）に対する品揃えと、顧客（０２）のユーザ群（０３）に対する品揃えとが同一であるとしても、異なる品揃え関連情報を登録する。このような構成とすることで、顧客と顧客フロントの関係に応じて、品揃え関連情報に各品目の流通に関する情報を登録しておくことができる。例えば、品揃え関連情報（０３）と（０４）との品揃え（取扱品目の一覧）が同一であるとしても、顧客（０１）に対する提供価格と顧客（０２）に対する提供価格が異なる場合や、品目を配送するデリバが異なる場合などであっても、品揃え関連情報（０３）の品目毎に定義する流通の属性情報と、品揃え関連情報（０４）での流通の属性情報とをそれぞれ定義することで、購買、販売及び配送手配を自動化することができる。
【００２２】
複雑な流通網をシステム化するための簡略化として、各品目毎にそのデリバが顧客フロント名で顧客に配送する仕組みを採用すると良い。顧客フロントが在庫を有し、顧客へ配達する場合には、顧客フロント自身をデリバとして登録する。図１に示す例では、サーバ１０が、購買単位に属するユーザによって使用される端末から１又は複数の品目を発注するための発注要求を受信したときに購買単位毎の品揃え関連情報を参照して各品番別に商品又はサービスをユーザに提供又は配送するデリバを特定するデリバ特定制御部１８と、品別発注制御部１４によって特定された顧客フロントの名義でデリバ特定制御部１８によって特定されたデリバからユーザへ配送するための顧客フロントデータをデリバによって使用される端末１へ出力する顧客フロントデータ出力制御部２０とを備えている。
【００２３】
デリバ特定制御部は、顧客の購買単位（ユーザ群）毎の品揃え関連情報を参照して、各品番別に商品又はサービスをユーザに提供又は配送するデリバを特定する。この例では、顧客と顧客フロントの関係毎に、且つ、各品目又は品目群（商品カテゴリ）毎に当該品目を顧客に配送するデリバを予め品揃え関連情報に定義しておく。
【００２４】
また、大規模組織内では、間接財の種類や用途毎に予算の管理や承認を行っている。この予算管理や承認管理を行う例では、承認基準別発注制御部１６が予算管理等を簡略化する。承認基準には、承認を行うか否かや、予算管理や、承認を行うための承認者群での承認経路などが定義される。図１に示す品別発注制御部１４が、前記顧客毎に品目の発注に関する承認基準が定められている場合であって、一又は複数の品目が前記顧客のユーザによって特定されているときには、当該特定された品目と新たに追加される品目の承認基準が異なる場合には新たな品目の追加を受け付けずに同一承認基準別の一括した発注を促す承認基準別発注制御機能１６を備えている。
承認基準別発注制御機能１６は、例えば、ユーザの所属する予算や承認管理上の単位（予算管理単位）と、発注する品目の費目とに基づいて、承認経路や、予算権限者や、承認を必要とする上限額や、月等の一定期間での累積購入額等の承認基準関連情報を取得する。品目の費目は、会計上の勘定科目等の仕訳単位や、組織個別の支出の分類や、予算単位の識別に用いられる。
【００２５】
予算や承認は、商品又はサービスの種類やユーザの所属部署毎に管理されている。また、あるプロジェクトのための予算から、他のプロジェクトに使用する品目の購入金額を支出することはできない。従来は、必要な品目は多数の販売店（顧客フロント）毎に個別に発注し、また、各予算単位毎に発注をしていた。本実施形態では、複数の顧客フロントに対する発注を一括して行うことができる。具体的には、ユーザが必要な品目を顧客フロントにかかわらず発注用に選択し、承認プロセスへ引き渡すことができる。この場合、承認基準別発注制御機能１６により、予め品目に費目が定められ、または発注時に入力される場合に、一括して発注できる最大範囲（すなわち、購買データや請求データの単位）を同一承認基準の範囲とする。これにより、別々の予算管理単位に属する品目を一括して発注し、購入金額を分割して承認を受ける必要がなくなる一方、同一予算単位であれば、顧客フロントや商品の種別（ボールペンと電球と生花など）が異なっていても、一括して承認プロセスへ引き渡すことができる。このように、承認基準別発注制御機能１６を有する実施形態では、従来の顧客フロント毎の発注から、予算管理単位又は承認単位での一括した発注へと発注業務をシフトさせることができ、承認を取りまとめて行うことができるようになる。これによっても、予算管理や、会計管理等が容易となり、見えないコストの削減に寄与する。この例では、承認単位別に一括した発注の最大範囲を制限するため、承認を行う購買と、承認の不要な購買とを顧客の現状に応じて設定し、自動的に制御することができる。
【００２６】
図３は、図１に示した構成での受発注処理の一例を示すフローチャートである。図３に示すように、まず、ユーザによって品目の選定及び追加がなされる（ステップＳ１）。このとき、既に選定されている品目の承認基準と、今回追加されようとする品目の承認基準を比較し（ステップＳ２）、承認基準が異なる場合には一括発注への追加を不可とする（ステップＳ３）。一方、同一承認基準で有れば、両品目の顧客フロントが異なっていても、発注品目群へ追加する。品目の承認基準が異なると、承認プロセスが異なる。そして、承認基準別発注制御機能１６（ステップＳ２，Ｓ３等）が、異なる承認基準の場合異なる発注品目群とするようにユーザに促すため、承認プロセスが別経路となる品目の一括発注を防止することができる。すなわち、顧客フロント毎の発注ではなく、承認基準別の一括した発注を行うことができる。
発注品目群は、たとえばインターネットによる販売サイトで一般的に用いられている買い物かご（ショッピングカート）機能を用いて一時的に格納しておくようにすると良い。
【００２７】
品目群の選定が完了すると（ステップＳ４）、品揃え関連情報を参照して、発注対象の品目毎に顧客フロントを特定し（ステップＳ５）、続いて、その品目のデリバを特定する（ステップＳ６）。その後、正式の発注要求や、または承認者による承認（ステップＳ８）に応じて確定発注となった場合には（ステップＳ７）。この品目群をそれぞれのデリバから当該顧客フロント名で配送するための制御をする（ステップＳ９）。顧客フロントと、デリバと、品目の提供者（サプライヤ）との間の商流については、自動的にサプライヤからデリバへ当該品目が引き渡され、また、サプライヤから顧客フロントまでの売上／仕入関係を特定するようにシステム化しても良い。また、顧客フロントの在庫をデリバの倉庫に蓄積しておくようにしても良い。
【００２８】
図４は、本実施形態での受発注用ＡＳＰシステムの構成例を示すブロック図である。図４に示す例では、商品又はサービスの品目に関する情報が登録された商品マスタ等の各種マスタを記憶するデータベース９と、インターネット等のネットワークを介してブラウザ端末と接続され当該ブラウザ端末とのデータ送受信を制御すると共に当該ブラウザ端末での要求に応じて各種マスタのデータの抽出又は登録をするサーバ１０とを使用して、顧客の購買単位に属する一又は複数のユーザの端末に発注機能を提供すると共に、当該顧客へ品番で識別される品目を提供する複数の顧客フロントの端末に受注機能を提供する。各ブラウザ端末は、サーバから送信されるページを表示し、そのページ内のリンクや実行ボタンの操作に応じてサーバ１０に各種要求を送信する。図４に示す例では、顧客のユーザによって使用されるブラウザ端末をユーザ端末１、顧客フロントによって使用されるブラウザ端末を顧客フロント端末２４と称呼する。サーバ１０は、ＨＴＭＬやＸＭＬ等のマークアップランゲージで記述されたページを各端末１，２４に送信し、そのページを介して入力されるデータや、そのページの実行ボタン等の操作に応じて、各種マスタに格納されたデータを検索してページを生成し、この生成したページを当該端末に送信することで、各端末１，２４に各種の機能を提供する。各端末には、サーバ１０との通信を制御する通信制御機能と、所定のマークアップランゲージを解釈して表示するブラウザ機能とがあれば良く、各端末にアプリケーションソフトウエアを導入（インストール）した場合と同様の機能をサーバ１０との通信で端末上に実現することができる。
【００２９】
サーバ１０は、第１に、商品マスタ３に登録された品目のうち顧客の購買単位毎で且つ対応する顧客フロント毎に予め定められた当該顧客と顧客フロント間で受発注する取扱品目の一覧である品揃え関連情報を整備するための品揃え関連情報整備機能２４Ａを、顧客フロントのブラウザ端末（顧客フロント端末）２４に提供する品揃え関連情報整備制御部２９を備えている。品揃え関連情報整備機能２Ａは、顧客フロントが新たな又は継続した顧客と取扱品目を定めるために用いる商品一覧等の提案データ等を生成する機能である。また、一旦生成し、登録した品揃え関連情報をメンテナンスするための機能を備えるようにしても良い。
【００３０】
サーバ１０は、第２に、品揃え関連情報整備制御部による制御に応じて整備された品揃え関連情報を品揃え関連情報マスタとしてオンライン又はオフラインでデータベースに登録する制御をする品揃え関連情報登録制御部３０を備えている。品揃え関連情報登録制御部は、顧客フロント端末２４にて整備されネットワーク２を介したオンライン又は磁気テープ２６等によるオフラインにて入手した品揃え関連情報を品揃え関連マスタ４に登録する機能である。
【００３１】
サーバ１０は、第３に、購買単位に属するユーザの端末から一又は複数の品目について発注する際に当該ユーザが属する購買単位毎の品揃え関連マスタを参照して各品番別に当該商品又はサービスを提供する顧客フロントを特定する特定機能１Ａを、ユーザのブラウザ端末に提供する顧客フロント特定制御部２８に備えると良い。これにより、多種類の品目の一括発注を可能とする。この顧客フロント特定制御部２８の作用効果は、図１に示す品別発注制御部１４とほぼ同一である。
【００３２】
また、図１等に示した例と同様に、品揃え関連マスタ４が、顧客の購買単位にて購入する品番が複数の顧客フロントで重複しないように登録すると、ユーザが品目を特定するのみで当該品目を販売する顧客フロントを特定することができる。
このＡＳＰシステムでは、発注に応じた金額についてのトランザクションが、顧客からは購買データであり、顧客フロントからは売り掛けデータとなる。そして、アプリケーションサービスの提供者は、この顧客及び顧客フロントからすると第三者的な存在であり、このＡＳＰにて金額に関するトランザクションを実行している。従って、顧客と顧客フロントは当該トランザクションの実行結果（請求額及び支払額）を相互に信頼しやすく、顧客及び顧客フロントはそれぞれ決済の突き合わせ業務を削減しやすい。
また、受発注システムを顧客側が開発する場合と比較して、このアプリケーションサービスの導入を行うと、購買システムにて最も煩雑な商品データベースの更新や、取扱品目の決定等についてアウトソースすることができ、従って、ＡＳＰから顧客側のシステムに提供する購買データ等の仕様を整理することで、顧客側では従来からの承認処理システムや会計処理システムをそのまま使用しながら発注処理の自動化が可能となる。また、顧客フロント側から見ると、複数の顧客が本実施形態によるアプリケーションサービスを利用することで、顧客毎に異なるシステムから発注される発注データの個別対応を行う必要がない。
【００３３】
図４や図１等に示す構成は、各機能に応じたプログラム（スクリプト）をサーバ１０にて実行することで実現できる。サーバ用のコンピュータを受発注システムのサーバ１０として機能させるための受発注システム用プログラムは、当該サーバ用コンピュータを動作させる指令として、顧客の購買単位毎で且つ当該顧客に品目を提供する顧客フロント毎に予め定められた当該顧客と顧客フロント間で受発注する取扱品目の一覧情報である品揃え関連情報を管理するための品揃え関連情報管理指令と、購買単位に属するユーザによって使用される端末から一又は複数の品目について一括して発注する要求を受信したときに購買単位毎の品揃え関連情報を参照して各品番別に当該商品又はサービスを提供する顧客フロントを特定する品別発注制御指令とを備える。また、サーバ用コンピュータを例えば、デリバ特定制御部１９として機能させるためには、受発注システム用プログラムが、購買単位に属するユーザによって使用される端末から１又は複数の品目を発注するための発注要求を受信したときに、購買単位毎の品揃え関連情報を参照して各品番別に商品又はサービスをユーザに提供又は配送するデリバを特定するデリバ特定制御指令を備えると良い。このように、図１（第１実施例では図５）に示す構成や、図２（実施例では図１２等）に示す動作を実現するには、その各処理工程や機能を実現するための指令を備え、その指令に基づいてサーバ用コンピュータを駆動すると良い。サーバ用コンピュータは、各指令を実行することで、図１又は図４（実施例では、図５）に示す各部及び各機能として動作する。
【００３４】
上述したように本実施形態によると、品揃え関連情報が、ユーザ群と顧客フロントとその間で受発注可能な取扱品目（品揃え）を管理するため、ユーザは、品目の発注時に顧客フロントが誰であるかを意識することなく、例えば組織の購買管理部門にて予め定められた顧客フロントに発注することができ、さらに、ユーザは、複数の顧客フロントに対する発注を一括して処理することができるため、顧客フロント毎に発注する手間や、また、販売店毎に異なる手続等にて発注する必要がなくなり、これにより、発注作業を時間を短縮することができ、発注作業に要していた時間的、人的コストを削減することができる。また、費目別の発注を制御する例では、異なる費目が含まれる発注が承認プロセスに引き渡されることが無くなり、一方、同時に承認したい品目群は顧客フロントが異なっていても同時点での一括した発注として承認することができるため、承認プロセスや予算管理が容易となる。そして、費目別に発注することで、発注処理や検収を行った場合にその購買の費目が既に特定されており、また、サーバとの通信による受発注であるから請求データ等をオンラインで入手することが容易で、このため、間接財の会計管理や予算管理という企業活動に不可欠ではあるが企業の主要な活動目的そのものではない分野での業務コストを低減させることができる。また、一括発注機能により、ユーザ群に対して多数の顧客フロントが取引可能となることから、当該受発注システムにて取引可能な品目種別が増加することが期待できる。取引可能な費目種別が増加すると、間接財や副資材のほとんどの購買管理を品目の選定という作業のみで、自動化することができる。
【００３５】
【第１実施例】
次に、本発明の第１実施例を図面を参照して説明する。図５は、本発明の第１実施例による流通支援システムの構成例を示すブロック図である。流通支援システムは、図１に示す受発注システムによる機能のほか、顧客フロントから品目のサプライヤまでの商流を自動的に決定する。このため、ユーザが品目を選択すると、予め定められた設定に従って、当該品目のサプライヤから当該ユーザ（顧客）までの商流が自動的に定められる。
【００３６】
図５に示す例では、本実施例による流通支援システムは、各種マスタを記憶するデータベース９と、ネットワーク２を介して所定の端末１と接続され当該端末１とのデータ送受信を制御すると共に要求に応じて各種マスタのデータの抽出又は登録をするサーバ１０とを備えている。そして、データベースは、流通支援に必要な多種類のマスタを有しているが、本実施例では特に、以下のマスタを備えている。
【００３７】
（１）顧客の所定の購買単位と、当該購買単位に所属するユーザへ商品又はサービス等の品目を提供する顧客フロントとの関係について、顧客の購買単位に対して品目別に複数の顧客フロントが定義された顧客／顧客フロント対応マスタ５。
（２）ユーザ又は顧客の運営単位の一方である購買単位と、顧客フロントとをキーとして定義され、当該顧客フロントから当該購買単位へ提供する品目の品揃えを識別する品揃え単位が定義された品揃え単位マスタ４Ａ。
（３）この品揃え単位マスタの品揃え単位によって識別される品揃えに所属する品目及びサプライヤ及びデリバ等の品目の流通に関する属性情報が品揃えデータとして定義された品揃えマスタ４Ｂ。
（４）品目の品番毎に当該品目の仕様及びサプライヤ等の品目自体の属性情報が定義された商品マスタ３。
（５）顧客フロントとサプライヤとデリバとの関係に応じた卸等の中間商流プレイヤが定義された商流管理マスタ６。
【００３８】
上述した実施形態では、顧客フロントのユーザ群に対する品揃えは「品揃え関連情報」として管理する例を説明した。本実施例では、顧客フロントのユーザ群に対する品揃えの識別を「品揃え単位」にて行う。品揃え単位マスタ４Ａに登録される品揃え単位情報には、実際の品揃え自体は登録されない。本実施例では、品揃え単位ＩＤと品番を組み合わせることで、品揃えを定義している。この品揃え単位ＩＤと品番の組み合わせを、本実施例では品揃えと呼ぶ。この品揃えは、品揃えマスタ４Ｂに登録される。
【００３９】
サーバ１０は、本実施例では、顧客／顧客フロント対応マスタを参照して顧客運営単位毎に顧客フロント群を特定する顧客フロント群特定部３２と、品揃え単位マスタを参照してユーザ毎又は顧客運営単位毎に品揃え単位群を特定する品揃え単位群特定部３４とを備えている。
【００４０】
サーバ１０はさらに、品揃え単位群特定部３４によって特定された複数の品揃え単位毎の品揃えデータとユーザから発注用に選択された品番とに基づいてこのユーザと取引する顧客フロント群の内の唯一の顧客フロントを特定する顧客フロント特定部３６と、ユーザから発注用に入力される品番に基づいて当該品番毎に品揃え単位群特定部によって特定された品揃え単位群のそれぞれの品揃えデータのうち各品番毎に唯一の品揃えデータを品揃え単位毎に定義された唯一の品揃えデータを品揃えマスタから抽出する品揃えデータ抽出部３８と、この品揃えデータ抽出部によって抽出された品揃えデータに基づいて当該品目のサプライヤ及びデリバを特定するサプライヤ／デリバ特定部４０とを備えいてる。
【００４１】
また、サーバ１０は、このサプライヤとデリバと顧客フロントとの組み合わせに応じて商流管理マスタを参照してサプライヤから顧客フロントまでの商流を特定すると共に当該商流での仕入／売上処理を支援する商流制御部４８と、デリバから顧客フロント名義で品目をユーザに配送するための制御をする配送制御部４２とを備えている。この図５に示す構成により、ユーザ群に対して複数の顧客フロント（品揃え単位）が定義されている場合であっても、発注用にユーザが品番を選択した段階でサプライヤから顧客までの商流を自動的に決定する。
【００４２】
図６は、本実施例での品揃え単位の各ユーザとの関係を示す説明図である。図６では、顧客（０１，０２）の４つの運営単位を例としている。運営単位に付する運営単位ＩＤは、顧客、サプライヤ、中間商流プレイヤ、デリバ全てにユニークに付され、相互に識別するＩＤとするとよい。中間商流プレイヤであっても、その業務の遂行上間接財は必要となるため、この場合顧客となる。本実施例では、会社をそのまま取引の単位とするのではなく、購買の仕組みが共通している単位を独立した運営単位としている。たとえば総務部と事業部で購買の仕組みが大きく相違する場合には、異なる運営単位とする。
【００４３】
運営単位には、ユーザが所属する。例えば、運営単位（０１）には、東京所在のユーザ（０１，０２）と、大阪所在のユーザ（０３）とが所属する。運営単位数やユーザ数は説明のために少なくしている。全国展開している顧客フロントの品揃え単位（０１）は、全てのユーザが発注可能となっている。一方、東京を主な活動地域とする東京顧客フロントの品揃え単位（０２）は、東京在住のユーザ（０１，０２）がアクセスし、大阪在住のユーザ（０３）は、東京顧客フロントではなく、大阪顧客フロントの品揃え単位（０３）へアクセスする。これは、所在地域等によって、同一の運営単位であっても、ユーザによって異なる顧客フロントと取引を行う例である。
【００４４】
運営単位（０２）に、総務のユーザ（０１）と、事業部のユーザ（０２）が所属しているとする。総務のユーザ（０１）はオフィス家具の発注が可能であるが、事業部の権限ではオフィス家具の発注ができないとする。この場合、オフィス家具を提供する顧客フロントの品揃え単位（０４）には、ユーザ（０２）はアクセスしない。文具の品揃え単位（０５）や理化学機器の品揃え単位（０６）は、共通してアクセス可能としている。オフィス家具と文具との双方を提供する顧客フロントの場合には、品揃え単位（０４）と（０５）とを一体化し、事業部のユーザ（０２）に対して品目単位で発注不可とするような制御をしてもよい。
また、運営単位（０３）のユーザ（０１）のように、唯一の品揃え単位のみが定義される場合もある。
【００４５】
図７は、品揃え単位と品番の関係を示す説明図である。図７に示す商品マスタには、本実施例による全ての取扱品目が含まれている（他サイト連携はここでは考慮しない）。そして、全ての品目はユニークな品番によって識別される。ユーザを単位として品揃え単位を検討すると、品揃え単位は相互に重複した品番を有さない。これにより、あるユーザにて品番が特定されると唯一の品揃え単位が特定され、この品揃え単位によって識別される顧客フロントが特定される。ユーザ（０１，０２）の品揃え単位（０２）と、ユーザ（０３）の品揃え単位では一部重複し、一部異なるものとなっている。東京と大阪での顧客フロントの品揃えやユーザの好みの差に応じて、それぞれの顧客フロントが顧客に最適な品揃えを提供しようと試みる。
【００４６】
図７に示す例では、品揃え単位（０１）による品番群（品揃え）と、品揃え単位（０４）による品揃えは品番としては一致している。しかし、品揃え単位は顧客フロント毎に生成されるため、顧客フロントが異なると品揃えの品目が同一であっても異なる品揃え単位を用意する。また、運営単位が異なる場合にも、異なる品揃え単位を用意する。品揃えデータには、その顧客への提供価格や、納品の手法に応じたデリバ等の流通の属性に関する情報が登録されるため、このように運営単位又は顧客フロント毎に品揃え単位が登録される。この品揃え単位は、運営単位に所属するユーザとの関連が定義され、このユーザと品揃え単位の関係はユーザ／品揃え単位マスタに登録される。
【００４７】
図５に示す例では、サーバ１０は、ユーザからアクセスされたときに当該ユーザを識別するユーザＩＤ及びパスワード並びに当該ユーザが所属する顧客運営単位ＩＤの入力を要求するログイン制御部４４を備えている。ユーザは、本実施例による流通支援システムのログイン用ページを読み出し、ユーザＩＤ及び顧客運営単位ＩＤとを入力することで、流通支援システムのサーバ１０にログインする。ログインユーザは、その所属する顧客の運営単位と、ユーザＩＤとが識別可能となる。本実施例では、顧客フロント群特定部３２は、ログイン制御部４４による制御に応じて入力される顧客運営単位ＩＤに基づいて当該ログインユーザに品目を提供可能な顧客フロント群を特定する機能を備えている。顧客と顧客フロント対応マスタ５には、顧客運営単位ＩＤとこの顧客運営単位ＩＤで識別される顧客運営単位に所属するユーザへ品目の提供を契約した一又は複数の顧客フロント（顧客フロント群）が特定される。品揃え関連情報を用いても顧客フロント群を特定することはできるが、図５に示す例では、ログインした状態で顧客フロント群を特定することで、当該ログインユーザに対して各顧客フロントからのメッセージを表示したり、また、緊急に取引停止となった顧客フロントの有無のログイン時での判定等が可能となる。
【００４８】
また、品揃え単位群特定部３４は、ログイン制御部４４による制御に応じて入力されるユーザＩＤ又は顧客運営単位ＩＤに基づいて各顧客フロント毎に当該ユーザに提供する品目の一覧が定義された品揃え単位群を特定する機能を備えている。ユーザ／品揃え単位マスタ７には、ユーザＩＤと品揃え単位ＩＤとの関係が定義されている。品揃え単位群特定部３４は、このユーザ／品揃え単位マスタ７を参照してログインユーザに対する品揃え単位ＩＤ群を特定する。この品揃え単位ＩＤ群が判明すると、当該ログインユーザが発注可能な全ての品目にアクセスすることができる。従って、例えば「オフィス清掃」というキーワードで品目の検索をした場合には、顧客フロント（１０）の品揃えである清掃用具と、顧客フロント（１１）の品揃えである電球等の消耗品と、顧客フロント（１３）の品揃えである清掃サービスとを検索することも可能となる。
【００４９】
図５を参照すると、サーバ１０は、ユーザによって発注される一又は複数の品目の品番を発注品番群として一時的に格納する制御をする発注制御部４６を備えている。そして、顧客フロント特定部３６は、発注制御部４６にて格納される発注品番群の品番毎に特定される当該品番の品揃え単位に基づいて顧客フロント群の内の唯一の顧客フロントを特定する機能を備えている。品揃え単位マスタ中の整備責任運営単位ＩＤは、当該品揃えを提供する顧客フロントの運営単位ＩＤである。顧客フロント特定機能は、本実施例では、ユーザＩＤと品番とによって品揃え単位が特定された後に、この品揃え単位マスタの整備責任運営単位ＩＤを参照して当該品目を当該ユーザに提供する顧客フロントを発注時に自動的に特定する。このとき、顧客フロント特定部３６は、顧客フロント群特定部によって特定された顧客フロント群に関する情報を参照することなく、当該顧客フロントを特定することができる。一方、この顧客フロント特定部３６が特定する顧客フロントは、顧客フロント群特定部によって特定された顧客フロント群の中の一つである。
【００５０】
ユーザＩＤが定まっている状態で、品番が定まると、品揃えが重複しない前提では、品揃え単位ＩＤを唯一に特定できる。品揃えは顧客フロント毎に定義されるため、ユーザＩＤと品番の組み合わせにより、複数の顧客フロントから唯一の顧客フロントを特定することができる。
【００５１】
また、発注制御部４６は、発注制御部が、承認基準が定められている場合であって、前記一時的に格納した発注品番又は発注品番群がある場合に当該発注品番と新たに追加される品目の品番の承認基準が異なる場合には新たな品目の追加を受け付けずに同一承認基準別の一括した発注を促す承認基準別発注制御機能４６Ａを備えるようにしても良い。承認基準別発注制御機能４６Ａの作用及び効果は、図１に示す承認基準別発注制御機能１６と同様である。
【００５２】
図５に示す例では、発注制御部４６は、ユーザ又は承認者等の他のユーザから発注品番群に対する確定発注の受信を制御する機能を備えている。承認者から発注の承認があった場合に、当該発注品番群に対する確定発注があったと判断するようにしても良い。確定発注がなされると、サプライヤ／デリバ特定部は、確定発注の発注品番群の各品番毎に顧客フロント特定部３６によって特定された顧客フロントの当該ユーザに対する品揃え単位によって識別される品揃えデータを参照して、当該品番のサプライヤ及びデリバを特定する機能を備えている。すなわち、本実施例では、顧客フロントと品目の組み合わせによって、唯一のサプライヤ及びデリバを特定する。生花贈答サービスや、名刺印刷サービスなど、複数のサプライヤが存在する場合であっても、品揃え関連情報の生成時にユーザと品目毎にサプライヤを特定しておく。
【００５３】
さらに、商流特定部４８は、このサプライヤ／デリバ特定部４０によって特定されたサプライヤ及びデリバと当該品番の顧客フロントとの組み合わせに応じて商流管理マスタ６を参照してサプライヤから顧客フロントまでの中間商流プレイヤの商流を唯一の流通経路として特定する機能を備えている。すなわち、本実施例では、顧客フロントと、サプライヤと、デリバとの組み合わせが定まると、顧客フロントからサプライヤまでの商流を唯一のものとして特定する。この商流は、品目又は品目群ごとに顧客フロントは仕入先を唯一のものとして特定する。この仕入先は、さらにその仕入先を唯一のものとして特定する。この中間商流プレイヤのつながりがサプライヤに至るまで、その経路を唯一のものとする。
【００５４】
デリバを商流特定のキーとすることで、顧客と顧客フロントとの間の品揃えをより豊かで柔軟なものとすることができる。例えば、コピー用紙について通常の購買と、特に急ぐ緊急用の購買とに別の品番を定めておき、通常の購買についてはサプライヤと提携したデリバからの直送とし、一方、緊急用の購買の場合には顧客フロントが直接ユーザにコピー用紙を届けることとする。この場合、緊急用のコピー用紙のデリバは、顧客フロント自身である。従って、商流は発生しない。このデリバの態様を種々定義できるようにしつつ、通常の運用時には商流を高速かつ確実に自動判定できるようにするために、顧客フロントと、サプライヤと、デリバとの組み合わせに応じて商流を定めることとした。また、サプライヤからの直送のみとせず、現在の商流に近似した仕組みをシステム上に実現することで、多種多様な業種の品目が本実施例による流通支援システムにて商取引可能となることを図っている。品目の種類が増加すると、一括発注機能により、ユーザはさらに簡易な発注が可能となり、さらに、会計処理を本実施例により自動化できる範囲が拡大できる。
【００５５】
次に、各種マスタの主要な項目を説明する。図８は本実施例での各マスタの代表的項目例を示す説明図である。図８、図９、図１１に共通して、システム運用上必要な全ての項目ではなく、本実施例の説明に必要な項目のみを開示する。また、各マスタ毎のブロックのうち、一番目のボックスは項目名で、二番目のボックスの項目はその項目毎に当該テーブルが定義されることを示し、三番目のボックスは各テーブル毎に入力されるデータの項目である。
【００５６】
図８（Ａ）は商品マスタの項目例を示す図である。商品マスタには、主に、商品及びサービスのサプライヤから提供される情報を登録する。顧客フロント毎に異なる情報については商品マスタには登録しない。
【００５７】
商品マスタは、各品目を識別する品番キーとして三番目のボックスの項目が登録される。すなわち、一つの品番に対して、供給元メーカコード等が定義される。図８（Ｃ）に示す例では、品揃え単位ＩＤと品番の組み合わせをキーとして、この組み合わせ毎に提供価格等が登録される。
【００５８】
商品マスタは、その項目として、サプライヤ側での商品管理に用いる供給元メーカコードと、このサプライヤを識別するためのサプライヤＩＤと、顧客フロント以外のデリバの不在や、指定可能なデリバなど品目毎に予め定められた配送に関する状況を示す複数のデリバ判定用フラグと、生花のギフトサービスや、名刺印刷サービスなど、発注時に通常の品目と異なる情報が必要となる特殊品番であるか否かを示す特殊品番区分と、提携するサプライヤのＷｅｂサイト等の他サイトにて管理される品目であるか否かを示す他サイト連携区分と、ユーザに当該品目の内容を紹介するための複数の画像ファイル名と、定められている場合には希望小売価格と、この価格の改定の予定日とを有する。
【００５９】
商品マスタはまた、顧客のユーザが必要な商品を検索する際に使用する検索用キーワードや、商品カテゴリなどを有する。この商品カテゴリは、例えばシャープペンシルという小分類、筆記具という中分類、文房具という大分類等の商品のカテゴリを識別するものである。この商品カテゴリの活用法には種々のものがあり、例えば品揃えデータに費目を定義する際には、例えば文房具であれば全て消耗品という費目とする場合、各品番毎に費目を定義する必要が無く、商品カテゴリを参照して少ない操作で全体の品目に費目を定義することができる。
【００６０】
図８（Ｂ）は品揃え単位マスタの項目例を示す図である。品揃え単位は、顧客フロントが運営単位に対して提案し、顧客によって選定された品揃えの名称である。また、品揃え全体に対して有効な情報についても、この品揃え単位に登録される。図８（Ｂ）に示す例では、品揃え単位は、品揃え単位ＩＤをキーとして登録される。また、本実施例では、例えば流通支援システムのバージョンや、品揃えを予め定められたカタログとする場合の流通支援などシステムが顧客等に対して提供するサービスの形態を識別するサービス形態ＩＤを使用している。品揃え単位についても、このサービス形態ＩＤを定義する。
【００６１】
品揃え単位は、その項目として、商品群の名称等の品揃え単位名と、当該品揃え単位によって識別される品揃えの整備責任を有すると共に当該顧客に品揃えの各品目を提供する顧客フロントの運営単位のＩＤである整備責任運営単位ＩＤと、当該品揃えを適用するユーザが所属する顧客運営単位ＩＤと、ユーザとのデータ送受信において品目の価格や消費税額等の表示を行うか否かを示す価格関連情報表示可否フラグとを有する。大規模な会社の場合には、当該会社やグループ会社での購買を一括して管理する購買子会社を有する場合がある。その会社に対する顧客フロントは購買子会社となるが、品揃えの提案はこの購買子会社と取引を行う顧客フロント（中間商流プレイヤの一種）である。この場合、品揃えの整備及び実際の品目の提供は購買子会社と取引する顧客フロントとなる例が想定できる。このようなケースでは、品揃え単位マスタについて、品揃え単位から特定する顧客フロントを、購買子会社ではなく、その購買子会社と取引を行う顧客フロント（購買子会社フロント）とすると良い。購買子会社フロントが、品揃え関連情報を購買子会社等との取り決めに従って整備する。この場合、購買子会社と購買子会社フロント間の仕入、請求や、購買子会社から顧客への仕入及び請求については他のマスタで管理すると良い。
価格関連情報表示可否フラグで設定した内容は、その品揃え単位で識別される品揃えの全品目に適用される。
【００６２】
図８（Ｃ）は品揃えマスタの項目例を示す図である。品揃えは、図８（Ｂ）に示す品揃え単位マスタにて定義された品揃え単位ＩＤと、品番との組み合わせをキーとして、主に品目の流通に必要な属性情報を管理する。ここでは、品揃え単位にて識別される品揃えの品番毎に、顧客フロントから顧客への提供価格の算出方式を指定する提供価格算出方式区分や、提供価格（実額方式の場合）や、掛率（仕入又は希望小売価格に対する掛け率の場合）や、顧客フロントが卸やサプライヤから仕入れる際の値段である顧客フロント仕入価格や、当該品目のサプライヤを特定するサプライヤ運営単位ＩＤや、デリバの運営単位ＩＤや、当該ユーザについての当該品目の費目を指定した費目コードを有する。
【００６３】
品揃えマスタは、その項目として、品揃え単位にて識別される品揃えのうち当該品目が一般ユーザにとって発注禁止であるか否かを区分コード（例えば、１から５の数値）で特定する一般ユーザ発注禁止区分や、一定の数量を単位として提供する場合の数量等の提供価格丸め方式を指定する提供価格丸め区分とを有する。一般ユーザ発注禁止区分に記述される禁止区分コードがユーザマスタに登録されている場合、その品目は発注禁止となる。これは、例えば一定の予算権限を有する者のみに購入を許可する場合や、特定の部署での購入を禁止する場合等に用いる。
【００６４】
品揃え関連情報というときには、この品揃え単位マスタと品揃えマスタとを一体化した場合の情報を意味する。すなわち、品揃え関連マスタデータは、本実施例では、品揃え単位マスタと、品揃えマスタとを備える。購買単位に対して複数の品揃え単位が定義されている場合に、当該複数の品揃え単位にて当該購買単位に対して取扱可能な品目が品揃え単位間で重複しない状態で定義すると、複数の顧客フロントに対する一括した発注を行いやすい。この一括発注は、品目別に顧客フロントを切り分けて発注する品別発注機能でもある。
【００６５】
図９（Ａ）はユーザ／品揃え単位マスタの項目例を示す図である。ユーザ品揃え単位マスタ７は、その項目として、ユーザＩＤと品揃え単位ＩＤとを有する。すなわち、ユーザＩＤに対して、そのユーザがアクセス可能な品揃え単位群を指定する。また、ユーザ品揃え単位マスタ７は、品揃え単位にアクセスするユーザ群を指定する。図９（Ｂ）は顧客／顧客フロント対応マスタの項目例を示す図である。顧客／顧客フロント対応マスタ５は、運営単位ＩＤと、顧客フロント運営単位ＩＤとをキーとして登録される。すなわち、顧客の運営単位ＩＤが定まると、顧客フロント群が特定される。また、顧客フロント運営単位ＩＤが定まると、この顧客フロントの顧客となる顧客運営単位群を特定できる。
【００６６】
図９（Ｃ）は商流管理マスタの項目例を示す図である。商流管理マスタは、顧客フロントと、サプライヤと、デリバとの間の中間商流を特定するために使用する。商流管理マスタ６は、サービス形態ＩＤと、顧客フロント運営単位ＩＤと、サプライヤ運営単位ＩＤと、デリバ運営単位ＩＤとをキーとする。従って、品目毎に商流を定義するのではなく、この三者の組み合わせに応じて中間商流を特定する。商流管理マスタは、その項目として、まず、顧客フロントの直接の仕入先となる顧客フロント仕入先コードを有する。さらに、中間商流プレイヤ１の得意先コード（顧客フロントの運営単位ＩＤ）と、中間商流プレイヤ１の運営単位ＩＤと、中間商流プレイヤ１の仕入先コード（中間商流プレイヤ１の直接の仕入先となるサプライヤまた中間商流プレイヤ）というように、この得意先、運営単位、仕入先という組み合わせをプレイヤ毎に定義する。サプライヤ運営単位ＩＤが仕入先コードに特定されると、商流は唯一のものとして完成する。この商流のパターンは予め定められている場合が多く、品揃え関連情報の生成ではそのパターンに基づいてこの商流管理マスタを生成する。
【００６７】
図１０は、本実施例でのユーザの所属単位の例を示す説明図である。運営単位に所属するユーザは、例えば、ある部署を単位に請求を行うが、予算は部署を横断したプロジェクトを単位とし、さらに同一部署であってもオフィスが分散していて品目の提供先・送り先が異なる場合がある。これらの関係は組織によって多様であるため、図１０に示すようにユーザの所属を多重継承とし、各請求先ＩＤ等を図１０に示すようにユーザの属性を定義するユーザマスタに登録することとした。図１０（Ａ）は請求先との関係を示す図で、ユーザ（０１，０２）は請求先（０１）に所属している。図１０（Ｂ）は予算管理単位との関係を示す図で、ユーザ（０１，０３，０５）は予算管理単位（０１）に所属している。本実施例では、予算管理単位と、費目とに応じて、購買に関する承認基準（承認経路、予算管理者）を唯一のものとして特定する。費目が異なる場合であっても同一承認基準となることはある。この場合、承認基準が同一であるから、ユーザは異なる費目で、且つ、異なる顧客フロントの取扱品目であっても、承認基準毎に一括して発注することができる。
ユーザ（０６）は他の承認者を経ずに品目の購入ができるため、予算管理単位（０３）を他のユーザから分けている。図１０（Ｃ）は直送先との関係を示す図である。この直送先は、一般的にはユーザの勤務地で、所属部署のオフィスとなる。
【００６８】
図１１（Ａ）は顧客マスタの項目例を示す図である。顧客マスタは、運営単位ＩＤ（顧客運営単位ＩＤ）をキーとして登録される。顧客項目には、その運営単位全体に適用する購買に関するデータが登録される。一方、ユーザマスタ５２は、ユーザＩＤをキーとして登録され、その項目は、図１０に示すように、各ユーザの当該運営単位内での種々の所属に関するデータが登録される。休日フラグは、納期の算出のために用いられる。
【００６９】
図１２及び図１３は、本実施例での代表的な動作例を示す説明図である。ユーザからアクセスされると、まずログイン画面を表示する。ここで、運営単位ＩＤとユーザＩＤとが入力され、さらにパスワードを使用したユーザ認証に成功すると、運営単位ＩＤに基づいてそのユーザが顧客であるか又は顧客フロントであるか等を判定する。顧客である場合には、顧客／顧客フロント対応マスタ５を用いて当該ユーザが所属する顧客運営単位と取引が可能な顧客フロント群を決定する。また、ユーザＩＤから、品揃え単位群を特定する。
【００７０】
発注用のメインメニューの表示では、例えば、顧客フロント群それぞれのバーナー広告や、お知らせ等を表示するようにしても良い。そして、品番入力注文等により品目の買い物かごへの登録を行う。ここで、品揃え単位群で特定できる品揃え群に入力された品番が存在しない場合には、取扱不能であるエラーメッセージや、または、購入を希望する場合には購買担当部門への連絡が必要である等のメッセージを出力すると良い。品目の品番が特定されると、顧客フロント、デリバ、名刺印刷等の特殊品番であるか否か、他サプライヤとの連携があるか否か、提供価格及び費目の初期値とを特定することができる。
【００７１】
名刺の印刷や生花のギフト等の特殊品番である場合には、それぞれ必要な情報の入力を求める。他サイト連携にてシステム外の他のサプライヤの商品を発注する場合には、所定の他サイト連携機能を用いて他サイトから品番や小売価格等を取得し、提供価格を決定する。また、用途による検索や、使用法による検索や、前回注文した履歴を参照しての発注など、種々の方向から品目を選択して、買い物かごへ入れる。このとき、異なる費目の品目を買い物かごへ入れる操作がなされた場合には、費目相違であるため別に発注して欲しい旨を表示すると良い。これにより、一回の発注では唯一の承認経路を特定することができる。従って、品揃え関連情報によって複数の顧客フロントにまたがる品目を一括して発注するように発注品番群を特定しつつ、この発注品番群について一度の承認プロセスで承認の可否を得ることができる。承認者もユーザであるため、顧客端末を使用して承認を行うことができる。これにより、承認を単位とした一括発注を行うことができる。これは、顧客フロント別に手書き伝票で発注依頼を生成し、且つ、それらを合計した承認用の書類を作成し、その書類を次々と承認者へ回覧することと比較して、購買に関するユーザが用いる時間を飛躍的に短縮することができる。
【００７２】
図１３に示すように、発注が行われると、ユーザと費目に応じて承認の有無や承認方式を特定し、承認が不要で有ればこの発注を確定発注とする。確定発注であれば、サプライヤと、中間商流プレイヤと、中間商流での売上や仕入等を決定する。商流のプレイヤ間の納品書や請求書等は予め定められた方式で印刷し、各名義にて送付する。
【００７３】
承認が必要な場合には、承認または否認を特定し、否認の場合には発注の取り消しとする。最終承認が得られると、この発注が確定したものと判定する。この承認に際して、予算管理単位毎に下限や今までの累計金額等での予算管理を行うようにしても良い。
【００７４】
上述したように本実施例によると、顧客フロント群とユーザとの関係を品揃え関連情報として整備しておくことで、一括発注（品別発注）を実現している。また、顧客の購買担当部門や購買子会社では購買管理作業を簡略化することができ、さらに、顧客フロント側でも、定番品の受注処理が自動化されるためより個別のサービスに営業資源を用いることができる。すなわち、第１実施例は、販売店向けの定番品販売用アプリケーション・サービス・プロバイダ・システムとしても機能する。この場合、顧客への提供価格及び中間商流プレイヤからの仕入価格を自動決定し、また、デリバからの配送完了通知を電子的に取得することで、月締めの請求書や売上を自動的に計上することができる。
【００７５】
【第２実施例】
次に、本発明の第２実施例を図面を参照して説明する。第２実施例では、上述した実施形態や第１実施例で使用する品揃え関連情報（品揃え単位で識別される品揃え）の生成手法を開示する。図１４は、第２実施例による品揃え関連情報登録方法の構成例を示すフローチャートである。まず、顧客と定番品の定期購入契約を締結しようとする顧客フロントのユーザが、当該顧客フロントの端末を使用して、商品マスタに基づいて当該顧客向けに提案する取扱品目の一覧を生成する（ステップＳ１１，提案用データ生成工程）。
【００７６】
続いて、この提案用データ生成工程Ｓ１１にて生成された提案用データを使用して顧客の購買担当者と顧客フロントのユーザ間で商談が行われ、顧客の購買担当部門等によって取扱品目の一覧が特定されたときに、取扱品目の一覧である品揃えを識別するための品揃え単位を顧客のユーザ別等の購買単位毎に定義する（ステップＳ１２，品揃え単位定義工程）。
【００７７】
さらに、この品揃え単位定義工程Ｓ１２にて定義された品揃え単位によって識別される品揃えに含まれる各品目について当該品目のサプライヤ及びデリバを登録する（ステップＳ１３，サプライヤ／デリバ登録工程）。このとき、商品マスタに登録されていない品目を品揃えに登録する場合には、予め商品マスタに当該品目を追加する。この追加された品目は、他の顧客フロントによっても他の顧客に対して品揃えに含めることができる。続いて、このサプライヤ／デリバ登録工程Ｓ１３にて登録されるサプライヤとデリバと顧客フロントとの関係に基づいて当該サプライヤから顧客フロントまでの中間商流を定義する（ステップＳ１４，中間商流定義工程）。
【００７８】
続いて、顧客運営単位内にて複数の品揃え単位がある場合には（ステップＳ１５）、顧客運営単位のユーザごとに品揃え単位を登録する（ステップＳ１６，ユーザ別品揃え単位登録工程）。さらに、品揃えを登録するときに、当該顧客について他の顧客フロントと品番が重複している場合には（ステップＳ１７）、品番重複エラーを出力する（ステップＳ１８，品番重複確認工程）。一方、エラーとならなければ、サプライヤ及びデリバを品揃え単位の品目毎に定義し、品揃えマスタに登録する（ステップＳ１９，品揃え登録工程）。
【００７９】
図１５は、第２実施例による品揃え関連情報登録システムの構成例を示すブロック図である。本実施例による品揃え関連情報登録システムは、第１実施例にて開示した流通支援システムで使用する品揃え関連情報を生成する。上述したように、流通支援システムは、サプライヤによって提供されデリバによって配送又は提供される商品又はサービス等の品目に関する情報が登録された商品マスタ等の各種マスタを記憶するデータベース９と、ネットワーク２を介して所定の端末と接続され当該端末とのデータ送受信を制御すると共に要求に応じて各種マスタからデータを抽出又は登録するサーバ１０とを備えている。
【００８０】
本実施例による品揃え関連情報登録システムは、Ｗｅｂ関連技術を用いたクライアント・サーバ形式で実現でき、また、顧客フロントの顧客フロント端末２４に対して品揃え関連情報の登録用機能を提供するＡＳＰともいえる。図１５では、顧客フロント端末２４のブラウザ上で実現できる機能群と、サーバ１０での機能群とに区分した。図１５に示すように、品揃え関連情報登録システム顧客フロント端末２４の機能として、顧客と定番品の定期購入契約を締結しようとする顧客フロントのユーザが当該顧客フロントの端末２４を使用して商品マスタ３に基づいて当該顧客向けに提案する取扱品目の一覧を生成する提案用データ生成部６０と、顧客フロントからサプライヤまでの間の仕入／売上関係について各品目の価格に関する掛け率等の価格関連情報を品目毎又は品目群毎に登録する価格関連情報登録部６２と、品揃え単位ＩＤ付与部７６によって付与された品揃え単位ＩＤによって識別される品揃えに属する各品目について当該品目のサプライヤ及びデリバを特定するサプライヤ／デリバ特定部６４と、サプライヤ／デリバ特定部６４によって特定されるサプライヤと顧客フロントとの関係に応じて卸等の中間商流プレイヤを登録する中間商流登録部６６とを備えている。
【００８１】
顧客フロント端末２４は、さらに、品揃え単位の品揃えマスタへの登録を制御する品揃え単位登録制御部６８と、サプライヤ／デリバ特定部６４によって特定されるサプライヤ及びデリバを品揃え単位の品目毎に登録すると共に、その品揃えデータを磁気テープ２６等に格納する品揃え登録制御部７２とを備えている。
【００８２】
サーバ１０は、提案用データ生成部６０によって生成された提案用データに応じて顧客によって取扱品目の一覧が特定されたときに当該顧客フロントの顧客に対する取扱品目の一覧である品揃えに品揃え単位ＩＤを付する品揃え単位ＩＤ付与部７６と、磁気テープ２６等から読み出した品揃えを品揃えマスタ４Ｂに登録する品揃え登録部８０と、この品揃え登録部８０によって品揃えが登録されるときに当該顧客について他の顧客フロントと品番が重複している場合には品番重複エラーを出力する品番重複確認部８２とを備えている。
【００８３】
また、図１５に示す例では、品揃え単位登録部７８が、顧客に対して複数の品揃え単位がある場合には顧客の購買単位となるユーザ毎に当該品揃え単位を登録するユーザ別品揃え単位登録機能７０を備えている。この図１５に示す構成により、一括発注を可能とするための品揃え関連情報を生成し、マスタに登録することができる。
また、好ましい例では、サーバが、商品マスタに登録されていない品目を品揃えに登録しようとする場合には当該品目を新たに商品マスタに登録させる制御をする新品目時商品マスタ更新部と、この新品目時商品マスタ更新部によって更新された品目が当該顧客フロントのオリジナルである場合には当該品目の他の顧客フロントでの品揃えでの使用を禁止するための独自品番フラグを当該商品マスタに格納する独自品番フラグ格納部とを備えるようにしても良い。新品目時商品マスタ更新部は、商品マスタに登録されていない品目を品揃えに追加する場合に、まず、商品マスタへ登録し、特に商品マスタでユニークな品番を取得させる。新品目時商品マスタ更新部は、新たに登録する品目が特定のサプライヤの新商品等である場合には、サプライヤへ当該新商品の登録を促すようにしても良いし、顧客フロントが直接顧客に提供するサービス等である場合、本実施例では、顧客フロント自身がその品目のサプライヤである場合には、顧客フロント自身が登録する。この顧客フロントにオリジナルの品目を、独自品番と呼ぶ。
そして、独自品番フラグ格納部は、この独自品番を商品マスタに登録する場合には、当該品目が独自品目であることを示す独自品番フラグを当該商品マスタに登録すると良い。独自品番フラグは、独自品番か否かを示す区分データでも良い。そして、品揃えデータの作成のために他の顧客フロントが商品マスタにアクセスする場合には、この独自品番フラグが格納された品目の品揃えを禁止する。これにより、商品マスタと顧客フロント別の品揃えマスタとの整合性を保つことができる。
【００８４】
図１６は、第２実施例での品揃え関連情報検査システムの構成例を示すブロック図である。図１６に示す例では、顧客に提供する商品又はサービス等の品目の品揃えである品番の一覧及び当該品揃えの各品目毎にサプライヤ及びデリバ等の当該品目の流通に関する属性情報が定義された品揃え関連情報の整合性を検査する。
【００８５】
この品揃え関連情報検査システムは、品揃え関連情報にて特定される品揃え中の品番が商品マスタに登録されているか否かを確認する品番確認部９０と、品揃え単位データに含まれる品番が顧客に対する他の品揃関連情報に登録されているか否かを確認する品番重複確認部９２とを備えている。そして、品揃えの各品目毎に当該品目を顧客に配送するデリバと、当該品目の在庫を有するサプライヤと、当該品目の顧客に対する価格決定方式とが登録されているか否かを確認する品目属性データ確認部９４とを備えている。また、品揃え関連情報検査システムは、品揃えデータの登録に際して品目の顧客のユーザ別に定義された予算管理又は会計管理に使用される費目が登録されているか否かを確認する費目確認部９６を備えるようにしても良い。
【００８６】
品揃え関連情報検査システムは、品番確認部９０によって品番がないと判定された場合には、当該品揃え関連情報の顧客フロントのオリジナル品番として商品マスタ及び品揃え関連情報へ登録する処理に導くようにしても良い。品番重複確認部９２によって品番の重複が発見された場合には、顧客の購買担当者にいずれかの顧客フロントを選択すべき旨を連絡する制御をしても良い。品目属性データ確認部９４によって、例えばデリバが特定されておらず、配達経路がない品目が発見された場合には、顧客フロントがデリバとなるか、または他のデリバを選択する処理に導くようにしても良い。
【００８７】
【発明の効果】
本発明は以上のように構成され機能するので、これによると、品揃え関連マスタに、商品マスタに登録された品目のうち顧客の購買単位且つ当該顧客へ品目を提供する顧客フロント（販売店）毎に予め取り決められた取扱品目の一覧である品揃え関連情報を登録しておき、品別発注制御部は、ユーザの端末から一又は複数の品目を発注するための発注要求を受信したときに、当該ユーザが属する購買単位毎の品揃え関連情報に基づいて当該発注要求の各品目を提供する顧客フロントを特定するため、品目の手配が必要となったユーザは、各品目の顧客フロント毎に品目を検索することなく、必要な品目を選定し、発注処理を行うことができ、このとき、ユーザが指定する内容が品目のみであっても、品別発注制御部は、品揃え関連情報を参照してその品目を取り扱う顧客フロントを特定することができ、従って、ユーザは各品目別の顧客フロント名等を知らずに品目の発注を行うことができる。このように、品目を入手するユーザは、販売店が異なる毎に異なるシステムを利用することなく、複数種別の品目から必要な品目を選択して発注することができる。さらに、品別発注制御部が、複数の品目を発注する発注要求を受信したときであっても、その品目別に顧客フロントを特定するため、ユーザは、複数種別の品目を一括して選択し、一括して発注することができ、発注業務を簡略化、迅速化することができ、さらに、顧客フロントに限定されずに複数種類の品目を一括して発注可能となると、会計処理や予算管理での単位別の発注が可能となり、予算、承認、会計を含めた購買管理を低コストで実現することができ、このように、間接財を主とする商品及びサービスの購買を低コストで実行及び管理することができる、という従来にない優れた受発注システムを提供することができる。さらに、本発明の構成では、顧客フロントと品番とが定まると、顧客フロントとサプライヤとデリバとが定まるので、サプライヤから顧客フロントまでの商流を唯一に特定できる。
【図面の簡単な説明】
【図１】本発明の一実施形態の構成を示すブロック図である。
【図２】図１に示す構成で使用する品揃え関連情報の顧客購買単位（ユーザ群）との関係を示す説明図である。
【図３】図１に示す構成での受発注処理の一例を示すフローチャートである。
【図４】本実施形態での受発注用ＡＳＰシステムの構成例を示すブロック図である。
【図５】本発明の第１実施例の構成例を示すブロック図である。
【図６】本実施例での品揃え単位の各ユーザとの関係を示す説明図である。
【図７】図６に示す各品揃えでのユーザと品番との関係を示す説明図である。
【図８】本実施例での各マスタの代表的項目例を示す説明図であり、図８（Ａ）は商品マスタの項目例を示す図で、図８（Ｂ）は品揃え単位マスタの項目例を示す図で、図８（Ｃ）は品揃えマスタの項目例を示す図である。
【図９】本実施例での各マスタの代表的項目例を示す説明図であり、図９（Ａ）はユーザ／品揃え単位マスタの項目例を示す図で、図９（Ｂ）は顧客／顧客フロント対応マスタの項目例を示す図で、図９（Ｃ）は商流管理マスタの項目例を示す図である。
【図１０】本実施例でのユーザの所属単位の例を示す説明図であり、図１０（Ａ）は請求先との関係を示す図で、図１０（Ｂ）は予算管理単位との関係を示す図で、図１０（Ｃ）は直送先との関係を示す図である。
【図１１】本実施例での各マスタの代表的項目例を示す説明図であり、図１１（Ａ）は顧客マスタの項目例を示す図で、図１１（Ｂ）はユーザマスタの項目例を示す図である。
【図１２】本実施例での代表的な動作例の前段を示す説明図である。
【図１３】図１２に続く代表的な動作例の後段を示す説明図である。
【図１４】本発明の第２実施例による品揃え関連情報登録処理の一例を示すフローチャートである。
【図１５】第２実施例による品揃え関連情報登録システムの構成例を示すブロック図である。
【図１６】第２実施例での品揃え関連情報検査システムの構成例を示すブロック図である。
【符号の説明】
１ 端末
２ ネットワーク（例えば、インターネット）
３ 商品マスタ
４ 品揃え関連マスタ
１０ サーバ
１２ データ送受信部
１４ 品別発注制御部
１６ 費目別発注制御部
１８ デリバ特定制御部
２０ 顧客フロントデータ出力制御部

Claims (5)

1. 販売店等の顧客フロントから顧客へ提供される商品又はサービス等の品目に関する情報を当該品目を識別する品番を単位として登録した商品マスタと、顧客フロント運営単位ＩＤにより運営単位が示される顧客フロントが顧客運営単位ＩＤにより示される顧客の購買単位に対して提案し顧客によって選定された品揃えを示す品揃え単位ＩＤ、前記顧客運営単位ＩＤ、前記顧客フロント運営単位ＩＤ、品番、商品又はサービスを前記ユーザに提供又は配送するデリバを示すデリバ運営単位ＩＤ、及び商品又はサービスをユーザに提供するサプライヤを示すサプライヤ運営単位ＩＤを対応付けて記憶している品揃え関連マスタとを記憶したデータベースと、ネットワークを介して所定の端末と接続され当該端末とのデータ送受信を制御すると共に前記端末からの要求に応じて前記各種マスタに対するデータの抽出又は登録をするサーバとを備え、前記品揃え関連マスタが、前記顧客の購買単位にて購入する品番が顧客フロント運営単位ＩＤで示される顧客フロント毎に重複しない状態で登録されたものであって、
   前記サーバが、前記購買単位に属するユーザによって使用される端末から一又は複数の品目を発注するための発注要求を受信したときに受信した顧客運営単位ＩＤ及び品番をキーとして前記品揃え関連マスタを参照することにより該顧客運営単位ＩＤ及び品番に対応する品揃え単位ＩＤを特定し、特定された品揃え単位ＩＤ及び受信した品番をキーとして前記品揃え関連マスタを参照することにより当該発注要求の各品番に対応する品目を提供する顧客フロントを顧客運営単位ＩＤで識別される顧客運営単位に所属するユーザへ品目の提供を契約した複数の顧客フロントのうちから唯一に特定する品目発注制御部と、受信した顧客運営単位ＩＤをキーとして前記品揃え関連マスタを参照することにより該購買単位に対応する品揃え単位ＩＤを特定し、特定された品揃え単位ＩＤ及び各品番に対応付けられたデリバ運営単位ＩＤ及びサプライヤ運営単位ＩＤを前記品揃え関連マスタ中から検索することによりデリバ及びサプライヤを特定するサプライヤ／デリバ特定部とを備えたことを特徴とする受発注システム。
2. 販売店等の顧客フロントから顧客へ提供される商品又はサービス等の品目に関する情報を当該品目を識別する品番を単位として登録した商品マスタと、顧客フロント運営単位ＩＤにより運営単位が示される顧客フロントが顧客運営単位ＩＤにより示される顧客の購買単位に対して提案し顧客によって選定された品揃えを示す品揃え単位ＩＤ、前記顧客運営単位ＩＤ、前記顧客フロント運営単位ＩＤ、品番、商品又はサービスを前記ユーザに提供又は配送するデリバを示すデリバ運営単位ＩＤ、及び商品又はサービスをユーザに提供するサプライヤを示すサプライヤ運営単位ＩＤを対応付けて記憶している品揃え関連マスタとを記憶するデータベースと、ネットワークを介して所定の端末と接続され当該端末とのデータ送受信を制御すると共に要求に応じて前記各種マスタからデータを抽出又は登録するサーバとを備えた受発注システムの前記サーバを使用して受発注を制御するための受発注用プログラムを格納する記憶媒体であって、
   前記プログラムが、前記サーバを、前記購買単位に属するユーザによって使用される端末から一又は複数の品目を発注するための発注要求を受信したときに受信した顧客運営単位ＩＤをキーとして前記品揃え関連マスタを参照することにより該顧客運営単位ＩＤに対応する品揃え単位ＩＤを特定し、特定された品揃え単位ＩＤ及び受信した品番をキーとして前記品揃え関連マスタを参照することにより当該発注要求の各品番に対応する品目を提供する顧客フロントを顧客運営単位ＩＤで識別される顧客運営単位に所属するユーザへ品目の提供を契約した複数の顧客フロントのうちから唯一に特定する品目発注制御部、及び受信した顧客運営単位ＩＤをキーとして前記品揃え関連マスタを参照することにより該購買単位に対応する品揃え単位ＩＤを特定し、特定された品揃え単位ＩＤ及び各品番に対応付けられたデリバ運営単位ＩＤ及びサプライヤ運営単位ＩＤを前記品揃え関連マスタ中から検索することによりデリバ及びサプライヤを特定するデリバ特定制御部として機能させることを特徴とする記憶媒体。
3. 販売店等の顧客フロントから顧客へ提供される商品又はサービス等の品目に関する情報を当該品目を識別する品番を単位として登録した商品マスタと、顧客フロントが運営単位に対して提案し顧客によって選定された品揃えを示す品揃え単位ＩＤ、前記顧客運営単位ＩＤ、及び顧客に品揃えの各品目を提供する顧客フロントの運営単位を示す顧客フロント運営単位ＩＤを対応付けて記憶している品揃え単位マスタと、前記品揃え単位ＩＤ、品番、商品又はサービスを前記ユーザに提供又は配送するデリバを示すデリバ運営単位ＩＤ、及び商品又はサービスをユーザに提供するサプライヤを示すサプライヤ運営単位ＩＤを対応付けて記憶している品揃えマスタと、前記顧客フロント運営単位ＩＤ、サプライヤＩＤ、前記デリバＩＤ、及び卸等の中間商流プレイヤを示す中間商流プレイヤ運営単位ＩＤを対応付けて記憶している商流管理マスタとを記憶したデータベースと、ネットワークを介して所定の端末と接続され当該端末とのデータ送受信を制御すると共に前記端末からの要求に応じて前記各種マスタに対するデータの抽出又は登録をするサーバとを備え、前記品揃え関連マスタが、前記顧客の購買単位にて購入する品番が顧客フロント毎に重複しない状態で登録されたものであって、
   前記サーバが、顧客運営単位ＩＤをキーとして前記品揃え単位マスタを参照し、該顧客運営単位ＩＤに対応する品揃え単位ＩＤ群を特定する品揃え単位群特定部と、前記品揃え単位群特定部によって特定された複数の品揃え単位ＩＤ中から前記ユーザから発注用に選択された品番をキーとして前記品揃えマスタを参照し該品番に対応する品揃え単位ＩＤを唯一特定し、この品揃え単位ＩＤをキーとして前記品揃え単位マスタを参照することにより前記品揃え単位ＩＤに対応する顧客フロント運営単位ＩＤを特定し顧客運営単位ＩＤで識別される顧客運営単位に所属するユーザへ品目の提供を契約した複数の顧客フロントのうちから唯一の顧客フロントを特定する顧客フロント特定部と、前記品揃え単位ＩＤをキーとして前記品揃えマスタを参照することにより各品番に対応付けられたサプライヤ及びデリバを特定するサプライヤ／デリバ特定部と、このサプライヤとデリバと顧客フロントとの組み合わせをキーとして前記商流管理マスタを参照してこれらに対応付けられた中間商流プレイヤ運営単位ＩＤを特定する商流制御部とを備えたことを特徴とする流通支援システム。
4. 前記サーバは、前記ユーザからアクセスされたときに当該ユーザを識別するユーザＩＤ及びパスワード並びに当該ユーザが所属する顧客運営単位ＩＤの入力を要求するログイン制御部を備え、前記品揃え単位特定部は、前記ログイン制御部による制御に応じて入力される前記顧客運営単位ＩＤをキーとして前記品揃え単位マスタを参照し、この顧客運営単位ＩＤに対応付けられた品揃え単位ＩＤを特定する機能を備えたことを特徴とする請求項３記載の流通支援システム。
5. 前記サーバは、前記ユーザによって発注される一又は複数の品目の品番を発注品番群として一時的に格納する制御をする発注制御部を備え、前記顧客フロント特定部は、前記発注制御部にて格納される発注品番群の品番をキーとして前記品揃えマスタを参照して該品番に対応付けられた品揃え単位ＩＤを特定し、さらにこの品揃え単位ＩＤをキーとして前記品揃え単位マスタを参照しこの品揃え単位ＩＤに対応付けられた顧客フロント運営単位ＩＤを特定することにより、当該品番の品揃え単位に基づいて顧客フロント群の内の唯一の顧客フロントを特定する機能を備えたことを特徴とする請求項３又は４記載の流通支援システム。

Images