JP3982168B2 - 購買管理システム、購買管理方法、及び購買管理用プログラム - Google Patents
購買管理システム、購買管理方法、及び購買管理用プログラム Download PDFInfo
- Publication number
- JP3982168B2 JP3982168B2 JP2000344735A JP2000344735A JP3982168B2 JP 3982168 B2 JP3982168 B2 JP 3982168B2 JP 2000344735 A JP2000344735 A JP 2000344735A JP 2000344735 A JP2000344735 A JP 2000344735A JP 3982168 B2 JP3982168 B2 JP 3982168B2
- Authority
- JP
- Japan
- Prior art keywords
- management
- item
- budget
- unit
- purchase
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
- G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
- G06Q10/0875—Itemisation or classification of parts, supplies or services, e.g. bill of materials
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/12—Accounting
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Economics (AREA)
- Strategic Management (AREA)
- Human Resources & Organizations (AREA)
- Entrepreneurship & Innovation (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Marketing (AREA)
- General Business, Economics & Management (AREA)
- Development Economics (AREA)
- Tourism & Hospitality (AREA)
- Quality & Reliability (AREA)
- Operations Research (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Game Theory and Decision Science (AREA)
- Educational Administration (AREA)
- Data Mining & Analysis (AREA)
- Technology Law (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、購買管理システムに係り、特に、品目の購買に関して予算、承認等の管理を行う購買管理システムに関する。
【０００２】
【従来の技術】
従来より、文具・工具などの消耗品（MRO: Maintenance, Repair and Operationsとも呼ばれる）や家具類などは企業等の組織で多種大量に消耗されている。これらの消耗品は、組織の事業運営に必要なものであり、その購入は予算や会計との関係で管理されている。消耗品や工具・家具類などは、事業活動や生産活動に間接的に必要となるものであるから、間接財や副資材とも呼ばれる。間接材の購買は少額で多頻度且つ多種膨大であり、購買先や購買条件も品目や地域ごとに異なっている場合が多く、その購買管理が煩雑である。
【０００３】
従来より、従業員が数百人に及ぶ大規模な組織では、一定期間で行われた見積合わせなどによって、販売店（顧客フロント）と顧客（企業などの組織）との間で取扱商品及び価格を定めておき、その取り決めに従った購買活動を行うことで、購買管理を簡略化することが図られている。そして、近年、購買管理、発注処理等をコンピュータを用いて行うことで、さらなる省力化を実現するための手法が種々提案されている。
【０００４】
特開平９−９７２８４号公報には、消耗品等の発注情報に基づいて各発注部門の発注金額を累計し、累計した発注金額が予め記憶した発注部門の予算限度額を超えていない場合に発注許可情報を出力する手法が開示されている。この公報では、複数の発注先（販売店）に発注を均等に分配する機能が開示されている。
【０００５】
特開２０００−７６３４２号公報には、複数の品目を選択した後に、その複数種類の物品の購買について費用の負担元、職場コード、勘定科目、費目、設備予算コード、希望納期、納入事業所等の情報を入力する手法が開示されている（段落「０１５６」）。そして、勘定科目、費目、費用負担元コード、設備予算コードの関係が予め定められたクロスチェックテーブルを使用する旨が開示されている（図２１）。
【０００６】
また、特開平７−２８９１２号公報には、購買に関して予算管理を行う部門を階層的に定義する旨が開示されている。特開平６−３４８７２９号公報には、伝票の種類に応じて承認の経路を特定する手法が開示されている。
【０００７】
【発明が解決しようとする課題】
上記各従来例では、個別の機能に応じた個々の作業は省力化されるものの、購買毎にその組織での経理や購買条件等に依拠した購買活動を行うには、各ユーザが種々の手引き等を参照したり、購買管理部門等へ問い合わせを行うなど、各ユーザが購買条件等を習得しなければならなかった。すると、購買管理システム等を導入しても、購買管理部門の日常的な業務負担が少なからず残ってしまう、という不都合があった。すなわち、上記各従来例やその組み合わせでは、必要とするユーザが必要な分だけ組織の購買条件や予算に応じて発注を行うという理想的な状態を構築しがたい。例えば、発注する品目について勘定科目や費目をユーザ本人が入力する従来例では、どの品目がどの勘定科目や費目（例えば、販促費、消耗品費、出張旅費等）に属するかを覚えるか又は購買要求（発注）に調べなければならない。また、複数の品目を選択した後にそれらが同一の勘定科目ではないことが明らかになると、品目の選択を最初からやり直さなければならない。
【０００８】
このように、上記各従来例や、各従来例の要素技術の組み合わせでは、組織に所属するユーザ本人がその組織の購買条件等を意識することなく、簡単に発注の要求（購買要求）及び発注を行うことができない。
【０００９】
また、予算管理や、品目の購入の承認や、品目の購入に関連する会計管理などの購買活動の管理については、組織内にて購買条件や購買方法を統一しておくと、承認や会計に関する人的コストの削減を図ることができる。しかし、間接材の購買は多頻度で且つ多種膨大であり、さらに品目の改廃が頻繁に行われることから、このような予算管理や管理会計を含めた購買管理を行うには、システム開発及び維持のコストや、運用に必要な人的コストが膨大となってしまう。すると、間接財の購買管理によってかえってコスト増となってしまう事態も想定され得る。
【００１０】
間接材及び副資材の購買活動及び管理については、事業活動及び生産活動に対して間接的な業務であるため、低コストで実施すべきであるが、従来例では、組織内での多大な人的コストを要している、という不都合があった。
【００１１】
これは、間接材等の購買や、その会計処理は、間接的な業務ではありながら、各種の税の納付のために必要な書類や、会計報告で必要な書類は必ず作成しなければならないため、企業にとって必須の活動であり、この必須の活動である点が、間接材の購買に関する「見えないコスト」削減をより一層困難にしている。すなわち、間接材の購買及びその会計処理等を一切廃止することはできず、従って、いかにしてコストを削減するかについての検討が必要となる。
【００１２】
一方、近年の経営では、事業部毎の会計や、社内カンパニー制や、分社化や、コストのみを生じさせる部門のアウトソースや、逆に、関連会社全体での連結決算の実施など、小さい部門毎の経費分担の明確化から、複数の会社に渡る単位での集計まで、種々の方向性から財務会計及び管理会計を実行すべき要望が強くなっている。そして、詳細な単位で管理会計を実行するには、発注の単位を小さくする必要がある。一方、発注の単位があまりに小さいと、例えば承認の作業数が増加するなど、購買活動自体があまりに煩雑となってしまう。
【００１３】
【発明の目的】
本発明は、係る従来例の有する不都合を改善し、特に、組織内での購買条件等をユーザが熟知する必要が無く、間接財の購買をそのユーザ自身が簡易に行うことのできる購買管理システムを提供することを、その目的とする。
また、本発明は、購買管理部門及びユーザの最小限の作業で、多種多様な品目の購買活動実績を種々の方向から分析・集計可能な購買管理システムを提供することを、その目的とする。
【００１４】
【課題を解決するための手段】
本発明では、データベースが、品目を他の品目から識別する品番及び該品目の価格を関連付けて記憶している商品マスタと、ユーザＩＤ、該ユーザＩＤが示すユーザが所属する運営単位を示す顧客運営単位ＩＤ、及び該ユーザＩＤが示すユーザが所属する予算管理単位を示す予算管理単位ＩＤを関連付けて記憶しているユーザマスタと、前記顧客運営単位ＩＤ、前記予算管理単位ＩＤ、及び当該予算管理単位ＩＤが示す予算管理単位にて使用可能な費目コードを関連付けて記憶している予算管理単位マスタと、品目を示す品番、その品目で使用可能な一又は複数の当該品目の区分又は用途を示す費目を示す費目コード、及び顧客フロントのユーザに対する品揃えを示す品揃え単位ＩＤを関連付けて記憶している品揃えマスタと、前記品揃え単位ＩＤ、前記顧客運営単位ＩＤ、及び顧客フロントの運営単位ＩＤを関連付けて記憶している品揃え単位マスタと、前記予算管理単位ＩＤ、費目コード、下限額、及び前記顧客の管理基準を関連付けて記憶している承認経路兼予算階層マスタと、前記予算管理単位ＩＤ、費目コード、承認用購買累計額、及び予算額を関連付けて記憶している予算枠・承認用累計管理マスタとを有し、サーバが、ユーザがログインした際にユーザマスタを参照してユーザＩＤ及び予算管理単位ＩＤを特定する手段と、複数種類の品目の購買要求がなされる場合に各品目に付された品番をキーとして品揃えマスタを参照して該品番に関連付けられている費目コードを特定するか又は前記手段により特定された予算管理単位ＩＤをキーとして予算管理単位マスタを参照することにより該予算管理単位ＩＤに関連付けられた費目コードを特定するともに買い物かごに蓄積し、この費目コード及び前記予算管理単位ＩＤをキーとして前記承認経路兼予算階層マスタを参照することにより当該購買要求がなされた各品目の管理基準を特定するとともに、品目を買い物かごに蓄積する毎に、既に買い物かごに蓄積された他の品目の管理基準と同一であるか否かを判定する管理基準特定部と、前記管理基準特定部によって判定される管理基準が同一であると前記管理基準特定部によって判定された場合に前記管理基準が示す予算管理単位ＩＤに対応する承認者端末に購買要求の承認を依頼する信号を発する機能、品目の価格を前記予算枠・承認用累計管理マスタにて前記予算管理単位ＩＤに関連付けられた承認用購買累計額に加算し、承認用購買累計額を前記予算枠・承認用累計管理マスタにて前記予算管理単位ＩＤに関連付けられた予算額と比較し、承認用購買累計額が予算額以下である場合には直ちに購買要求を許可したことを示す信号を発する機能、又は品目の価格が前記承認経路兼予算階層マスタにて前記予算管理単位ＩＤに関連付けられた下限額以下である場合には直ちに購買要求を許可したことを示す信号を発する機能と、買い物かごに蓄積した品目の管理基準が既に買い物かごに蓄積された他の品目の管理基準と同一でないと前記管理基準特定部によって判定された場合に購買要求の分割を促すための信号を発する機能とを有する管理処理制御部と、前記承認者端末又は前記管理処理制御部から購買要求を許可したことを示す信号が発された際に、前記品目ごとに該品目に関連付けられた品揃え単位ＩＤを前記予算管理単位ＩＤに関連付けられた顧客運営単位ＩＤ及び前記品番をキーとして前記データベースを参照して特定し、特定された品揃え単位ＩＤをキーとして前記データベースを参照し顧客フロントの運営単位ＩＤを特定し、特定された顧客フロントの運営単位ＩＤが示す顧客フロント毎に当該購買要求が行われたことを示す発注データを送信する分割発注制御部とを備えた、という構成を採っている。これにより前述した目的を達成しようとするものである。
【００１５】
本発明では、組織に所属するユーザから購買要求がなされ、この購買要求に応じて予算枠との関係での発注可否や承認等の購買管理処理を行い、この管理処理が完了した購買要求を発注データとして受注先（販売店等）に送信する。管理基準特定部は、購買要求として品目が選択される毎に、品目の費目に応じて承認経路や予算枠等の購買の管理基準を特定する。品目の費目は、例えば財務会計の勘定科目である。また、組織内のユーザの理解を助けるためにより簡略化した科目コードや、勘定科目の小分類を費目としても良い。管理基準分割制御部は、購買要求なされた各品目の管理基準が各品目間で異なる場合には当該購買要求を管理基準毎に分割する制御をする。従って、ユーザは、承認経路等の管理基準の枠を超えて一括して多種類の品目群の購買要求を行うことができる。管理基準が同一であるというのは、例えば承認経路が同一の場合や、予算枠が同一の場合や、承認を行わないという点で一致する場合などがある。続いて、管理処理制御部は、管理基準毎に分割された購買要求を受信すると共に当該購買要求についての管理処理の制御をする。この管理処理制御部の制御に応じた承認等が完了すると、分割発注制御部は、購買要求を品目別の発注先に分割して各発注先へ発注する制御をする。この発注は、発注書を印刷するようにしても良いし、またオンラインで発注データを各販売店（顧客フロント）に送信するようにしても良い。本発明では、購買要求を行う際に、当該品目の管理基準（例えば、承認経路）がどのようになっているかを予め知ることなく購買要求を行うことができ、さらに、管理基準や、発注先や品目の種別や費目にかかわらず一つの購買要求として取り扱うことができ、管理基準毎に分割され、さらに、承認等なされた購買処理要求は品目別に一又は複数の発注先へ自動的に分割して発注される。このため、ユーザは、管理基準や発注先を予め知る必要もない。
【００１６】
【発明の実施の形態】
＜第１実施形態： 購買管理システム＞
次に、本発明の一実施形態を図面を参照して説明する。図１は、本発明の一実施形態の構成を示すブロック図である。本実施形態による購買管理システムは、ユーザ端末１Ａから複数種類の品目の購買要求がなされる場合に品目が選択される毎に当該品目に定義され当該品目の区分又は用途を示す費目に応じて当該購買要求の管理基準を特定する管理基準特定部２０と、購買要求なされた各品目の管理基準が異なると前記管理基準特定部によって判定された場合には当該購買要求を管理基準毎に分割する制御をする管理基準分割制御部１９と、
この管理基準分割制御部１９によって管理基準毎に分割された購買要求を受信すると共に当該購買要求についての管理処理の制御をする管理処理制御部２１と、この管理処理制御部によって購買要求が許可されたときに当該購買要求を品目別の発注先毎に分割して発注する制御をする分割発注制御部２２と、この分割発注制御部２２によって発注された発注データを当該発注の費目等の属性に応じて集計する発注集計処理部２３とを備えている。
【００１７】
また、図１に示す例では、管理基準特定部２０が、ユーザが所属する予算管理単位と費目とに応じて前記管理基準を特定するユーザ所属別管理基準特定機能２０Ａや、一又は複数の予算管理部門を特定する予算管理単位ＩＤ又は予算と承認とを管理する複数の予算・承認管理部門を特定する予算管理単位ＩＤを前記管理基準として特定する経路特定機能２０Ｂを備えている。ユーザ所属別管理基準特定機能２０Ａにより、製造部門であるか否かや、販売促進費を用いる部門であるか否か等に応じて使用可能な費目をユーザの予算管理単位（購買管理上の所属）に基づいて定義することができる。
【００１８】
購買管理としては、予算管理のみを行う場合と、承認付きで予算管理を行う場合とがある。経路特定機能２０Ｂは、予算管理のみを行う例では、一又は複数の予算管理部門を特定する予算管理単位ＩＤを管理基準として特定する。また、承認及び予算管理を行う例では、予算と承認とを管理する複数の予算・承認管理部門を特定する予算管理単位ＩＤを前記管理基準として特定する。予算管理単位ＩＤは、一般には組織の部門名を特定する。予算管理単位ＩＤを階層的に特定することで、承認経路等を特定することができる。
【００１９】
本実施形態では、管理基準分割制御部１９が、購買要求なされた各品目の管理基準が異なると前記管理基準特定部によって判定された場合には当該購買要求を管理基準毎に分割する制御をするため、従って、ユーザは、承認経路等の管理基準の枠を超えて一括して多種類の品目群の購買要求を行うことができる。また、分割発注制御部２２が、管理基準毎に分割された購買要求をさらに発注先毎に自動的に分割して発注する制御をする。このため、ユーザは、承認経路や予算枠管理部門等の管理基準や、発注先等の組織内の購買条件を予め知ることなく、必要な物を１回の操作で一括して発注（購買要求）することができる。
【００２０】
「費目」は、財務会計での勘定科目や、予算管理で用いる品目の区分など購買管理上品目をグループ分けする概念である。一般的には、品目が特定されると費目も唯一に特定される。しかし、例えば販売の促進を目的とした展示会で使用する文具を購入した場合には、消耗品費ではなく販売促進費となる。また、家具についても、同一の品目であっても一定額以内は消耗品費となり、一定額以上は備品費となり、さらに耐用年数及び購入金額によっては工具・器具・備品（固定資産）となる。文具のうち、工具としても利用されるものは、購入部門が製造部門であるか否かで費目が異なることもある。本実施形態では、ユーザの属する予算管理単位と、品目群とに使用可能な費目を定めておき、購買要求での品目の選択を受信する際にこの使用可能な費目をユーザに表示し、選択を促す。
【００２１】
図２は、ユーザ等と費目との関係を示す説明図である。図２（Ａ）に示すように、ユーザは本来の所属部門がある。一方、予算枠は、プロジェクト毎に部門に横断して定められたり、また、製造部門、総務部門等の相違に応じて異なる予算枠とすることもある。その組織（会社等の運営単位）での予算枠の設定が純粋な部門毎ではなく、プロジェクト毎や、地域ごととなっている場合には、予算管理単位は所属部門の階層とは異なる。図２（Ｂ）に示す例では、説明のために、所属部門と予算管理単位とを異なるグループとしている。所属部門（０２）のユーザ（０４）は、販売促進の担当者であるとする。
図２（Ｂ）に示す例では、予算管理単位毎に使用可能な費目を定義している。また、図２（Ｃ）に示す例では、品目群毎に使用可能な費目を定義している。本実施形態では、この予算管理単位が特定された場合に使用可能となる費目と、品目群が特定されたときに使用可能となる費目と併用する。好ましい例では、ユーザによって品目が特定された場合に初期設定された費目を表示し、且つ、そのユーザが所属する予算管理単位や、その選択された品目に別の費目が定義されている場合には、この費目も選択可能とする。
品目群（０１）がファイリング用品や、鉛筆等の文具消耗品を含むとする。図３（Ａ）に示すように、ユーザ（０１）等の通常のユーザはこれを消耗品費として購入する。この場合、図２（Ｃ）に示す品目群（０１）に定義された費目を用いる。一方、販売促進の担当者であるユーザ（０４）は、ファイリング用品等を、組織内で消費する消耗品としてではなく、例えばショールームの展示品に関する費用である販売促進費（販促費）という費目コードで購入することもできる。この販促費は、図２（Ｂ）に示す予算管理単位（０２）に定義された費目コードである。このように、ユーザ又はユーザ群である予算管理単位に定められた費目コードと、品目群に定められた費目コードとを用いることで、同一品目に関する複数種類の費目コードを使い分けることができる。さらに、品目の内容による費目コードを品目群に、用途による費目コードを予算管理単位に定義することで、原則的な費目と例外的な費目とをユーザ別に使い分けることができる。
【００２２】
再度図１を参照すると、本実施形態による購買管理システムは、品目の購買要求を行うユーザ毎に当該ユーザが購買可能な品目群を特定すると共に当該購買可否に応じて各ユーザ毎に品目の閲覧を制御する品目閲覧制御部１８を備えている。品目閲覧制御部１８は、ユーザ毎に発注可能な品目を制御する機能である。例えば、図３（Ｂ）に示すように、ユーザＡ，Ｂは品目群（０１）のみを発注でき、ユーザＣは品目群（０１），（０２），（０３）の全ての品目を発注でき、ユーザＤは品目群（０１）と品目群（０２）の発注ができる。品目閲覧制御部１８は、ユーザＡから購買要求がなされる場合に、品目群（０２）等を品目選択画面等に表示しないか、または、閲覧のみとして購買要求の選択を付加とする制御をする。
【００２３】
図３（Ｂ）に示す例では、品目閲覧制御部１８は、各ユーザ又はユーザ群毎に定められた品揃えを特定する品揃え関連情報に基づいて前記ユーザ毎の購買可否を判定する機能１８Ａを備えている。すなわち、ユーザと品目群との関係を予め定義する。費目コードは、品目又はユーザの予算管理単位に定義する。これにより、品目閲覧制御と、ユーザの用途別の費目コードを実現する。図３（Ｂ）に示す例では、ユーザＡは品目群（０１）を消耗品費としてのみ購入でき、一方、ユーザＢは品目群（０１）を販促費又は消耗品費として購入できる。品目閲覧制御部１８の機能により、ユーザＡおよびＢは、品目群（０２），（０３）にはアクセスできない。
【００２４】
図３（Ｃ）に示す例では、品目閲覧制御部１８は、前記各ユーザ又はユーザ群毎に予め定められた購買可能な費目に基づいて前記ユーザ毎の購買可否を判定する機能１８Ｂを備えている。図３（Ｃ）に示す例では、ユーザは費目コードと結びつけられている。消耗品費での購入は全てのユーザが可能で、備品費での購入はユーザＣのみが可能となる。費目コードは商品のカテゴリでもあるため、図３（Ｃ）に示す例では、各費目コードに品目群を定義している。これにより、品目閲覧制御部１８は、各ユーザ別に購買可能な品目を制御する。この場合、ユーザＢは販促費を介して品目群（０１）にアクセス可能に定義することで、ユーザ毎の費目を実現する。
【００２５】
図１に示す例では、管理基準特定部２０は、ユーザからの購買要求される品目の指定を受信する毎に、当該品目の費目に応じて当該品目の購買管理基準を特定する。管理基準特定部２０は、ユーザの所属部門名と費目とに基づいて管理基準を特定するようにしても良い。「管理基準」は、例えば予算枠や、承認者である。階層的な承認や予算管理を行う場合には、承認経路や予算管理階層が管理基準となる。ユーザによって品目が選択されてから、電子的な買い物かご等に一時的に蓄積するまでにこの管理基準を特定すると良い。
【００２６】
管理基準特定部２０は、品目を買い物かごに蓄積する毎に、既に買い物かごに蓄積された他の品目の管理基準と同一であるか否かを判定する。管理基準が同一の場合には買い物かごに蓄積された購買要求をそのまま一括して承認処理や予算管理処理に入力する。一方、管理基準別分割制御部１９は、買い物かごに蓄積された品目群が複数の管理基準に属する場合には、購買要求された品目群を各管理基準毎に分割する。
【００２７】
例えば、図３（Ｄ）に示すように、ある部門に新人が配属され、その新人用に鉛筆等の消耗品と、デスクと、パーソナルコンピュータ（ＰＣ）及びコンピュータ関連の消耗品とを購入する。ユーザＣは、消耗品費、備品費、理化学機器の全ての品目が購買可能であるため、図３（Ｄ）に示すように、管理基準や販売店にかかわらず必要な全ての品目を一度に一括して購買要求を行う。そして、消耗品費が管理基準１に属し、備品費及び理化学機器が同一の管理基準２に属するとする。管理基準別分割制御部１９は、購買要求された複数の品目群を、図３（Ｄ）に示すように、管理基準毎に分割する。
【００２８】
管理基準毎に分割された購買要求は、管理所里制御部２１の制御に従って、それぞれの管理基準にて予算執行や承認等の管理処理が行われる。管理処理が完了すると、分割発注制御部２２は、購買要求を発注先毎に分割して発注する。例えば、デスクとＰＣとは異なる発注先に発注する場合には、分割発注制御部２２は、管理基準２の購買要求をさらに分割して各販売店に発注する。
【００２９】
このように、本実施形態では、購買要求者は自らが発注できる品目を予め知ることなく、発注可能な品目のみを購買要求することができ、さらに、販売店や管理基準にかかわらず必要な物を一括して購買要求することができる。一方、承認者側でも、管理基準を最大枠として分割された購買要求の承認を行うため、１つ１つの品目を個別に承認する必要が無く、一括して承認を行うことができる。さらに、販売店毎に自動的に分割して発注なされるため、購買担当者によらず予め販売店毎に定められた購買契約等に基づいた発注を行うことができる。また、管理基準や発注先にかかわらず一括した購買要求を行うため、その購買要求を行った品目が全て納品されたか否か等の検収作業を行いやすくなる。
【００３０】
本実施形態では、当該管理基準の枠を用いて購買要求を分割することで、複数種類の品目を一体的に承認又は予算執行することができ、各品目を個別に承認等の管理をすることと比較して、承認回数等の購買管理に必要な作業量を減らすことができる。このようにユーザ及び購買管理部門の利便性を向上させる一方、実際の発注については、発注先毎に分割して発注する。従って、例えば文具と書籍とを一体的に承認処理を行い、続いて文具店と書店とに自動的に発注データを分割して発注することができる。承認経路や予算枠等の管理基準を単位として異なる種別の品目であっても一体的に購買の管理処理を行うことで、煩雑な承認処理の回数（頻度）を減少させることができる。さらに、発注データの発注先毎への自動的な分割処理により承認等の購買管理と、実際の発注との大きさ、範囲を異なるものとして取り扱うため、購買管理の局面では承認回数等を減少させるために比較的多種類の品目を一体的に扱い、一方、発注先への発注については各受注者毎の個別の発注として取り扱うことができる。
【００３１】
管理基準特定部２０は、品目の費目を用いて管理基準を特定する。この費目を用いて管理基準を特定するために、まず品目に対応する費目を特定する。図１に示す例では、サーバ１０は、品目の購買要求を行うユーザが所属する予算管理単位に定義された費目コードと、前記品目の商品カテゴリ又は価格決定区分毎に定められた費目コードとを当該購買要求時に選択可能に表示する費目コード表示制御部２４と、この費目コード表示制御部２４によって表示される選択可能な一又は複数の費目コードのうち前記ユーザによって購買要求がなされる時に選択される費目コードを当該品目の費目として前記管理基準特定部２０に入力する購買要求時費目特定部２６とを備えている。
【００３２】
費目を特定する要素としては、品目と、ユーザの所属部門と、ユーザの所属する予算管理単位（工場等の製造現場であるか等）と、その品目の用途（販促用や広告用であるか等）などによって定まる。例えば販促用に文具類を購入する場合、その品目の費目が販売促進費であるのか消耗品費となるかは事前に特定することができない。
【００３３】
費目コード表示制御部２４は、品目の商品カテゴリ又は価格決定区分毎に定められた費目コードとを当該購買要求時に選択可能に表示する。価格決定区分は、購買管理システム内で商品を分類するために用いられることがあるため、この価格決定区分と費目を対応させるようにしても良い。例えば、購買管理システムが他のシステムで管理される品目を提供する場合には、その他のシステムでの価格から本システムでの価格を算出する。この他のシステムとの連携では、品目の価格を決定するための区分コード等を用いる。このような場合には、この価格決定区分コードと費目を関連させることで、予め各品目に費目を付することができない場合であっても、各品目に費目を定義することができる。
【００３４】
ここでは、費目コード表示制御部２４は、ユーザが購買要求を行う際に、品目別や、ユーザの所属する予算管理単位（例えば、所属部門や、所属プロジェクト）毎に定まる費目を当該ユーザに通知する制御を行う。費目コード表示制御部２４は、例えばポップアップメニューの形式で費目を表示させるようにしても良い。そして、ユーザは、購買要求時にこの費目コード表示制御部２４によって表示制御される一又は複数の費目から、当該購買要求での費目を選択する。購買要求時費目特定部２６は、費目コード表示制御部２４によって表示される選択可能な一又は複数の費目コードのうち前記ユーザによって購買要求がなされる時に選択される費目コードを当該品目の費目として前記管理基準特定部２０に入力する。費目が特定されると、ユーザが属する予算管理単位と費目とを用いて予算枠や承認経路等の購買管理基準を特定する。書籍の費目が雑費で、文具の費目が消耗品費である場合であっても、管理基準は同一であることもある。従って、費目が異なる場合であっても、管理基準が同一であれば、一括した購買要求が可能である。品目等から直接管理基準を特定せず、一旦費目を特定するのは、購買実績の財務会計でこの費目が必要となるためである。
【００３５】
図４は、購買の管理基準の一例を示す説明図である。ある企業Ａ（運営単位）の部門は三階層となっている。そして、図４（Ｂ）に示すように予算の階層が費目別に定められている。例えば、マーケティング部の企画課は、消耗品はマーケティング部の予算枠での購買で、備品費は総務部での予算枠での購買となる。企画課ユーザＡが鉛筆を消耗品費（自社消費）で購入する場合、一般的には企画課内の承認で発注に至る。予算枠は、図４（Ｂ）に示すようにマーケティング部となる。販促課のユーザＢが鉛筆を販促費として購入する場合、販促費は購買額が大きくなるため、１階層上位の部門（ここでは、マーケティング部）の承認を要することが多い。また、一定額以内であれば承認不要で発注でき、一定額を超える場合に承認が必要としても良い。
【００３６】
第１課のユーザＣが家具を備品費で購入する場合、第１課、関東営業部、そして総務部の承認を経て発注される。備品費等は、各部門ではなく、総務部の管轄とされることが多い。図４（Ｂ）に示すように、総務部を予算枠管理部門としつつ、承認を行わない営業本部の予算とすることもある。このような階層的な承認の場合には、費目とその費目毎に定められた購買上限金額等に基づいて何階層までの承認が必要かを判定するようにしても良い。
【００３７】
図５は発注集計処理部２３による購買実績の集計例を示す説明図である。図５に示す例では、費目と予算管理単位毎に購買実績を算出した。家具という費目は設備費に含まれる。文具消耗品は、消耗品費に含まれる。図５に示すように、例えば第１課の２０という購買実績は、関東営業部の購買実績の７０に含まれる。この関東営業部の購買実績は営業本部の１００に含まれる。図５に、全部門の家具（備品費）の購買実績を総務部に集計した例を示す。
【００３８】
図６は、図１に示した購買管理マスタ等の項目例を示す説明図である。ユーザには、ユーザＩＤが付される。ユーザＩＤ毎に、そのユーザが属する企業または企業の部門を識別する運営単位ＩＤと、ユーザ名と、発注した際の送り先となる直送先ＩＤと、請求先の部門名等を識別する請求先ＩＤと、このユーザが所属する予算管理単位を識別する予算管理単位ＩＤと、システムへのログインに必要なパスワード等を有する。図６に示す例では、商品マスタは、品目を他の品目から識別する品番と、その品名と、価格とを有する。そして、その品目で使用可能な一又は複数の費目が定義されている。品目に複数の費目を付するのは、例えば階層的な費目コードを用いる場合に好適となる。例えば、書庫類、家具、備品費等の階層的な費目などを用いる場合には、品目に複数の費目を定義すると良い。
【００３９】
また、図６に示す例では、費目関連マスタ１７には、予算管理単位ＩＤと、品目群（商品カテゴリや、商品の価格決定方式など）を識別する品目群ＩＤとを用いて特定される費目が定義されている。この例では、膨大な種類の品目を扱う場合に、品目をグループ分けし、さらに品目群と予算管理単位とを用いて当該予算管理単位に属するユーザが当該品目群に含まれる品目に使用できる一又は複数の費目を定義する。品目群と予算管理単位とを用いて費目を定義するのは、例えば本実施形態による購買管理システムにて直接管理しない品目で、予め全品目に費目コードを付することができない場合であっても、費目コードを定義することができる。従って、例えば、他のシステムとの連携によって品目を購入又は販売する場合などであっても費目コードを付した購買が可能となる。すると、本実施形態による購買管理システムを用いて、すべての間接財の購買を行うと、購入した全ての品目に予め体系づけた費目コードを付することができる。
【００４０】
これらの費目は、本システムの導入時に購買管理担当者と会計担当者等との指定に応じて定められる。購買管理担当者等は、図６に示すデータベースに費目に関するデータを品目毎または予算管理単位毎に定義しておくことで、その後の実際の購買がなされる局面では費目を特定するための作業が不要となる。
【００４１】
購買管理マスタは、予算管理単位ＩＤと費目コードとを用いて図４（Ｂ）に示すような購買の管理基準を定める。承認・予算管理フラグは、予算管理のみを行うか、それとも承認と予算管理の双方を行うかを予算管理単位毎に識別するためのフラグである。このフラグを用いることで、例えば文具と書籍については承認を行わず、家具と理化学機器（コンピュータ等）については承認を行う等の処理が可能となる。承認方式区分は、例えば、下限方式と、累計方式と、下限＆累計方式とがある。下限方式は、階層的な承認経路が定められている場合に、各階層のみで決済可能な購買額（の上限）を定める手法である。累計方式は、例えば予算枠が定められていて、累計した購買実績が予算枠を超えてしまう購買要求がなされた場合にその予算枠管理部門の承認者の承認を必要とする方式である。下限＆累計方式では、通常は下限方式で行い、予算枠を超えた場合に累計方式とする手法である。
【００４２】
図６に示すように、購買管理マスタは、第１階層予算管理単位ＩＤと、第２階層予算管理単位ＩＤと、最終階層予算管理単位ＩＤ（予算枠管理部門ＩＤ）とを有する。この各予算管理単位を展開すると、例えば図４（Ｂ）に示す構造となる。そして、各予算管理単位毎に、下限額情報や、承認者を識別する情報や、累計金額（購買実績）情報等を格納する。
【００４３】
図７は、本実施形態での購買管理処理例を示すフローチャートである。ユーザがパスワードを用いて購買管理システムにログインする。すると、ユーザＩＤと予算管理単位ＩＤが定まる。ユーザＩＤが定まると、まず、ユーザ別の閲覧（発注）可能品目を特定する（ステップＳ１，品目閲覧制御工程）。続いて、当該ユーザが購買可能な品目のうち、ユーザが必要とする品目の全てを一括した購買要求を受信する（ステップＳ２）。購買要求を受信すると、各品目の管理基準（例えば、承認経路や予算枠等）を展開する（ステップＳ３，管理基準特定工程）。ステップＳ２で受信した購買要求の各品目が複数の管理基準に属する場合には、各品目を管理基準毎に分割する（ステップＳ４，管理基準別分割工程）。そして、管理基準毎に分割された各購買要求の購買管理処理を制御する（ステップＳ５，管理処理制御工程）。
購買管理処理が完了し、発注が許可された場合には、購買要求を品目別の発注先毎に分割して発注する制御をする（ステップＳ６，分割発注制御工程）。発注先の特定は、例えば各品目に唯一の発注先（販売店）を特定するようにしても良いし、また、同一品目について複数の発注先が有る場合には一定の条件に基づいて発注先を選択するようにしても良い。発注の形態としては、単純に発注書を印刷するのみとしても良いし、また、ネットワークを介してオンラインで発注データを送信するようにしても良い。発注データ又は発注書の項目には、図６に示すユーザマスタ５２等を参照して納品や請求に関する項目を含めると良い。
このような発注が行われたのち、ユーザの所属部門や、各予算管理単位や、費目等に応じて購買実績を集計する（ステップＳ８，発注集計処理工程）。
【００４４】
図１に示す構成や、図６に示す処理は、サーバ１０のＣＰＵを動作させる購買管理用プログラムを用いて実現することができる。この購買管理用プログラムは、サーバ１０を動作させる指令として、複数種類の品目の購買要求がなされる場合に品目が選択される毎に当該品目又は前記購買の管理単位に定義され当該品目の区分又は用途を示す費目に応じて当該購買要求の管理基準を特定させる管理基準特定指令と、購買要求なされた各品目の管理基準が異なると前記管理基準特定指令に応じて判定される場合には当該購買要求を管理基準毎に分割する制御をさせる管理基準分割制御指令と、この管理基準別分割制御指令に応じて管理基準毎に分割される購買要求を受信させると共に当該購買要求についての管理処理の制御をさせる管理処理制御指令と、この管理処理制御指令に応じて購買要求が許可されるときに当該購買要求を品目別の発注先毎に分割して発注する制御をさせる分割発注制御指令と、この分割発注制御指令に応じて発注される発注データを当該発注の費目等の属性に応じて集計させる発注集計処理指令とを備えると良い。
【００４５】
ここで、管理基準特定指令等が、サーバ１０を「動作させる」というときには、各指令のみでサーバ１０のＣＰＵを動作させる指令と、演算装置に予め格納されているオペレーティングシステムやデータベース駆動プログラム等の他のプログラムに依存して当該コンピュータを動作させる指令とのいずれかまたは双方を含む。例えば、図１に示す例では、管理基準特定指令を、サーバ１０に予め格納されたデータベース駆動用プログラムによるデータベース検索機能に依存して、当該検索機能に購買管理マスタ１６等に予算管理単位や費目コード等の検索項目を引き渡す指令としても良い。このように、当該品番振替制御用プログラムや、受発注システム用プログラムを記憶する記憶媒体であって、当該プログラムをユーザへ搬送する用途の記憶媒体には、例えば「データベースサーバにマスタ名と項目名を引き渡す指令」のみが格納される場合がある。これは、動作させようとするコンピュータのオペレーティングシステムやサーバ用プログラム等との関係で定る。
【００４６】
購買管理用プログラムは、可搬性のある記憶媒体１１Ａに格納されて当該コンピュータに供給される。図１に示す例では、ディスクドライブ１１は、ＣＤＲＯＭ等の記憶媒体１１Ａを駆動し、記憶媒体１１Ａに格納された購買管理用プログラムをサーバ１０の管理下のハードディスク等に実行可能な状態で格納する。また、ネットワークを介してサーバのハードディスク等に直接転送するようにしても良い。
【００４７】
＜第１実施形態の変形例＞
次に、図１及び図８を参照して本実施形態の変形例を説明する。この変形例では、管理基準が同一となる範囲で購買要求を受信し、管理基準が異なる場合には異なる購買要求とするようにユーザに促す機能を備える。この変形例による購買管理システムは、複数種類の品目の購買要求がなされる場合に品目が選択される毎に当該品目に定義され当該品目の区分又は用途を示す費目に応じて当該購買要求の管理基準を特定する管理基準特定部２０と、この管理基準特定部２０によって特定される管理基準が同一である場合に複数種類の品目の一括した購買要求を受信すると共に当該購買要求についての管理処理の制御をする管理処理制御部２１と、分割発注制御部２２と、発注集計処理部２３とを備える。分割発注制御部２２と発注集計処理部２３は上述した実施形態と同様である。
【００４８】
管理基準特定部２０は、ユーザが所属する予算管理単位と費目とに応じて前記管理基準を特定するユーザ所属別管理基準特定機能２０Ａや、一又は複数の予算管理部門を特定する予算管理単位ＩＤ又は予算と承認とを管理する複数の予算・承認管理部門を特定する予算管理単位ＩＤを前記管理基準として特定する経路特定機能２０Ｂを備えている。
【００４９】
この変形例では特に、管理処理制御部２１が、経路特定機能２０Ｂによって特定される予算管理単位ＩＤの階層が同一である場合に複数種類の品目を一括して当該予算管理単位ＩＤでの予算処理又は予算・承認処理を実行する経路別実行機能２１Ａと、前記予算管理単位ＩＤの階層が異なる品目の購買要求に対しては前記ユーザに購買要求の分割を促す経路別分割依頼制御機能２１Ｂとを備えている。例えば、費目１が付される品目と、費目２が付される品目とが同一の承認経路である場合には、経路別実行機能２１Ａは、この品目を一括して購買上の管理処理を実行する。購買の管理処理は、例えば予算との比較による購買の可否の判定や、承認者端末１Ｂへの承認依頼等である。一方、経路別分割依頼制御機能２１Ｂは、予算管理単位ＩＤの階層が異なる品目の購買要求に対しては前記ユーザに購買要求の分割を促す。すなわち、複数種類の品目を一括した購買要求とできる範囲は同一承認経路の範囲内であって、経路別分割依頼制御機能２１Ｂは、承認経路の異なる品目が選択された場合にはその品目は別途購買処理要求を生成するように促す。
【００５０】
図８は、本変形例での動作例を示すフローチャートである。サーバ１０は、商品マスタを参照して、購買要求可能な品目の検索等のサービスを提供する。検索された品目情報には、使用可能な費目コードを付加する。費目コードと共に購買要求を受信すると（ステップＳ１１）、当該購買要求の管理基準を特定する（ステップＳ１２，管理基準特定工程）。例えば、図６に示す購買管理マスタ１６を用いて図４（Ｂ）等に示す予算階層・承認経路を展開する。
続いて、既に選択されている品目と管理基準（承認経路等）が同一であるか否かを判定し（ステップＳ１３）、管理基準が同一の場合には、複数種類の品目の一括した購買要求を受信し（ステップＳ１５）、当該購買要求についての管理処理の制御をする（ステップＳ１６，管理処理制御工程）。管理処理は、承認・予算管理フラグや承認方式区分を参照して予め定められた予算管理や承認制御を行う。一方、ステップＳ３にて、既に選択されている品目の管理基準と異なる管理基準であることが判明すると、その品目の追加を付加として別途の購買要求をユーザに促す。承認等が完了し発注可能な状態となると、購買要求を発注先毎に分割して発注する（ステップＳ１７）。さらに、各種の集計を行う（ステップＳ１８）。
【００５１】
＜第１実施形態の実施例： 流通支援システム＞
次に、購買管理システムを購買管理部として一部に含む流通支援システムを開示する。流通支援システムでは、複数の組織（発注者）と、複数の販売店（受注者、顧客フロント）と、品目の製造又は提供を行うサプライヤとを結び付ける。そして、発注者側では購買対象とする品目の一覧情報等の作成やメンテナンスを行わない。発注者となる組織が本実施例によるシステムを導入する際に、購買対象とする品目の一覧（品揃え）とその費目とを販売店等と共に検討する。続いて、費目と予算管理単位とをキーとして承認経路等の購買管理を特定する。この導入時の作業によって、実際の運用開始後は購買管理部門の担当者が個別に費目や管理基準等を組織内の各ユーザに示唆する必要性が少なくなる。
【００５２】
すなわち、本実施例による流通支援システムを用いると、組織内の購買管理と、購買実績の集計（財務会計及び管理会計）と、発注先の自動選定及び自動発注と、予め指定した部門等への納品とが自動的に行われる。また、顧客フロントやサプライヤにとっても、一定の形式で発注情報を受信できるため、製造や流通の最適化を行いやすい。さらに、発注情報を記憶しておき、顧客フロントから発注者への請求や、発注者となる組織での検収等を同一のデータを用いることができるため、検収や請求書の確認などの作業の省力化を図ることができる。本実施例では、発注者となる組織を顧客と呼ぶ。
【００５３】
図９は、本実施例で用いる品揃え関連情報とユーザとの関係を示す説明図である。図９に示すように、顧客のユーザ群（運営単位又は購買単位）と、顧客フロントとは、品揃え関連情報で結びつけられている。品揃え関連情報は、ユーザ群毎にそのユーザが購買可能な品目の一覧を特定するための情報である。そして、品目毎の費目コードは、この品揃え関連情報に定義する。また、品揃え関連情報を顧客フロント（販売店）毎に作成することで、品揃え関連情報を特定することによって顧客フロントを唯一のものとして特定することができる。品目の紹介画像などは、品揃え関連情報ではなく、流通支援システムの商品マスタや、ネットワークを介して接続される他サイトの商品マスタに格納しておいても良い。
【００５４】
品揃え関連情報での品揃えに含まれる品目は、商品マスタ３に登録されている品目である。商品マスタと、ユーザ群及び顧客フロント別に登録する品揃え関連情報とを用いることで、各品目に関する情報の登録及び更新は商品マスタにて一度のみ行うこととした。図９に示す例では、顧客フロント（０１）は、顧客（０１）に対して、ユーザ群別に２つの品揃え関連情報（０１，０２）を有している。顧客フロント（０２）は、顧客（０１）に対して、一つの品揃え関連情報（０３）を有している。
【００５５】
顧客（０１）のユーザ群（０１）は、顧客フロント（０１）の品揃え関連情報（０１）で品揃えされている品目と、顧客フロント（０２）の品揃え関連情報（０３）で品揃えされている品目とについて流通支援システムによる購入を行うことができる。同一のユーザ群（０１）に対する２つの品揃え関連情報（０１，０３）にて、同一品目が重複しないように品揃え関連情報を定義すると良い。同一ユーザ群に対する複数の品揃えにて品目の重複が存在しないと、ユーザが品目を特定したときにその品目を品揃えしている顧客フロントを唯一に特定できる。このユーザ群（顧客購買単位）と品目とが特定されたときに、顧客フロントを自動的に特定できる構成とすると、品目毎の発注先や商流の切り分けを行うことができる。例えば、顧客の購買単位に所属するユーザが本実施例による流通支援システムにログインし、購入を希望する品目を特定すると、品揃え関連情報は、同一のユーザに対して顧客フロント間で同一品目が重複しないように登録されているため、このユーザと品目とから品揃え関連情報を唯一のものとして特定できる。従って、ユーザと品目とが定まると顧客フロントを唯一のものとして特定することができる。このため、ユーザは、品目を特定するのみで、顧客フロントを選定する必要がない。すると、ユーザは、その顧客の購買管理部門が予め定めた顧客フロントに対して、その顧客フロント名や品目と顧客フロントの関係を予め知ることなく、発注を行うことができる。
【００５６】
ユーザが直接品目を発注できると、必要に応じて必要な分を発注することが可能となり、購買担当部門等での在庫量を削減することができる。そして、この購買の単価や在庫削減によるコスト低減のみならず、購買管理に必要な直接的及び間接的な人件費を削減することができる。例えば、ある組織の年間の消耗品の総購入額が「１００」であるとき、この「１００」を管理するための人員の人件費が「３００」であることもある。しかし、消耗品は必ず業務に必要であるから手配を行わなければならず、また、税務関連の報告や会計処理なども必須作業であるため、この「３００」のコスト（見えないコスト）の削減は容易ではなかった。
【００５７】
しかし、品揃え関連情報を用いて品別の発注を行うと、購買管理部門の作業は数年に一度品揃え（取扱品目）を顧客フロント毎に定めることとなり、実際の発注をユーザが直接行うことができる。しかも、この発注は、購買管理部門が定めた顧客フロント及び提供価格にて実行される。すなわち、ユーザが品目を特定するのみで、購買管理部門によって定められた購買条件に従った購買活動を顧客のユーザが直接実行することができる。そして、本実施例では特に、発注の前提となる購買要求を行う時点で選択可能な費目がユーザに提供され、この費目を用いて購買管理基準を単位とした購買管理を行う。従って、ユーザは、各品目での費目も、品目毎に異なる承認経路も、品目の販売店（顧客フロント）も知ることなく、必要なものを必要な時に発注することができる。このようにユーザによる簡易な発注を可能としつつ、複数段階の予算管理単位での予算枠・購買実績の累計金額等を簡明に管理することができるため、購買活動の最適化や経費分担の最適化を行いやすい。
【００５８】
この品揃え関連情報を用いた発注管理を、ここでは品別発注制御機能２２Ｂと呼ぶ。図１に示す構成では、分割発注制御部２２が、品目別に予め定められた受注者毎に当該発注データを送信する品別発注制御機能を備える。図１０は、本実施例の詳細構成例を示すブロック図である。図１０に示す例では、各種マスタを記憶するデータベース９と、ネットワーク２を介して所定の端末１と接続され当該端末１とのデータ送受信を制御すると共に要求に応じて各種マスタのデータの抽出又は登録をするサーバ１０とを備えている。そして、データベースは、流通支援に必要な多種類のマスタを有しているが、本実施例では、受発注を行うために図１１に示す以下のマスタを備えている。次のマスタ構造とすることで、Ｎ個の顧客とＮ個の顧客フロントとＮ個のサプライヤとさらに卸等の中間商流プレイヤを結びつけている。
【００５９】
（１）顧客の所定の購買単位と、当該購買単位に所属するユーザへ商品又はサービス等の品目を提供する顧客フロントとの関係について、顧客の購買単位に対して品目別に複数の顧客フロントが定義された顧客／顧客フロント対応マスタ５。
（２）ユーザ又は顧客の運営単位の一方である購買単位と、顧客フロントとをキーとして定義され、当該顧客フロントから当該購買単位へ提供する品目の品揃えを識別する品揃え単位が定義された品揃え単位マスタ４Ａ。
（３）この品揃え単位マスタの品揃え単位によって識別される品揃えに所属する品目及びサプライヤ及びデリバ等の品目の流通に関する属性情報が品揃えデータとして定義された品揃えマスタ４Ｂ。品揃えマスタ４Ｂには、品目毎に選択可能な費目コードを格納する。
（４）品目の品番毎に当該品目の仕様及びサプライヤ等の品目自体の属性情報が定義された商品マスタ３。
（５）顧客フロントとサプライヤとデリバとの関係に応じた卸等の中間商流プレイヤが定義された商流管理マスタ６。
【００６０】
データベース９には、さらに、購買管理を行うために図１２に示す各種マスタを備えている。図１２に示す各種マスタは、図６に示す各種マスタの詳細構成の一例となっている。
（６）運営単位毎に選択可能な費目の一覧を管理する費目マスタ５４。発注時選択可否フラグを用いることで、ある品目に関しては強制的に特定の費目を割り当てる等の処理が可能となる。
（７）運営単位毎に複数設けられる予算管理単位（購買管理上の部門コード、プロジェクトコード等）の一覧を管理する予算管理単位マスタ５６。予算管理マスタには、各予算管理単位での承認者ユーザＩＤが、その予算管理単位で使用する費目コード等が格納される。
（８）運営単位毎に、発注部門の予算管理単位ＩＤと選択された費目の費目コードとによって特定する承認経路及び予算階層を管理する承認経路兼予算階層マスタ５５。図６に示す購買管理マスタとほぼ同様である。
（９）各予算管理単位毎の予算額や購買の累計額を管理する予算枠・承認用累計マスタ５７、承認用累計額は予算額と比較され、累計方式を採る場合、承認用累計額が予算額を上回った場合には承認が必要となる。
【００６１】
図１０乃至図１２に示す例では、「品揃え関連情報」を品揃え単位マスタ４Ａと品揃えマスタ４Ｂの２つのマスタで管理する。ここでは、顧客フロントのユーザ群に対する品揃えの識別を「品揃え単位」にて行う。品揃え単位マスタ４Ａに登録される品揃え単位情報には、実際の品揃え自体は登録されない。本実施例では、品揃え単位ＩＤと品番を組み合わせることで、品揃えを定義している。この品揃え単位ＩＤと品番の組み合わせを、本実施例では品揃えと呼ぶ。この品揃えは、品揃えマスタ４Ｂに登録される。
【００６２】
サーバ１０は、本実施例では、顧客／顧客フロント対応マスタを参照して顧客運営単位毎に顧客フロント群を特定する顧客フロント群特定部３２と、品揃え単位マスタを参照してユーザ毎又は顧客運営単位毎に品揃え単位群を特定する品揃え単位群特定部３４とを備えている。
【００６３】
サーバ１０はさらに、品揃え単位群特定部３４によって特定された複数の品揃え単位毎の品揃えデータとユーザから発注用に選択された品番とに基づいてこのユーザと取引する顧客フロント群の内の唯一の顧客フロントを特定する顧客フロント特定部３６と、ユーザから発注用に入力される品番に基づいて当該品番毎に品揃え単位群特定部によって特定された品揃え単位群のそれぞれの品揃えデータのうち各品番毎に唯一の品揃えデータを品揃え単位毎に定義された唯一の品揃えデータを品揃えマスタから抽出する品揃えデータ抽出部３８と、この品揃えデータ抽出部によって抽出された品揃えデータに基づいて当該品目のサプライヤ及びデリバを特定するサプライヤ／デリバ特定部４０とを備えいてる。
【００６４】
また、サーバ１０は、このサプライヤとデリバと顧客フロントとの組み合わせに応じて商流管理マスタを参照してサプライヤから顧客フロントまでの商流を特定すると共に当該商流での仕入／売上処理を支援する商流制御部４８と、デリバから顧客フロント名義で品目をユーザに配送するための制御をする配送制御部４２とを備えている。この図１０に示す構成により、ユーザ群に対して複数の顧客フロント（品揃え単位）が定義されている場合であっても、発注用にユーザが品番を選択した段階でサプライヤから顧客までの商流を自動的に決定する。
【００６５】
さらに、図１０に示す例では、サーバ１０は、ユーザからアクセスされたときに当該ユーザを識別するユーザＩＤ及びパスワード並びに当該ユーザが所属する顧客運営単位ＩＤの入力を要求するログイン制御部４４を備えている。ユーザは、本実施例による流通支援システムのログイン用ページを読み出し、ユーザＩＤ及び顧客運営単位ＩＤとを入力することで、流通支援システムのサーバ１０にログインする。ログインユーザは、その所属する顧客の運営単位と、ユーザＩＤとが識別可能となる。本実施例では、顧客フロント群特定部３２は、ログイン制御部４４による制御に応じて入力される顧客運営単位ＩＤに基づいて当該ログインユーザに品目を提供可能な顧客フロント群を特定する機能を備えている。
【００６６】
顧客と顧客フロント対応マスタ５には、顧客運営単位ＩＤとこの顧客運営単位ＩＤで識別される顧客運営単位に所属するユーザへ品目の提供を契約した一又は複数の顧客フロント（顧客フロント群）が特定されている。品揃え関連情報を用いても顧客フロント群を特定することはできるが、図１０に示す例では、ログインした状態で顧客フロント群を特定することで、当該ログインユーザに対して各顧客フロントからのメッセージを表示したり、また、緊急に取引停止となった顧客フロントの有無のログイン時での判定等が可能となる。また、顧客の購買単位に属するユーザが、品目の選定以前に、取引のある顧客フロントへ各種の質問等を行うこともできる。
【００６７】
また、品揃え単位群特定部３４は、ログイン制御部４４による制御に応じて入力されるユーザＩＤ又は顧客運営単位ＩＤに基づいて各顧客フロント毎に当該ユーザに提供する品目の一覧が定義された品揃え単位群を特定する機能を備えている。ユーザ／品揃え単位マスタ７には、ユーザＩＤと品揃え単位ＩＤとの関係が定義されている。品揃え単位群特定部３４は、このユーザ／品揃え単位マスタ７を参照してログインユーザに対する品揃え単位ＩＤ群を特定する。この品揃え単位ＩＤ群が判明すると、当該ログインユーザが発注可能な全ての品目にアクセスすることができる。
【００６８】
図１０を参照すると、サーバ１０は、ユーザによって発注される一又は複数の品目の品番を発注品番群として一時的に格納する制御をする発注制御部４６を備えている。そして、顧客フロント特定部３６は、発注制御部４６にて格納される発注品番群の品番毎に特定される当該品番の品揃え単位に基づいて顧客フロント群の内の唯一の顧客フロントを特定する機能を備えている。品揃え単位マスタ中の整備責任運営単位ＩＤは、当該品揃えを提供する顧客フロントの運営単位ＩＤである。顧客フロント特定機能は、本実施例では、ユーザＩＤと品番とによって品揃え単位が特定された後に、この品揃え単位マスタの整備責任運営単位ＩＤを参照して当該品目を当該ユーザに提供する顧客フロントを発注時に自動的に特定する。このとき、顧客フロント特定部３６は、顧客フロント群特定部によって特定された顧客フロント群に関する情報を参照することなく、当該顧客フロントを特定することができる。一方、この顧客フロント特定部３６が特定する顧客フロントは、顧客フロント群特定部によって特定された顧客フロント群の中の一つである。
【００６９】
ユーザＩＤが定まっている状態で、品番が定まると、品揃えが重複しない前提では、品揃え単位ＩＤを唯一に特定できる。品揃えは顧客フロント毎に定義されるため、ユーザＩＤと品番の組み合わせにより、複数の顧客フロントから唯一の顧客フロントを特定することができる。
【００７０】
発注制御部には、上述した実施形態での購買管理システムとして機能する購買管理部６４が接続されている。購買管理部６４は、管理基準が定められている場合であって、一時的に格納した発注品番又は発注品番群がある場合に、当該発注品番と新たに追加される品目の品番の管理基準が異なる場合には新たな品目の追加を受け付けずに同一承認基準別の一括した発注を促す機能を備えている。
【００７１】
図１０に示す例では、購買管理部６４は、ユーザ又は承認者等の他のユーザから発注品番群に対する確定発注の受信を制御する機能（図１に示す例では、管理処理制御部２１）を備えている。承認者から発注の承認があった場合に、当該発注品番群に対する確定発注があったと判断するようにしても良い。確定発注がなされると、サプライヤ／デリバ特定部は、確定発注の発注品番群の各品番毎に顧客フロント特定部３６によって特定された顧客フロントの当該ユーザに対する品揃え単位によって識別される品揃えデータを参照して、当該品番のサプライヤ及びデリバを特定する機能を備えている。すなわち、本実施例では、顧客フロントと品目の組み合わせによって、唯一のサプライヤ及びデリバを特定する。生花贈答サービスや、名刺印刷サービスなど、複数のサプライヤが存在する場合であっても、品揃え関連情報の生成時にユーザと品目毎にサプライヤを特定しておく。
【００７２】
さらに、商流特定部４８は、このサプライヤ／デリバ特定部４０によって特定されたサプライヤ及びデリバと当該品番の顧客フロントとの組み合わせに応じて商流管理マスタ６を参照してサプライヤから顧客フロントまでの中間商流プレイヤの商流を唯一の流通経路として特定する機能を備えている。すなわち、本実施例では、顧客フロントと、サプライヤと、デリバとの組み合わせが定まると、顧客フロントからサプライヤまでの商流を唯一のものとして特定する。この商流は、品目又は品目群ごとに顧客フロントは仕入先を唯一のものとして特定する。この仕入先は、さらにその仕入先を唯一のものとして特定する。この中間商流プレイヤのつながりがサプライヤに至るまで、その経路を唯一のものとする。
【００７３】
デリバを商流特定のキーとすることで、顧客と顧客フロントとの間の品揃えをより豊かで柔軟なものとすることができる。例えば、コピー用紙について通常の購買と、特に急ぐ緊急用の購買とに別の品番を定めておき、通常の購買についてはサプライヤと提携したデリバからの直送とし、一方、緊急用の購買の場合には顧客フロントが直接ユーザにコピー用紙を届けることとする。この場合、緊急用のコピー用紙のデリバは、顧客フロント自身である。従って、商流は発生しない。このデリバの態様を種々定義できるようにしつつ、通常の運用時には商流を高速かつ確実に自動判定できるようにするために、顧客フロントと、サプライヤと、デリバとの組み合わせに応じて商流を定めることとした。また、サプライヤからの直送のみとせず、現在の商流に近似した仕組みをシステム上に実現することで、多種多様な業種の品目が本実施例による流通支援システムにて商取引可能となることを図っている。品目の種類が増加すると、購買管理基準内での一括発注機能により、ユーザはさらに簡易な発注が可能となり、さらに、会計処理を本実施例により自動化できる範囲が拡大できる。
【００７４】
図１０に示す例では、サーバ１０が、前記購買単位に属するユーザによって使用される端末から品目を発注するための発注要求を受信したときに前記品揃え関連情報を参照して当該品目に振替先品番が格納されている場合には当該振替先品番の品目を受注用にユーザに通知する振替受注制御部６０を備えている。振替受注制御部は、品揃え関連情報を参照して前記発注要求を受けた品番が廃番となっていた場合には当該品目の発注の変更又は取消を前記ユーザに促す廃番品発注変更機能を備えるようにしても良い。この品番の廃番（品目の供給停止）や新商品等への振替が成された場合に、予め品揃え関連情報に格納した振替自動実施レベル等に基づいて品番振替等を自動実施することで、顧客の購買管理部門の負担を軽減すると共に、廃番によって必要な品目が入手できなくなる不都合を回避する。
【００７５】
また、購買管理部６４が、その管理処理制御部２１によって１つの管理基準に属する購買要求とされた品目の組み合わせを当該組み合わせを単位として次回以降の購買要求用に格納する管理基準別購買要求データ格納部２７を備えるようにしても良い。ホームページの閲覧でのブックマーク機能やお気に入り登録機能と同様に、周期的に発注する品目の一覧を登録しておき、再度の発注を容易とすることが行われている。しかし、間接財の購買では多品種少量であることから、その整理の仕方が難しく、単純な購買履歴の参照による再発注ではかえって探索に時間を要することも想定され得る。管理基準別購買要求データ格納部２７は、購買要求を一括して申請可能であった組み合わせを記憶しておくことで、再発注にかかる作業時間の短縮を図っている。
【００７６】
図１３は、本実施例による流通支援システムを用いる効果を説明するための説明図である。図１３に示すように、品揃え関連情報を用いることで、ユーザ群毎に購買可能な品目群を予め特定しておくことができる。例えば、家具に関しては、ユーザ群２のみが購買可能としている。そして、必要なときに必要な品目の購買要求を行うと、その品目の費目に応じて承認経路や予算管理単位が特定される。例えば、文具事務用品であれば総務部担当で、且つ２０万円以上の場合には総務部部長の承認が必要となる。これらの購買管理基準は、図１２に示す承認経路兼予算階層マスタによって管理する。また、品揃え関連情報を用いることで、品目別に顧客フロントを自動的に特定することができる。従って、ユーザ群は、どのような承認経路で、どこの予算枠か等を意識することなく、さらに、定期購買契約等の関係でどの顧客フロントに発注すべきか等の知識を要せずに発注を行うことができる。また、本実施例では、購買管理基準毎に一括した購買要求（発注）を行うことができる。図１３に示す例では、書籍と、生花や御歳暮等のギフトは所属部門担当の予算枠であるため、書籍と生花とを一括して購買要求することができる。この場合、書籍は百貨店へ、生花は生花店へと発注される。
【００７７】
＜第２実施形態： 購買管理支援システム＞
次に、顧客側の購買管理システムに商品データ等の提供を行う購買管理支援システムを開示する。間接財は多品種少量であり、その改廃も頻繁であることから、発注側で購買管理システムを構築し、その商品マスタを管理することは煩雑であり、かえってコスト増を招くことも想定され得る。一方、承認等のワークフローのシステム化が完了している組織では、上述した流通支援システム等の導入により商品データのメンテナンス等のコストの減少を図ることが困難となる。このため、本実施形態による購買管理支援システムは、商品データのメンテナンスを購買管理支援システム側で行い、最新の商品データを顧客の購買システムに提供する。このとき、本実施形態では、購買管理に必要となる費目コードや管理基準コード等を付加した状態で品目データを送信する。
【００７８】
図１４は本実施形態での購買管理支援システムの構成例を示すブロック図である。図１４に示す例では、一又は複数の購買管理システム７０と接続されたサーバ１０と、前記購買管理システムを運営する運営単位毎にユーザ及び購買管理単位を記憶した購買管理マスタ１６と、商品及びサービスである品目に関する品目データを記憶した商品マスタ３とを備えている。そして、購買管理マスタ１６が、前記各購買管理システムの運営単位毎に当該運営単位にて発注する品目の一覧と、当該品目又は品目群毎に定義された費目コードと、前記購買管理単位毎に定義された費目コードとを記憶している。
【００７９】
さらに、サーバ１０が、前記各購買管理システムの運営単位での購買管理単位に属するユーザの端末からアクセスされた時に当該ユーザの操作に応じて前記購買管理マスタ及び商品マスタを参照して品目データを当該ユーザの端末に提供する商品データ提供部８０と、この商品データ提供部８０によって提供される商品データのうち前記ユーザによって品目が選択される毎に当該品目に定義された費目コードに基づいて当該運営単位での購買要求の管理基準を特定する管理基準特定部８１と、この管理基準特定部によって特定される管理基準を識別するための管理基準コードを前記ユーザによって選択された品目データと共に前記購買管理システムに送信する購買用データ送信部８２とを備えている。
【００８０】
商品データ提供部３０は、顧客の購買管理システムにログインしていたユーザからアクセスされた時に、品目の検索機能等を提供し、ユーザにとって必要な品目に関する情報を提供する。このとき、仕入値や希望小売価格の掛け率が定義されている場合には、価格も併せてユーザ端末に提供すると良い。また、顧客の購買管理システムにて各ユーザ群毎に購買可能な品目を限定したい場合には、上述した実施例による品揃え関連情報を作成しておくと良い。
【００８１】
管理基準特定部８１は、顧客の購買管理システムのユーザによって選択される毎に当該品目に定義された費目コードに基づいて当該運営単位での購買要求の管理基準を特定する。購買用データ送信部８２は、管理基準特定部８１によって特定される管理基準を識別するための管理基準コードを前記ユーザによって選択された品目データと共に前記購買管理システムに送信する。管理基準コードは、例えば、ユーザの属する予算管理単位と当該ユーザによって選択された品目の費目とを識別する予算枠コードである。または、ユーザの属する運営単位での承認経路を識別する承認経路コードとしても良い。顧客の購買管理システムは、この予算枠コード等の管理基準コードを参照して購買管理システムでの承認等を制御する。
【００８２】
購買管理支援システムは、受注機能や、実施例として開示した流通支援機能を有するようにしても良い。この場合、管理基準特定部８１によって管理基準を特定した購買要求される予定の品目群を一時的に保持しておき、同一ユーザから再度アクセスされたときに例えば買い物かごの中身として当該品目群を提供するようにしたり、また、顧客側の購買管理システムにて発注許可がなされた場合に当該発注許可信号の受信により当該一時的に保持していた品目群の受注として取り扱うようにしても良い。
【００８３】
また、購買管理マスタが、前記商品マスタ又はネットワークを介して接続される他のサーバによって管理される他サイト７２の商品マスタの各品目に定義された価格の決定方式毎に費目コードを記憶し、他サイト７２からの品目に付する費目については価格の決定方式毎に定めるようにしても良い。他サイトでの商品マスタに格納される品目については、品揃え関連情報内に事前に組み込むことが難しい。一方、なんらかの形で価格を決定しなければならないため、種々の価格決定方式を取り決めることとなる。この価格決定方式は品目の種類に応じて定まるため、この価格決定方式毎に費目を定義すると、他サイト連携によって品目データを入手する場合であっても、一又は複数の選択可能な費目コードを特定することができる。
【００８４】
【発明の効果】
本発明は以上のように構成され機能するので、これによると、管理基準分割制御部が、購買要求なされた各品目の管理基準が各品目間で異なる場合には当該購買要求を管理基準毎に分割する制御をするため、ユーザは、承認経路等の管理基準の枠を超えて一括して多種類の品目群の購買要求を行うことができるため、承認回数を最小限とすることができ、一方、分割発注制御部が、購買の管理基準を単位として一体的に取り扱われた購買要求を、品目別の発注先に分割して各発注先へ発注する制御をするため、ユーザは、購買要求を行う際に、当該品目の管理基準（例えば、承認経路）がどのようになっているかや、各品目毎の発注先を予め知ることなく購買要求を行うことができる、という従来にない優れた受発注システムを提供することができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態による購買管理システムの構成例を示すブロック図である。
【図２】本実施形態でのユーザの所属と費目の関係を示す説明図であり、図２（Ａ）は所属部門との関係を示す図で、図２（Ｂ）は予算管理単位との関係を示す図で、図２（Ｃ）は品目群との関係を示す図である。
【図３】ユーザと品目群と費目の関係を示す説明図であり、図３（Ａ）はユーザと費目の関係を示す図で、図３（Ｂ）は品目群を用いて閲覧制御を行う例を示す図で、図３（Ｃ）は費目を用いて閲覧制御を行う例を示す図で、図３（Ｄ）は購買要求の管理基準別分割の一例を示す図である。
【図４】本実施形態での購買基準の一例を示す説明図であり、図４（Ａ）は部門の階層を示す図で、図４（Ｂ）は図４（Ａ）に示す部門階層での予算管理上の階層定義の例を示す図である。
【図５】本実施形態での購買実績の集計例を示す説明図である。
【図６】本実施形態での各種マスタの主要項目の一例を示す説明図である。
【図７】本実施形態での購買管理処理の一例を示すフローチャートである。
【図８】本実施形態の購買管理処理の変形例を示すフローチャートである。
【図９】第１実施形態の実施例の概要を説明するための説明図である。
【図１０】本実施例による流通支援システムの構成例を示すブロック図である。
【図１１】本実施例での商品マスタ等の構成を示す説明図である。
【図１２】本実施例での購買管理関連の各種マスタの構成を示す説明図である。
【図１３】本実施例の利点を説明するための説明図である。
【図１４】本発明の第２実施形態の構成例を示すブロック図である。
【符号の説明】
１ 端末
２ ネットワーク（例えば、インターネット）
３ 商品マスタ
１０ サーバ
１８ 品目閲覧制御部
１９ 管理基準別分割制御部
２０ 管理基準特定部
２１ 管理処理制御部
２２ 分割発注制御部
２３ 発注集計処理部
【発明の属する技術分野】
本発明は、購買管理システムに係り、特に、品目の購買に関して予算、承認等の管理を行う購買管理システムに関する。
【０００２】
【従来の技術】
従来より、文具・工具などの消耗品（MRO: Maintenance, Repair and Operationsとも呼ばれる）や家具類などは企業等の組織で多種大量に消耗されている。これらの消耗品は、組織の事業運営に必要なものであり、その購入は予算や会計との関係で管理されている。消耗品や工具・家具類などは、事業活動や生産活動に間接的に必要となるものであるから、間接財や副資材とも呼ばれる。間接材の購買は少額で多頻度且つ多種膨大であり、購買先や購買条件も品目や地域ごとに異なっている場合が多く、その購買管理が煩雑である。
【０００３】
従来より、従業員が数百人に及ぶ大規模な組織では、一定期間で行われた見積合わせなどによって、販売店（顧客フロント）と顧客（企業などの組織）との間で取扱商品及び価格を定めておき、その取り決めに従った購買活動を行うことで、購買管理を簡略化することが図られている。そして、近年、購買管理、発注処理等をコンピュータを用いて行うことで、さらなる省力化を実現するための手法が種々提案されている。
【０００４】
特開平９−９７２８４号公報には、消耗品等の発注情報に基づいて各発注部門の発注金額を累計し、累計した発注金額が予め記憶した発注部門の予算限度額を超えていない場合に発注許可情報を出力する手法が開示されている。この公報では、複数の発注先（販売店）に発注を均等に分配する機能が開示されている。
【０００５】
特開２０００−７６３４２号公報には、複数の品目を選択した後に、その複数種類の物品の購買について費用の負担元、職場コード、勘定科目、費目、設備予算コード、希望納期、納入事業所等の情報を入力する手法が開示されている（段落「０１５６」）。そして、勘定科目、費目、費用負担元コード、設備予算コードの関係が予め定められたクロスチェックテーブルを使用する旨が開示されている（図２１）。
【０００６】
また、特開平７−２８９１２号公報には、購買に関して予算管理を行う部門を階層的に定義する旨が開示されている。特開平６−３４８７２９号公報には、伝票の種類に応じて承認の経路を特定する手法が開示されている。
【０００７】
【発明が解決しようとする課題】
上記各従来例では、個別の機能に応じた個々の作業は省力化されるものの、購買毎にその組織での経理や購買条件等に依拠した購買活動を行うには、各ユーザが種々の手引き等を参照したり、購買管理部門等へ問い合わせを行うなど、各ユーザが購買条件等を習得しなければならなかった。すると、購買管理システム等を導入しても、購買管理部門の日常的な業務負担が少なからず残ってしまう、という不都合があった。すなわち、上記各従来例やその組み合わせでは、必要とするユーザが必要な分だけ組織の購買条件や予算に応じて発注を行うという理想的な状態を構築しがたい。例えば、発注する品目について勘定科目や費目をユーザ本人が入力する従来例では、どの品目がどの勘定科目や費目（例えば、販促費、消耗品費、出張旅費等）に属するかを覚えるか又は購買要求（発注）に調べなければならない。また、複数の品目を選択した後にそれらが同一の勘定科目ではないことが明らかになると、品目の選択を最初からやり直さなければならない。
【０００８】
このように、上記各従来例や、各従来例の要素技術の組み合わせでは、組織に所属するユーザ本人がその組織の購買条件等を意識することなく、簡単に発注の要求（購買要求）及び発注を行うことができない。
【０００９】
また、予算管理や、品目の購入の承認や、品目の購入に関連する会計管理などの購買活動の管理については、組織内にて購買条件や購買方法を統一しておくと、承認や会計に関する人的コストの削減を図ることができる。しかし、間接材の購買は多頻度で且つ多種膨大であり、さらに品目の改廃が頻繁に行われることから、このような予算管理や管理会計を含めた購買管理を行うには、システム開発及び維持のコストや、運用に必要な人的コストが膨大となってしまう。すると、間接財の購買管理によってかえってコスト増となってしまう事態も想定され得る。
【００１０】
間接材及び副資材の購買活動及び管理については、事業活動及び生産活動に対して間接的な業務であるため、低コストで実施すべきであるが、従来例では、組織内での多大な人的コストを要している、という不都合があった。
【００１１】
これは、間接材等の購買や、その会計処理は、間接的な業務ではありながら、各種の税の納付のために必要な書類や、会計報告で必要な書類は必ず作成しなければならないため、企業にとって必須の活動であり、この必須の活動である点が、間接材の購買に関する「見えないコスト」削減をより一層困難にしている。すなわち、間接材の購買及びその会計処理等を一切廃止することはできず、従って、いかにしてコストを削減するかについての検討が必要となる。
【００１２】
一方、近年の経営では、事業部毎の会計や、社内カンパニー制や、分社化や、コストのみを生じさせる部門のアウトソースや、逆に、関連会社全体での連結決算の実施など、小さい部門毎の経費分担の明確化から、複数の会社に渡る単位での集計まで、種々の方向性から財務会計及び管理会計を実行すべき要望が強くなっている。そして、詳細な単位で管理会計を実行するには、発注の単位を小さくする必要がある。一方、発注の単位があまりに小さいと、例えば承認の作業数が増加するなど、購買活動自体があまりに煩雑となってしまう。
【００１３】
【発明の目的】
本発明は、係る従来例の有する不都合を改善し、特に、組織内での購買条件等をユーザが熟知する必要が無く、間接財の購買をそのユーザ自身が簡易に行うことのできる購買管理システムを提供することを、その目的とする。
また、本発明は、購買管理部門及びユーザの最小限の作業で、多種多様な品目の購買活動実績を種々の方向から分析・集計可能な購買管理システムを提供することを、その目的とする。
【００１４】
【課題を解決するための手段】
本発明では、データベースが、品目を他の品目から識別する品番及び該品目の価格を関連付けて記憶している商品マスタと、ユーザＩＤ、該ユーザＩＤが示すユーザが所属する運営単位を示す顧客運営単位ＩＤ、及び該ユーザＩＤが示すユーザが所属する予算管理単位を示す予算管理単位ＩＤを関連付けて記憶しているユーザマスタと、前記顧客運営単位ＩＤ、前記予算管理単位ＩＤ、及び当該予算管理単位ＩＤが示す予算管理単位にて使用可能な費目コードを関連付けて記憶している予算管理単位マスタと、品目を示す品番、その品目で使用可能な一又は複数の当該品目の区分又は用途を示す費目を示す費目コード、及び顧客フロントのユーザに対する品揃えを示す品揃え単位ＩＤを関連付けて記憶している品揃えマスタと、前記品揃え単位ＩＤ、前記顧客運営単位ＩＤ、及び顧客フロントの運営単位ＩＤを関連付けて記憶している品揃え単位マスタと、前記予算管理単位ＩＤ、費目コード、下限額、及び前記顧客の管理基準を関連付けて記憶している承認経路兼予算階層マスタと、前記予算管理単位ＩＤ、費目コード、承認用購買累計額、及び予算額を関連付けて記憶している予算枠・承認用累計管理マスタとを有し、サーバが、ユーザがログインした際にユーザマスタを参照してユーザＩＤ及び予算管理単位ＩＤを特定する手段と、複数種類の品目の購買要求がなされる場合に各品目に付された品番をキーとして品揃えマスタを参照して該品番に関連付けられている費目コードを特定するか又は前記手段により特定された予算管理単位ＩＤをキーとして予算管理単位マスタを参照することにより該予算管理単位ＩＤに関連付けられた費目コードを特定するともに買い物かごに蓄積し、この費目コード及び前記予算管理単位ＩＤをキーとして前記承認経路兼予算階層マスタを参照することにより当該購買要求がなされた各品目の管理基準を特定するとともに、品目を買い物かごに蓄積する毎に、既に買い物かごに蓄積された他の品目の管理基準と同一であるか否かを判定する管理基準特定部と、前記管理基準特定部によって判定される管理基準が同一であると前記管理基準特定部によって判定された場合に前記管理基準が示す予算管理単位ＩＤに対応する承認者端末に購買要求の承認を依頼する信号を発する機能、品目の価格を前記予算枠・承認用累計管理マスタにて前記予算管理単位ＩＤに関連付けられた承認用購買累計額に加算し、承認用購買累計額を前記予算枠・承認用累計管理マスタにて前記予算管理単位ＩＤに関連付けられた予算額と比較し、承認用購買累計額が予算額以下である場合には直ちに購買要求を許可したことを示す信号を発する機能、又は品目の価格が前記承認経路兼予算階層マスタにて前記予算管理単位ＩＤに関連付けられた下限額以下である場合には直ちに購買要求を許可したことを示す信号を発する機能と、買い物かごに蓄積した品目の管理基準が既に買い物かごに蓄積された他の品目の管理基準と同一でないと前記管理基準特定部によって判定された場合に購買要求の分割を促すための信号を発する機能とを有する管理処理制御部と、前記承認者端末又は前記管理処理制御部から購買要求を許可したことを示す信号が発された際に、前記品目ごとに該品目に関連付けられた品揃え単位ＩＤを前記予算管理単位ＩＤに関連付けられた顧客運営単位ＩＤ及び前記品番をキーとして前記データベースを参照して特定し、特定された品揃え単位ＩＤをキーとして前記データベースを参照し顧客フロントの運営単位ＩＤを特定し、特定された顧客フロントの運営単位ＩＤが示す顧客フロント毎に当該購買要求が行われたことを示す発注データを送信する分割発注制御部とを備えた、という構成を採っている。これにより前述した目的を達成しようとするものである。
【００１５】
本発明では、組織に所属するユーザから購買要求がなされ、この購買要求に応じて予算枠との関係での発注可否や承認等の購買管理処理を行い、この管理処理が完了した購買要求を発注データとして受注先（販売店等）に送信する。管理基準特定部は、購買要求として品目が選択される毎に、品目の費目に応じて承認経路や予算枠等の購買の管理基準を特定する。品目の費目は、例えば財務会計の勘定科目である。また、組織内のユーザの理解を助けるためにより簡略化した科目コードや、勘定科目の小分類を費目としても良い。管理基準分割制御部は、購買要求なされた各品目の管理基準が各品目間で異なる場合には当該購買要求を管理基準毎に分割する制御をする。従って、ユーザは、承認経路等の管理基準の枠を超えて一括して多種類の品目群の購買要求を行うことができる。管理基準が同一であるというのは、例えば承認経路が同一の場合や、予算枠が同一の場合や、承認を行わないという点で一致する場合などがある。続いて、管理処理制御部は、管理基準毎に分割された購買要求を受信すると共に当該購買要求についての管理処理の制御をする。この管理処理制御部の制御に応じた承認等が完了すると、分割発注制御部は、購買要求を品目別の発注先に分割して各発注先へ発注する制御をする。この発注は、発注書を印刷するようにしても良いし、またオンラインで発注データを各販売店（顧客フロント）に送信するようにしても良い。本発明では、購買要求を行う際に、当該品目の管理基準（例えば、承認経路）がどのようになっているかを予め知ることなく購買要求を行うことができ、さらに、管理基準や、発注先や品目の種別や費目にかかわらず一つの購買要求として取り扱うことができ、管理基準毎に分割され、さらに、承認等なされた購買処理要求は品目別に一又は複数の発注先へ自動的に分割して発注される。このため、ユーザは、管理基準や発注先を予め知る必要もない。
【００１６】
【発明の実施の形態】
＜第１実施形態： 購買管理システム＞
次に、本発明の一実施形態を図面を参照して説明する。図１は、本発明の一実施形態の構成を示すブロック図である。本実施形態による購買管理システムは、ユーザ端末１Ａから複数種類の品目の購買要求がなされる場合に品目が選択される毎に当該品目に定義され当該品目の区分又は用途を示す費目に応じて当該購買要求の管理基準を特定する管理基準特定部２０と、購買要求なされた各品目の管理基準が異なると前記管理基準特定部によって判定された場合には当該購買要求を管理基準毎に分割する制御をする管理基準分割制御部１９と、
この管理基準分割制御部１９によって管理基準毎に分割された購買要求を受信すると共に当該購買要求についての管理処理の制御をする管理処理制御部２１と、この管理処理制御部によって購買要求が許可されたときに当該購買要求を品目別の発注先毎に分割して発注する制御をする分割発注制御部２２と、この分割発注制御部２２によって発注された発注データを当該発注の費目等の属性に応じて集計する発注集計処理部２３とを備えている。
【００１７】
また、図１に示す例では、管理基準特定部２０が、ユーザが所属する予算管理単位と費目とに応じて前記管理基準を特定するユーザ所属別管理基準特定機能２０Ａや、一又は複数の予算管理部門を特定する予算管理単位ＩＤ又は予算と承認とを管理する複数の予算・承認管理部門を特定する予算管理単位ＩＤを前記管理基準として特定する経路特定機能２０Ｂを備えている。ユーザ所属別管理基準特定機能２０Ａにより、製造部門であるか否かや、販売促進費を用いる部門であるか否か等に応じて使用可能な費目をユーザの予算管理単位（購買管理上の所属）に基づいて定義することができる。
【００１８】
購買管理としては、予算管理のみを行う場合と、承認付きで予算管理を行う場合とがある。経路特定機能２０Ｂは、予算管理のみを行う例では、一又は複数の予算管理部門を特定する予算管理単位ＩＤを管理基準として特定する。また、承認及び予算管理を行う例では、予算と承認とを管理する複数の予算・承認管理部門を特定する予算管理単位ＩＤを前記管理基準として特定する。予算管理単位ＩＤは、一般には組織の部門名を特定する。予算管理単位ＩＤを階層的に特定することで、承認経路等を特定することができる。
【００１９】
本実施形態では、管理基準分割制御部１９が、購買要求なされた各品目の管理基準が異なると前記管理基準特定部によって判定された場合には当該購買要求を管理基準毎に分割する制御をするため、従って、ユーザは、承認経路等の管理基準の枠を超えて一括して多種類の品目群の購買要求を行うことができる。また、分割発注制御部２２が、管理基準毎に分割された購買要求をさらに発注先毎に自動的に分割して発注する制御をする。このため、ユーザは、承認経路や予算枠管理部門等の管理基準や、発注先等の組織内の購買条件を予め知ることなく、必要な物を１回の操作で一括して発注（購買要求）することができる。
【００２０】
「費目」は、財務会計での勘定科目や、予算管理で用いる品目の区分など購買管理上品目をグループ分けする概念である。一般的には、品目が特定されると費目も唯一に特定される。しかし、例えば販売の促進を目的とした展示会で使用する文具を購入した場合には、消耗品費ではなく販売促進費となる。また、家具についても、同一の品目であっても一定額以内は消耗品費となり、一定額以上は備品費となり、さらに耐用年数及び購入金額によっては工具・器具・備品（固定資産）となる。文具のうち、工具としても利用されるものは、購入部門が製造部門であるか否かで費目が異なることもある。本実施形態では、ユーザの属する予算管理単位と、品目群とに使用可能な費目を定めておき、購買要求での品目の選択を受信する際にこの使用可能な費目をユーザに表示し、選択を促す。
【００２１】
図２は、ユーザ等と費目との関係を示す説明図である。図２（Ａ）に示すように、ユーザは本来の所属部門がある。一方、予算枠は、プロジェクト毎に部門に横断して定められたり、また、製造部門、総務部門等の相違に応じて異なる予算枠とすることもある。その組織（会社等の運営単位）での予算枠の設定が純粋な部門毎ではなく、プロジェクト毎や、地域ごととなっている場合には、予算管理単位は所属部門の階層とは異なる。図２（Ｂ）に示す例では、説明のために、所属部門と予算管理単位とを異なるグループとしている。所属部門（０２）のユーザ（０４）は、販売促進の担当者であるとする。
図２（Ｂ）に示す例では、予算管理単位毎に使用可能な費目を定義している。また、図２（Ｃ）に示す例では、品目群毎に使用可能な費目を定義している。本実施形態では、この予算管理単位が特定された場合に使用可能となる費目と、品目群が特定されたときに使用可能となる費目と併用する。好ましい例では、ユーザによって品目が特定された場合に初期設定された費目を表示し、且つ、そのユーザが所属する予算管理単位や、その選択された品目に別の費目が定義されている場合には、この費目も選択可能とする。
品目群（０１）がファイリング用品や、鉛筆等の文具消耗品を含むとする。図３（Ａ）に示すように、ユーザ（０１）等の通常のユーザはこれを消耗品費として購入する。この場合、図２（Ｃ）に示す品目群（０１）に定義された費目を用いる。一方、販売促進の担当者であるユーザ（０４）は、ファイリング用品等を、組織内で消費する消耗品としてではなく、例えばショールームの展示品に関する費用である販売促進費（販促費）という費目コードで購入することもできる。この販促費は、図２（Ｂ）に示す予算管理単位（０２）に定義された費目コードである。このように、ユーザ又はユーザ群である予算管理単位に定められた費目コードと、品目群に定められた費目コードとを用いることで、同一品目に関する複数種類の費目コードを使い分けることができる。さらに、品目の内容による費目コードを品目群に、用途による費目コードを予算管理単位に定義することで、原則的な費目と例外的な費目とをユーザ別に使い分けることができる。
【００２２】
再度図１を参照すると、本実施形態による購買管理システムは、品目の購買要求を行うユーザ毎に当該ユーザが購買可能な品目群を特定すると共に当該購買可否に応じて各ユーザ毎に品目の閲覧を制御する品目閲覧制御部１８を備えている。品目閲覧制御部１８は、ユーザ毎に発注可能な品目を制御する機能である。例えば、図３（Ｂ）に示すように、ユーザＡ，Ｂは品目群（０１）のみを発注でき、ユーザＣは品目群（０１），（０２），（０３）の全ての品目を発注でき、ユーザＤは品目群（０１）と品目群（０２）の発注ができる。品目閲覧制御部１８は、ユーザＡから購買要求がなされる場合に、品目群（０２）等を品目選択画面等に表示しないか、または、閲覧のみとして購買要求の選択を付加とする制御をする。
【００２３】
図３（Ｂ）に示す例では、品目閲覧制御部１８は、各ユーザ又はユーザ群毎に定められた品揃えを特定する品揃え関連情報に基づいて前記ユーザ毎の購買可否を判定する機能１８Ａを備えている。すなわち、ユーザと品目群との関係を予め定義する。費目コードは、品目又はユーザの予算管理単位に定義する。これにより、品目閲覧制御と、ユーザの用途別の費目コードを実現する。図３（Ｂ）に示す例では、ユーザＡは品目群（０１）を消耗品費としてのみ購入でき、一方、ユーザＢは品目群（０１）を販促費又は消耗品費として購入できる。品目閲覧制御部１８の機能により、ユーザＡおよびＢは、品目群（０２），（０３）にはアクセスできない。
【００２４】
図３（Ｃ）に示す例では、品目閲覧制御部１８は、前記各ユーザ又はユーザ群毎に予め定められた購買可能な費目に基づいて前記ユーザ毎の購買可否を判定する機能１８Ｂを備えている。図３（Ｃ）に示す例では、ユーザは費目コードと結びつけられている。消耗品費での購入は全てのユーザが可能で、備品費での購入はユーザＣのみが可能となる。費目コードは商品のカテゴリでもあるため、図３（Ｃ）に示す例では、各費目コードに品目群を定義している。これにより、品目閲覧制御部１８は、各ユーザ別に購買可能な品目を制御する。この場合、ユーザＢは販促費を介して品目群（０１）にアクセス可能に定義することで、ユーザ毎の費目を実現する。
【００２５】
図１に示す例では、管理基準特定部２０は、ユーザからの購買要求される品目の指定を受信する毎に、当該品目の費目に応じて当該品目の購買管理基準を特定する。管理基準特定部２０は、ユーザの所属部門名と費目とに基づいて管理基準を特定するようにしても良い。「管理基準」は、例えば予算枠や、承認者である。階層的な承認や予算管理を行う場合には、承認経路や予算管理階層が管理基準となる。ユーザによって品目が選択されてから、電子的な買い物かご等に一時的に蓄積するまでにこの管理基準を特定すると良い。
【００２６】
管理基準特定部２０は、品目を買い物かごに蓄積する毎に、既に買い物かごに蓄積された他の品目の管理基準と同一であるか否かを判定する。管理基準が同一の場合には買い物かごに蓄積された購買要求をそのまま一括して承認処理や予算管理処理に入力する。一方、管理基準別分割制御部１９は、買い物かごに蓄積された品目群が複数の管理基準に属する場合には、購買要求された品目群を各管理基準毎に分割する。
【００２７】
例えば、図３（Ｄ）に示すように、ある部門に新人が配属され、その新人用に鉛筆等の消耗品と、デスクと、パーソナルコンピュータ（ＰＣ）及びコンピュータ関連の消耗品とを購入する。ユーザＣは、消耗品費、備品費、理化学機器の全ての品目が購買可能であるため、図３（Ｄ）に示すように、管理基準や販売店にかかわらず必要な全ての品目を一度に一括して購買要求を行う。そして、消耗品費が管理基準１に属し、備品費及び理化学機器が同一の管理基準２に属するとする。管理基準別分割制御部１９は、購買要求された複数の品目群を、図３（Ｄ）に示すように、管理基準毎に分割する。
【００２８】
管理基準毎に分割された購買要求は、管理所里制御部２１の制御に従って、それぞれの管理基準にて予算執行や承認等の管理処理が行われる。管理処理が完了すると、分割発注制御部２２は、購買要求を発注先毎に分割して発注する。例えば、デスクとＰＣとは異なる発注先に発注する場合には、分割発注制御部２２は、管理基準２の購買要求をさらに分割して各販売店に発注する。
【００２９】
このように、本実施形態では、購買要求者は自らが発注できる品目を予め知ることなく、発注可能な品目のみを購買要求することができ、さらに、販売店や管理基準にかかわらず必要な物を一括して購買要求することができる。一方、承認者側でも、管理基準を最大枠として分割された購買要求の承認を行うため、１つ１つの品目を個別に承認する必要が無く、一括して承認を行うことができる。さらに、販売店毎に自動的に分割して発注なされるため、購買担当者によらず予め販売店毎に定められた購買契約等に基づいた発注を行うことができる。また、管理基準や発注先にかかわらず一括した購買要求を行うため、その購買要求を行った品目が全て納品されたか否か等の検収作業を行いやすくなる。
【００３０】
本実施形態では、当該管理基準の枠を用いて購買要求を分割することで、複数種類の品目を一体的に承認又は予算執行することができ、各品目を個別に承認等の管理をすることと比較して、承認回数等の購買管理に必要な作業量を減らすことができる。このようにユーザ及び購買管理部門の利便性を向上させる一方、実際の発注については、発注先毎に分割して発注する。従って、例えば文具と書籍とを一体的に承認処理を行い、続いて文具店と書店とに自動的に発注データを分割して発注することができる。承認経路や予算枠等の管理基準を単位として異なる種別の品目であっても一体的に購買の管理処理を行うことで、煩雑な承認処理の回数（頻度）を減少させることができる。さらに、発注データの発注先毎への自動的な分割処理により承認等の購買管理と、実際の発注との大きさ、範囲を異なるものとして取り扱うため、購買管理の局面では承認回数等を減少させるために比較的多種類の品目を一体的に扱い、一方、発注先への発注については各受注者毎の個別の発注として取り扱うことができる。
【００３１】
管理基準特定部２０は、品目の費目を用いて管理基準を特定する。この費目を用いて管理基準を特定するために、まず品目に対応する費目を特定する。図１に示す例では、サーバ１０は、品目の購買要求を行うユーザが所属する予算管理単位に定義された費目コードと、前記品目の商品カテゴリ又は価格決定区分毎に定められた費目コードとを当該購買要求時に選択可能に表示する費目コード表示制御部２４と、この費目コード表示制御部２４によって表示される選択可能な一又は複数の費目コードのうち前記ユーザによって購買要求がなされる時に選択される費目コードを当該品目の費目として前記管理基準特定部２０に入力する購買要求時費目特定部２６とを備えている。
【００３２】
費目を特定する要素としては、品目と、ユーザの所属部門と、ユーザの所属する予算管理単位（工場等の製造現場であるか等）と、その品目の用途（販促用や広告用であるか等）などによって定まる。例えば販促用に文具類を購入する場合、その品目の費目が販売促進費であるのか消耗品費となるかは事前に特定することができない。
【００３３】
費目コード表示制御部２４は、品目の商品カテゴリ又は価格決定区分毎に定められた費目コードとを当該購買要求時に選択可能に表示する。価格決定区分は、購買管理システム内で商品を分類するために用いられることがあるため、この価格決定区分と費目を対応させるようにしても良い。例えば、購買管理システムが他のシステムで管理される品目を提供する場合には、その他のシステムでの価格から本システムでの価格を算出する。この他のシステムとの連携では、品目の価格を決定するための区分コード等を用いる。このような場合には、この価格決定区分コードと費目を関連させることで、予め各品目に費目を付することができない場合であっても、各品目に費目を定義することができる。
【００３４】
ここでは、費目コード表示制御部２４は、ユーザが購買要求を行う際に、品目別や、ユーザの所属する予算管理単位（例えば、所属部門や、所属プロジェクト）毎に定まる費目を当該ユーザに通知する制御を行う。費目コード表示制御部２４は、例えばポップアップメニューの形式で費目を表示させるようにしても良い。そして、ユーザは、購買要求時にこの費目コード表示制御部２４によって表示制御される一又は複数の費目から、当該購買要求での費目を選択する。購買要求時費目特定部２６は、費目コード表示制御部２４によって表示される選択可能な一又は複数の費目コードのうち前記ユーザによって購買要求がなされる時に選択される費目コードを当該品目の費目として前記管理基準特定部２０に入力する。費目が特定されると、ユーザが属する予算管理単位と費目とを用いて予算枠や承認経路等の購買管理基準を特定する。書籍の費目が雑費で、文具の費目が消耗品費である場合であっても、管理基準は同一であることもある。従って、費目が異なる場合であっても、管理基準が同一であれば、一括した購買要求が可能である。品目等から直接管理基準を特定せず、一旦費目を特定するのは、購買実績の財務会計でこの費目が必要となるためである。
【００３５】
図４は、購買の管理基準の一例を示す説明図である。ある企業Ａ（運営単位）の部門は三階層となっている。そして、図４（Ｂ）に示すように予算の階層が費目別に定められている。例えば、マーケティング部の企画課は、消耗品はマーケティング部の予算枠での購買で、備品費は総務部での予算枠での購買となる。企画課ユーザＡが鉛筆を消耗品費（自社消費）で購入する場合、一般的には企画課内の承認で発注に至る。予算枠は、図４（Ｂ）に示すようにマーケティング部となる。販促課のユーザＢが鉛筆を販促費として購入する場合、販促費は購買額が大きくなるため、１階層上位の部門（ここでは、マーケティング部）の承認を要することが多い。また、一定額以内であれば承認不要で発注でき、一定額を超える場合に承認が必要としても良い。
【００３６】
第１課のユーザＣが家具を備品費で購入する場合、第１課、関東営業部、そして総務部の承認を経て発注される。備品費等は、各部門ではなく、総務部の管轄とされることが多い。図４（Ｂ）に示すように、総務部を予算枠管理部門としつつ、承認を行わない営業本部の予算とすることもある。このような階層的な承認の場合には、費目とその費目毎に定められた購買上限金額等に基づいて何階層までの承認が必要かを判定するようにしても良い。
【００３７】
図５は発注集計処理部２３による購買実績の集計例を示す説明図である。図５に示す例では、費目と予算管理単位毎に購買実績を算出した。家具という費目は設備費に含まれる。文具消耗品は、消耗品費に含まれる。図５に示すように、例えば第１課の２０という購買実績は、関東営業部の購買実績の７０に含まれる。この関東営業部の購買実績は営業本部の１００に含まれる。図５に、全部門の家具（備品費）の購買実績を総務部に集計した例を示す。
【００３８】
図６は、図１に示した購買管理マスタ等の項目例を示す説明図である。ユーザには、ユーザＩＤが付される。ユーザＩＤ毎に、そのユーザが属する企業または企業の部門を識別する運営単位ＩＤと、ユーザ名と、発注した際の送り先となる直送先ＩＤと、請求先の部門名等を識別する請求先ＩＤと、このユーザが所属する予算管理単位を識別する予算管理単位ＩＤと、システムへのログインに必要なパスワード等を有する。図６に示す例では、商品マスタは、品目を他の品目から識別する品番と、その品名と、価格とを有する。そして、その品目で使用可能な一又は複数の費目が定義されている。品目に複数の費目を付するのは、例えば階層的な費目コードを用いる場合に好適となる。例えば、書庫類、家具、備品費等の階層的な費目などを用いる場合には、品目に複数の費目を定義すると良い。
【００３９】
また、図６に示す例では、費目関連マスタ１７には、予算管理単位ＩＤと、品目群（商品カテゴリや、商品の価格決定方式など）を識別する品目群ＩＤとを用いて特定される費目が定義されている。この例では、膨大な種類の品目を扱う場合に、品目をグループ分けし、さらに品目群と予算管理単位とを用いて当該予算管理単位に属するユーザが当該品目群に含まれる品目に使用できる一又は複数の費目を定義する。品目群と予算管理単位とを用いて費目を定義するのは、例えば本実施形態による購買管理システムにて直接管理しない品目で、予め全品目に費目コードを付することができない場合であっても、費目コードを定義することができる。従って、例えば、他のシステムとの連携によって品目を購入又は販売する場合などであっても費目コードを付した購買が可能となる。すると、本実施形態による購買管理システムを用いて、すべての間接財の購買を行うと、購入した全ての品目に予め体系づけた費目コードを付することができる。
【００４０】
これらの費目は、本システムの導入時に購買管理担当者と会計担当者等との指定に応じて定められる。購買管理担当者等は、図６に示すデータベースに費目に関するデータを品目毎または予算管理単位毎に定義しておくことで、その後の実際の購買がなされる局面では費目を特定するための作業が不要となる。
【００４１】
購買管理マスタは、予算管理単位ＩＤと費目コードとを用いて図４（Ｂ）に示すような購買の管理基準を定める。承認・予算管理フラグは、予算管理のみを行うか、それとも承認と予算管理の双方を行うかを予算管理単位毎に識別するためのフラグである。このフラグを用いることで、例えば文具と書籍については承認を行わず、家具と理化学機器（コンピュータ等）については承認を行う等の処理が可能となる。承認方式区分は、例えば、下限方式と、累計方式と、下限＆累計方式とがある。下限方式は、階層的な承認経路が定められている場合に、各階層のみで決済可能な購買額（の上限）を定める手法である。累計方式は、例えば予算枠が定められていて、累計した購買実績が予算枠を超えてしまう購買要求がなされた場合にその予算枠管理部門の承認者の承認を必要とする方式である。下限＆累計方式では、通常は下限方式で行い、予算枠を超えた場合に累計方式とする手法である。
【００４２】
図６に示すように、購買管理マスタは、第１階層予算管理単位ＩＤと、第２階層予算管理単位ＩＤと、最終階層予算管理単位ＩＤ（予算枠管理部門ＩＤ）とを有する。この各予算管理単位を展開すると、例えば図４（Ｂ）に示す構造となる。そして、各予算管理単位毎に、下限額情報や、承認者を識別する情報や、累計金額（購買実績）情報等を格納する。
【００４３】
図７は、本実施形態での購買管理処理例を示すフローチャートである。ユーザがパスワードを用いて購買管理システムにログインする。すると、ユーザＩＤと予算管理単位ＩＤが定まる。ユーザＩＤが定まると、まず、ユーザ別の閲覧（発注）可能品目を特定する（ステップＳ１，品目閲覧制御工程）。続いて、当該ユーザが購買可能な品目のうち、ユーザが必要とする品目の全てを一括した購買要求を受信する（ステップＳ２）。購買要求を受信すると、各品目の管理基準（例えば、承認経路や予算枠等）を展開する（ステップＳ３，管理基準特定工程）。ステップＳ２で受信した購買要求の各品目が複数の管理基準に属する場合には、各品目を管理基準毎に分割する（ステップＳ４，管理基準別分割工程）。そして、管理基準毎に分割された各購買要求の購買管理処理を制御する（ステップＳ５，管理処理制御工程）。
購買管理処理が完了し、発注が許可された場合には、購買要求を品目別の発注先毎に分割して発注する制御をする（ステップＳ６，分割発注制御工程）。発注先の特定は、例えば各品目に唯一の発注先（販売店）を特定するようにしても良いし、また、同一品目について複数の発注先が有る場合には一定の条件に基づいて発注先を選択するようにしても良い。発注の形態としては、単純に発注書を印刷するのみとしても良いし、また、ネットワークを介してオンラインで発注データを送信するようにしても良い。発注データ又は発注書の項目には、図６に示すユーザマスタ５２等を参照して納品や請求に関する項目を含めると良い。
このような発注が行われたのち、ユーザの所属部門や、各予算管理単位や、費目等に応じて購買実績を集計する（ステップＳ８，発注集計処理工程）。
【００４４】
図１に示す構成や、図６に示す処理は、サーバ１０のＣＰＵを動作させる購買管理用プログラムを用いて実現することができる。この購買管理用プログラムは、サーバ１０を動作させる指令として、複数種類の品目の購買要求がなされる場合に品目が選択される毎に当該品目又は前記購買の管理単位に定義され当該品目の区分又は用途を示す費目に応じて当該購買要求の管理基準を特定させる管理基準特定指令と、購買要求なされた各品目の管理基準が異なると前記管理基準特定指令に応じて判定される場合には当該購買要求を管理基準毎に分割する制御をさせる管理基準分割制御指令と、この管理基準別分割制御指令に応じて管理基準毎に分割される購買要求を受信させると共に当該購買要求についての管理処理の制御をさせる管理処理制御指令と、この管理処理制御指令に応じて購買要求が許可されるときに当該購買要求を品目別の発注先毎に分割して発注する制御をさせる分割発注制御指令と、この分割発注制御指令に応じて発注される発注データを当該発注の費目等の属性に応じて集計させる発注集計処理指令とを備えると良い。
【００４５】
ここで、管理基準特定指令等が、サーバ１０を「動作させる」というときには、各指令のみでサーバ１０のＣＰＵを動作させる指令と、演算装置に予め格納されているオペレーティングシステムやデータベース駆動プログラム等の他のプログラムに依存して当該コンピュータを動作させる指令とのいずれかまたは双方を含む。例えば、図１に示す例では、管理基準特定指令を、サーバ１０に予め格納されたデータベース駆動用プログラムによるデータベース検索機能に依存して、当該検索機能に購買管理マスタ１６等に予算管理単位や費目コード等の検索項目を引き渡す指令としても良い。このように、当該品番振替制御用プログラムや、受発注システム用プログラムを記憶する記憶媒体であって、当該プログラムをユーザへ搬送する用途の記憶媒体には、例えば「データベースサーバにマスタ名と項目名を引き渡す指令」のみが格納される場合がある。これは、動作させようとするコンピュータのオペレーティングシステムやサーバ用プログラム等との関係で定る。
【００４６】
購買管理用プログラムは、可搬性のある記憶媒体１１Ａに格納されて当該コンピュータに供給される。図１に示す例では、ディスクドライブ１１は、ＣＤＲＯＭ等の記憶媒体１１Ａを駆動し、記憶媒体１１Ａに格納された購買管理用プログラムをサーバ１０の管理下のハードディスク等に実行可能な状態で格納する。また、ネットワークを介してサーバのハードディスク等に直接転送するようにしても良い。
【００４７】
＜第１実施形態の変形例＞
次に、図１及び図８を参照して本実施形態の変形例を説明する。この変形例では、管理基準が同一となる範囲で購買要求を受信し、管理基準が異なる場合には異なる購買要求とするようにユーザに促す機能を備える。この変形例による購買管理システムは、複数種類の品目の購買要求がなされる場合に品目が選択される毎に当該品目に定義され当該品目の区分又は用途を示す費目に応じて当該購買要求の管理基準を特定する管理基準特定部２０と、この管理基準特定部２０によって特定される管理基準が同一である場合に複数種類の品目の一括した購買要求を受信すると共に当該購買要求についての管理処理の制御をする管理処理制御部２１と、分割発注制御部２２と、発注集計処理部２３とを備える。分割発注制御部２２と発注集計処理部２３は上述した実施形態と同様である。
【００４８】
管理基準特定部２０は、ユーザが所属する予算管理単位と費目とに応じて前記管理基準を特定するユーザ所属別管理基準特定機能２０Ａや、一又は複数の予算管理部門を特定する予算管理単位ＩＤ又は予算と承認とを管理する複数の予算・承認管理部門を特定する予算管理単位ＩＤを前記管理基準として特定する経路特定機能２０Ｂを備えている。
【００４９】
この変形例では特に、管理処理制御部２１が、経路特定機能２０Ｂによって特定される予算管理単位ＩＤの階層が同一である場合に複数種類の品目を一括して当該予算管理単位ＩＤでの予算処理又は予算・承認処理を実行する経路別実行機能２１Ａと、前記予算管理単位ＩＤの階層が異なる品目の購買要求に対しては前記ユーザに購買要求の分割を促す経路別分割依頼制御機能２１Ｂとを備えている。例えば、費目１が付される品目と、費目２が付される品目とが同一の承認経路である場合には、経路別実行機能２１Ａは、この品目を一括して購買上の管理処理を実行する。購買の管理処理は、例えば予算との比較による購買の可否の判定や、承認者端末１Ｂへの承認依頼等である。一方、経路別分割依頼制御機能２１Ｂは、予算管理単位ＩＤの階層が異なる品目の購買要求に対しては前記ユーザに購買要求の分割を促す。すなわち、複数種類の品目を一括した購買要求とできる範囲は同一承認経路の範囲内であって、経路別分割依頼制御機能２１Ｂは、承認経路の異なる品目が選択された場合にはその品目は別途購買処理要求を生成するように促す。
【００５０】
図８は、本変形例での動作例を示すフローチャートである。サーバ１０は、商品マスタを参照して、購買要求可能な品目の検索等のサービスを提供する。検索された品目情報には、使用可能な費目コードを付加する。費目コードと共に購買要求を受信すると（ステップＳ１１）、当該購買要求の管理基準を特定する（ステップＳ１２，管理基準特定工程）。例えば、図６に示す購買管理マスタ１６を用いて図４（Ｂ）等に示す予算階層・承認経路を展開する。
続いて、既に選択されている品目と管理基準（承認経路等）が同一であるか否かを判定し（ステップＳ１３）、管理基準が同一の場合には、複数種類の品目の一括した購買要求を受信し（ステップＳ１５）、当該購買要求についての管理処理の制御をする（ステップＳ１６，管理処理制御工程）。管理処理は、承認・予算管理フラグや承認方式区分を参照して予め定められた予算管理や承認制御を行う。一方、ステップＳ３にて、既に選択されている品目の管理基準と異なる管理基準であることが判明すると、その品目の追加を付加として別途の購買要求をユーザに促す。承認等が完了し発注可能な状態となると、購買要求を発注先毎に分割して発注する（ステップＳ１７）。さらに、各種の集計を行う（ステップＳ１８）。
【００５１】
＜第１実施形態の実施例： 流通支援システム＞
次に、購買管理システムを購買管理部として一部に含む流通支援システムを開示する。流通支援システムでは、複数の組織（発注者）と、複数の販売店（受注者、顧客フロント）と、品目の製造又は提供を行うサプライヤとを結び付ける。そして、発注者側では購買対象とする品目の一覧情報等の作成やメンテナンスを行わない。発注者となる組織が本実施例によるシステムを導入する際に、購買対象とする品目の一覧（品揃え）とその費目とを販売店等と共に検討する。続いて、費目と予算管理単位とをキーとして承認経路等の購買管理を特定する。この導入時の作業によって、実際の運用開始後は購買管理部門の担当者が個別に費目や管理基準等を組織内の各ユーザに示唆する必要性が少なくなる。
【００５２】
すなわち、本実施例による流通支援システムを用いると、組織内の購買管理と、購買実績の集計（財務会計及び管理会計）と、発注先の自動選定及び自動発注と、予め指定した部門等への納品とが自動的に行われる。また、顧客フロントやサプライヤにとっても、一定の形式で発注情報を受信できるため、製造や流通の最適化を行いやすい。さらに、発注情報を記憶しておき、顧客フロントから発注者への請求や、発注者となる組織での検収等を同一のデータを用いることができるため、検収や請求書の確認などの作業の省力化を図ることができる。本実施例では、発注者となる組織を顧客と呼ぶ。
【００５３】
図９は、本実施例で用いる品揃え関連情報とユーザとの関係を示す説明図である。図９に示すように、顧客のユーザ群（運営単位又は購買単位）と、顧客フロントとは、品揃え関連情報で結びつけられている。品揃え関連情報は、ユーザ群毎にそのユーザが購買可能な品目の一覧を特定するための情報である。そして、品目毎の費目コードは、この品揃え関連情報に定義する。また、品揃え関連情報を顧客フロント（販売店）毎に作成することで、品揃え関連情報を特定することによって顧客フロントを唯一のものとして特定することができる。品目の紹介画像などは、品揃え関連情報ではなく、流通支援システムの商品マスタや、ネットワークを介して接続される他サイトの商品マスタに格納しておいても良い。
【００５４】
品揃え関連情報での品揃えに含まれる品目は、商品マスタ３に登録されている品目である。商品マスタと、ユーザ群及び顧客フロント別に登録する品揃え関連情報とを用いることで、各品目に関する情報の登録及び更新は商品マスタにて一度のみ行うこととした。図９に示す例では、顧客フロント（０１）は、顧客（０１）に対して、ユーザ群別に２つの品揃え関連情報（０１，０２）を有している。顧客フロント（０２）は、顧客（０１）に対して、一つの品揃え関連情報（０３）を有している。
【００５５】
顧客（０１）のユーザ群（０１）は、顧客フロント（０１）の品揃え関連情報（０１）で品揃えされている品目と、顧客フロント（０２）の品揃え関連情報（０３）で品揃えされている品目とについて流通支援システムによる購入を行うことができる。同一のユーザ群（０１）に対する２つの品揃え関連情報（０１，０３）にて、同一品目が重複しないように品揃え関連情報を定義すると良い。同一ユーザ群に対する複数の品揃えにて品目の重複が存在しないと、ユーザが品目を特定したときにその品目を品揃えしている顧客フロントを唯一に特定できる。このユーザ群（顧客購買単位）と品目とが特定されたときに、顧客フロントを自動的に特定できる構成とすると、品目毎の発注先や商流の切り分けを行うことができる。例えば、顧客の購買単位に所属するユーザが本実施例による流通支援システムにログインし、購入を希望する品目を特定すると、品揃え関連情報は、同一のユーザに対して顧客フロント間で同一品目が重複しないように登録されているため、このユーザと品目とから品揃え関連情報を唯一のものとして特定できる。従って、ユーザと品目とが定まると顧客フロントを唯一のものとして特定することができる。このため、ユーザは、品目を特定するのみで、顧客フロントを選定する必要がない。すると、ユーザは、その顧客の購買管理部門が予め定めた顧客フロントに対して、その顧客フロント名や品目と顧客フロントの関係を予め知ることなく、発注を行うことができる。
【００５６】
ユーザが直接品目を発注できると、必要に応じて必要な分を発注することが可能となり、購買担当部門等での在庫量を削減することができる。そして、この購買の単価や在庫削減によるコスト低減のみならず、購買管理に必要な直接的及び間接的な人件費を削減することができる。例えば、ある組織の年間の消耗品の総購入額が「１００」であるとき、この「１００」を管理するための人員の人件費が「３００」であることもある。しかし、消耗品は必ず業務に必要であるから手配を行わなければならず、また、税務関連の報告や会計処理なども必須作業であるため、この「３００」のコスト（見えないコスト）の削減は容易ではなかった。
【００５７】
しかし、品揃え関連情報を用いて品別の発注を行うと、購買管理部門の作業は数年に一度品揃え（取扱品目）を顧客フロント毎に定めることとなり、実際の発注をユーザが直接行うことができる。しかも、この発注は、購買管理部門が定めた顧客フロント及び提供価格にて実行される。すなわち、ユーザが品目を特定するのみで、購買管理部門によって定められた購買条件に従った購買活動を顧客のユーザが直接実行することができる。そして、本実施例では特に、発注の前提となる購買要求を行う時点で選択可能な費目がユーザに提供され、この費目を用いて購買管理基準を単位とした購買管理を行う。従って、ユーザは、各品目での費目も、品目毎に異なる承認経路も、品目の販売店（顧客フロント）も知ることなく、必要なものを必要な時に発注することができる。このようにユーザによる簡易な発注を可能としつつ、複数段階の予算管理単位での予算枠・購買実績の累計金額等を簡明に管理することができるため、購買活動の最適化や経費分担の最適化を行いやすい。
【００５８】
この品揃え関連情報を用いた発注管理を、ここでは品別発注制御機能２２Ｂと呼ぶ。図１に示す構成では、分割発注制御部２２が、品目別に予め定められた受注者毎に当該発注データを送信する品別発注制御機能を備える。図１０は、本実施例の詳細構成例を示すブロック図である。図１０に示す例では、各種マスタを記憶するデータベース９と、ネットワーク２を介して所定の端末１と接続され当該端末１とのデータ送受信を制御すると共に要求に応じて各種マスタのデータの抽出又は登録をするサーバ１０とを備えている。そして、データベースは、流通支援に必要な多種類のマスタを有しているが、本実施例では、受発注を行うために図１１に示す以下のマスタを備えている。次のマスタ構造とすることで、Ｎ個の顧客とＮ個の顧客フロントとＮ個のサプライヤとさらに卸等の中間商流プレイヤを結びつけている。
【００５９】
（１）顧客の所定の購買単位と、当該購買単位に所属するユーザへ商品又はサービス等の品目を提供する顧客フロントとの関係について、顧客の購買単位に対して品目別に複数の顧客フロントが定義された顧客／顧客フロント対応マスタ５。
（２）ユーザ又は顧客の運営単位の一方である購買単位と、顧客フロントとをキーとして定義され、当該顧客フロントから当該購買単位へ提供する品目の品揃えを識別する品揃え単位が定義された品揃え単位マスタ４Ａ。
（３）この品揃え単位マスタの品揃え単位によって識別される品揃えに所属する品目及びサプライヤ及びデリバ等の品目の流通に関する属性情報が品揃えデータとして定義された品揃えマスタ４Ｂ。品揃えマスタ４Ｂには、品目毎に選択可能な費目コードを格納する。
（４）品目の品番毎に当該品目の仕様及びサプライヤ等の品目自体の属性情報が定義された商品マスタ３。
（５）顧客フロントとサプライヤとデリバとの関係に応じた卸等の中間商流プレイヤが定義された商流管理マスタ６。
【００６０】
データベース９には、さらに、購買管理を行うために図１２に示す各種マスタを備えている。図１２に示す各種マスタは、図６に示す各種マスタの詳細構成の一例となっている。
（６）運営単位毎に選択可能な費目の一覧を管理する費目マスタ５４。発注時選択可否フラグを用いることで、ある品目に関しては強制的に特定の費目を割り当てる等の処理が可能となる。
（７）運営単位毎に複数設けられる予算管理単位（購買管理上の部門コード、プロジェクトコード等）の一覧を管理する予算管理単位マスタ５６。予算管理マスタには、各予算管理単位での承認者ユーザＩＤが、その予算管理単位で使用する費目コード等が格納される。
（８）運営単位毎に、発注部門の予算管理単位ＩＤと選択された費目の費目コードとによって特定する承認経路及び予算階層を管理する承認経路兼予算階層マスタ５５。図６に示す購買管理マスタとほぼ同様である。
（９）各予算管理単位毎の予算額や購買の累計額を管理する予算枠・承認用累計マスタ５７、承認用累計額は予算額と比較され、累計方式を採る場合、承認用累計額が予算額を上回った場合には承認が必要となる。
【００６１】
図１０乃至図１２に示す例では、「品揃え関連情報」を品揃え単位マスタ４Ａと品揃えマスタ４Ｂの２つのマスタで管理する。ここでは、顧客フロントのユーザ群に対する品揃えの識別を「品揃え単位」にて行う。品揃え単位マスタ４Ａに登録される品揃え単位情報には、実際の品揃え自体は登録されない。本実施例では、品揃え単位ＩＤと品番を組み合わせることで、品揃えを定義している。この品揃え単位ＩＤと品番の組み合わせを、本実施例では品揃えと呼ぶ。この品揃えは、品揃えマスタ４Ｂに登録される。
【００６２】
サーバ１０は、本実施例では、顧客／顧客フロント対応マスタを参照して顧客運営単位毎に顧客フロント群を特定する顧客フロント群特定部３２と、品揃え単位マスタを参照してユーザ毎又は顧客運営単位毎に品揃え単位群を特定する品揃え単位群特定部３４とを備えている。
【００６３】
サーバ１０はさらに、品揃え単位群特定部３４によって特定された複数の品揃え単位毎の品揃えデータとユーザから発注用に選択された品番とに基づいてこのユーザと取引する顧客フロント群の内の唯一の顧客フロントを特定する顧客フロント特定部３６と、ユーザから発注用に入力される品番に基づいて当該品番毎に品揃え単位群特定部によって特定された品揃え単位群のそれぞれの品揃えデータのうち各品番毎に唯一の品揃えデータを品揃え単位毎に定義された唯一の品揃えデータを品揃えマスタから抽出する品揃えデータ抽出部３８と、この品揃えデータ抽出部によって抽出された品揃えデータに基づいて当該品目のサプライヤ及びデリバを特定するサプライヤ／デリバ特定部４０とを備えいてる。
【００６４】
また、サーバ１０は、このサプライヤとデリバと顧客フロントとの組み合わせに応じて商流管理マスタを参照してサプライヤから顧客フロントまでの商流を特定すると共に当該商流での仕入／売上処理を支援する商流制御部４８と、デリバから顧客フロント名義で品目をユーザに配送するための制御をする配送制御部４２とを備えている。この図１０に示す構成により、ユーザ群に対して複数の顧客フロント（品揃え単位）が定義されている場合であっても、発注用にユーザが品番を選択した段階でサプライヤから顧客までの商流を自動的に決定する。
【００６５】
さらに、図１０に示す例では、サーバ１０は、ユーザからアクセスされたときに当該ユーザを識別するユーザＩＤ及びパスワード並びに当該ユーザが所属する顧客運営単位ＩＤの入力を要求するログイン制御部４４を備えている。ユーザは、本実施例による流通支援システムのログイン用ページを読み出し、ユーザＩＤ及び顧客運営単位ＩＤとを入力することで、流通支援システムのサーバ１０にログインする。ログインユーザは、その所属する顧客の運営単位と、ユーザＩＤとが識別可能となる。本実施例では、顧客フロント群特定部３２は、ログイン制御部４４による制御に応じて入力される顧客運営単位ＩＤに基づいて当該ログインユーザに品目を提供可能な顧客フロント群を特定する機能を備えている。
【００６６】
顧客と顧客フロント対応マスタ５には、顧客運営単位ＩＤとこの顧客運営単位ＩＤで識別される顧客運営単位に所属するユーザへ品目の提供を契約した一又は複数の顧客フロント（顧客フロント群）が特定されている。品揃え関連情報を用いても顧客フロント群を特定することはできるが、図１０に示す例では、ログインした状態で顧客フロント群を特定することで、当該ログインユーザに対して各顧客フロントからのメッセージを表示したり、また、緊急に取引停止となった顧客フロントの有無のログイン時での判定等が可能となる。また、顧客の購買単位に属するユーザが、品目の選定以前に、取引のある顧客フロントへ各種の質問等を行うこともできる。
【００６７】
また、品揃え単位群特定部３４は、ログイン制御部４４による制御に応じて入力されるユーザＩＤ又は顧客運営単位ＩＤに基づいて各顧客フロント毎に当該ユーザに提供する品目の一覧が定義された品揃え単位群を特定する機能を備えている。ユーザ／品揃え単位マスタ７には、ユーザＩＤと品揃え単位ＩＤとの関係が定義されている。品揃え単位群特定部３４は、このユーザ／品揃え単位マスタ７を参照してログインユーザに対する品揃え単位ＩＤ群を特定する。この品揃え単位ＩＤ群が判明すると、当該ログインユーザが発注可能な全ての品目にアクセスすることができる。
【００６８】
図１０を参照すると、サーバ１０は、ユーザによって発注される一又は複数の品目の品番を発注品番群として一時的に格納する制御をする発注制御部４６を備えている。そして、顧客フロント特定部３６は、発注制御部４６にて格納される発注品番群の品番毎に特定される当該品番の品揃え単位に基づいて顧客フロント群の内の唯一の顧客フロントを特定する機能を備えている。品揃え単位マスタ中の整備責任運営単位ＩＤは、当該品揃えを提供する顧客フロントの運営単位ＩＤである。顧客フロント特定機能は、本実施例では、ユーザＩＤと品番とによって品揃え単位が特定された後に、この品揃え単位マスタの整備責任運営単位ＩＤを参照して当該品目を当該ユーザに提供する顧客フロントを発注時に自動的に特定する。このとき、顧客フロント特定部３６は、顧客フロント群特定部によって特定された顧客フロント群に関する情報を参照することなく、当該顧客フロントを特定することができる。一方、この顧客フロント特定部３６が特定する顧客フロントは、顧客フロント群特定部によって特定された顧客フロント群の中の一つである。
【００６９】
ユーザＩＤが定まっている状態で、品番が定まると、品揃えが重複しない前提では、品揃え単位ＩＤを唯一に特定できる。品揃えは顧客フロント毎に定義されるため、ユーザＩＤと品番の組み合わせにより、複数の顧客フロントから唯一の顧客フロントを特定することができる。
【００７０】
発注制御部には、上述した実施形態での購買管理システムとして機能する購買管理部６４が接続されている。購買管理部６４は、管理基準が定められている場合であって、一時的に格納した発注品番又は発注品番群がある場合に、当該発注品番と新たに追加される品目の品番の管理基準が異なる場合には新たな品目の追加を受け付けずに同一承認基準別の一括した発注を促す機能を備えている。
【００７１】
図１０に示す例では、購買管理部６４は、ユーザ又は承認者等の他のユーザから発注品番群に対する確定発注の受信を制御する機能（図１に示す例では、管理処理制御部２１）を備えている。承認者から発注の承認があった場合に、当該発注品番群に対する確定発注があったと判断するようにしても良い。確定発注がなされると、サプライヤ／デリバ特定部は、確定発注の発注品番群の各品番毎に顧客フロント特定部３６によって特定された顧客フロントの当該ユーザに対する品揃え単位によって識別される品揃えデータを参照して、当該品番のサプライヤ及びデリバを特定する機能を備えている。すなわち、本実施例では、顧客フロントと品目の組み合わせによって、唯一のサプライヤ及びデリバを特定する。生花贈答サービスや、名刺印刷サービスなど、複数のサプライヤが存在する場合であっても、品揃え関連情報の生成時にユーザと品目毎にサプライヤを特定しておく。
【００７２】
さらに、商流特定部４８は、このサプライヤ／デリバ特定部４０によって特定されたサプライヤ及びデリバと当該品番の顧客フロントとの組み合わせに応じて商流管理マスタ６を参照してサプライヤから顧客フロントまでの中間商流プレイヤの商流を唯一の流通経路として特定する機能を備えている。すなわち、本実施例では、顧客フロントと、サプライヤと、デリバとの組み合わせが定まると、顧客フロントからサプライヤまでの商流を唯一のものとして特定する。この商流は、品目又は品目群ごとに顧客フロントは仕入先を唯一のものとして特定する。この仕入先は、さらにその仕入先を唯一のものとして特定する。この中間商流プレイヤのつながりがサプライヤに至るまで、その経路を唯一のものとする。
【００７３】
デリバを商流特定のキーとすることで、顧客と顧客フロントとの間の品揃えをより豊かで柔軟なものとすることができる。例えば、コピー用紙について通常の購買と、特に急ぐ緊急用の購買とに別の品番を定めておき、通常の購買についてはサプライヤと提携したデリバからの直送とし、一方、緊急用の購買の場合には顧客フロントが直接ユーザにコピー用紙を届けることとする。この場合、緊急用のコピー用紙のデリバは、顧客フロント自身である。従って、商流は発生しない。このデリバの態様を種々定義できるようにしつつ、通常の運用時には商流を高速かつ確実に自動判定できるようにするために、顧客フロントと、サプライヤと、デリバとの組み合わせに応じて商流を定めることとした。また、サプライヤからの直送のみとせず、現在の商流に近似した仕組みをシステム上に実現することで、多種多様な業種の品目が本実施例による流通支援システムにて商取引可能となることを図っている。品目の種類が増加すると、購買管理基準内での一括発注機能により、ユーザはさらに簡易な発注が可能となり、さらに、会計処理を本実施例により自動化できる範囲が拡大できる。
【００７４】
図１０に示す例では、サーバ１０が、前記購買単位に属するユーザによって使用される端末から品目を発注するための発注要求を受信したときに前記品揃え関連情報を参照して当該品目に振替先品番が格納されている場合には当該振替先品番の品目を受注用にユーザに通知する振替受注制御部６０を備えている。振替受注制御部は、品揃え関連情報を参照して前記発注要求を受けた品番が廃番となっていた場合には当該品目の発注の変更又は取消を前記ユーザに促す廃番品発注変更機能を備えるようにしても良い。この品番の廃番（品目の供給停止）や新商品等への振替が成された場合に、予め品揃え関連情報に格納した振替自動実施レベル等に基づいて品番振替等を自動実施することで、顧客の購買管理部門の負担を軽減すると共に、廃番によって必要な品目が入手できなくなる不都合を回避する。
【００７５】
また、購買管理部６４が、その管理処理制御部２１によって１つの管理基準に属する購買要求とされた品目の組み合わせを当該組み合わせを単位として次回以降の購買要求用に格納する管理基準別購買要求データ格納部２７を備えるようにしても良い。ホームページの閲覧でのブックマーク機能やお気に入り登録機能と同様に、周期的に発注する品目の一覧を登録しておき、再度の発注を容易とすることが行われている。しかし、間接財の購買では多品種少量であることから、その整理の仕方が難しく、単純な購買履歴の参照による再発注ではかえって探索に時間を要することも想定され得る。管理基準別購買要求データ格納部２７は、購買要求を一括して申請可能であった組み合わせを記憶しておくことで、再発注にかかる作業時間の短縮を図っている。
【００７６】
図１３は、本実施例による流通支援システムを用いる効果を説明するための説明図である。図１３に示すように、品揃え関連情報を用いることで、ユーザ群毎に購買可能な品目群を予め特定しておくことができる。例えば、家具に関しては、ユーザ群２のみが購買可能としている。そして、必要なときに必要な品目の購買要求を行うと、その品目の費目に応じて承認経路や予算管理単位が特定される。例えば、文具事務用品であれば総務部担当で、且つ２０万円以上の場合には総務部部長の承認が必要となる。これらの購買管理基準は、図１２に示す承認経路兼予算階層マスタによって管理する。また、品揃え関連情報を用いることで、品目別に顧客フロントを自動的に特定することができる。従って、ユーザ群は、どのような承認経路で、どこの予算枠か等を意識することなく、さらに、定期購買契約等の関係でどの顧客フロントに発注すべきか等の知識を要せずに発注を行うことができる。また、本実施例では、購買管理基準毎に一括した購買要求（発注）を行うことができる。図１３に示す例では、書籍と、生花や御歳暮等のギフトは所属部門担当の予算枠であるため、書籍と生花とを一括して購買要求することができる。この場合、書籍は百貨店へ、生花は生花店へと発注される。
【００７７】
＜第２実施形態： 購買管理支援システム＞
次に、顧客側の購買管理システムに商品データ等の提供を行う購買管理支援システムを開示する。間接財は多品種少量であり、その改廃も頻繁であることから、発注側で購買管理システムを構築し、その商品マスタを管理することは煩雑であり、かえってコスト増を招くことも想定され得る。一方、承認等のワークフローのシステム化が完了している組織では、上述した流通支援システム等の導入により商品データのメンテナンス等のコストの減少を図ることが困難となる。このため、本実施形態による購買管理支援システムは、商品データのメンテナンスを購買管理支援システム側で行い、最新の商品データを顧客の購買システムに提供する。このとき、本実施形態では、購買管理に必要となる費目コードや管理基準コード等を付加した状態で品目データを送信する。
【００７８】
図１４は本実施形態での購買管理支援システムの構成例を示すブロック図である。図１４に示す例では、一又は複数の購買管理システム７０と接続されたサーバ１０と、前記購買管理システムを運営する運営単位毎にユーザ及び購買管理単位を記憶した購買管理マスタ１６と、商品及びサービスである品目に関する品目データを記憶した商品マスタ３とを備えている。そして、購買管理マスタ１６が、前記各購買管理システムの運営単位毎に当該運営単位にて発注する品目の一覧と、当該品目又は品目群毎に定義された費目コードと、前記購買管理単位毎に定義された費目コードとを記憶している。
【００７９】
さらに、サーバ１０が、前記各購買管理システムの運営単位での購買管理単位に属するユーザの端末からアクセスされた時に当該ユーザの操作に応じて前記購買管理マスタ及び商品マスタを参照して品目データを当該ユーザの端末に提供する商品データ提供部８０と、この商品データ提供部８０によって提供される商品データのうち前記ユーザによって品目が選択される毎に当該品目に定義された費目コードに基づいて当該運営単位での購買要求の管理基準を特定する管理基準特定部８１と、この管理基準特定部によって特定される管理基準を識別するための管理基準コードを前記ユーザによって選択された品目データと共に前記購買管理システムに送信する購買用データ送信部８２とを備えている。
【００８０】
商品データ提供部３０は、顧客の購買管理システムにログインしていたユーザからアクセスされた時に、品目の検索機能等を提供し、ユーザにとって必要な品目に関する情報を提供する。このとき、仕入値や希望小売価格の掛け率が定義されている場合には、価格も併せてユーザ端末に提供すると良い。また、顧客の購買管理システムにて各ユーザ群毎に購買可能な品目を限定したい場合には、上述した実施例による品揃え関連情報を作成しておくと良い。
【００８１】
管理基準特定部８１は、顧客の購買管理システムのユーザによって選択される毎に当該品目に定義された費目コードに基づいて当該運営単位での購買要求の管理基準を特定する。購買用データ送信部８２は、管理基準特定部８１によって特定される管理基準を識別するための管理基準コードを前記ユーザによって選択された品目データと共に前記購買管理システムに送信する。管理基準コードは、例えば、ユーザの属する予算管理単位と当該ユーザによって選択された品目の費目とを識別する予算枠コードである。または、ユーザの属する運営単位での承認経路を識別する承認経路コードとしても良い。顧客の購買管理システムは、この予算枠コード等の管理基準コードを参照して購買管理システムでの承認等を制御する。
【００８２】
購買管理支援システムは、受注機能や、実施例として開示した流通支援機能を有するようにしても良い。この場合、管理基準特定部８１によって管理基準を特定した購買要求される予定の品目群を一時的に保持しておき、同一ユーザから再度アクセスされたときに例えば買い物かごの中身として当該品目群を提供するようにしたり、また、顧客側の購買管理システムにて発注許可がなされた場合に当該発注許可信号の受信により当該一時的に保持していた品目群の受注として取り扱うようにしても良い。
【００８３】
また、購買管理マスタが、前記商品マスタ又はネットワークを介して接続される他のサーバによって管理される他サイト７２の商品マスタの各品目に定義された価格の決定方式毎に費目コードを記憶し、他サイト７２からの品目に付する費目については価格の決定方式毎に定めるようにしても良い。他サイトでの商品マスタに格納される品目については、品揃え関連情報内に事前に組み込むことが難しい。一方、なんらかの形で価格を決定しなければならないため、種々の価格決定方式を取り決めることとなる。この価格決定方式は品目の種類に応じて定まるため、この価格決定方式毎に費目を定義すると、他サイト連携によって品目データを入手する場合であっても、一又は複数の選択可能な費目コードを特定することができる。
【００８４】
【発明の効果】
本発明は以上のように構成され機能するので、これによると、管理基準分割制御部が、購買要求なされた各品目の管理基準が各品目間で異なる場合には当該購買要求を管理基準毎に分割する制御をするため、ユーザは、承認経路等の管理基準の枠を超えて一括して多種類の品目群の購買要求を行うことができるため、承認回数を最小限とすることができ、一方、分割発注制御部が、購買の管理基準を単位として一体的に取り扱われた購買要求を、品目別の発注先に分割して各発注先へ発注する制御をするため、ユーザは、購買要求を行う際に、当該品目の管理基準（例えば、承認経路）がどのようになっているかや、各品目毎の発注先を予め知ることなく購買要求を行うことができる、という従来にない優れた受発注システムを提供することができる。
【図面の簡単な説明】
【図１】本発明の第１実施形態による購買管理システムの構成例を示すブロック図である。
【図２】本実施形態でのユーザの所属と費目の関係を示す説明図であり、図２（Ａ）は所属部門との関係を示す図で、図２（Ｂ）は予算管理単位との関係を示す図で、図２（Ｃ）は品目群との関係を示す図である。
【図３】ユーザと品目群と費目の関係を示す説明図であり、図３（Ａ）はユーザと費目の関係を示す図で、図３（Ｂ）は品目群を用いて閲覧制御を行う例を示す図で、図３（Ｃ）は費目を用いて閲覧制御を行う例を示す図で、図３（Ｄ）は購買要求の管理基準別分割の一例を示す図である。
【図４】本実施形態での購買基準の一例を示す説明図であり、図４（Ａ）は部門の階層を示す図で、図４（Ｂ）は図４（Ａ）に示す部門階層での予算管理上の階層定義の例を示す図である。
【図５】本実施形態での購買実績の集計例を示す説明図である。
【図６】本実施形態での各種マスタの主要項目の一例を示す説明図である。
【図７】本実施形態での購買管理処理の一例を示すフローチャートである。
【図８】本実施形態の購買管理処理の変形例を示すフローチャートである。
【図９】第１実施形態の実施例の概要を説明するための説明図である。
【図１０】本実施例による流通支援システムの構成例を示すブロック図である。
【図１１】本実施例での商品マスタ等の構成を示す説明図である。
【図１２】本実施例での購買管理関連の各種マスタの構成を示す説明図である。
【図１３】本実施例の利点を説明するための説明図である。
【図１４】本発明の第２実施形態の構成例を示すブロック図である。
【符号の説明】
１ 端末
２ ネットワーク（例えば、インターネット）
３ 商品マスタ
１０ サーバ
１８ 品目閲覧制御部
１９ 管理基準別分割制御部
２０ 管理基準特定部
２１ 管理処理制御部
２２ 分割発注制御部
２３ 発注集計処理部
Claims (8)
- 各種マスタを記憶するデータベースと、ネットワークを介して所定の端末と接続され当該端末とのデータ送受信を制御すると共に前記データベースに接続され要求に応じて前記各種マスタのデータの抽出又は登録をするサーバとを備えた購買管理システムであって、
前記データベースが、品目を他の品目から識別する品番及び該品目の価格を関連付けて記憶している商品マスタと、
ユーザＩＤ、該ユーザＩＤが示すユーザが所属する運営単位を示す顧客運営単位ＩＤ、及び該ユーザＩＤが示すユーザが所属する予算管理単位を示す予算管理単位ＩＤを関連付けて記憶しているユーザマスタと、
前記顧客運営単位ＩＤ、前記予算管理単位ＩＤ、及び当該予算管理単位ＩＤが示す予算管理単位にて使用可能な費目コードを関連付けて記憶している予算管理単位マスタと、
品目を示す品番、その品目で使用可能な一又は複数の当該品目の区分又は用途を示す費目を示す費目コード、及び顧客フロントのユーザに対する品揃えを示す品揃え単位ＩＤを関連付けて記憶している品揃えマスタと、
前記品揃え単位ＩＤ、前記顧客運営単位ＩＤ、及び顧客フロントの運営単位ＩＤを関連付けて記憶している品揃え単位マスタと、
前記予算管理単位ＩＤ、費目コード、下限額、及び前記顧客の管理基準を関連付けて記憶している承認経路兼予算階層マスタと、
前記予算管理単位ＩＤ、費目コード、承認用購買累計額、及び予算額を関連付けて記憶している予算枠・承認用累計管理マスタとを有し、
前記サーバが、ユーザがログインした際にユーザマスタを参照してユーザＩＤ及び予算管理単位ＩＤを特定する手段と、
複数種類の品目の購買要求がなされる場合に各品目に付された品番をキーとして品揃えマスタを参照して該品番に関連付けられている費目コードを特定するか又は前記手段により特定された予算管理単位ＩＤをキーとして予算管理単位マスタを参照することにより該予算管理単位ＩＤに関連付けられた費目コードを特定するとともに買い物かごに蓄積し、この費目コード及び前記予算管理単位ＩＤをキーとして前記承認経路兼予算階層マスタを参照することにより当該購買要求がなされた各品目の管理基準を特定するとともに、品目を買い物かごに蓄積する毎に、既に買い物かごに蓄積された他の品目の管理基準と同一であるか否かを判定する管理基準特定部と、
前記管理基準特定部によって判定される管理基準が同一であると前記管理基準特定部によって判定された場合に前記管理基準が示す予算管理単位ＩＤに対応する承認者端末に購買要求の承認を依頼する信号を発する機能、品目の価格を前記予算枠・承認用累計管理マスタにて前記予算管理単位ＩＤに関連付けられた承認用購買累計額に加算し、承認用購買累計額を前記予算枠・承認用累計管理マスタにて前記予算管理単位ＩＤに関連付けられた予算額と比較し、承認用購買累計額が予算額以下である場合には直ちに購買要求を許可したことを示す信号を発する機能、又は品目の価格が前記承認経路兼予算階層マスタにて前記予算管理単位ＩＤに関連付けられた下限額以下である場合には直ちに購買要求を許可したことを示す信号を発する機能と、買い物かごに蓄積した品目の管理基準が既に買い物かごに蓄積された他の品目の管理基準と同一でないと前記管理基準特定部によって判定された場合に購買要求の分割を促すための信号を発する機能とを有する管理処理制御部と、
前記承認者端末又は前記管理処理制御部から購買要求を許可したことを示す信号が発された際に、前記品目ごとに該品目に関連付けられた品揃え単位ＩＤを前記予算管理単位ＩＤに関連付けられた顧客運営単位ＩＤ及び前記品番をキーとして前記データベースを参照して特定し、特定された品揃え単位ＩＤをキーとして前記データベースを参照し顧客フロントの運営単位ＩＤを特定し、特定された顧客フロントの運営単位ＩＤが示す顧客フロント毎に当該購買要求が行われたことを示す発注データを送信する分割発注制御部とを備えたことを特徴とする購買管理システム。 - 品目の購買要求を行うユーザが所属する予算管理単位を示す前記予算管理単位ＩＤをキーとして予算管理単位マスタを参照することにより該予算管理単位ＩＤに関連付けられた費目コードを特定するとともに、前記品目に関連付けられた費目コードを前記品揃えマスタを参照することにより特定し、これら特定された費目コードを当該購買要求時に選択可能に表示する費目コード表示制御部と、この費目コード表示制御部によって表示される選択可能な一又は複数の費目コードのうち前記ユーザによって購買要求がなされる時に選択される費目コードをキーとして前記管理基準特定部に前記承認経路兼予算階層マスタを参照させる購買要求時費目特定部とを備えたことを特徴とする請求項１記載の購買管理システム。
- 前記承認経路兼予算階層マスタが、一又は複数の予算管理部門を特定する予算管理単位ＩＤ又は予算と承認とを管理する複数の予算・承認管理部門を特定する予算管理単位ＩＤを前記管理基準として前記予算管理単位ＩＤ及び費目コードに関連付けて記憶していることを特徴とする請求項１又は２記載の購買管理システム。
- 前記予算管理単位ＩＤをキーとして予算管理単位マスタを参照して費目コードを特定し、この費目コードをキーとして品揃えマスタを参照して該費目コードが示す費目に関連付けられた品番を特定し、特定された品番が示す品目のみをユーザが閲覧可能にする制御を行う品目閲覧制御部を備えたことを特徴とする請求項１、２又は３記載の購買管理システム。
- 前記管理処理制御部によって１つの管理基準に属する購買要求とされた品目を他の品目から識別する品番の組み合わせを、当該組み合わせを単位として次回以降の購買要求用に格納する管理基準別購買要求データ格納部を備えたことを特徴とする請求項１、２、３、４又は５記載の購買管理システム。
- 各種マスタを記憶するデータベースと、ネットワークを介して所定の端末と接続され当該端末とのデータ送受信を制御すると共に前記データベースに接続され要求に応じて前記各種マスタのデータの抽出又は登録をするサーバとを使用して購買を管理する購買管理方法であって、
前記データベースが、品目を他の品目から識別する品番及び該品目の価格を関連付けて記憶している商品マスタと、
ユーザＩＤ、該ユーザＩＤが示すユーザが所属する運営単位を示す顧客運営単位ＩＤ、及び該ユーザＩＤが示すユーザが所属する予算管理単位を示す予算管理単位ＩＤを関連付けて記憶しているユーザマスタと、
前記顧客運営単位ＩＤ、前記予算管理単位ＩＤ、及び当該予算管理単位ＩＤが示す予算管理単位にて使用可能な費目コードを関連付けて記憶している予算管理単位マスタと、
品目を示す品番、その品目で使用可能な一又は複数の当該品目の区分又は用途を示す費目を示す費目コード、及び顧客フロントのユーザに対する品揃えを示す品揃え単位ＩＤを関連付けて記憶している品揃えマスタと、
前記品揃え単位ＩＤ、前記顧客運営単位ＩＤ、及び顧客フロントの運営単位ＩＤを関連付けて記憶している品揃え単位マスタと、
前記予算管理単位ＩＤ、費目コード、下限額、及び前記顧客の管理基準を関連付けて記憶している承認経路兼予算階層マスタと、
前記予算管理単位ＩＤ、費目コード、承認用購買累計額、及び予算額を関連付けて記憶している予算枠・承認用累計管理マスタとを有するとともに、
前記サーバが、ユーザがログインした際にユーザマスタを参照してユーザＩＤ及び予算管理単位ＩＤを特定する工程と、
複数種類の品目の購買要求がなされる場合に各品目に付された品番をキーとして品揃えマスタを参照して該品番に関連付けられている費目コードを特定するか又は前記手段により特定された予算管理単位ＩＤをキーとして予算管理単位マスタを参照することにより該予算管理単位ＩＤに関連付けられた費目コードを特定するとともに買い物かごに蓄積し、この費目コード及び前記予算管理単位ＩＤをキーとして前記承認経路兼予算階層マスタを参照することにより当該購買要求がなされた各品目の管理基準を特定するとともに、品目を買い物かごに蓄積する毎に、既に買い物かごに蓄積された他の品目の管理基準と同一であるか否かを判定する管理基準特定工程と、
前記管理基準特定工程によって判定される管理基準が同一であると前記管理基準特定工程によって判定された場合に前記管理基準が示す予算管理単位ＩＤに対応する承認者端末に購買要求の承認を依頼する信号を発する機能、品目の価格を前記予算枠・承認用累計管理マスタにて前記予算管理単位ＩＤに関連付けられた承認用購買累計額に加算し、承認用購買累計額を前記予算枠・承認用累計管理マスタにて前記予算管理単位ＩＤに関連付けられた予算額と比較し、承認用購買累計額が予算額以下である場合には直ちに購買要求を許可したことを示す信号を発する機能、又は品目の価格が前記承認経路兼予算階層マスタにて前記予算管理単位ＩＤに関連付けられた下限額以下である場合には直ちに購買要求を許可したことを示す信号を発する機能と、買い物かごに蓄積した品目の管理基準が既に買い物かごに蓄積された他の品目の管理基準と同一でないと前記管理基準特定工程によって判定された場合に購買要求の分割を促すための信号を発する機能とを有する管理処理制御工程と、
前記承認者端末から、又は前記管理処理制御工程により購買要求を許可したことを示す信号が発されたときに、前記品目ごとに該品目に関連付けられた品揃え単位ＩＤを前記予算管理単位ＩＤに関連付けられた顧客運営単位ＩＤ及び前記品番をキーとして前記データベースを参照して特定し、特定された品揃え単位ＩＤをキーとして前記データベースを参照し顧客フロントの運営単位ＩＤを特定し、特定された顧客フロントの運営単位ＩＤが示す顧客フロント毎に当該購買要求が行われたことを示す発注データを送信する分割発注制御工程とを備えたことを特徴とする購買管理方法。 - 前記管理基準特定工程が、品目の購買要求を行うユーザ毎に該ユーザが所属する前記予算管理単位を示す予算管理単位ＩＤをキーとして品揃え単位マスタを参照して該予算管理単位ＩＤに関連付けられた品揃え単位ＩＤを特定し、特定された品揃え単位ＩＤに関連付けられている品番が示す品目のみをユーザが閲覧可能にする制御を行う品目閲覧制御工程を備えたことを特徴とする請求項６記載の購買管理方法。
- 各種マスタを記憶するデータベースと、ネットワークを介して所定の端末と接続され当該端末とのデータ送受信を制御すると共に前記データベースに接続され要求に応じて前記各種マスタのデータの抽出又は登録をするサーバとを備え、
前記データベースが、品目を他の品目から識別する品番及び該品目の価格を関連付けて記憶している商品マスタと、
ユーザＩＤ、該ユーザＩＤが示すユーザが所属する運営単位を示す顧客運営単位ＩＤ、及び該ユーザＩＤが示すユーザが所属する予算管理単位を示す予算管理単位ＩＤを関連付けて記憶しているユーザマスタと、
前記顧客運営単位ＩＤ、前記予算管理単位ＩＤ、及び当該予算管理単位ＩＤが示す予算管理単位にて使用可能な費目コードを関連付けて記憶している予算管理単位マスタと、
品目を示す品番、その品目で使用可能な一又は複数の当該品目の区分又は用途を示す費目を示す費目コード、及び顧客フロントのユーザに対する品揃えを示す品揃え単位ＩＤを関連付けて記憶している品揃えマスタと、
前記品揃え単位ＩＤ、前記顧客運営単位ＩＤ、及び顧客フロントの運営単位ＩＤを関連付けて記憶している品揃え単位マスタと、
前記予算管理単位ＩＤ、費目コード、下限額、及び前記顧客の管理基準を関連付けて記憶している承認経路兼予算階層マスタと、
前記予算管理単位ＩＤ、費目コード、承認用購買累計額、及び予算額を関連付けて記憶している予算枠・承認用累計管理マスタとを有する購買管理システムを使用して購買を管理する購買管理用プログラムであって、
当該購買管理用プログラムは前記サーバを動作させる指令として、
ユーザがログインした際にユーザマスタを参照してユーザＩＤ及び予算管理単位ＩＤを特定する指令と、
複数種類の品目の購買要求がなされる場合に各品目に付された品番をキーとして品揃えマスタを参照して該品番に関連付けられている費目コードを特定するか又は前記手段により特定された予算管理単位ＩＤをキーとして予算管理単位マスタを参照することにより該予算管理単位ＩＤに関連付けられた費目コードを特定するともに買い物かごに蓄積し、この費目コード及び前記予算管理単位ＩＤをキーとして前記承認経路兼予算階層マスタを参照することにより当該購買要求がなされた各品目の管理基準を特定するとともに、品目を買い物かごに蓄積する毎に、既に買い物かごに蓄積された他の品目の管理基準と同一であるか否かを判定する管理基準特定指令と、
前記管理基準特定指令によって判定される管理基準が同一であると前記管理基準特定指令によって判定された場合に前記管理基準が示す予算管理単位ＩＤに対応する承認者端末に購買要求の承認を依頼する信号を発する機能、品目の価格を前記予算枠・承認用累計管理マスタにて前記予算管理単位ＩＤに関連付けられた承認用購買累計額に加算し、承認用購買累計額を前記予算枠・承認用累計管理マスタにて前記予算管理単位ＩＤに関連付けられた予算額と比較し、承認用購買累計額が予算額以下である場合には直ちに購買要求を許可したことを示す信号を発する機能、又は品目の価格が前記承認経路兼予算階層マスタにて前記予算管理単位ＩＤに関連付けられた下限額以下である場合には直ちに購買要求を許可したことを示す信号を発する機能と、買い物かごに蓄積した品目の管理基準が既に買い物かごに蓄積された他の品目の管理基準と同一でないと前記管理基準特定指令によって判定された場合に購買要求の分割を促すための信号を発する機能とを有する管理処理制御指令と、
前記承認者端末から、又は前記管理処理制御指令により購買要求を許可したことを示す信号が発されたときに、前記品目ごとに該品目に関連付けられた品揃え単位ＩＤを前記予算管理単位ＩＤに関連付けられた顧客運営単位ＩＤ及び前記品番をキーとして前記品揃え単位マスタを参照して特定し、特定された品揃え単位ＩＤをキーとして品揃え単位マスタを参照し顧客フロントの運営単位ＩＤを特定し、特定された顧客フロントの運営単位ＩＤが示す顧客フロント毎に当該購買要求が行われたことを示す発注データを送信する分割発注制御指令とを備えたことを特徴とする購買管理用プログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000344735A JP3982168B2 (ja) | 2000-11-13 | 2000-11-13 | 購買管理システム、購買管理方法、及び購買管理用プログラム |
| US09/987,194 US7353195B2 (en) | 2000-11-13 | 2001-11-13 | System for purchase management and for facilitating distribution |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000344735A JP3982168B2 (ja) | 2000-11-13 | 2000-11-13 | 購買管理システム、購買管理方法、及び購買管理用プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002150066A JP2002150066A (ja) | 2002-05-24 |
| JP3982168B2 true JP3982168B2 (ja) | 2007-09-26 |
Family
ID=18818886
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000344735A Expired - Lifetime JP3982168B2 (ja) | 2000-11-13 | 2000-11-13 | 購買管理システム、購買管理方法、及び購買管理用プログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7353195B2 (ja) |
| JP (1) | JP3982168B2 (ja) |
Families Citing this family (46)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8392285B2 (en) | 1996-11-12 | 2013-03-05 | Syncada Llc | Multi-supplier transaction and payment programmed processing approach with at least one supplier |
| US20070055582A1 (en) | 1996-11-12 | 2007-03-08 | Hahn-Carlson Dean W | Transaction processing with core and distributor processor implementations |
| US8396811B1 (en) | 1999-02-26 | 2013-03-12 | Syncada Llc | Validation approach for auditing a vendor-based transaction |
| US20080172314A1 (en) | 1996-11-12 | 2008-07-17 | Hahn-Carlson Dean W | Financial institution-based transaction processing system and approach |
| JP3562418B2 (ja) * | 2000-01-21 | 2004-09-08 | コクヨ株式会社 | 流通支援設備 |
| JP2002300308A (ja) * | 2001-03-30 | 2002-10-11 | Ricoh Co Ltd | 顧客支援システム、オフィスシステム、顧客支援センター、サプライセンター及び顧客支援方法 |
| US20030171998A1 (en) * | 2002-03-11 | 2003-09-11 | Omnicell, Inc. | Methods and systems for consolidating purchase orders |
| US6760640B2 (en) * | 2002-03-14 | 2004-07-06 | Photronics, Inc. | Automated manufacturing system and method for processing photomasks |
| US6842881B2 (en) | 2002-07-30 | 2005-01-11 | Photronics, Inc. | Rule based system and method for automatically generating photomask orders in a specified order format |
| US7640529B2 (en) * | 2002-07-30 | 2009-12-29 | Photronics, Inc. | User-friendly rule-based system and method for automatically generating photomask orders |
| US7669167B2 (en) * | 2002-07-30 | 2010-02-23 | Photronics, Inc. | Rule based system and method for automatically generating photomask orders by conditioning information from a customer's computer system |
| US8024236B2 (en) * | 2002-11-22 | 2011-09-20 | Eastman Kodak Company | Method and apparatus for reducing supply orders in inventory management |
| JP2005078111A (ja) * | 2003-08-29 | 2005-03-24 | Fujitsu Ltd | データ分類処理装置、データ分類方法、プログラム及び可搬記憶媒体 |
| US8145543B2 (en) * | 2003-10-17 | 2012-03-27 | International Business Machines Corporation | Method, system and program product for approving item requests |
| US8370184B2 (en) * | 2004-03-08 | 2013-02-05 | Sap Aktiengesellschaft | System and method for assortment planning |
| US8050990B2 (en) | 2004-03-08 | 2011-11-01 | Sap Ag | Method of and system for generating purchase orders using an auction process |
| US8423428B2 (en) | 2004-03-08 | 2013-04-16 | Sap Ag | Method for allocation of budget to order periods and delivery periods in a purchase order system |
| US7813949B2 (en) * | 2004-03-08 | 2010-10-12 | Sap Ag | Method and system for flexible budgeting in a purchase order system |
| US7752067B2 (en) * | 2004-03-08 | 2010-07-06 | Sap Aktiengesellschaft | System and method for assortment planning |
| US7805335B2 (en) * | 2004-03-08 | 2010-09-28 | Sap Ag | Purchase list having status indicators |
| US8639548B2 (en) * | 2004-03-08 | 2014-01-28 | Sap Aktiengesellschaft | System and method for assortment planning |
| US7983962B2 (en) * | 2004-03-08 | 2011-07-19 | Sap Aktiengesellschaft | Method and system for purchase order data entry |
| US8027886B2 (en) * | 2004-03-08 | 2011-09-27 | Sap Aktiengesellschaft | Program product for purchase order processing |
| US8046273B2 (en) | 2004-03-08 | 2011-10-25 | Sap Ag | System and method for purchase order creation, procurement, and controlling |
| US8392231B2 (en) * | 2004-03-08 | 2013-03-05 | Sap Aktiengesellschaft | System and method for performing assortment definition |
| US8285584B2 (en) * | 2004-03-08 | 2012-10-09 | Sap Ag | System and method for performing assortment planning |
| US8050956B2 (en) * | 2004-03-08 | 2011-11-01 | Sap Ag | Computer-readable medium, program product, and system for providing a schedule bar with event dates to monitor procurement of a product |
| US7647250B2 (en) * | 2004-03-08 | 2010-01-12 | Sap Ag | Method and program product for event monitoring |
| US7660742B2 (en) | 2004-03-08 | 2010-02-09 | Sap Aktiengesellschaft | Method of and system for processing purchase orders |
| US8108270B2 (en) * | 2004-03-08 | 2012-01-31 | Sap Ag | Method and system for product layout display using assortment groups |
| EP1779308A4 (en) | 2004-06-09 | 2009-05-06 | Us Bancorp Licensing Inc | SYSTEM AND METHOD FOR PROCESSING TRANSACTIONS BASED ON A FINANCIAL ESTABLISHMENT |
| US7822653B2 (en) * | 2004-06-09 | 2010-10-26 | Syncada Llc | Transaction accounting payment and classification system and approach |
| US8762238B2 (en) | 2004-06-09 | 2014-06-24 | Syncada Llc | Recurring transaction processing system and approach |
| US7574386B2 (en) | 2004-06-09 | 2009-08-11 | U.S. Bank National Association | Transaction accounting auditing approach and system therefor |
| WO2005124638A2 (en) | 2004-06-09 | 2005-12-29 | U.S. Bancorp Licensing, Inc. | Order-resource fulfillment and management system and approach |
| US20060122724A1 (en) * | 2004-12-07 | 2006-06-08 | Photoronics, Inc. 15 Secor Road P.O. Box 5226 Brookfield, Connecticut 06804 | System and method for automatically generating a tooling specification using a logical operations utility that can be used to generate a photomask order |
| US20070027891A1 (en) * | 2005-08-01 | 2007-02-01 | Christiane Schauerte | System and method for providing listing check functionality |
| US8200579B2 (en) * | 2006-02-28 | 2012-06-12 | The Invention Science Fund I, Llc | Using payment mode rankings responsive to item attributes |
| US7953664B2 (en) * | 2006-02-28 | 2011-05-31 | The Invention Science Fund I, Llc | Using payment indicators in a common image |
| JP2008090667A (ja) * | 2006-10-03 | 2008-04-17 | Fuji Xerox Co Ltd | ワークフロー管理プログラムおよびワークフロー管理システム |
| US8712884B2 (en) | 2006-10-06 | 2014-04-29 | Syncada Llc | Transaction finance processing system and approach |
| US8751337B2 (en) | 2008-01-25 | 2014-06-10 | Syncada Llc | Inventory-based payment processing system and approach |
| US7991659B2 (en) * | 2008-02-11 | 2011-08-02 | International Business Machines Corporation | Accounting data retrieval method and system |
| JP2012137897A (ja) * | 2010-12-27 | 2012-07-19 | Nec Fielding Ltd | 情報管理システム、情報管理装置、情報管理方法、及び情報管理プログラム |
| JP5965999B2 (ja) * | 2012-05-17 | 2016-08-10 | 株式会社日立製作所 | ジョブ実行システム、ジョブ実行プログラム、ジョブ実行方法 |
| US20160225065A1 (en) * | 2015-02-03 | 2016-08-04 | Amazon Technologies, Inc. | Universal business procurement |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5319542A (en) * | 1990-09-27 | 1994-06-07 | International Business Machines Corporation | System for ordering items using an electronic catalogue |
| JP2770709B2 (ja) | 1993-06-11 | 1998-07-02 | 日本電気株式会社 | 電子伝票システム |
| JPH0728912A (ja) | 1993-07-15 | 1995-01-31 | Hitachi Ltd | 予算額確認方式 |
| JPH0850582A (ja) | 1994-08-04 | 1996-02-20 | Sanyo Electric Co Ltd | 家計簿機能を有する文書作成装置 |
| JP3490555B2 (ja) | 1995-10-02 | 2004-01-26 | 株式会社リコー | 発注管理システム |
| US5758327A (en) * | 1995-11-01 | 1998-05-26 | Ben D. Gardner | Electronic requisition and authorization process |
| US5870717A (en) * | 1995-11-13 | 1999-02-09 | International Business Machines Corporation | System for ordering items over computer network using an electronic catalog |
| JPH10261026A (ja) | 1997-01-14 | 1998-09-29 | Fujitsu Ltd | 電子商取引システムおよび記録媒体 |
| JP2000029963A (ja) | 1998-07-09 | 2000-01-28 | Ntt Data Corp | 電子決裁システム |
| JP2000076342A (ja) * | 1998-09-01 | 2000-03-14 | Canon Inc | 購買依頼承認装置及び購買依頼承認方法及びコンピュータ読み取り可能な記憶媒体 |
| JP2000132596A (ja) | 1998-10-21 | 2000-05-12 | Ntt Data Corp | 電子商取引システム及び電子商取引センタ |
-
2000
- 2000-11-13 JP JP2000344735A patent/JP3982168B2/ja not_active Expired - Lifetime
-
2001
- 2001-11-13 US US09/987,194 patent/US7353195B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7353195B2 (en) | 2008-04-01 |
| US20020059122A1 (en) | 2002-05-16 |
| JP2002150066A (ja) | 2002-05-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3982168B2 (ja) | 購買管理システム、購買管理方法、及び購買管理用プログラム | |
| JP3941358B2 (ja) | 受発注システム、記憶媒体、及び流通支援システム | |
| US7774238B2 (en) | Online marketplace management system with automated pricing tool | |
| US7024382B2 (en) | System and method for managing retail and wholesale operations | |
| EP1764735A1 (en) | Computer-based retail data management system and method thereof | |
| US20020052801A1 (en) | Hosted asset procurement system and method | |
| US20020072999A1 (en) | System and method for providing integrated inventory control of time-sensitive inventory | |
| JP2007536627A (ja) | 電子カタログのサプライヤ・ポータルのためのシステムおよび方法 | |
| JP3978991B2 (ja) | 受発注システム、及び記憶媒体 | |
| US20060047547A1 (en) | System and method for automated product design and approval | |
| US8738428B2 (en) | Managing retail promotion events | |
| US8473370B1 (en) | Method and apparatus for generating an order for purchase | |
| JP4448272B2 (ja) | ネットワークシステム、購入履歴提示方法、サーバ装置、プログラム、および記録媒体 | |
| JP2007025772A (ja) | 共同購入システム、共同購入方法およびプログラム | |
| Learmonth | Information system technology can improve customer service | |
| US7533039B2 (en) | Bulk ordering | |
| Becker et al. | Retail information systems based on SAP products | |
| JP4134631B2 (ja) | データ管理装置及びデータ管理方法 | |
| JP2003223543A (ja) | 採算管理システムおよび採算管理方法 | |
| JP2005208835A (ja) | 広告媒体管理用データベースシステム | |
| JP2002133197A (ja) | 発注代行システム | |
| JP2023159577A (ja) | 情報処理装置、情報処理方法、及びプログラム | |
| JP2003036293A (ja) | 営業・製造・購買支援方法、それを用いたシステム及び記憶媒体 | |
| JP2002074116A (ja) | 製品販売方法及びシステム | |
| JP4541040B2 (ja) | 商品流通方法及び商品流通プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040216 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20060421 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060726 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060925 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20060925 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20061219 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070216 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070323 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070612 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070625 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100713 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3982168 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100713 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110713 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110713 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120713 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120713 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130713 Year of fee payment: 6 |
|
| EXPY | Cancellation because of completion of term |