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:
|
ITEM_PARENT |
Parent item associated with this record when the item level is 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 REQUIRED when providing multiple levels of items to establish the parent/child relationships. |
ITEM_LEVEL |
Item Level ( Typical fashion item levels are:
|
TRAN_LEVEL |
Transaction level ( |
PACK_FLG |
Pack flag (where 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 |
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 andITEM_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 ofS1000358:BLUE
usesS1000358
as theITEM
in the style record andITEM_PARENT
in the SKU record. The valueBLUE
is written in theDIFF_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.