JP3978991B2 - 受発注システム、及び記憶媒体 - Google Patents

Description

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

Claims (7)

1. 各種マスタを記憶したデータベースと、ネットワークを介して所定の端末と接続され当該端末とのデータ送受信を制御すると共に前記端末からの要求に応じて前記各種マスタに対するデータの抽出又は登録をするサーバとを備え、
   前記データベースが、顧客フロントから顧客へ提供される品目に関する情報を当該品目を識別する品番を単位として登録した商品マスタと、この商品マスタに登録された品目のうち前記顧客の購買単位且つ当該顧客へ前記品目を提供する顧客フロント毎に予め取り決められた取扱品目の一覧である品揃え関連情報を登録した品揃え関連マスタと、品揃え単位ＩＤ、振替元品番、振替先品番、及び判断処理区分を関連付けて記憶した品番振替判断マスタとを備え、前記品揃え関連マスタが、前記品揃え単位ＩＤ、顧客フロントＩＤ、顧客運営単位ＩＤ、及び品番振替自動実施レベルを関連付けて記憶した品揃え単位マスタと、品揃え単位ＩＤ、品番、振替ステータス、及び振替先品番を関連付けて記憶した品揃えマスタとをさらに備えると共に、
   前記サーバが、品揃え単位ＩＤをキーとして品揃え単位マスタに該品揃え単位ＩＤに関連付けられた品番振替自動実施レベルを参照し、少なくとも品番振替自動実施レベルが自動方式レベルであって振替先の品目の価格が振替元の品目の価格よりも低額となる場合に自動振替を行う判断処理区分を前記品揃え単位ＩＤ及び振替元品番に関連付けて前記品番振替判断マスタに登録するとともに品番振替自動実施レベルが自動方式レベルであって振替先の品目の価格が振替元の品目の価格よりも高額となる場合に品番振替を行わないと判定する品揃え関連情報別品番振替制御部と、自動振替を行う判断処理区分が登録されている場合、品揃え単位ＩＤと振替元品番とをキーとしこれらに関連付けて振替先品番及び振替実施中であることを示す振替ステータスを品揃えマスタに登録する自動振替制御部とを備えたことを特徴とする受発注システム。
2. 前記品揃えマスタが、提供価格算出方式区分をさらに関連付けて記憶しているとともに、前記品揃え関連情報別品番振替制御部は、少なくとも品番振替自動実施レベルが中間方式レベルであって前記品揃え単位ＩＤに関連付けられて品揃えマスタに記憶された前記提供価格算出方式区分が示す顧客への提供価格の決定方式が掛率である場合に自動振替を行う判断処理区分を前記品揃え単位ＩＤ及び振替元品番に関連付けて前記品番振替判断マスタに登録する機能を有することを特徴とする請求項１記載の受発注システム。
3. 前記サーバが、前記自動振替制御部による制御に応じて前記品揃え関連情報に振替先品番が定義されている品目が前記購買単位に属するユーザによって使用される端末から発注された場合には、当該振替先品番へ振り替えた品目を示す品番を前記顧客フロントＩＤが示す顧客フロントに備えた端末に送信する設定する品目振替部を備えたことを特徴とする請求項１又は２記載の受発注システム。
4. 前記データベースが、振替元品番及び振替先品番を関連付けて記憶する品番振替マスタをさらに具備するものであって、前記サーバが、品番振替の振替元の品番すなわち振替元品番と新しい品目である振替先の品番すなわち振替先品番とを前記品番振替マスタに登録する品番別品番振替登録制御部をさらに備えたことを特徴とする請求項１記載の受発注システム。
5. 各種マスタを記憶したデータベースと、ネットワークを介して所定の端末と接続され当該端末とのデータ送受信を制御すると共に前記端末からの要求に応じて前記各種マスタに対するデータの抽出又は登録をするサーバとを備え、
   前記データベースが、顧客フロントから顧客へ提供される品目に関する情報を当該品目を識別する品番を単位として登録した商品マスタと、この商品マスタに登録された品目のうち前記顧客の購買単位且つ当該顧客へ前記品目を提供する顧客フロント毎に予め取り決められた取扱品目の一覧である品揃え関連情報を登録した品揃え関連マスタと、品揃え単位ＩＤ、振替元品番、振替先品番、及び判断処理区分を関連付けて記憶した品番振替判断マスタとを備え、前記品揃え関連マスタが、前記品揃え単位ＩＤ、顧客フロントＩＤ、顧客運営単位ＩＤ、及び品番振替自動実施レベルを関連付けて記憶した品揃え単位マスタと 、品揃え単位ＩＤ、品番、振替ステータス、及び振替先品番を関連付けて記憶した品揃えマスタとをさらに備えた受発注システムを使用して品目の振替を制御するための品目振替制御用プログラムを記録したものであって、
   該品目振替制御用プログラムは、前記サーバを動作させる指令として、品揃え単位ＩＤをキーとして品揃え単位マスタに該品揃え単位ＩＤに関連付けられた品番振替自動実施レベルを参照し、少なくとも品番振替自動実施レベルが自動方式レベルであって振替先の品目の価格が振替元の品目の価格よりも低額となる場合に自動振替を行う判断処理区分を前記品揃え単位ＩＤ及び振替元品番に関連付けて前記品番振替判断マスタに登録するとともに品番振替自動実施レベルが自動方式レベルであって振替先の品目の価格が振替元の品目の価格よりも高額となる場合に品番振替を行わないと判定する品揃え関連情報別品番振替制御指令と、自動振替を行う判断処理区分が登録されている場合、品揃え単位ＩＤと振替元品番とをキーとしこれらに関連付けて振替先品番及び振替実施中であることを示す振替ステータスを品揃えマスタに登録する自動振替制御指令とを備えたことを特徴とする記録媒体。
6. 各種マスタを記憶したデータベースと、ネットワークを介して所定の端末と接続され当該端末とのデータ送受信を制御すると共に前記端末からの要求に応じて前記各種マスタに対するデータの抽出又は登録をするサーバとを備え、
   前記データベースが、顧客フロントから顧客へ提供される品目に関する情報を当該品目を識別する品番を単位として登録した商品マスタと、この商品マスタに登録された品目のうち前記顧客の購買単位且つ当該顧客へ前記品目を提供する顧客フロント毎に予め取り決められた取扱品目の一覧である品揃え関連情報を登録した品揃え関連マスタと、振替元品番及び振替先品番を関連付けて記憶する品番振替マスタと、品揃え単位ＩＤ、振替元品番、振替先品番、及び判断処理区分を関連付けて記憶した品番振替判断マスタとを備え、前記品揃え関連マスタが、前記品揃え単位ＩＤ、顧客フロントＩＤ、顧客運営単位ＩＤ、及び品番振替自動実施レベルを関連付けて記憶した品揃え単位マスタと、品揃え単位ＩＤ、品番、振替ステータス、及び振替先品番を関連付けて記憶した品揃えマスタとをさらに備え、
   前記サーバが、前記品揃え関連情報を前記品揃え関連マスタに登録する際に、当該顧客と顧客フロント間で予め定められた品番振替の自動実施レベルを、前記顧客フロントを示す顧客フロントＩＤ及び前記顧客の運営単位を示す顧客運営単位ＩＤに関連付けて品揃え単位マスタに格納する自動実施レベル格納制御部と、品番振替の振替元の品番と新しい品目である振替先の品番とを関連付けて前記品番振替マスタに登録する品番別品番振替登録制御部と、前記品番振替マスタに振替元及び振替先の品番が登録された後に、当該振替元の品番と関連付けられて品揃えマスタに記憶されている品揃え単位ＩＤを前記品番振替マスタに記憶されている振替元品番をキーとして前記品揃えマスタから抽出する振替対象品揃え関連情報抽出制御部と、この振替対象品揃え関連情報抽出制御部によって抽出された品揃え単位ＩＤに関連付けられて品揃え単位マスタに格納された自動振替実施レベルをキーとし、少なくとも品番振替自動実施レベルが自動方式レベルであって振替先の品目の価格が振替元の品目の価格よりも低額となる場合に自動振替を行う判断処理区分を前記品揃え単位ＩＤ及び振替元品番に関連付けて前記品番振替判断マスタに登録するとともに品番振替自動実施レベルが自動方式レベルであって振替先の品目の価格が振替元の品目の価格よりも高額となる場合に品番振替を行わないと判定する品揃え関連情報別品番振替制御部と、自動振替を行う判断処理区分が登録されている場合、品揃え単位ＩＤと振替元品番とをキーとしこれらに関連付けて振替先品番及び振替実施中であることを示す振替ステータスを品揃えマスタに登録する自動振替制御部とを備えたことを特徴とする受発注システム。
7. 前記品揃えマスタが、提供価格算出方式区分をさらに関連付けて記憶しているとともに、前記品揃え単位マスタに格納された品番振替自動実施レベルが、確認方式レベルと、中間方式レベルと、自動方式レベルのいずれかであり、確認方式レベルは、振替元と振替先の品目の前記顧客への提供価格が変化しない場合にのみ振替を自動的に行う場合の品番振替自動実施レベルで、中間方式レベルは、前記顧客への提供価格の決定方式として掛率と実額がある場合に、前記品揃え単位ＩＤに関連付けられて品揃えマスタに記憶された提供価格算出方式区分が示す当該決定方式が掛率であるときには振替元と振替先の品目の提供価格差にかかわらず自動振替を行う場合の品番振替自動実施レベルで、自動方式レベルは、前記顧客への提供価格の決定方式にかかわらず、振替先の品目の価格が振替元の品目の価格よりも低額となる場合には自動的に品番振替を行い、振替先の品目の価格が振替元の品目の価格よりも高額となる場合に品番振替を行わないと判定する品番振替自動実施レベルであることを特徴とする請求項６記載の受発注システム。

Images