Store data information model diagram description
This diagram illustrates the data assets of a WebSphere Commerce store.
- Stores
- A package of stores. This asset is shown in the center of the diagram. In WebSphere Commerce an online store is the place where all transactions for your online business occur. WebSphere Commerce supports several different types of entities that are defined as stores. These store types include customer-facing store, asset store, and proxy store.
- Prices
- A package of prices. Prices are not specific to any particular store. Each store can use Prices, and thus the store object is shown as dependent on the Prices package.
- Catalogs
- A package of catalogs. Catalogs are not specific to any particular store. Each store can use catalogs, and thus the store object is shown as dependent on the catalogs package.
- Site Level Information
- A package of Site Level Information. A site can contain information such as organizations, member attributes, language, roles, and other information that pertains to the site. Site information is not particular to any store. Each store can use Site Level Information, and thus the store object is shown as dependent on the Site Level Information package.
- Business Policies
- A package of Business Policies. A business policy is a set of rules followed by a store or group of stores that define business processes, industry practices, or the scope and characteristics of business offerings. Business Policies are not particular to any store. Each store can use Business Policies, and thus the store object is shown as dependent on the Business Policies package.
- Trading Agreements for RFQs and Auctions
- A package of Trading Agreements. WebSphere Commerce provides a number of trading mechanisms that govern the interactions between buyers and sellers. 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 in a store that governs all auctions in that store. WebSphere Commerce supports several trading agreement types, including account, contract, RFQs, exchange, and auctions. Trading Agreements are specific to a particular Store, and thus the Trading Agreements package is shown as dependent on the Store.
- Contracts and Accounts
- 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 which 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.
- Members
- A package of Members. A member is a person, group, or organization that is known to the system.
A member can be a user, an organization, an organization unit, or a member group. A member can act
as a customer or an administrator, or can own entities.
A member must
first become a member of the marketplace before it can become a user. Members are not
particular to any store. Each store can use Members, and thus the store object is shown as dependent
on the Members package. - Payment
- A Payment package. In WebSphere Commerce Payments, a payment is a request from a merchant of a financial institution to approve all or part of an order. In many cases, all the money that is authorized for collection by an order is collected in a single payment. Some payment systems can allow the money authorized in one order (that is, one set of payment instructions) to be collected in multiple payments. This option is dependent on the business model. Payments are not particular to any store. Each store can use Payments, and thus the store object is shown as dependent on the Payments package.
- Fulfillment
- A Fulfillment package. In WebSphere Commerce, fulfillment is the process of filling an order for a client. A fulfillment center serves as a storage warehouse where products are packaged and shipped to customers. Fulfillment centers, stores, and shipping carriers are treated as separate entities. Fulfillment is not particular to any store. Each store can use Fulfillment, and thus the store object is shown as dependent on the Fulfillment package.
- Vendors
- A Vendors package. A vendor represents a source for merchandise that is received at a fulfillment center, or expected to be received at a fulfillment center. Vendors are not particular to any store. Each store can work with vendors, and thus the store object is shown as dependent on the Vendor package.
- Inventory
- An Inventory package. In WebSphere Commerce, inventory is the products at a fulfillment center. Inventory is specific to a particular Store, and thus the Inventory package is shown as dependent on the Store package.
- Orders
- An Orders package. One or more items, products, prebuilt kits, bundles, or SKUs, or a combination thereof, selected for purchase. An order contains quantities, prices, shipping information, and tax and shipping charges, which are compiled and displayed to customers after they initiate the ordering process. Depending on the store policy, orders can be returned, if customers are unhappy with their purchase. Orders are specific to a particular Store, and thus the Orders package is shown as dependent on the Store package.
- Jurisdictions
- A Jurisdictions package. A jurisdiction is a geographical region for tax or shipping purposes. A jurisdiction represents a country or region, province or territory, postal code range, or an application-specific geo-code. In WebSphere Commerce, a geo-code is an application-specific code that represents a geographical region. Jurisdictions are specific to a particular Store, and thus the Jurisdictions package is shown as dependent on the Store.
- Taxes
- A Taxes package. Taxes are specific to a particular Store and its location, and thus the Taxes package is shown as dependent on the Store.
- Customer Segments and Collaboration
- A Customer Segments and Collaboration package. Customer Segments are specific to a particular Store, and thus the Customer Segments package is shown as dependent on the Store.
- Experiments
- An Experiments package. Experimentation enables Marketing Managers to run alternative web activities concurrently with existing activities. Experiments are similar to web activities, in that they deliver an alternative marketing message. Experiments are specific to a particular Store, and thus the Experiments package is shown as dependent on the Store.
- Email Activities
- An email Activities package. Email activities provide Marketing Managers with a method by which they can perform direct marketing to customers with email. Email activities are specific to a particular Store, and thus the email Activities package is shown as dependent on the Store.
- Campaigns
- A Campaigns package. A campaign is a planned series of operations that include advertisements and suggestive selling techniques that are pursued to achieve a defined set of business objectives. Campaigns are specific to a particular Store, and thus the Campaigns package is shown as dependent on the Store.
- Coupons
- A Coupons package. Coupons are specific to a particular Store, and thus the Coupons package is shown as dependent on the Store.
- Promotions
- A Promotions package. Promotions are specific to a particular Store, and thus the Promotions package is shown as dependent on the Store.
- Shipping
- A Shipping package. Shipping is specific to a particular Store, and thus the Shipping package is shown as dependent on the Store.
- Store Relationships
- A Store Relationships package. A store relationship (captured in the STOREREL table) is the relationship between two stores. All store relationships are directional, that is in each store relationship one store provides the services and the second store in the relationship uses those services. For example, store A uses the catalogs that are provided by store B. Store relationships are specific to a particular Store, and thus the Store Relationships package is shown as dependent on the Store.
- Supported Currencies
- A Supported Currencies package. A supported currency is a currency that an online store can display and handle. Supported currencies are specific to a particular Store, and thus the Supported Currencies package is shown as dependent on the Store.
- Supported Languages
- A Supported Languages package. Supported languages are specific to a particular Store, and thus the Supported Languages package is shown as dependent on the Store.
- Supported Units of Measure
- A Supported Units of Measure package. Supported units of measure are specific to a particular Store, and thus the Supported Units of Measure package is shown as dependent on the Store.
- Command Registry Entries
- A Command Registry Entries package. Every command, whether it is a controller or task command, can be defined in the command registry. A command that is being executed is specific to an execution request by a particular Store. The Command Registry Entries package is shown as dependent on the Store.
- View Registry Entries
- A View Registry Entries package. The URL registry entries are not database assets, but presentation configuration (that is, struts actions and forwards) that need to be deployed. View registry entries are shown in the diagram to illustrate the entire store data information model. After a command is executed, in most cases, the requester of the command requires a response to be returned. Every view that returns a response must be defined in the view registry, either per store, or by default, by site. Each store defines the view for each possible device format of the incoming request. A view command that is being executed is specific to an execution request by a particular Store. The View Registry Entries package is shown as dependent on the Store.
- URL Registry Entries
- A URL Registry Entries package. A URL Registry Entries package. The URL registry entries are not database assets, but presentation configuration (that is, struts actions and forwards) that need to be deployed. URL registry entries are shown in the diagram to illustrate the entire store data information model. The URL registry maps a command name to the actual interface of the command to be executed. Each URL registry entry is store sensitive, that is, each store can define a different interface for the same URL value. Since each URL registry entry is store sensitive, the URL Registry Entries package is shown as dependent on the Store.