リベート管理の考慮事項と制限事項
リベート管理の使用を開始する前に、次の考慮事項と制限事項を確認してください。
必要なエディション
| 使用可能なエディション: リベート管理が有効になっている Enterprise Edition、Unlimited Edition および Developer Edition。 |
リベート管理に関する考慮事項
- リベート管理は、デスクトップおよびモバイルデバイスでのみサポートされます。
- データ処理エンジンアクション要素を使用してフローのスケジュールを設定する場合、データ処理エンジンジョブを順次実行します。定義済みリベート DPE ジョブをコピーすると、自動的に実装されます。
- 定義済みのデータ処理エンジンジョブは、すべての有効なリベートプログラムメンバーのすべての有効なプログラム、支払期間、およびリベート種別に対して実行されるように設計されています。特定のプログラム、期間、リベート種別、またはメンバーに対してデータ処理エンジンジョブを実行するには、特定のレコードを [リベート DPE ジョブを実行] フローの入力として渡します。
- 10,000 個を超えるリベート種別を 100 個を超える一意のリベート種別検索条件を使用して 1 つのデータ処理エンジン定義に関連付けないことをお勧めします。「Data Processing Engine Limits (データ処理エンジンの制限)」を参照してください。リベート種別を複数のエンジン定義に関連付けるか、1 回の実行でプログラムリベート種別または支払期間のサブセットのみが処理されるように入力を変更します。
- リベート種別には最大 100,000 個の報奨金を設定できます。データローダーを使用して大量のデータをアップロードする場合、一貫した結果が得られるようにシリアル同時実行モードを使用することをお勧めします。Bulk API ジョブの逐次同時実行モードでは、バッチが並列ではなく受信順に順次処理されます。リベート種別ごとに最大 10 個の報奨金を使用して内部検証が実行されています。大幅に多く使用すると、処理効率に影響し、分析中の支払計算ロジックの追跡が困難になる可能性があります。
- Experience Cloud ユーザーの取引記録レコードに関するレポートを作成することはできません。
- 特定のリベート種別に複数の報奨金が存在する場合は、データローダーを使用して基礎となるデータをリベート種別で並び替えてからアップロードします。
- マルチ通貨設定では、インテグレーションユーザープロファイルとデータ処理エンジンの書き戻しユーザープロファイルに対して同じデフォルト通貨を設定します。データ処理エンジン書き戻しユーザーを使用していない場合、同じデフォルト通貨を「データパイプラインベースユーザー」権限セットが割り当てられているシステム管理者プロファイルに対して使用します。リベート管理オブジェクトでは、次の方法でマルチ通貨構造が使用されます。
- 取引記録: 取引を目的の取引通貨で記録できます。
- リベートメンバー商品集計: データ処理エンジンジョブが実行されて集計が計算されると、取引記録の通貨はインテグレーションユーザープロファイルの通貨に変換されます。次に、金額が書き戻しユーザープロファイルの通貨で集計オブジェクトに保存されます。
- プログラムリベート種別支払取得元: 支払取得元は報奨金計算後に集計行の通貨コードで作成されます。
- プログラムリベート種別報奨金: 報奨金設定では、指定された最大金額と最小金額は集計行の通貨であるとみなされ、それに従って評価されます。
- リベート管理とチャネルパートナー在庫管理の両方が有効になっている組織で取引記録を作成する場合、次のようになります。
- チャネルパートナー在庫管理の [取引記録種別] を指定します。[取引記録種別] によって、チャネルパートナー在庫管理プロセスでの取引記録の使用方法が決まります。作成時に [取引記録種別] が空白のままの場合、[利用状況種別] はデフォルトで [リベート] になります。
- リベート取引記録の状況に対する DPE 絞り込みを設定します。リベート DPE は、[取引記録状況] 項目に基づいて自動的にレコードを除外しません。顧客が [状況] 項目 ([承認済み]、[却下済み]、[保留中] など) を使用して集計または支払を生成するレコードを制御する場合、リベート DPE 定義で検索条件を明示的に設定する必要があります。たとえば、対象レコードのみが処理され、[承認済み] 以外の状況 ([待機中] や [却下済み] など) を除外するには、TransactionJournal.Status = 'Approved' などの検索条件ロジックを含めます。
- 従来のレコードの互換性を確認します。既存のリベート取引記録レコードがデフォルトで [待機中] 状況になっている場合、DPE はデフォルトで [状況] で絞り込まれず、すべての PoS 取引が処理されます。適切なレコードが処理され、意図しないレコードが含まれたり除外されたりしないように、適切な DPE 検索条件ロジックが設定されていることを確認します。
リベート管理の制限事項
- データ処理エンジンの制限
- データ処理エンジンの問題のトラブルシューティング
- 一括管理使用時の留意事項
- フローの制限および考慮事項
- ロイヤルティ管理とリベート管理が有効になっている場合の取引記録からのメンバー詳細の取得
- データマネージャー接続を介して RebateProgramPayoutPeriod オブジェクトを同期する場合、同期時に SOQL クエリを使用して派生項目の [承認済み金額合計]、[却下済み金額合計]、[メンバーの支払数] が計算されます。約 25,000 件以上の RebateProgramPayoutPeriod レコードがある組織では、同期ジョブが QUERY_TIMEOUT エラーで失敗する可能性があります。この場合、ジョブ監視では、失敗後でもジョブの状況が [処理中] と表示される場合があります。ジョブの詳細で失敗メッセージを確認し、実際のジョブの状況を確認します。
メモ データ処理エンジンは Government Cloud または Government Cloud Plus では使用できません。
リベート管理ガードレール
リベート金額を計算し、リベートプログラムメンバーの支払を生成するプロセスを使用して、リベートプログラムを設定および管理します。通常、これらのプロセスでは、プログラム、期間、メンバー間で大量のリベート取引が処理されます。
- リベート金額を計算し、リベートプログラムメンバーの支払を生成するプロセスを使用して、リベートプログラムを設定および管理します。通常、これらのプロセスでは、プログラム、期間、メンバー間で大量のリベート取引が処理されます。
- リベート管理では、データ処理エンジン (DPE) と一括管理を使用した一括処理によって大量のデータがサポートされます。推奨されるデータ量ガードレールは、定義済みのリベート種別および関連付けられた報奨金に基づいてプログラムメンバーにリベート支払が発行されるシナリオ用にテストおよび設計されています。これらのガードレールは効果的な計画をサポートし、実装時の信頼性の高いパフォーマンスを保証します。これらは厳密な技術的制限ではなく、実際の結果はデータサイズ、複雑さ、設定によって異なる場合があります。リベート管理のライセンスとパッケージの詳細を参照するには、こちらを参照してください。メモ 特定の取引記録量を処理するためのガードレールは、業種間で一貫しています。これらのガードレールを別の業種に適用する場合は、注文オブジェクトとその関連する考慮事項および前提条件を、そのコンテキストで取引記録と元帳を生成するオブジェクトに置き換えます。ガードレールは、顧客の要件の複雑さに応じて異なる場合があります。
DPE を使用したエンドツーエンドのオーケストレーションのガードレール
次のシナリオは、データ処理エンジンを介して取引記録が処理される、内部でテストされたオーケストレーションフローの概要を示しています。
- シナリオ 1
組織データの概要: さまざまなデータオブジェクトの有効な数
オブジェクト 計数 詳細 リベートプログラム 5000 リベートプログラムメンバー 15,000 プログラムあたり 3 人のメンバー (親を含む 2 レベルの階層) リベート期間 60,000 プログラムあたり 12 か月の期間 リベート種別 30,000 プログラムあたり 6 個のリベート種別 プログラムリベート種別報奨金 180,000 リベート種別あたり 6 個の報奨金 リベート条件 90,000 リベート種別ごとに 3 つの対象資格条件 取引記録 2500 万 メンバーあたり期間あたり 140 件の取引記録 メモ これらの制限は内部でテストされています。ボリュームが大きい場合は、Salesforce システム管理者にお問い合わせください。
実行概要
- 使用される DPE: Aggregate By Member (メンバー別に集計)
- 処理済みリベート種別: 30,000
- Filters Processed (処理された検索条件): 90,000
- レシピサイズ: 799.1 KB
- 一意の検索条件: 200
Processing Summary (処理の概要): 次の表に、このレシピで処理された行数を示します。
| 結合種別 | Total Rows (合計行数) (30K リベート種別) | ノードの説明 |
|---|---|---|
| リベートプログラムとリベート種別 | 30,000 | 有効なリベートプログラムの有効なプログラムリベート種別を提供します。 |
| リベートプログラム、リベート種別、リベート支払期間 | 180,000 | 選択した有効なリベート種別の有効な支払期間を提供します。 |
| リベートプログラムメンバー、リベート支払期間、リベートプログラム、リベート種別 | 360,000 | 選択した有効なリベート種別と支払期間の有効なプログラムメンバーを指定します。 |
| 取引記録、リベートプログラムメンバー、リベート支払期間、リベートプログラム、リベート種別 | 1,166,400,000 | リベート種別と支払期間情報を取引記録データに追加します。 |
| Filter Data Valid Transaction Journal (データの絞り込みの有効な取引記録) | 97,200,000 | 活動日に基づいて、これらの TJ 数は今後の処理に有効です。対象資格基準の評価はこのセットで行われます。 |
| Final Data Valid Tansaction Journal (最終データ有効タンザクション記録) | 97,200,000 | 対象資格基準の事後評価 - 最終的に集計された行数。 |
計算: 10,000 リベート種別 × 90 取引記録/メンバー × 3 メンバー/プログラム × 12 期間/プログラム
メモ これらの制限は内部でテストされています。データがこれらのボリュームまたはディメンションを超える場合は、DPE ジョブをコピーして分割します。たとえば、10,000 件のリベート種別を 5,000 件の 2 つのジョブに分割します。サポートが必要な場合は、Salesforce システム管理者にお問い合わせください。
リベート支払計算のガードレール
組織概要
- 集計レコード: 18,000,000
- 支払期間: 180,000
実行概要
| プロセス | シナリオ 1 |
| バッチサイズ | 2000 |
| 処理者 | 集計レコード |
| 有効なリベートプログラム | 1 |
| 集計レコード数 | 1,800,000 |
| 有効なリベートプログラムメンバー | 15,000 |
| 有効な支払期間 | 12 |
| Total Records in Rebate Member Payout (リベートメンバー支払の合計レコード数) | 180,000 |
メモ
上記の数値は内部テストを反映しています。実際のパフォーマンスは、お客様の環境、設定、カスタマイズによって異なる場合があります。ボリュームが大きい場合は、Salesforce システム管理者にお問い合わせください。
リベート支払のデフォルトのバッチサイズは 2,000 レコードです。データ量とカスタムロジックに基づいて 200 ～ 2,000 の範囲で調整できます。Apex制限に達した場合はサイズを縮小し、システムのニーズを評価した後にのみ調整します。バッチサイズの選択については、Salesforce の担当者にお問い合わせください。
リベート処理方法を選択するときの考慮事項
リベートの処理方法を決定するときは、次の点を評価します。
ベストプラクティス
ガードレール内に留まり、パフォーマンスのボトルネックを回避するには、次の点に留意してください。
- 不要になった取引記録、リベート支払、リベート集計、およびリベート支払ソースレコードをアーカイブまたは消去します。
- [リベートプログラム] または [プログラムリベート種別] 検索条件を使用してバッチを処理します。
- 大量の報奨金のアップロードには、データローダーのシリアルモードを使用します。
- リベート支払を処理するデフォルトのバッチサイズは 2,000 レコードです。カスタマイズ内容とデータ量に応じて、この値は 200 ～ 2,000 レコードの間で調整できます。カスタマイズが原因で Apex ガバナ制限が発生した場合は、バッチ サイズを減らすことを検討してください。値を調整するには、データと処理要件を評価した後で行ってください。
この記事で問題は解決されましたか?
ご意見をお待ちしております。
