適切に計算されるように価格ルールの順序を指定する
学習の目的
この単元を完了すると、次のことができるようになります。
- CPQ 計算シーケンスのトリガーを特定する。
- 項目が更新されると自動的に計算がトリガーされるように、項目を設定する。
- CPQ 計算シーケンスの基本的な手順を説明する。
- 評価イベント項目が価格設定結果にどのように影響するかを説明する。
- 価格ルールの順序を指定して、特定の順序で実行する。
計算が実行されるタイミングを知る
このモジュールのすべての演習の一環として、見積に商品を追加して作業をテストしました。商品を追加すると、すぐに CPQ によってすべての価格設定計算が実行され、価格が想定どおりの値になっているかどうかを確認することができました。CPQ では、次のようないくつかの異なる状況下で価格設定計算が実行されます。
- 見積品目を追加または削除する。
- 見積品目エディターで、[Calculate (計算)]、[Quick Save (適用)]、または [Save (保存)] をクリックする。
- 見積レコードで [Calculate (計算)] をクリックする。
- 見積品目レコードへの変更を保存する。
- [Calculating Field (計算項目)] への変更を保存する。
計算項目とは、価格に何らかの方法で影響を与える可能性があるため、再計算をトリガーする必要があると CPQ で認識されている項目です。たとえば、サブスクリプション期間項目は計算項目です。見積を 24 か月から 36 か月に変更すると、おそらく価格に影響します。では、CPQ ではどの項目が計算項目であるかがどのように把握されるのでしょうか? 簡単です。項目は見積オブジェクトの [Calculating Field (計算項目)] の [Field Set (項目セット)] にあります。
[Setup (設定)] | [Object Manager (オブジェクトマネージャー)] | [Quote (見積)] | [Field Sets (項目セット)] | [Calculating Fields (計算項目)] に移動して、独自の項目を [Calculating Fields (計算項目)] に追加できます。たとえば、見積に「Expedited (急送)」という名前のカスタムチェックボックスがあり、そのチェックボックスが価格条件で使用され、送料の価格を調整するルールをトリガーであるとします。その項目を [Calculating Fields (計算項目)] 項目セットに配置します。これで、チェックボックスが (手動、自動化、または一括アップロードで) 変更されると、すべての価格を再計算することが CPQ で認識されます。
[Calculating Fields (計算項目)] 項目セットから項目を削除することはできますが、その際には注意が必要です。計算対象とすべき場合に、誤って価格が計算されなくなってしまうかもしれません。
価格ルールおよび見積計算シーケンス
CPQ では、見積が計算される際、見積、見積品目、見積品目グループのすべての項目で正しい値が確実に取得されるように、多くの作業がバックグラウンドで行われます。計算を実行するために必要な手順は、特定の順序で行われます。その手順の簡潔なリストを次に示します。
- 関連レコード (商品、オプション、コストなど) からデータを取得する
- [On Initialization (初期化時)] 価格ルールを実行する
- 数式項目を評価する (見積品目、見積、見積品目グループの順)
- [Before Calculate (計算前)] 価格ルールを実行する
- 見積品目の数量 (バンドルコンポーネントなど) を計算する
- [On Calculate (計算時)] 価格ルールを実行する
- 標準の価格設定ツール (ブロック価格設定、割引率表など) を計算する
- [After Calculate (計算後)] 価格ルールを実行する
- 数式項目を再度評価する (見積品目、見積、見積品目グループの順)
- 合計を計算する (グループと見積について)
ご覧のように、CPQ では価格ルールが異なるタイミングで 4 回実行されます。実際には、すべての価格ルールが 4 回実行されるわけではありません。むしろ、価格ルールの評価イベント項目にもよりますが、ほとんどの価格ルールは 1 回しか実行されません。
このバッジの活動を完了した際、すべてのルールで [Evaluation Event (評価イベント)] 項目セットを [On Calculate (計算時)] に設定したままにしました。つまり、1 回の計算につき 1 回のみ、見積品目の数量が計算された直後に実行されたということです。ほとんどの価格ルールの場合、このタイミングで実行して問題ありません。ただし、ルールの計算シーケンスを上下に移動しないと、想定どおりの結果が得られないことがあります。その場合、評価イベントを変更する必要があります。
たとえば、ランチバンドルを販売しているとします。各サンドイッチにはクッキーが 2 枚付いています。したがって、サンドイッチ 5 つではクッキー 10 枚ということになります。CPQ では、計算時ルールが実行される直前に数量の計算が行われます。次に、特別な顧客に対して、サンドイッチ 1 つにつきクッキー 3 枚を提供する、クッキーのバンドル数量を対象にした価格ルールを作成するとします。かなり凄いですね。ただし、ルールの [Evaluation Event (評価イベント)] を [On Calculate (計算時)] のままにしておくと、すでにクッキーの数量の計算が実行されているため、バンドル数量の更新が遅すぎることになります。そのため、5 つのサンドイッチを販売しても、顧客には 15 枚ではなく 10 枚のクッキーしか提供されません。
幸い、この問題を解決する簡単な方法があります。ルールの [Evaluation Event (評価イベント)] を [Before Calculate (計算前)] に変更してください。そうすれば、見積品目の数量が計算されるときに、クッキーの 2 枚から 3 枚への変更が反映されます。これで、サンドイッチ 5 つでクッキー 15 枚になります。
お気づきのとおり、評価イベントは複数選択リストです。1 つのルールを複数の評価イベントに追加することで、計算シーケンス中にそのルールを複数回実行できます。とはいえ、システムパフォーマンスを最大化するために、ルールは 1 つのイベントのみに限定することを強くお勧めします。
同時実行条件
[Calculate (計算)] をクリックすると、Salesforce CPQ によって計算シーケンスが順に開始されます。最終的には、初期化時の評価イベントに到達します。では、そのイベントには 3 つのルールがあり、実行される可能性があるとします。3 つのルールの条件はすべて、アクションが実行される前に CPQ によってテストされます。そのプロセスは次のようになります。
- ルール 1 の条件が満たされるかどうかをテストする [はいとします]。
- ルール 2 の条件が満たされるかどうかをテストする [はいとします]。
- ルール 3 の条件が満たされるかどうかをテストする [いいえとします]。
- ルール 1 の価格アクションを実行する。
- ルール 2 の価格アクションを実行する。
すべての条件は、指定された評価イベントで任意のアクションが実行される前に評価されます。CPQ では、4 つの評価イベントのいずれかに到達するたびに、このプロセスが繰り返されます。たいていの場合は問題ありません。ただし、2 つ目のルールの条件で使用される項目を対象にするルールが 1 つあると、問題が発生する可能性があります。たとえば、次の 2 つのルールがあるとしましょう。
- (IF) [Delivery Date (納品日)] が 2 週間以内である場合、(THEN) [Expedited (急送)] がオンに設定される。
- (IF) [Expedited (急送)] がオンになっている場合、(THEN) 送料に 20 ドルの追加料金が加算される。
この 2 つのルールが同じイベントで実行されるように設定されている場合、2 つ目のルールは実行されません。CPQ に関しては、次のようになります。
- [Delivery Date (納品日)] が 2 週間以内であるかどうかのテスト[はい]
- [Expedited (急送)] がオンになっているかのテスト[いいえ]
- ルール 1 の価格アクションを実行する。([Expedited (急送)] をオンに設定する: 遅すぎて意味がありません。)
このシナリオでは、ルール 2 のアクションが発生しないため、送料が正しく更新されません。これは非常に不適切な状態です。幸いにも、ソリューションがあり、最初のルールをより早い順序の評価イベントに移動させることができます。または、2 つ目のルールをより遅い順序の評価イベントに移動させることもできます。どちらの方法でも、これで [Expedited (急送)] をオンにするというアクションが実行されてから、2 つ目のルールの条件が評価されるようになります。
価格ルールでこの問題が発生しているかを判断するわかりやすい方法があります。つまり、想定価格を表示させる唯一の方法は、[Calculate (計算)] を複数回クリックすることであるということです。この場合、CPQ によって何度も計算シーケンスが実行されることになります。送料価格の例では、最初に [Calculate (計算)] をクリックすると [Expedited (急送)] が true に設定されます (送料は調整されません)。再度 [Calculate (計算)] をクリックすると、[Expedited (急送)] が true になっているため、送料が調整されます。
ここで問題になるのは、営業担当が計算ボタンを十分な回数クリックするという保証がないことです。そのため、適切な価格を取得するために、計算を複数回クリックすることに依存するのは到底許容できません。そのような事態に陥っていることが判明した場合は、ルールを別の評価イベントに移動することを検討してください。
アクションに関する順序
場合によっては、連動する 2 つの価格アクションを設定して、結果を連鎖的に計算させることもあります。たとえば、同じルールに次の 2 つのアクションがあるとします。
- [List Price (リスト価格)] を 535 ドルに設定する。
- [Max Discount Amount (最大割引金額)] を ([List Price (リスト価格)] - [Cost (コスト)]) に設定する。
この場合、2 では更新されたリスト価格が計算で使用されるように、1 が 2 の前に発生する必要があります。価格アクションレコードの順序を使用して番号付けすることで、アクションを特定の順序で計算させることができます。アクションは CPQ によって番号順に計算されます。
同様に、価格ルールレコードには、同じ評価イベントで実行されるルールの順序を指定するために使用できる評価の順番項目があります。つまり、この優先順位では、アクションが実行されるタイミングの管理方法は次の 3 つがあります。
- 価格ルールの評価イベント
- 価格ルールの評価の順番
- 価格アクションの順番
では、次の 3 つのルールがあり、それぞれに価格アクションが設定されているとします。どれが最初に実行されるでしょうか?
ルール A | ルール B | ルール C |
---|---|---|
Evaluation Event (評価イベント): On Calculate (計算時) Evaluation Order (評価の順番): 3 Price Action Order (価格アクションの順番): 20 |
Evaluation Event (評価イベント): On Calculate (計算時) Evaluation Order (評価の順番): 2 Price Action Order (価格アクションの順番): 30 |
Evaluation Event (評価イベント): After Calculate (計算後) Evaluation Order (評価の順番): 1 Price Action Order (価格アクションの順番): 10 |
ルール C の評価イベントは他のルールの場合よりも後に発生するため、ルール C はすぐに候補から外すことができます。つまり、ルール B の価格アクションが最初に計算されます。ルール B の評価の順番は 2 であり、ルール A よりも優先されます。ルール A のアクションの順番値がルール B のアクションの順番値より数値的に先であることは重要ではなく、ルールレベルの評価の順番が優先されます。
Salesforce CPQ では、価格ルールを適用するタイミングを詳細に制御できます。この機能を使用して、CPQ で初めて計算シーケンスが実行されたときに価格が正しく計算されていることを確認してください。
価格ルールは、ビジネスがどのような特有の理由で例外的な価格設定を行っているかにかかわらず、正確な商品価格設定に適しています。価格ルールを思いどおりに操作して活用しましょう。ただし、作業内容は必ずテストしてください。