料金計算可能明細管理の実行

料金計算可能明細管理では、データベース構造を定義する必要があります。データベース構造には、後続の料金計算手順のほか、業種またはカスタマ固有の要件が反映されている必要があります。統合請求では、事前定義されたインタフェースを使用するデータベース設計がサポートされています。

1.料金計算可能明細のインポートおよび管理

料金計算可能明細のインポートおよび管理には、料金計算可能明細クラスの設定の機能を使用することができます。

データインポートのインタフェース設定において、料金計算可能明細クラスは、料金計算可能明細の技術属性を示します。

料金計算可能明細クラスのインタフェース生成

契約未収金/未払金管理のカスタマイジングで、料金計算可能明細クラスのデータを転送および保存するために必要なオブジェクトを生成します。

料金計算可能明細の保存

料金計算済明細とシミュレートされた料金計算済明細がデータベース上で別々に保存されるように、料金計算可能明細クラスを設定することができます。

料金計算可能明細のモニタ

ステータスグループに基づいて、料金計算可能明細をモニタする機能があります。SAP Easy Access 画面で、料金計算→モニタの順に選択します。また、料金計算可能明細を処理から除外するか、処理できるように復元することで、料金計算処理のステータスを個別に変更することもできます。

2. 料金計算可能明細の処理

料金計算では、契約アカウントの料金計算可能明細を処理します。料金計算手順では、料金計算可能明細の選択に使用されるルール、および料金計算単位への自動グルーピングに使用されるルールを指定することで、料金計算が制御されます。料金計算単位ごとに、料金計算伝票が登録されます。

料金計算可能明細の主要構造に加えて、税および支払のデータも、税明細構造および支払明細構造に保存されます。

料金計算可能明細には、以下のステータスのいずれかが設定されます。

• 0 (ロー)

• 1 (ロー - 除外)

• 2 (料金計算可能)

• 3 (料金計算可能 - 除外)

• 4 (料金計算済)

ローデータは完全である必要はなく、整合性も必須ではありません。個々の項目のデータは変更することができます。

たとえば、チャージングシステムで認識されているビジネスパートナでも、ローデータに契約アカウントがない場合があります。

料金計算可能明細は、料金計算を行う前に、完全かつ矛盾のない状態にしておく必要があります。

ステータスがロー - 除外および料金計算可能 - 除外の明細は、後続の処理から除外されます。つまり、こうした明細は、転送時または料金計算時に考慮されません。

料金計算可能明細クラスのすべての料金計算可能明細は、それぞれのステータスに応じて別々のデータベーステーブルに保存されます。料金計算可能明細を分析するときには、評価するステータスを最初に選択する必要があります (料金計算でのレポートモニタなど)。

料金計算済明細とシミュレートされた料金計算済明細のデータストレージを別々に定義することができます。料金計算済明細のデータストレージは、時間依存として定義することができます。

レコードタイプにより、業務上で関連する料金計算可能明細の特性がグループ化されます。

以下のレコードタイプのデータは、データベースとメインメモリで別々に管理されます。

• IT (主要明細)

• PY (支払データ明細)

• TX (税明細)

• TT (テキスト明細)

レコードタイプ IT に属する料金計算可能明細は、料金計算の基本データを提供するために必要です。その他のレコードタイプは、既存の IT レコード (クレジットカード補足など) なしでは料金計算できない従属レコードタイプです。

レコードタイプごとに別々のテーブルが使用されます。

BIT クラスの要件は、ビジネスニーズから派生されます。以下に、ビジネスの例を 3 つ説明します。

ビジネス例 1

先行する Web ショップ販売プロセスで、インターネットダウンロードの料金計算可能明細ごとに、支払カード情報が提供されます。そのため、料金計算可能明細を直接参照する、支払カード情報用の追加の料金計算可能明細が必要です。料金計算可能明細クラス TDAT には、支払カード情報の追加データベース構造が必要です。

ビジネスの例 2

Telco の料金計算可能明細のレーティングおよびチャージングシステムにより、料金計算可能明細ごとの税がすでに計算されています。そのため、料金計算可能明細ごとに追加税 BIT が必要です。料金計算可能明細クラス TC01 には、追加税 BIT のデータベース構造が必要です。

ビジネスの例 3

レーティングおよびチャージングのシステムは SAP Convergent Charging です。Convergent Charging との統合に適した事前定義済データベース構造および汎用モジュールを有効化する必要があります。料金計算可能明細クラス HRAT により、Convergent Charging のインタフェースが有効化されました。

料金計算可能明細クラスはまだ有効化されていません。

すべてのビジネスの例で、データベース構造に関するさまざまな要件があります。これは、例 1 では支払カード情報の追加データベーステーブルが必要であり、例 2 では税情報が必要であり、例 3 ではデータベース構造とともにプロセス統合が必要であるためです。このコースでは、ビジネスの例 1 に焦点を当てます。

カスタマイジング:

クラスの新規登録または既存クラスの変更は、契約未収金/未払金管理のカスタマイジングで財務会計→契約未収金/未払金管理→統合請求→基本機能→料金計算可能明細→料金計算可能明細クラス→更新: 料金計算可能明細クラス→明細クラスの順に選択して実行できます。

料金計算可能明細クラスはクライアント非依存です。

SAP からはクラスを提供していません。カスタマイジングでの料金計算可能明細クラスのプロセス設定は、インタフェースコンポーネントメニューによって適切にサポートされています。ここで行う設定は、データベーステーブルの外観およびデータ転送のインタフェースに影響を及ぼします。

以下のステップに従って、料金計算可能明細クラスを設定します。

1. インタフェースコンポーネントの選択

2. カスタマ項目の選択 (オプション)

3. 料金計算済明細のテーブルの管理

4. シミュレーション対象の料金計算済明細テーブルの管理

5. 設定の有効化

6. 料金計算可能明細クラスのインタフェース生成

インタフェースコンポーネントは、料金計算の観点からビジネスプロセスを表します。これにより、料金計算可能明細クラスでサポートされる取引 (繰延収益や前受/前払金消込など) が定義されます。したがって、インタフェースコンポーネントは料金計算可能明細クラスのインタフェースです。

技術的な観点から見ると、インタフェースコンポーネントは、コンポーネントの文書、必須項目の選択、従属/前提条件インタフェースコンポーネントの指定、および項目値のチェック、誘導、割当で構成されます。

料金計算可能明細クラスの更新時に、インタフェースコンポーネントをクラスに割り当てることができます。この割当に基づいて、インタフェースコンポーネントの項目が自動的に統合されるインタフェースが生成されます。インタフェースには、データを転送する汎用モジュールと、データが保存されるテーブルの両方が含まれています。SAP では、事前設定されたインタフェースコンポーネントを用意しています。

一部のインタフェースコンポーネントは、契約未収金/未払金管理の請求の一部である特定の請求機能に対応しているか、またはその請求機能に追加されます。インタフェースコンポーネントで定義された項目は、作業構造にも含める必要があります。そうしないと、データが失われる可能性があります。

レポート RFKKBIXBITSTRUCCHECK を使用して、作業構造の項目をインタフェースコンポーネントの項目と比較し、不整合を照会することができます。

Web ショップ販売プロセスで、インターネットダウンロードの料金計算可能明細ごとに、支払カード情報が提供されます。そのため、支払カード情報には追加の BIT が必要です。料金計算可能明細クラス PBLW には、支払カード情報のデータベース構造が必要です。

インタフェースコンポーネントの定義は、財務会計のカスタマイジングで財務会計→契約未収金/未払金管理→統合請求→基本機能→料金計算可能明細→料金計算可能明細クラス→定義: インタフェースコンポーネントの順に選択して実行できます。

SAP では、請求機能 PCCARD_PAYM のデータ構造およびプログラム拡張を提供しています。

SAP には、すぐに使用できる事前設定されたインタフェースコンポーネントが用意されています。これには、各レコードタイプに必須の基本コンポーネントと、クラスに追加できるその他のオプションコンポーネントが含まれます。カスタマ固有のインタフェースコンポーネントを登録することはできません。

ビジネスの例:

料金計算可能明細クラスに対して支払処理および税処理が選択されます。主要明細、支払明細、および税明細に対してデータベーステーブルが生成されます。

カスタマイジングの財務会計→契約未収金/未払金管理→統合請求→基本機能→料金計算可能明細→料金計算可能明細クラス→更新: 料金計算可能明細クラスで、DB テーブルセット押ボタンを選択して、以下の機能にアクセスすることができます。

料金計算の実行が成功した後は、料金計算済明細をさまざまなデータベーステーブルに保存することができます。たとえば、毎月新しいテーブルを使用して料金計算済明細を保存することができます。テーブル追加押ボタンを使用してテーブルを生成することにより、料金計算済明細のテーブルを追加することができます。使用されるレコードタイプの数に応じて、新規エントリを行うごとに適切な数のテーブルが生成されます。こうしたテーブルは、テーブルセットとして管理されます。この後は、カスタマイジングの料金計算可能明細管理→設定: データストレージで、これらのテーブルセットを使用する方法を指定することができます。料金計算では大量のデータが生成されるため、このアプローチによって明細の管理およびアーカイブを簡素化することにつながります。

テーブルの名称は自動的に提案されます。クラスの個々のテーブルは、テーブルセットと呼ばれるテーブル名の末尾に付く連続番号によって区別されます。また、シミュレーション用のテーブルと更新実行用のテーブルは区別されます。

カスタマイジングアクティビティの設定: データストレージで、このアクティビティで定義した日付以降に使用されるストレージテーブルを入力することができます。(契約未収金/未払金管理のカスタマイジングで、財務会計→契約未収金/未払金管理→統合請求→基本機能→料金計算可能明細→料金計算可能明細管理→設定: データストレージを参照します)

料金計算済明細のテーブルセットとシミュレートされた料金計算済明細のテーブルセットは区別されます。テーブルセットは、実績決済とシミュレートされた決済の両方に対して指定する必要があります。実績決済およびシミュレートされた決済ごとに、一度に 1 つのテーブルセットのみを使用することができます。

このテーブルセットは、料金計算済明細を削除するためのオプションの選択基準として使用されます (レポート RFKKBIXBIT4DELETE)。

設定を移送する前に、カスタマイジングアクティビティ更新: 料金計算可能明細クラスで関連のクラスを有効化する必要があります。有効化するクラスを選択し、設定有効化を選択します。

設定ステータス - 処理中:

これは、料金計算可能明細クラスの初期設定ステータスとして設定されます。このステータスが付いている料金計算可能明細クラスでは、すべての変更が許可されます。ただし、このクラスの設定を別のシステムに移送することはできません。

設定ステータス - 移送可能:

このステータスになるまで、設定を別のシステムに移送することはできません。このステータスが付いている料金計算可能明細クラスでは、すべての変更が許可されます。

設定ステータス - 稼働中としてリリース済:

このステータスが付いている設定は、他のシステムに移送して生成することができます。この設定に対して互換性のある拡張のみがサポートされます。以下が可能です。

• 新規インタフェースコンポーネントの追加

• 新規項目の追加

• 料金計算済明細の新規ストレージテーブルの追加

• 新規索引の登録

候補となるステータスは以下のとおりです。

新規:

有効な設定バージョンがまだ存在しない新規クラスが指定されます。

変更済:

クラスの変更された設定バージョンが指定されます。そのクラスに古い有効なバージョンが存在します。

有効:

生成に使用できる有効な設定バージョンが指定されます。

クラスの有効化は、そのクラスが内部で一貫している場合にのみ実行することができます。これは主に、エラーのないクラスが必須であるという意味です。ある特定の時点で存在できる料金計算可能明細クラスの有効バージョンは 1 つのみです。クラスの有効バージョンを変更しても、再度有効化しない場合は、有効バージョンに加えて稼働バージョンが登録されます。設定を有効化すると、稼働バージョンが有効バージョンになります。有効化していない場合は、有効バージョンに戻る押ボタンを選択して、稼働バージョンから、設定の最後の有効バージョンに戻すことができます。

クラスの設定ステータスが稼働中としてリリース済になると、即座に有効バージョンの履歴が書き込まれます。この履歴を使用して、設定が変更された日時を確認することができます。履歴を表示するには、設定バージョンの表示を選択します。

トランザクション FKKBIXBIT_GEN で、料金計算可能明細の転送および料金計算可能明細のデータ保存に使用するインタフェースを生成します。

このトランザクションは、カスタマイジングの財務会計→契約未収金/未払金管理→統合請求→基本機能→料金計算可能明細→料金計算可能明細クラス→生成: 料金計算可能明細クラスのインタフェースにあります。

生成プロセス中は、インタフェースのステータスに応じて、以前に生成されたオブジェクトが削除されます。つまり、データの損失が発生する可能性があります。この状況でのシステムの動作は、インタフェースの稼働ステータスに依存します。インタフェースのステータスは、以下のいずれかです。

• 非本稼働インタフェース

  既存のオブジェクトが削除され、再生成されます。この場合、データは失われます。

• 本稼働インタフェース (テスト)

  既存のオブジェクトが削除され、再生成されます。この場合、データは失われます。

• 本稼働インタフェース

  以前に存在していなかったオブジェクト、または修正が必要なオブジェクトのみが再生成されます。すでに存在していたデータは影響を受けません。

料金計算可能明細ごとに、コンテンツ "Speed" を含むカスタマ固有項目があることが重要です。この項目は集計の基準であり、複数の異なる料金ポジションが印刷された請求書に記載される必要があります。料金計算可能明細クラスの Main_item には、コンテンツ "Speed" を含む項目の追加が必要です。

料金計算可能明細クラスの設定でカスタマ項目を使用するには、最初に、以下のカスタマイジングインクルードのいずれかに、そのカスタマ項目をレコードタイプごとに追加する必要があります。

CI_FKKBIXBIT_IT (主要明細のデータ)

CI_FKKBIXBIT_PY (支払データ明細)

CI_FKKBIXBIT_TX (税明細)

カスタマ項目を料金計算可能明細の処理に含めるために、料金計算可能明細クラスの設定が有効化される際に作業構造の完全性がチェックされます。チェックされた構造には、不足しているカスタマ項目が自動的に追加されます。こうした項目は、作業構造の関連カスタマイジングインクルードに追加されます。

SAP はカスタマインクルードを提供しません。カスタマインクルードは、使用する前に生成する必要があります。

料金計算可能明細クラスはカスタマイジングで設定します。設定はカスタマイジングデータとして保存されます。設定のステータスを "移送可能" に変更するとすぐに、このカスタマイジングデータをテストシステムに移送することができます。移送接続は、料金計算可能明細クラスを設定するためのトランザクションに標準として統合されています。完全で整合性のある設定のみが移送されます。

移送されたカスタマイジングデータを基準として、対応するワークベンチオブジェクト (データ転送用の RFC 汎用モジュール、データストレージのデータベーステーブルなど) をテストシステムのクラス用に生成することができます。

その後、テストデータを使用してクラスをテストすることができます。

テストが正常に終了したら、カスタマイジングデータを本稼働システムに移送して、そこでクラスのオブジェクトを生成することができます。