Pricing Engine

Customer specific pricing is visible to users when they invoke a Commerce Process. The following table shows how different prices are applied and how they affect the subtotal.

The following image shows the Pricing Engine components, the interaction between each other, and their relationship with Configuration attributes, Parts attributes, and Commerce attributes.

One Pricing Rule may apply multiple Price Models; and one Price Model may be applied by multiple Pricing Rules

• Pricing Rules are conditions that determine when the Pricing Engine should adjust pricing.
  • Only header level pricing attributes (i.e. Transaction / quote level attributes or Configuration attributes that apply to all configuration elements in a Configurations session) can be used in rule conditions.
  • Pricing Rules support effective dates for pricing.

• Price Models (previously known as Pricing Profiles) very simply are containers for prices. They contain a set of price points, a set of discount percentages, or discount unit values that can be applied based on the conditions in Pricing Rules.

  • Header and line level attributes can be used in Price Models, however best practice is to use header attributes in Pricing Rule conditions and use line attributes in Price Model conditions.

• Pricing Attributes are custom attributes that map to Configuration, Parts, or Commerce attributes that can be used in conditions or scripts.

The CPQ Pricing Engine can calculate the same prices for one or many Commerce Processes, or different prices for different Commerce Processes, depending on your requirements. The Pricing Engine runs as part of the CPQ Pricing Function every time a triggering action is performed. The actual prices returned depend on the conditions you have defined in your setup in Pricing Engine. If no conditions are specified, then Pricing Engine will return the same price for a product across all Commerce Processes.

Pricing conditions can be applied at several levels when prices are calculated, based on the input values present in the Commerce Process main document (Transaction) attributes and sub-document (Transaction Line) attributes. Conditions can be defined as conditions for:

• A Pricing Rule

• A Price Model

• A Price Model Item (a product within a Price Model)

• A Price Model Product Price or Charge

When evaluating these conditions, the transaction-specific values are interpreted by Pricing Engine using the Pricing Engine Pricing Attributes Mapping.

Canonical Pricing Engine Pricing Attributes are those used internally by Pricing Engine. These may be viewed in the Pricing Portal ‘Pricing Attributes’ list page shown below by clicking on the ‘Pricing Attributes’ card on the Pricing Portal page:

These attributes can be used by defining a mapping of these canonical attributes to process-specific attributes and then specifying conditional values for these Pricing Engine Attributes in Pricing Rules, Price Models, Price Model Items, Product Prices and Charges. In the example below, we’ve drilled into the main document (aka ‘Header’) attribute “Price As Of’ and can see that it is mapped to the corresponding date attributes in two different commerce processes:

Only those Pricing Rules and Price Models which evaluate as ‘TRUE’ based on their conditions will return pricing for that Commerce Process, and other CPQ pricing methods will be applied to price the transaction if they exist. If Pricing Engine contains a Price Model called ‘2Q 2024 Pricing’ with a Start Date of April 1, 2024, then transactions in both Commerce Processes will receive this pricing when the Default Request Date and Pricing Effectivity Date attributes are greater than or equal to April 1, 2024.

To apply a Pricing Rule or Price Model to only one Commerce Process, define a condition that will only be true for the desired Commerce Process. You can even make the Commerce Process Name a Pricing Attribute for use as a conditional attribute.

A specific pricing structure can be created for an individual or multiple accounts. Administrators can create Price Models that contain prices for one or many parts, and if a particular account is tied to that Pricing Rule, they will see the price model pricing. This is done so that when a sales user is quoting a customer that has a pre-determined contract or pricing agreement, this special pricing is visible in the UI once the customer and item(s) have been identified. This is a way to define the list price of a given part, based on customer.

In the following example there are three Pricing Rules. In this example the XYZ Corporation is within the National Account pricing segment.

1. The first Pricing Rule is always true and applies the Base Consumer Model. This model is the starting point and is applied to all segments and customers.
2. The second Pricing Rule applies to all customers in the National Account pricing segment. This rule is attached to the National Account Model, which defines the discounts or prices for this segment.
3. The final rule in this example is specified for the XYZ Corporation. The associated Price Model for this rule implements a negotiated tiered pricing agreement.

When a customer in the XYZ Corporation purchases an item or service, the Base Consumer Pricing is applied, then the price is adjusted according to the National Account Model, and the final price will be set using the Negotiated Agreement Model with Tiers. The Pricing Rules and Price Models are invoked based on the values from the pricing engine attributes (e.g. Configuration Quantity then Commerce Quantity, Pricing Segment, and Account). Oracle CPQ 22C established predefined mapping for these attributes, along with several other frequently used attributes.

Administrators can define Volume and Tier pricing to provide differing discounts or prices based in the line quantity. Both volume and tier pricing employ dynamic pricing that is driven by the quantity of an item.

• Volume pricing applies the same price to all items on a single Transaction Line. The price or discount is based upon the quantity (total number of units).
• Tier pricing can apply different unit price values to different items of a single Transaction Line. The total price or discount of the Transaction Line is based on aggregating the pricing brackets for all units of the item for that Transaction Line.

Volume Pricing Example

Tier Pricing Example

The new Redwood UI provides a consistent approach for actions and navigation. Module actions are provided in the upper right Actions menu. Individual item actions available by clicking the line ellipsis.

Every UI page has a navigation link that will take the admin user to the parent module. The new UX also provides persistent search results and navigation between filtered items. For example, the following image shows a list of filtered search results.

When the admin user opens an item from the filtered search results, the search results are persistent. Navigation arrows are provided in the upper right to allow navigation to the previous or next filtered search result item.

• "Pricing Profiles" is renamed "Price Models" to better reflect that they contain price data.
• The "Basic" Pricing Rule is renamed "Customer-Specific" to more accurately represent the nature of this Pricing Rule type.
• The "Discount Type" selection is relabeled "Value Type" to indicate that absolute price values may also be selected as values.
• The Pricing Rule fields "Active", "From", and "To" are renamed as "Status", "Start", and "End".
• The General Site Option Apply only first matching Pricing profile is reworded as Apply only first matching Price model to consistently refer to the renamed Price Model object.
• The Commerce Option Transfer Advanced Pricing Profiles JSON to Commerce is renamed as Transfer Price Model JSON to Commerce to more accurately reflect that the JSON object contains a list of ALL Price Models applied by the Pricing Engine
• Search is enabled in Pricing Rules, Price Models, and Pricing Attributes to easily locate specific results.
• Validations are enhanced by graying out invalid selections rather than flagging an entry when the user attempts to save.
• Users can easily return to the parent object or list page using the "Up" arrow at the top left side of the page.

• Optimized Pricing Engine Performance
  Oracle CPQ 23B optimized Pricing Engine performance by eliminating redundant Pricing Engine invocations during sales user interactions to improve performance.
• BOM Item Product Pricing - Enables the CPQ Pricing Engine to set up and execute different prices for a product based upon the presence and location of the product within a product hierarchy, bundle, or BOM.
• Added new seeded Base Price Model that enhances the pricing administrator user experience by predefining the setup for the base / starting / ceiling price list.

• Added new seeded BOM Item Variable Name Attribute that automatically supports BOM item product pricing in Pricing Engine without t requiring a pricing administrator to set up this attribute and its mapping.

• Added new seeded Base Pricing Rule that enhances the pricing administrator user experience by predefining the setup for the Base Price Model at runtime.