FAQs

24 FAQs

This chapter contains frequently asked questions and their answers.

General Questions

Here are some answers to typical questions of a general nature.

What delimiters are used in the data files?

The inbound data files must be pipe-delimited, while the outbound files are comma-delimited. The delimiters are not configurable.

When are W_RTL_RECLASS_DP_GP_TMP and W_RTL_RECLASS_IT_SC_CL_TMP interfaces used?

These are generally used for implementations that also use RI's data warehouse reporting.

If CREATED_BY_ID and CHANGED_BY_ID columns in every table are set to -1, will it have negative impacts on the functionality?

The value of -1 is the normally expected/used value. The value used will not affect functionality.

CREATED_ON_DT and CHANGED_ON_DT and SRC_EFF_FROM_DT are given values for every table, but since the value is not used functionally, can it be set to a value of NOW?

The only interface where this approach is not appropriate is W_RTL_PROMO_DS. For this interface, the SRC_EFF dates must indicate when the promotion was in effect. (If sales transaction data is not provided, W_RTL_PROMO_DS.dat interface becomes pointless, and therefore defaulting to NOW will be fine everywhere else.)

DT Questions

Here are some answers to typical questions related to demand transference.

Demand transference can make use of similarities derived from customer-linked transactions data. What is the advantage of using this type of similarity, instead of attribute-based similarities?

The benefit to using customer-linked transactions is that the similarities are not dependent on good construction of attributes and attribute values; in addition, the similarities will agree with the CDT if the customer has also implemented CDT. However, keep in mind that to handle the case of new items, attributes are required anyway, so even when using transaction-based similarities, it is still necessary to construct attributes.

What are the disadvantages of using similarities derived from customer-linked transactions data?

Two key disadvantages are:

Retailers want the similarities to be intuitive to their business users, and attribute-based similarities are much better for this because they are more transparent, particularly when the attributes provided by the business users themselves are used.

The requirement for frequent repeat purchases is a high requirement for a category to meet. Many grocery and drug store categories can meet this, but even at grocery or drug stores, there are categories, such as small electronics, that cannot meet this requirement. There are also categories such as batteries or toothbrushes that do have repeat purchases, but the length between purchases is quite long. For such categories, it is probably better to use attribute-based similarities.

Is it possible to use transactions-based similarities for categories where repeat purchases occur but are very infrequent?

It is recommended that you use attributes for such categories, but if there is sufficient data for the category, it is still possible to use transactions-based similarities. You must have either (or both):

A longer period of history for the category (for example, three years instead of one year) so that there is more chance of catching repeat purchases. Note that this does not necessarily mean that the actual data volume is higher. For example, for batteries, the data volume for three years might be equal to the data volume for six months of dairy, since battery sales have a much lower rate than dairy.
A large number of customers (at least 100,000) for each segment of the category, if you are implementing segments, or just a large number of customers (at least 100,000) for the entire category, if you are not implementing segments. Having such a large number of customers increases the probability that a significant fraction of them will have made repeat purchases in the category in your historical data, even if each customer did not make many repeat purchases. For example, you could have 100,000 customers, each of whom made only one repeat purchase.

How can grouped attributes be used in the AIF platform?

Grouped attributes are recommended only for CDT, not DT. For CDT, the guideline is that attributes must have no more than seven values. Grouping is a way to achieve this goal, as it groups together many attribute values into a single value. Having attributes with a large number of attribute values can result in very large CDTs, especially if the attribute occurs at the top of the tree. This general guideline of seven values is a way to keep CDTs to a reasonable size. Note that retailers seem to prefer having large CDTs with ungrouped attributes.

What attributes are typically good candidates for grouping?

The most common attributes are Brand, Flavor, and Color, because these attributes typically have a large number (that is, more than 50) of values. Keep in mind, that retailers typically do not want grouped attributes.

How can the Brand attribute be grouped?

Brands can, for example, be grouped into High End, Mainstream, and Budget. The grouping must be driven by how the retailer thinks of the category and thinks of brands in the category.

Does the software automatically determine which attributes are functional fit? Can the software help me determine which attributes are functional fit ones?

There is no way to automatically detect functional-fit attributes, or close-to-functional fit attributes. The determination is done today using business users' intuition, not science.

Are there other uses of functional-fit attributes besides the obvious examples like size in wiper blades and clothing? What about functional-fit attributes for food items?

Functional-fit attributes are useful for items such as food for expressing strong customer preferences. For example, caffeinated can be set as a functional-fit attribute for the Coffee category to eliminate transference between caffeinated and de-caffeinated coffee. While it is possible that a small minority of people might transfer purchases of one to the other, it is unlikely enough that, when planning an assortment, transference should simply be eliminated. Note that this is based on the business user's intuition, since there is no automatic way to detect these situations.

What are the special considerations for categories containing very few items, such as 20 or fewer?

Such categories are very rare; typically, categories have hundreds to thousands of items. Small categories may cause a problem in determining demand transference because their historical data may contain very few assortment changes. The more items a category has, the more likely assortment changes will have occurred; conversely, small categories may have very few historical assortment changes, which makes determining transference in the category difficult. One solution is to merge the small category into a bigger category that has similar items. For example, merge a specialty bacon category containing 20 items with the regular bacon category (since both are bacon). This amounts to applying the assortment elasticity of the larger bacon category to the specialty bacon, and if the specialty bacon by itself has very few assortment changes, this is a reasonable solution.

How is new-item introduction handled by demand transference? Which cases of new items are handled?

The case the application handles is introducing new items at an existing store for an existing category that already has attributes. For this case, all that is required for the new item are its attribute values. No sales history is required for the new item. From the attribute values assigned to the new item, the similarity of the new item to existing items is calculated. This similarity is used to forecast a base rate of sale for the new item based on the sales rates of existing similar items. This base rate of sale is then used in demand-transference calculations.

How is W_RTL_PRODUCT_BRAND_DS interface used by DT?

Brand can be provided as an ITEMUDA, or it can be provided via W_RTL_ITEM_GRP1_DS with a PROD_GRP_TYPE=BRAND. If it is done as a PROD_GRP_TYPE=BRAND, then this interface receives the master list of Brands, which the W_RTL_ITEM_GRP1_DS refers to. If Brand is just provided as an ITEMUDA, then there is no need for this file.

How is W_RTL_PRODUCT_COLOR_DS interface used by DT?

In the same way as the W_RTL_PRODUCT_BRAND_DS interface, only the PROD_GRP_TYPE is COLOR in this case.

Attribute Processing Questions

Here are some answers to typical questions related to attribute processing.

Is it allowed for RSE_PROD_ATTR_VALUE_XREF_STG to have attribute values which is not linked to items in W_RTL_ITEM_GRP1_DS? For example, given that in a certain season W_RTL_ITEM_GRP1_DS has following item/attributes: Item A Attribute 1, Item B Attribute 2, Item C Attribute 3, and Item D Attribute 4. RSE_PROD_ATTR_VALUE_XREF_STG should have Attribute 1,2,3,4. In the next season, Item C is dropped: Item A Attribute 1, Item B Attribute 2, and Item D Attribute 4. In this case, RSE_PROD_ATTR_VALUE_XREF_STG should be rebuilt to have only Attribute 1,2,4?

Yes, it is allowed. The load will not fail if there is no data found, so it is not a data validation rule that requires there to be a matching attribute in W_RTL_ITEM_GRP1_DS. If there are no products associated with the attribute value, then the attribute value will not be used.

Can you have records with NULL for all the following five "VALUE" columns in RSE_PROD_ATTR_VALUE_XREF_STG? So, records will have value only for PROD_ATTR_VALUE_KEY and ATTR_VALUE_EXT_CODE columns: MIN_ATTR_NUM_VALUE, MAX_ATTR_NUM_VALUE, ATTR_STRING_VALUE, MIN_ATTR_DATE_VALUE, and MAX_ATTR_DATE_VALUE.

The interface provides multiple choices for identifying the attribute value. You must pick the one approach that works for the specific attribute and the remaining values are NULL. So for attributes that relate to data in W_RTL_ITEM_GRP1_DS, you provide a value for ATTR_VALUE_EXT_CODE and leave the other five indicated Attribute Value columns as NULL.

Lifecycle Pricing Optimization Questions

Here are some answers to typical questions that you may encounter.

What are the recommended steps for preparing the environment for LPO?

Follow the Oracle Retail Analytics and Planning Implementation Guide and Oracle Retail AI Foundation Implementation Guide for setup, as the applications are designed to work together. For LPO specifically, the Lifecycle Pricing Optimization chapter in the AI Foundation Implementation Guide covers the detailed configuration steps.

Why does the initial setup and historical load take so long to process?

Initial data loads, especially on large datasets such as inventory, sales, or transaction history, can be time consuming due to data volume and necessary validations. Several hours of multi-month data is not uncommon particularly if you are loading millions of records. To ensure better performance:

Ensure data files are clean and formatted per specifications before uploading them.
Where possible, chunk files or perform incremental uploads.
Take into account your compute, storage, and data volumes.

After the setup and configuration, what steps should be taken to confirm that LPO and POM are ready for use?

For LPO:

Confirm all prerequisite data interfaces are loaded and validated.
Verify roles and permissions.
Perform an initial scenario / test to confirm data is flowing and outputs are generated.
More details can be found in the Lifecycle Pricing Optimization chapter in this guide.

For Process Orchestration and Monitoring (POM) availability, see the Process Orchestration and Monitoring documentation on Oracle Help Center.

How can the environment be set up to support multiple languages across different countries and browsers?

This is the same across all Oracle Retail Cloud applications and Globalization / Localization requirements. The browser language is the driver. You should be able to test this on your computer by switching the language in the browser.

What is the recommended approach to configure a forecast run for LPO?

In the Oracle Retail AI Foundation User Guide, see the Forecasting Methods in AIF chapter. It goes through the different forecasting methods. Lifecycle Method is typically the forecast we would recommend that will produce reliable forecasts at the lowest levels of the Merchandise and Location hierarchies, accounting for prices and markdowns but with a larger breadth of data needs.

Where can I find more information on Business Rules for LPO?

See the appendixes in the Oracle Retail Lifecycle Pricing Optimization User Guide.

How should business rules be configured, and what is the impact of using or not using forecasts?

The approach to managing forecast-based and non-forecast-based rules depends on how the business intends to use the solution. Non-forecast-based rules apply only to Regular Price.

In a price-zone, there are stores with different inventory levels. Some stores have very high inventory levels, and others have low inventory levels. Does LPO recommend different recommendations for the zone and such stores separately?

This is not possible in the current release. You can configure LPO to run either at the price-zone level or at the store-level. If the price-zone level is selected, then all the stores within that price-zone will receive the same price recommendations. If you want to have store-level recommendations, then you must configure the run-level to be at the store-level and let the algorithm dictate the recommendations. If the stores share very similar customer behavior, then it may be possible that they will receive similar recommendations.

I am not interested in the promotions; can the product handle only markdowns?

Yes, the product can handle only markdowns. You can define all the periods to allow markdowns, and no period should have promotions allowed.

I have a planned promotion and I know when the promotion should occur, but I do not know the items and the depth. Can the product recommend items and the depth?

No, the product requires planned promotion to specify the items, depth, and when the promotion should occur. However, if the retailer wants the product to recommend items and depth, then you can specify the promotion and markdown calendar using the interface provided and specify when the promotions and markdowns can be provided. LPO will determine which items should be promoted or the markdown among the set of periods provided. Note that you can also use the relative calendar option through the UI to specify the calendar.

Should I use Absolute Calendar or Relative Calendar?

The two calendars are provided for flexibility in handling two use cases. When all the items are introduced at almost the same time and exit at almost the same time, then it makes sense to use the absolute calendar. You can also use the relative calendar in such a use case. When the items are introduced at periodic intervals (for example, summer merchandise is introduced in May, June, and July) then it makes sense to use relative calendar. For example, the absolute calendar in such a scenario would probably say May, June as Regular and July as Clearance. This means that items that were introduced in July are going directly into a Clearance season. However, the relative calendar begins after the item is introduced. It is defined as the percentage of regular season and the percentage of the markdown season, based on the total length of the season available for the item.

Is the Style, Color needed as part of Merchandise Hierarchy?

Since the product supports fashion apparel, it is expected that the style and color be provided as part of merchandise hierarchy. If the retailer carries non-apparel items, then the retailer can specify some generic value for style and color, such as not applicable.

How does LPO handle the online channel?

The retailer can specify the online channel as a separate price zone. This means that the price recommendations for brick-and-mortar stores and online-stores will be different. If the retailer does not wish to have different price recommendations, then it is suggested that you combine the online channel into a brick-and-mortar store.

Can LPO handle complex promotions?

LPO handles only simple promotions (for example, percentage off). It does not handle complex promotions like BOGO.

Can LPO come up with bundles for complex promotions? How can this be handled?

LPO cannot come up with bundles for a promotion. A bundle can be specified using Product Groups under Business Rules.

Is budget constraint over the effective week or over the entire life of the item?

Budget is assumed to be for the entire remaining life of the item. The user can specify either different budgets for Promotions and Markdowns or a combined budget. Note that a planned promotions can be excluded or included from this budget.

What happens when a user accepts or rejects a recommendation? Do the numbers change for that week? Does it optimize the entire life again?

In the current release, the metrics in the Results or Manage Recommendations do not reflect the accept, reject, or override price recommendations. However, when the user selects the Recalculate button, then all the metrics are recalculated taking into account the price modifications done by the user. But, when the user selects Reoptimize, then the price modifications are ignored.

Can LPO handle any type of price-zone?

Yes. In the current release, LPO can accept price-zones that are defined as any combination of locations and merchandise.

How does LPO handle multi-currency support?

LPO accepts the historical sales data in the local currency provided. Further, the location in the application can be specified a country locale. Each application run has a location, which is used to tie the price and price-related metrics (for example, revenue) to the specified currency. However, if you want to configure the run to be at a level that spans multiple currencies, then you must specify one currency.

How does LPO support dynamic clustering?

Any time you change the price-zone or re-cluster the customer segments, the change must be re-loaded as part of new hierarchies to LPO. It is considered a major change to the application as it affects the core data elements. The application will be re-calculating the demand parameters and other relevant optimization inputs, based on the new hierarchies. Further, the UI does not offer support to re-group stores within a price-zone based on certain attributes, for example, group stores by sell-through.

How are product images loaded?

Product images can be loaded via the interface provided. LPO expects that the images will be loaded on an image server, which can be a local server. An URL is provided with the image name that can be accessed by the application. The application searches for the image and populates the UI with the relevant image for that item in the Targeted Offer screen.