1. Implementation Guide
  2. Data File Generation
  3. Dimension Files
  4. Product File

Product File

The product file is named PRODUCT.csv, and it contains most of the identifying information about the merchandise you sell and the services you provide. The file structure follows certain rules based on the Retail Merchandising Foundation Cloud Services (RMFCS) data model, as that is the paradigm for retail foundation data that we are following across all RAP foundation files.

The columns below are the minimum required data elements, but the file supports many more optional fields, as listed in the Interfaces Guide. Optional fields tend to be used as reporting attributes in RI and are nullable descriptive fields. Optional fields designated for use in a Science or Planning module are generally nullable too, but should generally be populated with non-null values to provide more complete data to those modules.

Table 7-3 Product File Required Fields

Column Header Usage

ITEM

Product number which uniquely identifies the record. Could be any of these records:

  • a sub-transaction level item (such as a UPC) which has a SKU as a parent and Style as a grandparent

  • a transaction-level SKU (with or without parents)

  • a style or "level 1" item which is above transaction level

ITEM_PARENT

Parent item associated with this record when the item level is 2 or 3.

REQUIRED when providing multiple levels of items to establish the parent/child relationships.

ITEM_GRANDPARENT

Grandparent item associated with this record when the item level is 3.

REQUIRED when providing multiple levels of items to establish the parent/child relationships.

ITEM_LEVEL

Item Level (1, 2, or 3) of this record from the source system. Used to determine what level of item is being provided to the target systems. Item level 2 should have a parent item, and item level 3 should provide both parent and grandparent.

Typical fashion item levels are:

  •  Level 1 – Style

  •  Level 2 – SKU (transaction level)

  •  Level 3 – UPC/EAN/barcode

TRAN_LEVEL

Transaction level (1 or 2) of the item from the source system. Identifies which level is used as the transaction level in RI and RSP.

PACK_FLG

Pack flag (where N = regular item, Y = pack item).

REQUIRED column if the retailer has packs, Optional otherwise.

DIFF_AGGREGATE

Combined differentiator values are used in defining the diff aggregate level (in between Item level 1 and 2 for a multi-level item). For example, for a fashion item, this will be the Color. Specify this on the transaction item-level records.

LVL4_PRODCAT_ID

Default level for Subclass, which is the first level above item in the hierarchy structure. Sometimes referred to as segment or subsegment. All items of any type are mapped to a subclass as their first level. Parent items are not to be treated as hierarchy levels in the file.

LVL4_PRODCAT_UID

Unique identifier of the Subclass. In many merchandising systems the subclass is not unique on its own, so a separate, unique key value must be provided in this case.

LVL5_PRODCAT_ID

Default level for Class (sometimes referred to as Subcategory).

LVL5_PRODCAT_UID

Unique identifier of the Class. In many merchandising systems the class is not unique on its own, so a separate unique key value must be provided in this case.

LVL6_PRODCAT_ID

Default Level for Department (also referred to as Category).

LVL7_PRODCAT_ID

Default Level for Group.

LVL8_PRODCAT_ID

Default Level for Division.

TOP_PRODCAT_ID

Default Level for Company. Only one company is supported at this time, you may not have 2+ companies in the same instance.

ITEM_DESC

Product Name or primary item description.

LVL4_PRODCAT_DESC

Default Level for Subclass Description.

LVL5_PRODCAT_DESC

Default Level for Class Description.

LVL6_PRODCAT_DESC

Default Level for Department Description.

LVL7_PRODCAT_DESC

Default Level for Group Description.

LVL8_PRODCAT_DESC

Default Level for Division Description.

TOP_PRODCAT_DESC

Default Level for Company Description.

The product hierarchy fields use generic level names to support non-traditional hierarchy structures (for example, your first hierarchy level may not be called Subclass, but you are still loading it into the same position in the file). Other levels such as LVL1 to LVL3 have columns in the interface but are not yet used in any module of the platform.

Note:

Multi-level items are not always required and depend on your use-cases. For example, the lowest level (ITEM_LEVEL=3) for sub-transaction items is only used in Retail Insights for reporting on UPC or barcode level attribute values. If you are a non-fashion retailer you may only have a single item level (for SKUs) and the other levels could be ignored. The reason for having different records for each item level is to allow for different attributes at each level, which can be very important in Retail Insights analytics. You may also need to provide multiple item levels for optimizing or planning data at a Style or Style/Color level in the non-RI modules. When providing multiple item level records, note that the item IDs must be unique across all levels and records.

Example data for the PRODUCT.csv file columns above, including all 3 supported item levels: 

ITEM,ITEM_PARENT,ITEM_GRANDPARENT,ITEM_LEVEL,TRAN_LEVEL,PACK_FLG,DIFF_AGGREGATE,LVL4_PRODCAT_ID,LVL4_PRODCAT_UID,LVL5_PRODCAT_ID,LVL5_PRODCAT_UID,LVL6_PRODCAT_ID,LVL7_PRODCAT_ID,LVL8_PRODCAT_ID,TOP_LVL_PRODCAT_ID,ITEM_DESC,LVL4_PRODCAT_DESC,LVL5_PRODCAT_DESC,LVL6_PRODCAT_DESC,LVL7_PRODCAT_DESC,LVL8_PRODCAT_DESC,TOP_LVL_PRODCAT_DESC
190085210200,-1,-1,1,2,N,,8,9001,3,910,3,2,1,1,2IN1 SHORTS,Shorts,Active Apparel,Women's Activewear,Activewear,Apparel,Retailer Ltd
190085205725,190085210200,-1,2,2,N,BLK,8,9001,3,910,3,2,1,1,2IN1 SHORTS:BLACK:LARGE,Shorts,Active Apparel,Women's Activewear,Activewear,Apparel,Retailer Ltd
190085205923,190085210200,-1,2,2,N,DG,8,9001,3,910,3,2,1,1,2IN1 SHORTS:DARK GREY:LARGE,Shorts,Active Apparel,Women's Activewear,Activewear,Apparel,Retailer Ltd
1190085205725,190085205725,190085210200,3,2,N,,8,9001,3,910,3,2,1,1,2IN1 SHORTS:BLACK:LARGE:BC,Shorts,Active Apparel,Women's Activewear,Activewear,Apparel,Retailer Ltd
1190085205923,190085205923,190085210200,3,2,N,,8,9001,3,910,3,2,1,1,2IN1 SHORTS:DARK GREY:LARGE:BC,Shorts,Active Apparel,Women's Activewear,Activewear,Apparel,Retailer Ltd

This example and the field descriptions covered in this section all follow the standard Merchandising Foundation (RMS) structure for product data, and it is strongly recommended that you use this format for RAP. If you are a legacy Planning customer or have specific needs for extended hierarchies, however, then there is a non-RMS format as well. In the non-RMS format, the fields for ITEM, ITEM_PARENT, and ITEM_GRANDPARENT are used to represent the SKU, style/color, and style levels, respectively. While it is not recommended to carry this format forward into RAP, the interface will accept it and there is a Science Platform configuration (EXTENDED_HIERARCHY_SRC) you must change to NON-RMS to align with this.

Instead, the preferred approach is to convert your non-RMS hierarchy structure to a standard RMS-like foundation format. This conversion involves:

  • Provide only the SKUs and Styles as separate item records (dropping the style/color level from the hierarchy). The Style will be the ITEM_PARENT value on the SKU records and ITEM_GRANDPARENT will always be -1.

  • Populate the field DIFF_AGGREGATE at the SKU level with the differentiator previously used in the style/color level. For example, a style/color item ID of S1000358:BLUE uses S1000358 as the ITEM in the style record and ITEM_PARENT in the SKU record. The value BLUE is written in the DIFF_AGGREGATE field in the SKU-level record.

  • When constructing the extended hierarchies in Planning and Science, the styles and diff aggregate values are concatenated together to dynamically create the style/color level of the hierarchy where needed.

Following this approach for your product hierarchy ensures you are aligned with the majority of Oracle Retail applications and will be able to take up additional retail applications in the future without restructuring your product data again.

For other fields not shown here, they are optional from a data load perspective but may be used by one or more applications on the platform, so it is best to consider all fields on the interface and populate as much data as you can. For example, supplier information is a requirement for Inventory Optimization, and brand information is often used in Clustering or Demand Transference. Also note that some fields come in pairs and must be provided together or not at all. This includes:

  •  Brand name and description

  •  Supplier ID and description

Description fields could be set to the same value as the identifier if no other value is known or used, but you must include both fields with non-null values when you want to provide the data.