Price rule assignment and contracts
For a price rule to display offer prices on store pages, you must assign the price rule to a contract. This requirement applies to all business models (B2B direct, B2C, and extended sites).
After you assign the price rule to a contract, customers shopping under the contract see and are entitled to prices from the price rule. A price rule is one of many terms and conditions that a contract can have. For a given contract, only a single price rule can be in effect at one time. Therefore, the price rule you assign must generate prices for every customer and for every catalog entry available to customers under the contract.
The following table identifies the types of contracts you can assign price rules to, based on your business model:
| Business model | Contracts you can assign price rules to |
|---|---|
| B2B direct store |
|
| Extended site – B2B direct | All the same contracts as in the previous row, plus:
|
| Extended site – B2C |
|
| B2C store |
|
* A base contract to support inheritance in the extended site business model. Included by default in storefront asset stores for starter stores.
Price rules at work: B2B direct store
The following example shows how price rules might be assigned to various contracts for a B2B direct store:
- Price rule 1 is assigned to the default contract for the store. Price rule 1 displays prices from an Offer Price list. Guests and unregistered customers, as well as customers with no other contract, see these prices on the storefront.
- Price rule 2 is assigned to a base contract. This price rule marks the Offer Price list down by 5%. Any customer contracts that inherit from this base contract that do not have their own price rule inherit Price rule 2 prices. This means Customer contract A inherits Price rule 2 prices, and Buyer participant A sees these prices on the storefront.
- Price rule 3 is assigned to Customer contract B. This price rule marks the Offer Price list down by 20%. Even though Customer contract B inherits some terms and conditions from the base contract, it does not inherit pricing because it has its own price rule assigned. Buyer participant B is entitled to Customer contract B prices and therefore sees Price rule 3 prices on the storefront.
- Price rule 4 is assigned to Customer contract C. This price rule marks the Offer Price list down by 10%. Customer contract C does not inherit anything from the base contract. Buyer participant C is entitled to Customer contract C prices and therefore sees Price rule 4 prices on the storefront.
Price rules at work: extended site - B2B direct
The following example shows how price rules might be assigned to various contracts for a B2B direct extended site:
- Price rule 1 is assigned to the storefront asset store base for default contract. This price rule displays prices from the Offer Price list. Any extended site stores that do not have a price rule assigned to their base for default contract or default contract inherit Price rule 1 prices. This means the Aurora U.S. store inherits Price rule 1 prices, and customers shopping the Aurora U.S. store see these prices on the storefront.
- Price rule 2 is assigned to the base for
default contract for the Aurora Canada store, which the default
contract for the store inherits from. This price rule marks the Offer
Price list up by 20%. Customers shopping the Aurora Canada store see these
prices on the storefront. Note that the base for default contract
is simply a base contract, so you can use it as a base contract for customer
contracts to inherit from as well, although this is not shown in the
diagram.
The extended site stores in this diagram show only store-level contract assignments to simplify the example; however, the example in Price rules at work: B2B direct store also apply to B2B direct extended site stores.
Price rules at work: extended site - B2C
The following example shows how price rules might be assigned to various contracts for a B2C extended site:
- Price rule 1 is assigned to the storefront asset store base for default contract. This price rule displays prices from the Offer Price list. Any extended sites that do not have a price rule assigned to their default contract inherit Price rule 1 prices. This means the Aurora U.S. store inherits Price rule 1 prices, and customers shopping the Aurora U.S. store see these prices on the storefront.
- Price rule 2 is assigned to the default contract for the Aurora Canada store. This price rule marks the Offer Price list up by 20%. Customers shopping the Aurora Canada store see these prices on the storefront.
Price rules at work: B2C store
The following example shows how a price rule is assigned to the default contract for a B2C store:
Price rule 1 is assigned to the default contract for the store. All customers see prices from Price rule 1.
Contract-level price rules versus nested price rules
A contract-level price rule is the price rule that you assign to a contract. Contract-level price rules must be able to generate a price for:- Every customer entitled to the contract
- Every catalog entry available to customers under the contract
You can also create price rules that you intend to nest in other price rules, rather than assigning them directly to a contract. Because these nested price rules are not assigned directly to contracts, they do not need to follow the same requirements as contract-level price rules.
You create contract-level and nested price rules exactly the same way; the only difference is how you use them. For example, the same price rule can be assigned to a contract and also be nested in another price rule.
Price rule start and expiry dates
By default, price rules do not have start and expiry dates; the assigned price rule will be active when the contract is active. For this reason, when you assign a price rule to a contract in WebSphere Commerce Accelerator, there are no fields to enter start and expiry dates.| Price rule A | Active timeframe: January 1, 2015 to June 30, 2015 |
| Price rule B | Active from July 1, 2015 onward |
You can leave gaps between time frames. In the previous example, you could have Price rule B start on August 1, 2015 instead of July 1, 2015, leaving a one-month gap in July when no price rule is active. In this case, the customer can still see the store catalog during July, but no pricing information is displayed and the customer cannot purchase the catalog entries. Note that if a contract does not have an active price rule, WebSphere Commerce always checks whether the contract refers to a base contract. If so, the price rule assigned to the base contract is inherited during the gap.