Contract and account assets

If you want customers who do not have any contract with your store (for example, guest shopper who shop at the store) to be able to shop in the store, or if you want customers to be able to purchase products that are not covered by their contracts, your store requires a default contract. WebSphere Commerce Professional Edition supports only the store default contract. Contracts other than the store default contract are supported only by WebSphere Commerce Enterprise.

Before customers can shop at a store, a store that is created with WebSphere Commerce must include the following assets:

• Business policies
• Default contract

The business policies are referenced by the default contract, thus allowing all customers to shop at a store.

The following diagram illustrates the structure of contracts in WebSphere Commerce:

Account (business account)

A business account is a trading agreement that represents the relationship between a buyer organization and a seller organization. A business account can be used to organize various trading agreements and to specify terms and conditions that are related to the relationship between buyer and seller. For example, invoice customization, purchase order verification, or maintaining a buyer line of credit with the seller.

Contracts are associated with business accounts since they represent an agreement between a buyer and a seller. The exception to this association is the store default contract, which cannot be associated with a business account. A business account can have many contracts that are associated with the account.

Store and store entity

A WebSphere Commerce online store consists of a set of HTML and JavaServer Pages files; tax, shipping, payment, catalog, and other database assets, which are contained in a store archive. A store also contains store data, which is the information that is populated into the WebSphere Commerce database to allow a store to function.

Contract

There are two types of active contracts that are associated with stores: deployed contracts and default contracts. Deployed contracts entitle specific buyer organizations or individual buyers and can be created by using the WebSphere Commerce Accelerator after you create your store. A deployed contract is associated with one business account. A default contract defines the default behavior of your store for buyers who do not have any other contracts with your store. A default contract can be created by using XML and only one default contract can be defined for a store.

A typical contract consists of the following elements:

Profile

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.

Participants

Contract participants are the organizations that take part in the contract. There is a buyer organization, a seller organization, and contacts at both organizations.

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, and order approval.

Attachments

Contract attachments cover any information that is not covered by the previous elements, such as file attachments that provide more 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.

Reference

A contract can refer to another contract to share its terms and conditions. For example, contract A can refer to contract B. A buyer who is entitled to contract A is entitled to all the terms and conditions from contract A, and to all the terms and conditions in contract B.

Trading agreement and trading agreement type

A contract is a type of trading agreement. WebSphere Commerce provides a number of trading mechanisms that govern the interactions between buyers and sellers. The following trading mechanisms are supported by different editions of WebSphere Commerce:

• Business accounts
• Contracts
• RFQs

All of these trading mechanisms have common properties. For example, all trading mechanisms have participants and they all have rules that govern the behavior of the trading mechanism. The rules that govern the behavior of trading mechanisms are known as terms and conditions in WebSphere Commerce.

A trading agreement represents an instance of a trading mechanism and records the properties of that instance of a trading mechanism. Each contract, business account, and RFQ in WebSphere Commerce is represented by a trading agreement.

A trading agreement consists of a profile that is stored in the TRADING table; participants that are stored in the PARTICIPNT table; terms and conditions that are stored in the TERMCOND table; and optional attachments that are stored as Universal Resource Identifiers (URIs) in the ATTACHMENT table. Because a trading agreement can have multiple attachments, attachments are related to the trading agreement by using the TRDATTACH table. Attachments are not supported for RFQs.

In addition to the general trading agreement, each type of trading agreement stores more information specific to the type of trading agreement in its own table: CONTRACT stores contract-specific information; RFQ stores RFQ-specific information; and ACCOUNT stores business account-specific information.

Participant

Contract participants take on specific roles within each contract. Participants can be a contact from a buyer organization and from a seller organization. If a contract specifies the buyer participant to be null, then all users, including guests, are entitled to the contract. Any contract can specify a null buyer participant.

Participant role

Participants in trading agreements take on specific roles within each trading agreement. WebSphere Commerce supports several participant roles, including creator, seller, buyer, supplier, approver, administrator, distributor, service provider, reseller, host, and recipient. Participant roles are defined in the PARTROLE table.

Terms and conditions

Terms and conditions define the behavior and properties of a trading agreement. For contracts, the terms and conditions define how a contract is implemented for a buyer organization. They define what is being sold under the contract; the price of the items that are being sold; how the items are shipped; how orders are paid for; how returns are handled; how orders are approved; and from where orders are shipped.

Some terms and conditions reference business policies because many aspects of a store operation are defined by business policies. Terms and conditions provide parameters for the business policies they reference. Providing parameters to the business policies provide you the ability to modify the behavior of business policies for each contract. WebSphere Commerce supports the following terms and conditions (terms and conditions that reference business policies are indicated with an asterisk (*)).

Address book

This term provides you the ability to specify the address books from which the customer can select the shipping and billing addresses for an order. When you complete the checkout process for an order, the customer can select an address from the following address books: their personal address book, their parent organization address book, or their business account organization address book.

Fulfillment center

This optional term provides you the ability to specify the list of fulfillment centers from which orders placed under the contract must be filled. This list must be a subset of the fulfillment centers that are defined for the store. Fulfillment center precedence is defined by the store and cannot be overridden by the terms and conditions of a contract.

Order approval

This term specifies whether orders must be approved by the customer organization before the order can be filled. You can specify an optional amount that includes taxes and shipping. This amount allows orders with a value below the amount to be filled without approval from the customer organization. If an order total is over this amount, approval is required. If a buyer is placing an order with order items under multiple contracts and one item in the order has a contract that specifies this term, the entire order is subject to the order approval term that applies to the item.

Payment method*

This optional term specifies the payment methods that are accepted for orders that are made under the contract. The payment method might be as general as a payment type, such as a credit card type, or as specific as a credit card number to be used for payment. If no payment method term is specified in a contract, payment in all methods that are accepted by the store is accepted for orders that are made under the contract.

Pricing terms and conditions

Pricing terms and conditions define what products are available under a contract and what prices the customer pays for the products. At least one pricing term is required in a contract. The following pricing terms and conditions are available in WebSphere Commerce:

Customized price list

This term specifies that both the list of products for sale and their prices are customized for sale in a contract and their price is customized. Items are not limited to a section of the store catalog they can be from anywhere in the store catalog.

Entire catalog with adjustment

This term and condition is deprecated; instead, use Catalog with filtering *.

Price list with adjustment *

This term offers all of the products available in a price list for sale with a percentage adjustment (mark-up or discount) from the base price as defined in the store catalog. If no adjustment is specified, items are sold at the base price.

Price list with selective adjustment *

This term is similar to price list with adjustment, except the adjustment is not applied to the entire price list. The adjustment is made on a subset of the price list. The subset of the price list can either be a product set business policy or a customized product set.

Catalog with filtering *

This term offers all of the products available in a store catalog for sale with a percentage adjustment (mark-up or discount) from the base price as defined in the store catalog. This term also offers all of the products available in a category, or a list of specify products and items, for sale with a percentage adjustment (mark-up or discount) from the base price as defined in the price list that is referenced by this term. This term can also state which categories, products, and items are for sale or are not for sale in a contract. Category product sets behave as a product set business policy. Item product sets are customized products sets.

Component price building block *

This term defines price adjustments that are only available or applicable to items purchased within a dynamic kit. That is, you can assign a price markdown, or markup, or even a different price if a particular item is included within a kit. Similarly, you can assign different prices to a single item that depends on the kit in which it is included.

Product constraint terms and conditions

Product constraint terms and conditions control what products are included or excluded for sale under a contract. Product constraint terms are optional. If no product constraint terms and conditions are specified in a contract, all products that are specified in the contract price terms and conditions are available for sale under the contract. The following product constraint terms and conditions are available in WebSphere Commerce:

Customized product set exclusion

This term states the items in a customized product set are not for sale in a contract.

Customized product set inclusion

This term states that items in a customized product set are for sale in a contract.

Product set exclusion*

This term states the items in a product set business policy are not for sale in a contract.

Product set inclusion*

This term states that items in a product set business policy are for sale in a contract.

Exclusion terms have precedence over inclusion terms. This means that if a product appears both an inclusion term and an exclusion term in the contract, the product cannot be purchased under the contract.

Returns terms and conditions

Returns terms and conditions specify how returns are handled under this contract. If no returns terms and conditions are specified, then returns cannot be created. If returns terms and conditions are specified, only one set applies to the entire contract. The following returns terms and conditions are available in WebSphere Commerce:

Refund payment method*

This term specifies the payment method that is used to pay refunds to a customer. If a return charge term is specified, at least one refund payment method term must be specified as well. This term cannot be specified whether returns are not allowed under the contract.

Return charge*

This term specifies how returns are automatically approved and any deductions from the refund that is made for handling the return, for example, restocking charges.

Right to buy amount

This term places a limit on the combined value of all orders, including taxes and shipping, placed under a contract. The value of all orders that are made under the contract must be less or equal to a specified amount. If this limit is exceeded when you place an order, payment authorization for the order fails.

Shipping terms and conditions

Shipping terms and conditions specify how orders are shipped, where they are shipped to and who pays for the shipping. The following shipping terms and conditions are available in WebSphere Commerce:

Shipping mode*

This optional term defines how orders created under a contract are shipped. If this term is not specified in a contract, orders can be shipped by any mode available in a store. A shipping mode is also known as a shipping provider. A shipping provider is the combination of a shipping carrier and its shipping service. For example, XYZ Courier, Overnight is a shipping provider.

Ship-to address

This optional term specifies where products purchased under a contract are shipped. By specifying this term and condition, you can limit the locations where orders can be shipped. If the ship-to address term and condition is not specified, a ship-to address must be specified each time that an order is made under a contract. If this term is specified, the buyer cannot specify a new ship-to address when the buyer places an order. The buyer must select a ship-to address from a list of ship-to addresses.

Shipping charge type*

This term defines who pays for shipping orders. The following types of shipping charges are supported:

• Shipping charges are paid by the buyer to the seller. The seller calculates the shipping charges when the order is captured and the shipping costs become part of the order total.
• Shipping charges are paid by the buyer to the shipping carrier. The carrier calculates the shipping cost and assumes the responsibility of collecting payment from the buyer. Shipping costs are not calculated when the order is captured.

Shipping charge adjustment *

This term contains specific shipping discounts for the contract. These discounts specify an adjustment type (percent off or fixed cost), applicable shipping method, the adjustment amount, and the adjustment description.

Referral Interface *

This term specifies the relationship between a store and a remote store. It defines the functions that are supported by the remote store and the parameters to be used in messages that are sent to the remote store.

Terms and conditions type

Terms and conditions define the behavior and properties of a trading agreement. WebSphere Commerce supports several terms and conditions types, including pricing, payment, and shipping. Terms and conditions types are defined in the TCTYPE table.

Terms and conditions sub type

Each terms and conditions type can contain several terms and conditions sub types. Terms and conditions sub types are defined in the TCSUBTYPE table.

Business policy and policy command

Business policies are sets of rules followed by a store or group of stores. Business policies define business processes, industry practices, and the scope and characteristics of a store or group of store 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, a reference to a business object that the rules act on, and a set of properties to configure the operation of the business policy commands. Terms and conditions can provide parameters for the business policies they reference. This reference allows the behavior of the business policy to be modified depending on the term and condition that reference the business policy.

Business policies are a shareable resource. When you list business policies that can be used in a contract, the business policies that are listed are the ones that are owned by the store in which the contract is being created, and the business policies that are owned by any store with which there is a com.ibm.commerce.businessPolicy store relationship.

Many contract terms and conditions reference business policies. This provides a measure of control over the nature of contracts a store enters while still providing flexibility in creating the contract terms and conditions.

Policy type

WebSphere Commerce supports several types of business policies. Policy types are defined in the POLICYTYPE table. The following types 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. For example, prices and the categorization of products in a store catalog.

Payment business policies

Invoicing, payment, and refund business policies define how a store accepts payments, pays refunds, and the format of a store invoice.

Returns business policies

Returns business policies define whether refunds are accepted, the time period they are accepted for, and any restocking fees that are applied to returns.

Shipping business policies

Shipping business policies define the shipping providers a store can use and the charges that are associated with each type.

Referral interface business policies

Referral interface business policies define the relationship between a proxy store and a remote store.

Policy type command interface

The policy type command interface is the Java command interface for the business policy object. The command for each policy instance must implement this interface. There can be zero or more commands for each business policy object.

Attachment and attachment usage

An attachment provides addition information about a trading agreement that is not covered by other elements of the trading agreement. An example is a file that provides more information about RFQ requirements and any general remarks about the RFQ. A trading agreement can have multiple attachments. Attachments are stored outside of WebSphere Commerce and the trading agreement stores Universal Resource Identifiers (URIs) to the attachments. Examples of URIs include:

• http://www.mycompany.com/information/document1.txt
• file:///home/joeuser/mydocs/document1
• ftp://ftp.mycompany.com/information/attachment.txt

All attachments can be assigned an attachment usage that indicates what the attachment is for. The attachment usage is an optional property of an attachment.

Order item

An order item is a product or item that is included with an order. Different order items in a single order can be purchased under different contract trading agreements. Buyers can select the contract trading agreement 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 a Buyer purchases items under different contract trading agreements, the following rules apply:

• Contract trading agreements 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 that are shared by all items in an order can be used to pay for the order.
• All items in an order must come from contract trading agreements that belong to the same business account or the store default contract.