Contract and account assets
A package of Contracts and Accounts. In WebSphere Commerce, a contract is an agreement that represents the terms and conditions that apply to a transaction. An account is a relationship between the merchant and the financial institution that processes transactions for that merchant. Contracts and Accounts are not particular to any store. Each store can use Contracts and Accounts, and thus the store object is shown as dependent on the Contracts and Accounts package. 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 time under specific conditions. When a customer browses a catalog, customers view products that are covered by the contracts they are entitled to within the store.If we want customers who do not have any contract with the store (for example, guest shopper who shop at the store) to be able to shop in the store, or if we want customers to be able to purchase products that are not covered by their contracts, the 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)
- Store and store entity
- Contract
- Profile
- Participants
- Terms and conditions
- Attachments
- Reference
- Trading agreement and trading agreement type
- Business accounts
- Contracts
- RFQs
- Participant
- Participant role
- Terms and conditions
- Address book
- Fulfillment center
- Order approval
- Payment method*
- Pricing terms and conditions
- Customized price list
- Entire catalog with adjustment
- Price list with adjustment *
- Price list with selective adjustment *
- Catalog with filtering *
- Component price building block *
- Product constraint terms and conditions
- Customized product set exclusion
- Customized product set inclusion
- Product set exclusion*
- Product set inclusion*
- Returns terms and conditions
- Refund payment method*
- Return charge*
- Right to buy amount
- Shipping terms and conditions
- Shipping mode*
- Ship-to address
- Shipping charge type*
- 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 *
- Referral Interface *
- Terms and conditions type
- Terms and conditions sub type
- Business policy and policy command
- Policy type
- Catalog business policies
- Payment business policies
- Returns business policies
- Shipping business policies
- Referral interface business policies
- Policy type command interface
- Attachment and attachment usage
- http://www.mycompany.com/information/document1.txt
- file:///home/joeuser/mydocs/document1
- ftp://ftp.mycompany.com/information/attachment.txt
- Order item
- 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.
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. 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 associated with the account.
- 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.
- 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 create the store. A
deployed contract is associated with one business account. A default contract defines the default
behavior of the store for buyers who do not have any other contracts with the 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:
- 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.
- 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.
- 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.
- 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.
- 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:
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 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 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.
- 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.
- 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 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 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 (*)).
- 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.
- 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.
- This term specifies whether orders must be approved by the customer organization before the order can be filled. We 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.
- 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 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:
- 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.
- This term and condition is deprecated; instead, use Catalog with filtering *.
- 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.
- 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.
- 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.
- This term defines price adjustments that are only available or applicable to items purchased
within a dynamic kit. That is, we can assign a price markdown, or markup, or even a different price
if a particular item is included within a kit. Similarly, we can assign different prices to a
single item that depends on the kit in which it is included.
- 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 price terms
and conditions are available for sale under the contract. The following product constraint terms and
conditions are available in WebSphere Commerce:
- This term states the items in a customized product set are not for sale in a contract.
- This term states that items in a customized product set are for sale in a contract.
- This term states the items in a product set business policy are not for sale in a contract.
- 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 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:
- 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 cannot be specified whether returns are not allowed under the contract.
- 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.
- 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 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:
- 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.
- This optional term specifies where products purchased under a contract are shipped. By
specifying this term and condition, we 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.
- This term defines who pays for shipping orders. The following types of shipping charges are supported:
- 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.
- 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 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.
- 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 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 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.
- 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 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.
- Invoicing, payment, and refund business policies define how a store accepts payments, pays
refunds, and the format of a store invoice.
- 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 define the shipping providers a store can use and the charges associated with each type.
- Referral interface business policies define the relationship between a proxy store and a remote
store.
- 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.
- 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:
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.
- 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:
Related concepts
Store data information model