[Gilles Muys]

You are correct. Using quote line groups allows you to specify a different term for each group, using Start Date and either Subscription Term or End Date. The QLE will automatically calculate the number of segments within each group.

[Gilles Muys]

Hey Aleksander, I have seen this use case. You can create a custom formula field on the Quote line that returns SBQQ__ProductOption__r.SBQQ__Feature__r.Name. Then you should be able to use that custom field in your price conditions. Obviously, your price rule needs to target the Calculator for this to work!

[Gilles Muys]

This is a fairly common use case actually. At the end of the day, you need to determine how data entry will be done between using multiple fields (street address, city, zip/postal code, state/province, country), or a single field which could be a text area field, or a lookup to an Account (or a custom object) that represents the delivery location.

Once you have made that first determination, it’s time to think about some automation since you are using MDQ. It’s not user friendly for example, to ask the sales rep to re-enter the same address on each segmented quote line. There are 2 ways to address this:

1. Use a virtual bundle as the parent of your segmented product. You might need a separate bundle for each segment product. You would specify the delivery location on this virtual bundle, and a simple price rule can propagate that field value to its child segment quote lines
2. Use the QCP to propagate the location specified in segment 1 to the other segmented lines

I personally favor the first approach, as it provides a consistent way of specifying the delivery location for both segmented and non-segmented products. My other preference is to use a lookup field to an account or potentially a custom object, rather than a text area field or a set of fields for the address. That makes it easier to re-use the same delivery address across multiple quotes. On the other hand, the record for the lookup object must exist before you work on your quote.

[Gilles Muys]

If you disable the triggers, the price rules and QCP plugin will no longer execute, until you re-enable them.

This is true when using SBQQ.TriggerControl.disable() (programmatic approach) or when disabling triggers in the package settings (manual approach).

It is recommended, after loading Quote, Quote Line Group, and Quote Line data with the data loader, to force loaded quotes to recalculate after you re-enable the triggers. This is done easily by running another UPDATE batch on loaded quotes and modifying a field that is in the Calculating Fields fieldset on the Quote object.

[Gilles Muys]

You just confirmed what I was suspecting, and you found a pretty good way to address the separate orders between the cancel and replace parts of such transactions. At the cost of additional complexity and customization.

[Gilles Muys]

Thanks @gaurang-patel for sharing your story. Indeed, you point out some common scenarios that have limited support with the Cancel & Replace package and therefore the need for its customization. MDQ is definitely adding layers of complexity across the board, despite being a really powerful tool for ramp and escalator deals.

How do you feel about the fact that the Cancel & Replace package is separating the Cancel part and the Replace part in two separate opportunities and quotes?

[Gilles Muys]

Yes, that’s the expected behavior. I usually create a custom field that I add to the Calculating Fields fieldset, and make sure every loaded quote gets a unique value in it, such as a datetime field that you set to TODAY(). Once the load is complete, you can delete that custom field, unless of course you execute such loads on a regular basis.

And you are correct, product rules targeting the Calculator will not execute if triggers are disabled.