Operate > WebSphere Commerce Accelerator > Business relationship management


Case Study: WebSphere Commerce contract modeling

WebSphere Commerce contracts are the foundation for determining what customers can purchase in an online store, and what price should be offered for the products. The contracts functionality is extremely flexible in that it can support many types of e-commerce business models and their complex business requirements. This flexibility is very powerful, and an optimal contract design can minimize the amount of effort required to manage business accounts and contracts. As well, an optimal design can minimize the amount of system resources required and thus enhance system performance. This topic explains the fundamental concepts used in developing a WebSphere Commerce contract model, and provides a detailed example that illustrates the use of these concepts.


Fundamental concepts

The following are the fundamental concepts used in a WebSphere Commerce contract design. Once these concepts are understood, they can be combined together to form an optimal design for a commerce site.

Contracts

A contract defines the terms and conditions under which a customer shops while they are in a commerce site. These terms modify the customer's shopping experience, including what products the customer can purchase, what prices they are entitled to, and what shipping and payment options they may use. See Contract terms and conditions for the entire set of terms and conditions available under a contract.

To enable a contract to be accessed by customers in a store, the contract is deployed to the store.

Terms and Conditions

The most commonly used term and condition is the Catalog Filter term. This term is the basis for setting entitled products and prices. The Catalog Filter term has the following settings:

  • If the entire catalog is selected, then the customer can purchase everything in the master catalog, except for any specifically excluded categories or products.

  • If the entire catalog is not selected, then the customer can purchase the categories and products that have been specifically included, except for any specifically excluded categories or products.

  • If the customer is entitled to multiple Catalog Filter terms, and any term excludes a category or product, then the customer will not be able to purchase that category or product under the applicable contract.

  • A percentage adjustment can be set for the entire catalog, specific categories and specific products. Within one term, the lowest level setting in the catalog hierarchy will take the pricing precedence.

  • Fixed prices can be set on specific products. This creates a custom price list which has a higher pricing precedence than the store's master price list. Therefore the fixed price will override any price from the master price list.

  • If a customer is entitled to multiple Catalog Filter terms, they will be entitled to the lowest price from the set of terms. The price list precedence also helps determine which price term takes priority.

In some business scenarios, the pricing and product terms for a customer are maintained in an external system. These terms need to be imported into Commerce to provide the correct entitlement in the online store. In this situation, it is preferable to have the contract refer to a price list and a product set by using a corresponding Price business policy and a Product Set business policy. The contract will then use the appropriate Price and Product Set terms and conditions to refer the respective business policy.

Participants

The commerce system determines who is allowed to use a contract from the 'Buyer' participants associated with a contract. Buyer participants can be an Organization or a Member Group, and a contract may have multiple Buyer participants. A contract can also have an empty Buyer participant which means that all customers are allowed to use that contract.

When a customer logs into site, they will be entitled to:

  • All contracts in which their immediate parent organization, or any parent organization is a Buyer participant. The immediate parent organization can be the one to which the member is directly assigned, or an organization in which they have the OrganizationParticipant role.

  • All contracts in which a member group they belong to is a Buyer participant.

  • All contracts in which there is an empty Buyer participant (unless this is restricted by their business account; more on that later).

If a customer is a guest shopper, or has not logged in, then they are only entitled to the contracts with empty Buyer participants.

Customer contracts

A customer contract is one that has a Buyer participant. This is distinguished from a base contract which does not have any Buyer participants. (Note that having an empty Buyer participant is different from not having any Buyer participant.) When the Commerce system determines a customer's entitled contracts, it is from the set of customer contracts deployed in the store.

Base contracts

A base contract is a contract without any Buyer participants. Base contracts are used to contain a set of terms and conditions that can be shared by many contracts. No customer is directly entitled to a base contract. A customer is allowed to use the terms and conditions from a base contract only if one of their customer contracts refers to the base contract.

A contract may only refer directly to one base contract, but there can be a hierarchy of contracts, which allows a contract to share the terms from several base contracts. Placing as many terms as possible in base contracts minimizes the contract management necessary, and reduces the amount of system resources required.

Base contracts can be created in a customer facing store to be shared by any contracts in the store. As well, base contracts can be created in an asset store that allows the base contracts to be shared by contracts in many different stores.

Terms and conditions that are applicable to many customers, or many of a single customer's contracts, should be placed in a base contract. All the contracts that refer to the base contract will share the terms from the base contract. The customer contract effectively gets a union of all the terms and conditions in the customer contract along will all the terms and conditions in all the base contracts referred to by the customer contract. Any changes made to a base contract are automatically included in any customer contract that refers to the base contract.

Default contract

A store has a default contract which allows guest and unregistered shoppers to shop in the store. The contract has an empty Buyer participant. The default contract typically has terms and conditions that specifies the entire master catalog is for sale at standard prices.

Business accounts

Base contracts are the most common way to share terms and conditions. However, terms that are only applicable to a particular customer should be placed in the customer's business account. All contracts under the business account will share the terms from the account. These terms include purchase orders and credit line. See Account terms and conditions for the entire set of terms and conditions available under a business account.

ContractSetInSession

As described above, a customer can be entitled to a set of customer contracts. Based on the design, there may be situations where you only allow the customer to use a subset of those entitled contracts in their current shopping session. For example, a customer may be entitled to three contracts, each one for a department of their company. However, the business has a requirement that each department must have a separate order. When the customer logs in, they will choose which department they are purchasing for, and the corresponding contract for that department will be set into the customer's session. Therefore the customer will only see the products for the appropriate department, and this will ensure the order applies to one department.

OrganizationSetInSession

A customer may only have one immediate parent organization in the Commerce organization hierarchy, and thus is only allowed to use only the contracts entitled to that organization. This can be restrictive in many situations. A customer may be allowed to shop on behalf of several organizations.

To achieve this, the customer can have the OrganizationParticipant role in many organizations. When the customers logs in, they can choose which organization they wish to purchase for. This organization is set into the customer's session, and it becomes the active organization. The customer will then be allowed to use all the contracts entitled to the selected active organization. By default, the session's active organization is the customer's immediate parent organization.


Case study in contract modeling

The following example illustrates how to use these concepts to create an optimal contract design for an online store. A company has a B2B commerce site for its customers. The following requirements need to be supported for their customers:

First, consider a very simple design with no sharing at all. We want each customer to have a set of contracts, each representing a unique bill-to/ship-to combination. Diagram 1 illustrates an example where Customer X has 2 bill-to addresses, and each bill-to address has 2 ship-to addresses. Customer X is entitled to four customer contracts. When an employee of Customer X logs in, they will be allowed to shop under the four entitled contracts. (Customer X's business account specifies that they are not entitled to shop using the store's default contract. If the account did not have that setting, then the customer would also be entitled to a fifth contract, the store's default contract). However, we have the requirement that the shopper may only shop for one bill-to/ship-to combination at a time. This can be solved by presenting the list of entitled contracts to the shopper, and allow the shopper to choose one of the contracts. We only allow the shopper to use the one selected contract during this shopping session. The selected contract can be set in the session by using the ContractSetInSession command, and then the shopper can only shop under that contract.

This solution, however, presents a usability concern. Each customer may have ten bill-to addresses, and each bill-to may have at least five associated ship-to addresses. When a customer logs in, they would be presented with a list of fifty bill-to/ship-to combinations. We do not want the customer to scroll a long list. When the customers logs in, they know for which bill-to they are purchasing, and therefore they should first be presented with a list of bill-to addresses. Once a bill-to address is selected, only then will they need to select the appropriate shipping address. We could write some custom logic to present the fifty contracts in a meaningful way, but preferably the contract functionality can be used to help us present the contract selections. The bill-to addresses can be modeled as base contracts, and the associated ship-to addresses are customer contracts that refer to a bill-to contract. Diagram 2 illustrates these contract relationships. This modified design helps in that we can first present the set of bill-to base contracts, and then only display the referring ship-to base contracts once the bill-to contract has been selected. This solution still requires writing some custom code to find all the base contracts from the entitled customer contracts.

Group the bill-to and associated ship-to contracts under different organizations will help solve this problem. We will use the active organization feature of WebSphere Commerce. Instead of displaying a list of base contracts, we will display a list of organizations for which the customer can shop. A customer can shop for their own organization, plus any organization they have been granted special shopping role under. This role is called the OrganizationParticipant role.

Customer X will no longer be directly entitled to the customer contracts. Instead, we will create organizations that represent each of the bill-to addresses. These bill-to organizations will then be the Buyer participants in the ship-to customer contracts under the bill-to base contract. Customer X is given authority to use the contracts for each of the bill-to organizations by having the OrganizationParticipant role in the bill-to organization. When a member of Customer X logs in, they can be presented a list of all the organizations in which they have the OrganizationParticipant role. This essentially means they will have a list of the bill-to organizations. When one of these organizations is selected, the OrganizationSetInSession command is called, and switches the user to be a member of the selected organization for this session. As a result, the customer will be entitled to the contracts entitled to the selected bill-to organization. Therefore the list of ship-to contracts entitled to the bill-to organization can be presented to the customer. When the customer selects one of the ship-to contracts, that contract can be set in the session with the ContractSetInSession command, and now the customer is shopping under their selected bill-to/ship-to contract.

There are some added benefits of using the Organization Participant solution. For each active organization the customer uses, they will have a separate shopping cart. This fits nicely with our business model as each active organization is mapped to a bill-to address. Therefore, each unique billing address will have its own shopping cart and order, so each bill-to address will be billed separately. However, different shipping addresses (different contracts) under the same bill-to will share the same order.

The billing address for each bill-to can be placed in the address book of the corresponding bill-to organization. This keeps all the billing addresses separate and identifiable during the checkout process. In the original design the user would have to identify the correct billing address from the customer's address book. Now the billing addresses are separate in each bill-to organization's address book, and the billing address can be filled in on the checkout pages by selecting the billing address from the active organization's address book.

Use the Change Flow tool in the WebSphere Commerce Accelerator for the AdvancedB2BDirect store to enable an OrganizationSetInSession and ContractSetInSession user interface that allows selecting the active organization and applicable contracts for the customer's session.

All of a customer's contracts need to share the same product and pricing terms and conditions. A base contract is created that will contain the customer's catalog filter term and condition, and all of the customer's bill-to base contracts will refer to the customer's catalog filter base contract. Thus, all the customer contracts will share the same terms and conditions, and the terms and condition only need to be maintained under one contract. If there were any additional terms specific to a bill-to or ship-to, then they could be added to the applicable contract. Each ship-to customer contract will consist of the union of the terms and conditions from the ship-to contract, the referred to bill-to base contract, and the customer's entitlement base contract.

The customer is entitled to the store's list price, with some exceptions where the customer has their own specific price. The Catalog Filter can specify all the product and pricing information. The filter uses two price lists - the store's master price list to get the list price, and the customer's price exceptions price list. The customer's price exceptions price list has a higher precedence than the store's master price list to ensure the price exceptions override the list price.

The customer is only allowed to purchase a subset of the master catalog. Any exclusion of categories or products can be set in the Catalog Filter.


Design Review

To review the design:


Conclusion

There are often several ways to model a customer's product and pricing entitlement in a WebSphere Commerce store. However, by effectively using the fundamental contract concepts described in the topic, an optimal contract design can be modeled. This design can often reduce the necessary contract management, and reduce the load on system resources. It can take some time and experience to understand all the contract functionality and capabilities. However, once these concepts are mastered, then the best way to model a specific store's contract requirements becomes clear.


+

Search Tips   |   Advanced Search