Indexing contract prices in HCL Commerce Search
Prices in HCL Commerce Search
- Offer prices, or default contract prices, are indexed directly from the default contract of the owning store.
- List prices are indexed directly from the LISTPRICE or OFFER database tables, depending on the price source.
- Contract prices are calculated based on the selected contract. They are then indexed in HCL Commerce Search either the Catalog Entry index or the Price extension index, depending on the number of contracts your site contains, or the source of the price data.
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.
When you work with prices and currencies in HCL Commerce Search, a separate index column is used by default to handle multiple currencies.
Indexing prices
- In the Catalog Entry index, when your site contains less than 1000 contracts and price data is
contained within HCL Commerce. You can calculate and index prices by using the Build Index
RESTful call. For more information, see Building the HCL Commerce Search index
The Calculate Price RESTful call updates the information in the price index on demand based on the pricing model your store uses. For more information, see Build contract price as embedded in the CatalogEntry index.
The ContractPriceCalculate job command is used for calculating prices on a schedule for all catalog entries that belong to a specific master catalog. The catalog entry price is calculated against all contracts that belong to the store. For more information, see Creating and scheduling the ContractPriceCalculate job.
- In the Price extension index, when your site contains more than 1000 contracts, or if you use an external source to populate prices. Prices are indexed by using Index Load, as it can populate a large amount of data into a separate extension index faster than the Catalog Entry index can index price data. For more information, see Index Load.
- When indexing contract prices, ensure that the value of
wc.search.priceMode.compatiblePriceIndex is set to
1.0 in the STORECONF table:
insert into storeconf(storeent_id,name,value) values('storeent_id', 'wc.search.priceMode.compatiblePriceIndex', '1.0');
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.
- Dedicated server or environment
- Allocate a dedicated server or instance to calculate prices.
- Live environment on Repeater
- You can calculate and the build price index on a repeater. Then, prices and other data within the catalog entry and catalog group index are replicated to the search subordinates.
- Authoring environment on Master
- Calculate prices on an HCL Commerce node on an authoring/master.
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 restriction exists because the prices are recalculated on behalf of the site administrator, and therefore cannot calculate any customer segment-level pricing.
- By default price calculations are either based on some unit of measure (kilos, crates, lots)
that has a base numeric quantity of 1, or on a unit of C62. C62 is used to signify items that are
not counted according to a separate unit of measure. For instance, shirts are not typically measured
in kilos, but by quantity. Their unit of measure can be set as C62. One limitation of this approach
is that any step-level pricing, that is, quantity-based pricing, is skipped.Tip: You can work around this limitation by explicitly defined C62 as having a value of 1, then defining a unit based upon C62 that can be multiplied. For instance, the following SQL query creates a new unit, CS, based on C62, that can be multiplied to enable to step-level or quantity-based pricing.
INSERT INTO QTYCONVERT VALUE('CS',1,'C62',1,'M','N',0);
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 by 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.
Name | Type | Description |
---|---|---|
CATENTRY_ID | BIGINT NOT NULL | The ID of the catalog entry. This column contains all catalog entry for the specified master catalog. |
PRICE | CLOB | Multiple value pairs for different contracts and currency values that are separated with white space. |
- SolrRESTSearchCatalogEntryViewPriceQueryPostprocessor
- SolrRESTSearchByPriceExpressionProvider
- SolrSearchResultFieldQueryPreprocessor
- SolrSearchFacetQueryPreprocessor
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. 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 multiple eligible contracts exist, 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
- B2B prices that are shown in store preview are only from approved content.
- Future prices can be previewed if the appropriate future contract is indexed. The future date is respected in the preview context and shows the correct contract for viewing.
- Prices cannot be associated with new non-approved content, such as previewing a non-approved new product that does not belong to any contract.
- When a business user changes the standard offer price on CMC, they want to preview such changes in the workspace store preview. If contract price index is enabled, without recalculation, such changes cannot be previewed. You must run the indexing service manually or by the schedule indexing service, or calculate a price job to capture the changed prices. This operation allows affected products to pick up the new prices changes.