| Oracle Retail AI Foundation Cloud Services Implementation Guide Release 22.2.301.0 F59895-02 |
|
 Previous |
 Next |
| Oracle Retail AI Foundation Cloud Services Implementation Guide Release 22.2.301.0 F59895-02 |
|
Previous |
Next |
This chapter describes the Size Profiles (SP) Cloud Service module.
Size Profiles (SP) is a module under AIF Profile Sciences and is used to estimate the distribution of demand across different sizes (size profile) for different merchandise and location levels.
Size profile is estimated at different levels of merchandise and location. The lowest level of estimation is style-color (for merchandise) and store (for location). Size profiles may also be estimated at higher levels of aggregation on both the merchandise and location dimensions (for example, at subclass-store or style/color-store cluster), depending on the retailer's requirements. Irrespective of the level of estimation, the final output for size profiles is at the lowest level (style-color/store), and size profiles are shown at the lowest level in the UI.
Size Profiles relies on the following data elements. These must be provided via text files, which are then loaded.
The three types of hierarchies are Location Hierarchy, Merchandise Hierarchy, and Calendar Hierarchy.
Location Hierarchy. An example of location hierarchy is: CHAIN ' COUNTRY ' REGION ' DISTRICT ' STORE.
Merchandise Hierarchy. An example of merchandise hierarchy is as follows: CHAIN ' COMPANY/BANNER 'DIVISION ' DEPARTMENT 'CLASS ' SUBCLASS ' STYLE ' COLOR ' SIZE (SKU). The Size Profiles application is used for fashion apparel. Therefore, it is expected that the extended merchandise hierarchy is provided, that is, Style and Color are provided through the relevant interfaces.
The STYLE, COLOR and SIZE SKUs are expected to be provided in the W_PRODUCT_DS interface, while the levels between CHAIN and Subclass are provided via W_PROD_CAT_DHS interface. In addition, there must be consistency between the levels provided when using an extended hierarchy. W_PRODUCT_ATTR_DS is used to indicate the relationship between Style, Style/Color, and Style/Color/Size for an extended hierarchy.
Here are the specific fields:
PRODUCT_ATTR13_NAME = PROD_NUM for the Style (for example, 0000190086820900)
PRODUCT_ATTR14_NAME = PROD_NUM for the Style/Color (for example, 190086834203)
PRODUCT_ATTR15_NAME = PROD_NUM for the Style/Color/Size (for example, 1975699).
The value of PROD_NUMs is the same as the value in the W_PRODUCT_DS.PROD_NUM interface.
Here is what this looks like:
Table 11-1 Hierarchy Data
| PROD_NUM | PRODUCT_ATTR13_NAME | PRODUCT_ATTR14_NAME | PRODUCT_ATTR15_NAME |
|---|---|---|---|
|
STYLE_PROD_NUM |
STYLE_PROD_NUM |
||
|
STY/COL_PROD_NUM |
STYLE_PROD_NUM |
STY/COL_PROD_NUM |
|
|
STY/COL_SIZ_PROD_NUM |
STYLE_PROD_NUM |
STY/COL_PROD_NUM |
STY/COL_SIZ_PROD_NUM |
|
Note: For Size Profiles Cloud Services, the Extended Product Hierarchy must be loaded. |
|
Note: The mapping of columns and the example mentioned above for product hierarchy can be different, depending on the source of the data. For example, if the data is loaded from RMS Cloud, the mapping will be as follows:
|
Calendar Hierarchy. This is one of the core hierarchies. The retailer can specify the calendar depending on their business requirements (for example, fiscal calendar).
Historical sales data is required at the sku-store-week level. If the sales transaction data is provided, it will be aggregated by the application to the sku-store-level. It is necessary that the sales transaction data be provided at the lowest level of product hierarchy (that is, the level in RSE_HIER_LEVEL that has LEAF_NODE_FLG = 'Y' for HIER_TYPE_ID = 3).
Alternatively, data can be provided directly at this level using the RSE_SLS_PR_LC_WK_STG interface. When the system is in production, the latest incremental sales data is obtained as part of the batch process.
Two methods are available for generating size profiles. For the Optimization method, historical inventory must be provided at the sku-store-week level. To generate profiles using the Normalize method, inventory data is not required.
Product images that are available on a customer-hosted web server can be viewed in the Size Profiles UI. The W_RTL_PRODUCT_IMAGE_DS.dat interface contains a column called PRODUCT_IMAGE_ADDR, which can contain the full URL to an image of the product. This URL must be in the following format:
http[s]://servername[:port]/location/filename.extension
For example:
PRODUCT_IMAGE_NAME = imagename.png
PRODUCT_IMAGE_ADDR = http://hostname/url/imagename.png
PRODUCT_IMAGE_DESC= Short description of the image
The Size Profiles application running in the cloud does not directly access these images, so there is no need to expose these images outside of the customer's firewall. As long as the user of the SP application has access to the URL while running the SP application, then the user's web browser will be able to resolve the URL and retrieve the images for display when the user chooses this option. The images must be in a file format that the web browser can display. Since the images shown in the UI are small, these images do not need to be high quality images. The size of the image files will affect the time it takes to render them.
The selected season for the run is used in two ways:The historical data period is set based on the start/end date of the selected season, one year ago. In addition, size profiles are generated for products that are selected for the run and are mapped to the selected season.
The season definition can be loaded through the following interfaces: W_RTL_SEASON_D and W_RTL_PHASE_D. In addition, the W_DOMAIN_MEMBER_LKP_TL should have data for DOMAIN_CODE of SEASON and PHASE. The mapping between items and season is also required and can be loaded through W_RTL_SEASON_PHASE_IT_D.
All available size ranges and sub size ranges must be provided using the SPO_SZ_RANGE_STG interface.
SPO_SZ_RANGE_STG sample data:
Table 11-2 Size Range - Sub Size Range Definition
| SZ_RANGE_EXT_KEY | SZ_RANGE_NAME | SZ_RANGE_LENGTH | SUB_SZ_RANGE_EXT_KEY | SUB_SZ_RANGE_NAME | SUB_SZ_RANGE_LENGTH | COPY_OF_SZ_RANGE |
|---|---|---|---|---|---|---|
|
100 |
Active apparel top |
4 |
1001 |
S/M/L/XL |
4 |
Y |
|
100 |
Active apparel top |
4 |
1002 |
S/L/XL |
3 |
N |
|
100 |
Active apparel top |
4 |
1003 |
S/M/L |
3 |
N |
|
100 |
Active Apparel top |
4 |
1004 |
M/L/XL |
3 |
N |
|
100 |
Active apparel top |
4 |
1005 |
S/M/XL |
3 |
N |
|
100 |
Active apparel top |
4 |
1006 |
L/M |
2 |
N |
|
100 |
Active apparel top |
4 |
1007 |
S/M |
2 |
N |
|
100 |
Active apparel top |
4 |
1008 |
S/XL |
2 |
N |
|
100 |
Active apparel top |
4 |
1009 |
L/XL |
2 |
N |
All sizes across all merchandises and their mapping to sub size ranges must be provided using the SPO_SIZE_STG interface.
SPO_SIZE_STG sample data:
Table 11-3 Size Definition and Mapping
| SIZE_EXT_KEY | SIZE_EXT_CODE | SIZE_RANK | EXPECT_KINK_FLG | SZ_RANGE_EXT_KEY | SUB_SZ_RANGE_EXT_KEY |
|---|---|---|---|---|---|
|
1 |
SZ1 |
1 |
N |
100 |
1001 |
|
2 |
SZ2 |
2 |
N |
100 |
1001 |
|
3 |
SZ3 |
3 |
N |
100 |
1001 |
|
4 |
SZ4 |
4 |
N |
100 |
1001 |
|
1 |
SZ1 |
1 |
N |
100 |
1002 |
|
1 |
SZ1 |
3 |
N |
100 |
1002 |
|
4 |
SZ4 |
4 |
N |
100 |
1002 |
|
1 |
SZ1 |
1 |
N |
100 |
1003 |
| 2 |
SZ2 |
2 |
N |
100 |
1003 |
|
3 |
SZ3 |
3 |
N |
100 |
1003 |
|
2 |
SZ2 |
2 |
N |
100 |
1004 |
|
3 |
SZ3 |
3 |
N |
100 |
1004 |
| 4 |
SZ4 |
4 |
N |
100 |
1004 |
The mapping between sku and size must be provided using the SPO_PROD_SIZE_STG interface.
SPO_PROD_SIZE_STG sample data:
Table 11-4 Mapping Between SKU and Size
| PROD_HIER_TYPE_NAME | PROD_EXT_KEY | SIZE_EXT_KEY |
|---|---|---|
|
Extended Product Hierarchy |
78715077631 |
6 |
|
Extended Product Hierarchy |
78715077648 |
7 |
|
Extended Product Hierarchy |
78715077655 |
8 |
|
Extended Product Hierarchy |
78715077662 |
9 |
|
Extended Product Hierarchy |
78715156367 |
1 |
|
Extended Product Hierarchy |
78715156374 |
2 |
|
Extended Product Hierarchy |
78715156381 |
3 |
|
Extended Product Hierarchy |
78715991500 |
1 |
|
Extended Product Hierarchy |
78715991517 |
2 |
|
Extended Product Hierarchy |
78715991524 |
3 |
|
Extended Product Hierarchy |
78715991531 |
4 |
The mapping between style-color/store and sub size range must be provided using the SPO_SUB_SZ_RANGE_PRDLOC_STG interface.
SPO_SUB_SZ_RANGE_PRDLOC_STG sample data:
Table 11-5 Mapping - Style-Color/Store to Sub Size Range
| SUB_SZ_RANGE_EXT_KEY | PROD_HIER_TYPE_NAME | PROD_EXT_KEY | LOC_HIER_TYPE_NAME | LOC_EXT_KEY |
|---|---|---|---|---|
|
1001 |
Extended Product Hierarchy |
86323224302 |
Location Hierarchy |
732 |
|
1001 |
Extended Product Hierarchy |
86323224302 |
Location Hierarchy |
273 |
|
2003 |
Extended Product Hierarchy |
86323226802 |
Location Hierarchy |
778 |
|
2003 |
Extended Product Hierarchy |
86323226802 |
Location Hierarchy |
672 |
|
2003 |
Extended Product Hierarchy |
86323226802 |
Location Hierarchy |
679 |
|
2007 |
Extended Product Hierarchy |
86323226803 |
Location Hierarchy |
778 |
|
2007 |
Extended Product Hierarchy |
86323226803 |
Location Hierarchy |
773 |
|
Note: As an alternative to SPO_SZ_RANGE_STG, SPO_SIZE_STG, SPO_PROD_SIZE_STG and SPO_SUB_SZ_RANGE_PRDLOC_STG, the required data for size, size ranges, and the mappings explained above can be provided through W_RTL_DIFF_GRP_D and W_RTL_DIFF_GRP_D_TL. It is also necessary to set the value of SPO_DIFF_TYPE in RSE_CONFIG to be the same as the diff_type that is in w_rtl_diff_grp_d for size attribute.In addition to these two interfaces, it is expected that the column prod_attr_grp_id will be populated in W_RTL_ITEM_GRP1_D for the PROD_GRP_TYPE that is associated with Size. For the jobs that must be run to load the size, size range, and data, see "Batch and Ad-Hoc Jobs". |
|
Note: It is necessary that all attributes, including the Size attribute, are provided at the lowest level of product hierarchy (that is, the level in RSE_HIER_LEVEL that has LEAF_NODE_FLG = Y). |
The Size Profiles science algorithm uses various configurations. These configurations can be viewed and overridden using the Strategy & Policy Management under Control & Tactical Center. In this dashboard, navigate to Manage System Configurations, select ALL for application and RSE_CONFIG for table and filter the table by APPL_CODE = 'SPO'. For more details, see the "Control & Tactical Center" chapter of the Oracle Retail AI Foundation Cloud Services User Guide.
The main configurations are shown in Table 11-6. These configurations are global and are applied to all runs. There are five configurations that can also be adjusted at the run level: SPO_KINK_INNER_RATIO, SPO_KINK_OUTER_RATIO, SPO_CORR_LOW_SELL_FLG, SPO_LOW_SELL_AVG, SPO_SZ_PRO_GEN_METHOD.
These five configurations are available in the UI and can be overridden when creating a new run.
Table 11-6 Configurations
| PARAM_NAME | PARAM_VALUE | DESCR |
|---|---|---|
|
LOC_CHAIN_LVL_ID |
2 |
To evaluate profiles by comparing them with chain level profile. |
|
MIN_SKUS_PRNT_STR_WK |
2 |
Minimum SKUs for determining SKU-Parent/Store Eligibility. |
|
MIN_SLS_PRNT_STR_WK |
4 |
Minimum Sales units for determining SKU-Parent/Store Eligibility. |
|
MIN_WKS_PRNT_STR_WK |
2 |
Minimum Weeks for determining SKU-Parent/Store Eligibility. |
|
SPO_AVG_WK_SLS_PRNT |
0.08 |
The default value for average weekly sales of sku-parent. |
|
SPO_CORR_LOW_SELL_FLG |
Y |
The default value to indicate Yes or No, whether to Correct Low Sellers flag. |
|
SPO_DIFF_ORG_CORR_PROF |
1 |
This is a configurable parameter that measures the difference between the original and corrected profile for each size. |
|
SPO_ELIG_FRACTION_SKU_STR |
0.1 |
Eligible Fraction SKU-Store for determining SKU-Store Eligibility. |
|
SPO_KINK_INNER_RATIO |
1.1 |
The default value for kink inner ratio. |
|
SPO_KINK_OUTER_RATIO |
1.03 |
The default value for kink inner ratio. |
|
SPO_LOC_HIER_PROCESSING_LVL |
6 |
Level Identifier for the level of the Location Hierarchy at which we process Size Profile. Default 6 is to process at STORE Level. |
|
SPO_LOC_HIER_TYPE |
2 |
Hierarchy Type Identifier for the Location Hierarchy Type. |
|
SPO_LOW_SELL_AVG |
0.08 |
Average weekly sale units across a season, below which deems a SKU (Size) to be a Low Seller. |
|
SPO_MIN_INV_SALES |
1 |
Minimum Inventory and Sales for determining start and end dates. |
|
SPO_MIN_INV_SALES_SKU_STR_WK |
1 |
Minimum Inventory and Sales for determining SKU/Store/Week Eligibility. |
|
SPO_MIN_SALES |
0 |
Minimum Sales for determining start and end dates. |
|
SPO_MIN_SALES_SKU_STR |
1 |
Minimum Sales SKU-Store for determining SKU-Store Eligibility. |
|
SPO_MIN_SALES_SKU_STR_WK |
0 |
Minimum Sales for determining SKU/Store/Week Eligibility. |
|
SPO_MIN_SEASON_LEN_SKU_STR |
1 |
Minimum Season Length SKU-Store for determining SKU-Store Eligibility. |
|
SPO_MIN_SKU_STR_WK |
2 |
Minimum SKUs for determining SKU-Parent/Store Eligibility. |
|
SPO_PCT_MAX |
0.05 |
Percent Maximum for determining start and end dates. |
|
SPO_PCT_MAX_SKU_STR_WK |
0 |
Percent Max SKU-Store-Week for determining SKU/Store/Week Eligibility. |
|
SPO_PCT_SZ_RNG_PRNT_STR_WK |
0.41 |
Percent sub size range for determining SKU-Parent/Store Eligibility. |
|
SPO_PROD_HIER_PARENT_LVL |
8 |
Level Identifier for the level of the Product Hierarchy of the SKU-Parent. Default 8 is the STYLE-COLOR Level. |
|
SPO_PROD_HIER_PROCESSING_LVL |
9 |
Level Identifier for the level of the Product Hierarchy at which we process Size Profile. Default 9 is to process at SKU Level. |
|
SPO_PROD_HIER_TYPE |
3 |
Hierarchy Type Identifier for the Product/Merchandise Hierarchy Type. |
|
SPO_PROF_EXP_LOC_LVL |
6 |
Mark USER_BY_AIP=Y Where active Season Size Profiles created at Store level in Export DB view. |
|
SPO_PROF_EXP_MERCH_LVL |
6 |
Mark USER_BY_AIP=Y Where active Season Size Profiles created at Subclass level in Export DB view. |
|
SPO_SKU_PRNT_STR_WK |
2 |
Post Processing threshold: Min number of SKU-parent/store/weeks with at least one valid sale. |
|
SPO_SP_CHART_COLOR_LVL_ID |
8 |
Color level id for displaying color level items in the size profiles chart. |
|
SPO_SP_CHART_DISTRICT_LVL_ID |
5 |
District level id for filtering store level items in the size profiles chart. |
|
SPO_SP_CHART_STYLE_LVL_ID |
7 |
Style level id for filtering color level items in the size profiles chart. |
|
SPO_SZ_PRO_GEN_METHOD |
Optimization |
The default value for size profile generation method. |
|
SPO_TOT_UNIT_SLS |
2 |
Post Processing threshold that is applied to determine the number of valid sizes (i.e., the sizes that meet this minimum sales threshold). |
|
SPO_TOT_UNIT_SLS_PCT_SIZES |
0.4 |
Post Processing threshold that is applied to the number of valid sizes in a sub size range. This filter is applied in connection with SPO_TOT_UNIT_SLS. In this example, 40% of the sizes must have two units or more for the profile to be considered valid. |
|
SZ_PROF_CORR_THRESHOLD |
0.75 |
The size profiles at the lower level of escalation are compared to size profiles at a higher level (e.g., at Chain level). If the correlation between the two profiles is more than this value, the size profile at the lower level of merchandise/location hierarchy is considered valid. |
|
SPO_DIFF_TYPE |
SIZE |
Diff Type value to be used in loading data from RI to SPO. Note: This value must be the same as the diff_type that is in w_rtl_diff_grp_d for size attribute. |
The output of Size Profiles is reviewed and submitted by the user using the Size Profiles UI. The submitted profiles can be obtained from the export interface file spo_size_profile.csv, which is available under ORASE_WEEKLY_extract.zip.
The output contains the size profiles at the style-color/location as well as profiles at higher levels of merchandise (for example, class/location). In addition to the columns that indicate the merchandise-location-size dimension and the percentage of each size in the profile, there are two flags in the export file (USED_BY_AIP and USED_BY_RDF) that indicate which rows must be extracted by Retail Demand Forecasting (RDF) and Assortment Planning Cloud Service (AP CS).
In addition to spo_size_profile.csv, the ORASE_WEEKLY_extract.zip folder contains two other files (d1itpt.01 and spo_gid_label.txt) for integration with Allocation. For details about the content and format of these files, please refer to the documentation for Oracle Retail Allocation Cloud Service.
The following batch and ad-hoc jobs are responsible for loading the size, size range, and season data into SPO.
|
Note: When running ad-hoc jobs for loading size and size range data, they must be run in the following sequence:SPO_SIZE_LOAD_JOB; SPO_PROD_SIZE_LOAD_JOB; SPO_SIZE_RANGE_LOAD_JOB; SPO_SUB_SZ_RANGE_PRDLOC_LOAD_JOB |
Table 11-7 Data-Loading Batch and Ad-Hoc Jobs
| JobName | Description | RmsBatch | ParameterValue | Modules |
|---|---|---|---|---|
|
SPO_SEASON_LOAD_START_JOB |
SPO_SEASON_LOAD_START_JOB |
rse_process_state_update.ksh |
SPO_SEASON_LOAD_PROCESS Start |
SPO_Batch |
|
SPO_SEASON_LOAD_JOB |
SPO_SEASON_LOAD_JOB |
spo_season_load.ksh |
SPO_Interfac-es||SPO_Interfac-es_CNE |
|
|
SPO_SEASON_LOAD_END_JOB |
SPO_SEASON_LOAD_END_JOB |
rse_process_state_update.ksh |
SPO_SEASON_LOAD_PROCESS End |
SPO_Batch |
|
SPO_SIZE_RANGE_LOAD_START_JOB |
SPO_SIZE_RANGE_LOAD_START_JOB |
rse_process_state_update.ksh |
SPO_SIZE_RANGE_LOAD_PROCESS Start |
SPO_Batch |
|
SPO_SIZE_RANGE_LOAD_JOB |
SPO_SIZE_RANGE_LOAD_JOB |
spo_sz_range_load.ksh |
SPO_Interfac-es||SPO_Interfac-es_CNE |
|
|
SPO_SIZE_RANGE_LOAD_END_JOB |
SPO_SIZE_RANGE_LOAD_END_JOB |
rse_process_state_update.ksh |
SPO_SIZE_RANGE_LOAD_PROCESS End |
SPO_Batch |
|
SPO_SIZE_LOAD_START_JOB |
SPO_SIZE_LOAD_START_JOB |
rse_process_state_update.ksh |
SPO_SIZE_LOAD_PROCESS Start |
SPO_Batch |
|
SPO_SIZE_LOAD_JOB |
SPO_SIZE_LOAD_JOB |
spo_size_load.ksh |
SPO_Interfac-es||SPO_Interfac-es_CNE |
|
|
SPO_SIZE_LOAD_END_JOB |
SPO_SIZE_LOAD_END_JOB |
rse_process_state_update.ksh |
SPO_SIZE_LOAD_PROCESS End |
SPO_Batch |
|
SPO_PROD_SIZE_LOAD_START_JOB |
SPO_PROD_SIZE_LOAD_START_JOB |
rse_process_state_update.ksh |
SPO_PROD_SIZE_LOAD_PROCESS Start |
SPO_Batch |
|
SPO_PROD_SIZE_LOAD_JOB |
SPO_PROD_SIZE_LOAD_JOB |
spo_prod_size_load.ksh |
SPO_Interfac-es||SPO_Interfac-es_CNE |
|
|
SPO_PROD_SIZE_LOAD_END_JOB |
SPO_PROD_SIZE_LOAD_END_JOB |
rse_process_state_update.ksh |
SPO_PROD_SIZE_LOAD_PROCESS End |
SPO_Batch |
|
SPO_SUB_SZ_RANGE_PRDLOC_LOAD_START_JOB |
SPO_SUB_SZ_RANGE_PRDLOC_LOAD_START_JOB |
rse_process_state_update.ksh |
SPO_SUB_SZ_RANGE_PRDLOC_LOAD_PROCESS Start |
SPO_Batch |
|
SPO_SUB_SZ_RANGE_PRDLOC_LOAD_JOB |
SPO_SUB_SZ_RANGE_PRDLOC_LOAD_JOB |
spo_sub_sz_range_prdloc_load.ksh |
SPO_Interfac-es||SPO_Interfac-es_CNE |
|
|
SPO_SUB_SZ_RANGE_PRDLOC_LOAD_END_JOB |
SPO_SUB_SZ_RANGE_PRDLOC_LOAD_END_JOB |
rse_process_state_update.ksh |
SPO_SUB_SZ_RANGE_PRDLOC_LOAD_PROCESS End |
SPO_Batch |
The following jobs are for exporting the outputs.
Table 11-8 Output Exporting Batch and Ad-Hoc Jobs
| JobName | Description | RmsBatch | ParameterValue | Modules |
|---|---|---|---|---|
|
SPO_EXPORT_START_JOB |
SPO_EXPORT_START_JOB |
rse_process_state_update.ksh |
SPO_PROD_SIZE_LOAD_PROCESS Start |
SPO_Batch |
|
SPO_EXPORT_PREP_JOB |
SPO_EXPORT_PREP_JOB |
spo_export_prep.ksh |
SPO_Export |
|
|
SPO_SZ_PROF_EXPORT_JOB |
SPO_SZ_PROF_EXPORT_JOB |
spo_sz_prof_export.ksh |
#Sys-Opt.SPO_HOME/data/outfile/spo_sz_prof_export.csv |
SPO_Export |
|
SPO_SZ_PROF_EXPORT_ADHOC_JOB |
SPO_SZ_PROF_EXPORT_ADHOC_JOB |
spo_sz_prof_export.ksh |
#Sys-Opt.SPO_HOME/data/outfile/spo_sz_prof_export.csv |
SPO_Export |
|
SPO_EXPORT_END_JOB |
SPO_EXPORT_END_JOB |
rse_process_state_update.ksh |
SPO_PROD_SIZE_LOAD_PROCESS End |
SPO_Batch |
|
SPO_EXPORT_PREP_ADHOC_JOB |
SPO_EXPORT_PREP_ADHOC_JOB |
spo_export_prep.ksh |
SPO_Export |
|
|
SPO_ALLOC_EXPORT_JOB |
Export data for allocation |
spo_alloc_export.ksh |
||
|
SPO_ALLOC_EXPORT_ADHOC_JOB |
Ad hoc job to export data for allocation |
spo_alloc_export.ksh |
SPO_Export |
|
|
SPO_ALLOC_GID_FILE_EXPORT_JOB |
Generate a GID file |
spo_alloc_gid_file_export.ksh |
||
|
SPO_ALLOC_GID_FILE_EXPORT_ADHOC_JOB |
Ad hoc job to generate a GID file |
spo_alloc_gid_file_export.ksh |
SPO_Export |
