Rules for custom catalogs: Each category exists in one and only one catalog Each category can contain other categories and catalogs Products can belong to multiple categories Catalogs can be linked such that a catalog can contain one or more catalogs Security can be defined on a per catalog basis
Note: A category can belong in multiple categories, as long as all of those categories are in the same catalog. A category can only be directly included in one catalog, but that entire catalog can then be added to other catalogs.
Product asset properties include Name Brand Start and end dates Description and long description Keywords Related products Upsell products Custom attributes
Provide a means to define a set of prices that are applied to products, SKUs or a combination of product and SKUs Allow different price lists to be assigned to different groups of users according to business rules Provide a means of overlaying price lists price not found in current price list can be looked up in base price list, or (as of 9.1) on catalog object Supported means of pricing include price by product id price by SKU id price by product/SKU pairing
1. A pricing operation is requested and the PricingEngine is invoked. 2. PricingEngine constructs a new PriceInfo object, and passes it to pre-calculators which set an initial, undiscounted price in the priceInfo. 3. All discount promotions associated with the user are retrieved from the PricingModelHolder, which contains all promotions specific to the current user (from the Profile), and global promotions available to all users. 4. PricingEngine iterates through the user’s promotions and invokes each promotion’s discount calculator one at a time. 5. Each discount calculator uses the Qualifier service to check if the object being priced qualifies for the promotion associated with that calculator. If so, the price is discounted, and qualified objects are marked as having been used. 6. PricingEngine sends PriceInfo to post-calculators, which may further alter the price. 7. PricingEngine returns modified PriceInfo.
Users can also add new shipping groups by entering addresses in forms provided on the store pages. Registered and anonymous users can both add shipping groups this way. Anonymous users, who have no saved addresses, must add at least one shipping address.
Users can then set which commerce items are to be shipped to which addresses and select a shipping method for each shipping group. If they have ordered more than one of a particular item, they may choose to ship some of that item to one address and some to another.
A similar process is used to create and allocate the order among payment groups. If there are any saved credit cards or store credits (or other custom payment types) in a registered user's profile, they will be loaded into the PaymentGroupContainerService for possible use in this order. Users can also add payment groups as needed, which may be credit cards, gift certificates, store credits, or in the case of B2B sites, purchase orders. Again, similarly to allocating shipping, users may be able to select how much of an order should be paid for by each payment group. Depending on how the application is designed, users may split shipping based on the total order amount (i.e., an order with a total of $400 for all items, tax, and shipping is paid for by a $100 gift certificate and a $300 credit card charge) or based on the individual line items (i.e., the tax, shipping, and cost of SKU123 is paid for by one purchase order, and the total cost of SKU456 is paid for by another). The ability to manually adjust the amount covered by each payment group is not currently exposed in the Commerce Reference Store.
By default, orders from anonymous users are not persisted in the Order Repository until they are submitted. Once an order is submitted, its status changes from INCOMPLETE to SUBMITTED.