Indexing contract prices in HCL Commerce Search

Prices in HCL Commerce Search

Prices that are returned by HCL Commerce Search are either indexed or calculated:

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 and stored in the designated Price index of HCL Commerce Search. This data is later copied back into the Product index to be used with the Query service API for filtering, sorting, and displaying.
Note: This copy operation only takes place when the newly calculated contract price is different from the previously calculated price. The reason is to avoid any unnecessary updates to the Product index.

Indexed prices are populated quickly, but not evaluated dynamically. To ensure that the storefront displays accurate prices, adjust the frequency of the price calculation operation 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

You can calculate and index prices by using the Build Index RESTful call. For more information, see Building the Elasticsearch index.
The Calculate Price RESTful call updates the information in the price index whenever required based on the pricing model your store uses. 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 for all contracts that belong to the store. For more information, see Creating and scheduling the ContractPriceCalculate job .
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. The calculation is performed as a background job on the Transaction server. This task can take a considerable amount of time to finish depending on the number of contracts involved and the size of each price list. Only the status of the price calculation job submission itself is returned initially, not the status of the entire price calculation task.

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 Price index. This is to avoid copying expired contract price data back to the Product index.
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.

Transaction server and NiFi processes

Transaction server

When the Transaction server receives a data import/build command, it launches worker threads to pre-process all contract price data. The command that launches these processes is:
```
POST: https://CommerceServerName:ts-app-port/wcs/resources/admin/index/dataImport/build?connectorId=price&indexSubType=Price&storeId=12
```
```
POST: https://CommerceServerName:ts-app-port/wcs/resources/admin/index/dataImport/build?connectorId=auth.price&indexSubType=Price&storeId=12
```
This command takes two additional parameters.

numWorkers

Controls the number of worker threads to be used for pre-processing contract price calculation.

flushSize

Controls the size of each request body when sending to NiFi.
Once pre-processing is done, the result is stored in the TI_OFFER and TI_OFFERPRICE database tables. At this time all the worker threads are terminated and the main flow streams the result to NiFi, using the flushSize parameter to determine the size of each request payload. The default value of flushSize is 1000.

Each calculated price request (with default size of 1000) is sent to the NiFi Auth.price connector.
Inside this price connector, the flow file is transformed into a bulk request to be sent to the Auth.price Elasticsearch index.
At this time, while the list of catentries is still present in the dataflow, CopyLink uses this list of IDs to determine whether to actually copy to the Product index or not. Only the updated numbers are copied, instead of copying everything over.
- The process waits until the copying is completed before continuing.
- Dataflow with the current run ID ends at the Terminal stage and is disposed of through the Terminal Service, which produces an entry in the Log index in Elasticsearch.
The transaction server receives the dataimport/build command and launches worker threads to pre-process all contract price data.

In addition, you should use the following command to query the status of this Price Cacluation from the Transaction server instead of Search's Ingest endpoint. For example:

https://TSHost:TSPort/wcs/resources/admin/index/dataImport/status?jobStatusId=100

Workspace preview

When you use 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 contract price and wants to preview such changes in the workspace store preview. Without recalculation, such changes cannot be previewed. You must run the contract price recalculation to capture the changed prices into the Price index, which is then copied back to the Product index. This operation allows affected products to pick up the new contract related price changes.