#Price Rule0 utenti parlano di questo argomento

Rachel,

This sounds like the perfect use case for a summary variable in conjunction with you price rule. Here is the general idea:

1. Create a summary variable that will total up all Multipads. I'm not sure how you designate those in your org. A common criteria would be Product Family = 'Multipad'. But you could probably do it with SKUs as well.
2. Add that summary variable as criteria to your price rules. In your current rule(s), you would replace the conditions that say SKU greater than 10 with summary variable greater than 10. 
3. Keep your price actions the same.

There may be a little more involved, depending on how your rules are set up right now, but hopefully this gives you a direction to start. Let me know if you run into issues or have any further questions!

How about using flag field?

First, It apply the price rule and rule update the flag field(name as rule applied, checkbox type)unchecked to check

rule have a condition that flag field is unchecked.

Second, when user update the discount, rule just applied once before, so user can change the discount and price rule don't rollback the discount value.

I’m not sure it is the better solution, so definitely consider the tradeoffs and test thoroughly in a sandbox before you implement it.

Another option, again depending on whether you can define criteria for lines where no discount should apply, is to use Price Rules to target the Non-Discountable flag (or zero out the discount) on the Quote Line in a more dynamic sense. You can also use Quote Line Groups and use the standard functionality to apply discounts to one group while leaving another group untouched. Lots of possibilities. The right solution will depend on your specific preferences and requirements.

Let's step back for a second: You can update a unit price based on a FIELD VALUE. The place where this can happen today is not configuration, it's pricing/commerce - the line editor.

"Product options" should only be thought of as the logical reference to a product that exists entirely within configuration. There is a lookup to product option from a quote line which was created based on selection of a particular product within configuration, but nothing is updated or changed on that option according to what an end-user does in CPQ. Configuration attributes, similarly, are logical references to a field, in this case that exists on the product option object. A configuration attribute value specified in configuration can be used to select or remove a product (product rules) and that value can be written/updated on the resulting quote line (twin field functionality), but until Spring '20 is available the weekend after Valentine's Day, you cannot create a price rule that fires in the configuration context based on a configuration attribute - you can only create one which fires in the line editor context based off an attribute's quote line twin.

Even when the new capability is rolled out, you may still wish not to update unit price within configuration because price rules will continue to be extremely limited in configuration contexts. The reasoning for that was the subject of a long write-up on generalized CPQ best practices in a comment I posted in a different thread. But in general/short, it is beneficial to design simplicity/elegance and performance to separate search + configuration (resulting in a DML operation) and pricing + discounting (resulting in a record update), as opposed to trying to do them both at the same time (trying to select a product and customize its price simultaneously).