2 Implementation Considerations
The following information must be considered before configuring Assortment Planning Cloud Service:
Configuration Considerations
Assortment Planning Cloud Service (APCS) contains the solutions APFA (Assortment Planning) and IPCS (Item Planning). During implementation, the user has option to extend the application configuration using Extensibility guidelines. For more details about the extensibility of the configuration, see the Oracle Retail Analytics and Planning Implementation Guide.
Data
APCS needs the following sets of data from retailers, which are broadly classified as hierarchy files and data files. The data is described in the following sections. Based on solutions implemented in Assortment Planning Cloud Service, only hierarchy files and data files specific for those solutions are needed and those are specified in the subsequent sections:
Hierarchy Files
This is the foundation data to build any RPASCE solution. Assortment Planning Cloud Service requires the base foundation hierarchy files, such as Calendar, Product, and Location; also, additional sets of hierarchy files specific to different solutions used in APCS. By default, APCS can get the base foundation hierarchy details as part of RAP integration. The customer only needs to upload hierarchy files which are not part of RAP integration. To load the hierarchy files during the batch process, the customer can upload their hierarchy files as individual files into Object Storage under the input directory or zip them up as hiers.zip and upload the file to the same input directory in Object Storage. All hierarchy files should have at least one valid entry, otherwise the customer will face issues in the application if the hierarchy is used in the workbook templates and if it is empty.
Note:
In order to implement Planning cloud services on Retail Analytics and Planning (RAP), the customer should ensure their foundation data, that is, Product and Organization hierarchies align with Oracle Retail Merchandising Foundation Cloud Service (RMFCS) so that the foundation and transactional data can be used by all services in RAP. They can have more alternate dimensions than available in RMFCS if needed for their Planning Cloud Services.
Customers can use the flex fields available in RAP Foundation files to interface this data. Also, if multiple Planning cloud services such as MFPCS, APCS, and IPOCS-Demand Forecasting are residing in the same PDS, then hierarchies which are common across them should have the same dimension names so they can share the same data interfaced from RAP. However, additional non-shared dimensions can be present in each service, but shared dimensions should have the same name.
Note:
Hierarchy files should always contain header information and columns in any order but the file name must be in the format <hier>.hdr.csv.dat.
For information on the base hierarchy files that can be readily interfaced in RAP integration, see the following sections:
Calendar Hierarchy File
File name: clnd.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
DAY |
Day |
Main |
None |
WEEK |
Week |
Main |
DAY |
MNTH |
Month |
Main |
WEEK |
QRTR |
Quarter |
Main |
MNTH |
HALF |
Half |
Main |
QRTR |
YEAR |
Year |
Main |
HALF |
HLDY |
Holiday |
UDA |
WEEK |
EVNT |
Event |
UDA |
WEEK |
WOYR |
Week of Year |
Alternate |
WEEK |
STDB |
STD/BTA |
UDA |
WEEK |
BYPD |
Assortment Period |
UDA |
WEEK |
Example:
day,day_label,week,week_label,mnth,mnth_label,qrtr,qrtr_label,half,half_label,year,year_label,hldy,hldy_label,evnt,evnt_label,woyr,woyr_label,stdb,stdb_label,bypd,bypd_label 20170129,1/29/2017,w01_2017,2/4/2017,m01_2017,Feb FY2017,q01_2017,Quarter1 FY2017,h1_2017,Half1 FY2017,a2017,FY2017,0,None,0,None,1,Week 01,1,STD,1,AP1 20170130,1/30/2017,w01_2017,2/4/2017,m01_2017,Feb FY2017,q01_2017,Quarter1 FY2017,h1_2017,Half1 FY2017,a2017,FY2017,0,None,0,None,1,Week 01,1,STD,1,AP1 20170131,1/31/2017,w01_2017,2/4/2017,m01_2017,Feb FY2017,q01_2017,Quarter1 FY2017,h1_2017,Half1 FY2017,a2017,FY2017,0,None,0,None,1,Week 01,1,STD,1,AP1 20170201,2/1/2017,w01_2017,2/4/2017,m01_2017,Feb FY2017,q01_2017,Quarter1 FY2017,h1_2017,Half1 FY2017,a2017,FY2017,0,None,0,None,1,Week 01,1,STD,1,AP1
Note:
Though RPASCE supports a string for position IDs, for calendar position week, it is preferred to use the date format YYYYMMDD. If the customer uses RAP integration to get the data, the day and week position IDs at which the data needs to be stored are in the YYYYMMDD format.
Note:
For non-template customers, it is also recommended to align with the GA Calendar Hierarchy structure for the dimension names for day, week, mnth, qrtr, half, and year so that they can upgrade/implement other GA solutions in a multi-app environment. They can use different labels. The lowest dimension should be day and it is mandatory. The rest of the dimensions are optional and their equivalents should be named accordingly.
Product Hierarchy File
File name: prod.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
SKU |
Item |
Main |
None |
SKUP |
Style/Color |
Main |
SKU |
SKUG |
Style |
Main |
SKUP |
SCLS |
Sub-Category |
Main |
SKUG |
CLSS |
Category |
Main |
SCLS |
DEPT |
Department |
Main |
CLSS |
PGRP |
Group |
Main |
DEPT |
DVSN |
Division |
Main |
PGRP |
CMPP |
Company |
Main |
DVSN |
STA1 |
Style UDA 1 |
UDA |
SKUG |
BRND |
Brand |
Alternate |
SKU |
VNDR |
Vendor |
Alternate |
SKU |
Example:
sku,sku_label,skup,skup_label,skug,skug_label,scls,scls_label,clss,clss_label,dept,dept_label,pgrp,pgrp_label,dvsn,dvsn_label,cmpp,cmpp_label,brnd,brnd_label,vndr,vndr_label 1000001,Lasagna,1000001,Lasagna,1000001,Lasagna,1000001,Lasagna,70000,Pasta,4000,Dry Goods,100,Shelf Stable Grocery,10,Center Store,1,Spaces Grocery,Brand,Placeholder Brand,Vendor,Placeholder Vendor 1000002,Spagetti,1000002,Spagetti,1000002,Spagetti,1000002,Spagetti,70000,Pasta,4000,Dry Goods,100,Shelf Stable Grocery,10,Center Store,1,Spaces Grocery,Brand,Placeholder Brand,Vendor,Placeholder Vendor 1000003,Rigatoni,1000003,Rigatoni,1000003,Rigatoni,1000003,Rigatoni,70000,Pasta,4000,Dry Goods,100,Shelf Stable Grocery,10,Center Store,1,Spaces Grocery,Brand,Placeholder Brand,Vendor,Placeholder Vendor 1234582,1234582 - Folgers Breakfast Roast Non-Flavored De-Caffeinated 12 oz Can,22222222,Ground De-Caffeinated Can,121212,Ground De-Caffeinated,100000,Ground,10000,Coffee,1000,Shelf Stable Beverages,100,Shelf Stable Grocery,10,Center Store,1,Spaces Grocery,Brand,Placeholder Brand,Vendor,Placeholder Vendor 1234600,1234600 - Maxwell House 100% Columbian Non-Flavored De-Caffeinated 12 oz Can,22222222,Ground De-Caffeinated Can,121212,Ground De-Caffeinated,100000,Ground,10000,Coffee,1000,Shelf Stable Beverages,100,Shelf Stable Grocery,10,Center Store,1,Spaces Grocery,Brand,Placeholder Brand,Vendor,Placeholder Vendor
Note:
For non-template customers, it is also recommended to align with the GA Product Hierarchy structure for the dimension names for sku, skup, skug, scls, clss, dept, pgrp, dvsn, and cmpp so that they can upgrade/implement other GA solutions in a multi-app environment. They can use different labels. The lowest dimension should be sku and it is mandatory. The rest of the dimensions are optional and their equivalents should be named accordingly.
Location Hierarchy File
File name: loc.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
STOR |
Store |
Main |
None |
DSTR |
District |
Main |
STOR |
REGN |
Region |
Main |
DSTR |
CHNL |
Area |
Main |
REGN |
CHAN |
Chain |
Main |
CHNL |
COMP |
Company |
Main |
CHAN |
STRC |
Store Cluster |
Alternate |
STOR |
CHNC |
Channel |
Alternate |
STRC |
CCTY |
Country |
Alternate |
CHNC |
LOCT |
Location Type |
Alternate |
STOR |
PHWH |
Physical Warehouse |
Alternate |
STOR |
FFLT |
Fulfillment Type |
Alternate |
STOR |
Example:
STOR,STOR_LABEL,DSTR,DSTR_LABEL,REGN,REGN_LABEL,CHNL,CHNL_LABEL,CHAN,CHAN_LABEL,COMP,COMP_LABEL,LOCT,LOCT_LABEL,PHWH,PHWH_LABEL,FFLT,FFLT_LABEL,STRC,STRC_LABEL,CHNC,CHNC_LABEL,CCTY,CCTY_LABEL 1000,1000 Charlotte,1070,North Carolina,170,Mid-Atlantic,1,Brick & Mortar,1,US,1,Retailer Ltd,1,Store,WH-1,Warehouse - US,1,Brick & Mortar,1000,1000 Charlotte,1,Brick & Mortar,1,USA 1001,1001 Atlanta,1023,Georgia,400,South Atlantic,1,Brick & Mortar,1,US,1,Retailer Ltd,2,Kiosk,WH-1,Warehouse - US,1,Brick & Mortar,1001,1001 Atlanta,1,Brick & Mortar,1,USA 1002,1002 Dallas,1104,Texas,230,Gulf States,1,Brick & Mortar,1,US,1,Retailer Ltd,1,Store,WH-1,Warehouse - US,1,Brick & Mortar,1002,1002 Dallas,1,Brick & Mortar,1,USA 1003,1003 Boston,1051,Massachusetts,200,New England,1,Brick & Mortar,1,US,1,Retailer Ltd,1,Store,WH-1,Warehouse - US,1,Brick & Mortar,1003,1003 Boston,1,Brick & Mortar,1,USA 1004,1004 New York,1066,New York,200,New England,1,Brick & Mortar,1,US,1,Retailer Ltd,1,Store,WH-1,Warehouse - US,1,Brick & Mortar,1004,1004 New York,1,Brick & Mortar,1,USA004,1004 New York,1,Brick & Mortar,1,USA
Note:
The Store Cluster dimension (STRC) is dynamically set within the workbook. However, while loading the hierarchy file, the strc position should be loaded with the same position ID as stor and with the label as '.'. The Location clustering solution needs unique identifiers for creating store clusters and will use the unique store identifier loaded at these positions as internal identifiers for creating new clusters within the solution.
Note:
The Planning Location Hierarchy is aligned with the Merchandising Organization Hierarchy for RAP integration, so Region aggregates to Area as in the Merchandising Hierarchy. Channel is an attribute in RMFCS and is not part of the Organization Hierarchy. RMFCS integration to RAP will send the Planning Channel and Planning Country and that will be mapped to the Channel (CHNC) and Country (CCTY) dimension. Store Clusters defined within APCS or interfaced should be below this Channel level.
Note:
If the customer has warehouses holding inventory and receipts data, the Virtual Warehouse locations for each Channel can be loaded as locations with the Location type as ‘W’. The batch process allows splitting of Warehouse Inventory to locations to include in the Location Inventory for Location Planning.
Note:
For the non-template customer, it is also recommended to align with the GA Location Hierarchy structure for the dimension names for stor, dstr, regn, chnl, chan, comp, strc, chnc, and ccty so that they can upgrade/implement other GA solutions in a multi-app environment. They can use different labels. The lowest dimension should be stor and it is mandatory. The rest of the dimensions are optional and their equivalents should be named accordingly.
Cluster Hierarchy File
The cluster hierarchy is an internal application-specific hierarchy used to provide unique cluster IDs to be used during Location Clustering. It needs to be populated with unique cluster IDs (which need to be same as Store Identifiers) used in the Location hierarchy file. There is an OAT process available to synchronize this hierarchy whenever the location hierarchy file is loaded. It can also be scheduled to run on-demand, so retailers do not have to maintain this hierarchy.
Name | Label | Hierarchy Type | Aggs |
---|---|---|---|
CLUS |
Cluster |
Main |
None |
CHN1 | Cluster Channel | Main | CLUS |
File name: clrh.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Field | Description |
---|---|
Cluster |
This is the unique Cluster identifiers from the Location hierarchy but with the label as '.'. The label is created dynamically and mapped to the unique ID present in this file through the Store Clustering process. The number of positions here represents the maximum pool of cluster positions available. |
Cluster Channel | Channel below which the Clusters will be created. This Channel should have the same CHNC (Channel) values in the Location Hierarchy. |
Example:
clus,clus_label,chn1,chn1_label 1000,.,1,Brick & Mortar 1001,.,1,Brick & Mortar 1002,.,1,Brick & Mortar 1003,.,1,Brick & Mortar 1004,.,1,Brick & Mortar
Product Attributes Hierarchy File
The product attributes hierarchy represents attributes associated with products. These attributes are used to group products within categories. This grouping is what consumer decision trees are built on and are used when showing dynamic rollups at the item level.
This hierarchy is intended to capture all product attributes for all product types. The attributes are then assigned to individual products. This assignment is used when processing the dynamic rollups.
This hierarchy is intended to be customized for the individual retailer's needs.
Name | Label | Hierarchy Type | Aggs |
---|---|---|---|
PATV |
Prod Attribute Value |
Main |
None |
PATT |
Prod Attribute |
Main |
PATV |
File name: patr.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Field | Description |
---|---|
Prod Attribute Value |
The various values that an attribute might have. For example, the package type attribute might take the values bag, box, or convenience. |
Prod Attribute |
The name of a product attribute, such as brand, family type, flavor, grain, package type, size, or temperature. |
Example:
patv,patv_label,patt,patt_label prodtype~basic,Basic,prodtype,Product Type prodtype~seasonal,Seasonal,prodtype,Product Type brand~dylanrose,Dylan Rose,brand,Brand brand~forevercali,Forever Cali,brand,Brand brand~legaci,Legaci,brand,Brand
Note:
PATR is used as the Attribute Hierarchy to support the 2-dimensional Product attribute measure. For detailed information on how this configuration is set up, see the Oracle Retail Predictive Application Server Cloud Edition Configuration Tools User Guide.
Note:
APCS has separate workbook flows defined for Items classified as Basic or Seasonal based on the product attribute Product Type. It is recommended to use the Product Type attribute with Basic and Seasonal attribute values for all the Items. The Basic type defines items whose selling pattern is the same across all assortment periods where the Seasonal items selling pattern varies by Season. The customer can assign any UDA to identify the basic items in RMFCS and later can assign that attribute and attribute value to define the basic items in the Planning Admin -> Batch Setup view for the Product Attribute for Basic Items and Product Attribute Value for Basic Items measures.
Note:
APCS uses the Nested Dynamic Rollup of Hierarchies option to review products based on the combination of various product attributes. If non-template customers want to use the same features, customization of their configuration is needed.
For more details about customizing the configuration to use Nested Dynamic Rollup, see the Oracle Retail Predictive Application Server Cloud Edition Configuration of Nested Dynamic Hierarchies Reference Paper. It is available on My Oracle Support in the Oracle Retail Predictive Application Server (RPAS) Cloud for Planning and Optimization / Supply Chain Cloud Services Documentation Library Doc ID: 2492295.1.
Size Hierarchy File
The Size hierarchy represents different sizes associated with products. Also, different sizes are grouped by size range. Different product types by Class/Sub-class can be allowed to use different size ranges within the solution.
AP uses this size hierarchy to further plan buy quantity and receipts by different sizes for newly planned Style/Colors based on the Size Profiles either pre-defined by an Administrator or loaded from the Size Profile Optimization module.
This hierarchy is intended to be customized for the individual retailer's needs.
Name | Label | Hierarchy Type | Aggs |
---|---|---|---|
SIZD |
Size |
Main |
None |
SRNG |
Size Range |
Main |
SIZD |
File name: sizh.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Field | Description |
---|---|
Size |
Different unique sizes such ase S, XS, M, L, XL |
Size Range |
Different grouping of Size Ranges such as Men’s Shoes, Men’s Shirt |
Example:
sizd,sizd_label,srng,srng_label 04_0t15,4 Master,0t15master,Master 0t15 06_0t15,6 Master,0t15master,Master 0t15 08_0t15,8 Master,0t15master,Master 0t15 10_0t15,10 Master,0t15master,Master 0t15 10_5_mensshoes,10.5 Master,mensshoesmaster,Master Men's Shoes 10_5_womensshoes,10.5 Master,womensshoesmaster,Master Women's Shoes 10_mensshoes,10 Master,mensshoesmaster,Master Men's Shoes
Notes:
In RAP Integration with AIF, AP can get the Size hierarchy and Size Profiles from AIF or if the customer is not planning to use the SPO, they can also load the Size Hierarchy and load and use the Admin level Size Profiles.
Additional Specific Hierarchy Files
The following additional hierarchy files are also needed. They are not part of RAP integration, so the customer needs to explicitly provide the input files:
Assortment Hierarchy File
The assortment hierarchy represents the grouping of assortments for a time period. It can be a group of weeks, months, or quarters for which an assortment is planned. This hierarchy is DPM enabled, so users can create new assortments as needed in the Assortment Maintenance workbook and assign the product/calendar association for that assortment period in that workbook.
This hierarchy is intended to be customized for the individual retailer's needs.
Name | Label | Hierarchy Type | Aggs |
---|---|---|---|
FLOW |
Assortment |
Main |
None |
BPER |
Assortment Group |
Main |
FLOW |
BPLB |
Assortment Label |
UDA |
BPER |
BCLS |
Assortment Detail |
UDA |
BPER |
File name: asrt.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Field | Description |
---|---|
Assortment |
This defines different flow in an assortment group such as flow1, flow2, and so on. |
Assortment Group |
This uniquely groups the assortments for a sub-category/time frame. |
Assortment Label |
Assortment Label as user defined attribute given to group similar assortments using Label. |
Assortment Detail |
Assortment Detail as user defined attribute given to group similar assortments. |
Example:
flow,flow_label,bper,bper_label ap01f1,Flow 1,ap01,Assort Period 01 ap02f1,Flow 1,ap02,Assort Period 02 ap03f1,Flow 1,ap03,Assort Period 03
Customer Segment Hierarchy File
Name | Label | Hierarchy Type | Aggs |
---|---|---|---|
CSVD | Version | Main | None |
CSGD | Customer Segment | Main | CSVD |
File name: csgh.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Field | Description |
---|---|
Version |
This is the version of Customer Segment. If there are no versions of customer segment, this can be mapped to the same value as Customer Segment. |
Customer Segment | Customer Segment unique id used in AIF. |
Example:
csvd,csvd_label,csgd,csgd_label 5100,All Customers,5100,All Customers 5101,Value Seekers,5101,Value Seekers 5102,Top Spenders,5102,Top Spenders 5103,Seasonal Shopper,5103,Seasonal Shopper 5104,Loyal Customers,5104,Loyal Customers
Cluster Source Hierarchy File
The cluster source hierarchy is an internal application-specific hierarchy. It should be the same as in the GA configuration and should not be changed. This hierarchy is used during wizard selection for Location Clustering to specify the source for clustering.
File name: csls.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Field | Description |
---|---|
Cluster Source |
This is the unique Cluster Source identifier which can be Forecast, Plan or, Actual. |
Example:
csor,csor_label fcst,Forecast plan,Plan ty,Actual
Cluster Version Hierarchy File
The cluster version hierarchy is an internal application-specific hierarchy. It should be the same as in the GA configuration which contains 20 versions with 00 to 09 reserved for customer-created cluster versions within the applications and versions 10 to 20 for Loaded Clusters of different date ranges from external systems or from Advanced Clusters from AI Foundation. This hierarchy is used in Location Clustering to approve different versions of location clusters.
File name: cver.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Field | Description |
---|---|
Cluster Version |
This is the unique Cluster Version identifier used during approval of a cluster. |
Example:
vers,vers_label,vlbl,vlbl_label 01,Version 01,01,Version 01 02,Version 02,02,Version 02 03,Version 03,03,Version 03 04,Version 04,04,Version 04 05,Version 05,05,Version 05 06,Version 06,06,Version 06 07,Version 07,07,Version 07 08,Version 08,08,Version 08 09,Version 09,09,Version 09 10,Version 10,10,Version 10 11,Version 11,11,Version 11 12,Version 12,12,Version 12 13,Version 13,13,Version 13 14,Version 14,14,Version 14 15,Version 15,15,Version 15 16,Version 16,16,Version 16 17,Version 17,17,Version 17 18,Version 18,18,Version 18 19,Version 19,19,Version 19 20,Version 20,20,Version 20
Clustering Strategy Hierarchy File
The clustering strategy hierarchy is an internal application-specific hierarchy. The retailer can customize this hierarchy during implementation and can use the GA dataset hierarchy as a reference. This hierarchy is used to define different clustering strategies to provide different weights for metrics used during location clustering such as, Sales R and Sales U. This hierarchy is DPM enabled, so users can add more strategies dynamically while assigning strategy weights in the Planning Administration workbook.
File name: pos2.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Field | Description |
---|---|
Clustering Strategy |
This is the unique Clustering Strategy to use with different combinations of metric weights to create clusters. |
Example:
spl2,spl2_label 01,Sales R 02,Sales U 03,Sales AUR 04,GM R 05,GM R %
Curve Points Hierarchy File
The curve points hierarchy file is used to define unique curve libraries that can be used to define different sales curve patterns to be used during seeding in Item Planning. The retailer can customize this hierarchy during implementation and can use the GA dataset hierarchy as a reference. This hierarchy is DPM enabled, so users can add more Curve Points dynamically in Curve Setup.
File name: curv.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Field | Description |
---|---|
Curve Library |
This represents different curves that can be used to define different sales patterns. |
Example:
cnum,cnum_label C01,Curve 01 C02,Curve 02 C03,Curve 03 C04,Curve 04 C05,Curve 05 C06,Curve 06 C07,Curve 07 C08,Curve 08 C09,Curve 09 C10,Curve 10 C11,Curve 11 C12,Curve 12 C13,Curve 13 C14,Curve 14 C15,Curve 15 C16,Curve 16 C17,Curve 17 C18,Curve 18 C19,Curve 19 C20,Curve 20
Custom Messages Hierarchy File
AP Cloud Service also has an additional internal hierarchy for custom messages used in the application called Custom Messages Hierarchy (CMSH). Custom messages used in the application are pre-configured in that hierarchy file and, unless a retailer needs different custom messages, that file does not need to be changed.
All custom messages are loaded as hierarchy positions to enable the translation of custom messages to different languages. It is a single dimensional hierarchy with only one dimension, CMSD. By default, all positions are loaded in English during the hierarchy load. Custom message position names are hard coded in the application, so users should not change the position names. However, during implementation, custom messages can be changed if more descriptive messages are needed.
If a user wants to change the language of custom messages, the user needs to load the provided r_cmsdlabel.csv.ovr using the standard loadmeasure utility after removing languages not needed from that file.
File name: cmsh.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
CMSD |
Messages |
Main |
None |
Example:
cmsd,cmsd_label "ACSA01","Seed Assortment completed successfully." "ACSA02","Warning: Select Seed Source for Assortment from WP Seed Assortment." "ACSS01","Seed Sales completed successfully." "ACSS02","Warning: Select WP Seed Sales to execute the Seeding!" "ACCM01","Seed IPI Weights completed successfully."
Location Space Hierarchy File
The location space hierarchy is an internal application-specific hierarchy to define different location space metrics available based on which location can be clustered. The retailer can customize this hierarchy during implementation and use the GA dataset hierarchy as a reference.
File name: sspc.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Field | Description |
---|---|
Space by Location |
This is the unique location metrics that can be used to define a location such as Square Meter, Avg # of Fixtures, Fixture Capacity, and so on. |
Example:
sloc,sloc_label sqmetr,Square Meter sqfeet,Square Feet avgfix,Avg # of Fixtures avgfacings,Fixture Capacity
Performance Group Hierarchy File
The performance group hierarchy is an internal application-specific hierarchy to define different performance grouping (grading) to use during Location Clustering. The retailer can customize this hierarchy during implementation and use the GA dataset hierarchy as a reference. This hierarchy is DPM enabled, so users can add more performance groups if needed during location clustering.
File name: pos1.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Field | Description |
---|---|
Performance Group |
This is the unique performance grouping to use during clustering such as grades A, B, C, and so on. |
Example:
clst,clst_label 01,A 02,B 03,C 04,D 05,E
Level Hierarchy File
The Level hierarchy is an internal application-specific hierarchy to define different levels of the Dynamic Hierarchy Rollup for Product and Location using its attributes in various workbook templates. It is hard coded to have three levels in the APCS solution.
File name: lvlh.hdr.csv.dat
File format: comma-separated values file
The following table describes the field in this file.
Name | Description |
---|---|
Level |
Attribute Rollup Level. |
Example:
lvld,lvld_label lvl1,Level 1 lvl2,Level 2 lvl3,Level 3
RHS Product Hierarchy File
The RHS Product Hierarchy is a duplicate copy of the Product Hierarchy. It is defined as a Virtual Hierarchy using Platform features. Each dimension in the RHS Product Hierarchy is mapped to a corresponding dimension from the Product Hierarchy. It is used within AP to review Similarity Data and Demand Transference data across products in the Build Wedge process. The customer does not have to load any data for this hierarchy. Internally, the platform will create virtual positions for each position loaded into the Product Hierarchy.
Data Files
A broad and detailed data set is required to use the capabilities of APCS to its fullest.
The following tables describe the data files (measures) needed, load intersection, data type, file name, required/optional, and expected data source details. In the Data Source column, RI means any Data Warehouse or equivalent/RMS and those data are readily available from RAP integration, RSP means data from AI Foundation which is also available as part of RAP integration, Internal means any retailer internal system or the data using data files, and Admin means either data can be directly set up by an administration user or can be loaded as files.
Load Data Set
All data loads in batch after the initial domain build are done by scheduling batch tasks in Online Administration Tools. This information specifies which Load Set the user needs to use to load that particular data file while scheduling the Online Administration Tool Tasks. For more details, see the Oracle Retail Assortment Planning Cloud Service Administration Guide.
Table 2-1 Assortment Planning Cloud Service Measure List - Details 1
Measure Name | Measure Label | Data Type | Load Intersection | File Name | Agg Type | Required or Optional? | Data Source |
---|---|---|---|---|---|---|---|
drtyeop1c |
Ty EOP Reg+Promo C |
real |
week_sku_stor |
eopx.csv.ovr |
pet |
Required |
RI |
drtyeop1r |
Ty EOP Reg+Promo R |
real |
week_sku_stor |
eopx.csv.ovr |
pet |
Required |
RI |
drtyeop1u |
Ty EOP Reg+Promo U |
real |
week_sku_stor |
eopx.csv.ovr |
pet |
Required |
RI |
drtyeop2c |
Ty EOP Clr C |
real |
week_sku_stor |
eopx.csv.ovr |
pet |
Required |
RI |
drtyeop2r |
Ty EOP Clr R |
real |
week_sku_stor |
eopx.csv.ovr |
pet |
Required |
RI |
drtyeop2u |
Ty EOP Clr U |
real |
week_sku_stor |
eopx.csv.ovr |
pet |
Required |
RI |
drtynslsclrc |
Ty Net Sales Clear C |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtynslsclrr |
Ty Net Sales Clear R |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtynslsclru |
Ty Net Sales Clear U |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtynslsproc |
Ty Net Sales Promo C |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtynslspror |
Ty Net Sales Promo R |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtynslsprou |
Ty Net Sales Promo U |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtynslsregc |
Ty Net Sales Reg C |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtynslsregr |
Ty Net Sales Reg R |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtynslsregu |
Ty Net Sales Reg U |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtyrtnclrc |
Ty Return Clear C |
real |
week_sku_stor |
rtn.csv.ovr |
total |
Required |
RI |
drtyrtnclrr |
Ty Return Clear R |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtyrtnclru |
Ty Return Clear U |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtyrtnproc |
Ty Return Promo C |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtyrtnpror |
Ty Return Promo R |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtyrtnprou |
Ty Return Promo U |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtyrtnregc |
Ty Return Reg C |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtyrtnregr |
Ty Return Reg R |
real |
week_sku_stor |
nsls.csv.ovr |
total |
Required |
RI |
drtyrtnregu |
Ty Return Reg U |
real |
week_sku_stor |
rtn.csv.ovr |
total |
Required |
RI |
drtyooc |
Ty On Order C |
real |
week_sku_stor |
oo.csv.ovr |
total |
Required |
RI |
drtyoor |
Ty On Order R |
real |
week_sku_stor |
oo.csv.ovr |
total |
Required |
RI |
drtyoou |
Ty On Order U |
real |
week_sku_stor |
oo.csv.ovr |
total |
Required |
RI |
drtyporcptc |
Ty PO Receipt C |
real |
week_sku_stor |
rcpt.csv.ovr |
total |
Required |
RI |
drtyporcptr |
Ty PO Receipt R |
real |
week_sku_stor |
rcpt.csv.ovr |
total |
Required |
RI |
drtyporcptu |
Ty PO Receipt U |
real |
week_sku_stor |
rcpt.csv.ovr |
total |
Required |
RI |
drtytraninbc |
Ty Transfers In Book C |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytraninbr |
Ty Transfers In Book R |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytraninbu |
Ty Transfers In Book U |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytraninic |
Ty Transfers In ICT C |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytraninir |
Ty Transfers In ICT R |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytraniniu |
Ty Transfers In ICT U |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytraninr |
Ty Transfers In R |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Required |
RI |
drtytraninc |
Ty Transfers In C |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Required |
RI |
drtytraninu |
Ty Transfers In U |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Required |
RI |
drtytranoutbc |
Ty Transfers Out Book C |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytranoutbr |
Ty Transfers Out Book R |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytranoutbu |
Ty Transfers Out Book U |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytranoutic |
Ty Transfers Out ICT C |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytranoutir |
Ty Transfers Out ICT R |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytranoutiu |
Ty Transfers Out ICT U |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Optional |
RI |
drtytranoutr |
Ty Transfers Out R |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Required |
RI |
drtytranoutu |
Ty Transfers Out U |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Required |
RI |
drtytranoutc |
Ty Transfers Out C |
real |
week_sku_stor |
tranx.csv.ovr |
total |
Required |
RI |
drtyicmkdr |
TY Inter-Company Markdown R |
real |
week_sku_stor |
ic_mkd.csv.ovr |
total |
Optional |
RI |
drtyicmkur |
TY Inter-Company Markup R |
real |
week_sku_stor |
ic_mkd.csv.ovr |
total |
Optional |
RI |
drtywfslsr |
TY W/F Sales R |
real |
week_sku_stor |
wfms.csv.ovr |
total |
Optional |
RI |
drtywfslsu |
TY W/F Sales U |
real |
week_sku_stor |
wfms.csv.ovr |
total |
Optional |
RI |
drtywfslsc |
TY W/F Sales C |
real |
week_sku_stor |
wfms.csv.ovr |
total |
Optional |
RI |
drtywfrtnr |
TY W/F Returns R |
real |
week_sku_stor |
wfms.csv.ovr |
total |
Optional |
RI |
drtywfrtnu |
TY W/F Returns U |
real |
week_sku_stor |
wfms.csv.ovr |
total |
Optional |
RI |
drtywfrtnc |
TY W/F Returns C |
real |
week_sku_stor |
wfms.csv.ovr |
total |
Optional |
RI |
drdvprdattt |
Product Attribute - Item Level |
string |
sku_patt |
drdvprdattt.csv.ovr |
mode_pop |
Required |
RI |
drdvppatvt |
RMS Product Attribute Value |
string |
patv |
drdvppatvt.csv.ovr |
mode_pop |
Required |
RI |
drtyudab |
TY RMS UDA |
Boolean |
patt |
drtyudab.csv.ovr |
or |
Required |
RI |
addvlocopnd |
Location Open Date |
date |
stor |
stor_a.csv.ovr |
ambig_pop |
Required |
RI |
addvlocendd |
Location Close Date |
date |
stor |
stor_a.csv.ovr |
ambig_pop |
Required |
RI |
addvlocrefd |
Location Refurbish Date |
date |
stor |
stor_a.csv.ovr |
ambig_pop |
Required |
RI |
addvloctypet |
Location Type |
string |
stor |
stor_a.csv.ovr |
ambig_pop |
Required |
RI |
drtypclsst |
TY RMS Class Display Id |
string |
sku |
prod_a.csv.ovr |
ambig_pop |
Required |
RI |
drtypsclst |
TY RMS Sub-Class Id |
string |
sku |
prod_a.csv.ovr |
ambig_pop |
Required |
RI |
addvlocattt |
Location Attribute |
string |
stor_satt |
addvlocattt.csv.ovr |
mode_pop |
Required |
Admin |
adlylagwt |
LY Week Map |
string |
week |
adlylagwt.csv.ovr |
mode_pop |
Optional |
Admin |
addvprdattb |
Class - Product Attribute Eligibility |
Boolean |
clss_patt |
addvprdattb.csv.ovr |
or |
Optional |
Admin |
addvslscrvv |
Sales Curve % |
real |
woyr_scls_chnc_cnum |
addvslscrvv.csv.ovr |
total |
Optional |
Admin |
addvslsprcc |
Override Cost |
real |
skup_stor |
addvslsprc.csv.ovr |
max_pop |
Optional |
Admin |
addvslsprcr |
Override Retail Price |
real |
skup_stor |
addvslsprc.csv.ovr |
max_pop |
Optional |
Admin |
addvslswgtu |
Sales Weight U |
real |
chnc_spl2 |
addvstrcwgt.csv.ovr |
average_pop |
Optional |
Admin |
addvslswgtr |
Sales Weight R |
real |
chnc_spl2 |
addvstrcwgt.csv.ovr |
average_pop |
Optional |
Admin |
addvslswgtar |
Sales Weight AUR |
real |
chnc_spl2 |
addvstrcwgt.csv.ovr |
average_pop |
Optional |
Admin |
addvgmwgtr |
Gross Margin Weight R |
real |
chnc_spl2 |
addvstrcwgt.csv.ovr |
average_pop |
Optional |
Admin |
addvgmwgtrp |
Gross Margin Weight R % |
real |
chnc_spl2 |
addvstrcwgt.csv.ovr |
mode_pop |
Optional |
Admin |
drdvstrclust |
Loaded Location Cluster |
string |
week_dept_stor |
drdvstrclus.csv.ovr |
mode_pop |
Optional |
AI Foundation |
drdvstrclusl |
Loaded Location Cluster Label |
string |
week_dept_stor |
drdvstrclus.csv.ovr |
mode_pop |
Optional |
AI Foundation |
drdvsrtd |
Start Date |
date |
week_dept_stor |
drdvstrclus.csv.ovr |
ambig_pop |
Optional |
AI Foundation |
drdvendd |
End Date |
date |
week_dept_stor |
drdvstrclus.csv.ovr |
ambig_pop |
Optional |
AI Foundation |
drtyassrtelasv |
TY Assortment Elasticity |
real |
scls_chnc_csgd |
drtyassrtelasv.csv.ovr |
average_pop |
Required |
AI Foundation |
drtyattrwgtv |
TY Attribute Weight % |
real |
scls_chnc_patt_csgd |
drtyattrwgtv.csv.ovr |
average_pop |
Required |
AI Foundation |
drtyfuncfitb |
TY Functional Fit |
Boolean |
scls_chnc_patt_csgd |
drtyattrwgtv.csv.ovr |
or |
Required |
AI Foundation |
fcdvsls1u |
Fcst Sales Reg+Promo U |
real |
week_scls_stor |
fcst_scls.csv.ovr |
total |
Optional |
AI Foundation |
fcdvsls1r |
Fcst Sales Reg+Promo R |
real |
week_scls_stor |
fcst_scls.csv.ovr |
total |
Optional |
AI Foundation |
fctyfcpmu |
Fcst Pre-Season Sales U |
real |
week_sku_stor |
fcst.csv.ovr |
total |
Required |
AI Foundation |
fctyfcimu |
Fcst In-Season Sales U |
real |
week_sku_stor |
fcst.csv.ovr |
total |
Required |
AI Foundation |
fctyfcpmr |
Fcst Pre-Season Sales R |
real |
week_sku_stor |
fcst.csv.ovr |
total |
Required |
AI Foundation |
fctyfcimr |
Fcst In-Season Sales R |
real |
week_sku_stor |
fcst.csv.ovr |
total |
Required |
AI Foundation |
mlcpeopc |
MFP Loaded CP EOP C |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
pet |
Required |
MFP |
mlcpeopr |
MFP Loaded CP EOP R |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
pet |
Required |
MFP |
mlcpeopu |
MFP Loaded CP EOP U |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
pet |
Required |
MFP |
mlcprcptc |
MFP Loaded CP Receipts C |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlcprcptr |
MFP Loaded CP Receipts R |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlcprcptu |
MFP Loaded CP Receipts U |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlcprtn1r |
MFP Loaded CP Returns Reg+Promo R |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlcprtn1u |
MFP Loaded CP Returns Reg+Promo U |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlcprtn2r |
MFP Loaded CP Returns Clear R |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlcprtn2u |
MFP Loaded CP Returns Clear U |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlcpsls1r |
MFP Loaded CP Sales Reg+Promo R |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlcpsls1u |
MFP Loaded CP Sales Reg+Promo U |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlcpsls2r |
MFP Loaded CP Sales Clr R |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlcpsls2u |
MFP Loaded CP Sales Clr U |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlcpslsc |
MFP Loaded CP Sales Reg+Promo C |
real |
week_scls_stor |
mfp_mpcp.csv.ovr |
total |
Required |
MFP |
mlwpooadjc |
MFP Loaded WP On Order Adj C |
real |
week_scls_stor |
mfp_otb.csv.rpl |
total |
Required |
MFP |
mlwpooadjr |
MFP Loaded WP On Order Adj R |
real |
week_scls_stor |
mfp_otb.csv.rpl |
total |
Required |
MFP |
mlwpooadju |
MFP Loaded WP On Order Adj U |
real |
week_scls_stor |
mfp_otb.csv.rpl |
total |
Required |
MFP |
mlwpotbc |
MFP Loaded WP OTB C |
real |
week_scls_stor |
mfp_otb.csv.rpl |
total |
Required |
MFP |
mlwpotbr |
MFP Loaded WP OTB R |
real |
week_scls_stor |
mfp_otb.csv.rpl |
total |
Required |
MFP |
mlwpotbu |
MFP Loaded WP OTB U |
real |
week_scls_stor |
mfp_otb.csv.rpl |
total |
Required |
MFP |
lplaeopc |
LP AP EOP C |
real |
week_dept_stor |
mfp_ lpap.csv.ovr |
pet |
Optional |
MFP |
lplaeopr |
LP AP EOP R |
real |
week_dept_stor |
mfp_ lpap.csv.ovr |
pet |
Optional |
MFP |
lplaeopu |
LP AP EOP U |
real |
week_dept_stor |
mfp_ lpap.csv.ovr |
pet |
Optional |
MFP |
lplarcptc |
LP AP Receipts C |
real |
week_dept_stor |
mfp_ lpap.csv.ovr |
total |
Optional |
MFP |
lplarcptr |
LP AP Receipts R |
real |
week_dept_stor |
mfp_ lpap.csv.ovr |
total |
Optional |
MFP |
lplarcptu |
LP AP Receipts U |
real |
week_dept_stor |
mfp_ lpap.csv.ovr |
total |
Optional |
MFP |
lplartnr |
LP AP Returns R |
real |
week_dept_stor |
mfp_ lpap.csv.ovr |
total |
Optional |
MFP |
lplartnu |
LP AP Returns U |
real |
week_dept_stor |
mfp_ lpap.csv.ovr |
total |
Optional |
MFP |
lplaslsu |
LP AP Sales U |
real |
week_dept_stor |
mfp_ lpap.csv.ovr |
total |
Optional |
MFP |
lplaslsr |
LP AP Sales R |
real |
week_dept_stor |
mfp_ lpap.csv.ovr |
total |
Optional |
MFP |
lplaslsc |
LP AP Sales C |
real |
week_dept_stor |
mfp_ lpap.csv.ovr |
total |
Optional |
MFP |
addvpskugt |
Rename Style Id |
string |
skug |
addvpskugt.csv.ovr |
mode_pop |
Optional |
Admin |
addvpskupt |
Rename Style/Color Id |
string |
skup |
addvpskugt.csv.ovr |
mode_pop |
Optional |
Admin |
addvpskut |
Rename Item Id |
string |
sku |
addvpskugt.csv.ovr |
mode_pop |
Optional |
Admin |
adwpsizeprfp |
Admin Size Profile % |
real |
scls_stor_sizd |
adwpsizeprfp.csv.ovr |
max |
Optional |
Admin |
drdvsizeprfp |
SPO Size Profile % |
real |
scls_stor_sizd |
drdvsizeprfp.csv.ovr |
max |
Optional |
AI Foundation |
addvskuimgt |
Item Image |
string |
sku |
addvskuimgt.csv.ovr |
mode_pop |
Optional |
Admin |
addvskupimgt |
Style-Color Image |
string |
skup |
addvskupimgt.csv.ovr |
mode_pop |
Optional |
Admin |
addvskugimgt |
Style Image |
string |
skug |
addvskugimgt.csv.ovr |
mode_pop |
Optional |
Admin |
addvsclsimgt |
Sub-Class Image |
string |
scls |
addvsclsimgt.csv.ovr |
mode_pop |
Optional |
Admin |
addvpatvimgt |
Product Attribute Value Image |
string |
patv |
addvpatvimgt.csv.ovr |
mode_pop |
Optional |
Admin |
addvpattimgt |
Product Attribute Image |
string |
patt |
addvpattimgt.csv.ovr |
mode_pop |
Optional |
Admin |
drdvskuimgt |
Item Image Name |
string |
sku |
drdvskuimg.csv.ovr |
mode_pop |
Optional |
RI |
drdvskuimgl |
Item Image Address |
string |
sku |
drdvskuimg.csv.ovr |
mode_pop |
Optional |
RI |
All measure files that need to be loaded as data files need to be grouped based on the File Name. The files should contain the header for the measures to be loaded and it should be in .csv format. Measures within a file can be grouped in any order as long as the header column is specified correctly. If a measure is optional in a file, the customer can ignore that measure and group the remaining measures which are available for the customer.
Example:
In following example, the customer is using RAP integration and only grouping the data that is not coming in RAP (or RI) in a file for which customer has the data.
File Name: tranx.csv.ovr
Base Intersection: week/sku/stor
Data Type: real
week,sku,stor,drtyroyalr,drtymiscadju,drtymiscadjr,drtycogsr w01_2021,100000,1000,30.96,31.52,0,0 w02_2021,100000,1000,169.13,112.61,1,37.85 w03_2021,100000,1000,233.54,50.26,1,35.09
Historical Data
It is recommended that you have at least one full year of historical data to create in Assortment Planning Cloud Service. Less data can be used, but the more data that is available, the more statistical significance can be given to the plan data.
By default, RAP integration is set up to interface two years of history into Planning.
Loading and Extracting Data
Data is loaded into Assortment Planning Cloud Service using the Online Administration Tools, which in turn use standard RPAS utilities. For more information on loading and extracting data using Online Administration Tools, see the Oracle Retail Assortment Planning Cloud Service Administration Guide.
Loading Image Based Data
Assortment Planning Cloud Service is pre-configured to provide the item level image view in the templates. The measure set up as the Style-Color level image attribute is addvskupimgt with the base intersection of Style/Color and product attributes images to addvpatvimgt.
The Content Server exposes the client's image files placed into a particular directory as HTTP URLs. The images available in http://{content server url}/imgfetch/image-library/{sub directory if defined}/<image-file-name> must be defined in the load file in xml format.
Sample file for addvskupimgt.csv.ovr:
1234582,"<image id=""main"" label=""Front View""><url size=""thumb"">http://<server>:<port>/<image_path>/sku_10000019_main_thumb.jpg</url></image>" 1234600,"<image id=""main"" label=""Front View""><url size=""thumb"">http://<server>:<port>/<image_path>/sku_10000053_main_thumb.jpg</url></image>"
The first field represents the Style Color ID followed by the required image location. At a minimum, a "thumb" size image file must be loaded to show in the pivot table. However, both the "thumb" and "full" size images can be loaded. For example:
10000010,"<image id=""main"" label=""Front View""><url size=""thumb"">http:// <server>:<port>/<image_path>/sku_10000010_main_thumb.jpg</url><url size=""full"">http://<server>:<port>/<image_path>/sku_10000010_main_full.jpg</url></image>
The customer can also use the same format to upload image URLs for the Item Image, Style Image, and Sub-Class Images. The same image URLs can also be directly managed in Planning Admin -> Define Product Image. They can also set the Item Image Name and Item Image Address and enable the Aggregate Boolean to create the Image URLs for different levels from the same base Item Image.
In order to view the images, the Valid Image URL Hosts property should include the Image URL server name. That needs to be set in RPASCE UI Settings -> System Configuration -> Config Properties -> Images.
Integration
Assortment Planning Cloud Service uses RAP integration to interface with RI to get foundation data from RMFCS or other similar source systems and to get forecast and clustering data from AI Foundation (AIF). For more details about RAP integration, see RAP Integration.
Assortment Planning Cloud Service integrates with MFP Cloud Service for Merchandise Financial Plan Data to use as the Financial Target while creating assortments. For more details, see Appendix: Integration with MFP Cloud Service
If the customer is using an RMFCS version that does not use RAP integration, it can still interface using the file-based approach to interface the foundation data. For more details, see Appendix: RMFCS Integration.
Figure 2-1 Assortment Planning Cloud Service Integration
![This figure illustrates the APCS integration. This figure illustrates the APCS integration.](img/impl_consider_integ.png)
Assortment Planning Cloud Service provides some standard exports that can be used by external systems that need Assortment and Item Plan Data. For details about the standard exports from Assortment Planning Cloud Service, see Appendix: Standard Exports.
Retailers using either the template or non-template version must extract and provide the foundation files needed from other source systems as flat files in the required format as needed by RAP integration and then upload to Object Storage. Any data or hierarchy files that are specific to their Planning Solution that cannot be integrated using RAP integration can be directly uploaded to Object Storage for Planning. In the same way, exported files from the solution if not part of RAP integration are sent back to the Object Storage and retailers can download the extracted files from there. The retailer must integrate it with any other system that requires extracted plan data from APCS, if not part of RAP integration
User Roles and Security
To define workbook template security, the system administrator grants individual users, or user groups, access to specific workbook templates. Granting access to workbook templates provides users with the ability to create, modify, save, and commit workbooks for the assigned workbook templates. Users are typically assigned to groups based on their user application (or solution) role. Users in the same group can be given access to workbook templates that belong to that group alone. Users can be assigned to more than one group and granted workbook template access without belonging to the user group that typically uses a specific workbook template. Workbook access is either denied, read-only, or full access. Read-only access allows a user to create a workbook for the template, but the user is not able to edit any values or commit the workbook. The read-only workbook can be refreshed.
The following table provides guidance regarding which Assortment Planning Cloud Service users must have access to each of the workbooks.
Table 2-2 User’s Access Permission for APCS Workbooks
Workbook | User Roles |
---|---|
Planning Administration |
Planning Administrator |
Validate Loaded Data |
Planning Administrator |
Location Clustering |
Planner, Planning Administrator |
Assortment Period Setup |
Planner, Planning Administrator |
Curve Maintenance |
Planner, Planning Administrator |
Dashboard Parameters |
Planner, Planning Administrator |
Create Assortment |
Planner |
Item Planning |
Planner |
Item Planning - Basics |
Planner |
For more information on security, see the Oracle Retail Predictive Application Server Cloud Edition Administration Guide. For more information on data security in a cloud environment, see the Hosting Policy documents for the cloud solution.
Internationalization
Internationalization is the process of creating software that can be translated more easily. Changes to the code are not specific to any particular market.
Oracle Retail applications have been internationalized to support multiple languages.
The RPASCE platform supports associated solution extensions and solution templates:
-
A solution extension includes a collection of code and generally available configurations. Typically, solution extensions are implemented by a retailer with minimal configuration.
-
A solution template does not include code. A solution template is most typically implemented as a retailer configuration.
Oracle Retail releases the translations of the RPASCE server and client, as well as strings from the solution extensions.
Translations of the solution templates are not released. All templates have the ability to support multi-byte characters.
For more information on internationalization, see the Oracle Retail Predictive Application Server Cloud Service Administration Guide.
Translations are available for Assortment Planning Cloud Service for the following languages:
-
Chinese (Simplified)
-
Chinese (Traditional)
-
Croatian
-
Dutch
-
French
-
German
-
Greek
-
Hungarian
-
Italian
-
Japanese
-
Korean
-
Polish
-
Portuguese (Brazilian)
-
Russian
-
Spanish
-
Swedish
-
Turkish
Note:
For information about adding languages for the first time or for translation information in general, see the Oracle Retail Predictive Application Server Cloud Edition Administration Guide.
Batch Process and Scheduling
Batch scripts are lists of commands or jobs executed without human intervention. A batch window is the time frame in which the batch process must run. It is the upper limit on how long the batch can take. Batch scripts are used for loading foundation data received from a merchandising system, importing and exporting data, and generating targets. The retailer must decide the best time for running batch scripts within the available batch window.
How often to upload updated sales and inventory data and how often to recreate targets must be determined.
-
You must consider at what interval to load the latest sales and inventory data. A weekly load of transactional type data is supported, since the base intersection is at week. It is recommended that the information transactional system, such as RMS, be loaded daily.
-
Product availability and seasonal changes can be reasons for recalculating the targets. This can also be triggered by the addition of new products and availability of substantial new sales and inventory history.
The recommended batch schedule for Assortment Planning Cloud Service is to load historical and actual data on a weekly basis. All hierarchy changes can be loaded on a weekly basis.
In Assortment Planning Cloud Service, batch tasks can be controlled by a system administrator by using the Online Administration Tools. Those tasks, in turn, call the batch scripts with preset parameters to perform the batch tasks. For more information on the Online Administration Tool tasks, see the Oracle Retail Assortment Planning Cloud Service Administration Guide.
For more details about the list of batch control files, the batch process using them, and details about updating them, see the Enterprise Edition Batch framework in the Oracle Retail Predictive Application Server Cloud Edition Implementation Guide.
The customer can use JOS/POM if RAP integration is used and implemented to schedule pre-configured daily and weekly batch tasks in APCS. Those tasks scheduled using JOS/POM in turn call the same Configured batch tasks under the Online Administration Tool tasks. For more details about scheduling of tasks using JOS/POM, see the Oracle Retail Predictive Application Server Cloud Service Administration Guide. For more details about the APCS schedule in JOS/POM, see Appendix: APCS Scheduling in JOS/POM.