1

My Company uses a pricing structure of packages with several sub-levels.

Because of this we may see something where our products look like this:

  • Product Suite
    • Product Series
      • Product Workshop
        • Product Module

In this example each Product Module is $1 USD, and the Product Suite would be equal to the sum of every module.

Our business requirements also ask that we discount if the whole Product Suite is selected, and if the customer pays annually.

So we have Price Rules set up for each instance EX: Suite, Annual, Suite & Annual, etc.

What I've discovered though is that this causes us to apply Annual Discounts as to our product listings twice.

Is there an easier way to calculate this discount and apply it? Or perhaps some way to use a different price rule when applying any rules for the suites?

  • how do you know if they are planning to buy annually? is this field on quote? – night crawler Aug 16 '17 at 23:23
  • @nightcrawler yes this is a field on the quote. – Cody Beaner Aug 17 '17 at 11:43
1

You should use the extra "lookup tables" functionality available within Price Rules.

How this works is, in addition to the header-level rule attributes, conditions for firing, and actions taken when true, is that there's also a "lookup query" you can define that points to a custom object and matches one value to another, similar to SQL (or SOQL). So you could create an object called "Suite Pricing" that has records for each product, and fields for each scenario that store a discount percent (e.g. field 1 is "Suite - 5%", field 2 is "Annual - 10%", field 3 is "Suite + Annual - 15%").

You would need 2 lookup queries: One to match the product on the quote to the record on the table, one to match the value to the scenario. Your condition is likely to fire all the time or if the quote line product family = your suites, and the action would be to populate that discount onto the quote line (or quote is fine, if you will only ever have 1 suite on 1 quote). Finally an additional rule or action on the same rule would inject the value of "price minus discount" into the pricing sequence, likely "special price" (and then an additional action would also set the "special price type", to any non-blank value, to make sure the system picks up your special price).

The one final consideration is to make sure you rules, and actions within rules, fire in the appropriate sequence. This should be easy to define based on your use case, but must be specified in the appropriate fields to prevent unwanted/unpredictable actions from occurring within your quoting sequence.

Hope this makes sense.

Thanks,

Christopher Hickman

Edit: Another possibility to consider would be to define separate SKUs for your "everything and the kitchen sink" bundles, set to be non-configurable (locked into selecting all) and discountable only at the parent level, or even not at all at the product level (in a discretionary sense; requiring a quote-level discount only spread across the entire "cart"). Depending on your/the client's views on "SKU proliferation" you may prefer the former method even though it is more complex to set up and requires more data maintenance (since the custom object records are in addition to products, price books, and product options/etc.) but tracking offering this way may actually be more natural to the organization if they think about things in a standard/enhanced/deluxe/ad-hoc way...the former method does provide that data but in a less straightforward way than just having 2 SKUs.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.