Price rule assignment and contracts
For a price rule to display offer prices on store pages, we must assign the price rule to a contract. This requirement applies to all business models (B2B, 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 we can assign price rules to, based on your business model:
| Business model | Contracts we can assign price rules to |
|---|---|
| B2B store |
|
| Extended site – B2B | 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 store
The following example shows how price rules might be assigned to various contracts for a B2B 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
The following example shows how price rules might be assigned to various contracts for a B2B 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 we 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 store also apply to B2B 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
For example, if customers shopping under the contract can purchase every catalog entry in the master catalog, do not assign a price rule to the contract that generates prices only for certain categories. A contract-level price rule must also contain a price list, that is, the price rule must be independent. We cannot assign a dependent price rule (one that does not contain a price list) as a contract-level price rule.
We 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. You might have a business need to assign multiple price rules to a contract for different time frames, as in this example:| Price rule A | Active time frame: January 1, 2015 to June 30, 2015 |
| Price rule B | Active from July 1, 2015 onward |
If so, we can edit the XML for the contract directly and specify the active time frame for each price rule. Keep in mind that only one price rule can be valid in a contract at a time, so the time frames you specify must not overlap.
We 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.