JP2010020507A - 料金計算システム - Google Patents

Abstract

【課題】料金プランの追加・変更に対して迅速に対応することができ、同業他社や、他業種へも容易に対応することができる料金計算システムを提供する。
【解決手段】料金計算システムにおいて、パッケージ開発会社側料金計算システム７と、パッケージ利用企業の利用企業側料金計算システム８とを備え、パッケージ開発会社側料金計算システム７は、複数のパッケージ利用企業での料金計算ロジックを集約して管理し、料金計算ロジックに基づいて、複数の入力情報に対して請求金額を対応させた料金計算テーブル４を作成し、利用企業側料金計算システム８は、パッケージ開発会社側料金計算システム７で作成された料金計算テーブル４をセカンダリテーブルとして管理し、セカンダリテーブルから一部のデータを抽出した検索用テーブルおよび複数の入力情報に基づいて、料金計算を行い、請求金額を確定する。
【選択図】図１

Description

本発明は、ガス、電力会社等における需要者への請求料金を確定する料金計算システムに関し、特に、その計算処理の効率化に関するものである。

従来、電力、ガス会社等において需要者に請求する料金を計算するシステムにおいては、料金プラン毎に個別のプログラムを作成する形態か、例えば、特開２００１−９４６８８号公報（特許文献１）に記載の「請求書作成方法及びその実施装置並びにその処理プログラムを記録した記録媒体」や、特開２００５−２４１３１８号公報（特許文献２）に記載の「テーブルドリブン方式による託送料金管理システム」などに記載されている各種関数の組み合わせで料金計算の結果を算出するテーブルドリブンの形態があった。

また、電力、ガス会社等の分野ではないが、テーブルを使用して料金計算を行う技術としては、料金の計算を行う際に予めテーブルを準備して料金計算を行う、特開平１１−３９３８５号公報（特許文献３）に記載の「送料金額の計算方法及び送料金額の計算プログラムを記録した媒体」があった。
特開２００１−９４６８８号公報 特開２００５−２４１３１８号公報 特開平１１−３９３８５号公報

現在、規制緩和によるガス、電力の小売自由化により、同業他社との競争を勝ち抜くために、各企業で多様化した料金メニューが設定され、需要者に対して迅速に料金メニューを提供する必要がでてきている。その為、料金計算システムとしては迅速な料金プランの追加・変更に対応することが必要になっている。

このような背景の中で、１つ目の課題としては、現在のガス、電力会社のパッケージシステムにおいては、各パッケージ利用企業側で料金計算ロジックに従って入力情報を取込む引数取込、基本料金を確定する基本料金算出、従量料金を確定する従量料金算出等の処理を料金計算処理のタイミングで毎回、需給者毎に実施している。

その為、料金計算処理において無駄な処理を行っており、料金計算処理に多くの時間を費やしている。しかし、ガス料金、電気料金の料金プランについては毎回料金計算ロジックに従って処理を行う必要がなく、入力となる使用量等の情報が決まれば、請求金額が算出されるのが一般的である。

また、同業種内で提供している料金プランについては、個別に設定している大口契約の料金プランを除き、大半は計算式が同じであり、単価の設定が異なるという形が一般的である。その為、従来の技術では、同じような料金計算ロジックをパッケージ利用企業毎に管理しており、同じような料金計算ロジックが散在している状況である。その様な状態で、料金計算ロジックに対して修正があった場合にパッケージ利用企業毎に対応を行う必要があり、料金プランの追加／変更に迅速に対応できていなかった。

２つ目の課題としては、特許文献３に記載のように予めテーブルデータを準備して料金計算の金額を確定させるという技術は存在するが、送料の計算といった簡易な計算であり、注文数という限られた幅の中で変動する１つの可変情報から金額が決まるものや、ある区切りで金額が変更されるような条件下のみで有効な技術であった。

しかし、ガス料金等の様に複数の可変情報によって金額が決まるものや、段階的に金額が決まるわけではなく、入力値の１つ１つの組み合わせによって金額が異なっているものについては従来の技術ではテーブルに定義するレコード数が膨大となってしまい、予めテーブルを用意してもレスポンスの向上はできないという課題が存在していた。

３つ目の課題としては、特許文献１、２に記載のように、個別にプログラムを作成する形態、テーブルドリブンの形態ではガス会社、電力会社の営業部門にてプログラム作成、テーブル定義を行い、新しい料金メニューの追加・変更を行う必要があり、このような対応を行うには開発期間が必要となり迅速な対応ができない点や、その開発期間に比例してコストも増大してしまうという課題があった。

また、テーブルドリブンの形態については、テーブル定義を行うにあたり、企業側において、専門的な技術を必要とする課題も存在し、さらに、料金計算システムのパッケージ化を行う場合に各ガス、電力会社毎に料金プランの計算ロジックを保持してしまうため、パッケージ開発会社側では、各利用企業側の料金計算ロジックの内容が把握できず、料金プランの追加・変更を行う場合に、パッケージ開発会社では迅速な対応ができないという課題や、パッケージ適用会社毎に対応者を割り当てる必要がでてきてしまい人材不足に陥るという課題が存在していた。

そこで、本発明の目的は、料金プランの追加・変更に対して迅速に対応することができ、同業他社や、他業種へも容易に対応することができる料金計算システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。

すなわち、代表的なものの概要は、利用企業側料金計算システムが、パッケージ開発会社側料金計算システムで作成された料金計算テーブルをセカンダリテーブルとして管理し、セカンダリテーブルから一部のデータを抽出した検索用テーブルおよび複数の入力情報に基づいて、料金計算を行い、請求金額を確定するものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、代表的なものによって得られる効果は、料金計算システムを使用するガス、電力会社等の企業においては、料金プランの追加・変更に対して迅速に対応することができ、料金計算の処理時間を短縮することができる。

また、料金計算システムを開発／提供する企業においては、料金計算テーブルの作成機能を集約していることから、同業他社や他業種への料金計算システムの提供に対して迅速に対応することができる。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。

図１により、本発明の一実施の形態に係る料金計算システムの構成について説明する。図１は本発明の一実施の形態に係る料金計算システムの構成を示す構成図である。

図１において、料金計算システムは、料金計算システムのパッケージを開発するパッケージ開発会社１のパッケージ会社側料金計算システム７と、料金計算システムの利用企業の利用企業側料金計算システム８から構成されている。

料金計算システムのパッケージ開発会社１は、料金計算テーブル４を作成するためのパッケージ開発会社側料金計算システム７、料金計算ロジックを定義した料金計算ルールテーブル５０をメンテナンスするパッケージ開発会社オンライン端末６から構成されている。

パッケージ開発会社側料金計算システム７は、料金計算ルールテーブル５０や料金計算単価テーブル５１などの情報に基づいて、料金計算テーブル４を作成するプログラムを有する疑似入力情報作成処理部２および料金計算テーブル作成処理部３によって構成されるシステムである。

また、パッケージ開発会社側料金計算システム７内には、後述する疑似入力情報作成処理部２および料金計算テーブル作成処理部３の処理により使用される、料金対象料金プランテーブル、料金計算テーブル定義情報、計算対象料金プラン定義テーブル、契約情報などが保有され、これらの情報や入力パラメータなどにより、疑似入力情報作成処理部２および料金計算テーブル作成処理部３での処理が行われている。

また、利用企業側はパッケージ開発会社１より配信された料金計算テーブル４を受け取り、料金計算テーブル４により料金計算を行う利用企業側料金計算システム８によって構成されている。

料金計算ロジックは、パッケージ開発会社１に集約して管理を行い、パッケージ利用企業側では保持しない構成を取っている。

ここで、料金計算システムの処理の概要を説明する。

（１）パッケージ開発会社１は、パッケージ開発会社オンライン端末６にて、ガス業界、電気業界の約款を元に料金計算ルールテーブル５０の作成を行う。料金計算ルールテーブル５０の定義方法については従来の手法と同じとする。

（２）パッケージ利用企業に応じて、料金計算を行う上で必要となる単価情報を料金計算ルールテーブル５０に定義を行う。通常、ガス、電力会社における料金プランは同業他社間を見ても、計算式は同じであり、単価、割引率などが異なるという形が一般的であり、料金計算ロジックの追加、変更は行わず、単価情報のみを変更することで各パッケージ利用企業側への提供が可能となる。

（３）パッケージ開発会社１は入力パラメータを元に、疑似入力情報作成処理部２内での処理を行い、料金計算を行うための入力情報を作成する。

（４）作成された入力情報を元に、料金計算テーブル作成処理部３内での処理を行い、パッケージ利用企業側へ提供する料金計算テーブル４を作成する。料金計算テーブル４は料金プラン毎に作成するものとする。また、パッケージ利用企業毎に、その企業用の料金計算テーブル４として作成される。

（５）作成した料金計算テーブル４を各パッケージ利用企業の利用企業側料金計算システム８へ提供を行う。

（６）パッケージ利用企業側へ提供を行うタイミングは、料金計算システムパッケージの初期購入時、単価情報変更時、料金改定による料金プラン追加時となる。

（７）利用企業側料金計算システム８は、提供された料金計算テーブル４を使用して請求金額の確定を行う。

このような、パッケージ開発会社１と利用企業から構成される料金計算システムにより、料金計算ロジックに基づいた計算処理をパッケージ利用企業側で実施しないことから料金計算時間の短縮化、料金プランの追加・変更時の迅速な対応を行うシステムを実現することが可能である。

また、料金計算ロジックをパッケージ開発会社１に集約して管理できるため、料金計算ロジックが散在しなくなる。

次に、図２および図３により、本発明の一実施の形態に係る料金計算システムのパッケージ開発会社１側の処理について説明する。図２は本発明の一実施の形態に係る料金計算システムのパッケージ開発会社側の疑似入力情報作成処理を説明するための説明図、図３は本発明の一実施の形態に係る料金計算システムのパッケージ開発会社側の料金計算テーブル作成処理を説明するための説明図である。

まず、パッケージ開発会社１で料金計算テーブル４を作成するにあたっては、図２に示すように、疑似入力情報作成処理部２にて料金計算テーブル作成処理部３で処理を行うための疑似料金計算入力情報３２を作成する。

疑似入力情報作成処理部２は、料金プラン毎に請求金額を確定するための入力条件を網羅的に作成する疑似入力情報作成プログラム３１を有しており、疑似入力情報作成プログラム３１の処理により、実際に料金計算を行う料金プランコードを特定する計算対象料金プラン定義テーブル２９や料金プランコード毎の引数に対しての入力上限、下限となる閾値、固定値等を定義する料金計算テーブル定義情報３０などから、疑似料金計算入力情報３２を作成している。

計算対象料金プラン定義テーブル２９については、パッケージ利用企業側で意識する料金プランのコードとパッケージ開発会社側で意識する料金プランのコードが通常異なるため、その対応関係を定義するテーブルとなる。

図２に示すように、料金プランコード「ＲＹＯＫＩＮ０１」は利用企業側で意識するコードであり、利用企業に応じて変更を行う。計算対象料金プランコード「ＰＬＡＮ０２」についてはパッケージ側共通的に管理している料金計算ロジックに対するコードとなる。

料金計算テーブル定義情報３０は、引数毎に料金計算を行う範囲を定義するものとし、閾値（下限）から閾値（上限）まで１ずつ加算を行っていく形のものと、需要者の地区コードの様に固定的に決まる固定値１，２，３による設定がある。

図２に示す例では、「ＰＬＡＮ０１」のキー１は下限値を１として上限が１０００の数値の入力値であり、キー２は固定値として「０１」「０２」「０３」となっている入力値である。料金計算テーブル定義情報３０はパッケージ開発会社１で意識する料金プランコードをキー項目として保持、利用企業に応じて、下限値、上限値、固定値を変更して実行する。

このように定義された情報より、各料金プランの引数の組み合わせを網羅した疑似料金計算入力情報３２がパッケージ開発会社１側の料金プランコードにて作成される。

実際に料金計算を行う契約者については、擬似的に契約情報を作成して対応を行うものとする。

また、料金計算テーブル作成処理部３は、図３に示すように、疑似入力情報作成処理部２にて作成した疑似料金計算入力情報３２を元に計算結果情報３５を算出する料金計算プログラム３４と、計算結果情報３５を元に料金計算テーブル４を作成する料金計算テーブル作成プログラム３７を有している。

料金計算プログラム３４については、ダミーとして作成した契約情報を管理する契約情報３３、疑似入力情報作成プログラム３１にて作成した疑似料金計算入力情報３２、料金計算ルールテーブル５０、料金計算単価テーブル５１を入力として、計算結果情報３５を作成する。各パッケージ利用企業に応じて料金計算単価テーブル５１を定義し、料金計算の実行を行うことで利用企業に応じた計算結果情報３５を作成する。

料金計算テーブル作成プログラム３７では、利用企業側に料金計算テーブル４を展開するために、パッケージ開発会社１側で意識する料金プランコードから利用企業側で意識する料金プランコードを計算対象料金プラン定義テーブル２９にて変換し、計算結果情報の結果を料金計算テーブル４の形式に変換する。

料金計算ルールテーブル５０については、ガス業界、電力業界の約款を元に定義しており、単価情報を変更して料金計算を行うことで、各パッケージ利用企業に対応した料金計算テーブル４を作成することができる。

従来では、料金計算システムとしてパッケージ利用企業側に料金計算ルールテーブル５０を提供しており、同じ料金計算ロジックが同業他社間で複数存在している。また、従来では、パッケージ利用企業側に料金計算ルールテーブル５０があることから、適用企業側で必要に応じてカスタマイズできるという利点がある一方、テーブル定義を行う要員の確保が必要な点や、同業他社が行っている約款を適用する場合についても各適用企業側で、１からテーブル定義を行う必要があり、料金計算に迅速に対応できないという欠点が存在していた。

本実施の形態では、専門知識を必要とする料金計算ルールテーブル５０を定義する人材をパッケージ開発会社１へ集約することで、パッケージ利用企業での人員削減や、料金プランの追加においても料金計算単価テーブル５１を変更することで迅速な料金プランの追加・変更に対応することができる。

次に、図４により、本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側での処理の概要について説明する。図４は本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側での処理を説明するための説明図である。

図４において、パッケージ利用企業側に提供された利用企業側料金計算システム８は、パッケージ開発会社１より提供される料金計算テーブル４を元に請求金額を確定するシステムであり、各料金計算プランに応じた料金計算ロジックを持込んでいない汎用的な料金計算システムである。

利用企業側料金計算システム８は、その制御部内に、料金プラン判定部１２、請求金額確定部１３，検索用テーブル反映部１４を有している。

料金計算テーブル４は、パッケージ開発会社１から提供されたままの情報であるセカンダリテーブル１０と請求金額の確定に使用されたレコードと抽出範囲を意識して抽出を行った一部のレコードのみを抽出している検索用テーブル１１から構成される。

パッケージ利用企業側に提供された利用企業側料金計算システム８は、入力情報として料金プランを識別する料金プランコード、料金計算結果を取得するための引数１、２，３（料金計算テーブル４のキーに対応）、一時金や延滞利息額を加算するための付加料金額を必要とする。

請求金額を確定するための引数については、請求金額を確定することができるための情報であり、月別使用量、休日使用量等の需要者の利用状況に応じて変化する可変値の情報や、需要者の居住している地区を示す地区コード等の固定的な情報で構成される。

付加料金額については、料金プラン毎の請求金額とは別に需要者へ請求したい一時金や、延滞利息等の情報がある場合、入力情報として定義することで一時金、延滞利息等を考慮した請求金額、消費税額を算出するために使用する。

上記に示す入力情報を使用して料金プラン判定部１２にて、料金プランコードから検索を行うＴＡＢＬＥ名（検索用テーブル、セカンダリテーブル）を取得する。料金プラン判定部１２で特定されたＴＡＢＬＥ名、引数情報を元に請求金額確定部１３にて検索用テーブル１１を検索し、請求金額、消費税額、割引額を取得する。

検索用テーブル１１にて取得できない場合はセカンダリテーブル１０を検索する。取得した結果に対して付加料金額、付加料金消費税額を加算して、最終的な請求金額を確定する。

料金計算テーブル４のセカンダリテーブル１０から検索用テーブル１１へレコードを移動させる処理は、検索用テーブル反映部１４にて実施する。検索用テーブル反映部１４では、１人の需要者の料金計算が終了したタイミングで請求金額の確定に使用されたレコードを元に検索用テーブル１１へ抽出する対象を特定する。

抽出する対象を特定するにあたっては、セカンダリテーブル１０よりレコードを取得した場合であり、請求額を確定する際に使用したレコードと関連性が高いレコードも合わせて検索用テーブルへ抽出を行う。その為、需要者の利用状況を統計的に判断した検索用テーブル１１を構成することができる。

また、請求金額確定部１３にて、料金計算ロジックを持込まず、請求金額を確定するため、料金計算処理の短縮化を図ることができる。

上記のような仕組みで料金計算ロジックを簡略化し、処理時間を短縮できる理由としては、請求金額を算出するための要素である入力情報が確定していれば、前述した従来の特許文献１、２のように毎回計算処理を行わなくて良いためである。

また、通常、ガス、電力会社の需要者の大半は一般の需要者であり、同一の料金プランである点や、請求金額を確定する際の入力情報である使用量については、需要者によって大きく変わらないことから料金計算テーブル４（検索用テーブル１１）を使用して需要者の統計的な利用状況を考慮していることから、本実施の形態では、処理時間を早くすることができる。

さらに、検索用テーブルとセカンダリテーブルの２つのテーブルにて構成を行うことによって、前述した特許文献３の課題となっていたテーブルに定義するレコード数が増加してしまうことによる検索処理のレスポンス悪化を防ぐことができる。

次に、図５により、本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側での処理フローについて説明する。図５は本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側での処理フローを示すフローチャートである。

パッケージ利用企業側での利用企業側料金計算システム８内での処理は、以下のように行われる。

まず、料金プラン判定部１２の対象ＴＡＢＬＲＥ特定処理（ステップ１００）では、入力値として受け取った料金プランコードより、検索対象となる検索用テーブル、セカンダリテーブルのＴＡＢＬＥ名を取得する。取得するＴＡＢＬＥ名はデータベース上のＴＡＢＬＥ名とする。

図４に示す例では、入力値である料金プランコードの「ＲＹＯＫＩＮ０１」にて計算対象特定テーブル９を検索し、検索用テーブル名「ＴＡＢＬＥ１」、セカンダリテーブル名「ＴＡＢＬＥ４」を取得する。

そして、請求金額確定部１３の請求金額情報取得処理（ステップ１０１）では、まず、検索用テーブル１１にて検索を行い、キーと対応する引数１、２、３にて請求金額、消費税額、割引額を取得する。キーが３つまで存在しない場合は引数情報としてＮＵＬＬ値を設定するものとする。

ステップ１０２で検索用テーブル１１から取得可能か否かを判断し、ステップ１０２で検索用テーブル１１から取得できない場合については、セカンダリテーブル１０を検索し、請求金額を確定させる（請求金額情報取得処理（セカンダリ）：ステップ１０３）。

図４に示す例では、入力値であるキー１をガス料金の需給エリアを決める地区コードとして「地区１」、キー２をガスの使用量を表す情報として「１００」とする。その場合、ステップ１００の対象ＴＡＢＬＥ特定処理にて取得した検索用ＴＡＢＬＥ名の「ＴＡＢＬＥ１」を検索条件として、キー１に「地区１」、キー２に「１００」にて検索を行う。

検索を行った結果として該当レコードが存在するため、請求金額「２０００」、消費税「１００」、割引額「０」を取得する。検索用テーブル１１より取得できなかった場合は、検索を行うテーブル名を変更してセカンダリテーブル１０の検索を行う。

そして、ステップ１０４で付加料金情報が存在するか否かを判断し、ステップ１０４で付加料金情報が存在する場合は、付加料金情報加算処理（ステップ１０５）では、ステップ１０２、ステップ１０３での請求金額情報取得処理で取得した情報に加算を行うこととする。

延滞利息等の様に消費税という概念が存在しない金額については、付加料金消費税額を設定しない形とする。

図４に示す例では、入力値である付加料金額１が「１００」であり、付加料金消費税額が「５」であるため、請求金額を「２１００」、消費税額を「１０５」とする。

そして、最終的に出力情報となる請求金額、消費税額、割引額の確定を行い、出力を行う（請求額確定処理：ステップ１０６）。

そして、検索用テーブル反映処理（ステップ１０７）では、１人の需要者に対するバッチ処理が走行完了したタイミングで請求金額の確定に使用されたレコードと、そのレコードと関連性の高いレコードを検索用テーブルへ追加し、次の需給者のバッチ処理時に使用するものとする。

次に、図６により、本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側の検索テーブル反映部の処理の概要について説明する。図６は本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側の検索テーブル反映部の処理を説明するための説明図であり、セカンダリテーブル１０から検索用テーブル１１へレコードを反映する処理を示している。

検索用テーブル１１への追加処理については、検索用テーブル１１へレコードを追加するのは、検索用テーブル１１からレコードが取得できずにセカンダリテーブル１０よりレコードを取得した場合に行う。

セカンダリテーブル１０に定義されているレコード数は、各料金プランに対して必要な入力情報（可変値）の数によって異なり、入力情報が複数になればレコード数は増加していく。

検索用テーブル１１に移動する対象を特定する要素としては、検索に使用された情報と関連するレコードを合わせて移動させるための対象範囲を定義する抽出範囲増減数が必要である。抽出するレコードに範囲を持たすことで類似した検索の際にも検索用テーブルから検索できるように対応し、検索効率を向上させることができる。

セカンダリテーブル（イメージ図）２２は１レコードずつからなるセカンダリテーブルをキー１、キー２の対応関係を可視化したイメージ図である。抽出範囲増減数の定義はセカンダリテーブル（イメージ図）２２に記載されているとおり、抽出対象に使用したレコードと隣接するものが対象となる（図６の例では抽出範囲増減数は「１」）。

図６で記載しているものは、２つの入力情報（可変値）から料金計算の金額を確定するものである。

１人の需要者の請求額を確定するにあたって、図６の例では使用量が「２」、契約最大使用量が「２」であったと仮定している。請求額の確定に使用されたレコードは、使用量が「２」、契約最大使用量が「２」のレコードであり、そのレコードと隣接する抽出対象レコードの８件も合わせて追加されるものとする。

パッケージ開発会社１からセカンダリテーブル１０が展開された際は、検索用テーブル１１には該当レコードがない状態であり、バッチ処理にて請求金額を確定していく際にセカンダリテーブル１０から検索用テーブル１１へ追加を行っていく。

検索用テーブル１１へレコードを抽出するタイミングは１人の需要者に対する請求金額の確定が終了したタイミングで行い、次の需要者に対する請求金額の確定については追加された内容を参照する形となる。

パッケージ開発会社１から提供されてからの初回の需給者の料金計算を行う際は処理時間の短縮はできないが、料金計算処理を行うにつれて検索用テーブル１１に適正化されたレコードが登録されることになる。

その結果として、請求金額を確定する際の大半の処理では検索用テーブル１１へのアクセスとなり、検索効率を向上した形での検索処理を行うことができる。運用上を考慮するとセカンダリテーブル１０をパッケージ開発会社１より受け取った当初は、抽出範囲増減数を大きくしておき、検索用テーブル１１が適正化されていくに従って、抽出範囲増減数を小さくしていくことで、検索用テーブルへのレコード追加が無駄なく行うことができる。

次に、図７により、本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側の検索テーブル反映部の処理フローについて説明する。図７は本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側の検索テーブル反映部の処理フローを示すフローチャートである。

図６でも説明したとおり、検索用テーブル１１へレコード追加を行う場合は、セカンダリテーブル１０よりレコードを取得した場合である。

まず、セカンダリテーブル１０より検索したか否かを判断し（ステップ１１０）、ステップ１１０でセカンダリテーブル１０より取得を行った場合、抽出範囲増減数取得処理（ステップ１１１）にて抽出範囲増減数の数値を取得する。

取得した抽出範囲増減数と検索に使用したキー１、キー２の情報から対象のレコードを取得するために内部変数の初期化を行う（ループ処理初期化処理：ステップ１１２）。

次に、終了フラグが１か否かを判断し（ステップ１１３）、ステップ１１３で終了フラグが１であれば終了し、ステップ１１３で終了フラグが１でなければ、検索用レコード追加処理（ステップ１１４）にてセカンダリテーブル１０から検索用テーブル１１にレコードの追加を行う。

ステップ１１４では、追加を行う際に、検索用テーブル１１にキー１＝Ｘ、キー２＝Ｙとなるレコードが検索用テーブルに存在するか検索を行い、検索される場合は検索を行わず、次の処理を行う。

次に、Ｘカウントアップ処理（ステップ１１５）では、抽出範囲の対象内で次の対象を特定するために、変数であるＸをカウントアップする。

次に、ＸがＸ＿ＥＮＤより大きいか否かを判断し（ステップ１１６）、ステップ１１６でＸがＸ＿ＥＮＤより大きくなければ、ステップ１１３に戻り、ステップ１１６でＸがＸ＿ＥＮＤより大きければ、Ｙカウントアップ処理（ステップ１１７）にて、Ｙの値をカウントアップし、抽出範囲内のＸ軸に対する追加処理を全て実施した場合、次の行に対して処理を行うために変数Ｘの初期化を行う（Ｘ初期化処理：ステップ１１８）。

以上のように、本実施の形態では、パッケージ開発会社１にて、料金計算テーブル４を作成し、その料金計算テーブル４により、利用企業側料金計算システム８により、料金計算を行うようにしたので、料金計算処理にかかる時間を短縮することができる。

また、料金計算テーブル４として、全ての料金計算のためのテーブルであるセカンダリテーブル１０と、通常の料金計算に使用する検索用テーブル１１の２つのテーブルを使用するようにしたので、料金計算テーブル４から対象データを特定する際の検索効率を向上させることができる。

また、料金計算処理においては、一度に多量の需要者に対してバッチ処理を行うため、料金計算処理の短縮化の効果は需給者が多くなるにつれて、より効果が顕在化してくる。

本実施の形態では、料金計算テーブル４にて入力情報と請求金額を対応させた情報を管理することとし、その料金計算テーブル４の作成をパッケージ開発会社１側で実施することになる。その為、料金計算ロジックを集約してパッケージ開発会社１が保持することから、同業他社間で同一の料金計算処理ロジックとなっているパッケージ利用企業に対して、迅速に料金プランの追加・変更に対応した料金計算テーブル４を配布することができる。その結果として、パッケージ利用企業側では、料金プランの追加・変更に迅速に対応することができる。

また、同業種内で提供している約款のみで料金計算パッケージを提供する場合については、既存の料金計算テーブルを適用できることからパッケージ購入時の費用の削減、導入期間の短縮化を図ることができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

例えば、本実施の形態では、セカンダリテーブル１０から検索用テーブル１１にレコードを反映する際に、セカンダリテーブル１０の各レコードが検索用テーブル１１に存在するかのチェックを行ってから、なければ追加を行う形になっているが、この場合、検索用テーブル１１のレコードが適正化され、検索用テーブル１１に追加する必要がない場合は無駄な処理を行っている形になる。

そこで、その場合は、以下のような処理により、無駄な処理を回避するようにしてもよい。

・セカンダリテーブルに抽出済フラグを設け、そのフラグがＯＮにっている場合は、検索用テーブルのチェック処理は実施しないようにする。

フラグがＯＦＦの場合は検索用テーブル１１に追加処理を行い、セカンダリテーブル１０の該当レコードの抽出済プラグをＯＮとする。

これにより、無駄なチェック処理は行われないので、検索用テーブル１１が適正化されている場合でもオーバヘッドは発生しない。この判定は各お客様毎に実施する。

・セカンダリテーブル１０に抽出対象フラグを設け、その抽出対象フラグを全てのお客様に対しての料金計算が終了した時点で纏めて検索用テーブル１１へ追加する。

抽出対象フラグへの更新は抽出範囲増減数を考慮した範囲内のレコードに対してＯＮを設定する。１回の料金計算の処理で、同じレコードを範囲として指定された場合は、すでに抽出対象フラグがＯＮになっているが、特に判定はせずにフラグをＯＮとして更新する（判定をしてフラグがＯＮであれば更新しないという形でも問題なく、特に差異はない）。

検索用テーブル１１へのチェック処理、検索用テーブル１１への追加処理が実施されないので、レスポンスの悪化はしない。

１回の料金計算が終了すると、セカンダリテーブル１０には抽出対象となったレコードがあるので、そのレコードが検索用テーブル１１にあるかのチェックを行い、レコードを追加していく。

また、本実施の形態では、利用企業側料金計算システム８で料金計算する例を説明したが、利用企業側料金計算システム８として、企業が使用するハンディーターミナル内で、料金計算テーブル４を用いて料金計算を行うようにしてもよい。

この場合、ハンディーターミナルでは、通常は、料金計算テーブル４の検索用テーブル１１により、料金計算を行うことができ、処理能力の低いハンディーターミナルでも、料金計算を行うことができる。

本発明は、ガス、電力会社等における需要者への請求料金を確定する料金計算システムに関し、料金計算処理の短縮化が必要なシステムに適用可能である。

本発明の一実施の形態に係る料金計算システムの構成を示す構成図である。 本発明の一実施の形態に係る料金計算システムのパッケージ開発会社側の疑似入力情報作成処理を説明するための説明図である。 本発明の一実施の形態に係る料金計算システムのパッケージ開発会社側の料金計算テーブル作成処理を説明するための説明図である。 本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側での処理を説明するための説明図である。 本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側での処理フローを示すフローチャートである。 本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側の検索テーブル反映部の処理を説明するための説明図である。 本発明の一実施の形態に係る料金計算システムのパッケージ利用企業側の検索テーブル反映部の処理フローを示すフローチャートである。

符号の説明

１…パッケージ開発会社、２…疑似入力情報作成処理部、３…料金計算テーブル作成処理部、４…料金計算テーブル、６…パッケージ開発会社オンライン端末、７…パッケージ開発会社側料金計算システム、８…利用企業側料金計算システム、９…計算対象特定テーブル、１０…セカンダリテーブル、１１…検索用テーブル、１２…料金プラン判定部、１３…請求金額確定部、１４…検索用テーブル反映部、２９…計算対象料金プラン定義テーブル、３０…料金計算テーブル定義情報、３１…疑似入力情報作成プログラム、３２…疑似料金計算入力情報、３３…契約情報、３４…料金計算プログラム、３５…計算結果情報、３７…料金計算テーブル作成プログラム、５０…料金計算ルールテーブル、５１…料金計算単価テーブル。

Claims (5)

1. 料金計算用のパッケージを複数のパッケージ利用企業に提供するパッケージ開発会社のパッケージ開発会社側料金計算システムと、
   前記パッケージ利用企業の利用企業側料金計算システムとを備え、
   前記パッケージ開発会社側料金計算システムは、前記複数のパッケージ利用企業での料金計算ロジックを集約して管理し、前記料金計算ロジックに基づいて、複数の入力情報に対して請求金額を対応させた料金計算テーブルを作成し、
   前記利用企業側料金計算システムは、前記パッケージ開発会社側料金計算システムで作成された前記料金計算テーブルをセカンダリテーブルとして管理し、前記セカンダリテーブルから一部のデータを抽出した検索用テーブルおよび前記複数の入力情報に基づいて、料金計算を行い、請求金額を確定することを特徴とする料金計算システム。
2. 請求項１記載の料金計算システムにおいて、
   前記利用企業側料金計算システムは、前記検索用テーブルに前記料金計算に必要なデータが存在しない場合、前記セカンダリテーブルに基づいて、前記料金計算を行い、請求金額を確定し、前記料金計算に使用したデータを前記検索用テーブルに追加することを特徴とする料金計算システム。
3. 請求項２記載の料金計算システムにおいて、
   前記利用企業側料金計算システムは、前記セカンダリテーブルから前記検索用テーブルにデータを追加する際、前記料金計算に使用したデータを中心として、予め設定された抽出範囲のデータも追加することを特徴とする料金計算システム。
4. 請求項３記載の料金計算システムにおいて、
   前記利用企業側料金計算システムは、前記セカンダリテーブルに、抽出済フラグを設け、前記セカンダリテーブルから前記検索用テーブルにデータを追加する際、前記抽出済フラグが有効の場合、そのデータの追加処理を行わないことを特徴とする料金計算システム。
5. 請求項３記載の料金計算システムにおいて、
   前記利用企業側料金計算システムは、前記セカンダリテーブルに、抽出対象フラグを設け、前記セカンダリテーブルに基づいて、前記料金計算を行った際に、その料金計算に使用したデータの抽出対象フラグを有効にするだけで、前記検索用テーブルへの追加は行わず、全ての前記料金計算が終了した後、前記抽出対象フラグが有効のデータを、前記セカンダリテーブルから前記検索用テーブルに一括して追加することを特徴とする料金計算システム。

Images