Contract and account assets
In WebSphere Commerce, all customers must shop under a contract. A contract allows customers to purchase products from a store at a specified price for a specified period of time under specific conditions. When browsing a store's catalog, customers will only see products covered by the contracts they are entitled to within the store.
If you want customers who do not have any contract with your store (for example, guest customers who shop at the store) to be able to shop in the store, or if you want customers to be able to purchase products not covered by their contracts, your store will require a default contract. WebSphere Commerce Professional Edition and WebSphere Commerce - Express support only the store default contract. Contracts other than the store default contract are supported only by WebSphere Commerce Enterprise.
To allow all customers to shop at a store, a store created with WebSphere Commerce must include the following:
- 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:
relationships." usemap="#FPMap0"/>D
- 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 related to the relationship between buyer and seller such as: invoice customization, purchase order verification, or maintaining a buyer's 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 is the store default contract which cannot be associated with a business account. A business account can have many contracts associated with the account.
- Store and store entity
- A WebSphere Commerce online store is consists ofa set of HTML and JavaServer Pages files, as well as 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 populated into the WebSphere Commerce database to allow a store to function.
- Contract
- There are two types of active contracts associated with stores: deployed contracts and default contracts. Deployed contracts entitle specific buyer organizations or individual buyers and can be created using the WebSphere Commerce Accelerator after you have created 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 only be created using XML and only one default contract may 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 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.
- Reference
- 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.
- Trading agreement and trading agreement type
- A contract is a type of trading agreement. WebSphere Commerce provides a number of trading mechanisms governing the interactions between buyers and sellers. The following trading mechanisms are supported by different editions of WebSphere Commerce:
- Auctions
Business accounts- Contracts
RFQs
All of these trading mechanisms have common properties. For example, all trading mechanisms have participants and they all have rules governing the behavior of the trading mechanism. The rules governing 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. There is a single trading agreement that governs all auctions in WebSphere Commerce.
A trading agreement consists of a profile stored in the TRADING table; participants stored in the PARTICIPNT table; terms and conditions stored in the TERMCOND table; and optional attachments 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 through the TRDATTACH table. Note that attachments are not supported for RFQs.
In addition to the general trading agreement, each type of trading agreement stores additional 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 may 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 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's operation are defined by business policies. Terms and conditions provide parameters for the business polices they reference. Providing parameters to the business policies allows you 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 allows you to specify the address books from which the customer can choose the shipping and billing addresses for an order. When completing the checkout process for an order, the customer can select an address from the following address books: their personal address book, their parent organization's address book, or their business account organization's address book.
- Fulfillment center
- This optional term allows you 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 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 if orders must be approved by the customer organization before filling the orders. You can specify an optional amount, that includes taxes and shipping, that would allow 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 specifying 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 will be accepted for orders made under the contract. The payment method could 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 accepted by the store will be accepted for orders 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 will pay 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 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. If no adjustment is specified, items are sold at the base price.
- 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 may 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 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 will behave as a product set business policy. Item product sets will be customized products sets.
- Component price building block *
- This term defines price adjustments which 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 completely different price if a particular item is included within a kit. Similarly, you can assign different prices to a single item depending 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 specified in the contract's 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 could not 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 can not be created. If returns terms and conditions are specified they should only be one set that 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 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 may not be specified if returns are not allowed under the contract.
- Return charge*
- This term specifies how returns are automatically approved and any deductions from the refund 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 made under the contract must be less or equal to a specified amount. If this limit is exceeded when placing an order, payment authorization for the order will fail.
- Shipping terms and conditions
- Shipping terms and conditions specify how orders will be shipped, where they will be shipped to and who will pay 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. Specifying this term and condition allows you to 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 an order is made under a contract. If this term is specified, the buyer cannot specify a new ship-to address when placing an order, but 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 specifies 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 supported by the remote store and the parameters to be used in messages sent to the remote store.
- Terms and conditions type
- Terms and conditions define the behavior and properties of a trading agreement. WebSphere Commerce supports severalterms 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'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, 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 may provide parameters for the business polices they reference. This allows the behavior of the business policy to be modified depending on the term and condition referencing the business policy.
Business policies are a sharable resource. When you list business policies that can be used in a contract, the business policies listed are the ones owned by the store in which the contract is being created, and the business policies 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 into 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 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.
- Shipping business policies
- Shipping 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.
- 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 additional 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 the following:
- 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 may 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 purchasing 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 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 belonging to the same business account or the store default contract.