Operate > WebSphere Commerce Accelerator
Business relationship management
WebSphere Commerce contains a flexible business relationship system. This system allows you to customize what a customer can do in a store. This is referred to as customer entitlement. You entitle customers to various aspects of a store such as what products they can purchase from a store, the price they pay for a product, and what payment methods a store will accept from customers.
Customer entitlement is controlled by the following WebSphere Commerce components:
- Business accounts
- Business policies
The default customer entitlement is defined by a store's default contract. This default contract typically specifies that customers can access the master catalog and purchase products at standard prices.
Business relationship management provides the infrastructure and tools that facilitate scenarios like the following examples:
- Extended sites
- Create a contract for each extended site governs the product assortment and the respective prices available to customers of that site. As an example, consider a company that sells products in multiple countries. This company configures a different extended site for each country in which they do business. In this case, the company should create a contract for each country-specific extended site. The contract would specify the available product assortment, and set the respective prices for each country.
- Customer groups
- Create a contract for each customer group governs the product assortment and the respective prices available to the customers that explicitly belong to that group. This can serve as the basis for implementing customer loyalty groups. As an example, consider a company that offers a 5% discount to customers that belong to a special 'Platinum Club'. In this case, they would need two contracts. One that applied to regular customers, and a second that included the special 5% discount across the board for any customer that was an explicit member of the Platinum Club member group. In a related issue, customers that met the criteria for being a member of this club would have to be manually added to the member group. Contracts can only be applied to member groups that explicitly define their members.
- Business customers
- Create a contract for each organizational unit associated with a business account establishes the terms and conditions that govern the product assortment and the respective prices available to employees of that customer. As an example, consider a company that sells products to multiple business customers. Each customer organization with which they do business is entitled to one or more contracts independently. Collectively, the applicable contracts impose the negotiated available product assortment, and the respective prices for each customer.
These scenarios are explored in further detail in the Business Relationship Model topic.
In each of these cases, WebSphere Commerce enforces the defined contracts while customers are browsing the site, modifying the customer experience based on the criteria that you define. Furthermore, you can import contracts from external sources. For example, if you have contracts defined in an external CRM, or ERP system, these contracts can be exported to XML, and then imported into WebSphere Commerce. This ensures that the valuable contract data only has to be maintained on one system, with regular updates to the production server.
Business accounts represent the relationship between a store and the store's customer organizations, and are the starting point for managing business relationships. Using business accounts, you can track contracts and orders for customer organizations and configure how buyers from customer organizations shop in a store.
A business account contains the following information about a customer organization:
- The name of the customer organization and a contact person within that organization.
- The department and name of the account representative from the store assigned to the customer organization.
- Information about purchase orders a customer organization has with a store.
- How invoices are delivered to the customer organization.
- If the customer organization has a credit line.
- The shipping methods that are available for the customer.
- The payment terms established between the store and the customer.
- Any display customization information for the business customer. Store pages can be customized for a business account by specifying a piece of HTML code that can be used by a store's JavaServer Pages files.
- Any general remarks about the business account.
Also, business accounts control customer entitlement by controlling the ability of buyers from customer organizations to access a store's master catalog and see standard pricing for products contained in the master catalog. If a customer organization is not entitled to purchase products in the store's master catalog at standard prices, they are limited to products and prices covered by contracts the customer organization has with a store.
Before creating a business account for a customer organization, the customer organization must already exist in WebSphere Commerce.
Contracts enable a customer organization to purchase products from a store at a specified price for a specified period of time under specific conditions. Contracts affect many parts of a customer's shopping experience such as what products a customer is able to purchase, the price they will pay for the products, how they are allowed to pay for an order, and the addresses to which an order can be shipped. WebSphere Commerce provides the ability to record and deploy contracts that have been negotiated. Use the WebSphere Commerce Accelerator to manage contracts, for example, creating, changing, deploying, suspending, resuming, and unlocking contracts.
A contract consists of the following elements:
- The contract profile contains the identifying information for the contract. This information includes a unique name for the contract, a short description, and a time period for which the contract is valid.
- Contract participants are the organizations that take part in the contract. There is a buyer organization, a seller organization, and contacts at both organizations.
- When you specify an organization as a buyer participant, any user who is a member of that organization is entitled to the contract. Your direct parent organization does not have to be the buyer participant. In addition, if there are child organizations under the organization you have chosen, you do not have to explicitly select child organizations; the child organizations will be entitled to the contract and be participants of it.
- Contracts cannot be entitled to a customer segment or an implicit group based on dynamic conditions. Only customer groups that have explicit members listed can be specified as a customer group in a contract. With a B2B contract, you know precisely which members of an organization or members of a group are entitled to the contract. Therefore, contracts can be entitled to an explicit member group; that is, a member group where individual members are directly assigned to the group.
- Terms and conditions
- Contract terms and conditions are the rules that cover the actual implementation of the contract. Contract terms and conditions cover such information as product pricing, returns and refunds, payment, shipping, billing, and order approval.
- Contract attachments cover any information not covered by the previous elements such as file attachments that provide additional information about the contract and any general remarks about the contract. WebSphere Commerce stores Universal Resource Identifiers (URIs) for contract attachments, not the actual attachments.
- A contract can refer to another contract to share its terms and conditions. For example, contract A can refer to contract B. Thus, a buyer who is entitled to contract A will be entitled to all the terms and conditions from contract A, as well as to all the terms and conditions in contract B.
Contracts managed within the WebSphere Commerce Accelerator must be associated with a business account. Base contracts are associated with a base contracts account, and customer contracts are associated with the customer's business account. Some contracts may not be associated with an account, such as the store default contract.
Different items in a single order may be purchased under different contracts. Buyers can select the contract they shop under at either the start of the shopping flow or when they add an item to their order, depending on the store design. When purchasing items under different contracts the following rules apply:
- Contracts for all items in an order must share at least one payment method. If the contract for an item does not share a payment method, the buyer cannot add that item to the order. Only the payment methods shared by all items in an order can be used to pay for the order.
- All items in an order must come from contracts belonging to the same business account or the store default contract.
A contract's lifetime may include numerous states, and fully supports an approval flow, if that process is required.
Business policies are sets of rules followed by a store or group of stores that define business processes, industry practices, and the scope and characteristics of a store's or group of stores' offerings. They are the central source and reference template for all allowed and supported practices within a store or group of stores.
In WebSphere Commerce, business policies are enforced with a combination of one or more business policy commands that implement the rules of the business policy. Each business policy command is a Java class. A business policy command can be shared by multiple business policies. The behavior of the business policy command is determined by the parameters passed to the command.
Parameters affecting the function of a business policy command can be introduced in three places:
- the contract term and condition referencing the business policy
- the business policy definition
- the business policy command which enforces the policy
The following categories of business policies are provided in WebSphere Commerce:
- Catalog business policies
- Catalog business policies define the scope and characteristics of the catalog of products for sale in a store including prices and the categorization of products in a store's catalog.
- Payment business policies
- Invoicing, payment, and refund business policies define how a store accepts payments, pays refunds, and the format of a store's invoices.
- Returns business policies
- Returns business policies define if refunds are accepted, the time period they are accepted for, and any re-stocking fees applied to returns.
- Ship business policies
- Ship business policies define the shipping providers a store can use and the charges associated with each type.
- Referral interface business policies
- Referral interface business policies define the relationship between a proxy store and a remote store.
Many contract terms and conditions reference business policies. This provides a measure of control over the nature of contracts a store enters into while still providing flexibility in creating the contract terms and conditions.
- Business relationship model
The key elements in the business relationship model include the different kinds of contracts, the various buying units, and the distinct customers who have access to the site. These elements will be discussed further from different scenarios to explain their role in each.
- 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.
- Manage business accounts: an overview
Managing a business account involves tasks that create and modify business accounts. The various tasks involved in managing a business account are performed by different roles.
- Create distributor relationships: an overview
WebSphere Commerce provides the ability for the store to pass requests for quotes and orders from resellers to the proxy stores or distributors. These abilities and the terms and conditions applied to these abilities are defined in a service agreement. Creating and managing distributor service agreements is the basis of distributor relationships in WebSphere Commerce.
- Create reseller relationships: an overview
If you are an administrator for a reseller hub, WebSphere Commerce provides the ability for you to host stores for the resellers. Creating and managing these hosted stores is the basis of reseller relationships in WebSphere Commerce. (Note that resellers can use the Store Creation wizard to create stores. They will likely access the wizard from a link offered on the site.)
- Catalog filtering
You can access the Catalog Filter from within the WebSphere Commerce Accelerator. You can filter the catalog to a specific set of users and exclude any products in the master catalog that you do not want to sell at the store. Use the Catalog Filter on B2B contracts and hosting contracts.
- Tutorial: Creating contracts to reference base entitlement contracts
In this tutorial, we will learn how to create several contracts. You will create base contracts, then create other contracts to reference to those base contracts. For example, you might have a requirement where several different organizations may share the same entitlement to a product set. In this instance, you could create several organizational units that can reference a base contract that contains the shared attributes for that contract, specifically in this case, entitlement attributes.