JP4436923B2 - 使用量取得方法及び使用量取得装置 - Google Patents

Description

本発明は、例えばコピー機の保守サービスにおいて、印刷枚数（カウンタ値）を取得するカウンタ確認業務に適用して好適な使用量取得方法及び使用量取得装置に関する。

従来、顧客企業に対して、コピー機をリースするとともに、リースしたコピー機を使用して印刷した枚数から算出される枚数ごとの使用料金を集計し、請求する業務がある。カウンタ値は、コピー機に内蔵されたカウンタでカウントされ、内蔵メモリにカウンタ値が記録される。そして、コピー機のリース元から依頼されるカウンタ確認作業員は、コピー機の内蔵メモリからカウンタ値を読み出してカウンタ確認業務を行っていた。

コピー機からカウンタ値を取得する作業を、「カウンタ確認」と称する。そして、カウンタ確認し、顧客企業に使用料金を請求する対象期間は、例えば１か月としている。そして、ある月に注目したとき、カウンタ確認を行う対象期間は１日〜月末日までとし、この期間を「当月」と称する。

カウンタ確認業務では、いくつかのカウンタ確認方法が採用されていた。例えば、カウンタ確認方法には、通信回線を通じてデータを取得する方法と、顧客企業の担当者がカウンタ確認し、専用用紙にカウンタ値を記入してハガキ又はＦＡＸでサービス会社に送付する方法と、カウンタ確認作業員がコピー機を設置している現場に赴いてカウンタ確認を行う方法とがあった。

また、サービス会社と顧客企業との間で交わされるリース契約の締結時に決定される料金請求方法には、２種類の方法が存在していた。これらの方法としては、基本料金に使用料金を加えて請求する方法と、当月中で請求できない場合、当月では請求を行わず、当月の使用料金を翌月の請求料金に加えて請求する方法があった。

特許文献１には、ＯＡ装置が送信する記録紙等の消費数量を計量したカウンタ確認データを、ホストコンピュータに送信し、ホストコンピュータは、カウンタ確認データを評価した結果からＯＡ装置の異常の有無を判断する通信システムについて開示されている。
特開２００１−６９２９１号公報

ところで、電話回線を通じてカウンタ確認データを伝送するようにしても、回線障害等によりカウンタ値を収集できない場合がある。また、カウンタ確認作業員が、顧客の事業所に赴いてカウンタ確認を行おうとしても、カウンタ確認作業員が事業所に入れないことによりカウンタ確認業務が滞ることがある。また、顧客企業の担当者がカウンタ確認しても、期間内にカウンタ値をサービス会社に送付しないことにより、サービス会社はカウンタ値を取得できないこともある。

このような場合、カウンタ確認データを取得できていないことが判明するには多くの時間がかかっていた。また、その判明結果を受けて、事業所にカウンタ確認作業員を向かわせてもカウンタ確認作業に時間がかかるため、指定された期間内（例えば、月末営業日）までにカウンタ確認業務を終了しないことがあり、その結果、顧客企業に料金を請求することができない場合も生じていた。

このため、本来当月で請求すべき料金が翌月請求になったり、基本料金のみの請求になったりして正確に当月内の実績を反映したカウンタ確認、料金請求が行えないという問題があった。

また、カウンタ確認作業員が目検証によりカウンタ確認を行う場合には、帰社後にカウンタ値を入力していた。しかしながら、このような転記作業を行っていると、転記ミス等が発生する恐れがある。このため、取得したカウンタ値を機械的に入力できることが求められていた。

本発明はこのような状況に鑑みて成されたものであり、カウンタ確認の精度を高めることを目的とする。

本発明では、契約ＩＤに基づいて、消耗品の使用量を確認する機器を抽出し、抽出された機器毎に特定される、消耗品の使用量を確認する締め日であって、消耗品の使用量を確認する手順毎に日付が異なる複数の締め日のうち、現在日付に最も近く、かつ、現在日付が未経過である締め日を取得する。そして、消耗品の使用量を記録するログを参照し、締め日までに、使用量を確認済みとした確認日付が存在するかを確認する。そして、ログに、確認日付が存在していない場合、消耗品の使用量を確認するための複数の締め日に優先順位を付けて、契約ＩＤで規定される消耗品毎に、締め日及び手順が紐付けられる優先順位データから、優先順位が高く、かつ、現在日付が未経過である締め日が紐付けられる手順を読み出して、消耗品の使用量を確認する手順を変更し、変更された手順によって、現在日付が未経過である締め日までに消耗品の使用量を確認することを指示する指示データを作成する。

このようにしたことで、締め日までにカウンタ値を取得できない場合は、カウンタ確認方法を変更し、カウンタ確認を確実に行うようにすることが可能となる。

本発明によれば、ある締め日までにカウンタ確認が行えない場合、最終締め日までに信頼性の高いカウンタ確認方法に切り換えてカウンタ確認を行うため、当月内のカウンタ値を確実に取得でき、妥当な料金請求を行えるという効果がある。

以下、本発明の一実施の形態について、添付図面を参照して説明する。

図１は、本実施の形態の例である、機器管理システムの全体を示す概略図である。
本実施形態の機器管理システム１０１は、幾つかのｗｅｂサーバ１０２及び１０３と、データベースサーバ（以下「ＤＢサーバ」）１０４と、これらにアクセスする多くのクライアントＰＣ１０５、１０６及び１０７、クライアントＰＣ１０７に接続可能なカウンタ確認携帯端末１０８よりなる。カウンタ確認携帯端末１０８は、例えばドットプリンタを備えたＰＤＡ（Personal Digital Assistant）であり、顧客企業の訪問先で取得したカウンタ値や請求書を印刷することができる。
社内ＬＡＮ１０９は周知のプライベートＩＰアドレスを主体とするＴＣＰ／ＩＰネットワークを構成し、グループ会社をも網羅するものである。
クライアントＰＣ１０５は典型的なパソコンであり、ｗｅｂサーバ１０２にアクセスするための、図示しないｗｅｂブラウザを稼動させている。
ｗｅｂサーバ１０２はそれらグループ会社毎、或は担当業務毎に分離され、分散されている。
なお、カウンタ確認携帯端末１０８は、クライアントＰＣ１０５，１０６に接続してカウンタ値を供給することが可能であるし、社内ＬＡＮに接続された図示しないプリンタからカウンタ値や請求書を印刷することも可能である。

クライアントＰＣ１０５はｗｅｂサーバ１０２にアクセスする。
ｗｅｂサーバ１０２はＤＢサーバ１０４にアクセスする。
つまり、ｗｅｂサーバ１０２はクライアントＰＣ１０５に対してＤＢサーバ１０４にアクセスする際のユーザインターフェースを提供する。

ｗｅｂサーバ１０２及び１０３とＤＢサーバ１０４は、負荷分散や安全確保等を目的として、また安全確保のための二重化等の構築を容易にするため、それぞれ分散されている。
勿論、システムの規模が小さい場合には、これらを一体化することもできる。

図２は、ｗｅｂサーバ１０２等とＤＢサーバ１０４の詳細を示す機能ブロック図である。
ｗｅｂサーバ１０２は、ｗｅｂサーバプログラム２０２と、多くのｃｇｉ（Common Gateway Interface：ｗｅｂサーバがｗｅｂブラウザの要求に応じて、プログラムを起動するための仕組み。）を内包する。
各々のｃｇｉは、社内ＬＡＮ１０９にアクセス可能な従業員を認証するための従業員認証ｃｇｉ２０３を始め、各種ユーザインターフェースを作成するｈｔｍｌ文書を作成するｃｇｉが存在する。
ＤＢサーバ１０４は機器管理システム１０１の中心的な役割を担う、各種データを格納するテーブルを多数備えている。図２ではその一部を示している。テーブル群の詳細な説明は、後述する（図３参照）。
ＤＢサーバ１０４は周知のＳＱＬ（リレーショナルデータベースの操作に特化された言語。）サーバを構成する。

図３は、ＤＢサーバ１０４に含まれているテーブル群のフィールド名を一部抜粋した概略図である。
従業員テーブル３０２は、従業員を一意に識別する、従業員ＩＤを中心とするテーブルである。フィールドには、「従業員ＩＤ」の他に、従業員の「氏名」と「所属」を示すフィールド等が存在する。また、図示はしないがパスワードのハッシュ値等も含まれ、従業員のログイン認証等に用いられる。
なお、顧客企業に赴き、契約締結を行う従業員を「営業担当者」とも称する。

顧客企業テーブル３０３は、顧客企業を一意に識別する、顧客ＩＤを中心とするテーブルである。フィールドには、「顧客ＩＤ」の他に、「顧客企業名」を示すフィールド等が存在する。クライアントＰＣ１０５の表示画面上に所望の顧客企業名を表示させる場合は、このテーブルから「顧客企業名」フィールドの値を取得する。
顧客担当者テーブル３０４は、顧客担当者を一意に識別する、担当者ＩＤを中心とするテーブルである。「担当者ＩＤ」の他に、顧客担当者の「担当者名」と、顧客企業を識別するための「顧客ＩＤ」フィールドが存在する。
顧客設置先テーブル３０５は、顧客に販売した機器を設置する際の設置場所（設置先）を一意に識別する、設置先ＩＤを中心とするテーブルである。「設置先ＩＤ」の他に、「設置場所」と「顧客ＩＤ」フィールドが存在する。

商談テーブル３０６は、商談を一意に識別する、商談ＩＤを中心とするテーブルである。営業担当者が顧客と商談を始めた際に、新規なレコードを起こす。フィールドは、
・「商談ＩＤ」の他に、
・商談の詳細内容の一つとして、商談を開始した日付を示す「商談日付」フィールドや、
・商談の進行状況、またその成果（仮契約、契約成立、契約失敗等）を示す「商談ステータス」フィールド、そして
・顧客企業テーブルの「顧客ＩＤ」、
・顧客担当者テーブルの「担当者ＩＤ」、
・従業員テーブルの「従業員ＩＤ」
が存在する。

契約テーブル３０７は、契約を一意に識別する、契約ＩＤを中心とするテーブルである。一契約につき、一つの新規なレコードを起こす。フィールドは、
・「契約ＩＤ」の他に、
・契約の種別を示す「契約種別ＩＤ」や、
・契約の詳細内容の一つとして、契約を作成した日付を示す「契約日付」フィールド、
・契約の進行状況、またその成果（仮契約、契約成立、契約失敗等）を示す「契約ステータス」フィールド、
・正式に発行された契約書の発行回数を格納する「発行回数ステータス」
・契約書を構成するパーツを示す「パーツコード」、
・契約書のパーツ毎に決定されるテンプレートファイルを示す「テンプレートコード」、
が存在する。

商談契約テーブル３０８は、商談と契約との一対多の関係を記述する、「商談ＩＤ」と「契約ＩＤ」の組よりなるテーブルである。つまり、一つの商談について、複数の契約が発生し得る。このテーブルの存在により、契約ＩＤから商談ＩＤ、またその逆の参照が可能になっている。

禁則条件テーブル３０９は、営業担当者が商談を進める際に作成する見積もりにおいて、一緒に販売してはいけない商品や役務の組み合わせを記述するテーブルである。後述する商品基本情報テーブル３１２の「商品コード」或は役務基本情報テーブルの「役務コード」同士の組み合わせが列挙される。

締め日条件テーブル３１０は、コピー機等のカウンタを確認する作業の締め日に関する契約条件を記述するテーブルである。フィールドは、
・その機器がどの契約に属するかを示す「契約ＩＤ」と、
・機器を特定する「商品コード」と
・機器のシリアルナンバー（以下「機番」と呼ぶ。）の他に、
・契約の詳細内容の一つとして、締め日の条件を示す「締め日条件」フィールドと、
・「締め日条件」の優先順位を示す「優先順位」フィールド
が存在する。
本実施形態では、カウンタ確認方法によって異なる締め日が設定される。つまり、カウンタ確認方法が変わることで、締め日も変わることになる。
カウンタ確認方法は、機番ごとに優先順位が設定されている。優先順位が高いカウンタ確認方法が決定され、締め日までにカウンタ値の取得を行うことになる。

契約種別テーブル３１１は、契約の種別を列挙するテーブルである。フィールドは、「契約種別ＩＤ」と「契約種別名」が存在する。
契約種別には、「売買契約」、「ハード保守契約」、「パフォーマンス契約」が存在する。

商品基本情報テーブル３１２は、商品を一意に識別する、商品コードを中心とするテーブルである。各々の商品を識別するための「商品コード」の他に、「商品名」「商品詳細情報」フィールド等が存在する。
役務基本情報テーブル３１３は、役務を一意に識別する、役務コードを中心とするテーブルである。各々の役務を識別するための「役務コード」の他に、「役務名」「役務詳細情報」フィールド等が存在する。
商品等構成テーブル３１５は、役務と商品との一対多の関係を記述する、「役務コード」と「商品コード」の組よりなるテーブルである。
例えば「安心パック」という名称で、パソコンのメンテナンスサービスとウイルス防御ソフトウェア商品の提供を含む役務が考えられる。このように、役務の中には商品を含むものもあるので、このようなテーブルを設けている。

契約商品等テーブル３１４は、契約と商品或は役務との一対多の関係を記述する、「契約ＩＤ」と「商品コード」或は「役務コード」の組よりなるテーブルである。つまり、一つの契約について、複数の商品或は役務が発生し得る。また、このテーブルには「機番」と「設置先ＩＤ」等のフィールドが存在する。

機器管理テーブル３１６は本実施形態において中核的な役割を担うテーブルである。
一つの機器（商品）について、「商品コード」と「機番」にて一意に識別し、その機器の顧客に対する納入から、機器の廃棄或はリサイクルまで、「機器の一生」を日付とステータス情報にて逐一記録し、管理するテーブルである。フィールドは、
・「商品コード」と
・「機番」の他に、
・この機器が属する契約を示す、契約テーブル３０７の「契約ＩＤ」、
・この機器が設置されている場所を示す、顧客設置先テーブル３０５の「設置先ＩＤ」、
・この機器の状態を示す「機器稼動ステータス」と
・「機器物流ステータス」、そして
・それらステータス情報を記録した「日付」
が存在する。

カウンタ確認ログテーブル３１７は、主にコピー機に内蔵されている、使用の度にインクリメントされる「カウンタ」の数値を記録するテーブルである。コピー機は使用回数、つまりコピー出力によって消費される用紙の枚数に応じて、使用量が課金される仕組みになっている。そこで、毎月決まった締め日に、コピー機に内蔵されているカウンタの値を確認し、カウンタ確認ログテーブル３１７に記録する。フィールドは、
・この機器が属する契約を示す、契約テーブル３０７の「契約ＩＤ」、
・「商品コード」と
・「機番」の他に、
・カウンタ値を取得した日付を示す「確認日付」と、
・当月内におけるコピー機等で印刷した枚数を格納する「カウンタ値」と、
・カウンタ値を取得した状態を示す「カウンタステータス」と、
・カウンタ値を取得する際、どのカウンタ確認方法が採用されたかを示す「カウンタ確認方法」
が存在する。

契約書テンプレートテーブル３１８は、契約書に必要な雛形のパーツを識別するパーツコードと、テンプレートを識別するテンプレートコードを記録するテーブルである。パーツコードとテンプレートコードに対応する契約書の雛形がテンプレートファイルとして契約書テンプレートテーブル３１８に記録される。
契約書は、以下に記載する５つのパーツが組み合わされて作成される。ただし、ある契約書では必要とされるが、別の契約書では必要とされないパーツも存在する。これら５つのパーツを「基本パターン」とも称する。
・「表紙」…甲乙などの契約関係を表現するパーツ。
・「基本条項」…販売にあたって必要な「基本条項」を表現するパーツ。
・「サービス条項」…モノ（例えば、コピー機、ＰＣ）ではなく、保守サービスなどの付加価値に対する「基本条項」を表現するパーツ。
・「契約料金」…見積時の料金を表現するパーツ。
・「保守対象明細」…保守サービスを契約する場合は、そのサービスは何に対して行うのかを表現するパーツ。

［カウンタ確認機能］
本実施の形態は、パフォーマンス契約を締結した顧客企業に対して、カウンタ確認を行い、使用料金の請求を行うものである。
機器管理システム１０１で行われるカウンタ確認機能は、大まかには以下の処理を経る。
毎月の締め日の前にはコピー機のカウンタの値を確認しなければならない。
ところが、顧客によっては締め日までにカウンタ値を確認できない場合もある。
そのようなときには、予め契約書を作成する際に作成していた、締め日条件テーブル３１０に記録されている「優先順位」を参照する。
締め日から何日経ったらどのようなカウンタ確認作業をするのか、そしてその作業は既に完遂したのか否かを確認し、担当者に指示するカウンタ確認票を作成するためのカウンタ確認指示データを作成し、適切な指示を担当者に提示する。

［カウンタ確認の詳細］
図４は、本実施形態の機器管理システム１０１のうち、カウンタ確認機能に注目したブロック図である。

クライアントＰＣ１０７は、キーボード等からの文字、数字入力等を受け付ける入力部１０７ｂと、カウンタ確認機能を有するカウンタ確認ｗｅｂサーバ４０２に対してｈｔｍｌ文書を送受信するインタフェースである通信インタフェース１０７ｃと、液晶ディスプレイであり、カウンタ確認作業に用いられる図示しない画面を表示する表示部１０７ｄと、カウンタ確認作業票等をクライアントＰＣ１０７に取り付けられた図示しないプリンタに出力する出力部１０７ｅと、カウンタ確認携帯端末１０８からカウンタ値を取得するとともに、カウンタ確認携帯端末１０８に顧客企業の機器情報を提供するインタフェースである入出力インタフェース１０７ｆとで構成されている。出力部１０７ｅは、後述するカウンタ確認作業員に対するカウンタ確認作業票、顧客企業の担当者に対するカウンタ確認作業票等を印刷する。なお、以下の説明では、カウンタ確認に用いられるカウンタ確認作業票、カウンタ確認作業票等を単に「カウンタ確認票」とも称する。

サービス会社に勤務するカウンタ確認作業員４０１は、クライアントＰＣ１０７を操作して、販売会社に設置されているカウンタ確認ｗｅｂサーバ４０２にアクセスすることができる。カウンタ確認作業を行うカウンタ確認作業員４０１は、カウンタ確認ｗｅｂサーバ４０２の図示しない認証ｃｇｉによって、クライアントＰＣ１０７で入力したユーザＩＤ、パスワードで認証される。
カウンタ確認ｗｅｂサーバ４０２は、クライアントＰＣ１０７から来るアクセス要求（ＨＴＴＰリクエストメッセージ）に呼応して、所定の処理を行う。
所定の処理の内容によっては、ＤＢサーバ１０４内に格納されている各種テーブルに対し、ＳＱＬの規格に則ったデータ取得或は書き込み等のアクセスを行う。カウンタ確認票作成ｃｇｉ４０３から各テーブルに伸びている矢印の線がこれに該当する。これらは概念的な線ではあるが、実際は図１に示したように、ｗｅｂサーバ１０２とＤＢサーバ１０４は社内ＬＡＮ１０９に接続されており、矢印にて示されるこれらアクセス動作は、社内ＬＡＮ１０９を通じて行われる。

カウンタ確認ｗｅｂサーバ４０２には、ｗｅｂサーバプログラム２０２と、カウンタ確認票作成ｃｇｉ４０３と、請求書作成部４０４が含まれている。ｃｇｉはこれ以外にも多数存在するが、図４では本実施形態において直接的に関係するものだけを抜粋して記載している。

ｗｅｂサーバプログラム２０２は、ＨＴＴＰのサーバを構成する。ＴＣＰ／ＩＰネットワークである社内ＬＡＮ１０９を通じて来るクライアントの要求（ＨＴＴＰリクエストメッセージ）に応じ、ｈｔｍｌ文書や、ｃｇｉの実行結果を、ＨＴＴＰレスポンスメッセージの形式にて送信する。一例としてはＡｐａｃｈｅ(http://www.apache.org/)等である。
カウンタ確認票作成ｃｇｉ４０３は、クライアントＰＣ１０７のｗｅｂブラウザにて表示されるｈｔｍｌ文書を作成する。
また、カウンタ確認票作成ｃｇｉ４０３と、請求書作成部４０４は、ＳＱＬクライアントの機能を含み、ＤＢサーバ１０４の各テーブルにアクセスし、所望のデータを取得する。

ＤＢサーバ１０４は前述の通り、周知のＳＱＬサーバを構成する。図４においては、カウンタ確認票作成ｃｇｉ４０３が扱うテーブルを明確にするため、ＳＱＬサーバのプログラム部分は標記を省略している。実際のＤＢサーバ１０４は、入力されるＳＱＬ言語を解釈して実行する、対話式データベースエンジンプログラムと、テーブルを構成するデータファイル群の組み合わせよりなる。

図５は、カウンタ確認ｗｅｂサーバ４０２における、カウンタ確認票作成ｃｇｉ４０３の機能を説明するブロック図である。

カウンタ確認票を構成する各項目に必要なデータを取得するカウンタ確認指示データ作成部５０３は、顧客企業テーブル３０３、契約テーブル３０７、締め日条件テーブル３１０、契約種別テーブル３１１、カウンタ確認ログテーブル３１７等からカウンタ確認指示データを作成するために必要な情報を取得する。
そして、カウンタ確認指示データ作成部５０３は、契約ＩＤに基づいて、カウンタ確認する機器を抽出し、抽出された機器毎に特定される、カウンタ確認の締め日を取得する。また、カウンタ値を記録するカウンタ確認ログテーブル３１７を参照し、締め日までに、カウンタ確認済みとした確認日付が存在するかを確認する。カウンタ確認ログテーブル３１７に、確認日付が存在していない場合、締め日条件テーブル３１０を参照し、契約ＩＤで規定される優先順位データに応じて、カウンタ確認する手順を変更する。

そして、カウンタ確認指示データ作成部５０３は、作成したカウンタ確認指示データをカウンタ確認票作成部５０２に供給する。カウンタ確認票作成部５０２は、カウンタ確認指示データを元にカウンタ確認票のイメージデータを作成する。

ｈｔｍｌ文書を作成するｈｔｍｌ文書作成部５０１は、カウンタ確認票のイメージデータをｈｔｍｌ文書化し、ｈｔｍｌメッセージとしてクライアントＰＣ１０７に送出する。
カウンタ確認作業員が取得した機器ごとのカウンタ値は、クライアントＰＣ１０７に取り込まれる。そして、クライアントＰＣ１０７の制御部１０７ａによって、カウンタ値はｈｔｍｌ文書化され、カウンタ確認ｗｅｂサーバ４０２にｈｔｍｌメッセージが送信される。

このｈｔｍｌメッセージをカウンタ確認ｗｅｂサーバ４０２のｈｔｍｌ文書受信部５０４が受信する。受信したｈｔｍｌメッセージに基づいて、締め日までにカウンタ値を取得できない場合、カウンタ確認指示データ作成部５０３は、カウンタ確認方法と締め日を変更したカウンタ確認指示データを作成し、カウンタ確認票作成部５０２に供給する。

締め日までにカウンタ値を取得できた場合、カウンタ確認指示データ作成部５０３は、請求料金を計算する料金計算部５０５にカウンタ値を供給する。料金計算部５０５は、当月分の請求料金を計算し、請求データを作成する。請求データは、顧客企業あてに請求書を作成する請求書データ作成部５０６に供給される。請求書データ作成部５０６は、請求書のイメージデータを作成し、図示しないプリンタによって請求書を発行する。

図６は、図４のＤＢサーバ１０４における、各テーブルのフィールドの関係を示す概念図である。
カウンタ確認票作成ｃｇｉ４０３は、顧客との商談が成立した商談ＩＤをキーに、商談テーブル３０６を検索して、商談にかかる諸情報を得る。
次に、カウンタ確認票作成ｃｇｉ４０３は、商談ＩＤにて商談契約テーブル３０８を検索し、対応する契約の契約ＩＤを一つ以上得る。
次に、カウンタ確認票作成ｃｇｉ４０３は、契約ＩＤにて契約テーブル３０７を検索し、契約にかかる諸情報を得る。
次に、カウンタ確認票作成ｃｇｉ４０３は、契約種別ＩＤにて契約種別テーブル３１１を検索し、契約種別にかかる諸情報を得る。
更に、カウンタ確認票作成ｃｇｉ４０３は、契約ＩＤにて契約商品等テーブル３１４を検索し、
・商品コード又は役務コードを一つ以上、
・設置先ＩＤ一つ
を得る。

次に、カウンタ確認票作成ｃｇｉ４０３は、商品コードにて商品基本情報テーブル３１２を検索し、商品にかかる諸情報を得る。
また、カウンタ確認票作成ｃｇｉ４０３は、役務コードにて役務基本情報テーブル３１３を検索し、役務にかかる諸情報を得る。
また、カウンタ確認票作成ｃｇｉ４０３は、設置先ＩＤにて顧客設置先テーブル３０５を検索し、設置先にかかる諸情報を得る。
そして、カウンタ確認票作成ｃｇｉ４０３は、契約ＩＤと設置先ＩＤにて機器管理テーブル３０６を検索し、設置先にかかる諸情報を得る。
このようにして、カウンタ確認票作成ｃｇｉ４０３は、各テーブルの情報が紐付けられた状態でデータを取得することができ、カウンタ確認指示データを作成できる。

図７は、契約書の作成を行うＰＣクライアントとカウンタ確認ｗｅｂサーバ４０２との処理例を示すフローチャートである。

まず、カウンタ確認ｗｅｂサーバ４０２は、カウンタ確認指示データを作成する（ステップＳ１）。そして、カウンタ確認指示データを元に作成したカウンタ確認票イメージデータをクライアントＰＣに送信する（ステップＳ２）。

クライアントＰＣは、カウンタ確認票イメージデータを受信し（ステップＳ３）、カウンタ確認票を発行する。カウンタ確認票は、サービス会社のカウンタ確認作業員が当月内でカウンタ確認を行うために機器をリストアップするために用いられる。

クライアントＰＣは、機器からカウンタ値を取得すると（ステップＳ４）、カウンタ値をカウンタ確認ｗｅｂサーバ４０２に送信する（ステップＳ５）。そして、カウンタ確認ｗｅｂサーバ４０２は、カウンタ値を受信する（ステップＳ６）。

カウンタ確認ｗｅｂサーバ４０２は、受信したカウンタ値を元にして、当月に請求する料金を計算する（ステップＳ７）。その後、顧客企業に発送する請求書の元となる請求データを作成する（ステップＳ８）。

図８は、カウンタ確認処理の例を示すフローチャートである。
まず、カウンタ確認ｗｅｂサーバ４０２は、機器管理システム１０１より、「稼働中の機器」かつ「カウンタ確認が必要な機器」を抽出し（ステップＳ１１）、一覧リストとする。そして、検索キーを一覧リストの先頭に設定する（ステップＳ１２）。

次に、契約ＩＤで特定される契約情報より、機器のカウンタ確認を行うための締め日を取得する（ステップＳ１３）。そして、カウンタ確認ログテーブル３１７を検索し、前月までのカウンタ確認状況を取得する（ステップＳ１４）。

次に、カウンタ確認ｗｅｂサーバ４０２は、締め日までにカウンタ確認済みか否かを判断する（ステップＳ１５）。締め日までにカウンタ確認ができていない場合、後述するカウンタ確認変更処理を行う（ステップＳ１６）。

締め日までにカウンタ確認済みである場合、次のレコードがあるか否かを判断する（ステップＳ１７）。次のレコードがある場合、ステップＳ３の処理に戻り、カウンタ値を取得する処理を継続する。次のレコードがない場合、処理を終了する。

図９は、カウンタ確認変更処理の例を示すフローチャートである。
まず、カウンタ確認ｗｅｂサーバ４０２は、カウンタ確認ログテーブル３１７より確認日付を取得することで、前月までのカウンタ確認結果を検索する（ステップＳ２１）。そして、契約ＩＤで特定されるカウンタ確認条件を参照する（ステップＳ２２）。カウンタ確認条件には、締め日までにカウンタ値を取得できない場合、優先順位の高いカウンタ確認方法が選択されて、カウンタ確認が行われる締め日が決められている。

次に、カウンタ確認ｗｅｂサーバ４０２は、締め日条件テーブル３１０を参照し、契約ＩＤで特定される機番の優先順位が高いカウンタ確認方法を選択する（ステップＳ２３）。次に、カウンタ確認方法の変更条件を満たすか否かを判断する（ステップＳ２４）。
カウンタ確認方法の変更条件とは、優先度が一番高いカウンタ確認方法で締め日までにカウンタ値を取得できなかった場合、優先度が次に高いカウンタ確認方法に切り換えることができるかどうかを判断する条件である。優先度が次に高いカウンタ確認方法に切り換えた場合、このカウンタ確認方法で指定される締め日を新たに設定することができる。

カウンタ確認方法の変更条件を満たす場合、変更したカウンタ確認方法に基づく一覧リストを出力し（ステップＳ２５）、カウンタ確認処理（図７参照）に戻る。カウンタ確認方法の変更条件を満たさない場合、次のカウンタ確認方法に変更することができる否かを判断する（ステップＳ２６）。

次のカウンタ確認方法に変更することができる場合、ステップＳ２４の処理に戻り、次に優先順位の高いカウンタ確認方法に変更する。変更可能なカウンタ確認方法がない場合、営業担当者を機器の設置場所に向かわせて所在確認を行わせる指示データを作成し（ステップＳ２７）、カウンタ確認処理（図７参照）に戻る。

ここで、具体的なカウンタ確認処理について、図９を参照して説明する。
図１０は、カウンタ確認処理の例を示すフローチャートである。
本実施形態では、カウンタ確認方法の優先順位が高い順に、第１の締め日が設定されたＣＳＳ（Customer Support System）取得、第２の締め日が設定された訪問取得、第３の締め日が設定されたカウンタ確認依頼となっている。当然、実施形態に応じて、優先順位は変わり、締め日も変わることとなる。

ＣＳＳ取得は、通信回線を介して機器のカウンタ値を取得する方法である。ＣＳＳは、公衆回線を利用した遠隔診断と自動カウンタ確認システムのことである。機器の故障を未然に防ぐとともに、機器が故障しても故障期間を最小限に抑える機能を有している。また、第１の締め日までに自動的にカウンタ値を送信することが可能なシステムである。

訪問取得は、第２の締め日までにカウンタ確認作業員が顧客企業に赴いてカウンタ確認を行う方法である。カウンタ確認作業員は、カウンタ確認ｗｅｂサーバ４０２が発行するカウンタ確認作業票の発行を受けて、機器の設置場所に向かう。そして、カウンタ確認作業員は、カウンタ確認携帯端末１０８を用いて、カウンタ値を数字入力、または機器に接続してカウンタ値を取得する。

カウンタ確認依頼は、セキュリティ上の観点から機器が設置された場所への入場が禁止されている場合、顧客企業の担当者に依頼して第３の締め日までにカウンタ確認を行ってもらう方法である。この場合、カウンタ確認ｗｅｂサーバ４０２は、カウンタ確認依頼票を発行し、顧客企業の担当者あてに送信する。
カウンタ確認依頼票の発行を受けて、顧客企業の担当者が確認したカウンタ値は、図示しないｗｅｂページ、Ｆａｘ、ハガキ等によりサービス会社に送られる。サービス会社のカウンタ確認作業者は、ｗｅｂページから得られるカウンタ値の場合、データ変換してカウンタ確認ｗｅｂサーバ４０２に送る。同様に、Ｆａｘ、ハガキ等により受け取ったカウンタ値は、ＯＣＲ読み取り、またはキー入力によりクライアントＰＣでデータを取得して、カウンタ確認ｗｅｂサーバ４０２に送る。

まず、カウンタ確認ｗｅｂサーバ４０２とカウンタ確認対象機器間の通信チェックを行い（ステップＳ３１）、通信異常の有無を判断する（ステップＳ３２）。通信異常がある場合、エンジニアをカウンタ確認対象機器の設置場所に向かわせ点検作業を行わせる訪問点検指示データを作成する（ステップＳ３３）。

次に、エンジニアが訪問点検した結果、カウンタ確認対象機器の通信異常が継続しているか否かを判断する（ステップＳ３４）。カウンタ確認対象機器の通信異常が継続している場合、カウンタ確認方法を作業員による訪問確認に切り換える指示データを作成する（ステップＳ４１）。

ステップＳ３２の処理と、ステップＳ３４の処理で通信異常がない場合、カウンタ確認ｗｅｂサーバ４０２は、カウンタ確認指示データを作成する（ステップＳ３５）。そして、カウンタ確認ｗｅｂサーバ４０２は、現在日付と第１の締め日との大小関係を比較する（ステップＳ３６）。なお、現在日付は、カウンタ確認ｗｅｂサーバ４０２で取得されるシステム日付を用いればよい。

現在日付が第１の締め日以前である場合、通信回線を介してカウンタ値を取得する処理を行う（ステップＳ３７）。
この結果、カウンタ確認できたか否かを判断する（ステップＳ３８）。カウンタ確認できた場合、料金計算を行う（ステップＳ５０）。カウンタ確認できない場合、ステップＳ３６の処理に戻り、第１の締め日を過ぎるまで通信回線を介したカウンタ値の取得処理を継続する。

判断ステップＳ３６において、現在日付が第１の締め日を超過した場合、つまり、第１の締め日までにＣＳＳによりカウンタ値を取得できなかった場合、カウンタ確認ｗｅｂサーバ４０２は、第２の締め日を設定するとともに、カウンタ確認作業員を機器の設置場所に向かわせるための訪問データを作成する（ステップＳ４１）。そして、カウンタ確認ｗｅｂサーバ４０２は、現在日付と第２の締め日との大小関係を比較する（ステップＳ４２）。

現在日付が第２の締め日以前である場合、カウンタ確認作業員を機器の設置場所に向かわせ、機器から携帯端末１０８を用いてカウンタ値を取得する。取得したカウンタ値は、カウンタ確認ｗｅｂサーバ４０２が取り込む（ステップＳ４３）。

この結果、カウンタ確認できたか否かを判断する（ステップＳ４４）。カウンタ確認できた場合、料金計算を行う（ステップＳ５０）。カウンタ確認できない場合、ステップＳ４２の処理に戻り、第２の締め日を過ぎるまで、カウンタ確認作業員を機器の設置場所に向かわせるカウンタ確認作業票を発行する処理を継続する。

判断ステップＳ４２において、現在日付が第２の締め日を超過した場合、つまり、第２の締め日までにカウンタ確認作業員がカウンタ値を取得できなかった場合、カウンタ確認ｗｅｂサーバ４０２は、第３の締め日を設定するとともに、顧客企業の担当者に対してカウンタ確認を依頼するカウンタ確認依頼票を発行する（ステップＳ４５）。

そして、カウンタ確認ｗｅｂサーバ４０２は、現在日付と第２の締め日との大小関係を比較する（ステップＳ４５）。現在日付が第３の締め日以前である場合、顧客企業の担当者からカウンタ値が記録されたＦａｘ、ハガキ等からのデータ取り込み、またはｗｅｂ画面からのデータ取得を継続する（ステップＳ４７）。

この結果、カウンタ確認できたか否かを判断する（ステップＳ４８）。なお。顧客企業の担当者がカウンタ確認する場合、数値を誤って読み取ったり、字が判別できなかったりすることによってカウンタ確認が正しく行われない場合がある。

カウンタ確認できた場合、料金計算を行う（ステップＳ５０）。カウンタ確認できない場合、ステップＳ４６の処理に戻り、第３の締め日を過ぎるまで、顧客企業の担当者から送られるカウンタ値の受信を待つ。

第３の締め日までにカウンタ確認できない場合、予め顧客と締結した契約内容にしたがって、請求金額には当月分の料金を翌月に繰り越し、又は基本料金を適用する（ステップＳ４９）。

ステップＳ４９，Ｓ５０の処理で請求金額を計算した後、顧客に対して使用料金の請求票を発行する（ステップＳ５１）。

以上説明した本実施形態によれば、あるカウンタ確認方法によって締め日までにカウンタ確認が行えない場合、別のカウンタ確認方法に切り換えることで、当月内でカウンタ値を取得することが可能となる。それぞれのカウンタ確認方法には、当月内における締め日が設定されている。カウンタ確認できない場合は、優先順位に応じてカウンタ確認方法が切り替わる。このように、当月内に複数の締め日を設定し、複数のカウンタ確認方法に切り換えるため、取得したカウンタ値の信頼性が高まる。このため、より正確なカウンタ値による料金請求を行うことができ、顧客満足度を向上させる効果がある。

また、設定された締め日にカウンタ確認が行われると、即時料金計算、請求書発行が可能である。従来は、当月末にカウンタ確認を行った場合、顧客企業が月末請求を希望しても手書きで請求書を発行するしかなかった。しかし、本発明によると、個別の請求書を作成しなくても、顧客都合の即時の請求書発行に対応することができる。このため、カウンタ確認にかかる業務工数を削減できるととともに、顧客企業に請求する料金の信頼性を高めるという効果がある。

また、従来、通信回線によるカウンタ値の取得が行えなかった場合、緊急のカウンタ確認業務を行っていたため、作業員の手配等にともない、通常業務に影響がでていた。しかし、本実施形態によれば、カウンタ確認を行う作業員は、必要な時期に必要な場所に行って確認するようにできる。このため、人員配置の見積りをたてることが容易となるとともに、変則的な人員配置を行う必要がなくなるため、効率的なカウンタ確認業務を遂行することができる。

また、カウンタ確認ができなかった場合は、当月の料金請求は、基本料金のみを適用するか、翌月請求とすることができる。このため、当月末における緊急のカウンタ確認業務を廃止することができ、通常業務への影響を除くことができるという効果がある。

また、カウンタ確認をする期間を当月内としたが、例えば２週間以内であったり、３ヶ月以内であったりしてもよい。期間の長短は顧客との契約に応じて自由に変更することが可能である。

以上、本発明の実施形態例について説明したが、本発明は上記実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含むことは言うまでもない。

本発明の一実施の形態による機器管理システムの全体を示す概略図である。 ｗｅｂサーバ等とＤＢサーバの詳細を示す機能ブロック図である。 ＤＢサーバに含まれているテーブル群のフィールド名を一部抜粋した概略図である。 機器管理システムのうち、カウンタ確認機能の例を示すブロック図である。 カウンタ確認票作成ｃｇｉと請求書作成部の機能を説明するブロック図である。 ＤＢサーバにおける、各テーブルのフィールドの関係を示す概念図である。 クライアントＰＣとカウンタ確認ｗｅｂサーバの契約書作成処理例を示すシーケンス図である。 クライアントＰＣの契約書作成処理例を示すフローチャートである。 カウンタ確認方法の変更処理例を示すフローチャートである。 カウンタ確認方法と料金計算の変更処理例を示すフローチャートである。

符号の説明

１０１…機器管理システム、１０２、１０３…ｗｅｂサーバ、１０４…ＤＢサーバ、１０５、１０６、１０７…クライアントＰＣ、１０９…社内ＬＡＮ、２０２…ｗｅｂサーバプログラム、２０３…従業員認証ｃｇｉ、３０２…従業員テーブル、３０３…顧客企業テーブル、３０４…顧客担当者テーブル、３０５…顧客設置先テーブル、３０６…商談テーブル、３０７…契約テーブル、３０８…商談契約テーブル、３０９…禁則条件テーブル、３１０…締め日条件テーブル、３１１…契約種別テーブル、３１２…商品基本情報テーブル、３１３…役務基本情報テーブル、３１４…契約商品等テーブル、３１５…役務基本情報テーブル、３１６…機器管理テーブル、３１７…カウンタ確認ログテーブル、３１８…契約書テンプレートテーブル、４０１…営業担当者、４０２…契約書作成ｗｅｂサーバ、４０３…カウンタ確認表作成ｃｇｉ、４０４…請求書作成部、５０２…カウンタ確認票作成部、５０３…カウンタ確認指示データ作成部、５０５…料金計算部、５０６…請求書データ作成部

Claims (4)

1. 契約ＩＤに基づいて、消耗品の使用量を確認する機器を抽出するステップと、
   前記抽出された機器毎に特定される、前記消耗品の使用量を確認する締め日であって、前記消耗品の使用量を確認する手順毎に日付が異なる複数の前記締め日のうち、現在日付に最も近く、かつ、前記現在日付が未経過である前記締め日を取得するステップと、
   前記消耗品の使用量を記録するログを参照し、前記締め日までに、前記使用量を確認済みとした確認日付が存在するかを確認するステップと、
   前記ログに、前記確認日付が存在していない場合、前記消耗品の使用量を確認するための複数の締め日に優先順位を付けて、前記契約ＩＤで規定される前記消耗品毎に、前記締め日及び前記手順が紐付けられる優先順位データから、前記優先順位が高く、かつ、前記現在日付が未経過である前記締め日が紐付けられる前記手順を読み出して、前記消耗品の使用量を確認する手順を変更するステップと、
   変更された前記手順によって、前記現在日付が未経過である前記締め日までに前記消耗品の使用量を確認することを指示する指示データを作成するステップを含むことを特徴とする
   使用量取得方法。
2. さらに、前記指示データに基づいて、変更された前記手順と、前記手順に紐付けられ、前記現在日付が未経過である前記締め日が含まれる確認票を表すデータを作成するステップを含むことを特徴とする
   請求項１記載の使用量取得方法。
3. 契約ＩＤに基づいて、消耗品の使用量を確認する機器を抽出し、前記抽出された機器毎に特定される、前記消耗品の使用量を確認する締め日であって、前記消耗品の使用量を確認する手順毎に日付が異なる複数の前記締め日のうち、現在日付に最も近く、かつ、前記現在日付が未経過である前記締め日を取得し、前記消耗品の使用量を記録するログを参照し、前記締め日までに、前記使用量を確認済みとした確認日付が存在するかを確認する使用量確認指示部と、
   前記ログに、前記確認日付が存在していない場合、前記消耗品の使用量を確認するための複数の締め日に優先順位を付けて、前記契約ＩＤで規定される前記消耗品毎に、前記複数の手順の前記優先順位を記録する優先順位データから、前記優先順位が高い前記手順を読み出して、前記消耗品の前記使用量を確認する手順を変更する手順変更部と、
   変更された前記手順によって、前記現在日付が未経過である前記締め日までに前記消耗品の使用量を確認することを指示する指示データを作成する指示データ作成部と、を備えることを特徴とする
   使用量取得装置。
4. さらに、前記指示データに基づいて、変更された前記手順と、前記手順に紐付けられ、前記現在日付が未経過である前記締め日が含まれる確認票を表すデータを作成する確認票作成部を備えることを特徴とする
   請求項３記載の使用量取得装置。

Images