Telecom-billing-rating-processes

提供:Dev Guides
移動先:案内検索

テレコム請求-評価プロセス

レートは、イベントの発生に対する料金/価格です。 料金の例には、通話中の料金が含まれます。たとえば、「1分あたり0.40 INR」または特定の数量。 例:1MBのダウンロードで10.00 INR、またはサービスの品質に対して課金できます。

イベントは、製品/サービスの使用の単一の発生であると既に説明しました。 イベントはネットワーク要素によってCDRS/UDRの形式でキャプチャされ、評価および請求のために請求システムに渡されます。

評価は、個々のイベントの料金/価格を決定するプロセスです。 たとえば、2分間の通話料金は0.80 INR、1分あたり0.40 INRです。

課金システムの一部である評価エンジンは、この評価機能を実行します。

評価プロセス

評価エンジンは、製品/サービスの使用を記述するコール詳細レコード(CDR)または使用詳細レコード(UDR)と呼ばれるデータレコードの形式でイベントを受信します。 CDRは、イベントの評価に使用される、コールの日付と時刻、コールの長さ、発呼側、被呼側などのコール情報を含むデータの文字列です。

評価/評価エンジンの基本的な機能のリストがあります-

  • ローミングを使用する場合に、仲介システムまたは他のサービスプロバイダーまたはローミングパートナーからのCDRを受け入れます。
  • CDRの検証と重複レコードの削除。 これらの重複イベントは、後で確認するためにデータベーステーブルに保存されます。
  • イベントに対して請求する必要がある顧客アカウントを決定するため。 ここで、Rateプロセスはイベントソース(モバイル番号またはIPアドレスなど)を取得し、データベースをチェックして、このイベントソースがアカウントに関連付けられているかどうかを確認します。 このステップはイベントガイドと呼ばれます。
  • イベントをガイドできない場合、このイベントは拒否され、サスペンスカテゴリに入れることができます。 これらの拒否されたイベントは、後で確認するためにデータベーステーブルに保存されます。
  • 評価料金表(料金プランとも呼ばれます)に従ってイベントのコスト/価格を計算します。
  • 該当する評価時間の割引を適用します。 これは最初の5分間は無料で、その後は通常料金で請求されます。 このようなタイプの割引は、格付け時間割引と呼ばれます。
  • 評価目的のイベントを請求目的でデータベースに保存するか、請求のために外部システムに送信します。

次の画像は、評価エンジンとその関連機能の概要を示しています-

評価関数

顧客の情報により、料金/価格の計算に使用する料金プラン(料金表)が決まります。 評価エンジンは、評価テーブルとCDRからのイベント情報を使用します(例: 距離、時刻、通話の場所、イベントの継続時間または音量など)を呼び出して、各通話の実際の料金を計算します。

重複イベント

重複イベントは、以下のすべての方法で別の未請求イベントに関連する未請求イベントとして定義されます-

  • アカウント番号は同一です。
  • イベントソースは同じです。
  • イベントタイプIDは同じです。
  • イベントの日付と時刻は同じです。

重複イベントを識別するために、他の基準を請求システムで定義できます。 重複したイベントが課金システムに送信される可能性のある状況がいくつかあります-

  • メディエーションシステムのフィルタリングメカニズムの障害。
  • メディエーションシステムソフトウェアのコーディングエラー。
  • 評価エンジンに渡されるイベントファイルの全部または一部の繰り返し。

拒否されたイベント

Billing Systemが特定のイベントで問題を検出すると、問題のイベントは拒否されます。 拒否は、次のいずれかの問題が原因である可能性があります-

  • イベント自体。
  • 料金プラン。
  • 顧客およびアカウントのデータ。
  • 構成データ。

イベントを拒否する主な理由は3つあります-

  • 解析エラーにより、請求システムはイベント詳細レコードの情報を読み取ることができません。 イベントレコードのデータが破損しているか、形式が間違っているため、解析エラーが発生する場合があります。
  • 誘導不可能なエラーにより、ジュネーブはイベントに関連付けられたイベントソースまたはアカウントを特定できません。 イベントソースがBilling Systemデータベースにまだ存在しないため、ガイドできないエラーが発生する場合があります。
  • 評価不能なエラーにより、請求システムはイベントのコストを計算できません。 料金プランに問題があるため、評価できないエラーが発生する場合があります。

拒否されたすべてのイベントは、 internal account または suspense account と呼ばれる特別なアカウントに投稿され、これらの拒否されたイベントは* suspenseイベント*と呼ばれます。 財務部門は、拒否されたすべてのイベントを追跡し、収益損失の一部としてカウントします。 IT部門は、拒否されたイベントを解決し、適切に評価して収益を節約するために、常に多くの注意を払っています。

拒否されたイベントを修正できず、オペレーターがそのイベントを内部アカウントに投稿したくない場合、イベントを破棄できます。 イベントが破棄されると、そのイベントは評価エンジンに送信されず、それ以上の評価の試みは行われません。

リアルタイム評価

リアルタイムレーティングとは、イベントの発生とコストの発生をできるだけ遅延させずに、発生したイベントを即座に評価するプロセスです。 リアルタイム評価は、ファイルベースの評価とは対照的です。ファイルベースの評価では、ファイル全体が最終的に評価されるまで、イベントの詳細が数時間、数日、または数週間ファイルバッファーに保存されます。

リアルタイムシステムプロセスには、eコマーストランザクションとデータダウンロードが含まれます。 イベントを評価して顧客のアカウントにすばやく適用する必要があるアプリケーションは、リアルタイムの評価に適しています。

イベントの再評価

イベントを再評価する必要がある状況がいくつかあります。 たとえば、

  • 使用された料金プランのエラーにより、イベントの価格が不正確になりました。
  • イベントは、間違ったアカウントに対してロードされました(イベントソースの登録が正しくないため)。
  • 既存の料金プランは、最後の請求日と次の請求日の間のある時点で置き換えられました。
  • 製品の料金プラン、価格プラン、またはイベントソースが遡及的に変更されました。

イベントを再評価するプロセスは非常に簡単で、次のとおりです-

  • 提供されたユーティリティを使用して、データベースからすべてのイベントをアンロード/評価解除します。 課金システムのほとんどは、評価されたすべてのイベントをアンロードまたは評価解除するユーティリティを提供します。
  • 問題がどこにあっても修正します。
  • 評価エンジンによる評価のためにイベントを再送信します。

部分的なイベント

部分的なイベントにより、イベントの進行中に顧客のバランスを維持できます。

たとえば、データのダウンロードが長い場合、メディエーションシステムは部分的なイベントを課金システムに送信し続けるため、課金システムはイベントの完了を待たずにそれらを評価し続け、顧客の信用限度違反が発生するとすぐにアカウントは禁止され、ネットワーク要素は、コールを終了するよう通知されます。

しきい値とアクション

評価エンジンは、評価時間の割引しきい値を含む評価時間のしきい値に達しているかどうかを自動的に確認できます。

評価時間のしきい値は、多くの収益損失から事業者を保護するのに役立ちます。 たとえば、顧客は自分の与信限度額を超えて支払うことを望まない場合があり、そのような場合、与信限度のしきい値に達するとすぐに顧客の通話を終了することが必要になります。

評価時間のアクションを実行する必要がある場合は、できるだけリアルタイムで評価することが重要です。

次は何ですか?

これまで、顧客が使用量を生成する方法と、メディエーションシステムがその使用量(CDR)を課金システムにプッシュする方法、および課金システムがそれらのCDRを評価する方法について見てきました。

次の章では、1か月間のすべての評価済みCDRを収集し、最終的な請求書/請求書を生成する方法について説明します。