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