WebSphere Commerce search and the B2B direct business model

Prices in WebSphere Commerce search

Indexed prices are populated quickly, but not evaluated dynamically. To ensure that the storefront displays accurate prices, you can change the price mode to suit your business needs. For more information, see Changing price modes between WebSphere Commerce search versions.

When working with prices and currencies in WebSphere Commerce search, a separate index column is used by default to handle multiple currencies.

Typical B2B flows

A typical business-to-business storefront navigation shopping flow involves scenarios such as unique pricing, catalog filtering, ordering on a customer's behalf, and multiple contract selections. Sellers, Sales Managers, and Account Representatives can use either the Management Center or Accelerator to implement pricing strategies that meet the site's business needs over time, and to filter their catalog for product and price entitlement.

WebSphere Commerce search can be used to enhance the storefront keyword search and browsing experience to satisfy most of the business-to-business requirements using catalog filters. You can use the Catalog Filter and Pricing tool to filter your catalog to a specific set of catalog entries by specifying which categories, catalog entries, attribute dictionary attributes, and catalog entry properties to include or exclude from the catalog filter. Use catalog filters for your product entitlement, that is, to entitle customers to a subset of your catalog.

For more information, see Using catalog filters.

Contract price indexing and facets

WebSphere Commerce search builds calculated prices into the search index, so that the Aurora B2B starter store can use the indexed price mode to support contract-based pricing based on calculated prices.

This results in displaying storefront facet values based on the selected contract. Asset stores can either share prices, or use different prices for Extended Sites based on the selected pricing model.

Configurable price fields

Changing price modes between WebSphere Commerce search versions

Prioritized price mode settings in starter stores

Different starter stores can use different price modes in WebSphere Commerce search, instead of relying on the values in the preceding configuration files.

Indexing prices

Calculating prices

Prices can be calculated either fully, or for a specified catalog entry, contract, or currency. When full price recalculations are used, all prior price data is removed from the index before the B2B contract prices are recalculated.

Full price recalculations logic

• Recalculating prices uses current and future store contracts that share the master catalog.
• Only the supported currencies for all active stores that are identified in the master catalog are respected, while others are ignored and not indexed. This is because the prices are recalculated on behalf of the site administrator, and therefore cannot calculate any customer segment-level pricing.
• Price calculations are only based on the quantities that are the following amounts: A numeric amount of 1, or a unit of C62. Any step-level pricing, that is, quantity-based pricing, is skipped.

Recalculations logic

• Contract IDs are not validated when passed in as a separate parameter, so that future contracts show the correct prices when you preview a future date in store preview.
• All expired and suspended contracts are safe to remove from the TI_CNTRPRICE temporary table for the specified catalog entry or contract that is specified in the utility 's parameters. That is, the purge list is only limited to the specified catalog entry or contract. For example, if you specify an expired contract, all catalog entries that are covered by that contract are purged. However, if you specify a catalog entry, all expired contracts are purged only for the specified catalog entry.
• If a contract is suspended and inactive, the contract price is removed. If a business user resumes the contract and it becomes active again, the price is not shown in the storefront until the price is calculated again for the resumed contract.
• When an invalid product, contract or currency is passed in, the logic ignores, and therefore does not index invalid values.
• If a contract passed in is expired or suspended, it is deleted and purged from the calculation result. Otherwise, if a contract that will be active at a future date is passed in, it is indexed. That is, even though it is not currently active at the time of the price recalculation.
• The storeId and currency parameters cannot be specified with any other parameters.

Customization logic

Active and future contract prices are built into the catalog entry index using field definitions that start with price_, followed by a combination of contract and currency. For example, price_USD_10001 or price_CNY_10002. In contrast, for releases without indexed contract prices, the catalog entry index uses field definitions that start with price_, followed only by its currency.

In extended sites, the catalog asset store defines the price in the master catalog so that extended sites share the catalog asset store's prices. Or, the extended site can override the prices so that it contains the extended site-specific prices. Different extended sites can create specific items with specific price. When prices are calculated, the store-specific items are calculated first, then the shard items are calculated. Shared items are each calculated per store by their specific contract and currency. The price API gets the correct price, based on the specified contract, price rule, price model, or contract terms and conditions. Different extended sites can define different prices by using different contract. When a shopper logs on to a different extended site store, different contracts are resolved. Then, the shopper sees the relevant prices in the store, even for the same product in the master catalog.

Multiple price columns are set up in the catalog entry index. When a buyer logs on to the storefront, the eligible buyer contract is retrieved. If there are multiple eligible contracts, the buyer can select a contract to set for the session. Then, the corresponding price column that is related to the contract in session is displayed in the storefront. To customize this behavior, the ContractPriceCalculate URL uses ContractPriceCalculateCmd as the overall entry command. The logic can be overridden by a registering a new command implementation in the command registry table. If you want to introduce different calculation logic, override the calculateStoreSpecificItemPrice and calculateSharedItemPrice methods in the ContractPriceCalculateCmd command.

<cmdreg storeent_id="0" interfacename="com.ibm.commerce.price.commands.GetContractUnitPriceCmd+IBM_Admin_CalculatePriceIndex" 
classname="com.ibm.commerce.price.commands.CompositeGetContractUnitPriceCmdImpl" target="Local"/>

<cmdreg storeent_id="0" interfacename="com.ibm.commerce.price.commands.GetContractUnitPriceCmd+IBM_Admin_CalculatePriceIndex" 
classname="com.ibm.commerce.price.commands.PriceRuleGetContractUnitPriceCmdImpl" target="Local"/>

If your store uses the external price model, you can register your own price command to get your intended price result.

Workspace preview