Every catalog entry object must have a base price (commonly called a default price) there may be any number of prices associated with a given item.
Example:
- There may be a price for each supported currency.
- There may be a special discounted price for senior citizens or for employees.
- There may be special business customer contracts with terms and conditions (minimum quantity, maximum quantity, shipping restrictions, and so on) that justify special prices.
This following tables includes catalog and offering assets.
- Trading position container (TRADEPOSCN)
- Catalog group trading position relation (CATGRPTPC)
- Offer (OFFER)
- Offer description (OFFERDESC)
- Offer price (OFFERPRICE)
Trading position container (TRADEPOSCN)
A trading position container object organizes, by reference, a group of offers. The reference identifier tradeposcn_id value is used in all the offers in the container.
Typically, a developer begins by creating a single trade position container to contain the base prices for the entire catalog. In this container, the productset_id property is set to NULL and the type property is set to indicate that it represents the standard prices. When special prices need to be offered, the store developer creates additional trading position containers, one for each collection of related prices.
Catalog group trading position relation (CATGRPTPC)
The catalog group trading position relation is used to link a catalog or a catalog group to a trading position. If the catgroup_id property is set to 0, the relation applies to the entire catalog. Otherwise, the relation applies to the specified catalog group.
Offer (OFFER)
The offer object is used as a relation to link a particular catalog entry object and its related prices to a trading position container. It may also contain properties that qualify the applicability of the specified prices. Once a trading position container has been chosen, its reference identifier plus the reference identifier of the catalog entry can be used to find the appropriate offer object.
By convention, every catalog entry, regardless of type, has an offer in the base price list. You could argue that items could inherit their price from the related product, or all the item prices in a bundle could be summed to provide the price for the bundle. However, for convenience and performance while building a view, an invoice, or an order, each catalog entry is given its own offer, even when information appears to be redundant.
Offer description (OFFERDESC)
An offer description object contains language-dependent information about an offer. Although this object is not used in the sample stores, it can be used to add descriptive text about the price for viewing by a shopper. For example, it may say “For a limited time, only”, “While supplies last”, or “Special price because you are
an eligible Senior Citizen”.
an eligible Senior Citizen”.
Note the granularity of these descriptions, one per offer object. In most cases, all the offers in the same trading position container are there for the same reason. To have this information recorded for each offer can be very redundant. You may be tempted to use the description in the trading position container instead, but
that description is not language dependent and is therefore unsuitable for stores that support more than one language.
that description is not language dependent and is therefore unsuitable for stores that support more than one language.
Offer price (OFFERPRICE)
The offer price object links a currency-dependent price to an offer. Once an offer has been chosen, its reference identifier and the desired currency identifier can be used to find the price to be displayed. Optionally, this object may contain a comparison price, in the same currency. When special prices need to be added to the site, additional offer price objects are created for each offer in the new trading position container.
No comments:
Post a Comment