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 AI Foundation 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 8-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) or pack item

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

Style/colors are NOT considered as items and do not need to be provided as separate records.

ITEM_PARENT

Parent item associated with this record when the item level is 2 or 3. If you are not providing level 2 or 3 item records, then you may set this value to -1 on all rows as no items will have parents.

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. If you are not providing level 3 item records, then you may set this value to -1 on all rows as no items will have grandparents.

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 AI Foundation.

PACK_FLG

Pack flag (where N = regular item, Y = pack item). Defaults to N if not provided.

REQUIRED column if the retailer has packs, optional otherwise. If pack items are going to be included, then also note that additional interfaces SALES_PACK.csv and PROD_PACK.csv become required.

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. This is used to dynamically create the planning item-parent (SKUP) level, so it must follow RPAS format rules (a combination of numbers, letters, and underscores only, no spaces or other characters).

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 dataset. Typically, this is hard-coded to a value of 1 for the company ID.

ITEM_DESC

Product Name or primary item description. When you are providing multiple levels of items, this may contain the style name, SKU name, or sub-transaction item name (for example, UPC 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.

INVENTORIED_FLG

Indicates whether the item carries stock on hand. Data sent to Planning apps is generally only for inventoried items (Y), but you may have non-inventoried items loaded for other purposes (N). The flags are used from the SKU level item records, values on the style or UPC level item records can be defaulted to some value, they are not currently used.

SELLABLE_FLG

Indicates whether the item is sellable to customers. Data sent to Planning apps is only for sellable items (Y) or pack items (PACK_FLG=Y), but you may have non-sellable items loaded for other purposes (N). The flags are used from the SKU level item records, values on the style or UPC level item records can be defaulted to some value; they are not currently used.

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 file columns such as LVL1 to LVL3 exist 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. Most implementations will only have ITEM_LEVEL=1 and ITEM_LEVEL=2 records. 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 (style, SKU, and UPC): 

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,INVENTORIED_FLG,SELLABLE_FLG
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,Y,Y
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,Y,Y
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,Y,Y
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,Y,Y
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,Y,Y

This example and the field descriptions covered in this section all follow the standard Merchandising Foundation (RMFCS) 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, 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 legacy style/color item ID of S1000358:BLUE will instead create S1000358 as the ITEM for the style-level record and the ITEM_PARENT in the SKU record. The value BLUE is written in the DIFF_AGGREGATE field in the SKU-level record (DIFF_AGGREGATE can be set to -1 or left null on style level records).

  • When constructing the extended hierarchies in Planning and AI Foundation, 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 Planning 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 can 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.