リベート管理と関連機能を設定する
学習の目的
この単元を完了すると、次のことができるようになります。
- Salesforce フローテンプレートを挙げる。
- データ処理エンジン (DPE) 定義を挙げる。
- 一括管理について説明する。
- リベート管理の承認プロセスのしくみを説明する。
テンプレートを知る
前の単元では、リベート管理は Salesforce フローの事前定義済みテンプレート、データ処理エンジン、一括管理を備えていることを学びました。それぞれについて詳しく見ていきましょう。
データ処理エンジン (DPE): データ処理エンジンでは、組織の標準オブジェクトとカスタムオブジェクトからデータが抽出され、ビジネス要件に基づいて変換されます。変換されたデータを使用して特定のオブジェクトレコードを作成または更新できます。事前定義済みデータ処理エンジン定義を使用して、さまざまなリベート計算や取引記録用にデータの照会、絞り込み、集計ができます。
一括管理: どこかの時点で組織の数千件ものリベート支払レコードが処理待ちになるかもしれません。一括管理を使用すると、レコードを扱いやすいバッチに分割して一括処理することができます。スケジュール済みフローを使用して一括処理ジョブを実行し、[ワークフローサービスを監視] でジョブの状況や状態を追跡できます。
Salesforceフロー: Salesforce フローでは、Salesforce 組織または外部システムのデータを収集してアクションを実行できます。特定のビジネスプロセスを自動化するには、事前定義済みフローのいずれかを使用するか、さまざまな要素、トリガー、コネクタ、リソースを組み合わせて独自のフローを設計できます。フローを使用すると、DPE ジョブを使用してリベート計算プロセスを自動化できます。フローをスケジュールすることで、ビジネスにとって最適な時刻に実行することができます。
Cindy は事前定義済み DPE 定義、フロー、一括処理ジョブをコピーし、Rayler Parts の要件に合わせて再設定します。コピーすることで、元のテンプレートが変更されても、変更されていないコピーを使用できます。
次に、Cindy は各テンプレートがリベートプログラム用に合わせてどのようにカスタマイズされているかを調べます。
フローに従う
Cindy は Rishi や他のリベートプログラムマネージャーとミーティングを行い、テンプレートについて学んだことを説明します。事前定義済みフローについて次のことがわかりました。
フロー | 説明 |
---|---|
リベートオーケストレーションフロー |
リベートプログラムや計算に多くのカスタマイズが必要ない場合は、このフローを実行してエンドツーエンドのリベート計算を行います。リベートオーケストレーションフローでは、プロセス種別がリベートの DPE 定義を検索します。次に、計算プロセスをトリガーして支払金額を生成します。このフローには、リベート DPE ジョブを実行、リベート支払計算を実行、リベート金額を計算、リベート支払後のアクションを実行というフローが含まれます。 |
リベートオーケストレーションフロー 2 |
よりシンプルで拡張性の高いバージョンのリベートオーケストレーションフローです。このフローには、リベート DPE ジョブを実行、リベート支払計算を実行 2、リベート金額を計算、リベート支払後のアクションを実行 2 というフローが含まれます。 |
リベート DPE ジョブを実行 |
このフローでは、DPE 定義を実行して支払計算用のデータを集計し、レコードを生成します。リベートに DPE 定義のみを使用する場合はこのフローを実行します。 |
リベート支払計算を実行 |
このフローでは、DPE 定義と一括処理ジョブから支払金額を計算し、関連オブジェクトのレコードを作成または更新します。プログラムマネージャーは、オブジェクト全体での支払金額、小切手種別、メンバーなどを確認できます。 支払金額はリベートオーケストレーションフローが実行されるたびに計算されます。これによって、最終支払計算日より前に最新の支払金額を正確に知ることができます。 |
リベート支払計算を実行 2 |
このフローでは、前回の一括処理実行日以降に変更された集計レコードのみを処理します。 |
リベート金額を計算 |
このフローを使用して、集計レコードを処理してリベート金額を計算する標準一括処理ジョブの複数のバッチ実行を管理します。 |
リベート支払後のアクションを実行 |
このフローでは、支払後のアクションをトリガーし、計算日に期間を終了します。 |
リベート支払後のアクションを実行 2 |
このフローでは、支払後のアクションをトリガーし、さらにリベート支払の最終計算日を更新します。 |
事前定義済みフロー以外に個別のフローアクションもあり、フローをカスタマイズするために使用できます。フローアクションはリベートフロー内の詳細なタスクを対象とするもので、メンバーの登録、支払オブジェクトへの挿入なしの報奨金とリベート金額の取得、支払期間の生成などを行うことができます。
データを処理する
次に、Cindy は Rishi に各 DPE 定義が何を行うものであるかを説明します。
DPE Definition | 説明 |
---|---|
Aggregate by Member (メンバー別に集計)* |
この DPE 定義では、リベートプログラムからデータを抽出し、取引記録レコードをメンバーで絞り込み、適宜データを集計します。特定の支払期間のメンバー別集計金額がリベートメンバー商品集計オブジェクトの値として作成または挿入されます。 |
Aggregate By Member with Aggregate Item Details (集計品目の詳細と共にメンバー別に集計)* |
Aggregate by Member (メンバー別に集計) DPE で実行された変換に加え、この DPE 定義では、リベートメンバー集計品目オブジェクトで、対象取引記録レコードごとに 1 件のレコードを作成します。この定義は、各対象取引がメンバーの集計金額にどの程度寄与しているかを確認するために使用します。 |
Aggregate by Account (取引先別に集計)* |
取引先が複数のリベートプログラムに登録している場合、この DPE 定義を使用して、対象取引をリベート種別ごとに別のレコードに集計します。取引は支払期間ごとにメンバーレベルではなく取引先レベルで集計されます。 |
Aggregate by Product and Member (商品およびメンバー別に集計)* |
この DPE 定義では、リベートプログラムからデータを抽出し、取引記録レコードを絞り込んでデータをメンバーと商品によってグループ化します。Aggregate by Product and Member (商品およびメンバー別に集計) では、リベートプログラム報奨金の定義時に商品や商品カテゴリを追加した場合にも対応できます。 |
Process Per Transaction using Member (メンバーを使用して取引ごとに処理)* |
支払が取引または請求レベルごとに計算される場合、メンバーの各取引レコードを処理して、その取引に対する支払金額を生成できます。 |
Account Hierarchy Member Aggregate using Member (メンバーを使用した取引先階層メンバー集計)* |
1 つの階層内の複数の取引先が同じリベートプログラムのメンバーである場合、サブ取引先の取引を親取引先レベルで集計し、親取引先の支払金額を生成できます。 |
Ship & Debit Program Aggregate using Member (メンバーを使用した配送プログラムおよびデビットプログラムの集計)* |
配送とデビットのリベートプログラムでは、登録メンバーが優先納入先メンバーに販売した場合、特別な報奨金を受け取ります。この DPE 定義を使用して、メンバーが申請した請求金額を、プログラム参照番号や納入先取引先名などリベートプログラムの詳細と対照して検証します。対象取引は集計されて支払金額が生成されます。 |
Year Over Year Growth Aggregate using Member (メンバーを使用した前年同期比成長率の集計)* |
成長ベースのリベート用のこの DPE 定義では、メンバーの現在の支払期間の取引レコードを検索し、前年の同じ支払期間の対応するレコードと比較します。その後、データを集計して現在の期間と前年の同じ期間の合計数量と取引金額を生成します。 |
Insert Orders to Journal with Member (メンバーを使用して注文を取引記録に挿入) |
この DPE 定義では、有効なリベートプログラムの開始日から終了日までの間に処理されたすべての販売注文レコードを絞り込みます。そして、支払計算のために注文レコードを取引記録レコードにコピーします。 |
Rebate Calculations Post Processing (リベート計算の後処理) |
リベートオーケストレーションフロー 2 を使用したリベート計算が完了した後、この DPE 定義では、リベート支払の最終計算日を更新して、支払状況を計算済みに設定します。また、過去の支払計算日を使用して支払期間を終了します。 |
集計ロジックを地域別にカスタマイズしたり、プロセスにルールを追加したりするには、既存の DPE 定義を変更するか、テンプレートを基に独自の定義を作成します。
一括処理する
最後に Cindy は Rishi に一括処理ジョブのしくみを説明します。対象の取引レコードは DPE 定義によって絞り込まれ、集計された後、一括処理ジョブによって複数のバッチで処理されます。Cindy はいずれかの一括処理ジョブを変更するか、独自のジョブを作成できます。リベート管理には次の 2 つの事前提示済みジョブがあります。
- Calculate Rebate Payout (リベート支払の計算): この一括処理ジョブはレコードを 200 件ずつのバッチに分けて処理し、リベートオーケストレーションフローで使用されます。
- Calculate Rebate Payout for All Periods (すべての期間のリベート支払を計算): この一括処理ジョブはレコードを 2000 件ずつのバッチに分けて処理し、リベートオーケストレーションフロー 2 で使用されます。
リベートへの承認を得る
Rishi のレポートで提案されていたソリューションの 1 つは、財務的な影響が大きいことをふまえてスーパーバイザーと役員がリベートプロセスを厳しく管理できるようにするというものでした。
Rishi と話し合った後、Cindy は次の ToDo フローの承認プロセスを設定します。
- リベートプログラムへのメンバーの登録
- リベートプログラムの有効化
- リベート支払金額の調整
Rayler Parts は長年 Salesforce アプリケーションを使用しており、承認は標準機能の一部であるため、Cindy は承認プロセスの設定には精通しています。承認プロセスの設定についての詳細は、「リベート管理の承認」を参照してください。
次の単元では、Rishi が Mahira や Mehmood と話し合ったインセンティブモデルに基づいてリベートプログラムを作成します。