(57)【特許請求の範囲】
【請求項１】
マスタデータの保持管理を行うサーバと、
前記マスタデータの更新情報を含むマスタデータ更新要求を前記サーバへ発するクライアントと、
を有する分散データ処理システムにおいて、
前記サーバは、
前記クライアントを使用する各ユーザに対して設定された全ての前記マスタデータの更新可否に関する制約条件を保持するサーバ側制約条件情報記憶手段と、
前記クライアントから送られてきたマスタデータ更新要求の更新内容が、前記サーバ側制約条件情報記憶手段に保持されている制約条件及び前記マスタデータの設定値の双方から導かれる受入条件を満たすか否かを判断し、その判断結果を当該クライアントへ返信すると共に受入条件を満たす場合にのみ当該マスタデータ更新要求に応じて前記マスタデータの更新を行うマスタデータ管理手段と、
を有し、
前記クライアントは、
前記サーバ側制約条件情報記憶手段に保持されている制約条件のうち当該クライアントを使用するユーザに対する制約条件を保持するクライアント側制約条件情報記憶手段と、
ユーザにより要求されたマスタデータの更新内容に基づきマスタデータ更新要求を生成し、そのマスタデータの更新内容が前記クライアント側制約条件情報記憶手段に保持されている制約条件を満たす場合には当該マスタデータ更新要求を送信せずに要求履歴情報として保存し、当該制約条件を満たさない場合には当該マスタデータ更新要求を前記サーバへ送信する情報更新処理手段と、
を有することを特徴とする分散データ処理システム。
【請求項２】
前記サーバは、前記サーバ側制約条件情報記憶手段の制約条件の更新処理を行うサーバ側制約条件管理手段を有し、前記各クライアントから送られてきた制約条件を前記サーバ側制約条件情報記憶手段に登録することを特徴とする請求項１記載の分散データ処理システム。
【請求項３】
前記サーバは、制約条件の前記サーバ側制約条件情報記憶手段への登録の可否に関する登録条件情報が設定された登録条件記憶手段を有し、
前記サーバ側制約条件管理手段は、前記登録条件情報に基づき前記各クライアントから送られてきた制約条件の登録の可否の判定を行うことを特徴とする請求項１記載の分散データ処理システム。
【請求項４】
前記マスタデータ管理手段は、前記情報更新処理手段から送られてきた要求履歴情報に基づきマスタデータの更新を行い、
前記サーバ側制約条件管理手段は、当該要求履歴情報に該当する制約条件の更新を行うことを特徴とする請求項１記載の分散データ処理システム。
【請求項５】
前記クライアントは、前記クライアント側制約条件情報記憶手段の情報管理を行うクライアント側制約条件管理手段を有し、
前記クライアント側制約条件管理手段は、設定入力された制約条件の登録要求を前記サーバへ送信し、その登録要求に対して登録可の回答が得られたときには当該制約条件を前記クライアント側制約条件情報記憶手段に登録することを特徴とする請求項１記載の分散データ処理システム。
【請求項６】
前記サーバ側制約条件管理手段は、前記サーバ側制約条件情報記憶手段に登録されている制約条件に付加された有効期限情報に従い、有効期限に達した当該制約条件を自動削除することを特徴とする請求項１記載の分散データ処理システム。
【請求項７】
前記クライアント側制約条件管理手段は、前記クライアント側制約条件情報記憶手段に登録されている制約条件に付加された有効期限情報に従い、有効期限に達した当該制約条件を自動削除することを特徴とする請求項１記載の分散データ処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は分散データ処理システム、特にオフライン接続されたクライアントからアクセスされる、サーバが保持管理するマスタデータに設定されているデータ値の保証に関する。
【０００２】
【従来の技術】
近年のモバイルコンピューティングの発達に伴い、営業者が携帯型のクライアント端末を持ち運び、客先でクライアント端末を用いて在庫情報を確認しながら販売業務を行うような営業形態は一般的になってきている。客先の製品の注文数の在庫の有無を確認する方法として大きく２つの方法がある。
【０００３】
一つは、クライアント端末に携帯電話を接続し、事務所にあるホストコンピュータの在庫情報マスタに直接アクセスをして在庫の確認を行う方法である。この方法は、ホストコンピュータにオンライン接続することによって現時点での在庫情報をリアルタイムに参照することができるので、欠品しているのにもかかわらず注文を受け付けてしまうということがない。
【０００４】
もう一つは、ホストコンピュータにある在庫情報マスタのレプリケーションデータをクライアント端末に持たせ、客先ではオフラインのままクライアント端末にあるレプリケーションデータを参照することで在庫の確認を行う方法である。この方法は、在庫の確認をする度にオンライン接続をしなくてもよく、即座に在庫の確認をとることができる。
【０００５】
【発明が解決しようとする課題】
しかしながら、上記２つの方法は、それぞれに前述したような長所があるものの他方の方法の長所をそのまま短所として持っていることになる。すなわち、在庫の確認を行う度毎にホストコンピュータへオンライン接続をする方法では、情報量が膨大なときには在庫の確認に多くの時間を要してしまう。また、携帯電話等が使用できないところでは在庫の確認を全く行うことができない。一方、クライアント端末に在庫情報を記憶させるオフラインによる方法では、データの整合性をとった時点での在庫情報マスタとクライアント端末上のレプリケーションデータとは一致しており、クライアント端末にコピーした在庫情報は保証されるが、客先へ移動した他の営業者の契約内容を自己のクライアント端末に即座に反映することができないので在庫情報が保証されない。つまり、在庫情報をコピーしたときには在庫があったとしても契約時点では在庫が不足している場合が生じてしまう場合がありうる。
【０００６】
本発明は以上のような問題を解決するためになされたものであり、その目的は、サーバが管理するマスタデータに対する制約条件を付与することによってオフラインで利用されるクライアントにおいて更新対象とするマスタデータをある程度の範囲で保証しうる分散データ処理システムを提供することにある。
【０００７】
【課題を解決するための手段】
以上のような目的を達成するために、本発明に係る分散データ処理システムは、マスタデータの保持管理を行うサーバと、前記マスタデータの更新情報を含むマスタデータ更新要求を前記サーバへ発するクライアントとを有する分散データ処理システムにおいて、前記サーバは、前記クライアントを使用する各ユーザに対して設定された全ての前記マスタデータの更新可否に関する制約条件を保持するサーバ側制約条件情報記憶手段と、前記クライアントから送られてきたマスタデータ更新要求の更新内容が、前記サーバ側制約条件情報記憶手段に保持されている制約条件及び前記マスタデータの設定値の双方から導かれる受入条件を満たすか否かを判断し、その判断結果を当該クライアントへ返信すると共に受入条件を満たす場合にのみ当該マスタデータ更新要求に応じて前記マスタデータの更新を行うマスタデータ管理手段とを有し、前記クライアントは、前記サーバ側制約条件情報記憶手段に保持されている制約条件のうち当該クライアントを使用するユーザに対する制約条件を保持するクライアント側制約条件情報記憶手段と、ユーザにより要求されたマスタデータの更新内容に基づきマスタデータ更新要求を生成し、そのマスタデータの更新内容が前記クライアント側制約条件情報記憶手段に保持されている制約条件を満たす場合には当該マスタデータ更新要求を送信せずに要求履歴情報として保存し、当該制約条件を満たさない場合には当該マスタデータ更新要求を前記サーバへ送信する情報更新処理手段とを有するものである。
【０００８】
また、前記サーバは、前記サーバ側制約条件情報記憶手段の制約条件の更新処理を行うサーバ側制約条件管理手段を有し、前記各クライアントから送られてきた制約条件を前記サーバ側制約条件情報記憶手段に登録するものである。
【０００９】
また、前記サーバは、制約条件の前記サーバ側制約条件情報記憶手段への登録の可否に関する登録条件情報が設定された登録条件記憶手段を有し、前記サーバ側制約条件管理手段は、前記登録条件情報に基づき前記各クライアントから送られてきた制約条件の登録の可否の判定を行うものである。
【００１１】
更に、前記マスタデータ管理手段は、前記情報更新処理手段から送られてきた要求履歴情報に基づきマスタデータの更新を行い、前記サーバ側制約条件管理手段は、当該要求履歴情報に該当する制約条件の更新を行うものである。
【００１２】
更にまた、前記クライアントは、前記クライアント側制約条件情報記憶手段の情報管理を行うクライアント側制約条件管理手段を有し、前記クライアント側制約条件管理手段は、設定入力された制約条件の登録要求を前記サーバへ送信し、その登録要求に対して登録可の回答が得られたときには当該制約条件を前記クライアント側制約条件情報記憶手段に登録するものである。
【００１３】
また、前記サーバ側制約条件管理手段は、前記サーバ側制約条件情報記憶手段に登録されている制約条件に付加された有効期限情報に従い、有効期限に達した当該制約条件を自動削除するものである。
【００１４】
更に、前記クライアント側制約条件管理手段は、前記クライアント側制約条件情報記憶手段に登録されている制約条件に付加された有効期限情報に従い、有効期限に達した当該制約条件を自動削除するものである。
【００１５】
【発明の実施の形態】
以下、図面に基づいて、本発明の好適な実施の形態について説明する。
【００１６】
実施の形態１．
図１は、本発明に係る分散データ処理システムの一実施の形態を適用した営業支援システムの全体構成図である。このシステムは、営業事務所に設置された在庫情報マスタを有するサーバ装置１と各営業員によって携帯される複数のクライアント端末２とを有している。営業員は、クライアント端末２を用いてサーバ装置１に格納されている在庫情報マスタをアクセスすることによって在庫の確認を行う。営業員は、外出先からは携帯電話等を用いて公衆回線３を介してサーバ装置１にアクセスを行う。また、事務所内にいるときはクライアント端末２をＬＡＮ４に接続してアクセスを行う。
【００１７】
図２は、本実施の形態における分散データ処理システムの機能ブロック構成図である。なお、クライアント端末２は、全て同じ機能を有しておけばよいので、図２では、便宜的に１台のみ示す。
【００１８】
サーバ装置１は、製品に関するマスタデータとして製品情報マスタ１１を保有しており、この製品情報マスタ１１には、図３に示したように製品毎に製品名、型番、更に在庫数量等各製品に関するマスタデータが予め設定されている。また、サーバ装置１に構築された分散データ管理システムには、在庫管理処理部１２、制約条件管理テーブル１３、制約条件管理部１４及び制約管理マスタ１５が含まれている。在庫管理処理部１２は、製品情報マスタ１１に設定された在庫数量の更新等在庫管理に関する処理全般を行うが、本実施の形態においては、更にクライアント端末２からの在庫数量の確認の問合せの際、製品情報マスタ１１の在庫数量及び制約条件管理テーブル１３に設定された制約条件に基づいて在庫の有無を回答するマスタデータ管理手段としても設けられている。
【００１９】
制約条件管理テーブル１３は、製品情報マスタ１１の更新可否に関する制約条件を保持するサーバ側制約条件情報記憶手段である。制約条件管理部１４は、制約条件管理テーブル１３への制約条件の登録、削除、変更などのデータ管理を行うサーバ側制約条件管理手段として設けられている。制約管理マスタ１５は、制約条件の制約条件管理テーブル１３への登録の可否に関する登録条件情報が設定された登録条件記憶手段として設けられている。更に、サーバ装置１には、クライアント端末２との間の通信制御を行う通信制御処理部１６が設けられている。
【００２０】
一方、クライアント端末２の分散データ管理システムには、受注処理部２１、制約条件管理テーブル２２、制約条件管理部２３及び受注履歴情報蓄積部２４が含まれている。受注処理部２１は、情報更新処理手段として設けられており、設定入力された契約条件に基づき在庫の確認を行う。特に、該当する制約条件が制約条件管理テーブル２２に登録されていない場合には、マスタデータ更新要求に相当する在庫確認要求をサーバ装置１に送信する。制約条件管理テーブル２２は、制約条件管理テーブル１３と同様に制約条件が登録されるクライアント端末２における制約条件情報記憶手段であるが、制約条件管理テーブル１３にはシステム全体における制約条件が登録されるのに対して、制約条件管理テーブル２２には当該クライアント端末２を使用する営業員のための制約条件のみが登録される。制約条件管理部２３は、制約条件管理テーブル２２への制約条件の登録、削除、変更などのデータ管理を行うクライアント側制約条件管理手段として設けられている。受注履歴情報蓄積部２４は、マスタデータ更新要求の内容を満たす、例えば契約条件に含まれる受注数の在庫が仮押さえされていれば、その契約条件に基づく在庫確認要求をサーバ装置１に送信せずに受注情報として保存するための要求履歴情報記憶手段である。
【００２１】
更に、クライアント端末２には、営業員との間のインタフェースを形成する入出力制御処理部２５と、サーバ装置１との間の通信制御を行う通信制御処理部２６とが設けられている。
【００２２】
図４及び図５は、本実施の形態において特徴的なサーバ装置１及びクライアント端末２にそれぞれ設定される制約条件管理テーブル１３，２２のデータ構成例を示した図である。ともに同じデータ構成なのでまとめて説明する。
【００２３】
本実施の形態では、営業員毎に制約条件が設定できるようにしているので、「ユーザＩＤ」には、制約条件を設定した営業員の識別情報が設定される。「行ＩＤ」は、制約条件を付与する製品を識別するための情報であり、製品情報マスタ１１に登録されている製品ＩＤが設定される。「カラムＩＤ」は、制約条件を付与するマスタデータを特定するための情報であり、製品情報マスタ１１に製品毎に設定される価格、値引率、在庫数量等のマスタデータとなる各項目が設定される。「制約の種類」には制約条件の種類を指定し、「制約条件」には対応する制約の種類に付与する条件（値）を指定する。「有効期限」は、当該レコードの有効期限である。「登録日」は、制約条件が登録された日付情報である。図４に示したレコード２２ａの例によると、営業員Ａは、製品ＩＤが１２９である製品を１０個分仮押さえしていることを示しており、有効期限が「解除まで」なので、レコ−ド削除が人的にされるまでこのレコード２２ａの設定内容は有効であることを意味する。なお、本実施の形態のように、各営業員が特定の１台のクライアント端末２を常時使用することを前提とすれば、「ユーザＩＤ］の代わりにクライアント端末２の識別情報を用いることができる。
【００２４】
本実施の形態において特徴的なことは、複数の営業員により複数のクライアント端末２から更新されうる製品情報マスタ１１に対して、各営業員が制約条件を設定できるようにしたことである。例えば、営業員甲が製品Ａに対して在庫数が１０未満にならないような制約条件を設定したとすると、これによって営業員甲にとってみれば、製品Ａに対する在庫数は一定（１０個）以上であることが保証されることになる。すなわち、営業支援システムは、甲以外の営業員が当該製品の在庫数が１０個未満にならないような契約をしようとしたのであればそのままその契約を認めるが、１０個未満になるような契約をしようとした場合は、その契約に指定された受注数の在庫が実際には製品情報マスタ１１にあったとしてもその契約を認めないようにした。このように、各営業員により設定された制約条件を満たさない契約は受け入れないようにしたので、クライアント端末２がオフラインのままでも製品情報マスタ１１のデータ内容が保証されることになる。
【００２５】
次に、本実施の形態における動作について説明する。まず、最初に、クライアント端末２からオンラインで行う制約条件設定処理について図６及び図７に示したフローチャートを用いて説明する。
【００２６】
通常、各営業員が販売する製品はある程度特定されており、また、今までの契約の交渉の内容によって契約が取れるであろう製品や数はある程度の見込みがつくと思われる。この場合、受注できるであろう製品分の在庫があることが保証されていれば、営業員にとって望ましいことである。そこで、営業員が契約が取れることを予想してその製品を予め確保するためにこの制約条件設定処理が行われる。
【００２７】
図６において、例えば、営業員は、外出前、すなわち事務所にいるときＬＡＮ経由でサーバ装置１に接続し、所定の設定画面から制約条件を設定入力すると、制約条件管理部２３は、入出力制御処理部２５を介してその制約条件を受け付ける（ステップ１０１）。ここで入力される項目は、前述した制約条件管理テーブル２２を構成する項目である。制約条件管理部２３は、設定入力された制約条件をサーバ装置１に送ることで制約条件の登録要求を出す（ステップ１０２）。
【００２８】
図７において、サーバ装置１の制約条件管理部１４は、クライアント端末２からの制約条件を含む登録要求を受け取ると（ステップ１１１）、その制約条件を受け入れることができるかどうかの判定を、現時点において製品情報マスタ１１に設定されている在庫数量と制約条件管理テーブル１３にすでに設定されている製品の仮押さえに対する制約条件とに基づき行う（ステップ１１２）。例えば、製品Ａを１０個仮押さえしたいという制約条件が送られてきたとき、製品情報マスタ１１に設定されている在庫数量が２０であり、他の営業員により製品Ａに対して８個の仮押さえの制約条件が制約条件管理テーブル１３にすでに登録されていたとすると、制約条件管理部１４は、その制約条件を受け入れたとしてもまだ２（＝２０−８−１０）個の製品Ａが残るのでその制約条件を受け付けることができると判定する。このとき、受け付けた制約条件を制約条件管理テーブル１３に登録するとともに（ステップ１１３，１１４）、その旨を当該クライアント端末２に回答する（ステップ１１５）。
【００２９】
一方、製品情報マスタ１１に設定されている在庫数量が２０であり、他の営業員により製品Ａに対して１５個の仮押さえの制約条件が制約条件管理テーブル１３にすでに登録されていたとすると、制約条件管理部１４は、１０個分の仮押さえをすることができないので、その制約条件を受け付けることができないと判定して、当該クライアント端末２にその旨を返答する（ステップ１１３，１１５）。この際、再設定のための判断材料として現時点における製品Ａの在庫数量を送信するようにしてもよい。
【００３０】
図６において、クライアント端末２の制約条件管理部２３は、サーバ装置１から送られてきた回答を受け取る（ステップ１０３）。登録要求を受け入れるという回答であれば、その制約条件を制約条件管理テーブル２２に登録する（ステップ１０４，１０５）。登録要求が受け入れられないという回答であれば、営業員は、仮押さえを断念するか、あるいは現時点における製品Ａの在庫数量を参考に可能な範囲数で仮押さえを行う。
【００３１】
なお、制約条件設定処理において制約条件管理テーブル１３にすでに設定されている制約条件と、同一の製品（行ＩＤ）、項目（カラムＩＤ）及び制約の種類に対する制約条件が同一営業員から送られてきた場合、その送られてきた制約条件をエラーとしたり、その制約条件で上書きしたり、あるいは在庫数量などは加算するなどして対処する。
【００３２】
次に、営業員が客先でのクライアント端末２を用いて契約を取り付けるために在庫数量を確認する在庫確認処理について図８及び図９に示したフローチャートを用いて説明する。
【００３３】
図８において、客先において商談がまとまって契約が取れたとすると、営業員は、その契約条件をクライアント端末２から入力する。受注処理部２１は、入力された契約条件を受け付けると（ステップ２０１）、その入力された情報に含まれる製品とその受注数に基づきその受注製品の在庫数の確認を行うために制約条件管理部２３を介して制約条件管理テーブル２２へアクセスをする（ステップ２０２）。この在庫の確認を、本実施の形態ではクライアント端末２に設けた制約条件管理テーブル２２を最初に参照しにいくことによって行うことを特徴としている。例えば、製品ＩＤが１２９である製品Ａを８個受注したとすると、受注処理部２１は、制約条件管理テーブル２２を参照して８個以上の製品Ａの仮押さえがされているかを確認する。図４のレコード２２ａに示したような制約条件が制約条件管理テーブル２２に登録されていれば、この製品Ａに関しては、当該クライアント端末２を使用している営業員Ａのために１０個の在庫数が保証されているので、受注処理部２１は、在庫有りと判断してその旨を営業員に画面表示するなどして回答する（ステップ２０３，２０８）。すなわち、受注処理部２１は、在庫数量の確認をするためにサーバ装置１１へのアクセスを行わない。これにより、営業員は、公衆回線を介してサーバ装置１１と接続することなく即座に契約書を締結することができる。また、在庫確認のために通信コストを発生させずにすむ。
【００３４】
そして、受注処理部２１は、契約が締結されたことを確認すると、その受注した製品及びその受注数、代金等の契約締結に関する受注情報を受注履歴情報蓄積部２４に保存する（ステップ２０９）。
【００３５】
また、例えば、製品Ａを１５個受注したとき、仮押さえした在庫数は不足しているのでサーバ装置１１に在庫確認を行う必要が生じる。当該製品の仮押さえに関する制約条件が制約条件管理テーブル２２に登録されていない場合も同様である。このとき、受注処理部２１は、通信制御処理部２６を介してサーバ装置１１に接続して在庫管理処理部１２に対してマスタデータ更新要求に相当する在庫確認要求を発信して製品Ａの在庫数の確認を行う（ステップ２０４，２０５）。なお、営業員が客先が通信不可能な場所等の理由でサーバ装置１１に問合せを行わない場合には本在庫確認処理を終了する。もし、契約条件を変えて商談を進める場合には、再度在庫確認処理を開始する。
【００３６】
図９において、在庫管理処理部１２は、在庫確認要求を受け取ると（ステップ２２１）、その在庫確認要求に含まれているユーザＩＤ、製品ＩＤ、受注数に基づき制約条件管理テーブル１３と製品情報マスタ１１を参照することによって在庫の確認を行う。すなわち、この在庫確認要求に指定された製品に関して、製品情報マスタ１１に設定されている在庫数量から制約条件管理テーブル１３に登録されているカラムＩＤが「在庫数量」でかつ制約の種類が「仮押さえ」の当該製品に対する在庫数量（「制約条件」）の和を差し引いた算出値が在庫確認要求に指定された受注数を上回っているときに在庫有りと判断する。本実施の形態では、製品情報マスタ１１に設定されている在庫数量の値のみに基づくのではなく、上記算出値が受注数以上であるときにはじめて在庫有りと判断する。在庫有りと判断した場合は、製品情報マスタ１１に設定されている在庫数量を受注数で減算した値により更新する（ステップ２２４）。そして、在庫管理処理部１２は、在庫有りの旨の回答をする（ステップ２２５）。一方、受注数が算出値を上回っているときには在庫がないと判断して在庫無しの旨の回答をする（ステップ２２３，２２５）。
【００３７】
図８において、受注処理部２１は、在庫管理処理部１２から発信した在庫確認要求に対する回答を受け取る（ステップ２０６）。在庫有りという回答を受け取ったときにはその旨を画面表示するなどして営業員に回答する（ステップ２０７，２０８）。そして、受注処理部２１は、契約が締結されたことを確認できると、その受注した製品及びその受注数、代金等の契約締結に関する受注情報を受注履歴情報蓄積部２４に保存する（ステップ２０９）。
【００３８】
一方、受注処理部２１は、在庫無しという回答を受け取ったときにはその旨を営業員に回答する（ステップ２０７，２１０）。このように、製品情報マスタ１１を管理しているサーバ装置１１に対して問い合わせたことで、保証された在庫の確認結果を得ることができる。
【００３９】
次に、営業員が契約の締結後、事務所に戻ったときにあるいは外出先において契約締結に伴う製品情報マスタ１１及び制約条件管理テーブル１３，２２のデータ更新を行う。この情報更新処理について図１０及び図１１に示したフローチャートを用いて説明する。
【００４０】
図１０において、営業員は、クライアント端末２の受注履歴情報蓄積部２４に蓄積しておいた受注情報を製品情報マスタ１１に反映する必要がある。そのため、クライアント端末２をサーバ装置１に接続して受注情報を送出する（ステップ３０１）。
【００４１】
図１１において、在庫管理処理部１２は、クライアント端末２から受注情報を受け取ると（ステップ３１１）、製品情報マスタ１１に設定されている当該製品の在庫数量を、受注情報に含まれている製品の受注数で減算することによって更新する（ステップ３１２）。更に、制約条件管理テーブル１３に登録されている該当する制約条件の更新を行う（ステップ３１３）。更新対象となる制約条件は、当該受注情報に含まれているユーザＩＤ、製品ＩＤ及び制約の種類が「仮押さえ」の制約条件を見つけだすことで特定でき、本実施の形態では削除することにする。
【００４２】
図１０において、製品情報マスタ１１が正常に更新されたことを確認すると、受注処理部２４は、当該受注情報を受注履歴情報蓄積部２４から削除する（ステップ３０２）。そして、該当する制約条件を制約条件管理テーブル２２から削除する（ステップ３０３）。
【００４３】
なお、本実施の形態では、処理の簡略化のために制約条件管理テーブル１３，２２から該当する制約条件を削除するようにしたが、仮押さえをした在庫数量（「制約条件」）を受注数で減算するようにしてもよい。また、情報更新処理を逐次行わずに継続して営業活動を行うためには、契約が締結した時点で制約条件管理テーブル２２に登録されている制約条件の在庫数を減算することが望ましいが、本実施の形態では説明の簡略化のために情報更新処理で制約条件管理テーブル１３とともに制約条件管理テーブル２２を更新するようにした。いずれにせよ、各制約条件管理テーブル１３，２２において対応する制約条件の内容を一致させていればよい。
【００４４】
本実施の形態によれば、製品情報マスタ１１のデータ更新をする際の制約条件を設定できるようにしたので、各営業員に対して製品情報マスタ１１にアクセスさせなくても一定以上の在庫が確保されていることを保証することができる。
【００４５】
また、本実施の形態においては、制約条件に有効期限情報が付加されている。前述したように、有効期限が「解除まで」と設定されていれば、営業員やシステム管理者により人的に削除されるまでその制約条件は登録されたままである。有効期限に「１週間」等の終期が設定されていれば、本実施の形態における制約条件管理部１４，２３は、各制約条件管理テーブル１３，２２に登録されている制約条件の有効期限情報を定期的にチェックして、登録日からその終期に達した制約条件を各制約条件管理テーブル１３，２２から自動削除する。
【００４６】
ところで、本実施の形態では、在庫数量等マスタデータと制約条件管理テーブル１３の登録内容とを参照した結果満足するものであれば、いずれの営業員でも所望する制約条件を設定登録できるようにした。しかし、実際には営業活動全体からして制約条件の登録を無条件に認めていたのでは、不都合が生じる可能性がある。そこで、制約条件の制約条件管理テーブル１３への登録の可否に関する登録条件情報を登録条件記憶手段として設けた制約管理マスタ１５に予め設定しておき、登録条件情報を満足した制約条件のみ制約条件管理テーブル１３への登録を許可するようにした。制約条件管理テーブル１３への登録条件としては、役職や過去の実績等に基づき職位毎、営業員毎あるいは数量に関するマスタデータであれば更に上下限等が設定される。
【００４７】
従って、制約条件管理部１４は、各クライアント端末２から制約条件の登録要求が送られてきた場合には、製品情報マスタ１１のマスタデータ値と制約条件管理テーブル１３の登録内容のみならず制約管理マスタ１５に登録されている登録条件に基づきその制約条件の登録の可否の判定を行い、登録可と判定した場合にその制約条件を制約条件管理テーブル１３に登録することになる（図７のステップ１１４）。なお、制約条件管理テーブル１３への登録が可と判定されてはじめて制約条件の登録要求を発したクライアント端末２の制約条件管理テーブル２２にその制約条件が登録されることになるので、制約管理マスタ１５に設定された登録条件情報は、制約条件管理テーブル２２への登録条件でもある。本実施の形態によれば、制約条件の登録可否の判定を行った後に制約条件管理テーブル１３へ登録をするようにしたので、不都合な制約条件が設定されることを防止することができる。
【００４８】
以上、本実施の形態によれば、制約条件を設定できるようにしたことによりサーバ装置１に接続されていない状態でもマスタデータを保証させることができるようにしたが、上記実施の形態は、本発明の一形態であり、以下に示すような様々な変更を行うことができる。
【００４９】
上記説明したサーバ装置１１における在庫確認処理において在庫の確認を行う際、在庫確認要求に含まれているユーザＩＤの営業員による条件を満たさない制約条件が含まれていることもあり得る。例えば、上記のように、１０個の仮押さえをしているところに１５個の受注がされた場合がこれに該当する。この場合には、当該営業員による制約条件を無視して仮押さえのされていない在庫から優先的に割り当てるようにしてもよいし、当該営業員による制約条件で仮押さえされた在庫から割り当てるようにしてもよい。
【００５０】
また、本実施の形態では、所定数の在庫を仮押さえすることによってサーバ装置１に問い合わせなくても一定以上の在庫があることを保証することを特徴としているため、契約条件を満たす制約条件が制約条件管理テーブル２２に登録されていることを最初に検証する必要があるが、この特徴的な機能処理と常時サーバ装置１に問い合わせる従来からある機能処理とを選択的に使用できるようにしてもよい。
【００５１】
また、本実施の形態では、説明の簡略のために単一の製品の在庫確認を行う場合を例にして説明をしたが、複数の製品について同時に在庫確認を行うようにしてもよい。
【００５２】
また、営業員は、事務所外へ持ち出すクライアント端末２を事務所内でも使用することを想定して、クライアント端末２からそのクライアント端末２とサーバ装置１それぞれの制約条件管理テーブル２２，１３へ制約条件を登録するようにしたが、クライアント端末２以外の端末装置からでも制約条件管理テーブル２２，１３への登録処理を行うようにすることもできる。また、予め制約条件を登録するようにしてもよい。
【００５３】
また、クライアント端末２側に在庫情報マスタ１１のレプリケーションデータを持たせて、サーバ装置１へアクセスをする前に在庫情報の確認をするようにしてもよい。これにより、所定期間内に在庫数が増えないという前提条件があれば、契約条件が在庫量を確実に超えている場合にサーバ装置１へアクセスしなくてもすむ。
【００５４】
また、本実施の形態では、営業支援システムにおいてマスタデータとして在庫情報を用いて在庫確認を行う場合を例にして説明したが、これに限られたものではない。例えば、商品のレンタルの在庫処理等にも適用可能である。
【００５５】
【発明の効果】
本発明によれば、マスタデータの更新の可否に関する制約条件を設定できるようにし、制約条件を満たす場合にのみマスタデータの更新を行うようにした。すなわち、制約条件を満たさない他のユーザからのマスタデータ更新要求を受け入れないようにしたので、制約条件に対応したユーザに対してマスタデータを保証することができる。
【００５６】
また、サーバ側制約条件管理手段を設けたので、クライアントから送られてきた制約条件をサーバ側制約条件情報記憶手段に登録することができる。
【００５７】
また、制約条件の登録の可否に関する登録条件情報を設定できるようにしたので、制約条件が無条件に登録されることを防止することができる。
【００５８】
また、マスタデータ更新要求がクライアント側に登録されている制約条件を満たす場合には、サーバにアクセスすることなくマスタデータ更新要求が受け入れられたと判断することができる。これにより、マスタデータが更新可能であることをサーバに問い合わせることなく確認することができる。
【００５９】
また、実際にマスタデータの更新がされていないときに要求履歴情報に基づき後からマスタデータ及びサーバ側制約条件記憶手段の更新を行うことができる。
【００６０】
また、クライアント側制約条件管理手段を設けたので、クライアントから制約条件の設定を行うことができる。
【００６１】
また、制約条件に有効期限情報を付加するようにしたので、有効期限に達した制約条件を自動削除することができる。
【図面の簡単な説明】
【図１】本発明に係る分散データ処理システムの一実施の形態を適用した営業支援システムの全体構成図である。
【図２】本実施の形態における分散データ処理システムの機能ブロック構成図である。
【図３】本実施の形態における製品情報マスタのデータ構成例を示した図である。
【図４】本実施の形態におけるクライアント端末に設定される制約条件管理テーブルのデータ構成例を示した図である。
【図５】本実施の形態におけるサーバ装置に設定される制約条件管理テーブルのデータ構成例を示した図である。
【図６】本実施の形態のクライアント端末側における制約条件設定処理を示したフローチャートである。
【図７】本実施の形態のサーバ装置側における制約条件設定処理を示したフローチャートである。
【図８】本実施の形態のクライアント端末側における在庫確認処理を示したフローチャートである。
【図９】本実施の形態のサーバ装置側における在庫確認処理を示したフローチャートである。
【図１０】本実施の形態のクライアント端末側における情報更新処理を示したフローチャートである。
【図１１】本実施の形態のサーバ装置側における情報更新処理を示したフローチャートである。
【符号の説明】
１  サーバ装置、２  クライアント端末、３  公衆回線、４  ＬＡＮ、１１  製品情報マスタ、１２  在庫管理処理部、１３，２２  制約条件管理テーブル、１４，２３  制約条件管理部、１５  制約管理マスタ、１６，２６  通信制御処理部、２１  受注処理部、２４  受注履歴情報蓄積部。
【図１】
0003601579.tif 000002
【図２】
0003601579.tif 000003
【図３】
0003601579.tif 000004
【図４】
0003601579.tif 000005
【図５】
0003601579.tif 000006
【図６】
0003601579.tif 000007
【図７】
0003601579.tif 000008
【図８】
0003601579.tif 000009
【図９】
0003601579.tif 000010
【図１０】
0003601579.tif 000011
【図１１】
0003601579.tif 000012