6 Scheduled Integration
This chapter provides a summary of integrations that are scheduled either to be run once per day or periodically throughout the day. There are generally two types of integrations - those that expect or produce files and those that move data between integration tables, also referred to as Bulk Data Integration (BDI).
File-based Integration Overview
Merchandising and Sales Audit require that all inbound and outbound file-based transactions adhere to standard file layouts. There are two types of file layouts: detail-only and master-detail, which are described in the sections below.
Standard File Layouts
The Merchandising interface library supports two standard file layouts: one for master/detail processing, and one for processing detail records only. True sub-details are not supported within the Merchandising base package interface library functions.
A 5-character identification code or record type identifies all records within an I/O file, regardless of file type. The following includes common record type values:
-
FHEAD-File Header
-
FDETL-File Detail
-
FTAIL-File Tail
-
THEAD-Transaction Header
-
TDETL-Transaction Detail
-
TTAIL-Transaction Tail
Each line of the file must begin with the record type code followed by a 10-character record ID.
Detail-Only Files
File layouts have a standard file header record, a detail record for each transaction to be processed, and a file trailer record. Valid record types are FHEAD, FDETL, and FTAIL.
Example 6-1 Detail-Only Files
FHEAD0000000001STKU1996010100000019960929 FDETL0000000002SKU100000040000011011 FDETL0000000003SKU100000050003002001 FDETL0000000004SKU100000050003002001 FTAIL00000000050000000003
Master and Detail Files
File layouts consists of:
-
Standard file header record
-
Set of records for each transaction to be processed
-
File trailer record.
The transaction set consists of:
-
Transaction set header record
-
Transaction set detail for detail within the transaction
-
Transaction trailer record
Valid record types are FHEAD, THEAD, TDETL, TTAIL, and FTAIL.
Example 6-2 Master and Detail Files
FHEAD0000000001RTV 19960908172000 THEAD000000000200000000000001199609091202000000000003R TDETL000000000300000000000001000001SKU10000012 TTAIL0000000004000001 THEAD000000000500000000000002199609091202001215720131R TDETL000000000600000000000002000001UPC400100002667 TDETL0000000007000000000000020000021UPC400100002643 0 TTAIL0000000008000002 FTAIL00000000090000000007
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type. |
File Line Identifier |
Number(10) |
Specified by external system |
Line number of the current file. |
|
File Type Definition |
Char(4) |
N/A |
Identifies transaction type. |
|
File Create Date |
Date |
Create date |
Date file was written by external system. |
|
Transaction Header |
File Type Record Descriptor |
Char(5) |
THEAD |
Identifies file record type. |
File Line Identifier |
Number(10) |
Specified by external system |
Line number of the current file. |
|
Transaction Set Control Number |
Char(14) |
Specified by external system |
Used to force unique transaction check. |
|
Detail Sequence Number |
Char(6) |
Specified by external system |
Sequential number assigned to detail records within a transaction. |
|
Transaction Detail |
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies file record type. |
File Line Identifier |
Number(10) |
Specified by external system |
Line number of the current file. |
|
Transaction Set Control Number |
Char(14) |
Specified by external system |
Used to force unique transaction check. |
|
Detail Sequence Number |
Char(6) |
Specified by external system |
Sequential number assigned to detail records within a transaction. |
|
Transaction Trailer |
File Type Record Descriptor |
Char(5) |
TTAIL |
Identifies file record type. |
File Line Identifier |
Number(10) |
Specified by external system |
Line number of the current file. |
|
Transaction Detail Line Count |
Number(6) |
Sum of detail lines |
Sum of the detail lines within a transaction. |
|
File Trailer |
File Record Type Descriptor |
Char(5) |
FTAIL |
Identifies file record type. |
File Line Identifier |
Number(10) |
Specified by external system |
Line number of the current file. |
|
Total Transaction Line Count |
Number(10) |
Sum of all transaction lines |
All lines in file less the file header and trailer records. |
Integration Batch Wrapper FAQ
See also the "Batch Wrapper Overview" in Chapter 1 of the Merchandising Operations Guide, Volume 1.
For input files, are there any specific file format names?
Usually, the input file pattern is the same as the batch name. This can be seen in the ParameterValue
column of the Job tab in the Batch Schedule spreadsheet. For example, dealupld
has this parameter value:
dealupld #SysOpt.dbwallet dealupld
The input file pattern is the 3rd parameter (dealupld
) so the filename should have dealupld
in it (for example, dealupld_input
, input_dealupld
, and so on). There are some batch programs that should start with a specific pattern like saimptlogi - the input file should start with RTLOG*. This can be seen as well in the Batch Schedule spreadsheet:
#SysOpt.dbwallet RTLOG
How and where will files be moved?
The input file (zipped) should be in uploaded to the Object Storage through the FTS Rest service. The files should have a prefix of incoming/
.
Files uploaded to FTS Rest Service are no longer required to have a .complete file.
The batch wrappers will handle downloading the files from Object Storage using FTS Rest Service with "incoming/" prefix and the corresponding file name pattern at each batch runtime. The files will be downloaded to the batch/incoming folder. Each file downloaded from Object Storage will again be uploaded with a "downloaded/" prefix. The files with "incoming/" prefix will then be deleted from Object Storage.
The batch wrappers will move the downloaded files to the input folder (data/in) given that the filename of the zip file corresponds to the expected file name pattern.
What will happen to the files once they are processed?
Successfully processed files will be move to the processed folder (data/processed). Files with errors will be uploaded to Object Storage with a "reject/" prefix and will be removed from the input folder (data/in) and corresponding errors will be logged in the error log.
Will processed file be archived?
Yes. Input files will be archived in the processed folder (data/processed), while any output file will be archived in the archive folder (data/archive)
What will happen if the file is rejected?
Reject files will be created as applicable and this will be sent to the outgoing folder (batch/outgoing) as well as archived in the archive folder (data/archive). Reject files in the batch/outgoing folder will be uploaded to Object Storage with a "reject/" prefix and deleted from the batch/outgoing folder.
Depending on the batch, if the program completes successfully even with rejected records then the rejected input file will be moved to the processed folder (data/processed). But if the batch aborts, then the rejected input file will be removed from the input folder (data/in) and uploaded to Object Storage with a "reject/" prefix.
Input/Output File Naming Convention
Batch | Input File Name | Zip File Name |
---|---|---|
dealupld |
*dealupld* |
*dealdupld*.zip |
ediupack |
*ediupack* |
*ediupack*.zip |
ediupavl |
*ediupavl* |
*ediupavl*.zip |
lcup798 |
*lcup798* |
*lcup798*.zip |
lcupld |
*lcupld* |
*lcupld*.zip |
cmpupld |
*cmpupld* |
*cmpupld*.zip |
fcosttmplupld.ksh |
*fcosttmplupld* |
*fcosttmplupld*.zip |
htsupld |
*htsupld* |
*htsupld*.zip |
otbupld |
*otbupld* |
*otbupld*.zip |
tranupld |
*tranupld* |
*tranupld*.zip |
fcustomerupload.ksh |
*fcustomerupload* |
*fcustomerupload*.zip |
iindbatch.ksh |
Input file name is provided by user. Must end in *.xml Template name must correspond to S9T_TEMPLATE.TEMPLATE_KEY |
*<input file name>*.zip |
poindbatch.ksh |
Input file name is provided by user. Must end in *.xml Template name must correspond to S9T_TEMPLATE.TEMPLATE_KEY |
*<input file name>*.zip |
replindbatch.ksh |
Input file name is provided by user. Must end in *.xml Template name must correspond to S9T_TEMPLATE.TEMPLATE_KEY |
*<input file name>*.zip |
saimpadj |
*saimpadj* |
*saimpadj*.zip |
load_item_forecast.ksh |
*demand* |
*demand*.zip |
lcmt700 |
*lcmt700* |
*lcmt700*.zip |
lcmt707 |
*lcmt707* |
*lcmt707*.zip |
resa2sim |
SIMT* |
No zip file. Input file is from saexpsim. |
resa2dw |
RDWT* RDWF* RDWS* RDWC* |
No zip file. Input file is from saexpdw. |
lcmt730 |
*lcmt730* |
*lcmt730*.zip |
lcmt798 |
*lcmt798* |
*lcmt798*.zip |
lifstkup |
*lifstkup* |
*lifstkup*.zip |
ordinvupld |
ORIN* |
ORIN*.zip |
sa_rules_total_upload.ksh |
sartexp_<table name>* |
sartexp*.zip |
saimptlogfin |
storedayfile |
No zip file. Input file is from sagetref. |
saimptlogi |
RTLOG_<store>_<datetime>.dat |
RTLOG*.zip |
saimptlogtdup_upd |
storedayfile storeposfile |
No zip file. Input file is from sagetref. |
savouch |
*savouch* |
*savouch*.zip |
stlgdnld |
*stlgdnld* |
*stlgdnld*.zip |
stockcountupload.ksh |
STK*.<file extension> |
STK*.zip |
trandataload.ksh |
*trandataload* |
*trandataload*.zip |
uploadsales.ksh |
POSU_<store>_<tran_date>_ <sysdate>.<thread_val> |
POSU*.zip |
wfslsupld.ksh |
*wfslsupld* |
*wfslsupld*.zip |
wfordupld.ksh |
wford*.dat |
wford*.zip |
wfretupld.ksh |
wfreturn*.dat |
wfreturn*.zip |
Bulk Data Integration Overview
Oracle Bulk Data Integration (BDI) is a solution that is part of the Oracle Retail Integration Cloud Service that defines the architecture and infrastructure used to move bulk data among Oracle Retail applications.
In a Bulk Data Integration system, message families are represented as interface modules. Each interface module (for example, DiffGrp_Fnd) contains a Merchandising component that takes care of pulling and staging data for publication to the External BDI system. Interface modules are divided by functional entity (for example, Item Master, Stores, Diffs, and so on).
For more information on BDI, see the Oracle Retail Integration Cloud Service documentation on docs.oracle.com/retail
.
Outbound Scheduled Integration
This section provides a summary of integrations that are scheduled either to be run once per day or periodically throughout the day to send data from Merchandising or Sales Audit to another solution. It includes both file-based and BDI-based integrations.
Foundation Data
Merchandising publishes foundation data for many other solution areas, including stores, warehouses, omni-channel, and so on.
The following scheduled outbound integrations are included in this functional area:
-
Calendar Publication API (BDI_Calendar_Fnd_PF_From_RMS_EOW_JOB)
-
Code Detail Publication API (BDI_CodeDetail_Fnd_PF_From_RMS_JOB)
-
Code Head Publication API (BDI_CodeHead_Fnd_PF_From_RMS_JOB)
-
Company-wide Closings and Company Closed Exceptions (BDI_CompanyClosed_Fnd_PF_From_RMS_JOB)
-
Currency Conversion Rates Publication API (BDI_CurrConvRates_Fnd_PF_From_RMS_EOW_JOB)
-
Delivery Slot Publication API (BDI_DeliverySlot_Fnd_PF_From_RMS_JOB)
-
Diff Group Publication API (BDI_DiffGrp_Fnd_PF_From_RMS_JOB)
-
Finisher Address Publication API (BDI_FinisherAddr_Fnd_PF_From_RMS_JOB)
-
Location Closed Publication API (BDI_LocClosed_Fnd_PF_From_RMS_JOB)
-
Merch Hierarchy Publication API (BDI_MerchHier_Fnd_PF_From_RMS_JOB)
-
Organization Hierarchy Publication API (BDI_OrgHier_Fnd_PF_From_RMS_JOB)
-
Partner Address Publication API (BDI_PartnerAddr_Fnd_PF_From_RMS_JOB)
-
Partner Org Unit Publication API (BDI_PartOrgUnit_Fnd_PF_From_RMS_JOB)
-
Store Address Publication API (BDI_StoreAddr_Fnd_PF_From_RMS_JOB)
-
Store Hours Publication API (BDI_StoreHours_Fnd_PF_From_RMS_JOB)
-
Supplier Address Publication API (BDI_SupplierAddr_Fnd_PF_From_RMS_JOB)
-
UDA Values Publication API (BDI_UdaValues_Fnd_PF_From_RMS_JOB)
-
UOM Class Publication API (BDI_UomClass_Fnd_PF_From_RMS_JOB)
-
UOM Conversion Publication API (BDI_UomConversion_Fnd_PF_From_RMS_JOB)
-
Warehouse Address Publication API (BDI_WhAddr_Fnd_PF_From_RMS_JOB)
Brand Publication API (BDI_Brand_Fnd_PF_From_RMS_EOW_JOB)
This section describes the Brand Publication BDI.
Business Overview
This API publishes the creation, update and deletion of brand information to the RIB such that all the downstream applications (including an external system) may subscribe to it and have information in sync with Merchandising. Publishing is provided synchronously in a near-real time manner.
New Brand
Creating a new brand triggers a message sent to notify external systems. Brand name and description are sent as part of the create message.
Table 6-1 Brand – Create and Update
Message Element | Included? | Notes |
---|---|---|
Brand name |
Always |
This field contains the brand name. |
Brand Description |
Always |
This field contains the description of the brand. |
Error Handling
When the publication encounters a non-fatal error, messages continue to be processed. For the message where the error was
encountered, a status of Hospital (H
) is sent to the RIB and the status of the message in the queue is set
to H
. These types of errors occur when no changes in the database have been made and a process to try to
re-publish the messages is available. In case the error is a fatal error, a status of Error (E
) is sent to
the RIB and the next message in the queue is not retrieved until the error is resolved.
Message XSD
Here are the filenames that correspond with each message type. Please consult the RIB documentation for each message type for a detailed picture of the composition of each message.
Message Types | Message Type Description | XML Schema Definition (XSD) |
---|---|---|
brandcre |
Brand Create Message |
BrandDesc.xsd |
brandupd |
Brand Modify Message |
BrandDesc.xsd |
branddel |
Brand Delete Message |
BrandRef.xsd |
Calendar Publication API (BDI_Calendar_Fnd_PF_From_RMS_EOW_JOB)
This section describes the Calendar Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Calendar information (2 prior years, current year, 2 future years) from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdifoundationb.pls.pls
BDI_FOUNDATION_SQL.CALENDAR_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising V_BDI_DAY_LEVEL_CALENDAR view.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Code Detail Publication API (BDI_CodeDetail_Fnd_PF_From_RMS_JOB)
This section describes the Code Detail Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Code Detail information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdicrosspillarb.pls
BDI_CROSS_PILLAR_SQL.CODE_DETAIL_UP( O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function updates the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising CODE_DETAIL table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This updates the internal BDI control tables.
A database commit is issued, and the control ID is returned by the API.
Code Head Publication API (BDI_CodeHead_Fnd_PF_From_RMS_JOB)
This section describes the Code Head Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Code Head information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdicrosspillarb.pls
BDI_CROSS_PILLAR_SQL.CODE_HEAD_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising CODE_HEAD table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Company-wide Closings and Company Closed Exceptions (BDI_CompanyClosed_Fnd_PF_From_RMS_JOB)
This section describes the Company-wide Closings and Company Closed Exceptions Publication BDI.
Design Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Store information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
The following packages are impacted:
Filename: bdifoundations.pls
BDI_FOUNDATION_SQL.COMPANY_CLOSED_UP ( O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
Filename: bdifoundationb.pls
BDI_FOUNDATION_SQL.COMPANY_CLOSED_UP ( O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising company closed and company closed exception table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Data Definition XML
The BDI interface staging tables are generated based on the XML schema definition.
Data Flow | Description | XML Schema Definition (XSD) |
---|---|---|
Company Closed |
Company Closed upload to BDI |
CompanyClosed_Fnd_BdiInterfaceModule.xml |
Company Closed Exceptions |
Company Closed Exceptions upload to BDI |
CompanyClosedExcep_Fnd_BdiInterfaceModule.xml |
Currency Conversion Rates Publication API (BDI_CurrConvRates_Fnd_PF_From_RMS_EOW_JOB)
This section describes the Currency Conversion Rates Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Currency conversion rates information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdifoundationb.pls.pls
BDI_FOUNDATION_SQL.CURR_CONV_RATES_UP( O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising MV_CURRENCY_CONVERSION_RATES materialized view.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Delivery Slot Publication API (BDI_DeliverySlot_Fnd_PF_From_RMS_JOB)
This section describes the Delivery Slot Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Delivery Slot information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdicrosspillarb.pls
BDI_CROSS_PILLAR_SQL.DELIVERY_SLOT_UP ( O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising DELIVERY_SLOT table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Diff Group Export (export_diffgrp.ksh)
Module Name |
export_diffgrp.ksh |
Description |
Extraction of differentiator groups data. |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS255 |
Wrapper Script |
rmswrap_shell_out.ksh |
Design Overview
This batch job will extract new, updated and deleted Merchandising diff group information into a flat file. Data to be extracted will be pulled off from the differentiator group tables.The mode (full vs. delta) will be an input parameter for this batch. The mode will allow a full extract (all diff group records in Merchandising) as well as delta processing (all diff group record changes in the time frame passed in the program) of data. For a full extract, records will be retrieved from the differentiator group tables. For a delta extract, the action type and diff group ID will be retrieved from the differentiator group staging export table and the attributes will be retrieved from the differentiator group tables.
Diff Group Publication API (BDI_DiffGrp_Fnd_PF_From_RMS_JOB)
This section describes the Diff Group Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Diff Groups from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdicrosspillarb.pls
BDI_CROSS_PILLAR_SQL.DIFF_GROUP_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound tables that reside in the BDI_RMS_INT_SCHEMA schema. These outbound tables are loaded with records from the Merchandising Diff Group head and detail tables.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Diff ID and Type Export (export_diffs.ksh)
Module Name |
export_diffs.ksh |
Description |
Extraction of differentiator's data defined for a differentiator type. |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
256 |
Wrapper Script |
rmswrap_shell_out.ksh |
Design Overview
This batch job will extract new, updated and deleted Merchandising differentiator information into a flat file. Data to be extracted will be pulled off from the differentiator extract staging and the differentiator IDs table.
The mode (full vs. delta) will be an input parameter for this batch. The mode will allow a full extract (all differentiator records in Merchandising) as well as delta processing (all differentiator record changes in the time frame passed in the program) of data.
For a full extract, records will be solely retrieved from the differentiator IDs table. For a delta extract, the action type and differentiator ID will be retrieved from the differentiator export staging table and the attributes will be retrieved from the differentiator IDs table.
Diff ID Publication API (BDI_Diff_Fnd_PF_From_RMS_JOB)
This section describes the Diff ID Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Diff IDs from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
This section describes the package impact.
Bulk Interface Module
Filename: bdicrosspillarb.pls
BDI_CROSS_PILLAR_SQL.DIFF_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Diff tables.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Finisher Address Publication API (BDI_FinisherAddr_Fnd_PF_From_RMS_JOB)
This section describes the Finisher Address Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Finisher Address positions from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package
Package Impact
Filename: bdifoundations/b.pls
BDI_FOUNDATION_SQL.FINISHER_ADDR_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Finisher Address tables.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Location Closed Publication API (BDI_LocClosed_Fnd_PF_From_RMS_JOB)
This section describes the Location Closed Publication BDI.
Design Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Store information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
The following packages are impacted by this BDI:
Bulk Interface Module
The following build interface module packages are impacted:
Filename: bdifoundations.pls
FUNCTION LOCATION_CLOSED_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
Filename: bdifoundationb.pls
FUNCTION LOCATION_CLOSED_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Location closed table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Merch Hierarchy Publication API (BDI_MerchHier_Fnd_PF_From_RMS_JOB)
This section describes the Merch Hierarchy Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Merchandise Hierarchy information from Merchandising to other Oracle Retail Applications.
On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
This section describes the package impact.
Bulk Interface Module
Filename: bdimerchb.pls
BDI_MERCH_SQL.MERCH_HIER_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Merchandise Hierarchy tables.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Merchandise Hierarchy Export (export_merchhier.ksh)
Module Name |
export_merchhier.ksh |
Description |
Extraction of merchandise hierarchy data. |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
260 |
Wrapper Script |
rmswrap_shell_out.ksh |
Design Overview
This batch job will extract new, updated and deleted Merchandising merchandise hierarchy information from division to subclass into a flat file. Data to be extracted will be pulled off from the merchandise hierarchy export staging table and the main merchandise hierarchy tables. The mode (full vs. delta) will be an input parameter for this new batch. The mode will allow a full extract (all merchandise hierarchy records in Merchandising) as well as delta processing (all merchandise hierarchy changes since the last export) of data.For a full extract, records will be solely retrieved from the main merchandise hierarchy tables. For a delta extract, the action type and entity ID will be retrieved from the merchandise hierarchy export staging table and the attributes of the entities will be retrieved from their corresponding man entity tables.
Organization Hierarchy Publication API (BDI_OrgHier_Fnd_PF_From_RMS_JOB)
This section describes Organization Hierarchy Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Org Hierarchy information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
This section describes the package impact.
Bulk Interface Module
Filename: bdiorgb.pls
BDI_ORG_SQL.ORG_HIER_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Organization Hierarchy tables.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Organizational Hierarchy Export (export_orghier.ksh)
Module Name |
export_orghier.ksh |
Description |
Extraction of organizational hierarchy data. |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
Ksh |
Catalog ID |
RMS261 |
Wrapper Script |
rmswrap_shell_out.ksh |
Design Overview
This batch job will extract new, updated and deleted Merchandising organizational hierarchy information from company to stores and warehouses into a flat file. Data to be extracted will be pulled off from the organizational hierarchy export staging table and the main organizational hierarchy tables. The mode (full vs. delta) will be an input parameter for this batch. The mode will allow a full extract (all organizational hierarchy records in Merchandising) as well as delta processing (all organizational hierarchy changes since the last export) of data.For a full extract, records will be solely retrieved from the main organizational hierarchy tables. For a delta extract, the action type and entity ID will be retrieved from the organizational hierarchy export staging table and the attributes of the entities will be retrieved from their corresponding man entity tables.
Partner Address Publication API (BDI_PartnerAddr_Fnd_PF_From_RMS_JOB)
This section describes the Partner Address Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Code Head information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdifoundationb.pls.pls
BDI_FOUNDATION_SQL.PARTNER_ADDR_UP( O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Partner Address table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Partner Org Unit Publication API (BDI_PartOrgUnit_Fnd_PF_From_RMS_JOB)
This section describes the Partner Org Unit Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Code Head information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdifoundationb.pls.pls
BDI_FOUNDATION_SQL.PARTNER_ORG_UNIT_UP( O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Partner Org Unit table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Partner Publication API (BDI_Partner_Fnd_PF_From_RMS_JOB)
This section describes the Partner Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Code Head information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdifoundationb.pls.pls
BDI_FOUNDATION_SQL.PARTNER_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API. A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Partner table. After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.A database commit is issued, and the control Id is returned by the API.
Store Address Publication API (BDI_StoreAddr_Fnd_PF_From_RMS_JOB)
This section describes the Store Address Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Store Address information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
This section describes the package impact.
Bulk Interface Module
Filename: bdiorgb.pls
BDI_ORG_SQL.STORE_ADDR_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Store Address table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Store Hours Publication API (BDI_StoreHours_Fnd_PF_From_RMS_JOB)
This section describe the Store Hours Publication BDI.
Design Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Store information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
The following packages are impacted by the Store Hours Publication BDI:
Bulk Interface Module
In the Build Interface Module:
Filename: bdiorgb.pls
BDI_ORG_SQL.STORE_HOURS_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Store table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Store Publication API (BDI_Store_Fnd_PF_From_RMS_JOB)
This section describes the Store Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Store information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
This section describes the package impact.
Bulk Interface Module
Filename: bdiorgb.pls
BDI_ORG_SQL.STORE_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Item Location table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Stores Export (export_stores.ksh)
Module Name |
export_stores.ksh |
Description |
Extraction of store data. |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
Ksh |
Catalog ID |
RMS263 |
Wrapper Script |
rmswrap_shell_out.ksh |
Design Overview
This batch job will extract new, updated and deleted Merchandising store information into two flat files - one for store and one for store addresses. Data to be extracted will be pulled from the store export staging, store and address tables. The mode (full vs. delta) will be an input parameter for this batch. The mode will allow a full extract (all store records in Merchandising) as well as delta processing (all store changes since the last export) of data.For a full extract, records will be solely retrieved from the store table for store information and address table for store addresses. For a delta extract, the action type, store ID and address will be retrieved from the store export staging table and the details of the store will be retrieved from both the store and address tables.
Supplier Address Publication API (BDI_SupplierAddr_Fnd_PF_From_RMS_JOB)
This section describes the Supplier Address Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Supplier Address positions from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdifoundations/b.pls
BDI_FOUNDATION_SQL.SUPPLIER_ADDR_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Supplier Address tables.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Sups Publication API (BDI_Supplier_Fnd_PF_From_RMS_JOB)
This section describes the Sups Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Code Head information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdifoundationb.pls.pls
BDI_FOUNDATION_SQL.SUPS_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Sups table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Tax Download - Brazil (taxdnld)
Module Name |
taxdnld |
Description |
Tax Download to 3rd Party POS in Global Tax [GTAX] Implementations |
Functional Area |
Integration - 3rd Party POS |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS124 |
Wrapper Script |
N/A |
Design Overview
This batch program downloads the tax information to 3rd Party POS systems when the Merchandising default tax type is GTAX.This program only needs to be run if the client uses Merchandising Global Tax functionality.
Restart/Recovery
The logical unit of work for this module is defined by item, ref_item and store combination. This batch program uses table-based restart/recovery. The commit happens in the database when the commit max counter is reached.
Integration Contract
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000020 |
Output File Layout
Table 6-3 Output File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
File Line Sequence |
Number(10) |
N/A |
Line number of the current file |
|
File Type Definition |
Char(4) |
TAXD |
Identifies file as 'Tax Details' |
|
File Create Date |
Char(14) |
create date |
Vdate in 'YYYMMDDHHMISS'format |
|
FDETL |
FDETL |
Char(5) |
FDETL |
FDETL |
File Line Sequence |
Number(10) |
N/A |
Line number of the current file |
|
STORE |
Char(10) |
N/A |
Store number |
|
ITEM |
Char(25) |
N/A |
Item |
|
item_number_type |
Char(6) |
S - Store W - Warehouse |
Item number type |
|
format_id |
Char(1) |
N/A |
Format id |
|
prefix |
Char(2) |
N/A |
Prefix |
|
ref_item |
Char(25) |
N/A |
Reference Item |
|
ref_item_number_type |
Char(6) |
N/A |
Refrerence item number type |
|
ref_format_id |
Char(1) |
N/A |
Ref format id |
|
ref_prefix |
Char(2) |
N/A |
Ref no. prefix |
|
taxable indicator |
Char(1) |
N/A |
Taxable indicator |
|
class_vat_ind |
Char(1) |
N/A |
Class vat indicator |
|
FTAXD |
FTAXD |
Char(5) |
FTAXD |
FTAXD |
File Line Sequence |
Number(10) |
N/A |
Line number of the current file |
|
tax_code |
Char(10) |
N/A |
Tax code |
|
tax_rate |
Char(20) |
N/A |
Tax rate |
|
calculation_basis |
Char(1) |
N/A |
Calculation basis |
|
tax_amount |
Char(20) |
N/A |
Tax amount |
|
effective_from |
Char(8) |
N/A |
Effective from |
|
time |
Char(6) |
N/A |
Time |
|
status |
Char(1) |
N/A |
Status |
|
FTAIL |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Sequence |
Number(10) |
N/A |
Line number of the current file |
|
rec_counter |
Number(10) |
N/A |
Record counter |
Ticket Download (tcktdnld)
Module Name |
tcktdnld.pc |
Description |
Download of Data to be Printed on Tickets |
Functional Area |
Foundation Data |
Module Type |
Integration |
Module Technology |
PROC |
Catalog ID |
RMS59 |
Wrapper Script |
rmswrap_out.ksh |
Design Overview
This program creates an output file containing the information to be printed on a ticket or label for a particular item/location. This program is driven by the requests for tickets generated from Merchandising and Pricing. The details of what should be printed on each ticket are defined in Merchandising on the ticket type details table.
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameters |
Integration Contract |
IntCon000107 |
Output File Layout
Table 6-4 tcktdnld.pc - Output File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
File Line Sequence |
Number(10) |
N/A |
Line number of the current file |
|
File Type Definition |
Char(4) |
TCKT |
Identifies file as ‘Print Ticket Requests' |
|
File Create Date |
Char(14) |
N/A |
The date on which the file was created in ‘YYYMMDDHHMISS' format |
|
THEAD |
File Type Record Descriptor |
Char(5) |
THEAD |
Identifies file record type |
File Line Sequence |
Number(10) |
N/A |
Line number of the current file |
|
ITEM |
Char(25) |
N/A |
ID number of the transaction level item for which the ticket applies. |
|
Ticket Type |
Char(4) |
N/A |
ID which indicates the ticket type to be printed |
|
Location Type |
Char(1) |
N/A |
Identifies the type of location for which tickets will be printed. Valid values are store (S) and warehouse (W). |
|
Location |
Char(10) |
N/A |
The ID of the store or warehouse for which tickets will be printed |
|
Quantity |
Number(12,4) |
N/A |
The quantity of tickets to be printed; which includes 4 implied decimal places |
|
TCOMP |
File Type Record Descriptor |
Char(5) |
TCOMP |
Identifies file record type |
File Line Sequence |
Number(10) |
N/A |
Line number of the current file |
|
ITEM |
Char(25) |
N/A |
ID number of the item which is only populated if the item in THEAD is a pack item |
|
Quantity |
Number(12,4) |
N/A |
Quantity of the component item as a part of the pack; includes 4 implied decimal places |
|
TDETL |
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies file record type |
File Line Sequence |
Number(10) |
N/A |
Line number of the current file |
|
Detail Sequence Number |
Number(10) |
N/A |
Sequential number assigned to the detail records |
|
Ticket Item |
Char(4) |
N/A |
ID indicating the detail to be printed on the ticket. If the attribute is a UDA, then this will contain the ID of the UDA. Otherwise, it is the code associated with the attribute in Merchandising (such as, CLSS = class) |
|
Attribute Description |
Char(120) |
N/A |
Description of the attribute – either the UDA description or the Merchandising description for the attribute |
|
Value |
Char(250) |
N/A |
Detail to be printed on the ticket (for example:. Item number, Department Number, Item description) |
|
Supplement |
Char(120) |
N/A |
Supplemental description to the Value (for example: Department Name) |
|
TTAIL |
File Type Record Descriptor |
Char(5) |
TTAIL |
Identifies file record type |
File Line Sequence |
Number(10) |
N/A |
Line number of the current file |
|
Transaction Detail Line Count |
Number(6) |
sum of detail lines |
Sum of the detail lines within a transaction |
|
FTAIL |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Sequence |
Number(10) |
N/A |
Line number of the current file |
UDA Publication API (BDI_Uda_Fnd_PF_From_RMS_JOB)
This section describes the UDA Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Code Head information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdifoundationb.pls
BDI_FOUNDATION_SQL.UDA_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising UDA table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
UDA Values Publication API (BDI_UdaValues_Fnd_PF_From_RMS_JOB)
This section describes the UDA Values Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Code Head information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdifoundationb.pls.pls
BDI_FOUNDATION_SQL.UDA_VALUES_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising UDA Values table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
UOM Class Publication API (BDI_UomClass_Fnd_PF_From_RMS_JOB)
This section describes the UOM Class Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Uom Class information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdicrosspillarb.pls
BDI_CROSS_PILLAR_SQL.UOM_CLASS_UP ( O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising UOM_CLASS table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
UOM Conversion Publication API (BDI_UomConversion_Fnd_PF_From_RMS_JOB)
This section describes the UOM Conversion BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Uom Conversion information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdicrosspillarb.pls
BDI_CROSS_PILLAR_SQL.UOM_CONVERSION_UP ( O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising UOM_CONVERSION table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
VAT Codes, Regions, and Rates Export (export_vat.ksh)
Module Name |
export_vat.ksh |
Description |
Extraction of vat data |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
Ksh |
Catalog ID |
RMS264 |
Wrapper Script |
rmswrap_shell_out.ksh |
Design Overview
This batch job will extract new, updated and deleted Merchandising VAT information into a flat file. Data to be extracted will be pulled off from the VAT export staging, VAT region, VAT codes, and VAT code rates tables.
The mode (full vs. delta) will be an input parameter for this batch. The mode will allow a full extract (all vat region/vat code/vat code rate combination records in RMS) as well as delta processing (all VAT record changes in the time frame passed in the program) of data.
In either of the mode exempt vat region won't get fetched in case of SVAT tax type.
For a full extract, records will be retrieved from the VAT region, VAT code, and VAT code rates tables. For a delta extract, the action type, vat region, vat code and active date will be retrieved from the VAT export staging table and the attributes will be retrieved from the main table.
VAT Publication API (BDI_Vat_Fnd_PF_From_RMS_JOB)
This seciton describes the VAT Publication BDI.
Design Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Vat information from RMS to other Oracle Retail Applications. On this particular integration stream, the data flow is from RMS to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling an RMS owned API that will pull data from RMS and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Bulk Interface Module
Filename: bdifoundationb.pls
BDI_FOUNDATION_SQL.FUNCTION VAT_UP (O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the VAT_CODES, VAT_CODE_RATES and VAT_REGION tables from RMS.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Warehouse (BDI_Wh_Fnd_PF_From_RMS_JOB)
This section describes Warehouse Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Warehouse information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
This section describes the package impact.
Bulk Interface Module
Filename: bdiorgb.pls
BDI_ORG_SQL.WH_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Warehouse tables.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Warehouse Address Publication API (BDI_WhAddr_Fnd_PF_From_RMS_JOB)
This section describes Warehouse Address Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Warehouse Address information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
This section describes the package impact.
Bulk Interface Module
Filename: bdiorgb.pls
BDI_ORG_SQL.WH_ADDR_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Warehouse Address tables.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Items
Merchandising publishes item data for many other solution areas, including stores, warehouses, omni-channel, and so on.
-
Item Image Publication API (BDI_ItemImage_Fnd_PF_From_RMS_JOB)
-
Item Location Publication API (BDI_ItemLoc_Fnd_PF_From_RMS_JOB)
-
Item Master Publication API (BDI_ItemHdr_Fnd_PF_From_RMS_JOB)
-
Item Supplier Country Dimensions Publication API (BDI_ItSupCtryDim_Fnd_PF_From_RMS_JOB)
-
Item Supplier Country Publication API (BDI_ItSupCtry_Fnd_PF_From_RMS_JOB)
-
Item Supplier Manufacturing Country Publication API (BDI_ItSupManCtry_Fnd_PF_From_RMS_JOB)
-
Item Supplier Publication API (BDI_ItemSupp_Fnd_PF_From_RMS_JOB)
-
Item Supplier UOM Publication API (BDI_ItemSuppUom_Fnd_PF_From_RMS_JOB)
-
Pack Item Publication API (BDI_PckitemBrkout_Fnd_PF_From_RMS_JOB)
-
Price History Publication API (BDI_PriceHist_Fnd_PF_From_RMS_JOB)
-
Related Item Publication API (BDI_RelatedItem_Fnd_PF_From_RMS_JOB)
-
UDA Item Date Publication API (BDI_UdaItemDate_Fnd_PF_From_RMS_JOB)
-
UDA Item FF Publication API (BDI_UdaItemFF_Fnd_PF_From_RMS_JOB)
-
UDA Item LOV Publication API (BDI_UdaItemLov_Fnd_From_RMS_JOB)
Item Image Publication API (BDI_ItemImage_Fnd_PF_From_RMS_JOB)
This section describes the Item Image Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Item Image information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdiitemb.pls
BDI_ITEM_SQL.ITEM_IMAGE_UP (O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising ITEM_IMAGE table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Item Location Export (export_itemloc.ksh)
Module Name |
export_itemloc.ksh |
Description |
Extraction of item location data. |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS257 |
Wrapper Script |
rmswrap_shell_out.ksh |
Design Overview
This batch job extracts new, updated and deleted Merchandising item-location information into a flat file.
-
This batch supports both a full and delta export of item-location data.
-
A threading indicator parameter should be passed. Passing 'Y' means a thread number (1-20) will be passed in. Passing 'N' means no thread number will be passed in and the program will use a default thread number.
-
An optional location parameter may be passed in for either modes. If this value is passed in, the batch will create a flat file for the location passed in. If it is not passed in, the batch will create flat files for all locations.
-
This creates separate files per location (Store, Warehouse or External Finisher).
-
This exports delta item header information for each applicable store location.
-
This will export data only for approved, sellable items.
-
This will export attributes from item/location and item/location traits.
-
This should also include the item parent as its own record in the extract.
-
The flat files that will be created will now be pipe delimited.
Item Location Publication API (BDI_ItemLoc_Fnd_PF_From_RMS_JOB)
This section describes the Item Location Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Item Location information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
This section describes the package impact.
Bulk Interface Module
Filename: bdiitemb.pls
BDI_ITEM_SQL.ITEM_LOC_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Item Location table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Item Master Export (export_itemmaster.ksh)
Module Name |
export_itemmaster.ksh |
Description |
Extraction of item data |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS258 |
Wrapper Script |
rmswrap_shell_out.ksh |
Design Overview
This batch job will extract new, updated and deleted Merchandising item master information into a flat file.
Data to be extracted will be pulled off from the item export information, item export staging and the main item tables.
-
The mode (full vs. delta) will be an input parameter for this new batch. The mode will allow a full extract (all approved, sellable items in Merchandising) as well as delta processing (all approved, sellable item changes in the main item table since the last export) of data.
-
A threading indicator parameter should be passed. Passing 'Y' means a thread number (1-20) will be passed in. Passing 'N' means no thread number will be passed in and the program will use a default thread number.
-
In full mode, normal operation will produce both a corporate level file and files for all stores. An optional input parameter will also allow the program to produce a location level file for a specified store.
-
In delta mode, the only option is to produce corporate level files. Item header files at the store level will be created in the export_itemloc.ksh for delta mode.
-
The store specific file will also include UPC items. To determine which UPC Items to include, the store where the UPC's parent and/or grandparent item is ranged should be taken into consideration.
-
The flat files that will be created will now be pipe delimited.
Item Master Publication API (BDI_ItemHdr_Fnd_PF_From_RMS_JOB)
This section describes the Item Master Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Item Master information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI calls a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API is in the form of a PLSQL function inside a PLSQL package.
Package Impact
This section describes the package impact.
Bulk Interface Module
Filename: bdiitemb.pls
BDI_ITEM_SQL.ITEM_MASTER_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Item Master table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Item Supplier Country Dimensions Publication API (BDI_ItSupCtryDim_Fnd_PF_From_RMS_JOB)
This section describes the Item Supplier Country Dim Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Item Supplier Country Dim information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdiitemb.pls
BDI_ITEM_SQL.ITEM_SUP_CTY_DIM_UP (O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising ITEM_SUPP_COUNTRY_DIM table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Item Supplier Country Publication API (BDI_ItSupCtry_Fnd_PF_From_RMS_JOB)
This section describes the Item Supplier Country Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Item supplier country information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: Filename: bdiitemb.pls
BDI_ITEM_SQL.ITEM_SUPP_COUNTRY_UP (O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising ITEM_SUPP_COUNTRY table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Item Supplier Manufacturing Country Publication API (BDI_ItSupManCtry_Fnd_PF_From_RMS_JOB)
This section describes the Item Supplier Manufacturing Country Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Item Supplier Manufacturing Country information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdiitemb.pls
BDI_ITEM_SQL.ITEM_SUP_MAN_CTY_UP (O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising ITEM_SUPP_MANU_COUNTRY table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Item Supplier Publication API (BDI_ItemSupp_Fnd_PF_From_RMS_JOB)
This section describes the Item Supplier Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Item supplier information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdiitemb.pls
BDI_ITEM_SQL.ITEM_SUPPLIER_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising ITEM_SUPPLIER table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Item Supplier UOM Publication API (BDI_ItemSuppUom_Fnd_PF_From_RMS_JOB)
This section describes the Item Supplier UOM Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Item supplier UOM information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdiitemb.pls
BDI_ITEM_SQL.ITEM_SUPP_UOM_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising ITEM_SUPP_UOM table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Item VAT Rates Export (export_itemvat.ksh)
Module Name |
export_itemvat.ksh |
Description |
Extraction of vat item data. |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS259 |
Wrapper Script |
rmswrap_shell_out.ksh |
Design Overview
This batch job will extract new, updated and deleted Merchandising item VAT information into a flat file.
-
This batch supports both a full and delta export of item VAT data.
-
A threading indicator parameter should be passed. Passing 'Y' means a thread number (1-20) will be passed in. Passing 'N' means no thread number will be passed in and the program will use a default thread number.
-
In full mode, normal operation will produce both a corporate level file and files for all stores. An optional input parameter will also allow the program to produce a location level file for a specified store.
-
In full mode for store specific file if store belong to such a vat region, which is exempt (In case of tax type SVAT), then files for that store won't get generated.
-
In delta mode, this will produce both corporate level files and files for all stores the modified items are ranged to and the vat region the store is associated with.
-
In delta mode for store specific file if store belong to such a vat region, which is exempt, then files for that store won't get generated.
-
This will export data only for approved, sellable items.
-
This will export item VAT information from the item export staging and item tables.
-
This should also include the item parent as its own record in the extract.
-
The flat files that will be created will now be pipe delimited.
Pack Item Publication API (BDI_PckitemBrkout_Fnd_PF_From_RMS_JOB)
This section describes the Pack Item Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Pack Item information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdiitemb.pls
BDI_ITEM_SQL.PACK_ITEM_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising PACKITEM table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
POS Configuration Data to 3rd Party POS (poscdnld)
Module Name |
poscdnld.pc |
Description |
Download of POS Configuration Data to 3rd Party POS |
Functional Area |
Integration - 3rd Party POS |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS69 |
Wrapper Script |
rmswrap_out.ksh |
Design Overview
This program downloads POS configuration information from Merchandising to a flat file. This file can be used to load POS and back-office systems.This program (and its related prepost function) should only be run if Merchandising is used to master:
-
Coupon definitions and relationships to items
-
Restrictions on product sales, including but not limited to minimum age of purchaser, time/days when product cannot be sold, tenders that cannot be used to purchase the product, and so on.
Restart/Recovery
The logic unit of work is pos configuration type and pos configuration ID. The commit_max_ctr field should be set to prevent excessive rollback space usage, and to reduce the overhead of file I/O. The recommended commit counter setting is 1000 records (subject to change based on implementation).
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter. |
Integration Contract |
IntCon000063 |
Output File Layout
Table 6-5 Output File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record Type |
Char(5) |
'FHEAD' |
Record Identifier |
Line id |
Number(10) |
0000000001 |
Sequential Line Identifier |
|
File Name |
Char(4) |
'POSC' |
File Identifier |
|
File Date |
Char(14) |
N/A |
Date the file was created in 'YYYYMMDD HHMMSS' format |
|
TCOUP |
Record Type |
Char(5) |
TCOUP |
Record Identifier |
Line id |
Number(10) |
N/A |
Sequential Line Identifier |
|
Coupon id |
Number(6) |
N/A |
N/A |
|
Coupon Desc |
Char(250) |
N/A |
N/A |
|
Currency Code |
Char2(3) |
N/A |
N/A |
|
Max Discount Amount |
Number(20,4) |
N/A |
N/A |
|
Amount |
Number(20,4) |
N/A |
N/A |
|
Percent Ind |
Char(1) |
'N' - Amount 'Y'- Percentage |
N/A |
|
Profit Center |
Char(6) |
N/A |
N/A |
|
Tax Class |
Char(6) |
N/A |
N/A |
|
Export Code |
Char(6) |
N/A |
N/A |
|
Effective Date |
Char(14) |
N/A |
Indicates the first day the coupon can be used in 'YYYYMMDD HHMMSS' format |
|
Expiration Date |
Char(14) |
N/A |
Indicates the day the coupon becomes invalid in 'YYYYMMDD HHMMSS' format |
|
Prompted Ind |
Char(1) |
'Y', 'N' |
This indicator identifies if the cashier should be prompted to ask for a Coupon. |
|
Display Ind |
Char(1) |
'Y', 'N' |
This indicator specifies whether the coupon is displayed in the list of valid coupons on the register. |
|
Status |
Char(1) |
'A','C','D' |
Indicates if the coupon configuration is new, has been changed, or being deleted. |
|
Vendor |
Number(10) |
N/A |
N/A |
|
Vendor Type |
Char(6) |
'AG' - Agent 'AP' - Applicant 'BK' - Bank 'BR' - Broker 'CN' - Coonsignee 'CO' - Consolidator 'FA' - Factory 'FF' - Freight Forwarder 'IM' - Importer 'SU' - Supplier |
N/A |
|
Promotion |
Number(10) |
N/A |
N/A |
|
Coupon Barcode |
Char(20) |
N/A |
N/A |
|
Coupon Max Qty |
Number(6) |
N/A |
N/A |
|
TPRES |
Record Type |
Char(5) |
TPRES |
Record Identifier |
Line id |
Number(10) |
N/A |
Sequential Line Identifier |
|
POS Product Restriction id |
Number(6) |
N/A |
N/A |
|
POS Product Restriction Desc |
Char(120) |
N/A |
N/A |
|
POS Product Restriction Type |
Char(6) |
'PPRT' include: 'STMP' - Food Stamp 'MNAG' - Minimum Age 'CNDP' -Container Deposit 'CNVL' - Container Redemption Value 'DTDR' - Day/Time/Date Restriction 'TENT' - Tender Type 'NDSC' - Non-Discountable 'RTRN' - Returnable 'QLMT' - Quantity Limit |
N/A |
|
Effective Date |
Char(14) |
N/A |
Date the product restriction is first effective in 'YYYYMMDD HHMMSS' format |
|
Currency Code |
Char(3) |
N/A |
N/A |
|
Product Restriction Amount |
Number(20,4) |
N/A |
N/A |
|
Age Minimum |
Number(2) |
N/A |
N/A |
|
Date Restriction |
Char(14) |
N/A |
Date on which a specified product restriction is applied in 'YYYYMMDD HHMMSS' format |
|
Before Time Restriction |
Char(6) |
N/A |
N/A |
|
After Time Restriction |
Char(6) |
N/A |
N/A |
|
Day Restriction |
Char(6) |
N/A |
N/A |
|
Max Qty Amount |
Number(12,4) |
N/A |
N/A |
|
Tender Type Group |
Char(6) |
'CASH' - Cash, 'CHECK' - Check, 'CCARD' - Credit, 'COUPON' - Coupon, 'LOTTRY' - Lottery, 'FSTAMP' - Food Stamp, 'DCARD' - Debit Card, 'MORDER' - Money Order 'VOUCH' - Voucher 'ERR' - Error, 'SOCASS' - Social Assistance, 'TERM' - Termination Record, 'DRIVEO' - Drive Off, 'EBS' - Electronic Benefits ( Food Stamps) |
N/A |
|
Status |
Char(1) |
'A','C','D' |
Indicates if the product restriction configuration is new, has been changed, or being deleted. |
|
TSTOR |
Record Type |
Char(5) |
'TSTOR' |
N/A |
Line id |
Number(10) |
N/A |
N/A |
|
Store |
Number(10) |
N/A |
N/A |
|
Status |
Char(1) |
'A' - Add 'D' - Delete 'C' - Change |
N/A |
|
TITEM |
Record Type |
Char(5) |
TITEM |
Record Identifier |
Line id |
Number(10) |
N/A |
Sequential Line Identifier |
|
Item |
Char(25) |
N/A |
Left-Justified Item Identifier |
|
Status |
Char(1) |
'A' - Add 'D' - Delete 'C' - Change |
Indicates the item's status at the POS. Overlays of items as a result of a change to the merch criteria will have a ‘C' status. |
|
FTAIL |
Record Type |
Char(5) |
FTAIL |
Marks end of file |
Line id |
Number(10) |
N/A |
Total number of lines in file |
|
Number of transactions |
Number(10) |
N/A |
Number of transactions in file |
Price History Publication API (BDI_PriceHist_Fnd_PF_From_RMS_JOB)
This section describes the Price History Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Price History positions from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdifoundations/b.pls
BDI_FOUNDATION_SQL.PRICE_HIST_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Price History tables.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Related Items Export (export_relitem.ksh)
Module Name |
export_relitem.ksh |
Description |
Extraction of related item data |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS262 |
Wrapper Script |
rmswrap_shell_out.ksh |
Design Overview
This batch job will extract new, updated and deleted Merchandising related items information into a flat file.
-
This batch will support both a full and delta export of related item data.
-
A threading indicator parameter should be passed. Passing 'Y' means a thread number (1-20) will be passed in. Passing 'N' means no thread number will be passed in and the program will use a default thread number.
-
In full mode, normal operation will produce both a corporate level files and files for all stores. An optional input parameter will also allow the program to produce location level files for a specified store.
-
In delta mode, this will produce both corporate level files and files for all stores the modified data are ranged to.
-
This will export data only for approved, sellable items.
-
This will export item related item information from the related item export staging and related item tables.
-
Two types of flat files will be created for this extract - one for the related item header information and one for the related item detail information.
-
When creating the location level files, ensure that both items (the main item and related item) are ranged in the location.
-
The flat files that will be created will now be pipe delimited.
I/O Specification
Integration Type |
Extract from Merchandising |
File Name |
relitemhead_date_corp_[full/delta]_[#ofLines].dat relitemhead_date_[Location]_[full/delta]_[#ofLines].dat relitemdet_date_corp_[full/delta]_[#ofLines].dat relitemdet_date_[Location]_[full/delta]_[#ofLines].dat |
Integration Contract |
IntCon000210 IntCon000211 |
Related Item Publication API (BDI_RelatedItem_Fnd_PF_From_RMS_JOB)
This section describes the Related Item Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Related Items from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdiitemb.pls
BDI_ITEM_SQL.REL_ITEM_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound tables that reside in the BDI_RMS_INT_SCHEMA schema. These outbound tables are loaded with records from the Merchandising Related Item head and detail tables.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
UDA Item Date Publication API (BDI_UdaItemDate_Fnd_PF_From_RMS_JOB)
This section describes the UDA Item Date Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Code Head information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdiitemb.pls
BDI_ITEM_SQL.UDA_ITEM_DATE_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising UDA Item Date table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
UDA Item FF Publication API (BDI_UdaItemFF_Fnd_PF_From_RMS_JOB)
This section describes the UDA Item FF Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Code Head information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdiitemb.pls
BDI_ITEM_SQL.UDA_ITEM_FF_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising UDA Item FF table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
UDA Item LOV Publication API (BDI_UdaItemLov_Fnd_From_RMS_JOB)
This section describes the UDA Item LOV Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Code Head information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdiitemb.pls
BDI_ITEM_SQL.UDA_ITEM_LOV_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising UDA Item LOV table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.A database commit is issued, and the control Id is returned by the API.
Financials
Merchandising stages General Ledger (GL) data for subsequent upload into a financial system. A set of batch processes gather and organize the data before using it to populate the staging table, STG_FIF_GL_DATA.
For more information about how data moves from these staging tables to the General Ledger of a financial application and other integration between Merchandising and financial applications, see Oracle Retail Financial Integration for Oracle Retail Merchandise Operations Management and Oracle E-Business Suite Financials Implementation Guide.
The following scheduled outbound integrations are included in this functional area:
Daily or Weekly Donwload of Stock Ledger Data (stlgdnld)
Module Name |
stlgdnld.pc |
Description |
Weekly or Historical Download of Stock Ledger Data |
Functional Area |
Stock Ledger |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS17 |
Wrapper Script |
batch_stlgdnld.ksh |
Design Overview
This program extracts stock ledger data at the item level. The program can extract data for a historic period or for the most current complete week. The program accepts an input file that determines whether the extract is a historic extract or a weekly extract.
This program is often used in integration with RPAS applications.
Restart/Recovery
The logical unit of work for this program is set at item, location type, location and date. Threading is done by dept using the v_restart_dept view to thread properly.
The changes will be posted when the commit_max_ctr value is reached. The commit_max_ctr field should be set to prevent excessive rollback space usage, and to reduce the overhead of file I/O. The value of the counter is subject to change based on implementation.
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
The input filename is a runtime parameter. The output filename is hardcoded to stkldgr%d.dat where %d is substituted with the domain id. Each run of the program can produce multiple output files, one for each department. Additional input parameters are defined in the input file |
Integratin Contract |
IntCon000034 (output file) |
Input File Layout
Table 6-6 Input File Layout
Field Name | Field Type | Default Value | Description |
---|---|---|---|
Task Indicator |
Char(1) |
N/A |
Task Indicator. Valid values are 'H' - historical, 'W' - weekly |
From Date |
Char(8) |
N/A |
From Date in 'YYYYMMDD' format |
To Date |
Char(8) |
N/A |
To Date in 'YYYYMMDD' format |
Output File Layout
Table 6-7 Output File Layout
Field Name | Field Type | Default Value | Description |
---|---|---|---|
Item |
Char(25) |
N/A |
Item number |
Location Type |
Char(1) |
N/A |
Location Type Valid values are 'S','W' |
Location |
Number(20) |
N/A |
Location Number |
Eow_date |
Char(8) |
N/A |
End of Week date in 'YYYYMMDD' format |
Update_Ind |
Char(1) |
N/A |
Update Indicator Valid values are 'I ' and 'U' |
Regular_sales_retail |
Number(25,4) |
N/A |
Regular sales value (retail) |
Regular_sales_cost |
Number(25,4) |
N/A |
Regular sales value (cost) |
Regular_sales_units |
Number(17,4) |
N/A |
Regular sales value (units) |
Promo_sales_retail |
Number(25,4) |
N/A |
Promo sales value (retail) |
Promo_sales_cost |
Number(25,4) |
N/A |
Promo sales value (cost) |
Promo_sales_units |
Number(17,4) |
N/A |
Promo sales value (units) |
Clear_sales_retail |
Number(25,4) |
N/A |
Clearance sales value (retail) |
Clear_sales_cost |
Number(25,4) |
N/A |
Clearance sales value (cost) |
Clear_sales_units |
Number(17,4) |
N/A |
Clearance sales value (units) |
Sales_retail_excluding_vat |
Number(25,4) |
N/A |
Sales value excluding vat (retail) |
Custom_returns_retail |
Number(25,4) |
N/A |
Custom returns value (retail) |
Custom_returns_cost |
Number(25,4) |
N/A |
Custom returns value (cost) |
Custom_returns_units |
Number(17,4) |
N/A |
Custom returns value (units) |
Rtv_retail |
Number(25,4) |
N/A |
Return to Vendor value (retail) |
Rtv_cost |
Number(25,4) |
N/A |
Return to Vendor value (cost) |
Rtv_units |
Number(17,4) |
N/A |
Return to Vendor value (units) |
Reclass_in_retail |
Number(25,4) |
N/A |
Reclass In value (retail) |
Reclass_in_cost |
Number(25,4) |
N/A |
Reclass In value (cost) |
Reclass_in_units |
Number(17,4) |
N/A |
Reclass In value (units) |
Reclass_out_retail |
Number(25,4) |
N/A |
Reclass Out value (retail) |
Reclass_out_cost |
Number(25,4) |
N/A |
Reclass Out value (cost) |
Reclass_out_units |
Number(17,4) |
N/A |
Reclass Out value (units) |
Perm_markdown_value |
Number(25,4) |
N/A |
Permanent markdown value (retail) |
Prom_markdown_value |
Number(25,4) |
N/A |
Promotion markdown value (retail) |
Clear_markdown_value |
Number(25,4) |
N/A |
Clearance markdown value (retail) |
Markdown_cancel_value |
Number(25,4) |
N/A |
Markdown cancel value |
Markup_value |
Number(25,4) |
N/A |
Markup value |
Markup_cancel_value |
Number(25,4) |
N/A |
Markup cancel value |
Stock_adj_retail |
Number(25,4) |
N/A |
Stock adjustment value (retail) |
Stock_adj_cost |
Number(25,4) |
N/A |
Stock adjustment value (cost) |
Stock_adj_units |
Number(17,4) |
N/A |
Stock adjustment value (units) |
Received_retail |
Number(25,4) |
N/A |
Received value (retail) |
Received_cost |
Number(25,4) |
N/A |
Received value (cost) |
Received_units |
Number(17,4) |
N/A |
Received value (units) |
Tsf_in_retail |
Number(25,4) |
N/A |
Transfer In value (retail) |
Tsf_in_cost |
Number(25,4) |
N/A |
Transfer In value (cost) |
Tsf_in_units |
Number(17,4) |
N/A |
Transfer In value (units) |
Tsf_out_retail |
Number(25,4) |
N/A |
Transfer Out value (retail) |
Tsf_out_cost |
Number(25,4) |
N/A |
Transfer Out value (cost) |
Tsf_out_units |
Number(17,4) |
N/A |
Transfer Out value (units) |
Freight_cost |
Number(25,4) |
N/A |
Freight cost |
Employee_disc_retail |
Number(25,4) |
N/A |
Employee disc (retail) |
Cost_variance |
Number(25,4) |
N/A |
Cost variance |
Wkroom_other_cost_sales |
Number(25,4) |
N/A |
Wkroom other sales (cost) |
Cash_disc_retail |
Number(25,4) |
N/A |
Cash disc (retail) |
Freight_claim_retail |
Number(25,4) |
N/A |
Freight Claim (retail) |
Freight_claim_cost |
Number(25,4) |
N/A |
Freight Claim (cost) |
Freight_claim_units |
Number(25,4) |
N/A |
Freight Claim (Units) |
Stock_adj_cogs_retail |
Number(25,4) |
N/A |
Stock Adjust COGS (retail) |
Stock_adj_cogs_cost |
Number(25,4) |
N/A |
Stock Adjust COGS (cost) |
Stock_adj_cogs_units |
Number(25,4) |
N/A |
Stock Adjust COGS (Units) |
Intercompany_in_retail |
Number(25,4) |
N/A |
Intercompany In value (retail) |
Intercompany_in_cost |
Number(25,4) |
N/A |
Intercompany In value (cost) |
Intercompany_in_units |
Number(25,4) |
N/A |
Intercompany In value (units) |
Intercompany_out_retail |
Number(25,4) |
N/A |
Intercompany Out value (retail) |
Intercompany_out_cost |
Number(25,4) |
N/A |
Intercompany Out value (cost) |
Intercompany_out_units |
Number(25,4) |
N/A |
Intercompany Out value (units) |
Intercompany_markup |
Number(25,4) |
N/A |
Intercompany Markup |
Intercompany_markup_units |
Number(25,4) |
N/A |
Intercompany Markup (units) |
Intercompany_markdown |
Number(25,4) |
N/A |
Intercompany Markdown |
Intercompany_markdown_units |
Number(25,4) |
N/A |
Intercompany Markdown (units) |
Wo_activity_upd_inv |
Number(25,4) |
N/A |
Work Order Activity - Update Inventory (cost) |
Wo_activity_upd_inv_units |
Number(25,4) |
N/A |
Work Order Activity - Update Inventory (units) |
Wo_activity_post_fin |
Number(25,4) |
N/A |
Work Order Activity - Post to Financials (retail) |
Wo_activity_post_fin_units |
Number(25,4) |
N/A |
Work Order Activity - Post to Financials (units) |
Finance General Ledger to RFI (BDI_RFI_FinGenLdgr_Tx_PF_From_RMS_JOB)
Module Name |
BDI_RFI_FinGenLdgr_Tx_PF_From_RMS_JOB |
Description |
Extracts financial general ledger to RFI |
Functional Area |
Finance |
Module Type |
Integration |
Module Technology |
BDI Job |
Catalog ID |
N/A |
Runtime Parameters |
FinGenLdgr_Tx_ProcessFlow_From_RMS FinGenLdgr_Tx_Extractor |
Design Overview
This API extracts staged data from Merchandising and Sales Audit and transfers it to the General Ledger inbound staging tables. To accomplish this data transfer, BDI will call a Merchandising owned API that will pull data from RMS and deliver these to the BDI integration layer.
This integration is applicable when using Oracle Retail Financial Integration (RFI) to supported financial solutions. For more information on RFI, see the ORFI Implementation Guide, as part of the documentation for Oracle Retail Integration Cloud Service.
Fixed Deal Income (dealfinc)
Module Name |
dealfinc.pc |
Description |
Calculation & Interface of Fixed Deal Income for General Ledger |
Functional Area |
Integration - General Ledger |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS65 |
Wrapper Script |
rmswrap_multi.ksh |
Design Overview
This module writes to the STG_FIF_GL_DATA financial staging table to perform stock ledger processing for fixed deals. It splits deal income over all dept/class/subclass locations on the deal. This prorated income is written to the general ledger under a suitable cost center mapping.
Restart/Recovery
The logical unit of work for this program is a DEAL_ID. The database commit takes place when number of deal records processed is equal to the commit max counter in the restart control table.
Franchise Billing Extract (wfbillex.ksh)
Module Name |
wfbillex.ksh |
Description |
Franchise Billing Extract |
Functional Area |
Franchise Management |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS155 |
Wrapper Script |
rmswrap_shell.ksh |
Design Overview
The purpose of this shell script module is to fetch all billing information for Franchise sale and return transactions and write these to an output file for integration with an external financial application that manages billing. A file is generated for each customer location (store)/day.
The format of the generated file is based on a run time parameter:
-
If no parameter is passed or if the value 1 is used, the previously existing format (refer Output File Layout Format 1) will be generated.
-
If the value 2 (or greater than 2) is passed, the new file format (refer Output File Layout Format 2) will be generated.
Restart/Recovery
The logical unit of work for this module is defined as the customer location (store). Only one commit will be done for a customer location that has been completely processed. The WFBX formatted output file will be created with a temporary name and renamed just before a customer location commit. In case of failure, all work done will be rolled back.
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
WFBX_<store>_<SYSDATE> |
Integration Contract |
IntCon000110 |
Output File Layout
Table 6-8 Output File Layout Format 1
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record descriptor |
Char(5) |
FHEAD |
Identifies the file record type |
File Line Id |
Char(10) |
Sequential file line number |
||
File type definition |
Char(4) |
WFBX |
Identifies the file type |
|
File Create Date |
Char(14) |
File Create Date in YYYYMMDDHHMMSS format |
||
THEAD |
Record descriptor |
Char(5) |
THEAD |
Identifies the file record type |
File Line Id |
Char(10) |
Sequential file line number |
||
Customer Location |
Number(10) |
Franchise store number |
||
Customer Order Reference Number |
Char(20) |
Reference number provided by the franchise customer |
||
Franchise Order Number |
Number(10) |
Franchise Order Number |
||
Transaction Type |
Char(6) |
SALES or RETURN |
||
RMA Number |
Number(10) |
Return Merchandise Authorization Number for the return |
||
Order Return Date |
Number(8) |
Order return date for Return transaction type or Order date for Sale transaction type in YYYYMMDD format |
||
Shipment Date |
Number(8) |
Date on which the item was shipped to the franchise location or returned to the retailer |
||
TDETL |
Record descriptor |
Char(5) |
TDETL |
Identifies the file record type |
File Line Id |
Char(10) |
Sequential file line number |
||
Item |
Char(25) |
Item sequence number |
||
Department |
Number(4) |
Department number of the item |
||
Class |
Number(4) |
Class number of the item |
||
Subclass |
Char(4) |
Subclass number of the item |
||
Order Return Quantity |
Number(12) |
Return quantity with 4 implied decimal places |
||
Order Return Quantity UOM |
Char(4) |
Return quantity unit of measure |
||
Order Return Cost |
Number(20) |
Return cost for Return transaction type or Customer cost for Sale transaction type. For both it is the per-unit cost |
||
Freight Cost |
Number(20) |
Freight associated to the franchise order |
||
Return Restocking Fee |
Number(20) |
Unit restocking fee charged for received items |
||
VAT Code |
Char(6) |
VAT code for the item |
||
VAT Rate |
Number(20) |
VAT rate associated to the VAT code for the item |
||
Other Order Charges |
Number(20) |
Other charges for the item |
||
TTAIL |
Record descriptor |
Char(5) |
TTAIL |
Identifies the file record type |
File Line Id |
Char(10) |
Sequential file line number |
||
Tran Record Counter |
Number(6) |
Number of TDETL records in this transaction set |
||
FTAIL |
Record descriptor |
Char(5) |
FTAIL |
Identifies the file record type |
File Line Id |
Number(10) |
Sequential file line number |
||
File Record counter |
Number(10) |
Number of records/transactions processed in current file (only records between head & tail) |
Table 6-9 Output File Layout Format 2
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record descriptor |
Char(5) |
FHEAD |
Identifies the file record type |
File Line Id |
Char(10) |
Sequential file line number |
||
File type definition |
Char(4) |
WFBX |
Identifies the file type |
|
File Create Date |
Char(14) |
File Create Date in YYYYMMDDHHMMSS format |
||
Version No. |
Char(2) |
02 |
Identifies the file format version |
|
THEAD |
Record descriptor |
Char(5) |
THEAD |
Identifies the file record type |
File Line Id |
Char(10) |
Sequential file line number |
||
Customer Location |
Number(10) |
Franchise store number |
||
Customer Order Reference Number |
Char(20) |
Reference number provided by the franchise customer |
||
Franchise Order Number |
Number(10) |
Franchise Order Number |
||
Transaction Type |
Char(6) |
SALES or RETURN |
||
RMA Number |
Number(10) |
Return Merchandise Authorization Number for the return |
||
Order Return Date |
Number(8) |
Order return date for Return transaction type or Order date for Sale transaction type in YYYYMMDD format |
||
Shipment Date |
Number(8) |
Date on which the item was shipped to the franchise location or returned to the retailer |
||
TDETL |
Record descriptor |
Char(5) |
TDETL |
Identifies the file record type |
File Line Id |
Char(10) |
Sequential file line number |
||
Item |
Char(25) |
Item sequence number |
||
Department |
Number(4) |
Department number of the item |
||
Class |
Number(4) |
Class number of the item |
||
Subclass |
Char(4) |
Subclass number of the item |
||
Order Return Quantity |
Number(12) |
Return quantity with 4 implied decimal places |
||
Order Return Quantity UOM |
Char(4) |
Return quantity unit of measure |
||
Order Return Cost |
Number(20) |
Return cost for Return transaction type or Customer cost for Sale transaction type. For both it is the per-unit cost |
||
Freight Cost |
Number(20) |
Freight associated to the franchise order |
||
Return Restocking Fee |
Number(20) |
Unit restocking fee charged for received items |
||
VAT Code |
Char(6) |
VAT code for the item |
||
VAT Rate |
Number(20) |
VAT rate associated to the VAT code for the item |
||
Other Order Charges |
Number(20) |
Other charges for the item |
||
Uom Type |
Char(4) |
Uom Type fetched from GTS tax engine to be considered when tax is in value |
||
Uom Value |
Number(20) |
UOM value fetched from GTS tax engine to be considered when tax is in value. Having 10 places of decimal digits. |
||
Uom Tax Value Per Unit |
Number(20) |
UOM tax value per unit fetched from GTS tax engine to be considered when tax is in value. Having 10 places of decimal digits. |
||
TTAIL |
Record descriptor |
Char(5) |
TTAIL |
Identifies the file record type |
File Line Id |
Char(10) |
Sequential file line number |
||
Tran Record Counter |
Number(6) |
Number of TDETL records in this transaction set |
||
FTAIL |
Record descriptor |
Char(5) |
FTAIL |
Identifies the file record type |
File Line Id |
Number(10) |
Sequential file line number |
||
File Record counter |
Number(10) |
Number of records/transactions processed in current file (only records between head & tail) |
Item/Location Daily Stock Ledger Transactions (fifgldn1)
Module Name |
fifgldn1.pc |
Description |
Interface to General Ledger of Item/Loc Level Transactions |
Functional Area |
General Ledger |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS66 |
Wrapper Script |
rmswrap_multi.ksh |
Design Overview
This program extracts the detailed stock ledger information for certain transaction types on a daily basis in order to bridge the information to an interfaced financial application. The program reads from the IF_TRAN_DATA table for each transaction type/amount type and posts it to the Oracle Retail General Ledger staging table at the SKU detail level.
If transactions exist for which GL cross mappings do not exist, these will be logged in TRAN_DATA_ERRORS and a notification will be sent to the Finance Analyst user indicating that unmapped transactions exist. The TRAN_DATA_ERRORS table is available through the Data Access Schema, enabling users to view the errors and create the missing mappings. The fifgldn1 module will attempt to reprocess records from TRAN_DATA_ERRORS if mappings have been created. During the month-end processing run, if unmapped transactions still exist they will be posted into the clearing accounts as outlined below:
-
The cost value of the transaction will be posted into the Credit Clearance account [Credit Clearance Segment 1-10] associated with the location's set of books.
-
The cost value of the transaction will be posted into the Debit Clearance account [Debit Clearance Segment 1-10] associated with the location's set of books.
-
The retail value of the transaction will be posted into the Credit Clearance account [Credit Clearance Segment 1-10] associated with the location's set of books.
-
The retail value of the transaction will be posted into the Debit Clearance account [Debit Clearance Segment 1-10] associated with the location's set of books.
The fifgldn1 module will fail during month-end processing if unmapped transactions exist and clearance accounts haven't been defined.
Restart/Recovery
The logical unit of work is department/class/subclass. The batch is multithreaded using the restart department view.
Monthly Stock Ledger Transactions (fifgldn3)
Module Name |
fifgldn3.pc |
Description |
General Ledger Interface 3 |
Functional Area |
Interface to General Ledger of Month Level Information |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS68 |
Wrapper Script |
rmswrap_multi.ksh |
Design Overview
This program summarizes stock ledger data from the monthly stock ledger table based on the level of information required and writes it to the financial general ledger staging table. The transactions extracted are determined by the CODE_TYPE 'GLRT' (general ledger rolled transactions). Written information is then sent to the financial application. Stock ledger information may be rolled-up at department, class or subclass level. The level at which information is rolled-up to is determined by the system parameter GL_ROLLUP.
The fifgldn3 module is scheduled to run monthly and operates off both the TRAN_DATA and MONTH_DATA tables. If the module encounters an unmapped transaction, depending on whether the source of the unmapped transaction is TRAN_DATA or MONTH_DATA, the transaction will be logged into TRAN_DATA_ERRORS or MONTH_DATA_ERRORS tables, respectively. If clearing accounts have been defined, these unmapped transactions will be posted into the clearing accounts as outlined below:
-
The cost value of the transaction will be posted into the Credit Clearance account [Credit Clearance Segment 1-10] associated with the location's set of books.
-
The cost value of the transaction will be posted into the Debit Clearance account [Debit Clearance Segment 1-10] associated with the location's set of books.
-
The retail value of the transaction will be posted into the Credit Clearance account [Credit Clearance Segment 1-10] associated with the location's set of books.
-
The retail value of the transaction will be posted into the Debit Clearance account [Debit Clearance Segment 1-10] associated with the location's set of books.
A notification will be sent to the Finance Analyst user indicating that unmapped transactions exist and whether the postings to the clearance accounts have occurred. The fifgldn3 module will fail during month-end processing if unmapped transactions exist and clearance accounts haven't been defined.
Restart/Recovery
The logical unit of work is dependent on the level of rollup defined in the system options table. It can be department (department rollup), department/class (class rollup) or department/class/subclass (subclass rollup). The batch is multithreaded using the restart all locations view.
Open to Buy Download Stock Ledger (otbdlsal)
Module Name |
otbdlsal.pc |
Description |
Open To Buy Download Stock Ledger |
Functional Area |
OTB - Stock Ledger to Planning System Interface |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS16 |
Wrapper Script |
Rmswrap_out.ksh |
Design Overview
This module will sum stock ledger data from the DAILY_DATA table and opening stock information from the WEEK_DATA table across the current week, grouping by department, class, subclass, location and date, and export the data to a flat file for use by an outside planning system.
Restart/Recovery
The logical unit of work for the OTBDLSAL module is department, class, subclass and location. The commit_max_ctr field should be set to prevent excessive rollback space usage, and to reduce the overhead of the file I/O. The recommended commit counter setting is 10000 records. Each time the record counter equals the maximum recommended commit number, an application image array record will be written to the restart_start_array for restart/recovery if a fatal error occurs.
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
OTB - Stock Ledger to Planning System Interface IntCon00030 |
Output File Format
Table 6-10 File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
File Line Sequence Number |
Number(10) |
0000000001 |
Keeps track of the record's position in the file by line number |
|
File Type Definition |
Char(4) |
STKE |
Identifies file as Stock Ledger Export |
|
File Create Date |
Char(14) |
vdate |
Date file was written by batch program in YYYYMMDD format. Remaining six characters are blank. |
|
FDETL |
File Type Record Descriptor |
Char(5) |
FDETL |
Identifies file record type |
File Line Sequence Number |
Number(10) |
line number in file |
Keeps track of the record's position in the file by line number |
|
Transaction Set Control Number |
Number(14) |
sequence number |
Used to force unique file check |
|
Department |
Number(4) |
N/A |
The ID number of a department |
|
Class |
Number(4) |
N/A |
The ID number of a class within the department given |
|
Subclass |
Number(4) |
N/A |
The ID number of a subclass within the class given |
|
Loc_type |
Char(1) |
N/A |
The type of the location from which stock ledger data was collected |
|
Location |
Number(10) |
N/A |
The location from which stock ledger data was collected |
|
Half No. |
Number(5) |
N/A |
The half number for this stock ledger data |
|
Month No. |
Number(2) |
N/A |
The month number in the half for this stock ledger data |
|
Week No. |
Number(2) |
N/A |
The week number in the month for this stock ledger data |
|
Open Stock Retail |
Number(20,4) |
N/A |
The retail opening stock from the week_data table *10000 (implied 4 decimal places) for this stock ledger period |
|
Open Stock Cost |
Number(20,4) |
N/A |
The cost opening stock from the week_data table *10000 (implied 4 decimal places) for this stock ledger period |
|
Stock Adjustments Retail |
Number(20,4) |
N/A |
The retail stock adjustments summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Stock Adjustments Cost |
Number(20,4) |
N/A |
The cost stock adjustments summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Purchases Retail |
Number(20,4) |
N/A |
The retail purchases summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Purchases Cost |
Number(20,4) |
N/A |
The cost purchases summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
RTV Retail |
Number(20,4) |
N/A |
The retail return to vendor amount summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
RTV Cost |
Number(20,4) |
N/A |
The cost return to vendor amount summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Freight Cost |
Number(20,4) |
N/A |
The freight cost summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Net Sales Retail |
Number(20,4) |
N/A |
The retail net sales summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Net Sales Cost |
Number(20,4) |
N/A |
The cost net sales summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Returns Retail |
Number(20,4) |
N/A |
The retail returns amount summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Returns Cost |
Number(20,4) |
N/A |
The cost returns amount summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Promotional Markdowns Retail |
Number(20,4) |
N/A |
The retail promotional markdowns summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Markdown Cancellations Retail |
Number(20,4) |
N/A |
The retail markdown cancellations summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Employee Discount Retail |
Number(20,4) |
N/A |
The retail employee discounts amount summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Workroom Amount |
Number(20,4) |
N/A |
The workroom amount summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Cash Discount Amount |
Number(20,4) |
N/A |
The cash discounts amount summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Sales Units |
Number(12,4) |
N/A |
The sales units summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Markups Retail |
Number(20,4) |
N/A |
The retail markups summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Markup Cancellations Retail |
Number(20,4) |
N/A |
The retail markup cancellations summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Clearance Markdowns Retail |
Number(20,4) |
N/A |
The retail clearance markdowns summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Permanent Markdowns Retail |
Number(20,4) |
N/A |
The retail permanent markdowns summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Freight Claim Retail |
Number(20,4) |
N/A |
The retail freight claim summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Freight Claim Cost |
Number(20,4) |
N/A |
The cost freight claim summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Stock Adjust Cost of Goods Sold (COGS) Retail |
Number(20,4) |
N/A |
The retail stock adjust COGS summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Stock Adjust Cost of Goods Sold (COGS) Cost |
Number(20,4) |
N/A |
The cost stock adjust COGS summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Inter-company In Retail |
Number(20,4) |
N/A |
The Inter-company In retail summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Inter-company In Cost |
Number(20,4) |
N/A |
The Inter-company In cost summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Inter-company Out Retail |
Number(20,4) |
N/A |
The Inter-company Out Retail summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Inter-company Out Cost |
Number(20,4) |
N/A |
The Inter-company Out Cost summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Inter-company Markup |
Number(20,4) |
N/A |
The Inter-company Markup summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Inter-company Markdown |
Number(20,4) |
N/A |
The Inter-company Markdown summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Work Order Activity Update Inventory |
Number(20,4) |
N/A |
The Work Order Activity Update Inventory summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
Work Order Activity Post Finishing |
Number(20,4) |
N/A |
The Work Order Activity Post Finishing summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period |
|
FTAIL |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Sequence Number |
Number(10) |
N/A |
Keeps track of the record's position in the file by line number |
|
Control Number File Line Count |
Number(10) |
N/A |
Total number of all transaction lines, not including file header and trailer |
Rolled Up Daily Stock Ledger Transactions (fifgldn2)
Module Name |
fifgldn2.pc |
Description |
Interface to General Ledger of Rolled Up Transactions |
Functional Area |
Integration - General Ledger |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS67 |
Wrapper Script |
rmswrap_multi.ksh |
Design Overview
This program summarizes stock ledger data from the transaction staging table (IF_TRAN_DATA) based on the level of information required and writes it to the financial general ledger staging table. The transactions extracted are determined by the CODE_TYPE 'GLRT' (General Ledger Rolled Transactions). The written information can then be extracted by the financial applications. Stock ledger information may be rolled-up at department, class or subclass level. The level at which information is rolled-up to is determined by the system parameter GL_ROLLUP.
If transactions exist for which GL cross mappings do not exist, these will be logged in TRAN_DATA_ERRORS and a notification will be sent to the Finance Analyst user indicating that unmapped transactions exist. The TRAN_DATA_ERRORS table is available through the Data Access Schema, enabling users to view the errors and create the missing mappings. The fifgldn2 module will attempt to reprocess records from TRAN_DATA_ERRORS if mappings have been created. During the month-end processing run, if unmapped transactions still exist they will be posted into the clearing accounts as outlined below:
-
The cost value of the transaction will be posted into the Credit Clearance account [Credit Clearance Segment 1-10] associated with the location's set of books.
-
The cost value of the transaction will be posted into the Debit Clearance account [Debit Clearance Segment 1-10] associated with the location's set of books.
-
The retail value of the transaction will be posted into the Credit Clearance account [Credit Clearance Segment 1-10] associated with the location's set of books.
-
The retail value of the transaction will be posted into the Debit Clearance account [Debit Clearance Segment 1-10] associated with the location's set of books.
The fifgldn2 module will fail during month-end processing if unmapped transactions exist and clearance accounts haven't been defined.
Restart/Recovery
The logical unit of work is dependent on the level of rollup defined in the system options table. It can be department (department rollup), department/class (class rollup) or department/class/subclass (subclass rollup). The batch is multithreaded using the restart department view.
Stage G/L Extracts (gl_extract.ksh)
Module Name |
gl_extract.ksh |
Description |
Extraction of General Ledger transaction data from Merchandising and Sales Audit to be interfaced to third party GL/Financial system |
Functional Area |
Integration to General Ledger |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS495 |
Wrapper Script |
rmswrap_shell_out.ksh |
Design Overview
This batch job will extract general ledger transaction data from Sales Audit and Merchandising into a file. Data to be extracted will be pulled off from the STG_FIF_GL_DATA table. Once the data is extracted into the file batch will purge the data from the table.
I/O Specification
Integration Type |
Extract from Merchandising |
File Name |
GL_EXTRACT_[#date].dat |
Integration Contract |
Na |
Output File Layout
The output file is comma delimited with the following fields:
Record Name | Field Name |
---|---|
All records have the same structure |
SET_OF_BOOKS_ID |
ACCOUNTING_DATE |
|
CURRENCY_CODE |
|
STATUS |
|
DATE_CREATED |
|
CREATED_BY |
|
ACTUAL_FLAG |
|
USER_JE_CATEGORY_NAME |
|
USER_JE_SOURCE_NAME |
|
CURRENCY_CONVERSION_DATE |
|
CURRENCY_CONVERSION_TYPE |
|
ACCT_SEGMENT1 |
|
ACCT_SEGMENT2 |
|
ACCT_SEGMENT3 |
|
ACCT_SEGMENT4 |
|
ACCT_SEGMENT5 |
|
ACCT_SEGMENT6 |
|
ACCT_SEGMENT7 |
|
ACCT_SEGMENT8 |
|
ACCT_SEGMENT9 |
|
ACCT_SEGMENT10 |
|
ENTERED_DR_AMOUNT |
|
ENTERED_CR_AMOUNT |
|
TRANSACTION_DATE |
|
REFERENCE1 |
|
REFERENCE2 |
|
REFERENCE3 |
|
REFERENCE4 |
|
REFERENCE5 |
|
ATTRIBUTE1 |
|
ATTRIBUTE2 |
|
ATTRIBUTE3 |
|
ATTRIBUTE4 |
|
ATTRIBUTE5 |
|
ATTRIBUTE6 |
|
PERIOD_NAME |
|
CODE_COMBINATION_ID |
|
PGM_NAME |
|
ACCT_SEGMENT11 |
|
ACCT_SEGMENT12 |
|
ACCT_SEGMENT13 |
|
ACCT_SEGMENT14 |
|
ACCT_SEGMENT15 |
|
ACCT_SEGMENT16 |
|
ACCT_SEGMENT17 |
|
ACCT_SEGMENT18 |
|
ACCT_SEGMENT19 |
|
ACCT_SEGMENT20 |
|
REFERENCE_TRACE_ID |
|
PRIM_CURRENCY_CODE |
|
PRIM_ENTERED_DR_AMOUNT |
|
PRIM_ENTERED_CR_AMOUNT |
|
FIN_GL_SEQ_ID |
|
PROCESSED_FLAG |
Tran Data Publication (BDI_TranData_Tx_PF_From_RMS_EOW_JOB)
This section describes the Tran Data Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of transactional data from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdimfpb.pls
BDI_MFP_SQL.TRAN_DATA_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising transaction tables/views.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Ordering and Inventory
Merchandising publishes purchase order and inventory-related for many other solution areas, including purchase orders, import details, invoices, available inventory, and other inventory related data. This section has been broken down into subsections for:
Purchasing
Merchandising has scheduled integration for the following purchasing related data:
Download Contracts to Suppliers (edidlcon)
Module Name |
edidlcon.pc |
Description |
Download Contracts to Suppliers |
Functional Area |
Contracts |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS45 |
Wrapper Script |
rmswrap_out.ksh |
Design Overview
Contacts are defined in an Merchandising UI that writes to series of contracts database tables. This program is used to send this contract information to vendors. Only approved contracts that are flagged as EDI contracts are processed by this batch program. The output file of this program contains all records for the supplier contract data which are in approved status.
Restart/Recovery
The logical unit of work for this program is set at the contract number. This program processes one contract number at a time.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000011 |
Output File Layout
Table 6-11 edidlcon.pc- File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
File head descriptor |
Char(5) |
FHEAD |
Describes file line type |
Line Number |
Number(10) |
0000000001 |
Sequential file line number |
|
Gentran ID |
Char(4) |
'DNCN' |
Identifies which translation Gentran uses |
|
Current date |
Char(14) |
N/A |
Indicates the date that the file was created in YYYYMMDDHH24MISS format |
|
THEAD |
File head de-scriptor |
Char(5) |
THEAD |
Describes file line type |
Line Number |
Number(10) |
N/A |
Sequential file line number |
|
Transaction Number |
Number(10) |
N/A |
Sequential transaction number |
|
Supplier |
Number(10) |
N/A |
Indicates the supplier associated with the contract |
|
Contract Number |
Number(6) |
N/A |
Indicates the Merchandising contract number |
|
Contract type |
Char(1) |
N/A |
Type of contract. Valid types are A, B, C or D |
|
Department |
Number(4) |
N/A |
Indicates the Merchandising department ID for which the contract applies |
|
Currency code |
Char(3) |
N/A |
Indicates the currency code for the contract |
|
Total contract cost |
Number(20) |
N/A |
Contains the total cost of the contract; includes 4 implied decimal places |
|
TDETL |
File record descriptor |
Char(5) |
TDETL |
Describes file line type |
Line Number |
Number(10) |
N/A |
Sequential file line number |
|
Transaction number |
Number(10) |
N/A |
Sequential transaction number |
|
Item Number Type |
Char(6) |
N/A |
Indicates the type of item number is represented in the file. This corresponds to the item number type defined for items on ITEM_MASTER |
|
Item Number |
Char(25) |
N/A |
Contains the unique ID for the item on the contract |
|
Ref Item Number Type |
Char(6) |
N/A |
Indicates the item number type for the reference number corresponding to the item number |
|
Ref Item Number |
Char(25) |
N/A |
Contains the unique ID for the reference number for the item |
|
Diff1 |
Char(120) |
N/A |
Contains the description of Diff1 for the item |
|
Diff2 |
Char(120) |
N/A |
Contains the description of Diff2 for the item |
|
Diff3 |
Char(120) |
N/A |
Contains the description of Diff3 for the item |
|
Diff4 |
Char(120) |
N/A |
Contains the description of Diff4 for the item |
|
VPN |
Char(30) |
N/A |
Vendor Product Number for the item |
|
Unit cost |
Number(20) |
Contains the cost of the item on the contract with 4 implied decimal places |
||
Ready Date |
Char(14) |
Date on which the items are to be provided by supplier. This field contains only values for contract types of 'A' or 'B' |
||
Ready Quantity |
Number(20) |
Quantity contracted with supplier with 4 implied decimal points. This field contains only values for contract types of 'A' or 'B' |
||
Location Type |
Char(2) |
Indicates the type of location on the contract - either 'ST' (store) or 'WH' (warehouse). This field contains only values for contract types of 'A' or 'B' |
||
Location number |
Number(10) |
Contains a location on the contract. This field contains only values for contract types of 'A' or 'B' |
||
TTAIL |
File Record descriptor |
Char(5) |
TTAIL |
Describes file line type |
Line Number |
Number(10) |
N/A |
Sequential file line number |
|
Transaction number |
Number(10) |
N/A |
Sequential transaction number |
|
FTAIL |
File record descriptor |
Char(5) |
FTAIL |
Marks the end of file |
Line number |
Number(10) |
N/A |
Sequential file line number |
|
Number of lines |
Number(10) |
N/A |
Number of lines in file not counting FHEAD and FTAIL |
Download Current & Future OTB by Subclass (otbdnld)
Module Name |
otbdnld.pc |
Description |
Download Current & Future OTB by Subclass |
Functional Area |
Open To Buy |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS130 |
Wrapper Script |
rmswrap_out.ksh |
Design Overview
This batch program will extract current and future Open to Buy data from the OTB table in Merchandising and export it to a flat file for use by an external planning system. All records with an end of week date greater than or equal to today will be sent.
Restart/Recovery
The logical unit of work for the OTBDNLD module is department, class, subclass, and end-of-week date, with a recommended commit counter setting of 10,000. Each time the record counter equals the maximum recommended commit number, an application image array record will be written to the restart_start_array for restart/recovery if a fatal error occurs.
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000031 |
Output File Layout
Table 6-12 otbdnld.pc - Output File
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
File Type Record Descriptor |
Char (5) |
FHEAD |
Identifies file record type |
File Line Sequence Number |
Number (10) |
N/A |
Keeps track of the record's position in the file by line number |
|
File Type Definition |
Char (4) |
N/A |
Identifies file as ‘OTB Export' |
|
File Create Date |
Char(14) |
N/A |
Date the file was created in YYYYMMDD format. Remaining 6 characters are blank |
|
FDETL |
File record descriptor |
Char(5) |
FDETL |
Identifies file record type |
File Line Sequence Number |
Number (10) |
Keeps track of the record's position in the file by line number |
||
Transaction Set Control Number |
Number(14) |
Used to force unique file check |
||
Department |
Number(4) |
The ID number of a department |
||
Class |
Number(4) |
The ID number of a class within the department given |
||
Subclass |
Number(4) |
The ID number of a subclass within the class given |
||
EOW Date |
Date |
The end of week date for the budgeted period. Format is 'YYYYMMDDHHMMSS' |
||
Week number |
Number(2) |
The week number in the month for the budgeted period |
||
Month number |
Number(2) |
The month number in the half for the budgeted period |
||
Half number |
Number(5) |
The half number for the budgeted period |
||
Cancel Amount |
Number(20) |
The total amount cancelled from orders of all order type for the budgeted period; value includes 4 implied decimal places |
||
N Approved Amount |
Number(20) |
The amount of approved non-basic (order type N/B) orders for the budgeted period; value includes 4 implied decimal places |
||
N Receipts Amount |
Number(20) |
The amount of non-basic (order type N/B) orders due in the budgeted period that have been received; value includes 4 implied decimal places |
||
B Approved Amount |
Number(20) |
The amount of approved buyer-replenished basic (order type BRB) orders for the budgeted period; value includes 4 implied decimal places |
||
B Receipts Amount |
Number(20) |
The amount of buyer-replenished basic (order type BRB) orders due in the budgeted period that have been received; value includes 4 implied decimal places |
||
A Approved Amount |
Number(20) |
The amount of approved auto-replenished basic (order type ARB) orders for the budgeted period; value includes 4 implied decimal places |
||
A Receipts Amount |
Number(20) |
The amount of auto-replenihed basic (order type ARB) orders due in the budgeted period that have been received; value includes 4 implied decimal places |
||
FTAIL |
File record descriptor |
Char (5) |
FTAIL |
Identifies file record type |
File Line Sequence Number |
Number (10) |
Keeps track of the record's position in the file by line number |
||
Number of lines |
Number (10) |
Total number of all transaction lines, not including file header and trailer |
Download Purchase Orders to Suppliers (edidlord)
Module Name |
edidlord.pc |
Description |
Download of Purchase Order from Merchandising to Suppliers |
Functional Area |
Purchase Order |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS46 |
Wrapper Script |
rmswrap_multi_out.ksh |
Design Overview
Orders created within the Oracle Retail system are written to a flat file if they are approved and marked as EDI orders. This module is used to write new and changed purchase order data to a flat file in the Oracle Retail standard format. The translation to EDI format is expected to take place via a 3rd party translation utility. The order revision tables and allocation revision tables are also used to ensure that the latest changes are being sent and to allow both original and modified values to be sent. These revision tables are populated during the online ordering process and the batch replenishment process whenever an order has been approved, and constitutes a history of all revisions to the order.
The program sums up all quantities to the physical warehouse level from the virtual warehouse level for an order, before writing it into the output file.
If shipments are to be pre-marked by the supplier for cross docking, then along with the order information: allocation, location and quantities are also sent.
If the backhaul type is specified as “Calculated", then the backhaul allowances will be calculated.
If the order contains pack items; hierarchical pack information is sent (this may include outer packs, inner packs, and fashion styles with associated pack templates as well as component item information).
If the order is a Drop Ship Customer Order (location is a non-stockholding store), the customer billing and delivery information will be written to the flat file.
Restart/Recovery
The logical unit of work for this program is set at the supplier level. Threading is performed by the supplier using the v_restart_supplier view.
Restart ability is implied because the program updates ordhead.edi_sent_ind as records and are written out. The commit_max_ctr field should be set to prevent excessive rollback space usage, and to reduce the overhead of the file I/O. The recommended commit counter setting is 10000 records.
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000012 |
Output File Layout
Table 6-13 File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record descriptor |
Char(5) |
FHEAD |
File head marker |
Line id |
Number(10) |
0000000001 |
Unique line id |
|
Translator id |
Char(5) |
DLORD |
Identifies transaction type |
|
File create date |
Char(14) |
N/A |
Vdate in YYYYMMDDHH24MISS format |
|
TORDR |
Record descriptor |
Char(5) |
TORDR |
Order header information |
Line id |
Number(10) |
N/A |
Unique file line id |
|
Transaction id |
Number(10) |
N/A |
Unique transaction id |
|
Order change type |
Char(2) |
N/A |
‘CH' (changed) or ‘NW' (new) |
|
Order number |
Number(12) |
N/A |
Internal Oracle Retail order no |
|
Supplier |
Number(10) |
N/A |
Internal Oracle Retail supplier id |
|
Vendor order id |
Char(15) |
N/A |
External vendor_order_no (if available) |
|
Order written date |
Char(14) |
N/A |
Order created date in YYYYMMDDHH24MISS format |
|
Original order approval date |
Char(14) |
N/A |
Original order approval date in YYYYMMDDHH24MISS format |
|
Old Currency Code |
Char(3) |
N/A |
Old order currency_code (ISO standard) |
|
New Currency Code |
Char(3) |
N/A |
Changed order currency_code (ISO standard) |
|
Old Shipment Method of Payment |
Char(2) |
N/A |
Old ship_pay_method |
|
New Shipment Method of Payment |
Char(2) |
N/A |
Changed ship_pay_method |
|
Old Transportation Responsibility |
Char(2) |
N/A |
Old fob_trans_res |
|
Old Transportation Responsibility Description |
Char(250) |
N/A |
Old fob_trans_res_desc |
|
New Transportation Responsibility |
Char(2) |
N/A |
Changed fob_trans_res |
|
New Trans. Resp. Description |
Char(250) |
N/A |
New fob_trans_res_desc |
|
Old Title Passage Location |
Char(2) |
N/A |
Old fob_title_pass |
|
New Title Passage Location |
Char(2) |
N/A |
Changed fob_title_pass |
|
Old Title Passage Description |
Char(250) |
N/A |
Old fob_title_pass_desc |
|
New Title Passage Description |
Char(250) |
N/A |
Changed fob_title_pass_desc |
|
Old not before date |
Char(14) |
N/A |
Old not_before_date in YYYYMMDDHH24MISS format |
|
New not before date |
Char(14) |
N/A |
Changed not_before_date in YYYYMMDDHH24MISS format |
|
Old not after date |
Char(14) |
N/A |
Old not_after_date in YYYYMMDDHH24MISS format |
|
New not after date |
Char(14) |
N/A |
Changed not_after_date in YYYYMMDDHH24MISS format |
|
Old Purchase type |
Char(6) |
N/A |
Old Purchase type |
|
New Purchase type |
Char(6) |
N/A |
New Purchase type |
|
Backhaul allowance |
Char(20) |
N/A |
Backhaul allowance |
|
Old terms description |
Char(240) |
N/A |
Old terms description from terms table |
|
New terms description |
Char(240) |
N/A |
New terms description from terms table |
|
Old pickup date |
Char(14) |
N/A |
Old pickup date YYYYMMDDHH24MISS |
|
New pickup date |
Char(14) |
N/A |
New pickup date YYYYMMDDHH24MISS |
|
Old ship method |
Char(6) |
N/A |
Old ship method |
|
New ship method |
Char(6) |
N/A |
New ship method |
|
Old comment description |
Char(2000) |
N/A |
Old comment description |
|
New comment description |
Char(2000) |
N/A |
New comment description |
|
Supplier DUNS number |
Char(9) |
N/A |
Supplier DUNS number |
|
Supplier DUNS location |
Char(4) |
N/A |
Supplier DUNS location |
|
Customer order number |
Char(48) |
N/A |
Master customer order number from the Order Management System |
|
TITEM |
File record descriptor |
Char(5) |
TITEM |
Item info |
Line id |
Number(10) |
N/A |
Unique line id |
|
Transaction id |
Number(10) |
N/A |
Unique transaction id |
|
Item Number Type |
Char(6) |
N/A |
Item_number_type |
|
Item |
Char(25) |
N/A |
Item (For a pack item, this will be the pack number) |
|
Old Ref Item Number type |
Char(6) |
N/A |
Item_number_type for old ref_item |
|
Old Ref Item |
Char(25) |
N/A |
Old Ref_Item |
|
New Ref Item Number type |
Char(6) |
N/A |
Item_number_type for new ref_item |
|
New Ref Item |
Char(25) |
N/A |
Changed Ref_Item |
|
Vendor catalog number |
Char(30) |
N/A |
Supplier_item (VPN) |
|
Free Form Description |
Char(250) |
N/A |
Item_desc |
|
Supplier Diff 1 |
Char(120) |
N/A |
Supplier's diff 1 |
|
Supplier Diff 2 |
Char(120) |
N/A |
Supplier's diff 2 |
|
Supplier Diff 3 |
Char(120) |
N/A |
Supplier's diff 3 |
|
Supplier Diff 4 |
Char(120) |
N/A |
Supplier's diff 4 |
|
Pack Size |
Number(12) |
N/A |
Supplier defined pack size * 10000 (4 implied decimal places) |
|
Item line no |
Number(10) |
N/A |
Indicates the detail item line number. |
|
TPACK |
File record descriptor |
Char(5) |
TPACK |
Pack component info |
Line id |
Number(10) |
N/A |
Unique line id |
|
Transaction id |
Number(10) |
N/A |
Unique transaction id |
|
Pack id |
Char(25) |
N/A |
Packitem_breakout.pack_no (same as item for the pack item) |
|
Inner pack id |
Char(25) |
N/A |
Inner pack identification |
|
Pack Quantity |
Number(12) |
N/A |
Packitem_breakout.pack_item_qty*10000 (4 implied decimal places) |
|
Component Pack Quantity |
Number(12) |
N/A |
Packitem_breakout.comp_pack_qty*10000 (4 implied decimal places) |
|
Item Parent Part Quantity |
Number(12) |
N/A |
Packitem_breakout.item_parent_pt_qty*10000 (4 implied decimal places) |
|
Item Quantity |
Number(12) |
N/A |
Packitem_breakout.item_qty*10000 (4 implied decimal places) |
|
Item Number Type |
Char(6) |
N/A |
Item number type |
|
Item |
Char(25) |
N/A |
Item |
|
Ref Item Number Type |
Char(6) |
N/A |
Ref_item_number_type |
|
Ref Item |
Char(25) |
N/A |
Ref_item |
|
VPN |
Char(30) |
N/A |
Supplier item (vpn) |
|
Supplier Diff 1 |
Char(120) |
N/A |
Supplier's diff 1 |
|
Supplier Diff 2 |
Char(120) |
N/A |
Supplier's diff 2 |
|
Supplier Diff 3 |
Char(120) |
N/A |
Supplier's diff 3 |
|
Supplier Diff 4 |
Char(120) |
N/A |
Supplier's diff 4 |
|
Item Parent |
Char(25) |
N/A |
Required when Pack Template is not NULL |
|
Pack template |
Number(8) |
N/A |
Pack template associated w/style (packitem_breakout.pack_tmpl_id) |
|
Template description |
Char(250) |
N/A |
Description of pack template. sups_pack_tmpl_desc.supp_pack_desc |
|
TSHIP |
Record type |
Char(5) |
TSHIP |
Describes the file record-shipment information |
Line id |
Number(10) |
N/A |
Unique file line number |
|
Transaction id |
Number(10) |
N/A |
Unique transaction number |
|
Location type |
Char(2) |
N/A |
‘ST' store or ‘WH' warehouse |
|
Ship to location |
Number(10) |
N/A |
Location value form ordloc (store or warehouse – For warehouse,if multichannel option is ON, physical warehouse value is taken from warehouse) |
|
Old unit cost |
Number(20) |
N/A |
Old unit cost*10000 (4 implied decimal places) |
|
New unit cost |
Number(20) |
N/A |
New unit cost*10000 (4 implied decimal places) |
|
Old quantity |
Number(12) |
N/A |
Old qty_ordered *10000 or qty_allocated*10000 (4 implied decimal places) |
|
New quantity |
Number(12) |
N/A |
Changed qty_ordered*10000 or qty_allocated*10000 (4 implied decimal places) |
|
Old outstanding quantity |
Number(12) |
N/A |
Old (qty_ordered-qty_received)*10000 or (qty_allocated-qty transferred)*10000 for an allocation (4 implied decimal places) |
|
New outstanding quantity |
Number(12) |
N/A |
Changed qty_ordered-qty_received (4 implied decimal places)(or qty_allocated-qty_transferred, for an allocation) |
|
Cancel code |
Char(1) |
N/A |
N/A |
|
Old cancelled quantity |
Number(12) |
N/A |
Previous quantity cancelled (4 implied decimal places) |
|
New cancelled quantity |
Number(12) |
N/A |
Changed quantity cancelled (4 implied decimal places) |
|
Quantity type flag |
Char(1) |
N/A |
‘S'hip to ‘A'llocate |
|
Store or warehouse indicator |
Char(2) |
N/A |
‘ST' (store) or ‘WH' (warehouse) |
|
Old x-dock location |
Number(10) |
N/A |
Alloc_detail location (store or wh) |
|
New x-dock location |
Number(10) |
N/A |
Alloc_detail location (store or wh) |
|
Case length |
Number(12) |
N/A |
Case length (4 implied decimal places) |
|
Case width |
Number(12) |
N/A |
Case width (4 implied decimal places) |
|
Case height |
Number(12) |
N/A |
Case height (4 implied decimal places) |
|
Case LWH unit of measure |
Char(4) |
N/A |
Case LWH unit of measure |
|
Case weight |
Number(12) |
N/A |
Case weight (4 implied decimal places) |
|
Case weight unit of measure |
Char(4) |
N/A |
Case weight unit of measure |
|
Case liquid volume |
Number(12) |
N/A |
Case liquid volume (4 implied decimal places) |
|
Case liquid volume unit of measure |
Char(4) |
N/A |
Case liquid volume unit of measure |
|
Location DUNS number |
Char(9) |
N/A |
Location DUNS number |
|
Location DUNS loc |
Char(4) |
N/A |
Location DUNS loc |
|
Old unit cost init |
Number(20) |
N/A |
Old unit cost init (4 implied decimal places) |
|
New unit cost init |
Number(20) |
N/A |
New unit cost init (4 implied decimal places) |
|
Item/loc discounts |
Number(20) |
N/A |
Item/loc discounts (4 implied decimal places) |
|
TCUST |
Record type |
Char(5) |
TCUST |
Describes the file record-customer order information |
Line id |
Number(10) |
N/A |
Unique file line number |
|
Transaction id |
Number(10) |
N/A |
Unique transaction number |
|
Delivery first name |
Char(120) |
N/A |
First name for the delivery address on the order |
|
Delivery phonetic first name |
Char(120) |
N/A |
Phonetic first name for the delivery address on the order |
|
Delivery last name |
Char(120) |
N/A |
Last name for the delivery address on the order |
|
Delivery phonetic last name |
Char(120) |
N/A |
Phonetic last name for the delivery address on the order |
|
Delivery preferred name |
Char(120) |
N/A |
Preferred name for the delivery address on the order |
|
Delivery company name |
Char(120) |
N/A |
Company name for the delivery address on the order |
|
Delivery address Line 1 |
Char(240) |
N/A |
First line of the delivery address of the customer |
|
Delivery address Line 2 |
Char(240) |
N/A |
Second line of the delivery address of the customer |
|
Delivery address Line 3 |
Char(240) |
N/A |
Third line of the delivery address of the customer |
|
Delivery county |
Char(250) |
N/A |
County portion of the delivery address |
|
Delivery city |
Char(120) |
N/A |
City portion of the delivery address |
|
Delivery state |
Char(3) |
N/A |
State portion of the delivery address |
|
Delivery country ID |
Char(3) |
N/A |
Country portion of the delivery address |
|
Delivery post |
Char(30) |
N/A |
Postal code portion of the delivery address |
|
Delivery jurisdiction |
Char(10) |
N/A |
Jurisdiction code of the delivery country-state relationship |
|
Delivery phone |
Char(20) |
N/A |
Phone number in the delivery information |
|
Billing first name |
Char(120) |
N/A |
First name for the billing address on the order |
|
Billing phonetic first name |
Char(120) |
N/A |
Phonetic first name for the billing address on the order |
|
Billing last name |
Char(120) |
N/A |
Last name for the billing address on the order |
|
Billing phonetic last name |
Char(120) |
N/A |
Phonetic last name for the billing address on the order |
|
Billing preferred name |
Char(120) |
N/A |
Preferred name for the billing address on the order |
|
Billing company name |
Char(120) |
N/A |
Company name for the billing address on the order |
|
Billing address Line 1 |
Char(240) |
N/A |
First line of the billing address of the customer |
|
Billing address Line 2 |
Char(240) |
N/A |
Second line of the billing address of the customer |
|
Billing address Line 3 |
Char(240) |
N/A |
Third line of the billing address of the customer |
|
Billing county |
Char(250) |
N/A |
County portion of the billing address |
|
Billing city |
Char(120) |
N/A |
City portion of the billing address |
|
Billing state |
Char(3) |
N/A |
State portion of the billing address |
|
Billing country ID |
Char(3) |
N/A |
Country portion of the billing address |
|
Billing post |
Char(30) |
N/A |
Postal code portion of the billing address |
|
Billing jurisdiction |
Char(10) |
N/A |
Jurisdiction code of the billing country-state relationship |
|
Billing phone |
Char(20) |
N/A |
Phone number in the billing information |
|
TTAIL |
Record type |
Char(5) |
TTAIL |
Describes file record – marks end of order |
Line id |
Number(10) |
N/A |
Unique file line id |
|
Transaction id |
Number(10) |
N/A |
Unique transaction id |
|
#Lines in transaction |
Number(10) |
N/A |
Number of lines in transaction |
|
FTAIL |
Record type |
Char(5) |
FTAIL |
Describes file record – marks end of file |
Line id |
Number(10) |
N/A |
Unique file line id |
|
#lines |
Number(10) |
N/A |
Total number of transaction lines in file (not including FHEAD and FTAIL) |
For a new order, the “old" fields should be blank. For a changed order, both old and new fields should hold values. If the value has changed, “old" values come from the revision tables for the latest revision before the current one (the last one sent), while new orders come from the ordering tables.
-
FHEAD - REQUIRED: File identification, one line per file.
-
TORDR - REQUIRED: Order level information, one line per order.
-
TITEM - REQUIRED: Item description, multiple lines per order possible.
-
TPACK - OPTIONAL: Pack contents, multiple lines per order possible. This line will be written only for pack items.
-
TSHIP - REQUIRED: Ship to location and quantity, allocation location, multiple lines per item possible. Allocation information is optional on this line-will exist if premark_ind is 'Y'.
-
TCUST - OPTIONAL: Customer order information, one line per order. This line will be written only for Drop Ship Customer Orders.
-
TTAIL - REQUIRED: Order end, one line per order.
-
FTAIL - REQUIRED: End of file marker, one line per file.Output File Layout
Download Summary of Outstanding Orders on OTB by Subclass (otbdlord)
Module Name |
otbdlord.pc |
Description |
Download Summary of Outstanding Orders on OTB by Subclass |
Functional Area |
Open To Buy |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS13 |
Wrapper Script |
rmswrap_out.ksh |
Design Overview
This batch program runs at the end of the half to delete rows from the OTB table that are at least one half old. The current and previous half's OTB data is retained. The number of days that OTB records are retained by Merchandising is not configurable via a system parameter.
Restart/Recovery
The logical unit of work for the otbdlord module is department/class/subclass. The commit_max_ctr field should be set to prevent excessive rollback space usage, and to reduce the overhead of the file I/O. The recommended commit counter setting is 10000 records. Each time the record counter equals the maximum recommended commit number, an application image array record will be written to the restart_start_array for restart/recovery if a fatal error occurs.
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000029 |
Output File Layout
Table 6-14 otbdlord.pc - Output File
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
File Line Sequence Number |
Number(10) |
N/A |
Keeps track of the record's position in the file by line number |
|
File Type Definition |
Char(4) |
OOEX |
Identifies file as ‘OTB Out-standing Order Export' |
|
File Create Date |
Char(14) |
N/A |
Date the file was created in YYYYMMDD format. Remaining six characters are blank. |
|
File Detail |
File Type Record Descriptor |
Char(5) |
FDETL |
Identifies file record type |
File Line Sequence Number |
Number(10) |
N/A |
Keeps track of the record's position in the file by line number |
|
Transaction Set Control Number |
Number(14) |
N/A |
Sequence number used to force unique detail record check |
|
Department |
Number(4) |
N/A |
The number of the department which contains the outstanding order quantity value |
|
Class |
Number(4) |
N/A |
The number of the class which contains the outstanding order quantity value. |
|
Subclass |
Number(4) |
N/A |
The number of the subclass which contains the outstanding order quantity value |
|
N Outstanding Amt |
Number(20) |
N/A |
The amount of outstanding non-basic orders (order type N/B) for past periods; value includes 4 implied decimal places |
|
B Outstanding Amt |
Number(20) |
N/A |
The amount of outstanding buyer-replenished basic (order type BRB) orders for past periods; value includes 4 implied decimal places |
|
A Outstanding Amt |
Number(20) |
N/A |
The amount of outstanding auto-replenished basic (order type ARB) orders for past periods; value includes 4 implied decimal places |
|
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Sequence Number |
Number(10) |
N/A |
Keeps track of the record's position in the file by line number |
|
Control Number File Line Count |
Control Number File Line Count Number(10) |
N/A |
Total number of all transaction lines, not including file header and trailer |
On Order Publication API (BDI_OnOrder_Tx_PF_From_RMS_EOW_JOB)
This section describes the On Order Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of quantities On Order information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdimfpb.pls
BDI_MFP_SQL.ON_ORDER_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Order tables/view.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Replenishment Item Location Publication API (BDI_ReplItemLoc_Fnd_PF_From_RMS_JOB)
This section describes the Replenishment Item Location Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Replenishment Item Location information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdiitemb.pls
BDI_ITEM_SQL.REPL_ITEM_LOC_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising REPL_ITEM_LOC table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Import Management
When using the Import Management features in Merchandising, there are several outbound integration processes that are available for customs entry and letter of credit functions. These integrations are only available if you are using not using Simplified Import Management (based on your system options configurations).
For additional information about import management, including detailed flow diagrams, see the RTM Overview white paper in the Merchandising Documentation Library (Doc ID: 1585843.1).
Download of Customs Entry Transactions to Brokers (cednld)
Module Name |
cednld.pc |
Description |
Download of Customs Entry Transactions to Brokers |
Functional Area |
Oracle Retail Trade Management |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS53 |
Wrapper Script |
batch_cednld.ksh |
Design Overview
This program is used to download custom entry information from the Merchandising database to brokers. Each night, this program reads all customs entry (CE) transactions that are in Sent status for a broker ID. These transactions are written to a flat file and the status is changed to Downloaded. One flat file is written per broker.
Restart/Recovery
The Logical Unit of Work for the program is a single row from the customs entry header table. Restart/Recovery will be used for init and commit.
Table based restart/recovery must be used. The commit max counter field should be set to prevent excessive rollback space usage, and to reduce the overhead of file I/O. The recommended commit counter setting is 1000 records (subject to change based on implementation).
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter |
Integratin Contract |
IntCon000050 |
Output File Layout
Table 6-15 Output File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Type Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
File Line Identifier |
Number(10) |
Nine leading zeroes: 0000000001 |
ID of current line being processed by input file |
|
File Type Definition |
Char(4) |
CEDN |
Identifies file as ‘Customs Entry download' |
|
File Create Date |
Date |
Create date |
Vdate in YYYYMMDDHH24MISS format |
|
THEAD |
File Type Descriptor |
Char(5) |
THEAD |
Identifies file record type |
File Line Identifier |
Number(10) |
Incremented internally |
ID of current line being processed by input file |
|
CE ID |
Number(10) |
ce_head.ce_id |
N/A |
|
Entry No |
Char (15) |
ce_head.entry_no |
N/A |
|
Entry Date |
Char(14) |
ce_head.entry_date |
YYYYMMDDHH24MISS format |
|
Entry Status |
Char(6) |
ce_head.entry_status |
N/A |
|
Entry Type |
Char(6) |
ce_head.entry_type |
N/A |
|
Entry Port |
Char(5) |
ce_head.entry_port |
N/A |
|
Summary Date |
Char(14) |
ce_head.summary date |
YYYYMMDDHH24MISS format |
|
Broker ID |
Char(10) |
ce_head.broker_id |
N/A |
|
Broker Ref. ID |
Char(18) |
ce_head.broker_ref_id |
N/A |
|
File Number |
Char(18) |
ce_head.file_no |
N/A |
|
Importer ID |
Char(10) |
ce_head.importer_id |
N/A |
|
Import Country |
Char(3) |
ce_head.import_country_id |
N/A |
|
Currency Code |
Char(3) |
ce_head.currency_code |
N/A |
|
Exchange Rate |
Number(20,10) |
ce_head.exchange_rate*10000000000 (with 10 implied decimal places) |
N/A |
|
Bond Number |
Char(18) |
ce_head.bond_no |
N/A |
|
Bond Type |
Char(6) |
ce_head.bond_type |
N/A |
|
Surety Code |
Char(6) |
ce_head.surety_code |
N/A |
|
Consignee ID |
Char(10) |
ce_head.consignee_id |
N/A |
|
Live Indicator |
Char(1) |
ce_head.live_ind |
N/A |
|
Batch Number |
Char(20) |
ce_head.batch_no |
N/A |
|
Entry Team |
Char(3) |
ce_head.entry_team |
N/A |
|
Liquidation Amount |
Number(20,4) |
ce_head.liquidation_amt*10000 (4 implied decimal places) |
N/A |
|
Liquidation Date |
Date |
ce_head.liquidation_date |
YYYYMMDDHH24MISS format |
|
Reliquidation Amount |
Number(20,4) |
ce_head.reliquidation_amt*10000 (4 implied decimal places) |
N/A |
|
Reliquidation Date |
Date |
ce_head.reliquidation_date |
YYYYMMDDHH24MISS format |
|
Merchandise Loc |
Char(40) |
ce_head.merchandise_loc |
N/A |
|
Location Code |
Char(4) |
ce_head.location_code |
N/A |
|
TSHIP |
File Type Descriptor |
Char(5) |
TSHIP |
Identifies file record type |
File Line Identifier |
Number(10) |
Incremented internally |
ID of current line being processed by input file |
|
Vessel ID |
Char(20) |
ce_shipment.vessel_id |
N/A |
|
Voyage Flt ID |
Char(10) |
ce_shipment.voyage_flt_id |
N/A |
|
Estimated Departure Date |
Date |
ce_shipment.estimated_depart_date |
YYYYMMDDHH24MISS format |
|
Vessel SCAC Code |
Char(6) |
ce_shipment.vessel_scac_code |
N/A |
|
Lading Port |
Char(5) |
ce_shipment.lading_port |
N/A |
|
Discharge Port |
Char(5) |
ce_shipment.discharge_port |
N/A |
|
Tran Mode ID |
Char(6) |
ce_shipment.tran_mode_id |
N/A |
|
Export Date |
Date |
ce_shipment.export_date |
YYYYMMDDHH24MISS |
|
Import Date |
Date |
ce_shipment.import_date |
YYYYMMDDHH24MISS |
|
Arrival Date |
Date |
ce_shipment.arrival_date |
YYYYMMDDHH24MISS |
|
Export Country |
Char(3) |
ce_shipment.export_country_id |
N/A |
|
Shipment Number |
Number(10) |
ce_shipment.shipment_no |
N/A |
|
TORDI |
File Type Descriptor |
Char(5) |
TORDI |
Identifies file record type |
File Line Identifier |
Number(10) |
Incremented internally |
ID of current line being processed by input file |
|
Order Number |
Number(8) |
ce_ord_item.order_no |
N/A |
|
Item |
Char (25) |
ce_ord_item.item |
N/A |
|
BL AWB ID |
Char(30) |
ce_ord_item.bl_awb_id |
‘MULTI' – means multiple airway bills (otherwise a single airway bill will be retrieved) |
|
Invoice ID |
Char(30) |
ce_ord_item.invoice_id |
N/A |
|
Invoice Date |
Date |
ce_ord_item.invoice_date |
YYYYMMDDHH24MISS format |
|
Invoice Amount |
Number(20,4) |
ce_ord_item.invoice_amt*10000 (4 implied decimal places) |
N/A |
|
Currency Code |
Char(3) |
ce_ord_item.currency_code |
N/A |
|
Exchange Rate |
Number(20,10) |
ce_ord_item.exchange_rate*10000000000 (10 implied decimal places) |
N/A |
|
Manifest Item Quantity |
Number(12,4) |
ce_ord_item.manifest_item_qty*10000 (4 implied decimal places) |
N/A |
|
Manifest Item Quantity UOM |
Char(4) |
ce_ord_item.manifest_item_qty_uom |
N/A |
|
Carton Quantity |
Number (12,4) |
ce_ord_item.carton_qty*10000 (4 implied decimal places) |
N/A |
|
Carton Quantity UOM |
Char(4) |
ce_ord_item.carton_qty_uom |
N/A |
|
Gross Weight |
Number(12,4) |
ce_ord_item.gross_wt*10000 (4 implied decimal places) |
N/A |
|
Gross Weight UOM |
Char(4) |
ce_ord_item.gross_wt_uom |
N/A |
|
Net Weight |
Number(12,4) |
ce_ord_item.net_wt*10000 (4 implied decimal places) |
N/A |
|
Net Weight UOM |
Char(4) |
ce_ord_item.net_wt_uom |
N/A |
|
Cubic |
Number(12,4) |
ce_ord_item.cubic*10000 (4 implied decimal places) |
N/A |
|
Cubic UOM |
Char(4) |
ce_ord_item.cubic_uom |
N/A |
|
Cleared Quantity |
Number(12,4) |
ce_ord_item.cleared_qty*10000 (4 implied decimal places) |
N/A |
|
Cleared Quantity UOM |
Char(4) |
ce_ord_item.cleared_qty_uom |
N/A |
|
In Transit Number |
Char(15) |
ce_ord_item.in_transit_no |
N/A |
|
In Transit Date |
Date |
ce_ord_item.in_transit_date |
YYYYMMDDHH24MISS format |
|
Rush Indicator |
Char(1) |
ce_ord_item.rush_ind |
N/A |
|
Related Indicator |
Char(1) |
ce_ord_item.related_ind |
N/A |
|
Tariff Treatment |
Char(10) |
ce_ord_item.tariff_treatment |
N/A |
|
Ruling Number |
Char(10) |
ce_ord_item.ruling_no |
N/A |
|
Do Number |
Char(10) |
ce_ord_item.do_no |
N/A |
|
Do Date |
Date |
ce_ord_item.do_date |
YYYYMMDDHH24MISS format |
|
Manufacture ID |
Char(18) |
sup_import_attr.mfg_id |
N/A |
|
TBLAW |
File Type Descriptor |
Char(5) |
TBLAW |
Identifies file record type |
File Line Identifier |
Number(10) |
Incremented internally |
ID of current line being processed by input file |
|
BL AWB ID |
Char(30) |
Transportation.bl_awb_id |
N/A |
|
TCONT |
File Type Descriptor |
Char(5) |
TCONT |
Identifies file record type |
File Line Identifier |
Number(10) |
Incremented internally |
ID of current line being processed by input file |
|
Container ID |
Char(20) |
Transportation.container_id |
N/A |
|
Container SCAC Code |
Char(6) |
Transportation.container_scac_code |
N/A |
|
TLICV |
File Type Descriptor |
Char(5) |
TLICV |
Identifies file record type |
File Line Identifier |
Number(10) |
Incremented internally |
ID of current line being processed by input file |
|
License/Visa Type |
Char(6) |
ce_lic_visa.license_visa_type |
N/A |
|
License/Visa ID |
Char(30) |
ce_lic_visa.license_visa_id |
N/A |
|
License/Visa Quantity |
Number(12,4) |
ce_lic_visa.license_visa_qty*10000 (4 implied decimal places) |
N/A |
|
License/Visa Quantity UOM |
Char(4) |
ce_lic_visa.license_visa_qty_uom |
N/A |
|
Quota Category |
Char (6) |
ce_lic_visa.quota_category |
N/A |
|
Net Weight |
Number(12,4) |
ce_lic_visa.net_weight*10000 (4 implied decimal places) |
N/A |
|
Net Weight UOM |
Char(4) |
ce_lic_visa.net_weight_uom |
N/A |
|
Holder ID |
Char(18) |
ce_lic_visa.holder_id |
N/A |
|
TCHRG |
File Type Descriptor |
Char(5) |
TCHRG |
Identifies file record type |
File Line Identifier |
Number(10) |
Incremented internally |
ID of current line being processed by input file |
|
Sequence Number |
Number(6) |
ce_charges.seq_no |
N/A |
|
Pack Item |
Char(25) |
ce_charges.pack_item |
N/A |
|
HTS |
Char(10) |
ce_charges.hts |
N/A |
|
Effect From Date |
Date |
ce_charges.effect_from |
YYYYMMDDHH24MISS format |
|
Effect To Date |
Char(14) |
ce_charges.effect_to |
YYYYMMDDHH24MISS format |
|
Component ID |
Date |
ce_charges.comp_id |
N/A |
|
Component Rate |
Number(20,4) |
ce_charges.comp_rate*10000 (4 implied decimal places) |
N/A |
|
Per Count UOM |
Char(3) |
ce_charges.per_count_uom |
N/A |
|
Component Value |
Number(20,4) |
ce_charges.comp_value * 10000 (4 implied decimal places) |
N/A |
|
TMDOC |
File Type Descriptor |
Char(5) |
TMDOC |
Identifies file record type |
File Line Identifier |
Number(10) |
Incremented internally |
ID of current line being processed by input file |
|
Doc_id |
Number(6) |
Missing_doc.doc_id |
N/A |
|
Received_date |
Date |
Missing_doc.received_date |
YYYYMMDDHH24MISS format |
|
FTAIL |
File Type Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Identifier |
Number(10) |
Incremented internally |
ID of current line being processed by input file. |
|
File Record Counter |
Number(10) |
Determined internally |
Number of records/transactions processed in current file (only records between head & tail) |
Letter of Credit Amendment Download (lcmdnld)
Module Name |
lcmdnld.pc |
Description |
Letter of Credit Amendment Download |
Functional Area |
Oracle Retail Trade Management |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS56 |
Wrapper Script |
rmswrap_dnld_in.ksh |
Design Overview
lcmdnld.pc downloads amended letter of credit information to a bank, in the S.W.I.F.T. format.
Online user actions flag LCs for download by writing to the LC_DOWNLOAD table.
Restart/Recovery
Restart/recovery for this program is set up at the lc_ref_id level. The recommended commit counter setting is 1000 records (subject to change based on experimentation).
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter |
Integratin Contract |
IntCon000053 |
Output File Layout
Table 6-16 File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
File Line Sequence Number |
Number(10) |
Line number in file |
Keeps track of the record's position in the file by line number |
|
File Type Definition |
Char(4) |
LCAM |
Identifies file as ‘Letter of Credit Amendment' |
|
File Create Date |
Char(14) |
Create date |
Current date, formatted to ‘YYYYMMDDHH24MISS' |
|
Transaction Header |
Filetype Record descriptor |
Char(5) |
THEAD |
Identifies file record type |
File Line Sequence Number |
Number (10) |
Line number in file |
Keeps track of the record's position in the file by line number |
|
Transaction Set Control Number |
Number (10) |
Sequence number |
Used to force unique file check |
|
Issuing Bank |
Char(10) |
lc_head.issuing_bank |
Used to sort the LCs into individualized bank SWIFT formatted files (using another program) – bank where LC application is headed |
|
Issuing Bank Name |
Char(240) |
partner.partner_desc |
The description from the partner table where partner_id = issuing_bank and partner_type = ‘BK' |
|
Issuing Bank Address 1 |
Char(240) |
addr.add_1 |
Mandatory line of address |
|
Issuing Bank Address 2 |
Char(240) |
addr.add_2 |
Non-mandatory line of address (can be null) |
|
Issuing Bank Address 3 |
Char(240) |
addr.add_3 |
Non-mandatory line of address (can be null) |
|
Issuing Bank City |
Char(120) |
addr.city |
City bank located in |
|
Issuing Bank State |
Char(3) |
addr.state |
State, if applicable, where bank located in |
|
Issuing Bank Post Code |
Char(30) |
addr.post |
Post code, if applicable, where bank located in |
|
Issuing Bank Country |
Char(3) |
addr.country_id |
Country bank located in |
|
Letter of Credit |
Number (8) |
lc_detail.lc_ref_id |
The LC_REF_ID off the LC_DETAIL table |
|
Bank Letter of Credit ID |
Char(16) |
lc_head.bank_lc_id |
The BANK_LC_ID off the LC_HEAD table |
|
Currency Code |
Char(3) |
lc_head.currency_code |
The CURRENCY_CODE off the LC_HEAD table |
|
Date of Issue/ Transfer of the Credit |
Char(14) |
lc_head.confirmed_date |
Date the Issuing Bank thinks is the date of issue–when it was officially confirmed, formatted to ‘YYYYMMDDHH24MISS' |
|
Current Amount of LC |
Number (20,4) |
N/A |
This amount will be calculated in the get_current_amount() function and will be the net amount of the LC calculated only using amendments that have been downloaded. Normally, the net amount is calculated using amendments in the ‘D'ownloaded status |
|
Beneficiary |
Number (10) |
lc.head.beneficiary |
Party in favor of which the LC is being issued |
|
Beneficiary Name |
Char(240) |
sups.sup_name |
Beneficiary (supplier) name from the SUPS table |
|
Beneficiary Address 1 |
Char(240) |
addr.add_1 |
Mandatory line of address |
|
Beneficiary Address 2 |
Char(240) |
addr.add_2 |
Non-mandatory line of address (can be null) |
|
Beneficiary Address 3 |
Char(240) |
addr.add_3 |
Non-mandatory line of address (can be null) |
|
Beneficiary City |
Char(120) |
addr.city |
City beneficiary located in |
|
Beneficiary State |
Char(3) |
addr.state |
State, if applicable, where beneficiary located in |
|
Beneficiary Post Code |
Char(30) |
addr.post |
Post code, if applicable, where beneficiary located in |
|
Beneficiary Country |
Char(3) |
addr.country_id |
Country beneficiary located in |
|
Transaction Detail |
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies file record type |
File Line Sequence Number |
Number (10) |
line number in file |
Keeps track of the record's position in the file by line number |
|
Transaction Set Control Number |
Number (10) |
sequence number |
Used to force unique file check |
|
Amendment Number |
Number (8) |
lc_amendments.amend_no |
Holds the amendment number for the amendment |
|
Order_no |
Number (8) |
lc_amendments.order_no |
Order_no, if applicable, that is attached to the LC that is being amended |
|
Item |
Char(25) |
lc_amendments.item |
Item being amended, either a Style or Staple sku |
|
Value Being Amended |
Char(6) |
lc_amendments.amended_value |
LC Field being amended. Can be any of the following code_types: CODE CODE_DESC AI Add Item AO Add PO ARQD Add Reqd Doc. C Cost ED Expiration Date ESD Earliest Ship Date LSD Latest Ship Date NA Net Amount ND Negotiation Days OC Origin Country OQ Order Quantity PE Place of Expiry PRT Presentation Terms PSF Partial Ship Flag RI Remove Item RO Remove PO RRQD Remove Reqd Doc TFF Transferable Flag TSF Transshipment Flag |
|
Value Being Amended Description |
Char(40) |
code_detail.code_desc |
The Value Being Amended decoded (see the above list). Will possibly be used when printing to the SWIFT file MT 707 for clarity |
|
Original Value of Amended Field |
Char(45) |
lc_amendments.original_value |
Current value of field that is being amended |
|
New Value of Amended Field |
Char (2000) |
lc_amendments.new_value |
New value of the field that is being amended |
|
Description of New Value |
Char(40) |
code_detail.code_desc |
The new value decoded (or fetched from a table, as in the origin_country case)– only applicable to the following amended values: place of expiry, title_pass_location, origin_country, presentation terms, purchase type |
|
Sign |
Char(1) |
N/A |
If the effect is negative it will be “-“ if the effect is positive it will be “ “ |
|
Effect |
Number (20,4) |
lc.amendments.effect |
Effect that amendment will have on LC if amendment to change qty or cost of a PO or amount of LC itself |
|
Date of Amendment |
Char(14) |
Lc_amendments.accept_date |
Date on which Issuing Bank (or issuing party, in this case the retailer) considers the credit as being amended, formatted to ‘YYYYMMDD HH24MISS' |
|
Transaction Text |
File Type Record Descriptor |
Char(5) |
TTEXT |
Identifies file record type |
File Line Sequence Number |
Number (10) |
line number in file |
Keeps track of the record's position in the file by line number |
|
Transaction Set Control Number |
Number (10) |
sequence number |
Used to force unique file check |
|
Amendment Text |
Char (2000) |
text description |
A text description of the individual amendment (for each TDETL line of the output file) built by the package LC_AMEND_SQL. AMEND_TEXT. |
|
Transaction Trailer |
File Type Record Descriptor |
Char (5) |
TTAIL |
Identifies File Record Type |
File Line Sequence Number |
Number (10) |
Line Number in file |
ID of current line being created for output file |
|
Transaction set control number |
Number (10) |
Sequence number |
Used to force unique file check |
|
Transaction detail line count |
Number (10) |
ID of current line being created for output file |
Sume of the detail lines within a transaction |
|
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Sequence Number |
Number (10) |
line number in file |
Keeps track of the record's position in the file by line number |
|
Control Number File Line Count |
Number (10) |
total detail lines |
Sum of all transaction lines, not including the file header and trailer |
Letter of Credit Application Download (lcadnld)
Module Name |
Lcadnld.pc |
Description |
Letter of Credit Application Download |
Functional Area |
Retail Trade Management |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS57 |
Wrapper Script |
rmswrap_dnld_in.ksh |
Design Overview
Lcadnld sends letter of credit (LC) applications to partner banks. Online user actions flag LCs for download by writing to the LC_DOWNLOAD table.
Restart/Recovery
Restart/recovery for this program is set up at the lc_ref_id level. The recommended commit counter setting is 10000 records (subject to change based on experimentation).
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter |
Integratin Contract |
IntCon000052 |
Output File Layout
Table 6-17 File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
File Line Identifier |
Number(10) |
line number in file |
ID of current line being created for output file |
|
File Type Definition |
Char(4) |
LCAP |
Identifies file as ‘Letter of Credit Application' |
|
File Create Date |
Char(14) |
create date |
Current date, formatted to ‘YYYYMMDDHH24MISS' |
|
File Detail |
File Type Record Descriptor |
Char(5) |
THEAD |
Identifies file record type |
File Line Sequence Number |
Number(10) |
line number in file |
ID of current line being created for output file. |
|
Transaction Set Control Number |
Number(10) |
sequence number |
Used to force unique file check |
|
Issuing Bank |
Char(10) |
lc_head.issuing_bank |
Used to sort the LCs into individualized bank SWIFT formatted files (using another program) - bank where LC application is headed |
|
Issuing Bank Name |
Char(240) |
partner.partner_desc |
The description from the partner table where partner_id = issuing_bank and partner_type = 'BK' |
|
Issuing Bank Address 1 |
Char(240) |
addr.add_1 |
Mandatory line of address |
|
Issuing Bank Address 2 |
Char(240) |
addr.add_2 |
Non-mandatory line of address (can be null) |
|
Issuing Bank Address 3 |
Char(240) |
addr.add_3 |
Non-mandatory line of address (can be null) |
|
Issuing Bank City |
Char(120) |
addr.city |
City bank located in |
|
Issuing Bank State |
Char(3) |
addr.state |
State, if applicable, where bank located in |
|
Issuing Bank Post Code |
Char(30) |
addr.post |
Post code, if applicable, where bank located in |
|
Issuing Bank Country |
Char(3) |
addr.country_id |
Country bank located in |
|
Advising Bank |
Char(10) |
lc_head.advising_bank |
Used to sort the LCs into individualized bank SWIFT formatted files (using another program) - bank where LC application is headed |
|
Advising Bank Name |
Char(240) |
Partner.partner_desc |
The description from the partner table where partner_id = advising_bank and partner_type = 'BK' |
|
Advising Bank Address 1 |
Char(240) |
Addr.add_1 |
Mandatory line of address |
|
Advising Bank Address 2 |
Char(240) |
Addr.add_2 |
Non-mandatory line of address (can be null) |
|
Advising Bank Address 3 |
Char(240) |
Addr.add_3 |
Non-mandatory line of address (can be null) |
|
Advising Bank City |
Char(120) |
Addr.city |
City bank located in |
|
Advising Bank State |
Char(3) |
Addr.state |
State, if applicable, where bank located in |
|
Advising Bank Post Code |
Char(30) |
Addr.post |
Post code, if applicable, where bank located in |
|
Advising Bank Country |
Char(3) |
Addr.country_id |
Country bank located in |
|
Letter of Credit |
Number(8) |
lc_head.lc_ref_id |
The LC_REF_ID off the LC_HEAD table |
|
Form Type |
Char(6) |
lc_head.form_type |
The level of detail that the LC will send to the issuing bank |
|
Form Type Description |
Char(40) |
code_detail.code_desc |
Describes the form type: Long or Short |
|
Letter of Credit Type |
Char(6) |
lc_head.lc_type |
Describes the form type: Long or Short |
|
Letter of Credit Type Description |
Char(40) |
code_detail.code_desc |
Describes the LC type: Master, Normal, Revolving |
|
Form of Letter of Credit – I |
Char(1) |
sup_import_attr.revocable_ind |
The REVOCABLE_IND from the SUP_IMPORT_ATTR table |
|
Form of Letter of Credit – II |
Char(1) |
lc_head.transferable_ind |
Indicates if LC transferable |
|
Application Date |
Char(14) |
lc_head.application_date |
Date the LC is created within Import Management/Merchandising, formatted to 'YYYYMMDD HH24MISS' |
|
Expiration Date |
Char(14) |
lc_head.expiration_date |
The date the LC expires, formatted to 'YYYYMMDD HH24MISS' |
|
Place of Expiry |
Char(6) |
lc_head.place_of_expiry |
Code for the place the LC will expire |
|
Place of Expiry Description |
Char(40) |
desc is retrieved through a decode |
The description of the place the LC will expire |
|
Applicant |
Char(10) |
lc_head.applicant |
Party on whose behalf the LC is being issued |
|
Applicant Name |
Char(240) |
partner.partner_desc |
The description from the partner table where partner_id = applicant and partner_type = 'AP' |
|
Applicant Address 1 |
Char(240) |
addr.add_1 |
Mandatory line of address |
|
Applicant Address 2 |
Char(240) |
addr.add_2 |
Non-mandatory line of address (can be null) |
|
Applicant Address 3 |
Char(240) |
addr.add_3 |
Non-mandatory line of address (can be null) |
|
Applicant City |
Char(120) |
addr.city |
City applicant located in |
|
Applicant State |
Char(3) |
addr.state |
State, if applicable, where applicant located in |
|
Applicant Post Code |
Char(10) |
addr.post |
Post code, if applicable, where applicant located in |
|
Applicant Country |
Char(3) |
addr.country_id |
Country applicant located in |
|
Beneficiary |
Number(10) |
lc.head.beneficiary |
Party in favor of which the LC is being issued |
|
Beneficiary Name |
Char(240) |
sups.sup_name |
Beneficiary (supplier) name from the SUPS table |
|
Beneficiary Address 1 |
Char(240) |
addr.add_1 |
Mandatory line of address |
|
Beneficiary Address 2 |
Char(240) |
addr.add_2 |
Non-mandatory line of address (can be null) |
|
Beneficiary Address 3 |
Char(240) |
addr.add_3 |
Non-mandatory line of address (can be null) |
|
Beneficiary City |
Char(120) |
addr.city |
City beneficiary located in |
|
Beneficiary State |
Char(3) |
addr.state |
State, if applicable, where beneficiary located in |
|
Beneficiary Post Code |
Char(30) |
addr.post |
Post code, if applicable, where beneficiary located in |
|
Beneficiary Country |
Char(3) |
addr.country_id |
Country beneficiary located in |
|
Currency Code |
Char(3) |
lc_head.currency_code |
The country of origin for the orders on the LC |
|
Exchange Rate |
Number (20,10) |
lc_head.exchange_rate |
Exchange_rate to convert LC currency to Merchandising currency |
|
Origin Country ID |
Char(3) |
lc_head.origin_country_id |
Origin country of the orders associated with the LC |
|
Presentation Terms |
Char(6) |
lc_head.presentation_terms |
Code for the terms of presentation |
|
Presentation Terms Description |
Char(40) |
desc is retrieved through a decode |
Description of the terms of presentation |
|
Purchase Type |
Char(6) |
lc_head.purchase_type |
Code for the purchase type |
|
Purchase Type Description |
Char(40) |
desc is retrieved through a decode |
Description of the purchase type |
|
Advice Method |
Char(6) |
lc_head.advice_method |
Code for the advice method |
|
Advice Method Description |
Char(40) |
desc is retrieved through a decode |
Description of the advice method (eg. Full Wire, Mail, and so on) |
|
Issuance |
Char(6) |
lc_head.issuance |
Code for the issuance |
|
Issuance Description |
Char(40) |
desc is retrieved through a decode |
Description of the issuance (for example Cable, Telex, and so on) |
|
Amount Type |
Char(6) |
lc_head.amount_type |
If 'E'xact, then amount must be exat, if 'A'pproximate then amount can be within variance percent |
|
Amount Type Description |
Char(40) |
desc is retrieved through a decode |
Description of amount_type |
|
Amount |
Number (20,4) |
lc_head.amount |
The total amt of the Letter of Credit |
|
Variance Percent |
Number (12,4) |
lc_head.variance_pct |
Allowed currency variance percent for the LC |
|
Specification |
Char(6) |
lc_head.specification |
Code for any condition for the credit, such as,. "maximum", and so on |
|
Specification Description |
Char(40) |
desc is retrieved through a decode |
Description of condition for the credit, such as,. "maximum", and so on |
|
Credit Available With |
Char(10) |
lc_head.credit_avail_with |
Code for bank with which credit is available |
|
Credit With Bank Name |
Char(40) |
partner.partner_desc |
The description from the partner table where partner_id = credit_avail_with and partner_type = 'BK' |
|
Credit With Address 1 |
Char(240) |
addr.add_1 |
Mandatory line of address |
|
Credit With Address 2 |
Char(240) |
addr.add_2 |
Non-mandatory line of address (can be null) |
|
Credit With Address 3 |
Char(240) |
addr.add_3 |
Non-mandatory line of address (can be null) |
|
Credit With City |
Char(120) |
addr.city |
City creditor located in |
|
Credit With State |
Char(3) |
addr.state |
State, if applicable, where creditor located in |
|
Credit With Post Code |
Char(30) |
addr.post |
Post code, if applicable, where creditor located in |
|
Credit With Country |
Char(3) |
addr.country_id |
Country creditor located in |
|
Drafts At |
Char(6) |
lc_head.drafts_at |
Specifies the terms of the drafts to be drawn under the LC |
|
Drafts At Description |
Char(40) |
desc is retrieved through a decode |
Description of the terms of the drafts to be drawn under the LC |
|
Drawee |
Char(10) |
lc_head.paying_bank |
Identifies drawee of drafts to be drawn under LC (paying bank) |
|
Drawee Name |
Char(240) |
partner.partner_desc |
The description from the partner table where partner_id = paying_bank and partner_type = 'BK |
|
Drawee Address 1 |
Char(240) |
addr.add_1 |
Mandatory line of address |
|
Drawee Address 2 |
Char(240) |
addr.add_2 |
Non-mandatory line of address (can be null) |
|
Drawee Address 3 |
Char(240) |
addr.add_3 |
Non-mandatory line of address (can be null) |
|
Drawee City |
Char(120) |
addr.city |
City bank located in |
|
Drawee State |
Char(3) |
addr.state |
State, if applicable, where bank located in |
|
Drawee Post Code |
Char(30) |
addr.post |
Post code, if applicable, where bank located in |
|
Drawee Country |
Char(3) |
addr.country_id |
Country bank located in |
|
Negotiating Bank |
Char(10) |
lc_head.negotiating_bank |
Identifies the negotiating bank |
|
Negotiating Bank Name |
Char(240) |
partner.partner_desc |
The description from the partner table where partner_id = negotiating_bank and partner_type = 'BK' |
|
Negotiating Bank Address 1 |
Char(240) |
addr.add_1 |
Mandatory line of address |
|
Negotiating Bank Address 2 |
Char(240) |
addr.add_2 |
Non-mandatory line of address (can be null) |
|
Negotiating Bank Address 3 |
Char(240) |
addr.add_3 |
Non-mandatory line of address (can be null) |
|
Negotiating Bank City |
Char(120) |
addr.city |
City bank located in |
|
Negotiating Bank State |
Char(3) |
addr.state |
State, if applicable, where bank located in |
|
Negotiating Bank Post Code |
Char(30) |
addr.post |
Post code, if applicable, where bank located in |
|
Negotiating Bank Country |
Char(3) |
addr.country_id |
Country bank located in |
|
Confirming Bank |
Char(10) |
lc_head.confirming_bank |
||
Confirming Bank Name |
Char(240) |
partner.partner_desc |
Identifies the confirming bank |
|
Confirming Bank Address 1 |
Char(240) |
addr.add_1 |
The description from the partner table where partner_id = confirming_bank and partner_type = 'BK' |
|
Confirming Bank Address 2 |
Char(240) |
addr.add_2 |
Mandatory line of address |
|
Confirming Bank Address 3 |
Char(240) |
addr.add_3 |
Non-mandatory line of address (can be null) |
|
Confirming Bank City |
Char(120) |
addr.city |
Non-mandatory line of address (can be null) |
|
Confirming Bank State |
Char(3) |
addr.state |
City bank located in |
|
Confirming Bank Post Code |
Char(30) |
addr.post |
State, if applicable, where bank located in |
|
Confirming Bank Country |
Char(3) |
addr.country_id |
Post code, if applicable, where bank located in |
|
Transferring Bank |
Char(10) |
lc_head.transferring_bank |
Country bank located in |
|
Transferring Bank Name |
Char(240) |
partner.partner_desc |
Identifies the transferring bank |
|
Transferring Bank Address 1 |
Char(240) |
addr.add_1 |
The description from the partner table where partner_id = transferring_bank and partner_type = 'BK' |
|
Transferring Bank Address 2 |
Char(240) |
addr.add_2 |
Mandatory line of address |
|
Transferring Bank Address 3 |
Char(240) |
addr.add_3 |
Non-mandatory line of address (can be null) |
|
Transferring Bank City |
Char(120) |
addr.city |
Non-mandatory line of address (can be null) |
|
Transferring Bank State |
Char(3) |
addr.state |
City bank located in |
|
Transferring Bank Post Code |
Char(30) |
addr.post |
State, if applicable, where bank located in |
|
Transferring Bank Country |
Char(3) |
addr.country_id |
Post code, if applicable, where bank located in |
|
Partial Shipment Indicator |
Char(1) |
lc_head.partial_ship_ind |
Country bank located in |
|
Transshipment Indicator |
Char(1) |
lc_head.transshipment_ind |
Indicates whether goods covered by LC can be partially shipped or not |
|
Fob Title Pass |
Char(6) |
lc_head.fob_title_pass |
Indicates whether goods can be transferred to another vessel midway through the voyage |
|
Fob Title Pass Decode |
Char(40) |
desc is retrieved through a decode |
Indicates where the title for goods is passed from the vendor to the purchaser |
|
Fob Title Pass Description |
Char(250) |
lc_head.ob_title_pass_desc |
Decode of where the title for goods is passed from the vendor to the purchaser |
|
Transportation to |
Char(5) |
lc_head.transportation_to |
Describes the FOB_TITLE_PASS - could be city name and so on |
|
Transportation to description |
Char(150) |
outloc.outloc_desc |
Transportation to location |
|
With Recourse Indicator |
Char(1) |
lc_head.with_recourse_ind |
Description of transportation to location |
|
Latest Shipment Date |
Char(14) |
lc_head.latest_ship_date |
Indicates conditional payment on the part of the bank as instructed by the buyer |
|
Earliest Shipment Date |
Char(14) |
lc_head.earliest_ship_date |
Latest ship date for all Pos included in the LC, formatted to 'YYYYMMDD HH24MISS' |
|
Letter of Credit Negotiation Days |
Number(3) replaces x in the string “DOCUMENTS TO BE PRESENTED WITHIN x DAYS AFTER ISSUANCE OF THE SHIPPING DOCUMENTS BUT WITHIN THE VALIDITY OF THIS CREDIT" |
lc.head.lc_neg_days |
The number of days to negotiate documents |
|
Bank's LC reference id |
Number(8) |
lc_head.bank_lc_id |
Bank's LC ref id |
|
File Type Record Descriptor |
Char(5) |
THDCM |
Identifies file record type |
|
File Line Sequence Number |
Number(10) |
line number in file |
ID of current line being created for output file |
|
Transaction Set Control Number |
Number(10) |
sequence number |
Used to force unique file check |
|
Header Level Comments |
Char(2000) |
lc_head.comments |
Holds any comments that you added to the Letter of Credit. |
|
File Type Record Descriptor |
Char(5) |
TDOCS |
Identifies file record type |
|
File Line Sequence Number |
Number(10) |
line number in file |
ID of current line being created for output file |
|
Transaction Set Control Number |
Number(10) |
sequence number |
Used to force unique file check |
|
Swift Tag |
Char(6) |
doc.swift_tag |
Identifies individual document types that can be associated with an LC |
|
Document ID |
Number(6) |
req_doc.doc_id |
Uniquely identifies the individual documents associated with an LC |
|
Body Text |
Char(2000) |
req_doc.doc_text |
Documents associated with a given LC Description of Goods and Services OR Documents Required OR Additional Conditions OR Narrative |
|
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies file record type |
|
File Line Sequence Number |
Number(10) |
line number in file |
ID of current line being created for output file |
|
Transaction Set Control Number |
Number(10) |
sequence number |
Used to force unique file check |
|
Order Number |
Number(8) |
lc_detail.order_no |
PO associated with the LC |
|
Item |
Char(25) |
lc_detail.item |
Item on the PO - item is rolled up to the item_level of 1, if possible |
|
Cost |
Number (20,4) |
lc_detail.cost |
If form_type = 'S'hort then cost is the total cost of the order; if the form_type = 'L'ong then the cost is the unit cost of the item |
|
Quantity |
Number (12,4) |
lc_detail.qty |
Total qty of the item for the order on the LC |
|
Standard UOM |
Char(4) |
Item_master.standard_uom |
Standard unit of measure of the quantity of the item for the order on the LC |
|
Earliest Ship Date |
Char(14) |
lc_detail.earliest_ship_date |
The earliest date an order on the LC can be shipped, formatted to 'YYYYMMDDHH24MISS |
|
Latest Ship Date |
Char(14) |
lc_detail.latest_ship_date |
The latest date an order on the LC can be shipped, formatted to 'YYYYMMDD HH24MISS' |
|
item description |
Char(250) |
Item_master.desc_up |
Item's description |
|
File Type Record Descriptor |
Char(5) |
TMERC |
Identifies file record type |
|
File Line Sequence Number |
Number(10) |
line number in file |
ID of current line being created for output file |
|
Transaction Set Control Number |
Number(10) |
sequence number |
Used to force unique file check |
|
Merchandise Description |
Char(2000) |
lc_detail.merch_desc |
Contains the merchandise description of the field. |
|
File Type Record Descriptor |
Char(5) |
TDTCM |
Identifies file record type |
|
File Line Sequence Number |
Number(10) |
line number in file |
ID of current line being created for output file |
|
Transaction Set Control Number |
Number(10) |
sequence number |
Used to force unique file check |
|
Detail Level Comments |
Char(2000) |
lc_detail.comments |
Holds any comments that you added to the Letter of Credit detail record. |
|
File Trailer |
File Type Record Descriptor |
Char(5) |
TTAIL |
Identifies file record type |
File Line Sequence Number |
Number(10) |
line number in file |
ID of current line being created for output file |
|
Transaction Set Control Number |
Number(10) |
sequence number |
Used to force unique file check |
|
Transaction detail line count |
Number(10) |
ID of current line being created for output file |
Sum of the detail lines within a transaction |
|
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Identifier |
Number(10) |
Sequential number Created by program. |
ID of current line being created for output file. |
|
File Record Counter |
Number(10) |
N/A |
Number of records/transactions processed in current file (only records between head & tail) |
SWIFT File Conversion – Letter of Credit Amendment (lcmt707)
Module Name |
lcmt707 |
Description |
SWIFT File Conversion – Letter of Credit Amendment |
Functional Area |
Oracle Retail Trade Management |
Module Type |
Integration |
Module Technology |
Perl |
Catalog ID |
RMS137 |
Wrapper Script |
rmswrap_perl.ksh |
Design Overview
This Perl script converts the Oracle retail standard interface file format for Amendments to Letters of Credit download to the corresponding S.W.I.F.T file format (MT 707). The input file for this Perl script is the output of the lcmdnld.pc Merchandising batch.
I/O Specification
Integration Type |
Download to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000053 (input) IntCon000138 (output) |
Output
The SWIFT MT 707 output file should be in the following format:
-
Most output fields are contained in their own line (or 3-4 line for addresses).
-
Each amendment consists of only one part, the MT 707. There may be several MT 707s at any given time associated to an LC because they are grouped by amendment number at the time of creation. All TDETL records with the same amend_no will be grouped together in one MT 707.
-
Each record starts with a colon and a SWIFT field identifier, followed by another colon: for example, ‘:40A:'-
-
Each amendment is separated by a line with only the ASCII 3 symbol (a heart) on it.
Logic Setup:
The input file will be in standard Merchandising file format. It will potentially have numerous TDETL lines per each THEAD line. There may be numerous TDETL records for one amendment. MT 707 will write one record for each amendment, so if there are multiple TDETL records they need to be combined. There is one TTEXT for each TDETL.
There are three values that need to be calculated. 32B, 33B, 34B. 32B is the total increment or the sum of the positive effect values for each amendment. 33B is the total decrement or the sum of all the negative effect values for each amendment. 32B and 33B are separate totals for each amendment. 34B is the total difference, so it is the sum of the total increment and total decrement. 34B is not just for one amendment though; it is for all amendments of a THEAD record, so this total will run through each TDETL in a THEAD.
For example: if the input file contains:
-
THEAD
-
TDETL amendment 1, effect +1000
-
TTEXT
-
TDETL amendment 1, effect +500
-
TTEXT
-
TDETL amendment 2, effect -2500
-
TTEXT
-
TDETL amendment 3, effect +4000
-
TTEXT
-
TDETL amendment 3, effect -1000
-
TTEXT
-
TDETL amendment 3, effect +500
-
TTEXT
-
TDETL amendment 4, effect -1000
-
TTEXT
-
TDETL amendment 4 , effect –2500
-
TTEXT
-
TTAIL
32B for amendment 1 = 1500 33B for amendment 1 = 0 34B for amendemnt 1 = 1500 32B for amendment 2 = 0 33B for amendment 2 = 2500 34B for amendemnt 2 = -1000 32B for amendment 3 = 4500 33B for amendment 3 = 1000 34B for amendemnt 3 = 4500 32B for amendment 4 = 0 33B for amendment 4 = 3500 34B for amendemnt 4 = 1000
Examples of how individual lines of the M T 707 should look:
APPLICANT: OPERATOR: OPERATION DATE: OPERATION TIME: TEST KEY: BATCH TOTAL: SEGMENT TOTAL: MT/PRIORITY:707 02 :27:1/1 :20:10001981 :21:1981 :52D:Bank One 100 Bank One Way Columbus ,OH 41984 US :31C:990204 :30:990204 :26E:1 :59:David Fashion Creations P/L Pack Wholesale Division 109 Ackland St. St. Kilda ,VA 30280-1234 US :32B:USD500,0 :33B:USD0,0 :34B:USD500,0 :79:Letter of Credit: has been changed from 25 to 30 for Style 10049369, resulting in an effect of 500 (USD).
The layout of the S.W.I.F.T MT 707 (Amendment to a Documentary Credit) file is as follows:
SWIFT I.D. DATA TYPE CODES (refer to SWIFT User Handbook – Standards General Information – October 1998 release for formatting information):
Note:
The field lengths and types in the Oracle Retail Standard Download Format of the MT 707 are important because sometimes they are different from the information that is being placed in them and the fields may have to be truncated, rounded, and so on.
There is always a new line (nl) after every individual SWIFT ID (and there may be more than one line within an individual field (example 59 - Beneficiary, four lines to hold address information).
In some situations, certain fields will be blank. These fields should be skipped over. In other words, no blank line or tag should be printed indicating the field is blank. Simply ignore it.
SWIFT File Conversion - Letter of Credit Application (lcmt700)
Module Name |
lcmt700 |
Description |
SWIFT File Conversion – Letter of Credit Application |
Functional Area |
Oracle Retail Trade Management |
Module Type |
Integration |
Module Technology |
Perl |
Catalog ID |
RMS136 |
Wrapper Script |
rmswrap_perl.ksh |
Design Overview
This Perl script will convert the standard Merchandising flat file into the bank specific S.W.I.F.T. MT 700 output files. The input file for this Perl script is the output of the lcadnld.pc Merchandising batch. One output file will be created for each issuing bank in the lcadnld.pc output file.
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000052 (input) IntCon000137 (output) |
Output
All files layouts input and output the SWIFT MT 700. The output file should be in the following format:
-
Most output fields are contained in their own line (or 3-4 line for addresses).
-
Each application consists of four parts, one MT 700 and three MT 701s, which are ordered through the Sequence of Total field: for example, ':27:1/4 MT 700' is the first (MT 700) part of the application.
-
MT 700 and MT 701s will be mingled in the same file.
-
Each record starts with a colon and a SWIFT field identifier, followed by another colon: for example, ':40A:'-
-
Each application is separated by a line with only the ASCII 3 symbol (a heart) on it.
Examples of how individual lines of the MT 700 or MT 701 should look:
:27:1/4 :40A:IRREVOCABLE :20:29893098 :23:NOREF :31C:910906 :31D:911022DALLAS :51D:NORTHERN TRUST INT'L BANKING CORP. ONE WORLD TRADE CENTER SUITE 3941 NY, NY 10048 USA
The layout of the S.W.I.F.T MT 700 (Issue of a Documentary Credit) file is as follows:
SWIFT I.D. DATA TYPE CODES (refer to SWIFT User Handbook - Standards general Information - October 1998 release for formatting information):
Note:
There is always a new line (nl) after every individual SWIFT ID (and there may be more than one line within an individual field [for example, 59 – Beneficiary, four lines to hold address information]).
In some situations, certain fields will be blank. These fields should be skipped over. In other words, no blank line or tag should be printed indicating the field is blank. Simply ignore it.
Invoices
Merchandising has scheduled integration for the following invoices for communication with Oracle Retail Invoice Matching Cloud Service:
Download of Invoice for Invoice Matching (edidlinv)
Module Name |
edidlinv.pc |
Description |
Download of Invoice For Invoice Matching |
Functional Area |
Invoice Matching |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS127 |
Wrapper Script |
rmswrap_multi_out.ksh |
Design Overview
The EDIDLINV program extracts invoice information from Merchandising invoice tables (INVC_HEAD, INVC_DETAIL) to a flat file. This flat file is used by Invoice Matching to upload invoice data into tables such as IM_DOC_HEAD, IM_INVOICE_DETAIL and IM_DOC_NON_MERCH. This batch program is run daily, extracting invoice records whose invoice date falls on the current vdate.
If the batch is run ad hoc, there may be issues when consignment invoices are generated as the sales process can also run multiple times a day. Invoice information can potentially be not the latest when the extract is generated.
Restart/Recovery
Restart/recovery for this program is set up at the invoice ID and line sequence level. The program resumes writing to file starting on the next line where the previous process ended.
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000024 |
Output File Layout
Table 6-18 edidlinv.pc - Output File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record descriptor |
Char(5) |
FHEAD |
Describes file record type. Valid value is FHEAD. |
Line id |
Number(10) |
0000000001 |
Sequential file line number. |
|
Gentran ID |
Char(5) |
UPINV |
The type of transaction this file represents. Valid value is UPINV. |
|
Current date |
Char(14) |
Vdate in YYYYMMDDHH24MISS format. |
||
File Version |
Number(2) |
03 |
Numeric number of the file version to backward compatibility. Starting with 2, incremented by 1 each time the file format changes |
|
THEAD |
Record descriptor |
Char(5) |
Describes file record type. Valid value is THEAD. |
|
Line id |
Number (10) |
Sequential file line number. |
||
Transaction number |
Number(10) |
Sequential transaction number. All records within this transaction will also have this transaction number. |
||
Document Type |
Char(6) |
Describes the type of document being uploaded. The document type will determine the types of detail information that are valid for the document upload. Invoice types are held on the codes table under a code type of 'IMIT'. |
||
Vendor Document Number |
Char (50) |
Vendor’s document number. |
||
Group ID |
Char(10) |
NULL |
The Group ID is an informational field, which can be used to identify groups of invoices that were transmitted to Invoice Matching together. This is not populated by Merchandising. |
|
Vendor Type |
Char(6) |
Type of vendor (either supplier or partner) for this document. Valid values include Bank 'BK', Agent 'AG', Freight Forwarder 'FF', Importer 'IM', Broker 'BR', Factory 'FA', Applicant 'AP', Consolidator 'CO', Consignee 'CN', Supplier Hierarchy Level 1 'S1', Supplier Hierarchy Level 2 'S2', and Supplier Hierarchy Level 3 'S3'. These partner types will be held on the codes table under the code_type 'PTAL'. |
||
Vendor ID |
Char(10) |
Vendor for this document. |
||
Vendor Document Date |
Char(14) |
Date document was issued by the vendor (in YYYYMMDDHH24MISS format). |
||
Order Number / RTV order number |
Number(12) |
Merchandising system order number for this document. Required for merchandise invoices and optional for others. This field can also contain the RTV order number if the RTV flag is ‘Y’ |
||
Location |
Number(10) |
Merchandising system location for this document. |
||
Location Type |
Char(1) |
Merchandising system location type (either ‘S’tore or ‘W’arehouse) for this document. Required for merchandise invoices and optional for others. |
||
Terms |
Char(15) |
Terms of this document. If terms are not provided, the vendor’s default terms will be associated with this record. |
||
Due Date |
Char(14) |
Date the amount due is due to the vendor (YYYYMMDDHH24MISS format). If due date is not provided, default due date is calculated based on vendor and terms. |
||
Payment method |
Char(6) |
Method for paying this document. |
||
Currency code |
Char(3) |
Currency code for all monetary amounts on this document. |
||
Exchange rate |
Number(20,4) |
Exchange rate *10000 (implied 4 decimal places) for conversion of document currency to the primary currency. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) total cost amount. |
||
Total Cost |
Number(20,4) |
Total document cost *10000 (implied 4 decimal places), including all items and costs on this document. This value is in the document currency. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) total tax amount. |
||
Total Tax Amount |
Number(20,4) |
Total TAX amount *10000 (implied 4 decimal places), including all items and costs on this document. This value is in the document currency. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) total quantity amount. |
||
Total Quantity |
Number(12,4) |
Total quantity of items *10000 (implied 4 decimal places) on this document. This value is in EACHES (no other units of measure are supported in Invoice Matching). |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) total discount amount. |
||
Total Discount |
Number(12,4) |
Total discount *10000 (implied 4 decimal places) applied to this document. This value is in the document currency. |
||
Freight Type |
Char(6) |
NULL |
The freight method for this document. Always blank. |
|
Paid Ind |
Char(1) |
Indicates if this document has been paid. |
||
Multi-Location |
Char(1) |
N |
Indicates if this invoice goes to multiple locations. |
|
Merchandise Type |
Char(1) |
Indicates if this invoice is a consignment invoice. |
||
Deal Id |
Number(10) |
NULL |
Deal Id from Merchandising if this invoice is a deal bill back invoice. Always blank. |
|
Deal Detail Id |
Char(10) |
NULL |
Complex Deal Component Id. Always blank from Merchandising. |
|
Ref CNR Ext Doc Id |
Char(50) |
NULL |
Reference to the External Id of Credit Note Request associated with this document. Always blank from Merchandising. |
|
Ref INV Ext Doc Id |
Char(50) |
NULL |
Reference to the External Id of Invoice associated with this document. Always blank from Merchandising. |
|
Deal Approval Indicator |
Char(1) |
NULL |
Indicates if the document on IM_DOC_HEAD is to be created in Approved or Submitted status. Always blank from Merchandising. |
|
RTV indicator |
Char(1) |
Indicates if this invoice is a RTV invoice. |
||
Custom Document Reference 1 |
Char(90) |
NULL |
This optional field is included in the upload file for client customization. No validation will be performed on this field. Always blank from Merchandising. |
|
Custom Document Reference 2 |
Char(90) |
NULL |
This optional field is included in the upload file for client customization. No validation will be performed on this field. Always blank from Merchandising. |
|
Custom Document Reference 3 |
Char(90) |
NULL |
This optional field is included in the upload file for client customization. No validation will be performed on this field. Always blank from Merchandising. |
|
Custom Document Reference 4 |
Char(90) |
NULL |
This optional field is included in the upload file for client customization. No validation will be performed on this field. Always blank from Merchandising. |
|
Cross-reference document number |
Number(10) |
Document that a credit note is for. Blank for all document types other than merchandise invoices. |
||
Third-Party Payee |
Number(10) |
NULL |
This optional field is included in the upload file for client customization. No validation will be performed on this field. Always blank from Merchandising. |
|
TDETL |
Record descriptor |
Char(5) |
Describes file record type. Valid value is TDETL. |
|
Line id |
Number(10) |
Sequential file line number. |
||
Transaction number |
Number(10) |
Transaction number for this item detail record. |
||
UPC |
Char(25) |
NULL |
UPC for this detail record. Valid item number will be retrieved for the UPC. Always blank from Merchandising. |
|
UPC Supplement |
Number(5) |
NULL |
Supplement for the UPC. Always blank from Merchandising. |
|
Item |
Char(25) |
Item for this detail record. |
||
VPN |
Char(30) |
NULL |
Vendor Product Number which can (optionally) be used instead of the Oracle Retail Item Number. |
|
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) Original Document Quantity amount. |
||
Original Document Quantity |
Number(12,4) |
Quantity *10000 (implied 4 decimal places), in EACHES, of the item on this detail record. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) Original Unit Cost amount. |
||
Original Unit cost |
Number(20,4) |
Unit cost *10000 (implied 4 decimal places), in document currency, of the item on this detail record. |
||
Original Tax Code |
Char (6) |
Tax code for item. This will be Blank if the SYSTEM_OPTIONS.DEFAULT_TAX_TYPE is GTS. |
||
Original Tax rate |
Number (20,10) |
Tax Rate for the Tax code/item. This will be Blank if the SYSTEM_OPTIONS.DEFAULT_TAX_TYPE is GTS. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) total allowance. Default is “+” if no allowances exist for this detail record. |
||
Total Allowance |
Number(20,4) |
Sum of allowance details for this item detail record *10000 (implied 4 decimal places). If no allowances exist for this item detail record, value will be 0. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) for Tax Basis. Always blank from Merchandising. |
||
Tax Basis |
Number (20,4) |
Specify the basis for which this tax should be calculated. If not provided and tax calc type is ‘P’, use the qty * unit cost as basis. Always blank from Merchandising. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) for Per Unit Tax. Per Unit tax will be negative on Debit Memos, Credit Note Requests, and Credit Notes since quantity is always positive. Always blank from Merchandising. |
||
Per Unit Tax |
Number (20,4) |
Used to calculate the tax amount when tax rate type is ‘U’. Tax amount = quantity * per unit tax. (Quantity is the quantity of the item). Always blank from Merchandising. |
||
TDTLT |
Record descriptor |
Char(5) |
Describes file record type. Valid value is TDTLT. This record will be populated only if SYSTEM_OPTIONS.DEFAULT_TAX_TYPE is GTS. |
|
Line id |
Number(10) |
Sequential file line number. |
||
Transaction number |
Number(10) |
Transaction number for this item tax detail record. |
||
UPC |
Char(25) |
NULL |
UPC for this detail record. Valid item number will be retrieved for the UPC. Always blank from Merchandising. |
|
UPC Supplement |
Number(5) |
NULL |
Supplement for the UPC. Always blank from Merchandising. |
|
Item |
Char(25) |
Item for this tax detail record. |
||
VPN |
Char(30) |
NULL |
Vendor Product Number which can (optionally) be used instead of the Oracle Retail Item Number. |
|
Original Tax Code |
Char (6) |
Tax code for item. |
||
Original Tax rate |
Number (20,10) |
Tax Rate for the Tax code/item |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) for Tax Basis. |
||
Tax Basis |
Number (20,4) |
Specify the basis for which this tax should be calculated. If not provided and tax calc type is ‘P’, use the qty * unit cost as basis. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) for Per Unit Tax. Per Unit tax will be negative on Debit Memos, Credit Note Requests, and Credit Notes since quantity is always positive. |
||
Per Unit Tax |
Number (20,4) |
Used to calculate the tax amount when tax rate type is ‘U’. Tax amount = quantity * per unit tax. (Quantity is the quantity of the item). |
||
TNMRC |
Record descriptor |
Char(5) |
Describes file record type. Valid value is TNMRC. |
|
Line id |
Number (10) |
Sequential file line number. |
||
Transaction number |
Number(10) |
Transaction number for this non-merchandise record. |
||
Non Merchandise Code |
Char(6) |
Non-Merchandise code that describes this cost. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) Non Merchandise Amt. |
||
Non Merchandise Amt |
Number(20,4) |
Cost *10000 (implied 4 decimal places) in the document currency. |
||
Non Merch TAX Code |
Char (6) |
Tax Code for Non-Merchandise. This will be Blank if the SYSTEM_OPTIONS.DEFAULT_TAX_TYPE is GTS. |
||
Non Merch Tax Rate at this TAX code |
Number (20, 10) |
Tax Rate corresponding to the Tax code. This will be Blank if the SYSTEM_OPTIONS.DEFAULT_TAX_TYPE is GTS. |
||
Service Performed Indicator |
Char(1) |
Indicates if a service has actually been performed. |
||
Store |
Number(10) |
Store at which the service was performed. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) for Tax Basis. Always blank from Merchandising. |
||
Tax Basis |
Number (20,4) |
Specify the basis for which this tax should be calculated. Always blank from Merchandising. |
||
TNMRT |
Record descriptor |
Char(5) |
Describes file record type. Valid value is TNMRT. This record will be populated only if SYSTEM_OPTIONS.DEFAULT_TAX_TYPE is GTS. |
|
Line id |
Number (10) |
Sequential file line number. |
||
Transaction number |
Number(10) |
Transaction number for this non-merchandise record. |
||
Non Merchandise Code |
Char(6) |
Non-Merchandise code that describes this cost. |
||
Non Merch TAX Code |
Char (6) |
Tax Code for Non-Merchandise. |
||
Non Merch Tax Rate at this TAX code |
Number (20, 10) |
Tax Rate corresponding to the Tax code. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) for Tax Basis. |
||
Tax Basis |
Number (20,4) |
Specify the basis for which this tax should be calculated. |
||
TVATS |
File record descriptor |
Char(5) |
Marks costs at tax rate line. Valid value is TVATS. |
|
Line id |
Char(10) |
Sequential file line number |
||
Transaction number |
Number(10) |
Transaction number for this tax detail record. |
||
TAX code |
Char(6) |
Tax code that applies to cost |
||
TAX rate |
Number (20,10) |
Tax Rate corresponding to the Tax code. In case of SYSTEM_OPTIONS.DEFAULT_TAX_TYPE being GTS, this will be populated only when the tax calc type is 'P'. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) Original Document Quantity amount. In case of SYSTEM_OPTIONS.DEFAULT_TAX_TYPE being GTS, this will be populated only when the tax calc type is 'P'. |
||
Cost at this TAX code |
Number (20,4) |
Total amount *10000 (implied 4 decimal places) that must be taxed at the above TAX code. In case of SYSTEM_OPTIONS.DEFAULT_TAX_TYPE being GTS, this will be populated only when the tax calc type is 'P'. |
||
Sign Indicator |
Char(1) |
Indicates either a positive (+) or a negative (-) for Tax Amount. This will be calculated only if the SYSTEM_OPTIONS.DEFAULT_TAX_TYPE is GTS. |
||
Total Tax Amount |
Number (20,4) |
Invoice level total tax amount * 1000 (implied 4 decimal places) for the tax code. It includes both merchandise and non-merchandise taxes. This will be calculated only if the SYSTEM_OPTIONS.DEFAULT_TAX_TYPE is GTS. RMS will sum up the values in the Merch Tax Detail (i.e. TDTLT) and the Non-Merch Tax Detail (i.e. TNMRT) and aggregate it by Tax Code and Tax Rate if the tax calc type is 'P' and aggregate it by Tax Code if the tax calc type is 'U'. |
||
TTAIL |
Record descriptor |
Char(5) |
Describes file record type. Default value is TTAIL. |
|
Line id |
Number(10) |
Sequential file line number. |
||
Transaction number |
Number(10) |
Transaction number for the transaction that this record is closing. |
||
Transaction lines |
Number(6) |
Total number of detail lines within this transaction. |
||
FTAIL |
Record descriptor |
Char(5) |
Describes file record type. |
|
Line id |
Number(10) |
Sequential file line number. |
||
Number of lines |
Number(10) |
Total number of lines within this file excluding FHEAD and FTAIL. |
Stage Complex Deal Invoice Information (vendinvc)
Module Name |
vendinvc.pc |
Description |
Stage Complex Deal Invoice Information |
Functional Area |
Deals |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS122 |
Wrapper Script |
rmswrap.ksh |
Design Overview
The batch module creates records in invoice match staging tables dealing for complex type deals.
The invoicing logic will be driven from the billing period estimated next invoice date for complex deals. The amount to be invoiced will be the sum of the income accruals of the deal since the previous invoice date (or the deal start date for the first collection).
prepost vendinvc pre - truncates STAGE_COMPLEX_DEAL_HEAD and STAGE_COMPLEX_DEAL_DETAIL tables to remove previous days records.
prepost vendinvc post - calls the process_deal_head() function to update est_next_invoice_date of the deal to NULL.
Stage Fixed Deal Invoice Information (vendinvf)
Module Name |
vendinvc.pc |
Description |
Stage Complex Deal Invoice Information |
Functional Area |
Deals |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS123 |
Wrapper Script |
rmswrap_multi.ksh |
Design Overview
The batch module creates records in staging tables dealing for fixed type deals.
The invoicing logic will be driven by the collection dates for fixed deals. The amount to be invoiced will be retrieved directly from fixed deal tables for a given deal date.
prepost vendinvf pre - truncates STAGE_FIXED_DEAL_HEAD and STAGE_FIXED_DEAL_DETAIL tables to remove previous days records.
prepost vendinvf post – calls the process_fixed_deal function to update the status of the fixed deal claim to ‘I' (inactive)
Restart/Recovery
Data is committed to the database once the number of transactions processed reaches or exceeds the max_commit_ctr.
Inventory
Merchandising has scheduled integration for inventory and sales data through the following processes:
Download Sales and Stock on Hand to Suppliers (edidlprd)
Module Name |
edidlprd.pc |
Description |
Download Sales and Stock On Hand to Suppliers |
Functional Area |
Inventory |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS47 |
Wrapper Script |
rmswrap_multi_out.ksh |
Design Overview
This program is used to transmit item-level sales and stock-on-hand information to vendors. The report is a summary that will be sent to specified suppliers through EDI, giving sales details, as well as current stock on hand and in transit for all locations for each of the items supplied by that supplier. Only those suppliers which have an EDI sales reporting frequency of either daily or weekly will have files generated by this program. The system parameter EDI Daily Report Lag is used for suppliers receiving daily updates to determine the day lag for sales data sent, to account for late posting sales.
Restart/Recovery
Restart/recovery in this program is achieved through utilizing a global temporary table. Once a supplier is processed, it is deleted from the temporary table to prevent the same supplier from being processed again during recovery.
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000013 |
Output File Layout
Table 6-19 edidlprd.pc - Output File
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
File record descriptor |
Char(5) |
FHEAD |
Describes record type |
Line number |
Number(10) |
0000000001 |
Sequential file line number |
|
File source |
Char(5) |
DLPRD |
File Type |
|
File create date |
Char(8) |
N/A |
Date that the file was created in YYYYMMDD format |
|
THEAD |
File record descriptor |
Char(5) |
THEAD |
Identifies record type |
Line number |
Number(10) |
N/A |
Sequential file line number |
|
Transaction number |
Number(10) |
N/A |
Sequential transaction number |
|
Report date |
Char(8) |
N/A |
For weekly reporting, this will contain the current date. For daily reporting, it will be the date represented by the sales, current date – lag days. Both will be in the YYYYMMDD format |
|
Supplier |
Number(10) |
N/A |
Merchandising Supplier Number |
|
TITEM |
File record descriptor |
Char(5) |
TITEM |
Identifies file record type |
Line number |
Number(10) |
N/A |
Sequential file line number |
|
Transaction number |
Number(10) |
N/A |
Sequential transaction number |
|
Item |
Char(25) |
N/A |
Transaction level item to which with the data is related |
|
Item_Num_Type |
Char(6) |
N/A |
Contains the item number type for the item on ITEM_MASTER |
|
Ref_Item |
Char(25) |
N/A |
Contains the primary reference item for the item in the file, if defined |
|
Ref_Item_Num_Type |
Char(6) |
N/A |
Contains the item number type for the reference item from ITEM_MASTER |
|
Vendor catalog number |
Char(30) |
N/A |
Contains the VPN (Vendor Product Number), if defined for the item/supplier |
|
Item description |
Char(250) |
N/A |
Contains the transaction level item description from ITEM_MASTER |
|
TQUTY |
File record descriptor |
Char(5) |
TQUTY |
Identifies record type |
Line number |
Number(10) |
N/A |
Sequential file line number |
|
Transaction number |
Number(10) |
N/A |
Sequential transaction number |
|
Quantity descriptor |
Char(15) |
N/A |
Indicates what the quantity represents, either ‘On-hand' (stock), 'Sold'(sales), or 'In transit' |
|
Location type |
Char(2) |
N/A |
Indicates the type of location represented in the file: ‘ST' for store or ‘WH' warehouse |
|
Location |
Number(10) |
N/A |
Contains the store or warehouse number for which the information applies |
|
Unit cost |
Number(20) |
N/A |
Contains the current unit cost for the item/location with 4 implied decimal places. This value will be in the supplier's currency |
|
Quantity |
Number(12) |
N/A |
Indicates the quantity of the item sold, on hand or in transit to the location; the quantity is represented with 4 implied decimal places |
|
TTAIL |
File record descriptor |
Char(5) |
TTAIL |
Identifies record type |
Line number |
Number(10) |
N/A |
Sequential file line number |
|
Transaction lines |
Number(6) |
N/A |
Number of lines for this transaction |
|
FTAIL |
File record descriptor |
Char(5) |
FTAIL |
Identifies record type |
Line number |
Number(10) |
N/A |
Total number of lines in file |
|
Number of transaction lines |
Number(10) |
N/A |
Number of transaction lines in file |
Future Available Inventory Publication API (BDI_COFutureAvail_Tx_PF_From_RMS_JOB)
This section describes the Future Available Inventory Publication BDI.
Design Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of on-order quantity for all item/location combinations that are flagged as back-orderable in Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
The following packages are impacted:
Bulk Interface Module
In the bulk interface module:
Filename: bdiavinvb.pls
BDI_AV_INV_SQL.CO_FUTURE_AVAIL_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Item Inventory tables/view.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Inventory Publication API (BDI_Inventory_Tx_PF_From_RMS_EOW_JOB)
This section describes the Item Inventory Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of inventory from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
Filename: bdimfpb.pls
BDI_MFP_SQL.INVENTORY_UP(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Item Inventory tables/view.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Item Location History (BDI_ItemLocHist_Tx_PF_From_RMS_JOB)
Module Name |
BDI_ItemLocHist_Tx_PF_From_RMS_JOB |
Description |
Extracts Sales History |
Functional Area |
Sales |
Module Type |
Integration |
Module Technology |
BDI job |
Catalog ID |
N/A |
Runtime Parameters |
ItemLocHist_Tx_ProcessFlow_From_RMS ItemLocHist_Tx_Extractor |
Design Overview
Merchandising extracts item-location sales history on a weekly basis. It utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from Merchandising to an external solution.
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Reject POSU Transactions (salesgenrej.ksh)
Module Name |
salesgenrej.ksh |
Description |
Reject POSU Transactions |
Functional Area |
Sales Posting |
Module Type |
Business Processing |
Module Technology |
KSH |
Catalog ID |
RMS338 |
Wrapper Script |
batch_salesgenrej.ksh |
Design Overview
The purpose of this module is to archive the rejected transactions and create a reject file based on the recently processed POSU file which is still in the staging table. It will also generate a retry file based on input parameter (Retry IndicatorFoot 1) if error was due to locking and if the number of attempts does not exceed the retry lock attempt configuration (RMS_PLSQL_BATCH_CONFIG.RETRY_LOCK_ATTEMPT).
Performance Considerations
The number of threads, the amount of waiting time, number for retries, and average volume of data should be considered. RETRY_WAIT_TIME shouldn't be increased significantly.
Reject File:
The module will have the ability to re-process the reject file directly. The file format will therefore be identical to the input file layout. A reject line counter will be kept in the program and is required to ensure that the file line count in the trailer record matches the number of rejected records. If no errors occur, no reject files would be generated.
Store Available Inventory Publication API (BDI_InvAvailStore_Tx_PF_From_RMS_JOB)
This section describes the Store Available Inventory Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Store Address information from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API will be in the form of a PLSQL function inside a PLSQL package.
Package Impact
This section describes the package impact.
Bulk Interface Module
Filename: bdiavinvb.pls
BDI_AV_INV_SQL.ST_AVAIL_INV_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Merchandise Hierarchy tables.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Warehouse Inventory Publication API (BDI_InvAvailWh_Tx_PF_From_RMS_JOB)
This section describes the Warehouse Inventory Publication BDI.
Business Overview
BDI (Bulk Data Integration) is an integration layer that facilitates the bulk transfer of Warehouse Inventory positions from Merchandising to other Oracle Retail Applications. On this particular integration stream, the data flow is from Merchandising to BDI, and then BDI to downstream applications. To accomplish this data transfer, BDI will be calling a Merchandising-owned API that will pull data from Merchandising and deliver these to the BDI integration layer. This API is in the form of a PLSQL function inside a PLSQL package.
Package Impact
This section describes the package impact.
Bulk Interface Module
Filename: bdiavinvb.pls
BDI_AV_INV_SQL.WH_AVAIL_INV_UP(O_error_message IN OUT VARCHAR2, O_control_id IN OUT NUMBER, I_job_context IN VARCHAR2)
This function begins by calling a BDI function that signals the start of the interface process. The BDI function will update the internal BDI control tables to track the progress of the API.
A DML insert statement is then executed to populate the BDI outbound table that resides in the BDI_RMS_INT_SCHEMA schema. This outbound table is loaded with records from the Merchandising Item Location table.
After the insert, another call to a BDI function is performed to signify the successful loading of records. This will update the internal BDI control tables.
A database commit is issued, and the control Id is returned by the API.
Planning and Forecasting
Merchandising provides critical foundation and transactional information to the Oracle Retail planning and forecasting solutions. Because the planning and forecasting solutions are built on the same platform, several of the integrations from Merchandising are used by more than one of the solutions. The tables below summarize the key outbound integration points by solution.
Table 6-20 Integration to Oracle Retail Merchandise Financial Planning Cloud Service (MFPCS)
Description | Program |
---|---|
Calendar Extract to Planning and Forecasting |
BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB |
Currency Rates Extract to Planning and Forecasting |
BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB |
Inventory Extract to Planning |
BDI_MFP_Inventory_Tx_PF_From_RMS_JOB |
Merchandise Hierarchy and Item Extract to Planning and Forecasting |
BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB |
On Order Extract to Planning |
BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB |
Organization Hierarchy Extract to Planning and Forecasting |
BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB |
Store Extract to Planning and Forecasting |
BDI_RPAS_Store_Fnd_PF_From_RMS_JOB |
Transaction Data Extract to Planning |
BDI_MFP_TranData_Tx_PF_From_RMS_JOB |
Table 6-21 Integration to Oracle Retail Assortment and Item Planning for Fashion/ Softlines Cloud Service (A&IP CS)
Description | Program |
---|---|
Brand Extract to Planning |
BDI_RPAS_Brand_Fnd_PF_From_RMS_JOB |
Calendar Extract to Planning and Forecasting |
BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB |
Currency Rates Extract to Planning and Forecasting |
BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB |
Differentiator Extract to Planning |
BDI_RPAS_Diff_Fnd_PF_From_RMS_JOB |
Inventory Extract to Planning |
BDI_MFP_Inventory_Tx_PF_From_RMS_JOB |
Merchandise Hierarchy and Item Extract to Planning and Forecasting |
BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB |
On Order Extract to Planning |
BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB |
Organization Hierarchy Extract to Planning and Forecasting |
BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB |
Store Extract to Planning and Forecasting |
BDI_RPAS_Store_Fnd_PF_From_RMS_JOB |
Supplier Extract to Planning |
BDI_RPAS_Supplier_Fnd_PF_From_RMS_JOB |
Transaction Data Extract to Planning |
BDI_MFP_TranData_Tx_PF_From_RMS_JOB |
UDA Extract to Planning |
BDI_RPAS_UdaAndUdaValues_Fnd_PF_From_RMS_JOB |
UDA Item Extract to Planning and Forecasting |
BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB |
Table 6-22 Integration to Oracle Retail Demand Forecasting Cloud Service (RDFCS)
Description | Program |
---|---|
Calendar Extract to Planning and Forecasting |
BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB |
Merchandise Hierarchy and Item Extract to Planning and Forecasting |
BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB |
Organization Hierarchy Extract to Planning and Forecasting |
BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB |
Out of Stock Extract to Forecasting |
BDI_RDF_StockOut_Tx_PF_From_RMS_JOB |
Store Extract to Planning and Forecasting |
BDI_RPAS_Store_Fnd_PF_From_RMS_JOB |
UDA Item Extract to Planning and Forecasting |
BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB |
Weekly Sales Extract to Forecasting |
BDI_RDF_WeeklySales_Tx_PF_From_RMS_JOB |
Brand Extract to Planning (BDI_RPAS_Brand_Fnd_PF_From_RMS_JOB)
Module Name |
BDI_RPAS_Brand_Fnd_PF_From_RMS_JOBbdi_merch_extract_to_file_wrapper.shbdi_rpas_brand_extract.ksh |
Description |
Extracts Brand information to Planning |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI job, shell scripts |
Catalog ID |
N/A |
Runtime Parameters |
Brand_Fnd_ProcessFlow_From_RMSBrand_Fnd_ExtractorDatabase connection, download file location, filename, trigger filename |
Design Overview
This process extracts its brand data to Planning on a weekly basis.
Key assumptions for this integration:
-
The full set of brands is included in this integration each time it runs.
-
Retailers will not create a Diff with an ID of 'BRAND'.
-
In order to meet the format required by Planning, the UDA description in this extract is hard coded to "Brand" and does not take into account the primary language configuration in Merchandising.
-
The intended targets for this integration are
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This process utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement to Planning. The batch job BDI_RPAS_Brand_Fnd_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RPAS_Brand_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts Brand information and writes it out to a flat file for processing by AP and IP."/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RPAS_Brand_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (Brand_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor job (Brand_Fnd_Extractor) calls BDI_FOUNDATION_SQL.BRAND_UP function to extract data from Merchandising table BRAND to BDI outbound staging table BRAND_OUT.
-
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_brand_extract.ksh to write brand information from the BRAND_OUT table into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated locations as configured via BDI system options:
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
BRAND |
Yes |
No |
No |
No |
BRAND_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
UDA_ID |
Char(6) |
Yes |
Hardcoded to 'BRAND' |
UDA_DESC |
Char(120) |
Yes |
Hardcoded to 'Brand' |
BRAND_NAME |
Char(30) |
Yes |
The brand ID from the Merchandising Brand table. |
BRAND_DESCRIPTION |
Char(120) |
Yes |
The brand description in the primary language from the Merchandising Brand table. |
Calendar Extract to Planning and Forecasting (BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB)
Note:
This module replaces the ftmednld.pc module from previous releases.
Module Name |
BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB |
Description |
Extracts calendar information to RPAS from RMS |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI job |
Catalog ID |
N/A |
Runtime Parameters |
Calendar_Fnd_ProcessFlow_From_RMS Calendar_Fnd_Extractor |
Design Overview
This program extracts calendar data to planning and forecasting on a weekly basis.
Key assumptions for this integration:
-
The last two years, current year, and two years into the future are extracted each time this process is run.
-
A data set is sent each time the extract runs.
-
This extract supports a 4-5-4 calendar only.
-
The intended targets for this integration are
-
Oracle Retail Merchandise Financial Planning Cloud Service (MFPCS)
-
Oracle Retail Demand Forecasting Cloud Service (RDFCS)
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This program utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from Merchandising to the target applications.
The batch job BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts calendar information and writes it out to a flat file for processing by both MFP and RDF."/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RPAS_Calendar_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (Calendar_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor job (Calendar_Fnd_Extractor) calls BDI_FOUNDATION_SQL.CALENDAR_UP function to extract data from Merchandising view V_BDI_DAY_LEVEL_CALENDAR to BDI outbound staging table CALENDAR_OUT.
-
A generic BDI Downloader file creator job writes calendar information from the CALENDAR_OUT table into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. Separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated locations as configured via BDI system options:
-
MFP_outboundLocation
-
RDF_outboundLocation
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
V_BDI_DAY_LEVEL_CALENDAR |
Yes |
No |
No |
No |
CALENDAR_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
DAY |
Date |
Yes |
The date for which the data was derived, in YYYYMMDD format |
WEEK |
Date |
Yes |
The end of week date for the day, in YYYYMMDD format |
MONTH |
Number(2) |
Yes |
The month number of the day in the year; valid values 1-12 |
QUARTER |
Number(1) |
Yes |
The quarter of the year for the day; valid values 1-4 |
HALF |
Number(1) |
Yes |
The half of the year for the day; valid values are 1 or 2 |
YEAR |
Number(4) |
Yes |
The year for the day (YYYY format). |
WEEK_OF_YEAR |
Number(2) |
Yes |
The week of the year for the day; valid values 1-53 |
DAY_OF_WEEK |
Number(1) |
Yes |
The day number within the week; valid values 1-7. |
Currency Rates Extract to Planning and Forecasting (BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB)
Module Name |
BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB bdi_merch_extract_to_file_wrapper.sh bdi_rpas_curr_conv_rates_extract.ksh |
Description |
Extracts currency rates information to RPAS |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI job, shell scripts |
Catalog ID |
N/A |
Runtime Parameters |
CurrConvRates_Fnd_ProcessFlow_From_RMS CurrConvRates_Fnd_Extractor Database connection, download file location, filename, trigger filename |
Design Overview
This program extracts its currency rates data to planning and forecasting on a weekly basis.
Key assumptions for this integration:
-
Only currency rates for which stores and warehouse exist will be included in the extract.
-
Either the consolidated or operational rate will be sent based on the setting of the Consolidation system option. If Y, then the consolidation rates will be sent. If N, then the operational rates are used.
-
All applicable currency rates are sent each time this process is run.
-
The rates sent in this integration are based on a materialized view. The process that refreshes this view (batch_rfmvcurrconv.ksh) must be scheduled to ensure that the latest currency information is sent each week.
-
The intended targets for this integration are
-
Oracle Retail Merchandise Financial Planning Cloud Service (MFPCS)
-
Oracle Retail Demand Forecasting Cloud Service (RDFCS)
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This program utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from Merchandising to the target applications.
The batch job BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts currency conversion rate information and writes it out to a flat file for processing by both MFP and RDF."/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RPAS_CurrConvRates_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (CurrConvRates_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor job (CurrConvRates_Fnd_Extractor) calls BDI_FOUNDATION_SQL.CURR_CONV_RATES_UP function to extract data from Merchandising view MV_CURRENCY_CONVERSION_RATES to BDI outbound staging table CURR_CONV_RATES_OUT.
-
Only the currencies for which stores and warehouses exist in Merchandising will be extracted.
-
Either consolidated or operational rates will be included based on Merchandising system options (consolidation_ind).
-
-
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_curr_conv_rates_extract.ksh to write currency rates information from the CURR_CONV_RATES_OUT table into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. Separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated locations as configured via BDI system options:
-
MFP_outboundLocation
-
RDF_outboundLocation
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date |
Scheduling Considerations |
N/A |
Pre-Processing |
batch_rfmvcurrconv.ksh |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
MV_CURRENCY_CONVERSION_RATES |
Yes |
No |
No |
No |
SYSTEM_OPTIONS |
Yes |
No |
No |
No |
CURR_CONV_RATES_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
EFFECTIVE_DATE |
Date |
Yes |
Holds the effective date of the exchange rate for the currencies and the exchange type |
FROM_CURRENCY_CODE |
Char(3) |
Yes |
Holds the convert from currency code. |
TO_CURRENCY_CODE |
Char(3) |
Yes |
Holds the convert to currency code. |
EXCHANGE_TYPE |
Char(1) |
Yes |
Identifies the type of exchange rate. This will be either C (consolidation) or O (operational). |
EXCHANGE_RATE |
Number(20,10) |
Yes |
Contains the exchange rate between the from and to currencies for the specified exchange type on the next effective date. It is expressed in terms of the to-currency. |
Differentiator Extract to Planning (BDI_RPAS_Diff_Fnd_PF_From_RMS_JOB)
Module Name |
BDI_RPAS_Diff_Fnd_PF_From_RMS_JOBbdi_merch_extract_to_file_wrapper.shbdi_rpas_diff_extract.ksh |
Description |
Extracts Diff Types and Diff ID information to Planning |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI job, shell scripts |
Catalog ID |
N/A |
Runtime Parameters |
Diff_Fnd_ProcessFlow_From_RMS Diff_Fnd_Extractor Database connection, download file location, filename, trigger filename |
Design Overview
This process extracts its differentiator data to Planning on a weekly basis.
Key assumptions for this integration:
-
The full set of differentiators and diff types are included in this integration each time it runs.
-
The intended targets for this integration are
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This process utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement to Planning. The batch job BDI_RPAS_Diff_Fnd_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RPAS_Diff_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts Diff Types and Diff ID information and writes it out to a flat file for processing by AP and IP."/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RPAS_Diff_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (Diff_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor job (Diff_Fnd_Extractor) calls BDI_CROSS_PILLAR_SQL.DIFF_UP function to extract data from DIFF_IDS and DIFF_TYPE to BDI outbound staging table DIFF_OUT.
-
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_diff_extract.ksh to write differentiator information from the DIFF_OUT table into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. Separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated locations as configured via BDI system options:
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
DIFF_IDS |
Yes |
No |
No |
No |
DIFF_TYPE |
Yes |
No |
No |
No |
DIFF_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
DIFF_TYPE_ID |
Char(6) |
Yes |
The ID of the diff type (for example, C for color). |
DIFF_TYPE_DESC |
Char(120) |
Yes |
The description of the diff type (for example, Color) in the primary language. |
DIFF_ID |
Char(10) |
Yes |
The ID of the diff (for example, S for Small). |
DIFF_DESC |
Char(120) |
Yes |
The description of the diff (for example, Small) in the primary language. |
Inventory Extract to Planning (BDI_MFP_Inventory_Tx_PF_From_RMS_JOB)
Module Name |
BDI_MFP_Inventory_Tx_PF_From_RMS_JOB |
Description |
Extracts inventory information to Planning |
Functional Area |
Inventory |
Module Type |
Integration |
Module Technology |
BDI job |
Catalog ID |
N/A |
Runtime Parameters |
Inventory_Tx_ProcessFlow_From_RMS Inventory_Tx_Extractor |
Design Overview
This process extracts owned inventory information for inventoried, non-pack approved transaction items to planning on a weekly basis, at the end of the week. The integration captures the current on-hand and in-transit for all the included item/locations at the point in time that the integration is run.
Key assumptions for this integration:
-
Only inventoried, approved transaction items are included in the integration.
-
Any inventory for pack items is aggregated with inventory for the component items.
-
Only stockholding stores are included in the integration.
-
Cost values are based on system configuration for cost:
-
For a cost department with the system configured for average cost, the cost basis is the item/location's weighted average cost, converted to primary currency.
-
For a cost department with the system configured for standard cost, the cost basis is the item/locations unit cost, converted to primary currency.
-
For a retail department, the cumulative mark-on percentage is used to calculate cost based on the retail price, converted to primary currency.
-
-
Retail values sent are based on the current item/location retail price, converted to primary currency. The retail will include VAT if the system option to include VAT in the stock ledger is set to include VAT so that the retail values in this integration are consistent with other data sent to planning.
-
All unit values are sent in terms of the standard unit of measure for the item.
-
Planning will interpret inventory as being clearance if the clearance flag sent in this integration shows the item/location to be on clearance at the end of the week.
-
The intended targets for this integration are
-
Oracle Retail Merchandise Financial Planning Cloud Service (MFPCS)
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This process utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from Merchandising to the target applications. The batch job BDI_MFP_Inventory_Tx_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_MFP_Inventory_Tx_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts information regarding inventory for use by the MFP application"/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_MFP_Inventory_Tx_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (Inventory_Tx_ProcessFLow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor job (Inventory_Tx_ExtractorJob) calls BDI_MFP_SQL. INVENTORY_UP function to extract data from Merchandising view V_BDI_MFP_INVENTORY to BDI outbound staging table INVENTORY_OUT.
-
A generic BDI Downloader file creator job writes inventory quantities information from the INVENTORY_OUT table into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated locations as configured via BDI system options:
-
MFP_outboundLocation
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
V_BDI_MFP_INVENTORY |
Yes |
No |
No |
No |
INVENTORY_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
EOW |
Date |
Yes |
Indicates the end of week date that the on order information pertains to. |
ITEM |
Varchar2(25 |
Yes |
Transaction level item only. |
LOCATION |
Number(10) |
Yes |
Could be a store or virtual warehouse. |
LOC_TYPE |
Varchar2(1) |
Yes |
Indicates if the location is a store or warehouse - S = Store; W = Warehouse. |
CLEAR_IND |
Number(1) |
Yes |
Indicates if the item/location is currently on clearance. |
REGULAR_INVENTORY_UNITS |
Number(12,4) |
Yes |
Current owned inventory for the item/location in units based on the standard unit of measure; calculated as stock on hand + pack component stock on hand + in transit + pack component in transit. |
REGULAR_INVENTORY_COST |
Number(20,4) |
Yes |
The cost value of current owned inventory for the item/location; calculated based on unit inventory and the cost basis of the item's department, as described above. |
REGULAR_INVENTORY_RETAIL |
Number(20,4) |
Yes |
The retail value of current owned inventory for the item/location; calculated based on the unit inventory value shown above and the current item/location unit retail. |
UNIT_COST |
Number(20,4) |
Yes |
The current supplier purchase cost for the item/location. |
AV_COST |
Number(20,4) |
Yes |
The current weighted average cost for the item/location. |
UNIT_RETAIL |
Number(20,4) |
Yes |
The current unit retail for the item/location. If the item is on clearance, this would be the clearance price. |
Merchandise Hierarchy and Item Extract to Planning and Forecasting (BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB)
Module Name |
BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB bdi_merch_extract_to_file_wrapper.sh bdi_rpas_merchhier_extract.ksh |
Description |
Extracts merchandise hierarchy and item information to RPAS |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI job, shell scripts |
Catalog ID |
N/A |
Runtime Parameters |
ItemHdrAndMerchHier_Fnd_ProcessFlow_From_RMS ItemHdr_Fnd_Extractor Database connection, download file location, filename, trigger filename |
Design Overview
This program extracts the merchandise hierarchy from company to transaction level item to planning and forecasting on a weekly basis. Additional key attributes about the items are also included, such as the primary supplier, brand, and any differentiators (for example, colors, sizes, and so on) that exist for the item.
Key assumptions for this integration:
-
The full merchandise hierarchy and all items are sent each time this process is run.
-
Only approved, inventoried and sellable transaction-level items will be included in the integration. Pack items are not included.
-
All descriptions are sent in the primary language as defined in Merchandising.
-
For transaction items that do not have a parent item, then the transaction item is also displayed as the parent item, as well as the parent/diff level.
-
For a parent item that is not marked as an aggregate item or does not have any of its diffs flagged as aggregates, the parent item is sent as the parent/diff level for all of its transaction items.
-
A single unit of measure is assumed for all items and therefore the standard units of measure for the items are not sent.
-
The intended targets for this integration are
-
Oracle Retail Merchandise Financial Planning Cloud Service (MFPCS)
-
Oracle Retail Demand Forecasting Cloud Service (RDFCS)
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This program utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement to the target applications. The batch job BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts Merch Hierarchy information and writes it out to a flat file for processing by both MFP and RDF."/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RPAS_MerchHier_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (ItemHdrAndMerchHier_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to the target applications:
-
Extractor jobs (MerchHier_Fnd_Extractor, ItemHdr_Fnd_Extractor) call respective BDI_MERCH_SQL and BDI_ITEM_SQL functions to extract data from Merchandising tables to BDI outbound staging tables MERCH_HIER_OUT and ITEM_HDR_OUT.
-
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_merchhier_extract.ksh to write merchandise hierarchy and item information from the MERCH_HIER_OUT and ITEM_HDR_OUT tables into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. Separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated locations as configured via BDI system options:
-
MFP_outboundLocation
-
RDF_outboundLocation
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
COMPHEAD |
Yes |
No |
No |
No |
DIVISION |
Yes |
No |
No |
No |
GROUPS |
Yes |
No |
No |
No |
DEPS |
Yes |
No |
No |
No |
CLASS |
Yes |
No |
No |
No |
SUBCLASS |
Yes |
No |
No |
No |
ITEM_MASTER |
Yes |
No |
No |
No |
DIFF_GROUP_HEAD |
Yes |
No |
No |
No |
DIFF_IDS |
Yes |
No |
No |
No |
SYSTEM_OPTIONS |
Yes |
No |
No |
No |
MERCH_HIER_OUT |
Yes |
Yes |
No |
Yes |
ITEM_HDR_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
ITEM_SUPPLIER_OUT |
Yes |
Yes |
No |
Yes |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
ITEM |
Char(25) |
Yes |
The transaction level item ID. |
ITEM_DESC |
Char(250) |
Yes |
The transaction level item description. |
ITEM_PARENT_DIFF |
Char(30) |
Yes |
Concatenated value consisting of item parent ID with the composite diff aggregate. If there is no item parent, this will contain the transaction level item. |
ITEM_PARENT_DIFF_DESC |
Char(250) |
Yes |
Description of the item parent diff. Concatenated value consisting of the item parent description and the diff IDs for all diffs associated to the parent marked as aggregates. If there is no item parent, it will contain the transaction level item description. |
ITEM_PARENT |
Char(25) |
Yes |
If there is no item parent, it will contain the transaction level item. |
ITEM_PARENT_DESC |
Char(250) |
Yes |
If there is no item parent, it will contain the transaction level item description. |
SUBCLASS_ID |
Number(10) |
Yes |
Unique subclass ID |
SUBCLASS_NAME |
Char(120) |
Yes |
Concatenated value consisting of the subclass number with name. |
CLASS_ID |
Number(10) |
Yes |
Unique class ID |
CLASS_NAME |
Char(120) |
Yes |
Concatenated value consisting of the class number with name. |
DEPT |
Number(4) |
Yes |
Department ID |
DEPT_NAME |
Char(120) |
Yes |
Concatenated value consisting of the department ID and name. |
GROUP_NO |
Number(4) |
Yes |
Group ID |
GROUP_NAME |
Char(120) |
Yes |
Group name |
DIVISION |
Number(4) |
Yes |
Division ID |
DIV_NAME |
Char(120) |
Yes |
Division name |
COMPANY |
Number(4) |
Yes |
Company ID |
COMPANY_NAME |
Char(120) |
Yes |
Company name |
FORECAST_IND |
Char(1) |
Yes |
Indicates whether or not the item should be forecasted. Valid values are Y or N. |
CLASS |
Number(10) |
Yes |
The class ID that is displayed in the Merchandising screens. |
SUBCLASS |
Number(10) |
Yes |
The subclass ID that is displayed in the Merchandising screens. |
BRAND_NAME |
Char(30) |
Yes |
If a brand is not assigned, this is defaulted to 'NA'. |
BRAND_DESCRIPTION |
Char(120) |
Yes |
The brand description for the transaction item. If a brand is not assigned, this is defaulted to 'Not Assigned'. |
SUPPLIER |
Number(10) |
Yes |
The ID of the primary supplier for the transaction item. |
SUPPLIER_NAME |
Char(240) |
Yes |
The name of the primary supplier for the transaction item. |
DIFF_1 |
Char(10) |
No |
The ID of the first diff for the transaction level item. If a diff is not assigned, this is defaulted to 'NA'. |
DIFF_1_DESC |
Char(120) |
No |
The name of the first diff for the transaction item. If a diff is not assigned, this is defaulted to 'unassigned'. |
DIFF_2 |
Char(10) |
No |
The ID of the second diff for the transaction item. If a diff is not assigned, this is defaulted to 'NA'. |
DIFF_2_DESC |
Char(120) |
No |
The name of the second diff for the transaction item. If a diff is not assigned, this is defaulted to 'unassigned'. |
DIFF_3 |
Char(10) |
No |
The ID of the third diff for the transaction item. If a diff is not assigned, this is defaulted to 'NA'. |
DIFF_3_DESC |
Char(120) |
No |
The name of the third diff for the transaction item. If a diff is not assigned, this is defaulted to 'unassigned'. |
DIFF_4 |
Char(10) |
No |
The ID of the fourth diff for the transaction item. If a diff is not assigned, this is defaulted to 'NA'. |
DIFF_4_DESC |
Char(120) |
No |
The name of the fourth diff for the transaction item. If a diff is not assigned, this is defaulted to 'unassigned'. |
On Order Extract to Planning (BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB)
Note:
This module replaces the onordext.pc and onorddnld.pc modules from previous releases.
Module Name |
BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB |
Description |
Extracts inventory information to Planning |
Functional Area |
Inventory Tracking |
Module Type |
Integration |
Module Technology |
BDI job |
Catalog ID |
N/A |
Runtime Parameters |
OnOrder_Tx_ProcessFlow_From_RMS OnOrder_Tx_Extractor |
Design Overview
This process extracts its quantities on order to planning and forecasting on a weekly basis, at the end of the week. The integration sends any open on order quantities aggregated by week, grouped by the open to buy end of week date. Any on order quantity that is still open and has an OTB EOW date in the past will be combined with the current week's on order.
Key assumptions for this integration:
-
Only orderable, inventoried, approved transaction items are included in the integration.
-
Any on order for pack items is sent based on the component items.
-
Purchase orders flagged to not be included in "on order" are not included in the integration.
-
Cost and retail values sent are based on the purchase order's cost and retail value, converted to primary currency.
-
Retail values will include VAT if the system option to include VAT in the stock ledger is set to include VAT so that the retail values in this integration are consistent with other data sent to planning.
-
All unit values are sent in terms of the standard unit of measure for the item.
-
Planning will interpret the on order as being clearance if the clearance flag sent in this integration shows the item/location to be on clearance at the end of the week.
-
The intended targets for this integration are
-
Oracle Retail Merchandise Financial Planning Cloud Service (MFPCS)
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This process utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement to the target applications.
The batch job BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts information regarding quantities on order for use by the MFP application"/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_MFP_OnOrder_Tx_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end of week date. If the vdate is an end of week date, it invokes a BDI process flow (OnOrder_Tx_ProcessFlow_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor job (OnOrder_Tx_Extractor) calls BDI_MFP_SQL. ON_ORDER_UP function to extract data from Merchandising view V_BDI_MFP_ON_ORDER to BDI outbound staging table ON_ORDER_OUT.
-
A generic BDI Downloader file creator job writes quantities on order information from the ON_ORDER_OUT table into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. Separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated locations as configured via BDI system options:
-
MFP_outboundLocation
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
V_BDI_MFP_ON_ORDER |
Yes |
No |
No |
No |
ON_ORDER_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
EOW |
Date |
Yes |
Indicates the end of week date that the on order information pertains to. |
ITEM |
Varchar2(25) |
Yes |
Transaction level item only. |
LOCATION |
Number(10) |
Yes |
Could be a store or virtual warehouse. |
LOC_TYPE |
Varchar2(1) |
Yes |
Indicates if the location is a store or warehouse - S = Store; W = Warehouse. |
CLEAR_IND |
Number(1) |
Yes |
Indicates if the item/location is currently on clearance. |
ON_ORDER_UNITS |
Number(12) |
Yes |
Indicates the total quantity of the item in the order in standard unit of measure. |
ON_ORDER_COST |
Number(20,4) |
Yes |
on order * PO cost in primary currency |
ON_ORDER_RETAIL |
Number(20,4) |
Yes |
on order * PO retail in primary currency |
Organization Hierarchy Extract to Planning and Forecasting (BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB)
Module Name |
BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB bdi_merch_extract_to_file_wrapper.sh bdi_rpas_orghier_extract.ksh |
Description |
Extracts organizational hierarchy information to RPAS |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI job, shell scripts |
Catalog ID |
N/A |
Runtime Parameters |
StoreAndWhAndOrgHier_Fnd_ProcessFlow_From_RMS Store_Fnd_Extractor Wh_Fnd_Extractor OrgHier_Fnd_Extractor Database connection, download file location, filename, trigger filename |
Design Overview
This program extracts the organization hierarchy data from company to location, which can be stores or warehouses to planning and forecasting on a weekly basis. Additional key attributes about the organizational hierarchy will also be sent to assist in building alternate hierarchies for planning, such as channel.
Key assumptions for this integration:
-
MFPCS will use the third level of the Merchandising hierarchy (area) to represent channel.
-
The full organizational hierarchy is sent each time this process is run.
-
All names and descriptions are sent in the primary language only.
-
The location in the file can represent either a store or a virtual warehouse location.
-
Because warehouses live outside the organization hierarchy, for the levels of the organizational hierarchy above location (chain through district) when the location is a warehouse, the warehouse ID and description will be repeated.
-
The intended targets for this integration are
-
Oracle Retail Merchandise Financial Planning Cloud Service (MFPCS)
-
Oracle Retail Demand Forecasting Cloud Service (RDFCS)
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This program utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement to the target applications. The batch job BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts Org Hierarchy information and writes it out to a flat file for processing by both MFP and RDF."/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RPAS_OrgHier_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (StoreAndWhAndOrgHier_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor jobs (Store_Fnd_Extractor, Wh_Fnd_Extractor, OrgHier_Fnd_Extractor) call respective BDI_ORG_SQL functions to extract data from Merchandising tables to BDI outbound staging tables ORG_HIER_OUT, STORE_OUT, and WH_OUT.
-
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_orghier_extract.ksh to write organization hierarchy information from the ORG_HIER_OUT, STORE_OUT, and WH_OUT tables into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. Separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated locations as configured via BDI system options:
-
MFP_outboundLocation
-
RDF_outboundLocation
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
STORE |
Yes |
No |
No |
No |
WH |
Yes |
No |
No |
No |
AREA |
Yes |
No |
No |
No |
CHAIN |
Yes |
No |
No |
No |
DISTRICT |
Yes |
No |
No |
No |
REGION |
Yes |
No |
No |
No |
COMPHEAD |
Yes |
No |
No |
No |
CHANNELS |
Yes |
No |
No |
No |
CODE_DETAIL |
Yes |
No |
No |
No |
STORE_FORMAT |
Yes |
No |
No |
No |
LANG |
Yes |
No |
No |
No |
VAT_REGION |
Yes |
No |
No |
No |
TSFZONE |
Yes |
No |
No |
No |
ORG_HIER_OUT |
Yes |
Yes |
No |
Yes |
STORE_OUT |
Yes |
Yes |
No |
Yes |
WH_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
LOCATION |
Number(10) |
Yes |
Store or virtual warehouse ID |
LOC_NAME |
Char(150) |
Yes |
Store or warehouse name |
DISTRICT |
Number(10) |
Yes |
District ID; for warehouses, repeat the warehouse ID with the prefix "WH" |
DISTRICT_NAME |
Char(120) |
Yes |
District name; for warehouses, repeat the warehouse name |
REGION |
Number(10) |
Yes |
Region ID; for warehouses, repeat the warehouse ID with the prefix "WH" |
REGION_NAME |
Char(120) |
Yes |
Region name; for warehouses, repeat the warehouse name |
AREA |
Number(10) |
Yes |
Area ID; for warehouses, repeat the warehouse ID with the prefix "WH" |
AREA_NAME |
Char(120) |
Yes |
Area name; for warehouses, repeat the warehouse name |
CHAIN |
Number(10) |
Yes |
Chain ID; for warehouses, repeat the warehouse ID with the prefix "WH" |
CHAIN_NAME |
Char(120) |
Yes |
Chain name; for warehouses, repeat the warehouse name |
COMPANY |
Number(4) |
Yes |
Company ID |
COMPANY_NAME |
Char(120) |
Yes |
Company name |
COMPANY_CURRENCY |
Char(3) |
Yes |
The currency code for the base currency defined in system options |
LOC_TYPE |
Char(1) |
Yes |
'S' for store, 'W' for warehouse |
LOC_TYPE_NAME |
Char(120) |
Yes |
Store or Warehouse depending on location type |
PHYSICAL_WH |
Number(10) |
Yes |
Physical warehouse ID for warehouses, repeat store ID for store |
PHYSICAL_WH_NAME |
Char(120) |
Yes |
Physical warehouse name for warehouse, repeat store name for stores |
CHANNEL_ID |
Number(4) |
Yes |
Channel ID for the store or virtual warehouse; if no channel is defined, then NA |
CHANNEL_NAME |
Char(120) |
Yes |
Channel name; if no channel is defined, then 'unassigned' |
STORE_CLASS |
Char(1) |
Yes |
For stores, the store class ID; for warehouses or if no store class is defined; then NA. |
STORE_CLASS_DESCRIPTION |
Char(250) |
Yes |
For stores, the description of the store class, if defined; for warehouses or if not defined for a store, then 'unassigned'. |
STORE_FORMAT |
Number(4) |
Yes |
For stores, the store format ID; for warehouses or if no store class is defined; then NA. |
STORE_FORMAT_NAME |
Char(60) |
Yes |
For stores, the description of the store format, if defined; for warehouses or if not defined for a store, then 'unassigned'. |
Out of Stock Extract to Forecasting (BDI_RDF_StockOut_Tx_PF_From_RMS_JOB)
Note:
This module replaces the soutdnld.pc module from previous releases.
Module Name |
BDI_RDF_StockOut_Tx_PF_From_RMS_JOB |
Description |
Extracts out of stock item location information to Forecasting |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI job |
Catalog ID |
N/A |
Runtime Parameters |
StockOut_Tx_ProcessFlow_From_RMS StockOut_Tx_Extractor |
Design Overview
This process extracts items which are out of stock for use by Forecasting on a weekly basis. This integration sends all item/store combinations that meet the criteria for review and have a stock-on-hand position of less than or equal to zero at the end of the week.
Key assumptions for this integration:
-
Only stockholding stores are included in this integration.
-
Only forecasted items are included in this integration.
-
Only item/store combinations that have a status of Active and a ranged flag of Yes are reviewed for stock out conditions.
-
Only item/store combinations that have a last sold date that is between the end of week date and x number of days back are reviewed for stock out conditions, where x is the value reports system option value Days Since Last Transaction.
-
The intended targets for this integration are
-
Oracle Retail Demand Forecasting Cloud Service (RDFCS)
-
This process utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement to the target applications. The batch job BDI_RDF_StockOut_Tx_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RDF_StockOut_Tx_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts information for items which are out of stock for use by the RDF application"/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RDF_StockOut_Tx_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (StockOut_Tx_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor job (StockOut_Tx_ExtractorJob) calls BDI_RDF_SQL. STOCKOUT_UP function to extract data from the Merchandising view V_BDI_RDF_STOCKOUT to outbound staging table STOCKOUT_OUT.
-
A generic BDI Downloader file creator job writes out of stock item information from the STOCKOUT_OUT table into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful.
-
The downloaded data files and trigger files are written to designated location as configured through BDI system options:
-
RDF_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
V_BDI_RDF_STOCKOUT |
Yes |
No |
No |
No |
STOCKOUT_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
ITEM |
Varchar2(25) |
Yes |
Item that is out of stock at the store. |
STORE |
Number(10) |
Yes |
Store that is out of stock for the item. |
EOW_DATE |
Date |
Yes |
Indicates the end of week date for which the data applies. |
OUT_OF_STOCK |
Number(1) |
Yes |
Flag to indicate if the item/store is out of stock at end of week. This will always be 1, as only out-of-stock items are sent. |
Store Extract to Planning and Forecasting (BDI_RPAS_Store_Fnd_PF_From_RMS_JOB)
Module Name |
BDI_RPAS_Store_Fnd_PF_From_RMS_JOB bdi_merch_extract_to_file_wrapper.sh bdi_rpas_store_extract.ksh |
Description |
Extracts store information to RPAS |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI, shell scripts |
Catalog ID |
N/A |
Runtime Parameters |
Store_Fnd_ProcessFlow_From_RMS Store_Fnd_Extractor Database connection, download file location, filename, trigger filename |
Design Overview
This program extracts store data to planning and forecasting on a weekly basis. This data supplements the store information included in the organizational hierarchy feed.
Key assumptions for this integration:
-
Both stockholding and non-stockholding stores are included.
-
Both company and franchise types of stores are included.
-
All stores are sent each time this process is run.
-
Planning will derive the status of the store (e.g. open or closed) based on the dates sent in this integration. For example, if the open date is in the past and there is no close date defined or it is a future date, then the store is considered open.
-
All descriptions are sent in the primary language as defined in Merchandising.
-
The intended targets for this integration are
-
Oracle Retail Merchandise Financial Planning Cloud Service (MFPCS)
-
Oracle Retail Demand Forecasting Cloud Service (RDFCS)
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This program utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from Merchandising to the target applications.
The batch job BDI_RPAS_Store_Fnd_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RPAS_Store_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts store information and writes it out to a flat file for processing by both MFP and RDF."/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RPAS_Store_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (Store_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor job (Store_Fnd_Extractor) calls BDI_ORG_SQL.STORE_UP function to extract data from Merchandising tables to BDI outbound staging table STORE_OUT.
-
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_store_extract.ksh to write store information from the STORE_OUT table into a comma-delimited flat file, which will be consumed by the target application. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to the target application.
-
The downloaded data files and trigger files are written to designated locations as configured via BDI system options:
-
MFP_outboundLocation
-
RDF_outboundLocation
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
STORE |
Yes |
No |
No |
No |
CHANNELS |
Yes |
No |
No |
No |
CODE_DETAIL |
Yes |
No |
No |
No |
STORE_FORMAT |
Yes |
No |
No |
No |
LANG |
Yes |
No |
No |
No |
VAT_REGION |
Yes |
No |
No |
No |
TSFZONE |
Yes |
No |
No |
No |
STORE_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
STORE |
Number(10) |
Yes |
Store ID |
STORE_NAME |
Char(150) |
Yes |
Store name |
DISTRICT |
Number(10) |
Yes |
District in which the store is a member. |
STORE_CLOSE_DATE |
DATE |
Yes |
Date on which the store closed. If NULL, set to NA. |
STORE_OPEN_DATE |
DATE |
Yes |
Date on which the store opened |
REMODEL_DATE |
DATE |
Yes |
Date on which the store was last remodeled. If NULL, set to NA. |
STORE_CLASS |
Char(1) |
Yes |
ID for the store class of which the store is a member. |
STORE_CLASS_DESCRIPTION |
Char(250) |
Yes |
Store class description |
STORE_FORMAT |
Number(4) |
Yes |
Store format. If NULL, set to NA. |
STORE_FORMAT_NAME |
Char(60) |
Yes |
Store format name. If NULL, set to 'unassigned'. |
CURRENCY |
Char(3) |
Yes |
Currency under which the store operates. |
STORE_TYPE |
Char(6) |
Yes |
Indicates whether the store is a franchise (F) or company store (C). |
STOCKHOLDING_IND |
Char(1) |
Yes |
Indicates whether the store can hold stock. Valid values are Y or N. |
Supplier Extract to Planning (BDI_RPAS_Supplier_Fnd_PF_From_RMS_JOB)
Module Name |
BDI_RPAS_Supplier_Fnd_PF_From_RMS_JOB bdi_merch_extract_to_file_wrapper.sh bdi_rpas_supplier_extract.ksh |
Description |
Extracts Supplier information to Planning |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI job, shell scripts |
Catalog ID |
N/A |
Runtime Parameters |
Supplier_Fnd_ProcessFlow_From_RMS Supplier_Fnd_Extractor Database connection, download file location, filename, trigger filename |
Design Overview
This process extracts supplier data to Planning on a weekly basis.
Key assumptions for this integration:
-
All active, orderable supplier sites will be included in this integration each time it runs.
-
Retailers will not create a Diff with an ID of 'SUP'.
-
In order to meet the format required by Planning, the UDA description in this extract is hard coded to "Supplier" and does not take into account the primary language configuration in Merchandising.
-
The intended targets for this integration are
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This process utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement to Planning.
The batch job BDI_RPAS_Supplier_Fnd_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RPAS_Supplier_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts Supplier information and writes it out to a flat file for processing by AP and IP."/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RPAS_Supplier_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (Supplier_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor job (Supplier_Fnd_Extractor) calls BDI_FOUNDATION_SQL.SUPS_UP function to extract data from the Merchandising table SUPS to BDI outbound staging table SUPS_OUT. Only supplier sites will be extracted.
-
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_supplier_extract.ksh to write supplier information from the SUPS_OUT table into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. Two separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated locations as configured via BDI system options:
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
SUPS |
Yes |
No |
No |
No |
SUPS_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
UDA_ID |
Char(6) |
Yes |
Hardcoded 'SUP' |
UDA_DESC |
Char(120) |
Yes |
Hardcoded 'Supplier' |
SUPPLIER |
Char(30) |
Yes |
The supplier site ID. |
SUP_NAME |
Char(120) |
Yes |
The supplier site name in the primary language. |
Transaction Data Extract to Planning (BDI_MFP_TranData_Tx_PF_From_RMS_JOB)
Module Name |
BDI_MFP_TranData_Tx_PF_From_RMS_JOB |
Description |
Extracts Transaction data to Planning from RMS |
Functional Area |
Transactional Data |
Module Type |
Integration |
Module Technology |
BDI job |
Catalog ID |
N/A |
Runtime Parameters |
TranData_Tx_ProcessFlow_From_RMS TranData_Tx_Extractor |
Design Overview
This process extracts transactional data to planning on a weekly basis, aggregating all transactions that posted in the last week, which could include transactions for previous weeks that posted late.
Key assumptions in this integration:
-
Only orderable, inventoried, approved transaction items are included in the integration.
-
Pack items are not included in this integration; any transactions involving pack items will be sent in terms of the pack's component items.
-
Cost and retail values sent in primary currency.
-
Sales sent will always be net sales. If gross sales are needed in Planning, then net sales can be combined with returns.
-
Retail values will include VAT if the system option to include VAT in the stock ledger is set to include VAT so that the retail values in this integration are consistent with other data sent to planning.
-
All unit values are sent in terms of the standard unit of measure for the item.
-
Late posted transactions included in this integration may be for any week in the open stock ledger month, as well as any week in the previous month that posted during the week but before the previous month closed, if the month close ran during the current week.
-
The intended targets for this integration are
-
Oracle Retail Merchandise Financial Planning Cloud Service (MFPCS)
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This process utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement to the target applications. The batch job BDI_MFP_TranData_Tx_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_MFP_TranData_Tx_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts information regarding transaction data for use by the MFP application"/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_MFP_TranData_Tx_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (Trandata_Tx_ProcessFLow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor job (TranData_Tx_Extractor) calls BDI_MFP_SQL. TRAN_DATA_UP function to extract data from the Merchandising view V_BDI_MFP_TRAN_DATA to BDI outbound staging table TRAN_DATA_OUT.
-
A generic BDI Downloader file creator job writes transactional information from the TRAN_DATA_OUT table into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. Separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated MFP location as configured via BDI system options:
-
MFP_outboundLocation
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
V_BDI_MFP_TRAN_DATA |
Yes |
No |
No |
No |
TRAN_DATA_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
EOW |
Date |
Yes |
Indicates the end of week date that the information pertains to. |
ITEM |
Varchar2(25) |
Yes |
Transaction level item only. |
LOCATION |
Number(10) |
Yes |
Could be a store or virtual warehouse. |
LOC_TYPE |
Varchar2(1) |
Yes |
Indicates if the location is a store or warehouse - S = Store; W = Warehouse. |
CLEAR_IND |
Number(1) |
Yes |
If Y, item/location is currently on clearance. |
NET_SALES_REG_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 1 and sales type = R |
NET_SALES_REG_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 1 and sales type = R |
NET_SALES_REG_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 1 and sales type = R |
NET_SALES_PROMO_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 1 and sales type = P |
NET_SALES_PROMO_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 1 and sales type = P |
NET_SALES_PROMO_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 1 and sales type = P |
NET_SALES_CLEAR_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 1 and sales type = C |
NET_SALES_CLEAR_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 1 and sales type = C |
NET_SALES_CLEAR_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 1 and sales type = C |
NET_SALES_REG_RETAIL_VAT_EXCL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 2 and sales type = R |
NET_SALES_PROMO_RTL_VAT_EXCL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 2 and sales type = P |
NET_SALES_CLR_RETAIL_VAT_EXCL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 2 and sales type = C |
RETURNS_REG_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 4 and sales type = R |
RETURNS_REG_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 4 and sales type = R |
RETURNS_REG_RETAIL |
Number(20,4 |
No |
tran_data_history.total_retail: tran_code = 4 and sales type = R |
RETURNS_PROMO_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 4 and sales type = P |
RETURNS_PROMO_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 4 and sales type = P |
RETURNS_PROMO_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 4 and sales type = P |
RETURNS_CLEAR_UNITS |
Number(20,4) |
No |
tran_data_history.units: tran_code = 4 and sales type = C |
RETURNS_CLEAR_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 4 and sales type = C |
RETURNS_CLEAR_RETAIL |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 4 and sales type = C |
REG_MARKDOWN_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code 13 - tran_code 14 (Markdown Cancel) - tran_code 11 (Markup) |
PROMO_MARKDOWN_RETAIL_REG |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 15 - if the item is not on clearance EOW |
PROMO_MARKDOWN_RETAIL_CLEAR |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 15 - if the item is on clearance EOW |
CLEAR_MARKDOWN_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 16 |
WF_MARKDOWN_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 85 |
WF_MARKUP_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 84 |
SHRINK_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code 22 |
SHRINK_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code 22 |
SHRINK_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code 22 |
DEAL_INCOME_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code 6 & 7 |
RECEIPT_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 20 + 44 |
RECEIPT_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 20 + 44 |
RECEIPT_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 20 + 44 |
NON_SHRINK_ADJ_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 23 |
NON_SHRINK_ADJ_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 23 |
NON_SHRINK_ADJ_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 23 |
DEAL_INCOME_PURCHASES |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code 7 |
MARKUP |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code 11 |
MARKDOWN_CANCEL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code 14 |
INTERCOMPANY_MARKUP |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code 17 |
INTERCOMPANY_MARKDOWN |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code 18 |
RTV_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 24 |
RTV_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 24 |
RTV_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 24 |
TSF_IN_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 30 |
TSF_IN_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 30 |
TSF_IN_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 30 |
TSF_IN_UNITS_BOOK |
Number(12,4) |
No |
tran_data_history.units: tran_code = 31 |
TSF_IN_COST_BOOK |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 31 |
TSF_IN_RETAIL_BOOK |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 31 |
TSF_OUT_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 32 |
TSF_OUT_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 32 |
TSF_OUT_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 32 |
TSF_OUT_UNITS_BOOK |
Number(12,4) |
No |
tran_data_history.units: tran_code = 33 |
TSF_OUT_COST_BOOK |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 33 |
TSF_OUT_RETAIL_BOOK |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 33 |
RECLASS_IN_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 34 |
RECLASS_IN_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 34 |
RECLASS_IN_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 34 |
RECLASS_OUT_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 36 |
RECLASS_OUT_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 36 |
RECLASS_OUT_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 36 |
TSF_IN_UNITS_ICT |
Number(12,4) |
No |
tran_data_history.units: tran_code = 37 |
TSF_IN_COST_ICT |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 37 |
TSF_IN_RETAIL_ICT |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 37 |
TSF_OUT_UNITS_ICT |
Number(12,4) |
No |
tran_data_history.units: tran_code = 38 |
TSF_OUT_COST_ICT |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 38 |
TSF_OUT_RETAIL_ICT |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 38 |
INTERCOMPANY_MARGIN |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 39 |
TSF_RECEIPT_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 44 |
TSF_RECEIPT_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 44 |
TSF_RECEIPT_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 44 |
RTV_RESTOCK_FEE |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 65 |
FRANCHISE_SALES_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 82 |
FRANCHISE_SALES_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 82 |
FRANCHISE_SALES_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 82 |
FRANCHISE_RETURNS_UNITS |
Number(12,4) |
No |
tran_data_history.units: tran_code = 83 |
FRANCHISE_RETURNS_COST |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 83 |
FRANCHISE_RETURNS_RETAIL |
Number(20,4) |
No |
tran_data_history.total_retail: tran_code = 83 |
FRANCHISE_RESTOCK_FEE |
Number(20,4) |
No |
tran_data_history.total_cost: tran_code = 86 |
UDA Extract to Planning (BDI_RPAS_UdaAndUdaValues_Fnd_PF_From_RMS_JOB)
Module Name |
BDI_RPAS_UdaAndUdaValues_Fnd_PF_From_RMS_JOB bdi_merch_extract_to_file_wrapper.sh bdi_rpas_uda_extract.ksh |
Description |
Extracts LOV Type UDA information to Planning |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI job, shell scripts |
Catalog ID |
N/A |
Runtime Parameters |
UdaAndUdaValues_Fnd_ProcessFlow_From_RMS Uda_Fnd_Extractor UdaValues_Fnd_Extractor Database connection, download file location, filename, trigger filename |
Design Overview
This process extracts its UDA data to Planning on a weekly basis.
Key assumptions for this integration:
-
The full set of user defined attributes (UDAs) is included in this integration each time it runs.
-
Only list of value type UDAs will be included in the integration.
-
The intended targets for this integration are
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This process utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement to Planning. The batch job BDI_RPAS_UdaAndUdaValues_Fnd_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RPAS_UdaAndUdaValues_Fnd_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts LOV Type UDA information and writes it out to a flat file for processing by AP and IP."/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RPAS_UdaAndUdaValues_Fnd_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an and-of-week date, it invokes a BDI process flow (UdaAndUdaValues_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor jobs (Uda_Fnd_Extractor, UdaValues_Fnd_Extractor) call respective BDI_FOUNDATION_SQL functions to extract data from Merchandising tables UDA and UDA_VALUES to BDI outbound staging tables UDA_OUT and UDA_VALUES_OUT.
-
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rpas_uda_extract.ksh to write UDA information from the UDA_OUT and UDA_VALUES_OUT tables into a comma-delimited flat file, which will be consumed by the target applications. Only LOV type UDAs will be extracted. A zero-byte trigger file is also generated to signal that the extract process was successful. Separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated locations as configured via BDI system options:
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
UDA |
Yes |
No |
No |
No |
UDA_VALUES |
Yes |
No |
No |
No |
UDA_OUT |
Yes |
Yes |
No |
Yes |
UDA_VALUES_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
UDA_ID |
Number(5) |
Yes |
The ID of the UDA assigned to the item. |
UDA_DESC |
Char(120) |
Yes |
The description of the UDA (for example, Fabric Content). |
UDA_VALUE |
Number(5) |
Yes |
The ID of the UDA value for the UDA assigned to the item. |
UDA_VALUE_DESC |
Char(250) |
Yes |
The description of the UDA value (for example, Cotton). |
UDA Item Extract to Planning and Forecasting (BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB)
Module Name |
BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB bdi_merch_extract_to_file_wrapper.sh bdi_rdf_itemuda_extract.ksh |
Description |
Extracts information for LOV type of UDAs to Planning and Forecasting |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI job, shell scripts |
Catalog ID |
N/A |
Runtime Parameters |
ItemHdrAndUdaItemLov_Fnd_ProcessFlow_From_RMS ItemHdr_Fnd_Extractor UdaItemLov_Fnd_Extractor Database connection, download file location, filename, trigger filename |
Design Overview
This process extracts user-defined attributes (UDAs) assigned to item to Planning and Forecasting on a weekly basis.
Key assumptions for this integration:
-
Only list of value (LOV) type UDAs will be included.
-
Both forecasted and non-forecasted items are included in this extract, with the forecast flag included.
-
Planning and Forecasting can only support a specific UDA being associated with an item once. Merchandising has a configuration that allows the same UDA to be associated with an item more than one time. However, when implementing with Planning or Forecasting, this should be avoided for LOV-type UDAs to prevent issues with interpreting the data. If more than one is associated with the item, then only the last UDA with a particular ID will be visible in Planning and Forecasting.
-
The intended targets for this integration are
-
Oracle Retail Demand Forecasting Cloud Service (RDFCS)
-
Assortment & Item Planning for Fashion/Softlines Cloud Service and Assortment & Item Planning Enterprise Edition Cloud Service (referred to jointly as APCS)
-
This process utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement from Merchandising to the target applications. The batch job BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts UDA item LOV information and writes it out to a flat file for processing by RDF."/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RDF_UdaItemLov_Fnd_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (ItemHdrAndUdaItemLov_Fnd_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to the target applications:
-
Extractor jobs (ItemHdr_Fnd_Extractor, UdaItemLov_Fnd_Extractor) call respective BDI_ITEM_SQL functions to extract data from Merchandising tables to BDI outbound staging tables ITEM_HDR_OUT and UDA_ITEM_LOV_OUT.
-
Downloader file creator job calls the wrapper script, bdi_merch_extract_to_file_wrapper.sh, to set the runtime parameters on environment variables. This script will then call bdi_rdf_itemuda_extract.ksh to write LOV type of UDA information from the ITEM_HDR_OUT and UDA_ITEM_LOV_OUT tables into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. The data file and the trigger file are then sent to the target applications.
-
The downloaded data file and trigger file are written to designated locations as configured through BDI system options:
-
RDF_outboundLocation
-
AP_outboundLocation
-
IP_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
ITEM_MASTER |
Yes |
No |
No |
No |
CLASS |
Yes |
No |
No |
No |
SUBCLASS |
Yes |
No |
No |
No |
DIFF_GROUP_HEAD |
Yes |
No |
No |
No |
DIFF_IDS |
Yes |
No |
No |
No |
SYSTEM_OPTION |
Yes |
No |
No |
No |
UDA_ITEM_LOV |
Yes |
No |
No |
No |
UDA |
Yes |
No |
No |
No |
UDA_VALUES |
Yes |
No |
No |
No |
UDA_ITEM_LOV_OUT |
Yes |
Yes |
No |
Yes |
ITEM_HDR_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
ITEM |
Char(25) |
Yes |
The ID of the item. |
UDA_ID |
Number(5) |
Yes |
The ID of the UDA assigned to the item. |
UDA_DESC |
Char(120) |
Yes |
The description of the UDA (for example, Fabric Content) |
UDA_VALUE |
Number(5) |
Yes |
The ID of the UDA value for the UDA assigned to the item. |
UDA_VALUE_DESC |
Char(250) |
Yes |
The description of the UDA value (for example, Cotton). |
FORECAST_IND |
Char(1) |
Yes |
Indicates whether or not the item is to be forecasted. Valid values are Y or N. |
Weekly Sales Extract to Forecasting (BDI_RDF_WeeklySales_Tx_PF_From_RMS_JOB)
Module Name |
BDI_RDF_WeeklySales_Tx_PF_From_RMS_JOB |
Description |
Extracts weekly sales information to Forecasting |
Functional Area |
Foundation |
Module Type |
Integration |
Module Technology |
BDI job |
Catalog ID |
N/A |
Runtime Parameters |
WeeklySales_Tx_ProcessFlow_From_RMS WeeklySales_Tx_Extractor |
Design Overview
This process extracts weekly sales for use by Forecasting on a weekly basis. It sends only the sales from the last week.
Key assumptions for this integration:
-
This integration sends gross sales. Returns are not netted out of the sales values.
-
Warehouse issues are not included in this integration. Only sales for stores.
-
Only forecasted items are included in this integration.
-
The intended targets for this integration are
-
Oracle Retail Demand Forecasting Cloud Service (RDFCS)
-
This process utilizes BDI (Bulk Data Integration) to facilitate the bulk data movement to the target applications.
The batch job BDI_RDF_WeeklySales_Tx_PF_From_RMS_JOB is defined in the Merchandising JOS batch job admin as follows:
<job id="BDI_RDF_WeeklySales_Tx_PF_From_RMS_JOB" version="1.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"> <properties> <property name="description" value="Extracts weekly sales information for use by the RDF application"/> </properties> <step id="batchlet-step"> <batchlet ref="BDIInvokerBatchlet"> <properties> <property name="bdiProcessFlowUrl" value="#SysOpt.bdiProcessFlowUrl"/> <property name="bdiProcessFlowCredential" value="#SysOpt.bdiProcessFlowUrlUserAlias"/> <property name="predicateDS" value="RmsDBDS"/> <property name="predicateFunction" value="RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL"/> </properties> </batchlet> <end on="COMPLETED"/> </step> </job>
When the batch job BDI_RDF_WeeklySales_Tx_PF_From_RMS_JOB is executed, a batchlet (BDIInvokerBatchlet) starts the execution flow. It calls a PLSQL function (RMS_BATCH_STATUS_SQL.GET_EOW_RUN_SIGNAL) to ensure the process flow is only executed on an end-of-week date. If the vdate is an end-of-week date, it invokes a BDI process flow (WeeklySales_Tx_ProcessFlow_From_RMS) to perform a series of steps to extract, download, and transport the downloaded files to target applications:
-
Extractor job (WeeklySales_Tx_ExtractorJob) calls BDI_RDF_SQL. WEEKLY_SALES_UP function to extract data from a Merchandising view V_BDI_RDF_WEEKLY_SALES to outbound staging table WEEKLY_SALES_OUT.
-
A generic BDI Downloader file creator job writes weekly sales information from the WEEKLY_SALES_OUT table into a comma-delimited flat file, which will be consumed by the target applications. A zero-byte trigger file is also generated to signal that the extract process was successful. Separate copies of the data file and the trigger file are sent to the target applications.
-
The downloaded data files and trigger files are written to designated location as configured via BDI system options:
-
RDF_outboundLocation
-
Scheduling Constraints
Schedule Information | Description |
---|---|
Processing Cycle |
End of Day |
Frequency |
Scheduled daily but files will only be generated weekly on End of Week date. |
Scheduling Considerations |
N/A |
Pre-Processing |
N/A |
Post-Processing |
N/A |
Threading Scheme |
N/A |
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
V_BDI_RDF_WEEKLY_SALES |
Yes |
No |
No |
No |
WEEKLY_SALES_OUT |
Yes |
Yes |
No |
Yes |
BDI_DWNLDR_IFACE_MOD_DATA_CTL |
Yes |
No |
No |
No |
BDI_DWNLDR_IFACE_DATA_CTL |
Yes |
No |
No |
No |
Integration Contract
The flat file will contain the following information:
Field Name | Field Type | Required | Description |
---|---|---|---|
ITEM |
Varchar2(25) |
Yes |
Indicates the item. |
STORE |
Number(10) |
Yes |
Indicates the store. |
EOW_DATE |
Date |
Yes |
Indicates the end of week date for which the data applies. |
SALES_UNITS |
Number(12,4) |
No |
This value will be the total sales units for the item/location for the week. |
SALES_TYPE |
Varchar2(1) |
Yes |
Indicates the sales type. For example, R (Regular Sales), P (Promotional Sales) or C (Clearance Sales). |
Sales Audit
The purpose of Sales Audit is to accept transaction data from point-of-sale (POS) and order management (OMS) solutions and move the data through a series of processes that culminate in "clean" data. Data that Sales Audit finds to be inaccurate is brought to the attention of the auditors who can use the features in Sales Audit to correct the exceptions.
For more information on Sales Audit processing see Merchandising Operations Guide Volume 1.
This section contains details about the following integration processes used to export data from Sales Audit to other solutions:
-
Download from Sales Audit to Account Clearing House (ACH) System (saexpach)
-
Download of Escheated Vouchers from Sales Audit for Payment (saescheat)
-
Export DSD and Escheatment from Sales Audit to Invoice Matching (saexpim)
-
Export of POS transactions from Sales Audit to Merchandising (saexprms)
-
Export of Revised Sale/Return Transactions from ReSA to SIM/SIOCS (saexpsim)
-
Export to Universal Account Reconciliation System from Sales Audit (saexpuar)
-
Extract of POS Transactions by Store/Date from Sales Audit for Web Search (ang_saplgen)
-
Post User Defined Totals from Sales Audit to General Ledger (saexpgl)
Download from Sales Audit to Account Clearing House (ACH) System (saexpach)
Module Name |
saexpash.pc |
Description |
Download from Sales Audit to Account Clearing House (ACH) System |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RSA03 |
Wrapper Script |
rmswrap_out.ksh |
Design Overview
This module will post store/day deposit totals to the SA_STORE_ACH table and bank deposit totals for a given day in a file formatted for export to an ACH (Account Clearing House). The ACH export deviations from the typical Sales Audit export in that store/days must be exported even though errors may have occurred for a given day or store (depending on the unit of work defined), and also, the store/day does not need to be closed for the export to occur. The nature of the ACH process is such that as much money as possible must be sent as soon as possible to the consolidating bank. Any adjustments to the amount sent can be made using the sabnkach screen in the online system.
Deposits for store/days that have not been Fully (F) loaded will not be transferred to the consolidating bank. After they are fully loaded, their deposits will be picked up by the next run of this program.
Restart/Recovery
This module is in two distinct parts, with two different logical units of work. Thus, restart/recovery has to be implemented so that the first part does not get reprocessed in case the program is being restarted. Details on the implementation follow.
The first driving cursor in this module retrieves a store/day to generate ACH totals. Once the first cursor is complete, the second retrieves bank locations by account numbers.
The first Logical Unit of Work (LUW) is defined as a unique store/day combination. Records will be fetched, using the first driving cursor, in batches of commit_max_ctr, but processed and committed one store/day at a time.
The first driving cursor will fetch all store/days that have been Fully Loaded (F), whose audit status is Audited (A), HQ Errors Pending (H), or Store Errors Pending (S) and that are ready to be exported to ACH. Before processing starts, a write lock is obtained using get_lock (). This driving cursor only fetches store/days with a sa_export_log.status of SAES_R. After a store/day is processed, sa_export_log.status is set to SAES_P so that this store/day will not be selected again if the program is restarted. The commit is performed using retek_force_commit after each store/day has been processed and sa_export_log updated, so as to release the lock.
In case a store/day could not be processed due to locking, the store/day information is placed on a list (called locked store/day list) and the next store/day is processed. This list is kept in memory and is available only during processing. If the store for a store/day obtained from the first driving cursor, is on the locked store/day list, then this store/day cannot be processed. This is the case because there is a data dependency such that data from a particular store/day is dependent on data for the same store but at an earlier date. Thus, if a store/day cannot be processed, then subsequent store/days for the same store cannot be processed either. After the driving cursor returns no more data, the program attempts to process each store/day on the list two more times. If the store/day is still locked, then it is skipped entirely and a message is printed to the error log.
The second LUW is a bank account number. Again, records will be fetched in batches of commit_max_ctr. The second driving cursor cannot retrieve information by the LUW because it is possible for the store's currency to be different from the local bank's currency. In that case, a currency conversion is needed.
For each store/day, the query should retrieve the required ACH transfer. The latter is determined by adding the estimated deposit for the next day, the adjustment to the estimate for the current day, and any manual adjustment to the estimate.
Since a store can be associated with different accounts at different banks, only accounts that are consolidated should be retrieved. Since it is possible for the local bank to be in a different country than the consolidating bank, the currency of the partner should also be fetched.
Since processing is dependent on the type of account at the RDFI, the account type should be fetched by this cursor.
Due to differences in transaction processing in cases when the bank is outside the United States, the partner's country should also be fetched. The results of the query should be sorted by partner country. The results of the query should also be ordered by accounts.
Security Considerations
The fact that this program automates the transfer of funds on behalf of the user makes it a likely target for electronic theft. It must be made clear that the responsibility of electronic protection lies with the users themselves.
Following are some tips and recommendation to users:
-
A specific user should be used to run the program. This user would be the only one (or one of a few) who has access to this program.
-
The umask for this user should be set up so as to prevent other users from reading/writing its files. This would ensure that when the output file is created, it would not be accessible to other users.
-
The appropriate permissions should be set up on the directory, which holds the ACH files. The most restrictive decision would be to not allow any other user to view the contents of the directory.
-
A secure means of communication should be implemented for transferring the file from where it has been created to the ACH network. This may be done through encryption, or by copying the file to a disk and trusting the courier to deliver the files intact.
-
The ACH network needs to be secure.
I/O Specification
Integration Type |
Download from Sales Audit |
File Name |
ACH_ appended with the consolidating routing number, consolidating account number, and current system date. |
Integration Contract |
IntCon000040 |
Output File
Table 6-23 Output File
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
ACH File Header |
Section No. |
Number(3) |
101 |
Constant number. |
Console Route No |
Number(10) |
N/A |
The routing number of the consolidating bank. |
|
Sender ID |
Char(10) |
N/A |
ID used by the Originator to identify itself. |
|
Current Date |
Char(6) |
N/A |
Vdate in YYMMDD format. |
|
Day Time |
Char(4) |
N/A |
Time of file creation in HH24MM format. |
|
File Header No. |
Number(7) |
0094101 |
Constant number. |
|
Console Bank Name |
Char(23) |
N/A |
Name of the Originating Financial Depository Institution. |
|
Company Name |
Char(23) |
N/A |
The name of the company name. |
|
Ref Code |
Char (8) |
N/A |
Reference code. |
|
ACH CCD Batch Header |
Section No. |
Number(4) |
5225 |
Constant number. |
Company Name |
Char(16) |
N/A |
The name of the company. |
|
Comp Disc Data |
Char(20) |
NULL |
Any kind of data specific to the company. |
|
Comp Id |
Char(10) |
N/A |
Alphanumeric code to identify the company. |
|
CCD Header Id |
Char(3) |
CCD |
Constant value. |
|
Comp Entry Desc |
Char(10) |
CONSOL |
A short description from the Originator about the purpose of the entry. |
|
Tomorrow |
Char(6) |
N/A |
Vdate+1 in YYMMDD format. |
|
Tomorrow |
Char(6) |
N/A |
Vdate+1 in YYMMDD format. |
|
Settle Date |
Char(3) |
NULL |
This is inserted by receiving the ACH Operator. |
|
Reserved |
Number(1) |
1 |
Constant number. |
|
Odfi Id |
Number(8) |
8-digit routing number of the ODFI. |
||
Batch No |
Number(7) |
Batch number. |
||
ACH CBR Batch Header |
Section No. |
Number(4) |
5225 |
Constant number. |
Company Name |
Char(16) |
N/A |
The name of the company. |
|
Reserved |
Char(3) |
FV1 |
Constant value. |
|
Exch Rate |
Number(15) |
Exchange rate for the specified currency. |
||
Reserved |
Char(2) |
US |
Constant value. |
|
Comp Id |
Char(10) |
Alphanumeric code to identify the company |
||
CBR Header Id |
Char(3) |
CBR |
Constant value. |
|
Comp Entry Desc |
Char(10) |
"CONSOL " |
A short description from the Originator about the purpose of the entry. |
|
Partner Curr Code |
Char(3) |
N/A |
Code identifying the currency the partner uses for business transactions. |
|
Reserved |
Char(3) |
USD |
Constant value. |
|
Tomorrow |
Char(6) |
N/A |
Vdate+1 in YYMMDD forma. |
|
Settle Date |
Char(3) |
NULL |
This is inserted by the receiving ACH Operator. |
|
Reserved |
Number(1) |
1 |
Constant number. |
|
Odfi Id |
Number(8) |
N/A |
8-digit routing number of the ODFI. |
|
Batch No |
Number(7) |
N/A |
Batch number. |
|
ACH CCD Entry |
Section No. |
Number(1) |
6 |
Constant number. |
Trans Code |
Char(2) |
Code used to identify the type of debit and credit. Value accepted are 27 and 37. |
||
Routing No |
Number(9) |
Routing number for the bank account. |
||
Acct No |
Char(17) |
Account number of the bank. |
||
Deposit |
Number(10) |
The amount involved in the transaction* 10000 (4 implied decimal places). |
||
Id |
Char(15) |
Null |
Identification number. Optional field containing a number used by the Originator to insert its own number for tracing purposes. |
|
Store Name |
Char(22) |
Name of the local store. |
||
Disc Data |
Char(2) |
Null |
Discretionary data. Any kind of data specific to the transaction. |
|
Reserved |
Number(1) |
0 |
Constant number. |
|
Trace No |
Number(15) |
Used to uniquely identify each entry within a batch. The first 8 digits contain the routing number of the ODFI and the other 7 contains a sequence number. |
||
ACH CBR Entry |
Section No. |
Number(1) |
6 |
Constant number. |
Trans Code |
Char(2) |
N/A |
Code used to identify the type of debit and credit. Values accepted are 27 and 37. |
|
Routing No |
Number(9) |
N/A |
Routing number for the bank account. |
|
Acct No |
Char(17) |
N/A |
Account number of the bank |
|
Deposit |
Number(10) |
N/A |
The amount involved in the transaction* 10000 (4 implied decimal places). |
|
Id |
Char(15) |
NULL |
Identification number. Optional field containing a number used by the Originator to insert its own number for tracing purposes. |
|
Store Name |
Char(22) |
N/A |
Name of the local store. |
|
Disc Data |
Char(2) |
NULL |
Discretionary data. Any kind of data specific to the transaction. |
|
Reserved |
Number(1) |
1 |
Constant number. |
|
Trace No |
Number(15) |
N/A |
Used to uniquely identify each entry within a batch. The first 8 digits contain the routing number of the ODFI and the other 7 contains a sequence number. |
|
ACH CBR Addendum |
Section No. |
Number(3) |
701 |
Constant number. |
Payment Info |
Char(80) |
Null |
Payment related information. |
|
Reserved |
Number(4) |
0001 |
Constant number |
|
Trace Seq No |
Number(7) |
N/A |
Sequence number part of the Trace Number of the entry record to which this addendum is referring. |
|
ACH Batch Control |
Section No. |
Number(4) |
8225 |
Constant number. |
Batch Line Count |
Number(6) |
N/A |
The number of entries and addenda in the batch. |
|
Hash Count |
Number(10) |
N/A |
Sum of the RDFI IDs in the detail records. |
|
Total Batch Debit |
Number(12) |
N/A |
Contains the accumulated debit and debit for the file * 10000 (4 implied decimal places). |
|
Total Batch Credit |
Number(12) |
N/A |
Contains the accumulated credit and credit for the file * 10000 (4 implied decimal places). |
|
Comp Id |
Char(10) |
N/A |
An alphanumeric code identifying the company. |
|
Auth |
Char(19) |
Null |
Message Authentication Code. The first 8 characters represent a code from the Data Encryption Standard (DES) algorithm. The remaining eleven characters are blanks. |
|
Reserved |
Char(6) |
Null |
Reserved. |
|
ODFI Id |
Number(8) |
N/A |
8-digit routing number of the ODFI. |
|
Batch No |
Number(7) |
N/A |
Batch number. |
|
ACH File Control |
Section No. |
Number(1) |
9 |
Constant number. |
Batch count |
Number(6) |
N/A |
The number of batches sent in the file. |
|
Block count |
Number(6) |
N/A |
The number of physical blocks in the file, including both File Header and File Control Records. This is the ceiling of the number of records divided by the blocking factor, which is 10. |
|
Entry count |
Number(8) |
N/A |
The number of entries and addenda in the file. |
|
Total hash count |
Number(10) |
N/A |
Sum of the Entry Hash fields on the Batch Control Records. |
|
Total file debit |
Number(12) |
N/A |
Contains the accumulated debit and debit for the file * 10000 (4 implied decimal places). |
|
Total file credit, |
Number(12) |
N/A |
Contains the accumulated credit and credit for the file * 10000 (4 implied decimal places). |
|
Reserved |
Char(39) |
NULL |
Reserved. |
|
ACH Completed Block |
End string |
Char(94) |
N/A |
Mark the end of the file: a string of 94 '9' characters. The number of end lines with a string of 94 '9' characters is identified by the following equation: 10 - mod (number of lines in the file, 10). |
Download of Escheated Vouchers from Sales Audit for Payment (saescheat)
Module Name |
saescheat.pc |
Description |
Download of Escheated Vouchers from Sales Audit for Payment |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RSA05 |
Wrapper Script |
rmswrap.ksh |
Design Overview
The laws of individual states and countries may require a retailer to return monies for aged, unclaimed gift certificates, and vouchers. This process is called escheatment. This program writes records for this data to tables that are read into Invoice Matching by the program saexpim.pc. The data can then be sent as invoices approved for payment to a financial application.
The saescheat batch program will set the status of vouchers that have met certain state's escheats rules or have expired to the proper status and produce a total for later export to Invoice Matching. The rules for escheatment are defined on the sa_escheatment_options table.
Restart/Recovery
The logical unit of work is a store/day. The program commits when the number of store/day records processed has reached the commit_max_ctr.
Export DSD and Escheatment from Sales Audit to Invoice Matching (saexpim)
Module Name |
saexpim.pc |
Description |
Export DSD and Escheatment from Sales Audit to Invoice Matching |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RSA04 |
Wrapper Script |
rmswrap.ksh |
Design Overview
The purpose of this program is to support interfacing invoices from Direct Store Delivery and Escheatment sales audit transactions to the Invoice Matching application. Direct Store Delivery invoices refer to products or services that are delivered to the store and paid for at the store. This program will take DSD invoices that have been staged to the transaction header table by the saimptlog.pc program and move them into the invoice header table. All DSD transactions will be assumed paid. They can be assumed received if there is a proof of delivery number listed on them. Transactions with a vendor invoice ID or a proof of delivery number should be matched to any existing invoice in the invoice header, and that invoice updated with the new information being interfaced. Invoices that do not match an existing invoice in the invoice head table will need to be inserted. Each transaction will be exported to the invoice head table only once.
The Sales Audit Transaction type used to identify invoices for Direct Store Delivery transactions will be “Paid Out". The Paid Out transaction has a code of 'PAIDOU'. The Sales Audit sub-transaction types will be used to identify whether the invoice is an “Expense Vendor Payout" or a “Merchandise Vendor Payout". The codes are 'EV' for Expense Vendor Payout and 'MV' for Merchandise Vendor Payout. Any Paid Out transaction with a sub transaction type of Expense Vendor will create a non-merchandise invoice and cause a record to be written to the invoice non-merchandise table. Sales Audit will store non-merchandise codes in the reason_code field on sa_tran_head. Valid values for these reason codes should correspond to the codes stored on the non_merch_code_head table.
In addition to DSD invoices, this program will also interface Escheatment totals to Invoice Matching. Escheatment is the process where an unredeemed gift certificate/voucher or credit voucher will, after a set period of time, be paid out as income to the issuing retailer, or in some states, the state receives this escheatment income. Sales Audit will be the governing system that determines who receives this income, but Invoice Matching will send the totals, with the related Partner, to an Accounts Payable system. Escheatment information will be stored on the Sales Audit SA_TOTALS table and will be used to create non-merchandise invoices in Invoice Matching. These invoices will be assumed not paid.
Restart/Recovery
The logical unit of work for this module is defined as a unique store/day combination. Records will be fetched, updated, and inserted based on the commit_max_ctr specified on the restart_control table. Only two commits will be done, one to establish the store/day lock and another at the end, to release the lock after a store/day has been completely processed.In case of failure, all work done will be rolled back to the point right after the call to get_lock and releases the lock. Thus, the rollback segment should be large enough to hold all inserts into sa_exported for one store_day.
Export from Sales Audit to Oracle Retail Analytics (saexport_sales_to_dw)
Module Name |
saexpdw.pc |
Description |
Export from ReSA to Oracle Retail Analytics |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
KSH |
Catalog ID |
RSA02 |
Wrapper Script |
N/A |
Design Overview
The purpose of this batch module is to fetch all sales and return transactions that do not have Retail Analytics errors
from the Oracle Retail Sales Audit (ReSA) database tables and export it into the interface tables SA_EXPDW_RDW*
. RDS views have been written on the top of these interface tables so that the Oracle Retail Analytics application can fetch
the exported sales data. The data will be exported at the store-day level. If the transaction has a status of Deleted and
if it has been previously exported, a reversal of the transaction will be exported.
A batch process will export three types of data based on store day level. First is a header-level record: it contains the
transaction head and item information, which is exported to the SA_EXPDW_RDWT_HEAD
table. Second is the detail
level record, which contains the discount of the transaction at the header level and is exported to the SA_EXPDW_RDWT_DETAIL
table. Third is tender-level information, which is exported to the SA_EXPDW_RDWF_DETAIL
table.
Note:
This batch can run in two modes – trickle mode and batch mode. If ‘Y’ is passed as a parameter while running the batch, then the batch runs in trickle mode. If ‘N’ or the no parameter is passed, it runs in normal batch mode.Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
SA_EXPDW_RDWT_HEAD |
No |
Yes |
No |
No |
SA_EXPDW_RDWT_DETAIL |
No |
Yes |
No |
No |
SA_EXPDW_RDWF_DETAIL |
No |
Yes |
No |
No |
SA_STORE_DAY |
Yes |
No |
No |
No |
SA_EXPORT_LOG |
Yes |
No |
Yes |
No |
SA_EXPORTED |
Yes |
Yes |
Yes |
No |
SA_EXPORTED_REV |
Yes |
No |
No |
No |
SA_TRAN_HEAD |
Yes |
No |
No |
No |
SA_TRAN_HEAD_REV |
Yes |
No |
No |
No |
SA_TRAN_ITEM |
Yes |
No |
No |
No |
SA_TRAN_ITEM_REV |
Yes |
No |
No |
No |
SA_TRAN_DISC |
Yes |
No |
No |
No |
SA_TRAN_DISC_REV |
Yes |
No |
No |
No |
SA_TRAN_TENDER |
Yes |
No |
No |
No |
SA_TRAN_TENDER_REV |
Yes |
No |
No |
No |
SA_VOUCHER |
Yes |
No |
No |
No |
SA_STORE_PRICE_HIST_TEMP |
Yes |
Yes |
No |
No |
ORDCUST |
Yes |
No |
No |
No |
Export from Sales Audit to Oracle Retail Insights (saexpdw)
Module Name |
saexpdw.pc |
Description |
Export from Sales Audit to Oracle Retail Analytics |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RSA02 |
Wrapper Script |
batch_resa2dw.ksh |
Design Overview
The purpose of this batch module is to fetch all sales and return transactions that do not have Retail Analytics errors from the Sales Audit database tables for transmission to the Oracle Retail Analytics application. The data will be sent at the store day level. If the transaction has a status of Deleted, and if it has been previously Transmitted, a reversal of the transaction will be sent.
Note:
This batch program can be run in two modes - trickle mode and batch mode. If 'Y' is passed as a parameter while running the batch program, then the batch runs in trickle mode. If 'N' or no parameter is passed, it runs in normal batch mode.
Restart/Recovery
The logical unit of work for this module is defined as a unique store/day combination. Records will be fetched, updated, and inserted based on the commit_max_ctr. Only two commits will be done: one to establish the store/day lock and another at the end, to release the lock after a store/day has been completely processed. The RDWT, RDWF, RDWS, and RDWC formatted output files will be created with temporary names and renamed just before the end of store/day commit.
In case of a failure, all the work done will be rolled back to the point right after the call to get_lock() and the lock is released. Thus, the rollback segment should be large enough to hold all inserts into sa_exported for one store/day.
I/O Specification
Integration Type |
Download from Sales Audit |
File Name |
RDWT_ appended with store number, business date, and system date. RDWF_ appended with store number, business date, and system date. RDWS_ appended with store number, business date, and system date. RDWC_ appended with store number, business date, and system date. |
Integration Contract |
IntCon000041 (RDWT) IntCon000156 (RDWF) IntCon000157 (RDWS) IntCon000158 (RDWC) |
Four output files will be created for each store_day:
-
RDWT - Transaction File
-
RDWF - Form of Payment (Tender) file
-
RDWS - Store Totals output file
-
RDWC - Cashier output File
Each output file is converted into a format for loading into Retail Analytics by the resa2dw Perl script.
Sales Audit - File Layout - Retail Analytics
-
File layouts for the interface between sales audit and Retail Analytics.
-
Char fields are left justified and blank filled.
-
Number fields are right justified and zero filled. They can contain only numbers.
-
Numeric fields are left justified and blank filled. They can contain only numbers.
RDWT File
Table 6-24 RDWT File
Record Name | Field Name | Field Type | Default Value | Description | Required |
---|---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
File Type Definition |
Char(4) |
RDWT |
Identifies file as ‘Retail Analytics Transaction file’ |
Yes |
|
File Create Date |
Number(14) |
create date |
Date file was written by external system. Format YYYYMMDDHH24MISS |
Yes |
|
Transaction Header |
File Type Record Descriptor |
Char(5) |
THEAD |
Identifies transaction record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
Business date |
Number(8) |
Format YYYYMMDD (Note, This is the date the Retail Analytics will consider the transaction date) |
Yes |
||
Transaction Date |
Number(14) |
transaction date |
Date sale/return transaction was processed at the POS. Format YYYYMMDDHH24MISS (Note, the Retail Analytics only uses the HH24MI part of this date) |
Yes |
|
Location |
Number(10) |
specified by external system |
Store or warehouse identifier. This value is now being determined based on either the Account for Sale or Account for Return system option. |
Yes |
|
Register ID |
Char(5) |
The register identifier |
Yes, -1 for null |
||
Banner ID |
Char(4) |
The unique identifier of the banner. |
Yes, -1 for null |
||
Line Media ID |
Char(10) |
The identifier of the media for the order line. For non-merchandise items, such as Shipping & Handling, Service Lines and gift certificates, the media code will be that of the order line it’s associated. |
Yes, -1 for null |
||
Selling Item ID |
Char(25) |
The unique identifier of a selling item. |
Yes, -1 for null |
||
Customer Order Header ID |
Char(48) |
The unique identifier of a customer order. |
Yes, -1 for null |
||
Customer Order Line ID |
Char(30) |
The identifier of a customer order line. For a Value Added Service, like monogramming, this will be the line number for the item which the service was applied. |
Yes, -1 for null |
||
Customer Order Create Date |
Char(8) |
The date when the customer order was created/placed. |
Yes, -1 for null |
||
Cashier Identifier |
Char(10) |
The cashier number. This will be the unique employee number. |
Yes, -1 for null |
||
Salesperson Identifier |
Char(10) |
The salesperson number. This will be the unique employee number. |
Yes, -1 for null |
||
Customer ID Type |
Char(6) |
The type of ID number used by this customer. |
Yes, -1 for null |
||
Customer ID Number |
Char(16) |
Customer id associated with the transaction. |
Yes, -1 for null |
||
Transaction Number |
Number(10) |
The unique transaction reference number generated by the POS. |
Yes |
||
Original Register ID |
Char(5) |
Register ID of the original transaction. |
Yes for a transaction type of ‘PVOID’. |
||
Original Transaction Number |
Number(10) |
Transaction number of the original transaction. |
Yes for a transaction type of ‘PVOID’, 'EEXCH' and 'RETURN' |
||
Transaction Header Number |
Numeric(20) |
Unique reference used within sales audit to represent the date/store/register/tran_no |
No |
||
Revision number |
Number(3) |
Number used to identify the version of the transaction being sent. |
Yes |
||
Sales Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Determines if the Total Sales Quantity and Total Sales Value are positive or negative. |
Yes |
|
Transaction Type |
Char(6) |
Transaction type code |
Yes |
||
Sub Transaction Type |
Char(6) |
The Sub Transaction type |
Yes, -1 for null |
||
Retail Type |
Char(1) |
‘R’egular, ‘P’romo, or ‘C’learance |
Yes |
||
Item_Seq_No |
Number(4) |
The order in which items were entered during the transaction. |
No |
||
Employee Number (Cashier) |
Char(10) |
Employee identification number. This will only be populated if the sub transaction type is ‘EMP’. |
Yes, -1 for null |
||
Receipt Indicator |
Char(1) |
Flag that identifies returns that have been processed without a receipt. This field will only be populated if the transaction type is ‘RETURN’. |
No |
||
Reason Code |
Char(6) |
A reason is required with a Paid In/Out transaction type, and optional with a return transaction. |
Yes, -1 for null |
||
Vendor number |
Number(10) |
This will only get populated when the paid in code is Expense Vendor |
No |
||
Item Type |
Char(6) |
item type identifier |
Type of item sold, ‘ITEM’, ‘REF’, ‘GCN’ (gift certificate number), or ‘NMITEM’ |
No |
|
Item |
Char(25) |
ID number of the item or gift certificate. |
No. Required if Item Type is not null. |
||
Ref Item |
Char(25) |
Sub-transaction level item |
No. Also, this field can never be populated without a transaction level item in the item field. |
||
Taxable Indicator |
Char(1) |
Taxable/non-taxable status indicator |
No |
||
Entry/mode |
Char(6) |
Indicator that identifies whether the item was scanned or manually entered |
No |
||
Department |
Number(4) |
Department of item sold or returned. Yes need to validate if using ReSA. |
No |
||
Class |
Number(4) |
Class of item sold or returned. Yes need to validate if using ReSA. |
No |
||
Subclass |
Number(4) |
Subclass of item sold or returned. Yes need to validate if using ReSA. |
No |
||
Total Sales Quantity |
Number(12) |
Number of units sold at a particular location with 4 implied decimal places. |
No |
||
Total Transaction Value |
Number(20) |
Sales value, net sales value of goods sold/returned with 4 implied decimal places. |
No |
||
Override Reason |
Char(6) |
This column will be populated when an item’s price has been overridden at the POS to define why it was overridden. This will also always be sent if the transaction originated in RCOM. |
Yes, -1 for null |
||
Return Reason |
Char(6) |
The reason an item was returned. |
Yes, -1 for null |
||
Total original sign |
Char(1) |
‘P’- positive ‘N’ – negative |
No |
||
Total Original Sales Value |
Number(20) |
This column will be populated when the item's price was overridden at the POS and the item's original unit retail is known. This will always be written when the transaction originated in RCOM. This has 4 implied decimals. |
No |
||
Weather |
Char(6) |
For transaction types of ‘COND’, this field will store the type of weather for the store-day. |
No |
||
Temperature |
Char(6) |
For transaction types of ‘COND’, this field will store the type of temperature for the store-day. |
No |
||
Traffic |
Char(6) |
For transaction types of ‘COND’, this field will store the type of traffic for the store-day. |
No |
||
Construction |
Char(6) |
For transaction types of ‘COND’, this field will store info regarding any construction on that store-day. |
No |
||
Drop Shipment Indicator |
Char(1) |
‘Y’ or ‘N’ |
Indicates whether item is involved in a drop shipment. |
No |
|
Item Status |
Char(6) |
The status of the item, required for voided or exchanged items. Valid values are found in the code_detail table under code_type SASI. |
Y, -1 for null |
||
Tran Process Sys |
Char(3) |
This column holds the name of the system that processed the transaction. This will be used for filtering duplicate transactions coming from the different systems for export to downstream systems. Expected values are POS – Point of Sale, OMS – Order Management System and SIM – Store Inventory Management. |
Y, -1 for null |
||
Return Wh |
Number(10) |
This column contains the physical warehouse ID for the warehouse identifier where the item was returned. |
N, -1 for null |
||
Fulfill Order No |
Char(48) |
This column holds the number from OMS related to the fulfillment details. One or more fulfillment orders could relate back to a single customer order in OMS. This column is required if the order is a cross channel order (i.e. Sales Type = ‘E’) and the item status is ‘ORD’. |
N, -1 for null |
||
No Inventory Return Ind |
Char(1) |
This column contains an indicator that identifies a return without inventory. This is generally a non-required column, but in case of Returns, this is required. |
N |
||
Sales Type |
Char(1) |
This column indicates whether the line item is a Regular Sale, a customer order serviced by OMS (External CO) or a customer order serviced by a store (In Store CO). |
Y |
||
Return Disposition |
Char(10) |
This column will contain the disposition code published by RWMS as part of the Returns upload to OMS. |
N, -1 for null |
||
Original Store |
Char(10) |
This column contains the store ID for the original store. |
N |
||
Original Transaction Number |
Number(10) |
Original transaction number for the returned item. |
N |
||
Reference Number 1 |
Char(30) |
No |
|||
Reference Number 2 |
Char(30) |
No |
|||
Reference Number 3 |
Char(30) |
No |
|||
Reference Number 4 |
Char(30) |
No |
|||
Reference Number 5 |
Char(30) |
No |
|||
Reference Number 6 |
Char(30) |
No |
|||
Reference Number 7 |
Char(30) |
No |
|||
Reference Number 8 |
Char(30) |
No |
|||
Reference Number 25 |
Char(30) |
No |
|||
Reference Number 26 |
Char(30) |
No |
|||
Reference Number 27 |
Char(30) |
No |
|||
Reference Number 28 |
Char(30) |
No |
|||
Reference Number 29 |
Char(30) |
No |
|||
Reference Number 30 |
Char(30) |
No |
|||
Reference Number 31 |
Char(30) |
No |
|||
Fulfill Loc Type |
Char(2) |
This column contains the fulfillment location type of the customer order. Valid values are ‘S’ for physical store and ‘V’ for virtual store. |
N, -1 for null |
||
Fulfill Loc ID |
Number(10) |
This column contains the fulfillment location of the customer order. It can only be either a physical store or a virtual store. |
N, -1 for null |
||
Posting Store |
Number(10) |
This column contains the store at which the item sale/return should be accounted for in case of cross-store sales happening at co-located stores. It is expected that this field will be populated only for items that are checked out at a different store from the one at which they are originally managed. |
N, -1 for null |
||
Transaction Detail |
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies transaction record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
Discount Type |
Char(6) |
Code for discount type from code_detail, code_type = ‘SADT’ |
No |
||
Promotional Transaction Type |
Char(6) |
Code for promotional type from code_detail, code_type = ‘PRMT’ |
Yes |
||
Promotion Number |
Number(10) |
promotion number |
Promotion number from Merchandising |
No |
|
Promotion Component Number |
Number(10) |
Offer ID from Pricing |
Required if it is a promotional sale. |
||
Coupon Number |
Char(40) |
Yes if Discount Type is ‘SCOUP’. |
|||
Coupon Reference Number |
Char(16) |
No |
|||
Sales Quantity |
Number(12) |
Number of units sold in this prom type with 4 implied decimal places. |
No |
||
Transaction Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Yes |
||
Transaction Value |
Number(20) |
Value of units sold in this promotion type with 4 implied decimal places. |
Yes |
||
Discount Value |
Number(20) |
Value of discount given in this prom type with 4 implied decimal places. |
Yes |
||
Reference Number 13 |
Char(30) |
No |
|||
Reference Number 14 |
Char(30) |
No |
|||
Reference Number 15 |
Char(30) |
No |
|||
Reference Number 16 |
Char(30) |
No |
|||
Transaction Trailer |
File Type Record Descriptor |
Char(5) |
TTAIL |
Identifies file record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
Transaction Count |
Number(6) |
specified by external system |
Number of TDETL records in this transaction set |
Yes |
|
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
File Record Counter |
Number(10) |
Number of records/transactions processed in current file (only records between head & tail) |
Yes |
Transaction Item Information Produced by saexpdw.pc after Translation by resa2dw
Table 6-25 File Layout
Record Name | Field Name | Field Type | Default Value | Description | Required |
---|---|---|---|---|---|
Business date |
Number(8) |
Format YYYYMMDD |
Yes |
||
Transaction Date |
Number(14) |
transaction date |
Date sale/return transaction was processed at the POS. Format YYYYMMDDHH24MISS |
Yes |
|
Location |
Number(10) |
specified by external system |
Store or warehouse identifier. This value is now being determined based on either the Account for Sale or Account for Return system option. |
Yes |
|
Register ID |
Char(5) |
The register identifier |
Yes, -1 for null |
||
Banner ID |
Char(4) |
The unique identifier of the banner. |
Yes, -1 for null |
||
Line Media ID |
Char(10) |
The identifier of the order line media. For non-merchandise items, such as Shipping & Handling, Service Lines and gift certificates, the media code will be that of the order line it’s associated. |
Yes, -1 for null |
||
Selling Item ID |
Char(25) |
The unique identifier of a selling item. |
Yes, -1 for null |
||
Customer Order Header ID |
Char(48) |
The unique identifier of a customer order. |
Yes, -1 for null |
||
Customer Order Line ID |
Char(30) |
The identifier of a customer order line. For a Value Added Service, like monogramming, this will be the line number for the item, which the service was applied. |
Yes, -1 for null |
||
Customer Order Create Date |
Number(8) |
The customer order creation date |
Yes, ‘transaction date’ for null |
||
Cashier Identifier |
Char(10) |
The cashier number. This will be the unique employee number. |
Yes, -1 for null |
||
Salesperson Identifier |
Char(10) |
The salesperson number. This will be the unique employee number. |
Yes, -1 for null |
||
Customer ID Type |
Char(6) |
The type of ID number used by this customer. |
Yes, -1 for null |
||
Customer ID Number |
Char(16) |
Customer id associated with the transaction. |
Yes, -1 for null |
||
Transaction Number |
Number(10) |
The unique transaction reference number generated by the POS. |
Yes |
||
Original Register ID |
Char(5) |
Register ID of the original transaction. |
Yes for a transaction type of ‘PVOID’. |
||
Original Transaction Number |
Number(10) |
Transaction number of the original transaction. |
Yes for a transaction type of ‘PVOID’. |
||
Transaction Header Number |
Numeric(20) |
Unique reference used within sales audit to represent the date/store/register/tran_no |
Yes |
||
Revision number |
Number(3) |
Number used to identify the version of the transaction being sent. |
Yes |
||
Sales Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Determines if the Total Sales Quantity and Total Sales Value are positive or negative. |
Yes |
|
Transaction Type |
Char(6) |
Transaction type code |
Yes |
||
Sub Transaction Type |
Char(6) |
The Sub Transaction type |
Yes, -1 for null |
||
Retail Type |
Char(1) |
‘R’egular, ‘P’romo, or ‘C’learance |
Yes |
||
Item_Seq_No |
Number(4) |
The order in which items were entered during the transaction. |
No |
||
Employee Number (Cashier) |
Char(10) |
Employee identification number. This will only be populated if the sub transaction type is ‘EMP’. |
Yes, -1 for null |
||
Receipt Indicator |
Char(1) |
Flag that identifies returns that have been processed without a receipt. This field will only be populated if the transaction type is ‘RETURN’. |
No |
||
Reason Code |
Char(6) |
A reason is required with a Paid In/Out transaction type, and optional with a return transaction. |
Yes, -1 for null |
||
Vendor number |
Numeric(10) |
This will only get populated when the paid in code is Expense Vendor |
No |
||
Item Type |
Char(6) |
item type identifier |
Type of item sold, ‘ITEM’, ‘REF’, ‘GCN’ (gift certificate number), or ‘NMITEM’ |
No |
|
Item |
Char(25) |
ID number of the item or gift certificate. |
No. Required if Item Type is not null. |
||
Ref Item |
Char(25) |
Sub-transaction level item |
No. Also, this field can never be populated without a transaction level item in the item field. |
||
Taxable Indicator |
Char(1) |
Taxable/non-taxable status indicator |
No |
||
Entry/mode |
Char(6) |
Indicator that identifies whether the item was scanned or manually entered |
No |
||
Department |
Number(4) |
Department of item sold or returned. Yes need to validate if using ReSA. |
No |
||
Class |
Number(4) |
Class of item sold or returned. Yes need to validate if using ReSA. |
No |
||
Subclass |
Number(4) |
Subclass of item sold or returned. Yes need to validate if using ReSA. |
No |
||
Total Sales Quantity |
Number(12) |
Number of units sold at a particular location with 4 implied decimal places. |
No |
||
Total Transaction Value |
Number(20) |
Sales value, net sales value of goods sold/returned with 4 implied decimal places. |
No |
||
Override Reason |
Char(6) |
This column will be populated when an item price has been overridden at the POS to define why it was overridden. This will always be sent if the transaction originated in RCOM. |
Yes, -1 for null |
||
Return Reason |
Char(6) |
The reason an item was returned. |
Yes, -1 for null |
||
Total original sign |
Char(1) |
‘P’- positive ‘N’ – negative |
No |
||
Total Original Sales Value |
Number(20) |
This column will be populated when the item's price was overridden at the POS and the item's original unit retail is known. This will always be sent if the transaction originated in RCOM. This has 4 implied decimals. |
No |
||
Weather |
Char(6) |
For transaction types of ‘COND’, this field will store the type of weather for the store-day. |
No |
||
Temperature |
Char(6) |
For transaction types of ‘COND’, this field will store the type of temperature for the store-day. |
No |
||
Traffic |
Char(6) |
For transaction types of ‘COND’, this field will store the type of traffic for the store-day. |
No |
||
Construction |
Char(6) |
For transaction types of ‘COND’, this field will store info regarding any construction on that store-day. |
No |
||
Drop Shipment Indicator |
Char(1) |
‘Y’ or ‘N’ |
Indicates whether item is involved in a drop shipment. |
No |
|
Item Status |
Char(6) |
The status of the item, required for voided or exchanged items. Valid values are found in the code_detail table under code_type SASI. |
Y, -1 for null |
||
Tran Process Sys |
Char(3) |
This column holds the name of the system that processed the transaction. This will be used for filtering duplicate transactions coming from the different systems for export to downstream systems. Expected values are POS – Point of Sale, OMS – Order Management System and SIM – Store Inventory Management. |
Y, -1 for null |
||
Return Wh |
Number(10) |
This column contains the physical warehouse ID for the warehouse identifier where the item was returned. |
N, -1 for null |
||
Fulfill Order No |
Char(48) |
This column holds the number from OMS related to the fulfillment details. One or more fulfillment orders could relate back to a single customer order in OMS. This column is required if the order is a cross channel order (i.e. Sales Type = ‘E’) and the item status is ‘ORD’. |
N, -1 for null |
||
No Inventory Return Ind |
Char(1) |
This column contains an indicator that identifies a return without inventory. This is generally a non-required column, but in case of Returns, this is required. |
N |
||
Sales Type |
Char(1) |
This column indicates whether the line item is a Regular Sale, a customer order serviced by OMS (External CO) or a customer order serviced by a store (In Store CO). |
Y |
||
Return Disposition |
Char(10) |
This column will contain the disposition code published by RWMS as part of the Returns upload to OMS. |
N, -1 for null |
||
Original Store |
Char(10) |
This column contains the store ID for the original store. |
No |
||
Original Transaction Number |
Number(10) |
Original transaction number for the returned item. |
No |
||
Discount Type |
Char(6) |
Code for discount type from code_detail, code_type = ‘SADT’ |
No |
||
Promotional Transaction Type |
Char(6) |
Code for promotional type from code_detail, code_type = ‘PRMT’ |
Yes |
||
Promotion Number |
Number(10) |
promotion number |
Promotion number from Merchandising |
No |
|
Promotion Component Number |
Numbr(10) |
Offer ID from Pricing |
Required if it is a promotional sale. |
||
Coupon Number |
Char(40) |
Yes if Discount Type is ‘SCOUP’. |
|||
Coupon Reference Number |
Char(16) |
No |
|||
Sales Quantity |
Number(12) |
Number of units sold in this prom type with 4 implied decimal places. |
No |
||
Transaction Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Yes |
||
Transaction Value |
Number(20) |
Value of units sold in this promotion type with 4 implied decimal places. |
Yes |
||
Discount Value |
Number(20) |
Value of discount given in this prom type with 4 implied decimal places. |
Yes |
||
Reference Number 1 |
Char(30) |
No |
|||
Reference Number 2 |
Char(30) |
No |
|||
Reference Number 3 |
Char(30) |
No |
|||
Reference Number 4 |
Char(30) |
No |
|||
Reference Number 5 |
Char(30) |
No |
|||
Reference Number 6 |
Char(30) |
No |
|||
Reference Number 7 |
Char(30) |
No |
|||
Reference Number 8 |
Char(30) |
No |
|||
Reference Number 13 |
Char(30) |
No |
|||
Reference Number 14 |
Char(30) |
No |
|||
Reference Number 15 |
Char(30) |
No |
|||
Reference Number 16 |
Char(30) |
No |
|||
Reference Number 25 |
Char(30) |
No |
|||
Reference Number 26 |
Char(30) |
No |
|||
Reference Number 27 |
Char(30) |
No |
|||
Reference Number 28 |
Char(30) |
No |
|||
Reference Number 29 |
Char(30) |
No |
|||
Reference Number 30 |
Char(30) |
No |
|||
Reference Number 31 |
Char(30) |
No |
|||
Fulfill Loc Type |
Char(2) |
This column contains the fulfillment location type of the customer order. Valid values are ‘S’ for physical store and ‘V’ for virtual store. |
N, -1 for null |
||
Fulfill Loc ID |
Number(10) |
This column contains the fulfillment location of the customer order. It can only be either a physical store or a virtual store. |
N, -1 for null |
||
Posting Store |
Number(10) |
This column contains the store at which the item sale/return should be accounted for in case of cross-store sales happening at co-located stores. It is expected that this field will be populated only for items that are checked out at a different store from the one at which they are originally managed. |
N, -1 for null |
RDWF File
Table 6-26 RDWF File
Record Name | Field Name | Field Type | Default Value | Description | Required |
---|---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
File Type Definition |
Char(4) |
RDWF |
Identifies file as ‘Retail Analytics Form of Payment (Tender) file’ |
Yes |
|
File Create Date |
Number(14) |
create date |
Date file was written by external system. Format YYYYMMDDHH24MISS |
Yes |
|
File Detail |
File Type Record Descriptor |
Char(5) |
FDETL |
Identifies file record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
Business date |
Number(8) |
Format YYYYMMDD |
Yes |
||
Transaction Date |
Number(14) |
transaction date |
Date sale/return transaction was processed at the POS. Format YYYYMMDDHH24MISS |
Yes |
|
Location |
Number(10) |
specified by external system |
Store or warehouse identifier. |
Yes |
|
Cashier Identifier |
Char(10) |
The cashier number. This will be the unique employee number. |
Yes, -1 for null |
||
Register Identifier |
Char(5) |
Yes, -1 for null |
|||
Sales Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Determines if the Total Sales Quantity and Total Sales Value are positive or negative. |
Yes |
|
Transaction Sequence Number |
Numeric(20) |
Unique reference used within sales audit to represent the date/store/ register/transaction number |
Yes |
||
Revision number |
Number(3) |
Number used to identify the version of the transaction being sent. |
Yes |
||
Transaction Type |
Char(6) |
Transaction type code. |
Yes |
||
Tender type group |
Char(6) |
Yes |
|||
Tender type id |
Number(6) |
Tender type code. |
Yes |
||
Tender amount |
Number(20) |
Tender amount. |
Yes |
||
Credit Card Entry Mode |
Char(6) |
Contains the method in which the transaction was entered at the POS. Possible entry modes could include: Terminal Used, Magnetic Strip Track One Read, Magnetic Strip Two Read, Magnetic Strip One Transmitted, or Magnetic Strip Two Transmitted. The code type for this field is ‘CCEM’. |
No |
||
Voucher Number |
Char(25) |
No |
|||
Voucher Age |
Numeric(5) |
Age of the gift certificate. Redeemed date minus sold date. |
Yes if Tender Type Group is ‘VOUCH’. |
||
Escheat Date |
Numeric(8) |
Date on which this gift certificate escheats. Format is YYYYMMDD. |
Yes if voucher can escheat. |
||
Coupon Number |
Char(40) |
Yes if Tender Type Group is ‘COUPON’. |
|||
Coupon Reference Number |
Char(16) |
No. Only if Tender Type Group is ‘COUPON’. |
|||
Transaction Status |
Char(1) |
Determines if the transaction is Present ('P') or Voided/Deleted ('R' - Reverse) |
NO |
||
Reference Number 9 |
Char(30) |
No |
|||
Reference Number 10 |
Char(30) |
No |
|||
Reference Number 11 |
Char(30) |
No |
|||
Reference Number 12 |
Char(30) |
No |
|||
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
File Record Counter |
Number(10) |
Number of records/transactions processed in current file (only records between head & tail) |
Yes |
Retail Analytics Form of Payment File after Translation by resa2dw
Table 6-27 Form of Payment File
Record Name | Field Name | Field Type | Default Value | Description | Required |
---|---|---|---|---|---|
Business date |
Number(8) |
Format YYYYMMDD |
Yes |
||
Transaction Date |
Number(14) |
transaction date |
Date sale/return transaction was processed at the POS. Format YYYYMMDDHH24MISS |
Yes |
|
Location |
Number(10) |
specified by external system |
Store or warehouse identifier. |
Yes |
|
Cashier Identifier |
Char(10) |
The cashier number. This will be the unique employee number. |
Yes, -1 for null |
||
Register Identifier |
Char(5) |
Yes, -1 for null |
|||
Sales Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Determines if the Total Sales Quantity and Total Sales Value are positive or negative. |
Yes |
|
Transaction Sequence Number |
Numeric(20) |
Unique reference used within sales audit to represent the date/store/ register/transaction number |
Yes |
||
Revision number |
Number(3) |
Number used to identify the version of the transaction being sent. |
Yes |
||
Transaction Type |
Char(6) |
Transaction type code. |
Yes |
||
Tender type group |
Char(6) |
Yes |
|||
Tender type id |
Number(6) |
Tender type code. |
Yes |
||
Tender amount |
Number(20) |
Tender amount. |
Yes |
||
Credit Card Entry Mode |
Char(6) |
Contains the method in which the transaction was entered at the POS. Possible entry modes could include: Terminal Used, Magnetic Strip Track One Read, Magnetic Strip Two Read, Magnetic Strip One Transmitted, or Magnetic Strip Two Transmitted. The code type for this field is ‘CCEM’. |
No |
||
Voucher Number |
Char(25) |
No |
|||
Voucher Age |
Number(5) |
Age of the gift certificate. Redeemed date minus sold date. |
Yes if Tender Type Group is ‘VOUCH’. |
||
Escheat Date |
Number(8) |
Date on which this gift certificate escheats. Format is YYYYMMDD. |
Yes if voucher can escheat. |
||
Coupon Number |
Char(40) |
Yes if Tender Type Group is ‘COUPON’. |
|||
Coupon Reference Number |
Char(16) |
No. Only if Tender Type Group is ‘COUPON’. |
|||
Transaction Status |
Char(1) |
Determines if the transaction is Present ('P') or Voided/Deleted ('R' - Reverse) |
No |
||
Reference Number 9 |
Char(30) |
No |
|||
Reference Number 10 |
Char(30) |
No |
|||
Reference Number 11 |
Char(30) |
No |
|||
Reference Number 12 |
Char(30) |
No |
RDWS File
Table 6-28 RDWS File
Record Name | Field Name | Field Type | Default Value | Description | Required |
---|---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
File Type Definition |
Char(4) |
RDWS |
Identifies file as ‘Retail Analytics Store Totals file’ |
Yes |
|
File Create Date |
Numeric(14) |
create date |
Date file was written by external system. Format YYYYMMDDHH24MISS |
Yes |
|
File Detail |
File Type Record Descriptor |
Char(5) |
FDETL |
Identifies transaction record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
Business date |
Number(8) |
Format YYYYMMDD |
Yes |
||
Location |
Number(10) |
specified by external system |
Store or warehouse identifier |
Yes |
|
Sales Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Determines if the Total Sales Quantity and Total Sales Value are positive or negative. |
Yes |
|
Total ID |
Char(10) |
Category identifier used to determine the type of total. |
Yes |
||
Reference Number 1 |
Char(30) |
No |
|||
Reference Number 2 |
Char(30) |
No |
|||
Reference Number 3 |
Char(30) |
No |
|||
Total Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Yes |
||
Total Amount |
Number(20) |
Total over/short amount with 4 implied decimal places. |
Yes |
||
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
File Record Counter |
Number(10) |
Number of records/transactions processed in current file (only records between head & tail) |
Yes |
Store Totals Information after Translation by resa2dw
Table 6-29 Store Totals Information
Record Name | Field Name | Field Type | Default Value | Description | Required |
---|---|---|---|---|---|
Business date |
Number(8) |
Format YYYYMMDD |
Yes |
||
Location |
Number(10) |
specified by external system |
Store or warehouse identifier |
Yes |
|
Sales Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Determines if the Total Sales Quantity and Total Sales Value are positive or negative. |
Yes |
|
Total ID |
Char(10) |
Category identifier used to determine the type of total. |
Yes |
||
Reference Number 1 |
Char(30) |
No |
|||
Reference Number 2 |
Char(30) |
No |
|||
Reference Number 3 |
Char(30) |
No |
|||
Total Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Yes |
||
Total Amount |
Number(20) |
Total over/short amount with 4 implied decimal places. |
Yes |
RDWC File
Table 6-30 RDWC File
Record Name | Field Name | Field Type | Default Value | Description | Required |
---|---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
File Type Definition |
Char(4) |
RDWC |
Identifies file as ‘Retail Analytics Cashier/Register Totals file’ |
Yes |
|
File Create Date |
Number(14) |
create date |
Date file was written by external system. Format YYYYMMDDHH24MISS |
Yes |
|
File Detail |
File Type Record Descriptor |
Char(5) |
FDETL |
Identifies transaction record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
Business date |
Number(8) |
Format YYYYMMDD |
Yes |
||
Location |
Number(10) |
specified by external system |
Store or warehouse identifier |
Yes |
|
Cashier Identifier |
Char(10) |
The cashier number |
If Cashier_id is NULL then Register_id has value. If Cashier_id has value then Register_id is NULL. Yes, -1 for null |
||
Register ID |
Char(5) |
The register identifier |
If Cashier_id is NULL then Register_id has value. If Cashier_id has value then Register_id is NULL. Yes, -1 for null |
||
Sales Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Determines if the Total Sales Quantity and Total Sales Value are positive or negative. |
Yes |
|
Total ID |
Char(10) |
Category identifier used to determine the type of total. |
Yes |
||
Reference Number 1 |
Char(30) |
No |
|||
Reference Number 2 |
Char(30) |
No |
|||
Reference Number 3 |
Char(30) |
No |
|||
Total Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Yes |
||
Total Amount |
Number(20) |
Total over/short amount with 4 implied decimal places. |
Yes |
||
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
|
File Line Identifier |
Number(10) |
specified by external system |
ID of current line being processed by input file. |
Yes |
|
File Record Counter |
Number(10) |
Number of records/transactions processed in current file (only records between head & tail) |
Yes |
Cashier/ Register Totals Information after Translation by resa2dw
Table 6-31 Cashier/Register Totals Information
Record Name | Field Name | Field Type | Default Value | Description | Required |
---|---|---|---|---|---|
Business date |
Number(8) |
Format YYYYMMDD |
Yes |
||
Location |
Number(10) |
specified by external system |
Store or warehouse identifier |
Yes |
|
Cashier Identifier |
Char(10) |
The cashier number |
If Cashier_id is NULL then Register_id has value. If Cashier_id has value then Register_id is NULL. Yes, -1 for null |
||
Register ID |
Char(5) |
The register identifier |
If Cashier_id is NULL then Register_id has value. If Cashier_id has value then Register_id is NULL. Yes, -1 for null |
||
Sales Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Determines if the Total Sales Quantity and Total Sales Value are positive or negative. |
Yes |
|
Total ID |
Char(10) |
Category identifier used to determine the type of total. |
Yes |
||
Reference Number 1 |
Char(30) |
No |
|||
Reference Number 2 |
Char(30) |
No |
|||
Reference Number 3 |
Char(30) |
No |
|||
Total Sign |
Char(1) |
‘P’- positive ‘N’ – negative |
Yes |
||
Total Amount |
Number(20) |
Total over/short amount with 4 implied decimal places. |
Yes |
Export Inventory Reservation/Release for In Store Customer Order & Layaway Transactions (saordinvexp)
Module Name |
saordinvexp.pc |
Description |
Export Inventory Reservation/Release for In Store Customer Order & Layaway Transactions from Sales Audit |
Functional Area |
Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RSA12 |
Wrapper Script |
rmswrap_multi_dnld_in.ksh |
Design Overview
This batch program will generate a flat file to reserve or un-reserve the inventory for items on in-store customer order or layaway transactions. Inventory will be reserved for items on customer order/layaway initiate and un-reserved for customer order/layaway cancel or complete transactions.
Customer orders can be categorized into two categories: In-Store Customer Orders and External Customer Orders. The In-Store Customer Orders are defined as orders that are serviced at the store and inventory reservation is done in Oracle Retail Store Inventory Management (SIM). While the External Customer orders are serviced by an external order management system, no inventory reservation will be made at the store in SIM.
This batch should only process records where the sales type is not equal to External Customer Sales, as it handles only the in-store type orders.
Restart/Recovery
The logical unit of work for this module is defined as a unique store/day combination.
Records are fetched, updated, and inserted in batches of pl_commit_max_ctr. Only two commits are done, one to establish the store/day lock and another at the end, to release the lock after a store/day is completely processed. The ORIN formatted output file is created with a temporary name and renamed just before the end of store/day commit.
In case of failure, all work done is rolled back to the point right after the call to get_lock() and the lock is released. Thus, the rollback segment should be large enough to hold all inserts into sa_exported for one store/day.
I/O Specification
Integration Type |
Inventory Export from Sales Audit to Merchandising |
File Name |
ORIN_<store>_<tran_date>_<sysdate> |
Integration Contract |
IntCon000049 |
Output File Layout
Table 6-32 Output File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record descriptor |
Char(5) |
FHEAD |
Identifies the file record type. |
File Line Id |
Char(10) |
0000000001 |
Sequential file line number. |
|
File type Definition |
Char(4) |
ORIN |
Identifies the file type. |
|
File Create Date |
Char(14) |
N/A |
File Create Date in YYYYMMDDHHMMSS format. |
|
Location |
Number(10) |
N/A |
Store location number. |
|
THEAD |
Record descriptor |
Char(5) |
THEAD |
Identifies the file record type. |
File Line Id |
Char(10) |
Sequential file line number. |
||
Transaction Date & Time |
Char(14) |
Transaction Date |
Date and time of the order processed. |
|
Transaction Type |
Char(6) |
SALE |
Transaction type code specifies whether the transaction is sale or return. |
|
TDETL |
Record descriptor |
Char(5) |
TDETL |
Identifies the file record type. |
File Line Id |
Char(10) |
N/A |
Sequential file line number. |
|
Item Type |
Char(3) |
REF or ITM |
Can be REF or ITM. |
|
Item |
Char(25) |
N/A |
ID number of the ITM or REF. |
|
Item Status |
Char(6) |
LIN - Layaway Initiate LCA - Layaway Cancel LCO - Layaway Complete PVLCO - Post void of Layaway complete ORI - Pickup/delivery Initiate ORC - Pickup/delivery Cancel ORD - Pickup/delivery Complete PVORD - Post void of Pick-up/delivery complete |
Type of transaction. |
|
Dept |
Number(4) |
N/A |
Department of item sold or returned. |
|
Class |
Number(4) |
N/A |
Class of item sold or returned |
|
Sub class |
Number(4) |
N/A |
Subclass of item sold or returned. |
|
Pack Ind |
Char(1) |
N/A |
Pack indicator of item sold or returned. |
|
Quantity Sign |
Chanr(1) |
P or N |
Sign of the quantity. |
|
Quantity |
Number(12) |
N/A |
Quantity * 10000 (4 implied decimal places), number of units for the given order (item) status. |
|
Selling UOM |
Char(4) |
N/A |
UOM at which this item was sold. |
|
Catchweight Ind |
Char(1) |
N/A |
Indicates if the item is a catchweight item. Valid values are Y or NULL. |
|
Customer Order number |
Char(48) |
N/A |
Customer Order number. |
|
Posting Store |
Number(10) |
Contains the store at which the item reservation/ reservation cancellation should occur in case of cross-store transactions happening at co-located stores. It is expected that this field will be populated only for items that are to be reserved (or have the reservation canceled) at a different store from the one at which the checkout happened. |
||
TTAIL |
File Type Record Descriptor |
Char(5) |
TTAIL |
Identifies file record type. |
File Line Identifier |
Number(10) |
Specified by Sales Audit |
ID of current line being processed by input file. |
|
Transaction count |
Number(6) |
Specified by Sales Audit |
Number of TDETL records in this transaction set. |
|
FTAIL |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type. |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
|
File Record Counter |
Number(10) |
Number of records/transactions processed in the current file (only records between FHEAD and FTAIL). |
Export of POS transactions from Sales Audit to Merchandising (saexprms)
Module Name |
saexprms.pc |
Description |
Export of POS transactions from Sales Audit to Merchandising |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RSA01 |
Wrapper Script |
rmswrap_multi_dnld_in.ksh |
Design Overview
The purpose of this batch module is to fetch all sale and return transactions that do not have Merchandising errors from the Sales Audit database tables for transmission to the Merchandising system. Transaction data is rolled up to the item/store/day/price point/sales type level for SALES transaction type and item/store/day/price point/sales type/no inventory return indicator/return disposition/return warehouse level for RETURN transaction types.
If unit of work system parameter is defined as 'S', then the whole store/day is skipped if any Merchandising error is found. If this value is 'T', then only transactions with Merchandising errors are skipped.
If the transaction has a status of Deleted and it has previously been transmitted, a reversal of the transaction will be sent.
A file is generated for each store/day.
Restart/Recovery
The logical unit of work for this module is defined as a unique store/day combination. Records will be fetched, updated, and inserted in batches of pl_commit_max_ctr. Only two commits will be done, one to establish the store/day lock and another at the end, to release the lock after a store/day has been completely processed. The POSU formatted output file will be created with a temporary name and renamed just before the end of store/day commit.
In case of failure, all work done will be rolled back to the point right after the call to get_lock() and the lock will be released. Thus, the rollback segment should be large enough to hold all inserts into sa_exported for one store/day.
I/O Specification
Integration Type |
Download from Sales Audit |
File Name |
"POSU_" appended with store number, business date and system date |
Integration Contract |
IntCon000044 |
Table 6-33 File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record descriptor |
Char(5) |
FHEAD |
Identifies the file record type. |
File Line Id |
Char(10) |
0000000001 |
Sequential file line number. |
|
File type definition |
Char(4) |
POSU |
Identifies the file type |
|
File Create Date |
Char(14) |
N/A |
File Create Date in |
|
Store |
Number(10) |
N/A |
Store location. |
|
Vat include indicator |
Char(1) |
N/A |
Determines whether or not the store values include VAT. Not required, but populated by Sales Audit. |
|
Vat region |
Number(4) |
N/A |
VAT region the given location is in. Not required, but populated by Sales Audit. |
|
Currency code |
Char(3) |
N/A |
Currency of the given location. Not required, but populated by Sales Audit. |
|
Currency retail decimals |
Number(1) |
N/A |
Number of decimals supported by given the currency for retails. Not required, but populated by Sales Audit. |
|
THEAD |
Record descriptor |
Char(5) |
THEAD |
Identifies the file record type. |
File Line Id |
Char(10) |
N/A |
Sequential file line number. |
|
Transaction date |
Char(14) |
N/A |
Transaction date in |
|
Item Type |
Char(3) |
REF or ITM |
Can be REF or ITM. |
|
Item |
Char(25) |
N/A |
ID number of the ITM or REF. |
|
Dept |
Number(4) |
N/A |
Department of item sold or returned. |
|
Class |
Number(4) |
N/A |
Class of item sold or returned. |
|
Sub Class |
Number(4) |
N/A |
Subclass of item sold or returned. |
|
Pack Ind |
Char(1) |
N/A |
Pack indicator of item sold or returned. |
|
Item Level |
Number(1) |
N/A |
Item level of item sold or returned. |
|
Tran level |
Number(1) |
N/A |
Transaction level of item sold or returned. |
|
Wastage Type |
Char(6) |
N/A |
Wastage type of item sold or returned. |
|
Wastage pct |
Number(12) |
N/A |
Waste pct (4 implied decimal places). |
|
Tran type |
Char(1) |
N/A |
Transaction type code to specify whether transaction is a sale or a return. |
|
Drop Shipment indicator |
Char(1) |
N/A |
Indicates whether the transaction is a drop shipment or not. |
|
Total sales qty |
Number(12) |
N/A |
Total sales quantity (4 implied decimal places). |
|
Selling UOM |
Char(4) |
N/A |
Selling Unit of Measure for the item. |
|
Sales sign |
Char(1) |
N/A |
Determines if the Total Sales Quantity and Total Sales Value are positive or negative. |
|
Total Sales Value |
Number(20) |
N/A |
Total sales value of goods sold/returned (4 implied decimal places). |
|
Last Date time modified |
Char(14) |
N/A |
Date and time of last modification in |
|
Catchweight indicator |
Char(1) |
N/A |
Indicates if item is a catchweight item. |
|
Total weight |
Number(12) |
N/A |
The actual weight of the item, only populated if |
|
Sub Tran type indicator |
Char(1) |
N/A |
Transction type for Sales Audit. Valid values are A, D, and NULL. |
|
Total IGTAX Value |
Number(20) |
N/A |
This indicates total of all IGTAX amount for the item. |
|
Sales Type |
Char(1) |
N/A |
This column indicates whether the line item is a Regular Sale, a customer order serviced by OMS (External CO), or a customer order serviced by a store (In Store CO). |
|
No Inventory Return Indicator |
Char(1) |
N/A |
This column contains an indicator that identifies a return without inventory. This is generally a non-required column, but in the case of Returns, this is required. |
|
Return Disposition |
Char(10) |
N/A |
This column contains the disposition code published by Oracle Retail Warehouse Management System (RWMS0 as part of the Returns upload to OMS. |
|
Return Warehouse |
Char(10) |
N/A |
This column contains the physical warehouse ID for the warehouse identifier where the item was returned. |
|
Customer Order No |
Char(48) |
N/A |
This column contains the customer order number ID. |
|
Fulfillment Order No |
Char(48) |
N/A |
This column contains the fulfillment order number ID. |
|
Fulfillment Loc Type |
Char(2) |
N/A |
This column contains the fulfillment location type. Code for the fulfillment loc type from |
|
Fulfillment Loc |
Number(10) |
N/A |
This column contains the fulfillment loc ID. |
|
Orig Store |
Number(10) |
N/A |
This column contains the original store value for a Return transaction. |
|
POS Tran Id |
Number(20) |
This column contains the unique identifier for a sale transaction. This is an Optional field. |
||
Posting Store |
Number(10) |
This column contains the store at which the item sale/return should be accounted for in case of cross-store sales happening at co-located stores. It is expected that this field will be populated only for items that are checked out at a different store from the one at which they are originally managed. |
||
TTAX |
Record descriptor |
Char(5) |
TTAX |
Identifies the file record type. |
File Line Id |
Char(10) |
N/A |
Sequential file line number. |
|
Tax Code |
Char(6) |
N/A |
The Tax Code of the item. |
|
Tax Rate |
Number(20) |
N/A |
The tax rate of the item (10 implied decimal places). |
|
Total Tax Amount |
Number(20) |
N/A |
The item level tax or prorated transaction level tax of the item (4 implied decimal places). |
|
TDETL |
Record descriptor |
Char(5) |
TDETL |
Identifies the file record type. |
File Line Id |
Char(10) |
N/A |
Sequential file line number. |
|
Promo Tran Type |
Char(6) |
N/A |
Code for the promotional type from |
|
Promotion Number |
Number(10) |
N/A |
Promotion number from Merchandising. |
|
Sales quantity |
Number(12) |
N/A |
Sales quantity sold for this promotion type (4 implied decimal places). |
|
Sales value |
Number(20) |
N/A |
Sales value for this promotion type (4 implied decimal places). |
|
Discount value |
Number(20) |
N/A |
Discount value for this promotion type (4 implied decimal places). |
|
Promotion component |
Number(10) |
N/A |
Links the promotion to additional pricing attributes. Contains the offer ID from Pricing. |
|
TTAIL |
Record descriptor |
Char(5) |
TTAIL |
Identifies the file record type. |
File Line Id |
Char(10) |
N/A |
Sequential file line number. |
|
Tran Record Counter |
Number(6) |
N/A |
Number of |
|
FTAIL |
Record descriptor |
Char(5) |
FTAIL |
Identifies the file record type. |
File Line Id |
Number(10) |
N/A |
Sequential file line number. |
|
File Record counter |
Number(10) |
N/A |
Number of records/transactions processed in the current file (only records between head and tail). |
Fields expected in POSU format based on changes adopted:
V16 | V16 with Customer Order Changes | V19 | |
---|---|---|---|
Fulfillment Order No |
No |
Yes |
Yes |
Fulfillment Loc Type |
No |
Yes |
Yes |
Fulfillment Loc |
No |
Yes |
Yes |
Orig Store |
No |
Yes |
Yes |
POS Tran Id |
No |
No |
Yes |
Design Assumptions
-
Tax can be sent either in TTAX or IGTAX regardless of default_tax_type of SVAT, GTAX, SALES or GTS. Prorated tax in TTAX will only be sent to Merchandising in all configuration.
-
POS can send either transactional level tax details in TTAX lines or item-level tax details in IGTAX lines through the RTLOG file to Sales Audit. These tax details will be passed on to Merchandising in the TTAX lines of the POSU file. Even though POS can pass multiple IGTAX/TTAX lines to Sales Audit and from Sales Audit to Merchandising, Merchandising only supports one tax code per item. If multiple taxes for an item are sent from POS to Sales Audit, they will be summed to a single tax in Merchandising sales upload process and assigned one of the applicable tax codes when writing tran_data 88.
Export of Revised Sale/Return Transactions from ReSA to SIM/SIOCS (saexpsim)
Module Name |
Saexpsim.pc |
Description |
Export of Revised Sale/Return Transactions from Sales Audit to SIM |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RSA14 |
Wrapper Script |
rmswrap_multi_dnld_in.ksh |
Design Overview
The purpose of this batch module is to fetch all revised sale and return transactions that do not have SIM errors from the Sales Audit database tables for transmission to SIM. It retrieves all quantity revision transaction data for SALES, RETURN, EEXCH, VOID, and SPLORD transaction types.
If sa_system_options.unit_of_work is S, the whole store/day is skipped if any SIM error is found. If this value is T, then only transactions with SIM errors are skipped.
The batch will only export transactions whose quantity has been revised. The batch will write these revised transactions to the output file along with a reversal of the quantity.
A file of type SIMT is generated for each store/day.
Restart/Recovery
The logical unit of work for this module is defined as a unique store/day combination. Records will be fetched, updated, and inserted in batches of pl_commit_max_ctr. Only two commits will be done, one to establish the store/day lock and another at the end, to release the lock after a store/day has been completely processed. The SIMT formatted output file will be created with a temporary name and renamed just before the end of store/day commit.
In case of failure, all work done will be rolled back to the point right after the call to get_lock() and the lock released. Thus, the rollback segment should be large enough to hold all inserts into SA_EXPORTED for one store/day.
I/O Specification
Integration Type |
Download from Sales Audit |
File Name |
SIMT_ appended by store number, business date, and system date |
Integration Contract |
IntCon000045 |
Output File Layout
Table 6-34 Output File
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record descriptor |
Char(5) |
FHEAD |
Identifies the file record type. |
File Line Id |
Char(10) |
0000000001 |
Sequential file line number. |
|
File type definition |
Char(4) |
SIMT |
Identifies the file type. |
|
Store |
Number(10) |
N/A |
Store location. |
|
Business Date |
Char(8) |
N/A |
Business Date in YYYYMMDD format. |
|
File Create Date |
Char(14) |
N/A |
File Create Date in YYYYMMDDHHMMSS format. |
|
THEAD |
Record descriptor |
Char(5) |
THEAD |
Identifies the file record type. |
File Line Id |
Char(10) |
N/A |
Sequential file line number. |
|
Transaction Number |
Number(10) |
N/A |
Transaction Identifier. |
|
Revision Number |
Number(3) |
N/A |
Revision Number of the transaction. |
|
Transaction date |
Char(14) |
N/A |
Transaction date in YYYYMMDDHHMMSS format. Corresponds to the date that the transaction occurred. |
|
Transaction Type |
Char(6) |
N/A |
Transaction Type. |
|
POS Transaction Indicator |
Char(1) |
N/A |
Indicates if the transaction was received from POS or manually created. Valid values: Y - POS N - Manual |
|
TDETL |
Record descriptor |
Char(5) |
TDETL |
Identifies the file record type. |
File Line Id |
Char(10) |
N/A |
Sequential file line number. |
|
Item Sequence Number |
Number(4) |
N/A |
Item sequence number. |
|
Item |
Char(25) |
N/A |
Identifies the merchandise item. |
|
Item number type |
Char(6) |
N/A |
Identifies the type of item number if the item type is ITEM or REF. |
|
Item Status |
Char(6) |
N/A |
Status of the item within the transaction, V for item void, S for sold item, R for returned item. ORI - Order Initiate ORC - Order Cancel ORD - Order Complete LIN - Layaway Initiate LCA - Layaway Cancel LCO - Layaway Complete |
|
Serial Number |
Char(128) |
N/A |
Unique ID. |
|
Pack Indicator |
Char(1) |
N/A |
Pack Indicator. |
|
Catchweight Indicator |
Char(1) |
N/A |
Catchweight Indicator. |
|
Quantity Sign |
Char(1) |
N/A |
Sign of the quantity. |
|
Quantity Value |
Number(12) |
N/A |
Number of items, with 4 implied decimal places. |
|
Standard Unit of Measure |
Char(4) |
N/A |
Standard Unit of Measure of the item. |
|
Selling Unit of Measure |
Char(4) |
N/A |
Unit of Measure of the quantity value. |
|
Waste Type |
Char(6) |
N/A |
Waste Type. |
|
Waste Percent |
Number(12) |
N/A |
Waste Percent. |
|
Drop Ship Indicator |
Char(1) |
N/A |
Indicates whether the item is part of a drop shipment. |
|
Actual Weight |
Number(12) |
N/A |
Contains the weight of the item sold, with 4 implied decimal places. |
|
Actual Weight Sign |
Char(1) |
N/A |
Sign of the actual weight. |
|
Reason Code |
Char(6) |
N/A |
Reason entered by the cashier for some transaction types. |
|
Sales Value |
Number(20) |
N/A |
Transaction value, with 4 implied decimal places |
|
Sales Value Sign |
Char(1) |
N/A |
Transaction value sign. |
|
Unit Retail |
Number(20) |
N/A |
Unit retail, with 4 implied decimal places. |
|
Sales Type |
Char(1) |
N/A |
Indicates if the transaction is an In Store Customer Order, External Customer Order, or Regular Sale. |
|
Customer Order Number |
Char(48) |
N/A |
Contains the customer order ID. |
|
Customer Order Type |
Char(6) |
N/A |
Customer order type. |
|
Fulfillment Order Number |
Char(48) |
N/A |
Contains the order ID of the fulfillment order. |
|
Customer Order Line Number |
Number(6) |
Contains customer order line number. |
||
TTAIL |
Record descriptor |
Char(5) |
TTAIL |
Identifies the file record type. |
File Line Id |
Char(10) |
N/A |
Sequential file line number. |
|
Tran Record Counter |
Number(6) |
N/A |
Number of TDETL records in this transaction set. |
|
FTAIL |
Record descriptor |
Char(5) |
FTAIL |
Identifies the file record type. |
File Line Id |
Number(10) |
N/A |
Sequential file line number. |
|
File Record counter |
Number(10) |
N/A |
Number of records/transactions processed in the current file (only records between head and tail). |
Export to Universal Account Reconciliation System from Sales Audit (saexpuar)
Module Name |
saexpuar.pc |
Description |
Export to Universal Account Reconciliation System from Sales Audit |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RSA06 |
Wrapper Script |
N/A |
Design Overview
The SAEXPUAR program is used to select the lottery, bank deposit, money order, and credit card totals and write them to output files for export to an external account clearing house application. For each store day, saexpuar posts specified totals to their appropriate output files.
Restart/Recovery
The logical unit of work for this module is defined as a unique store/day combination. Records will be fetched, updated, and inserted in batches of commit_max_ctr. Only two commits will be done. One to establish the store/day lock (this will be done by the package) and the other is done at the end, after a store/day has been completely processed.
I/O Specification
Integration Type |
Download from Sales Audit |
File Name |
UAR usage type appended with system date. |
Integration Contract |
IntCon000046 |
Output File Layout
The output file will contain one line for each store/day detail record in a comma-delimited format. The fields are surrounded by double quotes. For example, a record for store 1000 on May 20, 2001 with an amount of 19.99 will look something like this:
"1", "1000", "1999", "20010520","2","","1","","","","","","","","","MN","RET"
Table 6-35 Output File
Field Name | Field Type | Description |
---|---|---|
Detail Flag |
Char |
“1" for detail record. |
Store |
Number |
Store number. |
Amount |
Number |
Total Value * 100 (with 2 implied decimal places). |
TranDate |
Char |
Transaction Date in YYYYMMDD format. |
UAR TranCode |
Char |
Transaction Code. “1" for negative amount, “2" for positive amount. |
User Defined Value 1 |
Char |
Ref Number 1 on SA_TOTAL. |
User Defined Value 2 |
Char |
Total Seq Number on SA_TOTAL. |
User Defined Value 3 |
Char |
Ref Number 2 on SA_TOTAL. |
User Defined Value 4 |
Char |
Ref Number 3 on SA_TOTAL. |
User Defined Value 5 |
Char |
Not used. |
User Defined Value 6 |
Char |
Not used. |
User Defined Value 7 |
Char |
Not used. |
User Defined Value 8 |
Char |
Not used. |
User Defined Value 9 |
Char |
Not used. |
User Defined Value 10 |
Char |
Not used. |
State |
Char |
State. |
Account |
Char |
Total Identification on SA_TOTAL. |
Extract of POS Transactions by Store/Date from Sales Audit for Web Search (ang_saplgen)
Module Name |
ang_saplgen.pc |
Description |
Extract of POS Transactions by Store/Date from Sales Audit for Web Search |
Functional Area |
Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Integration Catalog ID |
RMS162 |
Wrapper Script |
N/A |
Design Overview
The purpose of this batch module is to fetch all corrected sale and return transactions that do not have Merchandising errors from the Sales Audit database tables for transmission to an external web search engine. If the transaction has a status of Deleted or Post Voided and has previously been transmitted, a reversal of the transaction will be sent. A file of type POSLOG is generated for each store/day.
Restart/Recovery
The logical unit of work for this module is defined as a unique store/day combination. Records will be fetched, in batches of pl_commit_max_ctr. The POSLOG formatted output file will be created with a completion of store/day looping.
I/O Specification
Integration Type |
Download from Sales Audit |
File Name |
POSLOG_<store>_<business date>_<system date>.xml |
Integration Contract |
IntCon000018 |
Output File Layout
Table 6-36 Output File Layout
Field Name | Field Type | Description |
---|---|---|
BatchID |
CHAR(18) |
A concatenation of store number and business date for a store. |
RetailStoreID |
CHAR(10) |
The store number for which the POSLog file has to be extracted. |
WorkStationID |
CHAR(5) |
RegistryID for the store. |
TillID |
CHAR(5) |
RegistryID for the store. |
SequenceNumber |
CHAR(10) |
Point of Sale system defined transaction number associated with a transaction. |
BeginDate |
CHAR(8) |
Starting date time of the transaction. |
EndDate |
CHAR(8) |
End date time of the transaction. |
CurrencyCode |
CHAR(3) |
Code of the currency used during the transaction. |
VoidFlag |
CHAR(5) |
Indicates if the item in the transaction is voided or not. Valid values are TRUE and FALSE. |
Item_Status |
CHAR(40) |
Status of the item is required for voided, exchanged, or returned item. |
MerchandisingHierarchy |
CHAR(4) |
Department number to which the item belongs |
Description |
CHAR(250) |
Item description that has been sold. |
Item |
CHAR(25) |
Item number. |
TaxIncludedInPrice |
CHAR(5) |
Indicates if the item is being taxed or not. Valid values are TRUE and FALSE. |
RegularSalesUnitPrice |
CHAR(20) |
Field holds the unit retail in the standard unit of retail for the item/location combination. |
ActualSalesUnitPrice |
CHAR(20) |
Retail price for the item. |
ExtendedAmount |
CHAR(20) |
Total sales for the item in the detail level. |
Qty |
CHAR(21) |
Unit sold of the item. |
Post User Defined Totals from Sales Audit to General Ledger (saexpgl)
Module Name |
saexpgl.pc |
Description |
Post User Defined Totals from Sales Audit to General Ledger |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Integration Catalog ID |
RSA09 |
Wrapper Script |
rmswrap.ksh |
Design Overview
The purpose of this module is to post all the properly configured user-defined Sales Audit totals to a general ledger application (Oracle or PeopleSoft). Totals without errors will be posted to the appropriate accounting ledger, as defined in the Sales Audit GL cross-reference module. Depending on the unit of work system parameter, the data will be sent at either the store/day or individual total level. Newly revised totals, that have already been posted to the ledger, will have their previous revision reversed, and the new total posted to the appropriate accounts.
When this module encounters a total that is not mapped to the General Ledger (GL), it will write the same into the IF_ERRORS table and raise a notification that unmapped total/store combinations exist. The IF_ERRORS table is available through the Data Access Schema, which will enable you to query for the error and create the missing mappings. It will also look for records written into IF_ERRORS on previous runs and attempt to reprocess the posting if GL mappings have been created.
'Late posted totals' that are received within a duration specified in the Close Month After Days system option after the end of the fiscal period will be processed by the module and posted to the intended month. All late posted totals received after this specified number of days has elapsed will be recorded against the first day of the subsequent month.
Restart/Recovery
The logical unit of work for this module is defined as a unique store/day combination. Records will be fetched, updated, and inserted in batches the size of commit max counter. Only one commit will be performed after a store/day has been completely processed. A call to the release lock functions performs a commit.
Inbound Scheduled Integration
This section provides a summary of integrations that are scheduled either to be run once per day or periodically throughout the day to retrieve data from another solution to Merchandising or Sales Audit. It includes both file-based and BDI-based integrations.
Item, Cost, and Price
Merchandising subscribes to data related to items, costs, and competitive prices from external sources, such as suppliers, PIM solutions, and so on.
The following scheduled inbound integrations are included in this functional area:
Upload Competitor's Prices (cmpupld)
Module Name |
cmpupld.pc |
Description |
Upload Competitor's Prices |
Functional Area |
Competitive Pricing |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS61 |
Wrapper Script |
rmswrap_in_rej.ksh |
Design Overview
This program is used to upload and process competitor item prices from an external source. The flat file being uploaded can contain pricing data for a completed shopping list or data for a new list of items to be shopped. The module processes data for both features.
Restart/Recovery
This is a file based upload, and file based restart/recovery logic is applied. The commit_max_ctr field should be set to prevent excessive rollback space usage and to reduce the overhead of file I/O. The recommended commit counter setting is 10000 records (subject to change based on experimentation).
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000007 |
Input File Layout
Table 6-37 Input File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Type Record Descriptor |
CHAR (5) |
FHEAD |
Value that identifies the record type. |
File Line Identifier |
NUMBER (10) |
0000000001 |
Sequential file line number. |
|
File Type Definition |
CHAR(4) |
CMPU |
Value that identifies the file as that for this program. |
|
File Create Date |
CHAR (14) |
N/A |
Date when the file was written by the external system. It should be in the YYYYMMDDHH24MISS format. |
|
File Detail |
File Type Record Descriptor |
CHAR (5) |
FDETL |
Value that identifies the record type. |
File Line Identifier |
NUMBER (10) |
Sequential file line number. |
||
Shopper ID |
NUMBER (4) |
Numeric value that uniquely identifies the shopper to which the competitive shopping list is assigned. |
||
Shop Date |
CHAR (14) |
Date when the competitive shop was performed. It should be in the YYYYMMDDHH24MISS format. |
||
Item |
CHAR (25) |
Alphanumeric value that uniquely identifies the transaction level or below transaction level item that was competitively shopped. |
||
Competitor ID |
NUMBER(10) |
Numeric value that uniquely identifies a competitor. |
||
Competitor Store ID |
NUMBER(10) |
Numeric value that uniquely identifies a competitor's store. |
||
Recorded Date |
CHAR (14) |
Date when the item's retail price was recorded at the competitor's store. It should be in the YYYYMMDD24MISS format. |
||
Competitive Retail Price |
NUMBER(20,4) |
Numeric value that represents the retail price at the competitor's store. Format for this value should include four implied decimal places. |
||
Competitive Retail Type |
CHAR(6) |
R, P, C |
Value that represents the retail type ('R' is for regular; 'P', promotional; and 'C', clearance) that was recorded. |
|
Promotion Start Date |
CHAR (14) |
Effective start date of the competitor's price. It should be in the YYYYMMDDHH24MISS format. |
||
Promotion End Date |
CHAR (14) |
Effective end date of the competitor's price. It should be in the YYYYMMDDHH24MISS format. |
||
Offer Type Code |
CHAR(6) |
Alphanumeric value that corresponds to a valid offer type (such as,. Coupon, Bonus Card, Pre-priced). Valid values are defined on CODE_DETAIL table with CODE_TYPE 'OFTP'. |
||
Multi-Units |
NUMBER(12,4) |
Numeric value that represents the number of units that must be purchased to qualify for a multi-unit price. An example of a multi-unit price would be 2 for $3.00. There are four implied decimal places. |
||
Multi-Units Retail |
NUMBER(20,4) |
Numeric value that represents the price for a multi-unit item that was competitively shopped. There should be four implied decimal places. |
||
File Trailer |
File Type Record Descriptor |
CHAR(5) |
FTAIL |
Value that identifies the record type. |
File Line Identifier |
NUMBER (10) |
N/A |
Sequential file line number. |
|
File Record Counter |
NUMBER (10) |
N/A |
Numeric value that represents the number of FDETL records in the file. |
Upload Items and Cost Changes (iindbatch.ksh)
Module Name |
iindbatch.ksh |
Description |
Upload items and cost changes from an external system |
Functional Area |
Item and Cost Maintenance |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS474 |
Wrapper Script |
rmswrap_shell_in.ksh |
Design Overview
This batch program is used to bulk upload XML data files from template files to the Merchandising templates table. It supports two types of templates - those for items and those for cost changes. The templates used in this upload are the same as those used for spreadsheet upload of items and cost changes.
See also Oracle Retail Merchandising Induction CSV to XML File Transformer Usage on My Oracle Support (Doc ID 2730273.1), for more details on formatting XML files for this upload.
This batch will be responsible for validating the input parameters, below are the list of validations.
-
The Input file should exist.
-
The Input file's extension must be ".xml".
-
The template name should be valid.
-
Destination (Optional Parameter) determines whether data will be loaded into the main Merchandising tables (RMS) or staging tables for further enrichment (STG). If a destination is not included, then it will be defaulted to STG.
Once XML data is loaded into the staging table, the script will do the following:
-
Initializes a row in the process tracker table for asynchronous processing.
-
Call the main induction process that uploads data into the staging tables, validates and inserts data into the base Merchandising item or cost change tables.
Note:
The base templates used by this batch are loaded through a script on provisioning (ITEM_MASTER_DATA and COST_CHANGE). Additional templates can be configured using the Data Loading Template Configuration in the Merchandising task list under Application Administration for type Item or Cost Change.
Ordering and Inventory
Merchandising subscribes to purchasing and inventory data via scheduled integration from external sources, such as stores, warehouses, order management solutions, and import partners.
This section has been broken into the following sub-sections:
Purchasing
Merchandising subscribes to data related to purchase orders from external sources, such as suppliers, planning solutions, and so on.
The following scheduled inbound integrations are included in this functional area:
For more on purchase order processing, see Merchandising Operations Guide - Volume 1.
Upload of Deals from 3rd Party Systems (dealupld)
Module Name |
dealupld.pc |
Description |
Upload of Deals from 3rd Party Systems |
Functional Area |
Deals |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS42 |
Wrapper Script |
rmswrap_multi_in_rej.ksh |
Design Overview
This process uploads deals from external systems into Merchandising. Generally, deals are uploaded from merchandise suppliers and other trading partners. This program uses a proprietary file format (not any EDI standard).
The deals that are uploaded through the batch are created in the worksheet (W) status by default, but can be created in submitted (S) or approved (A) statuses, based on the Deal Upload Status configuration for the supplier. If any validation error occurs during the deal submission or approval, the deal will be created in the worksheet status and a user needs to manually rectify the error through the Deal UI in order to approve it. Please note that this functionality is limited to Supplier based deals. Deals created for other Partners can only be created in the worksheet status.
Assumptions
-
This upload supports two format versions. The fields noted below can be omitted from the file format if not creating deals with a billing type of Clearance Consignment Rate (CCR) or Promotional Consignment Rate (PCR).
-
Consignment Rate in the TDETL record for Transaction Detail Record Type DCDTL.
-
The CPDTL section of the file, including THEAD, TDETL, and TTAIL.
However, if either of these types of deals are being created, the DCDTL TDETL Consignment Rate must be included in the upload; CPDTL section is required for PCR types only.
-
Restart/Recovery
The program uses File based restart recovery process. The logical unit of work is a single deal head detail record and its associated component records in the input file.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000008 |
Input File Layout
Table 6-38 dealupld.pc - Input File Layout
Record Name | Field Name | Field Type | Default Value | Description/Constraints |
---|---|---|---|---|
FHEAD |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type (the beginning of the input file). |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
File Type Definition |
Char(5) |
EDIDU |
Identifies file as ‘EDI Deals Upload' |
|
File Create Date |
Char(14) |
Create date |
Current date, formatted to ‘YYYYMMDDHH24MISS'. |
|
THEAD |
File Type Record Descriptor |
Char(5) |
THEAD |
Identifies file record type to upload a new deal header. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Detail Record Type |
Char(5) |
DHDTL |
Identifies file record type Deal Header. This record MUST BE FOLLOWED BY ONE AND ONLY ONE REQUIRED TDETL RECORD that holds the deal head information. |
|
TDETL |
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies file record type to upload a new deal. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Partner Type |
Char(6) |
REQUIRED |
Type of the partner the deal applies to. Valid values are ‘S' for a supplier, 'S1' for supplier hierarchy level 1 (for example, the manufacturer), 'S2' for supplier hierarchy level 2 (for example, the distributor) and 'S3' for supplier hierarchy level 3 (that is, the wholesaler). Descriptions of these codes will be held on the codes table under a code_type of 'SUHL'. Information pertaining to a single deal has to belong to the same supplier, since a deal may have only one supplier hierarchy associated with it. Only items with the same supplier hierarchy can be on the same deal. Supplier hierarchy is stored at an item / supplier / country / location level. |
|
Partner Id |
Char(10) |
Blank (space character string) |
Level of supplier hierarchy (for example, manufacturer, distributor or wholesaler), set up as a partner in the PARTNER table, used for assigning rebates by a level other than supplier. Rebates at this level will include all eligible supplier/item/country records assigned to this supplier hierarchy level. This field is required if the Partner Type field was set to ‘S1', ‘S2' or ‘S3'. This field must be blank if the Partner Type field was set to ‘S'. |
|
Supplier |
Number (10) |
Blank (space character string) |
Deal supplier's number. This supplier can be at any level of supplier hierarchy. This field is required if the Partner Type field was set to ‘S'. This field must be blank if the Partner Type field was set to ‘S1', ‘S2' or ‘S3'. Deals for items with an ownership of Consignment can only be set up for the primary supplier for the given item/location combination. |
|
Type |
Char(6) |
REQUIRED |
Type of the deal. Valid values are A for annual deal, P for promotional deal, O for PO-specific deal or M for vendor-funded markdown. Deal types will be held on the codes table under a code type of 'DLHT'. |
|
Currency Code |
Char(3) |
Blank (space character string) |
Currency code of the deal's currency. All costs on the deal will be held in this currency. If Type is 'O', 'P' or 'A', then Currency Code may not be blank. Currency Code has to be blank if Type is 'M'. |
|
Active Date |
Char(14) |
REQUIRED |
Date the deal will become active. This date will determine when deal components begin to be factored into item costs. For a PO-specific deal, the active date will be the order's written date. |
|
Close Date |
Char(14) |
Blank (space character string) |
Date the deal will/did end. This date determines when deal components are no longer factored into item costs. It is optional for annual deals, required for promotional deals. It will be left NULL for PO-specific deals. Close Date must not be blank if Type is 'P' or ‘M'. Close Date has to be blank if Type is 'O'. |
|
External Reference Number |
Char(30) |
Blank (space character string) |
Any given external reference number that is associated with the deal. |
|
Order Number |
Number (12) |
Blank (space character string) |
Order the deal applies to, if the deal is PO-specific. |
|
Recalculate Approved Orders |
Char(1) |
REQUIRED |
Indicates if approved orders should be recalculated based on this deal once the deal is approved. Valid values are Y for yes or N for no. Valid values are ‘Y' and ‘N'. |
|
Comments |
Char (2000) |
Blank (space character string) |
Free-form comments entered with the deal. |
|
Billing Type |
Char(6) |
REQUIRED |
Billing type of the deal component. Valid values are 'OI' for off-invoice, 'BB' for bill-back, ‘VFP' for vendor funded promotion, ‘VFM' for vendor funded markdown, 'CCR' for clearance consignment rate and 'PCR' for promotional consignment rate. Billing types are held in the codes table under a code type of 'DLBT'. |
|
Bill Back Period |
Char(6) |
Blank (space character string) |
Code that identifies the bill-back period for the deal component. This field will only be populated for billing types of 'BB' or 'VFP' or ‘VFM'. Valid bill back period codes are ‘W', ‘M', ‘Q', ‘H', ‘A'. If Billing Type is 'BB', then Bill Back Period must not be blank; if Billing Type is ‘OI' (off invoice), 'CCR' (clearance consignment rate), 'PCR' (promotional consignment rate, then Bill back Period has to be blank. |
|
Deal Application Timing |
Char(6) |
Blank (space character string) |
Indicates when the deal component should be applied - at PO approval or time of receiving. Valid values are 'O' for PO approval, 'R' for receiving. These values will be held on the codes tables under a code type of 'AALC'. It must be NULL for an M-type deal (vendor funded markdown). |
|
Threshold Limit Type |
Char(6) |
Blank (space character string) |
Identifies whether thresholds will be set up as quantity values, currency amount values or percentages (growth rebates only). Valid values are 'Q' for quantity, 'A' for currency amount. Threshold limit types will be held on the codes table under a code type of 'DLLT'. It must be NULL for an M-type deal (vendor funded markdown) or if the threshold value type is ‘Q' (buy/get deals) or a 'CCR'/'PCR' deal. If Growth Rebate Indicator is 'Y', then the Threshold Limit Type has to be 'Q', 'A' or NULL. |
|
Threshold Limit Unit of Measure |
Char(4) |
Blank (space character string) |
Unit of measure of the threshold limits, if the limit type is quantity. Only Unit of Measures with a UOM class of 'VOL' (volume), 'MASS' or 'QTY' (quantity) can be used in this field. Valid Unit of Measures can be found on the UOM_CLASS table. If the Threshold Limit Type is 'A', then Threshold Limit Unit of Measure has to be blank. If the Threshold Limit Type is 'Q', Threshold Limit Unit of Measure must not be blank. If Threshold Limit Type is blank, Threshold Limit Unit of Measure must be blank. |
|
Rebate Indicator |
Char(1) |
REQUIRED |
Indicates if the deal component is a rebate. Deal components can only be rebates for bill-back billing types. Valid values are 'Y' for yes or 'N' for no. If Billing Type is 'OI', 'CCR' or 'PCR', then Rebate Indicator must be 'N'. |
|
Rebate Calculation Type |
Char(6) |
Blank (space character string) |
Indicates if the rebate should be calculated using linear or scalar calculation methods. Valid values are 'L' for linear or 'S' for scalar. This field will be required if the rebate indicator is 'Y'. Rebate calculation types will be held on the codes table under a code type of 'DLCT'. If Rebate Indicator is 'Y', then Rebate Calculation Type must not be blank. Otherwise it has to be blank. |
|
Growth Rebate Indicator |
Char(1) |
REQUIRED |
Indicates if the rebate is a growth rebate, meaning it is calculated and applied based on an increase in purchases or sales over a specified period of time. Valid values are 'Y' for yes or 'N' for no.If Rebate Indicator is 'N', then Growth Rebate Indicator must be ‘N'. |
|
Historical Comparison Start Date |
Char(14) |
Blank (space character string) |
The first date of the historical period against which growth will be measured in this growth rebate. Note performance and the rebate amount are not calculated - this field is for informational/reporting purposes only. If Growth Rebate Indicator is 'Y', then Historical Comparison Start Date must not be blank. Otherwise it must be blank. |
|
Historical Comparison End Date |
Char(14) |
Blank (space character string) |
The last date of the historical period against which growth will be measured in this growth rebate. Note performance and the rebate amount are not calculated - this field is for informational/reporting purposes only. If Growth Rebate Indicator is 'Y', then Historical Comparison End Date must not be blank. Otherwise it must be blank. |
|
Rebate Purchases or Sales Application Indicator |
Char(6) |
Blank (space character string) |
Indicates if the rebate should be applied to purchases or sales. Valid values are 'P' for purchases or 'S' for sales. It will be required if the rebate indicator is 'Y'. Rebate purchase/sales indicators will be held on the codes table under a code type of 'DLRP'. If the Rebate Indicator is 'Y', then the Rebate Purchases or Sales Application Indicator must not be blank. Otherwise it has to be blank. |
|
Security Indicator |
Char |
Y |
Security Indicator |
|
TTAIL |
File Line Identifier |
Char(5) |
TTAIL |
Identifies file record type (the end of the transaction detail). |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Record Counter |
Numeric ID(6) |
Sequential number Created by program. |
Number of records/transactions in current transaction set (only records between thead and ttail). For DHDTL TDETL records this will always be 1! |
|
THEAD |
File Type Record Descriptor |
Char(5) |
THEAD |
Identifies file record type to upload a new deal sub loop. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Detail Record Type |
Char(5) |
DCDTL |
Identifies file record type of sub loop as Deal Component Detail. |
|
TDETL |
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies file record type to upload deal components. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Deal Component Type |
Char(6) |
REQUIRED |
Type of the deal component, user-defined and stored on the DEAL_COMP_TYPE table. |
|
Application Order |
Number (10) |
Blank (space character string) |
Number indicating the order in which the deal component should be applied with respect to any other deal components applicable to the item within the deal. This number will be unique across all deal components within the deal. It must be NULL for an M-type deal (vendor funded markdown). |
|
Collect Start Date |
Char(14) |
Blank (space character string) |
Date that collection of the bill-back should begin. If Billing Type is 'BB' then Collect Start Date must not be blank, otherwise it has to be blank. |
|
Collect End Date |
Char(14) |
Blank (space character string) |
Date that collection of the bill-back should end. If Billing Type is 'BB' then Collect End Date must not be blank, otherwise it has to be blank. |
|
Cost Application Level Indicator |
Char(6) |
Blank (space character string) |
Indicates what cost bucket the deal component should affect. Valid values are 'N' for net cost, 'NN' for net cost and 'DNN' for dead net cost. These values will be held on the codes tables under a code type of 'DLCA'. It must be NULL for an M-type deal (vendor funded markdown), 'CCR' or 'PCR' deals |
|
Pricing Cost Indicator |
Char(1) |
REQUIRED |
Identifies deal components that should be included when calculating a pricing cost. Valid values are 'Y'es and 'N'o. |
|
Deal Class |
Char(6) |
Blank (space character string) |
Identifies the calculation class of the deal component. Valid values are 'CU' for cumulative (discounts are added together and taken off as one lump sum), 'CS' for cascade (discounts are taken one at a time with subsequent discounts taken off the result of the previous discount) and 'EX' for exclusive (overrides all other discounts). 'EX' type deal components are only valid for promotional deals. Deal classes will be held on the codes table under a code type of 'DLCL'. It must be NULL for an M-type deal (vendor funded markdown), 'CCR' and 'PCR' deals. |
|
Threshold Value Type |
Char(6) |
Blank (space character string) |
Identifies whether the discount values associated with the thresholds will be set up as qty values, currency amount values, percentages or fixed amounts. Valid values are 'Q' for qty, 'A' for currency amount, 'P' for percentage or 'F' for fixed amount. Qty threshold value (buy/get) deals are only allowed on off-invoice discounts. Deal threshold value types will be held on the codes table under a code type of 'DLL2'. It must be NULL for an M-type deal (vendor funded markdown), 'CCR' and 'PCR' deals. If Billing Type is 'BB', then the Threshold Value Type must be'A' or ‘P'. |
|
Buy Item |
Char(25) |
Blank (space character string) |
Identifies the item that must be purchased for a quantity threshold-type discount. This value is required for quantity threshold value type discounts. Otherwise it has to be blank. |
|
Get Type |
Char(6) |
Blank (space character string) |
Identifies the type of the 'get' discount for a quantity threshold-type (buy/get) discount. Valid values include 'X' (free), 'P' (percent), 'A' (amount) and 'F' (fixed amount). They are held on the codes table under a code type of 'DQGT'. This value is required for quantity threshold value deals. Otherwise it has to be blank. |
|
Get Value |
Number(20,4) |
All 0s. |
Identifies the value of the 'get' discount for a quantity threshold-type (buy/get) discount that is not a 'free goods' deal. The Get Type above identifies the type of this value. This value is required for quantity threshold value type deals that are not a Get Type of free. Otherwise it has to be 0. If Get Type is ‘P', ‘A' or ‘F', then Get Value must not be blank. If the Get Type is ‘X' or blank, then Get Value has to be blank. |
|
Buy Item Quantity |
Number(12,4) |
All 0s. |
Identifies the quantity of the threshold 'buy' item that must be ordered to qualify for the 'free' item. This value is required for quantity threshold value type discounts. Otherwise it has to be 0. |
|
Recursive Indicator |
Char(1) |
REQUIRED |
For 'buy/get free' discounts, indicates if the quantity threshold discount is only for the first 'buy amt.' purchased (such as, for the first 10 purchased, get 1 free), or if a free item will be given for every multiple of the 'buy amt' purchased on the order (such as, for each 10 purchased, get 1 free). Valid values are 'Y' for yes or 'N' for no. If the Get Type is blank, then Recursive Indicator has to be ‘N'. |
|
Buy Item Order Target Quantity |
Number(12,4) |
All 0s. |
Indicates the targeted purchase level for all locations on a purchase order. This is the target level that will be used for future calculation of net cost. This value is required for quantity threshold value type deals. Otherwise it has to be 0. |
|
Average Buy Item Order Target Quantity Per Location |
Number(12,4) |
All 0s. |
Indicates the average targeted purchase level per location on the deal. This value will be used in future cost calculations. This value is required for quantity threshold value type deals. Otherwise it has to be 0. |
|
Get Item |
Char(25) |
Blank (space character string) |
Identifies the 'get' item for a quantity threshold-type (buy/get) discount. This value is required for quantity threshold value deals. Otherwise it has to be blank. If Get Type is ‘P', ‘A', ‘F' or ‘X', then Get Item must not be blank. If the Get Type is blank, then Get Item has to be blank. |
|
Get Quantity |
Number(12,4) |
All 0s. |
Identifies the quantity of the identified 'get' item that will be given at the specified 'get' discount if the 'buy amt' of the buy item is purchased. This value is required for quantity threshold value type discounts. Otherwise it has to be 0. If Get Type is ‘P', ‘A', ‘F' or ‘X', then Get Quantity must not be 0. If the Get Type is blank, then Get Quantity has to be 0. |
|
Free Item Unit Cost |
Number(20,4) |
All 0s. |
For 'buy/get free' discounts, identifies the unit cost of the threshold 'free' item that will be used in calculating the prorated qty. discount. It will default to the item/supplier cost, but can be modified based on the agreement with the supplier. It must be greater than zero as this is the cost that would normally be charged for the goods if no deal applied. If Get Type is ‘P', ‘A', ‘F' or blank, then Free Item Unit Cost must be 0. If the Get Type is ‘X', then Free Item Unit Cost must not be 0. |
|
Transaction Level Discount Indicator |
Char(1) |
REQUIRED |
Indicates if the discount is a transaction-level discount (for example, 10% across an entire PO). Valid Values are 'Y' or 'N'. If set to 'Y', Deal Class has to be 'CU' and Billing Type has to be 'OI'. For 'CCR', and 'PCR'deals, the valid value is 'N'. No DIDTL or PPDTL records may be present for a Transaction Level Discount DCDTL record. |
|
Comments |
Char(2000) |
Blank (space character string) |
Free-form comments entered with the deal component. |
|
Get Free Discount |
Number(12,4) |
All 0s. |
This specifies how much percentage of the total discount should be apportioned from the get items unit cost for off invoice deals where buy item is not same as the get item and QTY_THRESH_GET_TYPE is X. The remaining will be apportioned from the buy item unit cost. |
|
Consignment Rate |
Number(12,4) |
All 0s. |
Rate used to capture the deal consignment rate applicable for the set of item/location combinations that are included in the deal during the deal timeframe, instead of the regular consignment rate. |
|
TTAIL |
File Line Identifier |
Char(5) |
TTAIL |
Identifies file record type (the end of the transaction detail). |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Record Counter |
Numeric ID(6) |
Sequential number Created by program. |
Number of records/transactions in current transaction set (only records between thead and ttail). |
|
THEAD |
File Type Record Descriptor |
Char(5) |
THEAD |
Identifies file record type to upload a new deal sub loop. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Detail Record Type |
Char(5) |
CPDTL |
Identifies file record type of sub loop as Deal Component Prom. |
|
TDETL |
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies file record type to upload deal proof of performance details. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Prom ID |
Number (10) |
All 0s. |
Promotion identification number. |
|
Promo Comp Id |
Number (10) |
All 0s. |
Promotion offer identification number. |
|
Consignment Rate |
Number(12,4) |
All 0s. |
Rate used to capture the deal consignment rate applicable for the set of item/location combinations that are included in the deal during the deal timeframe, instead of the regular consignment rate. |
|
Reference Line |
Number (10) |
REQUIRED |
This value determines which line in the input file this deal component-promotional record belongs to. |
|
TTAIL |
File Line Identifier |
Char(5) |
TTAIL |
Identifies file record type (the end of the transaction detail). |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Record Counter |
Numeric ID(6) |
Sequential number Created by program. |
Number of records/transactions in current transaction set (only records between thead and ttail). |
|
THEAD |
File Type Record Descriptor |
Char(5) |
THEAD |
Identifies file record type to upload a new deal sub loop. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Detail Record Type |
Char(5) |
DIDTL |
Identifies file record type of sub loop as Deal Component Item-location Detail. |
|
TDETL |
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies file record type to upload deal item-location details. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Merchandise Level |
Char(6) |
REQUIRED |
Indicates what level of the merchandise hierarchy the record is at. Valid values include '1' for company-wide (all items), '2' for division, '3' for group, '4' for dept, '5' for class, '6' for subclass, '7' for line, '8' for line/differentiator 1, '9' for line/differentiator 2' '10' for line/differentiator 3, ‘11' for line/differentiator 4 and ‘12' for. These level types will be held on the codes table under a code type of 'DIML'. |
|
Company Indicator |
Char(1) |
REQUIRED |
Indicates if the deal component is applied company-wide (that is, whether all items in the system will be included in the discount or rebate). Valid values are 'Y' for yes and 'N' for no. |
|
Division |
Number (4) |
Blank (space character string) |
ID of the division included in or excluded from the deal component. Valid values are on the DIVISION table. If Group is not blank, then Division must not be blank. If Merchandise Level is 2, then Division must not be blank and Group, Department, Class and Subclass must be blank. |
|
Group |
Number (4) |
Blank (space character string). |
ID of the group included in or excluded from the deal component. Valid values are on the GROUPS table. If Department is not blank, then Group must not be blank. If Merchandise Level is 3, then Group must not be blank and Department, Class and Subclass must be blank. |
|
Department |
Number (4) |
Blank (space character string). |
ID of the department included in or excluded from the deal component. Valid values are on the DEPS table. If Class is not blank, then Department must not be blank. If Merchandise Level is 4, then Department must not be blank and Class and Subclass must be blank. |
|
Class |
Number (4) |
Blank (space character string). |
ID of the class included in or excluded from the deal component. Valid values are on the CLASS table. If Subclass is not blank, then Class must not be blank. If Merchandise Level is 5, then Class must not be blank and Subclass must be blank. |
|
Subclass |
Number (4) |
Blank (space character string). |
ID of the subclass included in or excluded from the deal component. Valid values are on the SUBCLASS table. If Merchandise Level is 6 or more than 6, then Subclass must not be blank. |
|
Item Parent |
Char(25) |
Blank (space character string) |
Alphanumeric value that uniquely identifies the item/group at the level above the item. This value must exist as an item in another row on the ITEM_MASTER table. If Merchandise Level is 7, then Item Parent or Item Grandparent must not be blank (at least one of them has to be given). |
|
Item Grandparent |
Char(25) |
Blank (space character string) |
Alphanumeric value that uniquely identifies the item/group two levels above the item. This value must exist as both an item and an item parent in another row on the ITEM_MASTER table. If Merchandise Level is 7, then Item Parent or Item Grandparent must not be blank (at least one of them has to be given). |
|
Differentiator 1 |
Char(10) |
Blank (space character string) |
Diff_group or diff_id that differentiates the current item from its item_parent. If Item Grandparent, Item Parent and Differentiator 2 are blank, then Differentiator 1 must be blank. If Merchandise Level is 8, then Differentiator 1 must not be blank. |
|
Differentiator 2 |
Char(10) |
Blank (space character string) |
Diff_group or diff_id that differentiates the current item from its item_parent. If Item Grandparent, Item Parent and Differentiator 1 are blank, then Differentiator 2 must be blank. If Merchandise Level is 9, then Differentiator 2 must not be blank. |
|
Differentiator 3 |
Char(10) |
Blank (space character string) |
Diff_group or diff_id that differentiates the current item from its item_parent. If Item Grandparent, Item Parent and Differentiator 1 and 2 are blank, then Differentiator 3 must be blank. If Merchandise Level is 10, then Differentiator 3 must not be blank. |
|
Differentiator 4 |
Char(10) |
Blank (space character string) |
Diff_group or diff_id that differentiates the current item from its item_parent. If Item Grandparent, Item Parent and Differentiator 1, 2 and 3 are blank, then Differentiator 4 must be blank. If Merchandise Level is 10, then Differentiator 4 must not be blank. |
|
Organizational Level |
Char(6) |
Blank (space character string) |
Indicates what level of the organizational hierarchy the record is at. Valid values include '1' for chain, '2' for area, '3' for region, '4' for district and '5' for location. These level types will be held on the codes table under a code type of 'DIOL'. If company indicator is N, this must not be blank. If location type is warehouse or location list, this must be 5. |
|
Chain |
Number (10) |
Blank (space character string). |
ID of the chain included in or excluded from the deal component. Valid values are on the CHAIN table. If org. level is 1, this field must not be blank. |
|
Area |
Number (10) |
Blank (space character string). |
ID of the area included in or excluded from the deal component. Valid values are on the AREA table. If org. level is 2, this field and chain must not be blank. |
|
Region |
Number (10) |
Blank (space character string). |
ID of the region included in or excluded from the deal component. Valid values are on the REGION table. If org. level is 3, this field, area, and chain must not be blank. |
|
District |
Number (10) |
Blank (space character string). |
ID of the district included in or excluded from the deal component. Valid values are on the DISTRICT table. If org. level is 4, then this field, region, area, and chain must not be blank. |
|
Location |
Number (10) |
Blank (space character string). |
ID of the location included in or excluded from the deal component. Valid values are on the STORE, WH, or LOC_LIST_HEAD table. If org. level is 5, this field must not be blank. Chain, area, region, and district should be blank if the loc_type is L or W. If the loc_type is S, then they all must not be blank. If Location Type is not blank, then Location must not be blank. Otherwise it has to be blank. |
|
Origin Country Identifier |
Char(3) |
Blank (space character string) |
Origin country of the item that the deal component should apply to. |
|
Location Type |
Char(1) |
Blank (space character string) |
Type of the location referenced in the location field. Valid values are 'S' and 'W'. Location types will be held on the codes table under the code type 'LOC3'. If location is blank then this field has to be blank also. |
|
Item |
Char(25) |
Blank (space character string) |
Unique alphanumeric value that identifies the item. If Merchandise Level is 10, then Item must not be blank. |
|
Exclusion Indicator |
Char(1) |
REQUIRED |
Indicates if the deal component item/location line is included in the deal component or excluded from it. Valid values are 'Y' for yes or 'N' for no. |
|
Reference Line |
Number (10) |
REQUIRED |
This value determines which line in the input file this item-loc record belongs to. |
|
TTAIL |
File Line Identifier |
Char(5) |
TTAIL |
Identifies file record type (the end of the transaction detail). |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Record Counter |
Numeric ID(6) |
Sequential number Created by program. |
Number of records/transactions in current transaction set (only records between thead and ttail). |
|
THEAD |
File Type Record Descriptor |
Char(5) |
THEAD |
Identifies file record type to upload a new deal sub loop. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Detail Record Type |
Char(5) |
PPDTL |
Identifies file record type of sub loop as Proof of Performance Detail. |
|
TDETL |
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies file record type to upload deal proof of performance details. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Deal Sub Item |
Char(25) |
No data |
Specific transaction level (or below) item that's proof of performance is being measured. This can be populated when the deal itself is on a case UPC but the proof of performance is on an individual selling unit. |
|
Proof of Performance Type |
Char(6) |
REQUIRED |
Code that identifies the proof of performance type (that is, the term is that the item must be displayed on an end cap for 28 days - the pop_type is code 'ECD' for end cap display). Valid values for this field are stored in the code_type = 'PPT'. This field is required by the database. |
|
Proof of Performance Value |
Number (20,4) |
All 0s. |
Value that describes the term of the proof of performance type (that is, the term is that the item must be displayed on an end cap for 28 days - the pop_value is 28). This field is required by the database if the record has a pop_value_type. If Proof of Performance Value is not blank, then Proof of Performance Value Type must not be blank. If Proof of Performance Value is blank, then Proof of Performance Value Type must be blank. |
|
Proof of Performance Value Type |
Char(6) |
Blank (space character string) |
Value that describes the type of the pop_value (that is, the term is that the item must be displayed on an end cap for 28 days - the pop_value_type is the code 'DAYS' for days). Valid values for this field are stored in the code_type = 'PPVT'. This field is required by the database if the record has a pop_value. If Proof of Performance Value is not blank, then Proof of Performance Value Type must not be blank. If Proof of Performance Value is blank, then Proof of Performance Value Type must be blank. |
|
Vendor Recommended Start Date |
Char(14) |
Blank (space character string) |
This column holds the date that the vendor recommends that the POP begin. |
|
Vendor Recommended End Date |
Char(14) |
Blank (space character string) |
This column holds the date that the vendor recommends that the POP end. |
|
Planned Start Date |
Char(14) |
Blank (space character string) |
This column holds the date that the merchandiser/category manager plans to begin the POP. |
|
Planned End Date |
Char(14) |
Blank (space character string) |
This column holds the date that the merchandiser/category manager plans to end the POP. |
|
Comment |
Char(255) |
Blank (space character string) |
Free-form comments. |
|
Reference Line |
Number (10) |
REQUIRED |
This value determines which line in the input file this Proof of Performance record belongs to. |
|
TTAIL |
File Line Identifier |
Char(5) |
TTAIL |
Identifies file record type (the end of the transaction detail). |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Record Counter |
Numeric ID(6) |
Sequential number Created by program. |
Number of records/transactions in current transaction set (only records between thead and ttail). |
|
THEAD |
File Type Record Descriptor |
Char(5) |
THEAD |
Identifies file record type to upload a new deal sub loop. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Detail Record Type |
Char(5) |
DTDTL |
Identifies file record type of sub loop as Deal Component Threshold Detail. |
|
TDETL |
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies file record type to upload deal threshold details. |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Lower Limit |
Number (20,4) |
REQUIRED |
Lower limit of the deal component. This is the minimum value that must be met in order to get the specified discount. This value will be either a currency amount or quantity value, depending on the value in the deal_detail.threshold_limit_type field of this deal component (Threshold Value Type field of the DCDTL record that this DTDTL record belongs to as specified in the reference line field). |
|
Upper Limit |
Number (20,4) |
REQUIRED |
Upper limit of the deal component. This is the maximum value for which the specified discount will apply. This value will be either a currency amount or quantity value, depending on the value in the deal_detail.threshold_limit_type field of this deal component (Threshold Value Type field of the DCDTL record that this DTDTL record belongs to as specified in the reference line field). |
|
Value |
Number (20,4) |
REQUIRED |
Value of the discount that will be given for meeting the specified thresholds for this deal component. This value will be either a currency amount or quantity value, depending on the value in the deal_detail.threshold_value_type field of this deal component (Threshold Value Type field of the DCDTL record that this DTDTL record belongs to as specified in the reference line field). |
|
Target Level Indicator |
Char(1) |
REQUIRED |
Indicates if a threshold level is the targeted purchase or sales level for a deal component. This indicator will be used for cost calculations. Valid values are 'Y' for yes and 'N' for no. |
|
Reference Line |
Number (10) |
REQUIRED |
This value determines which line in the input file this Threshold record belongs to. |
|
TTAIL |
File Line Identifier |
Char(5) |
TTAIL |
Identifies file record type (the end of the transaction detail). |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
Transaction Record Counter |
Numeric ID(6) |
Sequential number Created by program. |
Number of records/transactions in current transaction set (only records between thead and ttail). |
|
FTAIL |
File Line Identifier |
Char(5) |
FTAIL |
Identifies file record type (the end of the input file). |
File Line Identifier |
Numeric ID(10) |
Sequential number Created by program. |
ID of current line being read from input file. |
|
File Record Counter |
Numeric ID(10) |
Sequential number Created by program. |
Number of records/transactions in current file (only records between head and tail). |
The input file structure should be as below:
FHEAD { THEAD of DHDTL REQUIRED for deal head record TDETL REQUIRED 1 deal head record TTAIL REQUIRED end of deal head record THEAD of DCDTL REQUIRED for deal component records [ TDETL OPTIONAL for deal component records ] TTAIL REQUIRED end of deal component records THEAD of CPDTL OPTIONAL for deal component promotion records [ TDETL OPTIONAL for deal component promotion records ] TTAIL OPTIONAL end of deal component promotion records THEAD of DIDTL REQUIRED for item-loc records [ TDETL OPTIONAL for item-loc records ] TTAIL REQUIRED end of item-loc records THEAD of PPDTL REQUIRED for proof of performance records [ TDETL OPTIONAL for proof of performance records ] TTAIL REQUIRED end of proof of performance records THEAD of DTDTL REQUIRED for threshold records [ TDETL OPTIONAL for threshold records ] TTAIL REQUIRED end of threshold records } FTAIL THEAD of DIDTL REQUIRED for item-loc records [ TDETL OPTIONAL for item-loc records ] TTAIL REQUIRED end of item-loc records THEAD of PPDTL REQUIRED for proof of performance records [ TDETL OPTIONAL for proof of performance records ] TTAIL REQUIRED end of proof of performance records THEAD of DTDTL REQUIRED for threshold records [ TDETL OPTIONAL for threshold records ] TTAIL REQUIRED end of threshold records } FTAIL
Upload Order Data (poindbatch.ksh)
Module Name |
poindbatch.ksh |
Description |
Upload Order Data |
Functional Area |
Purchase Order Maintenance |
Module Type |
Integration |
Module Technology |
Ksh |
Catalog ID |
RMS234 |
Wrapper Script |
rmswrap_shell_in.ksh |
Design Overview
This batch program is used to Bulk upload xml file data from template files to S9T_FOLDER table (into content_xml column).
This batch will be responsible for validating the input parameters, below are the list of validations.
-
The Input file should exist.
-
The Input file's extension must be “.xml".
-
The template_name should be valid. Function S9T_PKG.CHECK_TEMPLATE is called for validation.
-
Destination (Optional Parameter) should be STG or Merchandising. If destination is not passed then default it to STG.
Once XML data is loaded into S9T_FOLDER table, the script will do post processing by calling the packages listed below:
-
PO_INDUCT_SQL.INIT_PROCESS - This initialize a row in svc_process_tracker for asynchronous processing.
-
PO_INDUCT_SQL.EXEC_ASYNC - This function calls the main induction process that uploads data into the staging tables, validates and inserts data into the base Merchandising purchase order tables.
Note:
The base templates used by this batch are loaded through a script on provisioning (PURCHASE_ORDER_DATA). Additional templates can be configured using the Data Loading Template Configuration in the Merchandising task list under Application Administration for type Purchase Orders.
Upload OTB Budget from Planning Systems (otbupld)
Module Name |
otbupld.pc |
Description |
Upload OTB Budget from Planning Systems |
Functional Area |
Open To Buy |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS132 |
Wrapper Script |
rmswrap_multi_in_rej.ksh |
Design Overview
The purpose of this batch module is to accept new and updated open to buy (OTB) budget data from an external planning system. Merchandising supports three types of OTB budgets – those associated with Non-Basic (N/B), Buyer Replenished Basic (BRB) and Auto-Replenished Basic (ARB) orders, as defined by the Order type on Merchandising purchase orders. OTB budgets are created by subclass/end of week date in Merchandising.
Restart/Recovery
Processing of each row is independent and thus if an erroneous record is found during processing; only that record needs to be corrected and reprocessed.
If a record fails validation, it will be written to a rejected record file. This file will facilitate easy reprocessing once the error is fixed by writing the record exactly as it was in the source file.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000033 |
Input File Layout
Table 6-39 otbupld - Input File
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
File head descriptor |
Char(5) |
FHEAD |
Describes file line type |
Line id |
Number(10) |
0000000001 |
Sequential file line number |
|
File Type Definition |
Char(4) |
‘OTBI' |
Identifies file as ‘OTB Import' |
|
File Create Date |
Char(14) |
N/A |
The date on which the file was written by external system. The Date is in YYYYMMDDHH24MISS format |
|
Subclass |
Number(4) |
The ID number of a subclass within the class given |
||
Eow Date |
Char(14) |
The end of week date for the budgeted week in YYYYMMDDHH24MISS format |
||
FDETL |
File record descriptor |
Char(5) |
FDETL |
Describes file line type |
Line ID |
Number(10) |
N/A |
Sequential file line number |
|
Transaction Set Control Number |
Number(14) |
N/A |
Sequence number used to force unique transaction check |
|
Order Type |
Char(1) |
N/A |
Order type budgeted for: specified as A for ARB, B for BRB, and N for N/B |
|
Department |
Number(4) |
N/A |
The ID number of a department |
|
Class |
Number(4) |
N/A |
The ID number of a class within the department given |
|
Subclass |
Number(4) |
N/A |
The ID number of a subclass within the class given |
|
Eow Date |
Char(14) |
N/A |
The end of week date for the budgeted week in YYYYMMDDHH24MISS forma |
|
Budget Amount |
Number(20) |
N/A |
Budgeted amount for the specified order type/week; value includes 4 implied decimal places |
|
FTAIL |
File record descriptor |
Char(5) |
N/A |
Marks end of file |
Line ID |
Number(10) |
Line number in file |
Sequential file line number |
|
Number of lines |
Number(10) |
Total detail lines |
Number of lines in file not counting FHEAD and FTAIL |
Upload Purchase Order and Purchase Order Change Acknowledgements from Suppliers to RMS (ediupack)
Module Name |
ediupack.pc |
Description |
Upload Purchase Order and Purchase Order Change Acknowledgements from Suppliers to Merchandising |
Functional Area |
Purchase Orders |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS48 |
Wrapper Script |
rmswrap_in_rej.ksh |
Design Overview
This program has four functions:
-
to acknowledge vendor receipt of a buyer-generated order without changes (acknowledge type AK)
-
to acknowledge vendor receipt of a buyer-generated order with date, cost or quantity modifications (acknowledge type AK)
-
to notify buyer of a new or updated vendor-generated order (acknowledge type AP)
-
to acknowledge order cancellations (acknowledge type CA)
All acknowledgements update the ORDHEAD table with acknowledgement information.
When the supplier sends the acknowledgement of a buyer order with modifications, they can send the entire purchase order or only the changes. The file details are matched to the current order. If the Not Before Date, Not After Date, Quantity, Price, and item all match the current order, then no changes were submitted. If one of the variables is blank, for example the price, assume that no pricing changes were made. As soon as one of the variables does not match, the order has been changed. These changes will not be written directly to the order; they will be written to the revision tables. Revisions will be accepted in the on-line ordering screens and changed orders will be resubmitted via EDIDLORD.
Vendor generated orders will create new orders by inserting new records on the EDI temporary order tables that are picked up by a subsequent process (VRPLBLD). For revisions to a vendor-generated order, updates will be made to the order automatically without requiring user acceptance. If the update is to add a new item/location to the order, this will generate a new purchase order using the same vendor reference number.
For Customer Order POs created through an external Order Management System (OMS) and Franchise Order POs, the modifications to the dates, quantity and cost are applied automatically (and will not need to be accepted online). Also, changes to Franchise POs through this program will not affect their associated Franchise orders.
Restart/Recovery
The files will not have enough volume to warrant the implementation of restart recovery for commit/rollback considerations but minimal file-based restart/recovery capability will be added. The logical unit of work is a complete transaction represented by detail lines between the transaction header and transaction tail.
A savepoint will be issued before each transaction header record is successfully processed. If a non-fatal error occurs, a rollback to the last savepoint will be issued so that the rejected records are not posted to the database. If a fatal error occurs and restart is necessary, processing will restart at the last commit point.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000014 |
Input File Layout
Table 6-40 ediupack - Input File
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
File head descriptor |
Char(5) |
FHEAD |
Describes file line type |
Line id |
Number(10) |
0000000001 |
Sequential file line number |
|
File Type Definition |
Char(4) |
ORAK |
Identifies file as ‘Order Acknowledgment Import' |
|
THEAD |
File record descriptor |
Char(5) |
THEAD |
Describes file line type |
Line id |
Number(10) |
Line number in file |
Sequential file line number |
|
Transaction number |
Number(10) |
N/A |
Sequential transaction number |
|
Acknowledge type |
Char(2) |
N/A |
AP-product replenishment (VMI orders and updates) AK- Acknowledge or change CA-cancel order (no detail) |
|
Order number |
Char(15) |
N/A |
May be external order number (vendor order number) OR Oracle Retail order number |
|
Written_date |
Char(8) |
N/A |
Written date in YYYYMMDD format |
|
Supplier number |
Number(10) |
N/A |
Supplier number |
|
Not before date |
Char(8) |
N/A |
Not_before_date YYYYMMDD |
|
Not after date |
Char(8) |
N/A |
Not_after_date YYYYMMDD |
|
Purchase type |
Char(6) |
N/A |
Specifies type of purchase – may be blank |
|
Pickup date |
Char(8) |
N/A |
Pickup_date YYYYMMDD – may be blank |
|
TITEM |
File record descriptor |
Char(5) |
TITEM |
Describes file line type |
Line id |
Number(10) |
Line number in file |
Sequential file line number |
|
Transaction number |
Number(10) |
N/A |
Sequential transaction number |
|
ITEM |
Char(25) |
N/A |
Item (either item or ref_item must be defined) |
|
Ref_item |
Char(25) |
N/A |
Reference item (either item or ref_item must be defined) |
|
Vendor catalog number |
Char(30) |
N/A |
VPN (Vendor Product Number) |
|
Unit cost value |
Number(20) |
N/A |
Unit_cost * 10000 (4 implied decimal places) |
|
Loc_type |
Char(2) |
N/A |
‘ST' for store, ‘WH' for warehouse |
|
Location |
Number(10) |
N/A |
If NULL, apply to all locations for this item |
|
Pickup location |
Char(250) |
N/A |
Location to pick up item – may be blank |
|
TSHIP |
File record descriptor |
Char(5) |
TSHIP |
Describes file line type |
Line id |
Number(10) |
Line number in file |
Sequential file line number |
|
Transaction number |
Number(10) |
N/A |
Sequential transaction number |
|
Store/wh indicator |
Char(2) |
N/A |
‘ST' for store, ‘WH' for warehouse |
|
Ship to location |
Number(10) |
N/A |
Store or warehouse number |
|
Quantity |
Number(12) |
N/A |
Quantity ordered * 10000 (4 implied decimal places) |
|
TTAIL |
File record descriptor |
Char(5) |
TTAIL |
Describes file line type |
Line id |
Number(10) |
Line number in file |
Sequential file line number |
|
Transaction number |
Number(10) |
N/A |
Sequential transaction number |
|
Lines in transaction |
Number(6) |
N/A |
Total number of lines in this transaction |
|
FTAIL |
File record descriptor |
Char(5) |
FTAIL |
Marks end of file |
Line id |
Number(10) |
Line number in file |
Sequential file line number |
|
Number of transactions |
Number(10) |
´NA |
Number of lines between FHEAD and FTAIL |
Upload Replenishment Data (replindbatch.ksh)
Module Name |
replindbatch.ksh |
Description |
Upload replenishment schedule |
Functional Area |
Inventory Movement |
Module Type |
Integration |
Module Technology |
Ksh |
Catalog ID |
RMS475 |
Wrapper Script |
rmswrap_shell_in.ksh |
Design Overview
This batch program is used to Bulk upload xml file data from template files to a staging table (into the content XML column).
This batch will be responsible for validating the input parameters, below are the list of validations.
-
The input file should exist.
-
The input file's extension must be ".xml".
-
The template_name should be valid. A package function will be called for validation.
Once xml data is loaded into the staging table, the script will do the following:
-
Initialize a row in the process tracker table for asynchronous processing.
-
Call the main induction process that uploads data into the staging tables, validates and inserts data into the base Merchandising replenishment schedule tables.
Note:
The base templates used by this batch are loaded through a script on provisioning (REPLENISHMENT_DATA). Additional templates can be configured using the Data Loading Template Configuration in the Merchandising task list under Application Administration for type Replenishment.
Import Management
When using the Import Management features in Merchandising, there are several inbound integration processes that are available for harmonized tariff schedules (HTS), transportation, and letter of credit functions. If you are using Simplified Import Management (based on your system options configurations), then only the HTS upload is supported.
For additional information about import management, including detailed flow diagrams, see the RTM Overview white paper in the Merchandising Documentation Library (Doc ID: 1585843.1).
The following integrations are included in this section:
Harmonized Tariff Schedule Upload (htsupld)
Module Name |
htsupld.pc |
Description |
Harmonized Tariff Schedule Upload |
Functional Area |
Oracle Retail Trade Management |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS41 |
Wrapper Script |
rmswrap_multi_in_rej.ksh |
Design Overview
The harmonized tariff schedule batch module processes a file containing the most recent tariff schedule, by country of import, into Merchandising tables. The module uploads both the initial entry of the schedule and all the updates, as they become available.
Restart/Recovery
Recommended commit counter is 2000. Input file names must end in a “.1" for the restart mechanism to properly parse the file name. Because there is only 1 input file to be uploaded, only 1 thread is used.
A reject file is used to hold records that have failed processing. You can fix the rejected records and process the reject file again.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000051 |
Input File Layout
Table 6-41 Input File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record Descriptor |
Char(5) |
FHEAD |
Describes file line type |
Line number |
Number(10) |
0000000001 |
Sequential file line number |
|
File ID |
Char(5) |
HTSUP |
Describes file type |
|
THEAD |
Record Descriptor |
Char(5) |
THEAD |
Describes file line type |
Line number |
Number(10) |
N/A |
Sequential file line number |
|
Transaction id |
Number(14) |
N/A |
Unique transaction id |
|
HTS Line |
Char(358) |
N/A |
V1 through V4 records from the customs HTS file concatenated together |
|
TDETL |
Record Descriptor |
Char(5) |
TDETL |
Describes file line type |
Line number |
Number(10) |
N/A |
Sequential file line number |
|
Transaction id |
Number(10) |
N/A |
Unique transaction id |
|
Tax/fee line |
Char(80) |
N/A |
V5 through VC records from the customs HTS file, each on a separate TDETL line |
|
TTAIL |
Record Descriptor |
Char(5) |
TTAIL |
Describes file line type |
Line number |
Number(10) |
N/A |
Sequential file line number |
|
Detail lines |
Number(6) |
N/A |
Number of lines between THEAD and TTAIL |
|
FTAIL |
Record Descriptor |
Char(5) |
FTAIL |
Describes file line type |
Line number |
Number(10) |
N/A |
Sequential file line number |
|
Transaction Lines |
Number(10) |
N/A |
Number of lines between FHEAD and FTAIL |
Original Input File
Note:
The input file contains lines of 2400 characters (that is, the newline character occurs only after every 2400 characters). Each 2400-character line consists of thirty 80-character records. Each 80-character record starts with ‘V1' or ‘V2' … or ‘VD' or blank if the record is completely empty. For each tariff, records V1 and V2 are mandatory; records V3 through VD are optional, which means they can be all blank. Record V4 is not currently used in Merchandising/Trade Management. Records V5 through VC contain the tax/fee information for the tariff, and all have the same structure.
Record Name | Field Name | Field Type | Default Value | Description | ||||
---|---|---|---|---|---|---|---|---|
V1 a |
Control identifier |
Char(1) |
V |
Identifies start of record |
||||
b |
Record type |
Char(1) |
1 |
Identifies record type |
||||
c |
Tariff number |
Number(25) |
|
Harmonized Tariff Schedule (HTS) code or tariff number used to classify merchandise for import. If this number is less than 25 positions, it is left justified. |
||||
d |
Transaction code |
Char(1) |
A, D, R |
A code representing the type of transaction. Valid Transaction Codes are:
A = Add D = Delete R = Replace |
||||
e |
Begin effective date |
char(6) |
|
A numeric date in MMDDYY (month, day, year) format representing the record begin effective date. This date indicates when the record becomes effective. |
||||
f |
End effective date |
char(6) |
|
A numeric date in MMDDYY (month, day, year) format representing the record end effective date. This date indicates the last date the record is effective. |
||||
g |
number of reporting units |
number(1) |
0,1,or 2 or 3 |
The number of reporting units required by the Bureau of the Census. In a few instances, units not required by Census may be required to compute duty. In these cases, the Census reporting units are always first, followed by any additional units required to compute the duty. |
||||
h |
1st reporting unit of measure |
char(4) |
|
A code representing the first unit of measure. Valid unit of measure codes are found on the Units of Measure Class table (uom_class) in Merchandising. |
||||
I |
2nd reporting unit of measure |
char(4) |
|
A code representing the second unit of measure. Valid unit of measure codes are found on the Units of Measure Class table (uom_class) in Merchandising. |
||||
j |
3rd reporting unit of measure |
char(4) |
|
A code representing the third unit of measure. Valid unit of measure codes are found on the Units of Measure Class table (uom_class) in Merchandising. |
||||
k |
duty computation code |
char(1) |
|
A code indicating the formula to be used to compute the duty. Valid Duty Computation Codes are found under the Duty Computation Codes (DCMP) code type. |
||||
l |
commodity description |
char(30) |
|
A condensed version of the commodity description that appears in the HTS. |
||||
m |
column 1 specific rate of duty |
Number(12) |
|
The specific rate of duty (monetary amount per unit of measure) applied for imports in general when no conditional tariff treatments are applicable. Within Merchandising this rate is stored against the Column 1 (C1) tariff treatment. Eight decimal places are implied. |
||||
n |
base rate indicator |
char(1) |
‘B’ or blank |
A code indicating if the rate contains a base rate. If the base rate indicator is B, the duty rate is a base rate; otherwise, space fill. Not Used in RMS. |
||||
o |
space fill |
char(1) |
blank |
Space fill. Not used in RMS. |
||||
V2 a |
Control identifier |
char(1) |
V |
Identifies start of record |
||||
b |
Record type |
char(1) |
2 |
Identifies record type |
||||
c |
tariff number |
Number (25) |
|
Harmonized Tariff Schedule (HTS) code or tariff number used to classify merchandise for import. If this number is less than 25 positions, it is left justified. This number is the same as that in Record Identifier V1. |
||||
d |
general column 1 ad valorem percentage |
Number (12) |
|
The ad valorem rate of duty applied for imports in general when no conditional tariff treatments are applicable. Within Merchandising this rate is stored against the Column 1 (C1) tariff treatment. Eight decimal places are implied. |
||||
e |
column 1 other |
Number (12) |
|
The other rate of duty applied for imports in general when no conditional tariff treatments are applicable. Within Merchandising this rate is stored against the Column 1 (C1) tariff treatment. Eight decimal places are implied. |
||||
f |
Column 2 specific rate |
Num(12) |
|
The specific rate of duty (monetary amount per unit of measure) applied for imports in general when the country of origin is not in good standing with the country of import and higher rates of duty are assessed to deter trade. Within Merchandising this rate is stored against the Column 2 (C2) tariff treatment. Eight decimal places are implied. |
||||
g |
Column 2 ad valorem percentage |
Num(12) |
|
The ad valorem rate of duty applied for imports in general when the country of origin is not in good standing with the country of import and higher rates of duty are assessed to deter trade. Within Merchandising this rate is stored against the Column 2 (C2) tariff treatment. Eight decimal places are implied. |
||||
h |
Column 2 other rate |
Num(12) |
|
The other rate of duty applied for imports in general when the country of origin is not in good standing with the country of import and higher rates of duty are assessed to deter trade. Within Merchandising this rate is stored against the Column 2 (C2) tariff treatment. Eight decimal places are implied. |
||||
i |
countervailing duty flag |
char(1) |
blank or 1 |
A code of 1 indicating the tariff number is subject to countervailing duty; otherwise, space fill. |
||||
j |
additional tariff indicator |
char(1) |
blank or ‘R’ |
A code indicating if an additional HTS code or tariff number may be required to fully classify the item. This indicator is R when an additional tariff number may be required; otherwise, space fill. |
||||
k |
Miscellaneous Permit/ License Indicator |
char(2) |
|
A code indicating if a tariff number may be subject to a miscellaneous permit/license number. |
||||
l |
space fill |
char(4) |
blanks |
Not used in RMS. |
||||
V3 a |
Control identifier |
char(1) |
V |
identifies start of record |
||||
b |
Record type |
char(1) |
3 |
identifies record type |
||||
c |
tariff number |
Number(25) |
|
Harmonized Tariff Schedule (HTS) code or tariff number used to classify merchandise for import. If this number is less than 25 positions, it is left justified. This number is the same as that in Record Identifier V1. |
||||
d |
GSP excluded countries |
char(20) |
|
The International Organization for Standardization (ISO) country code that indicates countries not eligible for preferential treatment under GSP. Valid country codes are found on the country table (country). |
||||
e |
OGA codes |
char(15) |
|
Codes that indicate special requirements by Other Government Agencies (OGA) may apply. Up to five 3 position OGA codes can be provided. |
||||
f |
anti-dumping flag |
char(1) |
1 or blank |
A code of 1 indicating the tariff number is subject to an antidumping duty; otherwise, space fill. |
||||
g |
quota indicator |
char(1) |
1 or blank |
A code of 1 indicating the tariff number may be subject to quota. If the tariff number is not subject to quota, space fill. |
||||
h |
category number |
char(6) |
|
A code located in the HTS indicating the textile category assigned to the tariff number. If there is no textile category number, space fill. |
||||
I |
special program indicators Special Program Indicator (SPI) / Tariff Treatment |
char(60) |
|
Special Program Indicator or Tariff Treatment codes that indicate if a tariff number is subject to a special program with preferential rates of duty. Up to fourteen 2 position codes can be reported. Left justify. The tariff treatment codes are not reported in any particular sequence. If more than fourteen 2-position codes are required, they are reported on the VD record. |
||||
NEWLINE |
|
|
\n |
|
||||
V4 a |
Control identifier |
char(1) |
V |
identifies start of record. Entire V4 record not used in RMS. |
||||
b |
Record type |
char(1) |
4 |
identifies record type |
||||
c |
tariff number |
Number (25) |
|
Harmonized Tariff Schedule (HTS) code or tariff number used to classify merchandise for import. If this number is less than 25 positions, it is left justified. This number is the same as that in Record Identifier V1. |
||||
d |
value edit code |
char(3) |
|
A code representing the value edit. |
||||
e |
value low bounds |
Number (10) |
|
A value representing the minimum value edit. Five decimal places are implied. If this record contains date edits (positions 36‑53), space fill. |
||||
f |
value high bounds |
Number (10) |
|
A value representing the maximum value edit. Five decimal places are implied. If this record contains date edits (positions 36‑53), space fill. |
||||
g |
entry date restriction |
Number (1) |
0,1, or 2 |
A code representing the first entry date restriction code. |
||||
h |
beginning restriction date |
char(4) |
|
A numeric date in MMDD (month and day) format representing the first begin restriction date used in the edit. If this record contains a value edit (positions 13‑35), space fill. |
||||
I |
end restriction date |
char(4) |
|
A numeric date in MMDD (month and day) format representing the first end restriction date used in the edit. If this record contains a value edit (positions 13‑35), space fill. |
||||
j |
entry date restriction 2 |
number(1) |
0,1, or 2 |
A code representing the second entry date restriction code. |
||||
k |
beginning restriction date 2 |
char(4) |
|
A numeric date in MMDD (month and day) format representing the second begin restriction date used in the edit. If this record contains a value edit (positions 13‑35), space fill. |
||||
l |
end restriction date 2 |
char(4) |
|
A numeric date in MMDD (month and day) format representing the second end restriction date used in the edit. If this record contains a value edit (positions 13‑35), space fill. |
||||
m |
country of origin |
char(2) |
|
A code representing the value edit. |
||||
n |
space filler |
char(2) |
blanks |
A value representing the minimum value edit. Five decimal places are implied. If this record contains date edits (positions 36‑53), space fill. |
||||
o |
quantity edit code |
char(3) |
|
A value representing the maximum value edit. Five decimal places are implied. If this record contains date edits (positions 36‑53), space fill. |
||||
p |
low quantity |
Number (10) |
|
A code representing the first entry date restriction code. |
||||
q |
high quantity |
Number (10) |
|
A numeric date in MMDD (month and day) format representing the first begin restriction date used in the edit. If this record contains a value edit (positions 13‑35), space fill. |
||||
V5 a |
Control identifier |
char(1) |
V |
Identifies start of record |
||||
b |
Record type |
char(1) |
5,6,7,8,9,A,B,C |
Identifies record type |
||||
c |
tariff number |
Number (25) |
|
Harmonized Tariff Schedule (HTS) code or tariff number used to classify merchandise for import. If this number is less than 25 positions, it is left justified. This number is the same as that in Record Identifier V1. |
||||
d |
Country code Special Program Indicator (SPI) / Tariff Treatment / Country Code |
char(2) |
|
A code representing a tariff treatment/special program indicator which may or may not be the same as a valid ISO country code. Single character tariff treatment codes should include a space after the code to fill the 2-character space per code. |
||||
e |
specific rate |
Number (12) |
|
The specific rate of duty listed in the Special column of the HTS. Eight decimal places are implied. |
||||
f |
ad valorem rate |
Number (12) |
|
The ad valorem rate of duty listed in the Special column of the HTS. Eight decimal places are implied. |
||||
g |
Other rate |
Number (12) |
|
The rate of duty listed in the Special column of the HTS that is not a specific or ad valorem rate. Eight decimal places are implied. |
||||
h |
tax/fee class code |
char(3) |
|
A code representing the tax/fee class or type. The system assumes that any class/type code which is less than 23 (i.e. 016, 017, 018, 022, etc.) is a tax, and any value greater than or equal to 23 is a fee (i.e. 023, 024, 045, 056, etc.). |
||||
I |
tax/fee computation code |
char(1) |
|
A code indicating the first tax/fee computation formula. Valid Computation formulas for taxes and fees are found under the Duty Computation Codes (DCMP) code type, but computation codes 0, J and K are only valid for duty, not for tax and fee computations. |
||||
j |
tax/fee flag |
number(1) |
|
A code indicating a tax/fee is required. Valid Tax/Fee Flag Codes are:
1 = Tax/fee required 2 = Tax/fee may be required. Not used in RMS. |
||||
k |
tax/fee specific rate |
Number (12) |
blank if no value |
The specific rate of duty required to compute taxes and/or fees. Eight decimal places are implied. |
||||
l |
tax/fee ad valorem |
Number (12) |
blank if no value |
The ad valorem rate of duty required to compute taxes and/or fees. Eight decimal places are implied. |
||||
m |
space fill |
char(1) |
blank |
Space fill. |
||||
Note: V6 through VC records have the same fields as the V5 record. |
||||||||
VD a |
Control identifier |
char(1) |
V |
identifies start of record |
||||
b |
Record type |
char(1) |
D |
identifies record type |
||||
c |
tariff number |
Number (25) |
|
unique tariff number |
||||
d |
Special Program Indicator (SPI) Code / Tariff Treatment |
char(32) |
|
Special Program Indicator or Tariff Treatment codes that indicate if a tariff number is subject to a special program with preferential rates of duty. Up to sixteen 2-position codes can be reported. Left justify. The codes are not reported in any particular sequence. |
||||
e |
Filler |
char(36) |
|
Space fill. |
Letter of Credit Confirmation Upload (lcupld)
Module Name |
lcupld.pc |
Description |
Letter of Credit Confirmation Upload |
Functional Area |
Oracle Retail Trade Management |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS55 |
Wrapper Script |
Rmswrap_in_rej.ksh |
Design Overview
The LCUPLD program is used to upload LC (Letter of Credit) confirmations from bank partners.
After this program has processed a confirmation, the appropriate tables will be updated; a confirmation will update the LC to confirm status and it will write the appropriate records to the LC_ACTIVITY table.
Restart/Recovery
Restart/recovery for this program is set up at the individual FDETL record. Although there may be more than one FDETL record for a given LC, they will each be processed as a separate entity.
File based restart/recovery must be used. The commit_max_ctr field should be set to prevent excessive rollback space usage, and to reduce the overhead of file I/O. The recommended commit counter setting is 10000 records.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integratin Contract |
IntCon000054 |
Input File Layout
Table 6-42 Input File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
File Line Sequence Number |
Number(10) |
0000000001 |
Line number of the current file |
|
File Type Definition |
Char(4) |
LCUP |
Identifies file as ‘Letter of Credit Upload' |
|
File Create Date |
Char (14) |
vdate |
Date file was written by external system ‘YYYYMMDDHH24MISS' format |
|
File Detail |
File Type Record Descriptor |
Char(5) |
FDETL |
Identifies file record type |
File Line Sequence Number |
Number(10) |
Line number of the current file |
||
Sender's Reference |
Char(16) |
lc_head.bank_lc_id |
The LC number that the bank assigns to a Letter of Credit |
|
Receiver's Reference |
Number(8) |
lc_activity.lc_ref_id |
The LC number that Trade Management assigned to the Letter of Credit |
|
Date of Message Being Acknowledged |
Char(14) |
lc_activity.activity_date |
YYYYMMDDHH24MISS format |
|
Comments |
Char(2000) |
lc_activity.comments |
This field is a concatenation of the following SWIFT fields: 71B – Charges, 72 – Sender information |
|
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Sequence |
Number(10) |
N/A |
Line number of the current file |
|
Total number lines |
Number(10) |
N/A |
Total number of lines in file not including FHEAD and FTAIL |
Letter of Credit Drawdowns and Charges Upload (lcup798)
Module Name |
lcup798.pc |
Description |
Letter of Credit Drawdowns and Charges |
Functional Area |
Oracle Retail Trade Management |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS54 |
Wrapper Script |
rmswrap_in_rej.ksh |
Design Overview
This program reads data from an input file containing letter of credit charges and drawings (in standard Oracle Retail format, modified from the SWIFT 798 format by the lcmt798 Perl script), validates it, and inserts it into the LC_ACTIVITY table. If a record fails validation, it will be written to a reject file. These rejected records can be reprocessed by lcup798 after errors have been corrected.
Restart/Recovery
This program will be restartable but not threadable.
Restart/recovery logic for file-based processing is used. Records will be committed to the database when commit_max_ctr defined in the RESTART_CONTROL table is reached.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integratin Contract |
IntCon000055 |
The input file for this batch program is the output from the lcmt798 Perl script.
Input File Layout
Table 6-43 Input File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
File head descriptor |
Char(5) |
FHEAD |
Describes file line type |
Line id |
Number (10) |
0000000001 |
Sequential file line number |
|
File Type Definition |
Char(4) |
‘LCCH' |
Identifies as an LC 798 file-Letter of Credit Charges |
|
Current date |
Date |
N/A |
File date in YYYYMMDDHH24MISS format |
|
FDETL |
File record descriptor |
Char(5) |
FDETL |
Describes file line type |
Line id |
Number (10) |
Sequential file line number |
||
Bank letter of credit reference ID |
Char (16) |
SWIFT tag 20 |
Bank's LC ref ID |
|
Order number |
Number(8) |
SWIFT tag 21 |
Order number attached to LC.May be blank |
|
Invoice number |
Number (15) |
SWIFT tag 23 |
NOT a Merchandising invoice number, just a reference invoice number from the issuing bank. May be blank |
|
Transaction number |
Number (10) |
N/A |
Amendment number or transaction number assigned by bank.May be null |
|
Transaction code |
Char(6) |
B or D |
‘B'ank charge or‘D'rawdown |
|
Amount |
Number(21) |
SWIFT tag 33A,71A |
(This is a 20-digit number with a leading – sign or blank and 4 implied decimal places.) Amount of charge or drawdown |
|
Currency code |
Char(3) |
SWIFT 33A,71A |
Currency that the amount is in |
|
Activity date |
Date |
SWIFT 33A,32C,32D |
Activity date(formatted as 'YYYYMMDD') |
|
Comments |
Char(2000) |
SWIFT tag 72 |
Any comments associated with activity.May be null |
|
FTAIL |
File record descriptor |
Char(5) |
FTAIL |
Marks end of file |
Line id |
Char(10) |
N/A |
Sequential file line number |
|
Number of lines |
Number(10) |
N/A |
Number of lines in file not counting FHEAD and FTAIL |
SWIFT File Conversion - Letter of Credit Confirmation (lcmt730)
Module Name |
lcmt730 |
Description |
SWIFT File Conversion – Letter of Credit Confirmation |
Functional Area |
Oracle Retail Trade Management |
Module Type |
Integration |
Module Technology |
Perl |
Catalog ID |
RMS138 |
Wrapper Script |
batch_lcmt730.ksh |
Design Overview
The lcmt730 Perl script converts letter of credit confirmations from a S.W.I.F.T. format (MT730) to a Merchandising flat file format. The output file from this script will be the input file for the lcupld.pc.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integratin Contract |
IntCon000054 (output) IntCon000139 (input) |
Input File Layout
Table 6-44 Input File Layout
SWIFT I.D. and Description | Data Type | Description | How MT 730 fields are put into the Merchandising standard file format and what should be the size of Merchandising to be dealt with | Comments |
---|---|---|---|---|
20 - Sender's Reference |
16x |
LC number. The one assigned by the Sender (issuing bank) |
FDETL - Sender's reference, Char(16) |
This field maps to Trade Management's Bank LC Ref ID. |
21 - Receiver's Reference |
16x |
LC number assigned by the Receiver (retailer) |
FDETL - Receiver's reference, Number(8) (NOREF used if unknown) |
This field maps to Trade Management's LC Ref ID. If this field has 'NOREF', the record must be rejected since this field is used to indicate the LC within Trade Management to which this record applies. |
25 - Account Identification |
35x |
Identifies the number of the account, which has been used for the settlement of charges, on the books of the Sender. |
N/A |
Trade Management currently does not have fields that map directly to this. Current position - will be included in the input file. However, it will be ignored during the upload process. |
30 - Date of Message Being Acknowledged |
6!n |
When a message is acknowledging a MT700, this field specifies the date of issue. In all other cases, this field specifies the date on which the message being acknowledged was sent. |
FDETL - Date of message Being Acknowledged, Date |
This field maps to the LC activity date. As well, if this in confirming an LC application, it will be mapped to the LC's confirmation date. Year interpretation: If YY>79 then YYMMDD = 19YYMMDD Else YYMMDD = 20YYMMDD. |
32a - Amount of Charges |
Option B - 3!a15d
Option D - 6!n3!a15d |
Contains the currency code and total amount of charges claimed by the sender of the message. When charges have been debited, D is used (:32D) and when reimbursement for charges is needed, B is used (:32B). |
FDETL -Upload_type = 'C'onfirmation |
Current position - Because the 730 will only be used for confirmations, this field will not contain any values. The upload type should be set equal to 'C'onfirmation. |
57a - Account With Bank |
Option A - [/1!a][/34x] 4!a2!a2!c[ 3!c]
Option D - [/1!a][/34x] 4*35x |
This field specifies the bank to which the amount of charges is to be remitted in favor of the Sender. |
FDETL - Account With Bank, Char(10) |
Current position - will be added to the input file however will be ignored in the upload process. Because Trade Management has no facilities to maintain BICs or party identifiers, option D will always be used for this field (that is, 57D) without [/1!a][/34x] party identifier. |
71B - Charges |
6*35x |
Specification of the charges claimed. |
FDETL - Comments, Char(2000) |
This field maps to Trade Management's activity comments field. Sender to Receiver information (72) will be concatenated to this. |
72 - Sender to Receiver Information |
6*35x |
Text explanation if wanted. |
FDETL - Comments, Char(2000) |
This field maps to Trade Management's activity comments field. Charges (71B) will be concatenated to this. |
Output File Layout
Table 6-45 Output File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
File Line Sequence Number |
Number(10) |
specified by external system |
Line number of the current file |
|
File Type Definition |
Char(4) |
LCUP |
Identifies file as ‘Letter of Credit Upload' |
|
File Create Date |
Char (14) |
vdate |
date file was written by external system ‘YYYYMMDD HH24MISS' format |
|
File Detail |
File Type Record Descriptor |
Char(5) |
FDETL |
Identifies file record type |
File Line Sequence Number |
Number(10) |
specified by external system |
Line number of the current file |
|
Sender's Reference |
Char(16) |
lc_head.bank_ld_id |
The LC number that the bank assigns to a Letter of Credit |
|
Receiver's Reference |
Number(8) |
lc_activity.lc_ref_id |
The LC number that Merchandising assigned to the Letter of Credit |
|
Date of Message Being Acknowledged |
Date (char 8) |
lc_activity.activity_date |
If the upload type is ‘L' then this date will match the date MT 700 date of issue (which we have not resolved between being the vdate or the lc_head.application_date) ‘YYYYMMDD' format |
|
Comments |
Char(2000) |
lc_activity.comments |
Need to truncate? This field will probably be a concatenation of the following SWIFT fields: 71B – Charges, 72 – Sender information |
|
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Sequence |
Number(10) |
Specified by external system |
Line number of the current file |
|
Total number of lines |
Number(10) |
Specified by external system |
Total number lines in file |
SWIFT File Conversion - Letter of Credit Drawdowns and Charges (lcmt798)
Module Name |
lcmt798 |
Description |
SWIFT File Conversion – Letter of Credit Drawdowns and Charges |
Functional Area |
Retail Trade Management - Letter of Credit Interfaces |
Module Type |
Integration |
Module Technology |
Perl |
Catalog ID |
RMS139 |
Wrapper Script |
batch_lcmt798.ksh |
Design Overview
This Perl script converts letter of credit (L/C) activity data for charges and drawdowns from a S.W.I.F.T. format input file to a Merchandising format file.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000139 (input) |
Input File Layout
Table 6-46 Input File Layout
Swift Tag | Description | Regd? | Datatype | Merchandising Field |
---|---|---|---|---|
20 - Transaction Reference Number |
The sender's unambiguous identification of the transaction. Its detailed form and content are at the discretion of the sender. |
Yes |
16x - Transaction Reference Number |
Bank L/C ID Lc_head.bank_lc_id Varchar2(16) |
12 - Type of Financial Instrument |
This field classifies the financial instrument by a description or proprietary code. |
Yes |
Option A- :4!c/[8c]/30x :4!c - Qualifier / - Delimiter [8c] - Issuer Code / - Delimiter 30x - Type |
This field will contain a constant identifier - '798' |
77E - Proprietary Message |
This field contains the proprietary message in a format agreed to by the Sender and the Receiver. |
Yes |
Option E- 73x [n*78x] |
This field will contain the information below (fields 21, 23, 32C, 32D, 71A, 33A, 72) Carriage return, Line feed, Colon 'CrLf:' will be used to separate fields included in this 77E For example: :77E:'CrLf' :21:10004321:CrLf' :32C:990121USD1045 and so on. There may be multiple 77Es in one file |
21 - Related Reference |
This field specifies, in an unambiguous way, a message or transaction identifier which is normally included as part of the information supplied with the message or transaction itself, and can subsequently be used to distinguish the message or transaction identified from other messages or transactions. |
No |
16x |
P/O Number
Lc_activity.order_no Number(8) |
23 - Further identification |
This field specifies the type of transaction being confirmed, as well as the settlement method used. |
No |
16x |
Invoice Number Lc_activity.invoice_no Varchar2(15) |
32C - Date and Amount |
This field specifies the currency code and amount in a transaction and a corresponding date. |
No |
Option A- :4!c/[8c]/30x :4!c - Qualifier / - Delimiter [8c] - Issuer Code / - Delimiter 30x - Type |
Charges Credited (this is interpreted as a positive amount)
Date will be in format YYMMDD
The integer part of the Amount must contain at least one digit. A decimal comma ',' is mandatory and is included in the maximum length Lc_activity.amount Number(20,4) Lc_activity.currency_code Varchar2(3) Lc_activity.activity_date Date |
32D - Date and Amount |
This field specifies the currency code and amount in a transaction and a corresponding date. |
No |
Option D- 6!n3!a15d
6!n - Date 3!a - Currency 15d - Amount |
Charges Debited (this is interpreted as a negative amount)
Date will be in format YYMMDD
The integer part of the Amount must contain at least one digit. A decimal comma ',' is mandatory and is included in the maximum length Lc_activity.amount Number(20,4) Lc_activity.currency_code Varchar2(3) Lc_activity.activity_date Date |
33A - Date and Amount |
This field specifies the currency code and amount in a transaction and a corresponding date. |
No |
Option A- 6!n3!a15d
6!n - Date 3!a - Currency 15d - Amoun |
Date, currency, amount of drawing (this is interpreted as a positive amount)
Date will be in format YYMMDD
The integer part of the Amount must contain at least one digit. A decimal comma ',' is mandatory and is included in the maximum length Lc_activity.amount Number(20,4) Lc_activity.currency_code Varchar2(3) Lc_activity.activity_date Date |
33C - Date and Amount |
This field specifies the currency code and amount in a transaction and a corresponding date. |
No |
Option A- 6!n3!a15d 6!n - Date 3!a - Currency 15d - Amount |
Date, currency, amount of drawing (this is interpreted as a negative amount) Date will be in format YYMMDD The integer part of the Amount must contain at least one digit. A decimal comma ',' is mandatory and is included in the maximum length. Lc_activity.amount Number(20,4) Lc_activity.currency_code Varchar2(3) Lc_activity.activity_date Date |
72 - Sender to Receiver Information |
This field specifies instructions or additional information for the Receiver, Intermediary, Account with Institution or Beneficiary Institution. |
No |
6*35x |
Comments Lc_activity.comment Varchar2(2000) |
18A - Number of Repetitive Parts |
This field specifies the number of times the repetitive part(s)/sequence(s)directly before or after this field appears in the message. |
No |
Option A- 5n - Number of Repetitive Parts. |
Number of 77E's contained within the file. |
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integratin Contract |
IntCon000055 (input) |
Output File Layout
Table 6-47 Output File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
File Line Identifier |
Number (10) |
Line number in file |
ID of current line being created for output file |
|
File Type Definition |
Char(4) |
LCCH |
Identifies file as ‘Letter of Credit Changes' |
|
File Create Date |
Char(14) |
Create date |
Current date, formatted to ‘YYYYMMDDHH24MISS' |
|
File Detail |
File Type Record Descriptor |
Char(5) |
FDETL |
Identifies file record type |
File Line Sequence Number |
Number (10) |
Line number in file |
ID of current line being created for output file |
|
Bank Letter of Credit Reference ID |
Char(16) |
SWIFT tag 20 |
Bank L/C ID |
|
Order Number |
Number (8) |
SWIFT tag 21 |
Contains the order number that is attached to the letter of credit |
|
Invoice Number |
Char (15) |
SWIFT tag 23 |
Identifies the Issuing Bank's invoice number to which the drawdown refers. This field does not correspond to a Merchandising invoice number |
|
Transaction Number |
Char (10) |
Null |
Identifies the amendment number or actual transaction number assigned by the bank |
|
Transaction Code |
Char (6) |
If the transaction is a Bank Charge – ‘B' f the transaction is a Drawdown – ‘D' |
Identifies the type of transaction that occurred The type is determined by what detail fields are received for the record. If the record contains a 33A this field will get a 'D'. If the record contains either a 32C or 32D this field will get a 'B' |
|
Amount Sign |
Char (1) |
SWIFT 33A, 33C SWIFT 32C, 32D |
If the record contains a 33A field leave a blank space in this field If the record contains a 33C filed this field should contain a '-' If the record contains a 32C field leave a blank space in this field If the record contains a 32D field this field should contain a '-' |
|
Amount |
Number (20) |
SWIFT 33A, 33C SWIFT 32C, 32D |
Holds the amount of the activity. This field will have 4 implied decimal places If SWIFT 32C or 32D (Bank Charge) contains a value, use the amount from this field If SWIFT 33A or 33C (Drawdown) contains a value, use the amount from this field |
|
Currency Code |
Char (3) |
SWIFT 33A, SWIFT 32C, 32D |
Contains the activity's currency code If SWIFT 32C or 32D (Bank Charge) contains a value, use the currency from this field If SWIFT 33A (Drawdown) contains a value, use the currency from this field |
|
Activity Date |
Char (8) |
SWIFT 33A, SWIFT 32C, 32D |
Holds the date that the activity took place. Formatted to 'YYYYMMDD' If SWIFT 32C or 32D (Bank Charge) contains a value, use the date from this field If SWIFT 33A (Drawdown) contains a value, use the date from this field |
|
Comments |
Char (2000) |
SWIFT tag 72 |
Holds any comments for the activity |
|
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Identifier |
Number (10) |
Sequential number Created by program. |
ID of current line being created for output file |
|
File Record Counter |
Number (10) |
N/A |
This will contain the number of FDETL lines processed |
Transportation Upload (tranupld)
Module Name |
tranupld.pc |
Description |
Transportation Upload |
Functional Area |
Oracle Retail Trade Management |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS140 |
Wrapper Script |
rmswrap_multi_in.ksh |
Design Overview
This program uploads data from trading partners about the transportation of merchandise from the manufacturing site through customs clearance.
Restart/Recovery
The logical unit of work is a valid DTRAN record. The program reads each DTRAN record from the upload file, validates it and processes it. The recommended commit max counter value for this program is 1000 (this value depends on the implementation).
Backward Compatibility
Added additional parameter to indicate version. If no parameter is supplied, the version defaults to 1 (initial version).
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000177 |
Input File Layout Summary Across Versions
Version Number | Record Name | Length |
---|---|---|
1 |
File Header - FTRAN |
33 |
Transaction Header – DTRAN |
257 |
|
Transaction Detail – DPOIT |
560 |
|
Transaction Trailer – FTAIL |
25 |
|
2 |
File Header - FTRAN |
33 |
Transaction Header – DTRAN |
265 |
|
Transaction Detail – DPOIT |
560 |
|
Transaction Trailer – FTAIL |
25 |
Input File Layout
Table 6-48 Input File Layout
Record Name | Field Name | Field Type | Default Value | Description | Added in Version |
---|---|---|---|---|---|
FTRAN |
Record descriptor |
Char(5) |
FTRAN |
File head marker |
|
Line id |
Number(10) |
0000000001 |
Unique line id |
||
File type definition |
Char(4) |
TRUP |
Identifies program as tranupld |
||
File create date |
Char(14) |
Current date |
YYYYMMDDHHMISS format |
||
DTRAN |
Record descriptor |
Char(5) |
DTRAN |
Vessel, Voyage, ETD, Container, BL, Invoice File head |
|
Line id |
Number(10) |
Unique line id |
|||
Partner Type |
Char(6) |
Identifies the partner type |
|||
Partner ID |
Char(10) |
Identifies the partner id. |
|||
Vessel ID |
Char(20) |
Identifies the Vessel |
|||
Voyage ID |
Char(10) |
Identifies the Voyage or Flight ID |
|||
Estimated Depart Date |
Char(8) |
YYYYMMDD format |
|||
Shipment Number |
Char (20) |
Identifies an outside Shipment number |
|||
Actual Departure Date |
Char(8) |
YYYYMMDD format |
2 |
||
Actual Arrival Date |
Char(8) |
YYYYMMDD format |
|||
Trans Mode |
Char(6) |
Identifies the type of transportation being used. Valid values are found in the TRMO Code Type on the CODE_DETAIL table |
|||
Vessel SCAC Code |
Char(6) |
Customs defined ID for the Vessel. Validated against SCAC table. |
|||
Estimated Arrival Date |
Char(8) |
YYYYMMDD format |
|||
Lading Port |
Char(5) |
Identifies the Lading Port. Validated against OUTLOC with type = ‘LP’ |
|||
Discharge Port |
Char(5) |
Identifies the Discharge Port. Validated against OUTLOC with type = ‘DP’ |
|||
Service Contract Number |
Char(15) |
Identifies the outside Service Contract Number |
|||
Container id |
Char(20) |
Identifies the Container |
|||
Container SCAC code |
Char(6) |
Customs defined id for the container. Validated against SCAC table |
|||
Delivery Date |
Char(8) |
YYYYMMDD format |
|||
Seal id |
Char(15) |
Customs defined id for the container’s seal |
|||
Freight Type |
Char(6) |
Code that identifies the container type. Validated against the FREIGHT_TYPE table. |
|||
Freight Size |
Char(6) |
Code that identifies the container size. Validated against the FREIGHT_SIZE table. |
|||
In Transit No. |
Char(15) |
External transit number |
|||
In Transit Date |
Char(8) |
YYYYMMDD format |
|||
BL/AWB id |
Char(30) |
Identifies the Bill of Lading or Air Way Bill |
|||
Candidate Ind |
Char(1) |
Defaulted to ‘N’ |
Identifies a complete Transportation record. Valid values are ‘Y’ and ‘N’ |
||
DPOIT |
Record descriptor |
Char(5) |
DPOIT |
Order/Item detail info |
|
Line id |
Number(10) |
Unique file line id |
|||
ACD_Code |
Char(1) |
Determines which process to perform ‘A’dd, ‘C’hange, ‘D’elete. |
|||
Rush Ind |
Char(1) |
Defaulted to ‘N’ |
Identifies whether or not the item should be on a ‘Rush’ delivery. Valid values are ‘Y’ and ‘N’ |
||
Order number |
Number(12) |
Merchandising order number |
|||
Item |
Char(25) |
Merchandising Item number |
|||
Invoice id |
Char(30) |
Identifies the Commercial Invoice |
|||
Invoice date |
Char(8) |
YYYYMMDD format |
|||
Currency Code |
Char(3) |
Currency that the Currency Amount is reported in. Validated against CURRENCIES table. |
|||
Exchange Rate |
Char (20) |
The exchange rate back to the primary currency (10 implied decimals) |
|||
Invoice amt |
Char 20) |
Invoice amt*10000 (with 4 implied decimal places), amount charged by supplier for the PO/Item |
|||
Origin Country id |
Char(3) |
Identifies where the PO/Item was made |
|||
Consolidation Country id |
Char(3) |
Identifies where the PO/Items were consolidated |
|||
Export Country id |
Char(3) |
Identifies where the PO/Items where shipped from |
|||
Status |
Char(6) |
Identifies the PO/Item status. Valid values are found in the TRCO Code Type on CODE_DETAIL |
|||
Receipt ID |
Char(30) |
Identifies the external receipt number |
|||
FCR id |
Char(15) |
Identifies the Freight Cargo Receipt id |
|||
FCR date |
Char(8) |
YYYYMMDD format |
|||
Packing Method |
Char(6) |
Identifies the Packing Type (Hanging or Flat). Valid values are ‘HANG’ or ‘FLAT’ |
|||
Lot Number |
Char(15) |
Identifies the Lot Number of the PO/Item |
|||
Item Qty |
Number(12) |
Item Qty*10000(with 4 implied decimals), qty of Items |
|||
Item QTY UOM |
Char(4) |
Identifies the UOM associated with the item quantity |
|||
Carton QTY |
Number(12) |
Carton QTY*10000 (with 4 implied decimals), qty of Cartons |
|||
Carton QTY UOM |
Char(4) |
Identifies the UOM associated with the carton quantity |
|||
Gross WT |
Number(12) |
Gross WT*10000 (with 4 implied decimals), Gross weight |
|||
Gross WT UOM |
Char(4) |
Identifies the UOM associated with the gross weight |
|||
Net WT |
Number(12) |
Net WT*10000 (with 4 implied decimals), Net Weight |
|||
Net WT UOM |
Char(4) |
Identifies the UOM associated with the net weight |
|||
Cubic |
Number(12) |
Cubic*10000 (with 4 implied decimals), cubic size |
|||
Cubic UOM |
Char(4) |
Identifies the UOM associated with the cubic size |
|||
Comments |
Char(256) |
User Comments |
|||
FTAIL |
Record type |
Char(5) |
FTAIL |
||
Line id |
Number(10) |
Unique file line id |
|||
No. of lines |
Number(10) |
Total number of transaction lines in file (not including FHEAD and FTAIL) |
Record Name | Field Name | Field Type | Default Value | Description | Added in Version |
---|---|---|---|---|---|
FTRAN |
Record descriptor |
Char(5) |
FTRAN |
File head marker |
|
Line id |
Number(10) |
0000000001 |
Unique line id |
||
File type definition |
Char(4) |
TRUP |
Identifies program as tranupld |
||
File create date |
Char(14) |
Current date |
YYYYMMDDHHMISS format |
||
DTRAN |
Record descriptor |
Char(5) |
DTRAN |
Vessel, Voyage, ETD, Container, BL, Invoice File head |
|
Line id |
Number(10) |
N/A |
Unique line id |
||
Partner Type |
Char(6) |
N/A |
Identifies the partner type |
||
Partner ID |
Char(10) |
N/A |
Identifies the partner id |
||
Vessel ID |
Char(20) |
N/A |
Identifies the Vessel |
||
Voyage ID |
Char(10) |
N/A |
Identifies the Voyage or Flight ID |
||
Estimated Depart Date |
Char(8) |
N/A |
YYYYMMDD format |
||
Shipment Number |
Char (20) |
N/A |
Identifies an outside Shipment number |
||
Actual Arrival Date |
Char(8) |
N/A |
YYYYMMDD format |
||
Trans Mode |
Char(6) |
N/A |
Identifies the type of transportation being used. Valid values are found in the TRMO Code Type on the CODE_DETAIL table |
||
Vessel SCAC Code |
Char(6) |
N/A |
Customs defined ID for the Vessel. Validated against SCAC table |
||
Estimated Arrival Date |
Char(8) |
N/A |
YYYYMMDD format |
||
Lading Port |
Char(5) |
N/A |
Identifies the Lading Port. Validated against OUTLOC with type = ‘LP' |
||
Discharge Port |
Char(5) |
N/A |
Identifies the Discharge Port. Validated against OUTLOC with type = ‘DP' |
||
Service Contract Number |
Char(15) |
N/A |
Identifies the outside Service Contract Number |
||
Container id |
Char(20) |
N/A |
Identifies the Container |
||
Container SCAC code |
Char(6) |
N/A |
Customs defined id for the container. Validated against SCAC table |
||
Delivery Date |
Char(8) |
N/A |
YYYYMMDD format |
||
Seal id |
Char(15) |
N/A |
Customs defined id for the container's seal |
||
Freight Type |
Char(6) |
N/A |
Code that identifies the container type. Validated against the FREIGHT_TYPE table |
||
Freight Size |
Char(6) |
N/A |
Code that identifies the container size. Validated against the FREIGHT_SIZE table |
||
In Transit No. |
Char(15) |
N/A |
External transit number |
||
In Transit Date |
Char(8) |
N/A |
YYYYMMDD format |
||
BL/AWB id |
Char(30) |
N/A |
Identifies the Bill of Lading or Air Way Bill |
||
Candidate Ind |
Char(1) |
Defaulted to 'N' |
Identifies a complete Transportation record. Valid values are ‘Y' and ‘N' |
||
DPOIT |
Record descriptor |
Char(5) |
DPOIT |
Order/Item detail info |
|
Line id |
Number(10) |
N/A |
Unique file line id |
||
ACD_Code |
Char(1) |
N/A |
Determines which process to perform ‘A'dd, ‘C'hange, ‘D'elete. |
||
Rush Ind |
Char(1) |
Defaulted to 'N' |
Identifies whether or not the item should be on a ‘Rush' delivery. Valid values are ‘Y' and ‘N' |
||
Order number |
Number(8) |
N/A |
Merchandising order number |
||
Item |
Char(25) |
N/A |
Merchandising Item number |
||
Invoice id |
Char(30) |
N/A |
Identifies the Commercial Invoice |
||
Invoice date |
Char(8) |
N/A |
YYYYMMDD format |
||
Currency Code |
Char(3) |
N/A |
Currency that the Currency Amount is reported in. Validated against CURRENCIES table. |
||
Exchange Rate |
Char (20) |
N/A |
The exchange rate back to the primary currency (10 implied decimals) |
||
Invoice amt |
Char (20) |
N/A |
Invoice amt*10000 (with 4 implied decimal places), amount charged by supplier for the PO/Item |
||
Origin Country id |
Char(3) |
N/A |
Identifies where the PO/Item was made |
||
Consolidation Country id |
Char(3) |
N/A |
Identifies where the PO/Items were consolidated |
||
Export Country id |
Char(3) |
N/A |
Identifies where the PO/Items where shipped from |
||
Status |
Char(6) |
N/A |
Identifies the PO/Item status. Valid values are found in the TRCO Code Type on CODE_DETAIL |
||
Receipt ID |
Char(30) |
N/A |
Identifies the external receipt number |
||
FCR id |
Char(15) |
N/A |
Identifies the Freight Cargo Receipt id |
||
FCR date |
Char(8) |
N/A |
YYYYMMDD format |
||
Packing Method |
Char(6) |
N/A |
Identifies the Packing Type (Hanging or Flat). Valid values are ‘HANG' or ‘FLAT' |
||
Lot Number |
Char(15) |
N/A |
Identifies the Lot Number of the PO/Item |
||
Item Qty |
Number(12) |
N/A |
Item Qty*10000(with 4 implied decimals), qty of Items |
||
Item QTY UOM |
Char(4) |
N/A |
Identifies the UOM associated with the item quantity |
||
Carton QTY |
Number(12) |
N/A |
Carton QTY*10000 (with 4 implied decimals), qty of Cartons |
||
Carton QTY UOM |
Char(4) |
N/A |
Identifies the UOM associated with the carton quantity |
||
Gross WT |
Number(12) |
N/A |
Gross WT*10000 (with 4 implied decimals), Gross weight |
||
Gross WT UOM |
Char(4) |
N/A |
Identifies the UOM associated with the gross weight |
||
Net WT |
Number(12) |
N/A |
Net WT*10000 (with 4 implied decimals), Net Weight |
||
Net WT UOM |
Char(4) |
N/A |
Identifies the UOM associated with the net weight |
||
Cubic |
Number(12) |
N/A |
Cubic*10000 (with 4 implied decimals), cubic size |
||
Cubic UOM |
Char(4) |
N/A |
Identifies the UOM associated with the cubic size |
||
Comments |
Char(256) |
N/A |
User Comments |
||
FTAIL |
Record type |
Char(5) |
FTAIL |
N/A |
|
Line id |
Number(10) |
N/A |
Unique file line id |
||
No. of lines |
Number(10) |
N/A |
Total number of transaction lines in file (not including FHEAD and FTAIL) |
Stock Counts
Merchandising subscribes to data related to stock counts from stores, warehouses, and third-party counters.
The following scheduled inbound integrations are included in this functional area:
For more on stock count processing, see Merchandising Operations Guide – Volume 1.
Conversion of Warehouse Stock Count Results File (lifstkup)
Module Name |
lifstkup.pc |
Description |
Conversion of WMS Stock Count Results File |
Functional Area |
Stock Counts |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS150 |
Wrapper Script |
batch_lifstkup.ksh |
Design Overview
The Stock Upload Conversion batch is used when WMS sends count information to Merchandising. This batch converts the inventory balance upload file into the format supported by the Stock Count Upload process.
Restart/Recovery
Oracle Retail standard file-based restart/recovery is used. The commit max counter field should be set to prevent excessive rollback space usage, and to reduce the overhead of file I/O. The recommended commit counter setting is 1000 records (subject to change based on implementation).
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000172 (input from WMS) IntCon000102 (output for Merchandising stockcountupload) |
Input File Layout
Table 6-49 Input File Layout
Field Name | Field Type | Description |
---|---|---|
DC_DEST_ID |
11 – Number (10) + 1 for trailing space |
Unique identifier for the warehouse |
TRANSACTION_DATE |
15 – Date (14) + 1 for trailing space |
Date on which the transaction occurred |
ITEM_ID |
26 - Varchar2 (25) + 1 for trailing space |
Uniquely identifies the item on the count |
AVAILABLE_QTY |
15 – Number (12) + 1 for leading sign and + 1 for decimal and + 1 for trailing space |
Units available for distribution |
DISTRIBUTED_QTY |
14 – Number (12) + 1 for decimal and + 1 for trailing space |
Units distributed include: Units distributed but not yet picked, units picked but not yet manifested, units manifested but not yet shipped |
RECEIVED_QTY |
15 - Number (12) + 1 for leading sign and + 1 for decimal and + 1 for trailing space |
Units received but not put away |
TOTAL_QTY |
14 – Number (12,4) + 1 for decimal and + 1 for trailing space |
Sum of all units that physically exist: container status of: I, D, M, R, T, X |
AVAILABLE_WEIGHT |
15 – Number (12,4) + 1 for leading sign + 1 for decimal + 1 for trailing space |
Weight available for distribution of catch weight items |
RECEIVED_WEIGHT |
14 – Number (12,4) + 1 for decimal + 1 for trailing space |
Weight received but not put away for catch weight items |
DISTRIBUTED_WEIGHT |
14 – Number (12,4) + 1 for decimal + 1 for trailing space |
Weight distributed includes: weight distributed but not yet picked, weight picked but not yet manifested, weight manifested but not yet shipped (value only catch weight items) |
TOTAL_WEIGHT |
13 – Number (12,4) + 1 for decimal |
Sum of all weight that physically exist: container status of: I, D, M, R, T, X. For catch weight items |
Output File Layout
Table 6-50 Output File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
file type record descriptor |
Char (5) |
FHEAD |
Describes the file line type |
file line identifier |
Number (10) |
0000000001 |
ID of current line being processed |
|
file type |
Char (4) |
‘STKU' |
Identifies the file type |
|
stocktake_date |
Date (14) |
N/A |
The date on which the count occurred, formatted as YYYYMMDDHH24MISS |
|
file create date |
Date (14) |
N/A |
Date on which the file was created, formatted as YYYYMMDDHH24MISS |
|
cycle count |
Number (8) |
N/A |
stake_head.cycle_count |
|
Location type |
Char (1) |
‘W' |
Will always be ‘W', as this process is only executed for warehouse locations |
|
location |
Number(10) |
N/A |
Indicates the number of the physical warehouse where the count occurred |
|
FDETL |
file type record descriptor |
Char(5) |
FDETL |
Identifies the file line type |
file line identifier |
Number(10) |
N/A |
ID of current line being processed, internally incremented |
|
Item type |
Char(3) |
‘ITM' |
Indicates the type of item that was counted. This will always be ‘ITM', indicating a transaction level item |
|
item value |
Char(25) |
N/A |
The ID of the item that was counted |
|
inventory quantity |
Number(12) |
N/A |
The total quantity or weight of product counted; includes four implied decimal places |
|
location description |
Char(150) |
N/A |
Used by Merchandising to determine the location where the item was counted. This program will always leave as NULL |
|
FTAIL |
file type record descriptor |
Char(5) |
FTAIL |
Identifies the file line type |
file line identifier |
Number(10) |
N/A |
ID of current line being processed, internally incremented |
|
file record count |
Number(10) |
N/A |
Indicates the number of detail records |
Upload Stock Count Results from Stores/Warehouses (stockcountupload.ksh)
Module Name |
stockcountupload.ksh |
Description |
Upload Stock Count Results from Stores/Warehouses |
Functional Area |
Stock Count |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS153 |
Wrapper Script |
batch_stockcountupload.ksh |
Design Overview
The purpose of this module is to upload the contents of the stock count file, which contains the results of a count that occurred in a store or warehouse, to staging tables for further processing.
Input/Out Specification
Integration Type |
Upload in Merchandising |
File Name |
Determined by runtime parameter |
Integratin Contract |
IntCon000102 |
Input File Layout
Table 6-51 Input File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File head descriptor |
Char(5) |
FHEAD |
Describes file line type |
File line identifier |
Number(10) |
0000000001 |
ID of current line being processed |
|
File Type |
Char(4) |
STKU |
Identifies the file type |
|
File create date |
Char(14) |
N/A |
Indicates the date the file was created in YYYYMMDDHH24MISS format |
|
Stock take date |
Char(14) |
N/A |
Date on which stock count will take place in YYYYMMDDHHMISS format |
|
Cycle count |
Number (8) |
N/A |
Unique number to identify the stock count |
|
Location Type |
Char(1) |
N/A |
Indicates the type of location where the count occurred. Valid values are ‘S','W','E'. |
|
Location |
Number(10) |
N/A |
The location where the stock count occurred |
|
Transaction Record |
File record descriptor |
Char(5) |
FDETL |
Describes file line type |
Line Number |
Number(10) |
N/A |
Sequential file line number |
|
Item type |
Char(3) |
N/A |
Indicates the type of item counted – either transaction level (ITM) or reference item (REF) |
|
Item value |
Char(25) |
N/A |
Unique identifier for item that was counted |
|
Inventory quantity |
Number(12) |
N/A |
Total quantity counted for the item at the location formatted with 4 implied decimal places |
|
Location description |
Char(150) |
N/A |
Description of inventory location (such as,. sales floor, backroom) |
|
FTAIL |
File record descriptor |
Char(5) |
FTAIL |
Marks end of file |
File line identifier |
Number(10) |
N/A |
ID of current line being processed, internally incremented |
|
File record count |
Number(10) |
N/A |
Number of detail records |
Franchise
Merchandising subscribes to data related to franchise customers, orders, and returns from order management solutions and other external franchise customer management solutions.
The following scheduled inbound integrations are included in this functional area:
For more on franchise processing, see Merchandising Operations Guide - Volume 1.
Franchise Customer Upload (fcustomerupload)
Module Name |
fcustomerupload.ksh |
Description |
Franchise Customers Upload |
Functional Area |
Franchise Management |
Module Type |
Integration |
Module Technology |
ksh |
Integration Catalog ID |
RMS126 |
Wrapper Script |
rmswrap_shell_in.ksh |
Design Overview
This module uploads franchise customers and customer group details from an external system into Merchandising staging tables. It also performs both technical and business validation of the data sent in the file; for example, it validates that a customer cannot be deleted if a franchise store is associated with it.
Restart/Recovery
The restart recovery is different from the conventional Merchandising batch. There are three points on the batch upload process where you can evaluate the successful load of the data.
-
SQL load - SQL load dumps invalid records that do not meet certain technical requirements (for example:. data type inconsistencies, and so on.). The rejected record is written either to a bad file or to a discard file. The discard file contains records that do not satisfy conditions such as missing or invalid record types. Records with other technical issues are written to the bad file.
Note:
A non-fatal code is returned by the program and a message will be written to the log file if reject files are created.
Action Required: When such conditions exist, you may update either the bad or discard file and attempt to reload using the same files.
-
File-Based Validations - the data from the files are loaded into the staging tables for validation. PL/SQL functions will validate the data in the staging tables to determine if there are any issues with the FHEAD and FTAIL in the file. These kinds of errors are FATAL errors and the batch ends the file processing immediately with return code 255.
Action Required: When this condition exists, you can fix the data upload file and try to reload.
-
Business Validation Level - PL/SQL functions determine if the transactions loaded are valid enough to modify the actual Merchandising tables. Records that do not meet certain technical or business validations are rejected and the information is updated back into the staging table with an appropriate error message and the batch issues a NON-FATAL return code 1.
Action Required: When this condition exists, you can fix the data upload file and try to reload.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000022 |
Input File Layout
Table 6-52 File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Record Descriptor |
Char(5) |
N/A |
Identifies file record type. It should be FHEAD |
File Line ID |
Number(10) |
N/A |
ID of current line being processed by input file |
|
File Type |
Char(5) |
FCUST |
Identifies file as 'Franchise customer upload' |
|
File Create Date |
Date |
SYSDATE |
Date file was written by external system |
|
Transaction Header |
File Record Descriptor |
Char(5) |
N/A |
Identifies transaction record type. It should be THEAD |
File Line ID |
Number(10) |
N/A |
ID of current line being processed by input file |
|
Message Type |
Char(30) |
N/A |
Identifies the action that will be performed on the franchise customer transaction header record. It can be either create (fcustgrpcre) or update (fcustgrpupd) or delete (fcustgrpdel) a franchise customer group |
|
Franchise Customer group ID |
Number(10) |
N/A |
Customer group ID |
|
Franchise Customer group Name |
Char(120) |
N/A |
Customer group name. This field is optional for delete |
|
Transaction Detail |
File Record Descriptor |
Char(5) |
N/A |
Identifies transaction record type. It should be TDETL |
File Line ID |
Number(10) |
N/A |
ID of current line being processed by input file |
|
Message Type |
Char(30) |
N/A |
Identifies the action that will be performed on the franchise customer transaction detail record. It can be either create (fcustcre) or update (fcustupd) or delete (fcustdel) a franchise customer . |
|
Franchise Customer ID |
Number(10) |
N/A |
Customer ID to be processed |
|
Franchise Customer Name |
Char(120) |
N/A |
Customer Name |
|
Credit Ind |
Char(1) |
N |
This field will determine if the franchise customer has good credit. Valid values are Y and N |
|
Auto approve Ind |
Char(1) |
N |
To auto approve the externally uploaded orders and returns. Valid values are Y and N |
|
Transaction Trailer |
File Record Descriptor |
Char(5) |
N/A |
Identifies file record type. It should be TTAIL |
File Line ID |
Number(10) |
N/A |
ID of current line being processed by input file |
|
Transaction Record Count |
Number(10) |
N/A |
Number of TDETL records in this transaction set.(total records between THEAD & TTAIL) |
|
File Trailer |
File Record Descriptor |
Char(5) |
N/A |
Identifies file record type. It should be FTAIL |
File Line ID |
Number(10) |
N/A |
ID of current line being processed by input file. |
|
File Record Counter |
Number(10) |
N/A |
Number of records/transactions processed in current file (total records between FHEAD & FTAIL) |
Franchise Order Upload (wfordupld.ksh)
Module Name |
wfordupld.ksh |
Description |
Franchise Order Upload |
Functional Area |
Franchise Management |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS60 |
Wrapper Script |
batch_wfupload.ksh |
Design Overview
This batch program is used to upload franchisee orders from an external source. These orders will be created with an order type of 'EDI' and will be created for the source type specified in the upload file. If source type is not specified, then the costing location for the item/franchise store will be used. Orders will be created in approved status if the customer is setup for auto approval, assuming that the customer has valid credit.
If the customer fails credit check or if available inventory at the source location is insufficient to fulfill the order, the order will be generated in input status.
Franchise orders from customers that are not identified for 'Auto Approval' are uploaded into Merchandising in input status. These orders will need to be manually approved in Merchandising in order to be considered active.
Restart/Recovery
The restart recovery is different from the conventional Merchandising batch. There are two points on the batch upload process where users can evaluate the successful load of the data.
-
SQL load - At this point, SQL load dumps invalid records that do not meet certain technical requirements (for example:. file layout issues, data type inconsistencies, and so on.). The rejected record is written to a bad file or to a discard file. The discard file contains records that do not satisfy conditions, such as missing or invalid record types. Records with other technical issues are written to the bad file.
Note:
A non-fatal code is returned by the program and a message will be written to the log file if reject files are created.
Action Required: When such conditions exist, you may update either the bad or discard file and attempt to reload using the same files.
-
Business Validation - At this point data from the file(s) are loaded into the staging table(s). PL/SQL functions determine if this loaded data is valid enough to be inserted into the actual Merchandising tables. For records that do not meet certain technical or business validations, the error message will be updated in staging table.
Action Required: When this condition exists, you can fix the data upload file and try to reload the file with valid data.
I/O Specification
Integration Type |
Download from Merchandising |
File Name |
wford*.dat |
Integration Contract |
IntCon000108 |
SQL Loader Input File Layout
Table 6-53 SQL Loder Input File Layout
Record Name | Field Name | Field Type | Null allowed? | Default Value | Description |
---|---|---|---|---|---|
FHEAD |
File head descriptor |
Char(5) |
No |
FHEAD |
Describes file line type. |
Line Number |
Number(10) |
No |
N/A |
Id of the current line being processed. |
|
Customer Id |
Number(10) |
No |
N/A |
Customer ID of the customer requesting the order. |
|
Customer Order Reference number |
Char(20) |
No |
N/A |
A reference field used by the customer for their tracking purposes. |
|
Currency Code |
Char(3) |
No |
N/A |
This is the currency on which the order was transacted. |
|
Default Billing location |
Number(10) |
No |
N/A |
A customer's location where the billing for the entire order is sent. If blank, each location is billed. |
|
Comments |
Char(2000) |
Yes |
N/A |
Any other miscellaneous information relating to the order. |
|
FDETL |
File record descriptor |
Char(5) |
No |
FDETL |
Describes file line type. |
Line Number |
Number(10) |
No |
N/A |
Id of the current line being processed. |
|
Item |
Char(25) |
No |
N/A |
The item on the franchise order. |
|
Customer Location |
Number(10) |
No |
N/A |
The franchise store requesting the order. |
|
Source Loc Type |
Char(2) |
Yes |
N/A |
Source location type for which the franchise order has been created. Valid values are ST - Store, WH - warehouse, or SU - Supplier |
|
Source Location |
Number(10) |
Yes |
N/A |
Source location for which the franchise order has been created. |
|
Requested Quantity |
Number (12,4) |
No |
N/A |
Number of item units being ordered, includes 4 implied decimal places |
|
Unit of Purchase |
Char(3) |
No |
N/A |
Unit of purchase can be the item's standard unit of measure, case, inners or pallets. |
|
Fixed Cost |
Number (20,4) |
Yes |
N/A |
This is cost which will be charged to the customer for the item on the franchise order; value includes 4 implied decimal places. |
|
Need Date |
Char(11) |
No |
N/A |
Date on which the item is needed in the franchise store, with the following format "DD-MON-YYYY' . |
|
Not After Date |
Char(11) |
No |
N/A |
Date after which the item may no longer be accepted for a franchise store, with the following format "DD-MON-YYYY'. |
|
FTAIL |
File record descriptor |
Char(5) |
FTAIL |
Marks end of file. |
|
Line Number |
Number(10) |
N/A |
Id of current line being processed. |
||
File record count |
Number(10) |
N/A |
Number of detail records. |
Franchise Return Upload (wfretupld.ksh)
Module Name |
wfretupld.ksh |
Description |
Franchise Return Upload |
Functional Area |
Franchise Management |
Module Type |
Integration |
Module Technology |
Ksh |
Catalog ID |
RMS154 |
Wrapper Script |
batch_wfupload.ksh |
Design Overview
This batch program is used for uploading franchise returns sent from an external source, such as an external order management application. When returns are uploaded in this manner, the data will be validated and the return will be created in Merchandising. Additionally, an associated franchise return transfer will also be created.
Restart/Recovery
The restart recovery is different from the conventional Merchandising batch. There are two points on the batch upload process where users can evaluate the successful load of the data.
-
SQL load - At this point, SQL load dumps invalid records that do not meet certain technical requirements (for example:. file layout issues, data type inconsistencies, and so on.). The rejected record is written either to a bad file or to a discard file. The discard file contains records that do not satisfy conditions, such as missing or invalid record types. Records with other technical issues are written to the bad file.
Note:
A non-fatal code is returned by the program and a message will be written to the log file if reject files are created. When such conditions exist, you may either update the bad or discard file and attempt to reload using the same files.
-
Business Validation - At this point data from the file(s) are loaded into the staging table(s). PL/SQL functions determine if this loaded data is valid enough to be inserted into the actual Merchandising tables. For all records that do not meet certain technical or business validations, the error message will be updated in staging table. When this condition exists, you can fix the data upload file and try to reload the file with valid data.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
wfreturn*.dat |
Integration Contract |
Intcon000109 |
SQL Loader Input File Layout
The following is the file pattern for the upload file.
Note:
The values are pipe "|" delimited and can optionally be enclosed by " ".
Table 6-54 SQL Loader Input File Layout
Record Name | Field Name | Field Type | Null Allowed? | Default Value | Description |
---|---|---|---|---|---|
FHEAD |
File head descriptor |
Char(5) |
No |
FHEAD |
Describes file line type. |
Line Number |
Number(10) |
No |
Id of the current line being processed. |
||
Customer ID |
Number(10) |
No |
Franchise customer ID of the customer making the return. |
||
Customer Return Reference number |
Char(20) |
No |
A reference field used by the franchise customer for their tracking purposes. |
||
Currency Code |
Char(3) |
No |
This is the return currency. |
||
Comments |
Char(2000) |
Yes |
Any other miscellaneous information related to the return. |
||
FDETL |
File record descriptor |
Char(5) |
No |
FDETL |
Describes file line type. |
Line Number |
Number(10) |
No |
N/A |
Id of the current line being processed. |
|
Item |
Char(25) |
No |
N/A |
The item on the franchise return. |
|
Franchise Order Number |
Number(10) |
No |
N/A |
The franchise order number against which the return is made. |
|
Customer Location |
Number(10) |
No |
N/A |
The franchise location which is making the return. |
|
Return Loc Type |
Char(1) |
No |
N/A |
Return location type for the franchise return; valid values are S - store or W - warehouse. |
|
Return Location |
Number(10) |
No |
N/A |
Return location for the franchise return. |
|
Return Method |
Char(1) |
No |
N/A |
The type of return; valid values are: -R-Return to Store/Warehouse -D-Destroy at site |
|
Unit of measure |
Char(3) |
No |
N/A |
The unit measure of the return quantity. This is assumed to be the items standard UOM. |
|
Return qty |
Number(12,4) |
No |
N/A |
The quantity of item to be returned |
|
Return Reason |
Char(6) |
No |
N/A |
Return reason code; valid values are found on the CODE_DETAIL table where CODE_TYPE is 'RTVR'. |
|
Return unit cost |
Number(20,4) |
Yes |
N/A |
The per unit cost for the return. |
|
Restock Type |
Char(1) |
No |
N/A |
Indicates how the restocking fee will be calculated per item; valid values are S-specific or V-value. |
|
Restock Fee |
Number(20,4) |
No |
N/A |
Unit restocking fee. |
|
FTAIL |
File record descriptor |
Char(5) |
No |
FTAIL |
Marks end of file. |
Line Number |
Number(10) |
No |
N/A |
Id of current line being processed. |
|
File record count |
Number(10) |
No |
N/A |
Number of detail records. |
Upload Cost Buildup Template (fcosttmplupld)
Module Name |
fcosttmplupld.ksh |
Description |
Upload Cost Buildup Template |
Functional Area |
Franchise Management |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS125 |
Wrapper Script |
rmswrap_shell_in.ksh |
Design Overview
This module uploads cost buildup templates and franchise cost relationships used for franchise pricing from an external system into Merchandising staging tables. It also performs both technical and business validation of the data sent in the file; for example, it validates that start and end dates are included for new and updated templates.
Note:
No date format is specified in the input file, as any valid PL/SQL date format can be used.
Restart/Recovery
The restart recovery is different from the conventional Merchandising batch. There are three points on the batch upload process where users can evaluate the successful load of the data.
-
SQL load - SQL load dumps invalid records that do not meet certain technical requirements (for example:. file layout issues, data type inconsistencies, and so on.). The rejected record is written either to a bad file or to a discard file. The discard file contains records that do not satisfy conditions such as missing or invalid record types. Records with other technical issues are written to the bad file.
Note:
A non-fatal code is returned by the program and a message will be written to the log file if reject files are created
Action Required: When such conditions exist, you may update either the bad or discard file and attempt to reload using the same files.
-
Business Validation Level - the data from the files are loaded into the staging tables for validation. PL/SQL functions determine if this loaded data is valid enough to be inserted into the actual Merchandising tables. Records that do not meet certain technical or business validations are rejected and the information is updated back into the staging table with an appropriate error message and the batch issues a NON-FATAL return code.
Action Required: When this condition exists, you can fix the data upload file and try to reload.
-
Chunking validated data - At this point the data from staging tables that have passed business validation are chunked based on the number of valid transactions (cost templates) and max_chunk_size from RMS_PLSQL_BATCH_CONFIG table. If there are no valid transactions to be chunked, batch issues a FATAL return code.
Action Required: When this condition exists, you can fix the data upload file and try to reload.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000021 |
SQL Loader Input File Layout
Table 6-55 SQUL Loader Input File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
N/A |
Identifies file record type. Valid value is FHEAD. |
File Line Identifier |
Number(10) |
N/A |
Sequential file line number |
|
File Type Definition |
Char(5) |
CTMPL |
Identifies file as 'Cost Template Upload' |
|
File Create Date |
Date |
SYSDATE |
Date on which the file was created by external system |
|
Transaction Header |
File Record Descriptor |
Char(5) |
N/A |
Identifies transaction header record type. Valid value is THEAD |
File Line Identifier |
Number(10) |
N/A |
Sequential file line number |
|
Message Type |
Char(30) |
N/A |
Identifies the action that will be performed on the franchise cost template header information that is provided as part of this record It can be either create or update or delete a franchise cost template. Valid message types are: costtmpadd (for additions), costtmpmod (for updates), costtmpdel (for deletions) |
|
Template ID |
Number(10) |
N/A |
Template ID |
|
Template Description |
Char(120) |
N/A |
Template Description |
|
Template Type |
Char(1) |
N/A |
Indicates the type of the template. Valid values are M = Margin then Up-Charge, U = Up-charges, then Margin, R = % of Retail and C = Cost |
|
Percentage |
Number(12,4) |
N/A |
Margin percent or % off Retail value; required if template type is M, U and R types of templates |
|
Cost |
Number(20,4) |
N/A |
Indicates the franchise cost for an item when template type is 'C' This is mandatory and should only be populated if template type is 'C' |
|
Final Cost |
Char(1) |
N/A |
Signifies if the cost is final or acquisition. Valid values are 'Y' or 'N' |
|
Transaction Detail |
File Record Descriptor |
Char(5) |
Identifies transaction detail record type. Valid value is TDETL |
|
File Line Identifier |
Number(10) |
Sequential file line number |
||
Message Type |
Char(30) |
Identifies the action that will be performed on the franchise cost template relationship information that is provided as part of this record. It can be either create or update or delete a cost relationship. Valid values are: costtmpreladd (for additions), costtmprelmod (for updates), costtmpreldel (for deletions) |
||
Dept |
Number(4) |
Department associated with the cost template |
||
Class |
Number(4) |
Class associated with the cost template |
||
Subclass |
Number(4) |
Subclass associated with the cost template |
||
Item |
Char(25) |
Unique number that identifies a valid item associated with the template. Used for template types of 'C' only |
||
Location |
Number(10) |
Franchise Store Number associated with the template |
||
Start Date |
Date |
Date on which a cost template will be effective for the subclass/item and franchise store (required for update and delete of a cost relationship) |
||
End Date |
Date |
Date on which a cost template will expire for a subclass/item and franchise store (required for update and delete of a cost relationship) |
||
New Start Date |
Date |
New Date on which a franchise cost relationship will be effective |
||
New End Date |
Date |
New Date on which a franchise cost relationship will expire |
||
Cost Component ID |
Char(10) |
Unique code which signifies the up-charge cost component when First_Applied is 'U' This should only be populated if First Applied is 'U' |
||
Transaction Trailer |
File Record Descriptor |
Char(5) |
N/A |
Identifies transaction trailer record type. Valid value is TTAIL |
File Line Identifier |
Number(10) |
N/A |
Sequential file line number |
|
Transaction Record Counter |
Number(10) |
N/A |
Number of TDETL records in this transaction set |
|
File Trailer |
File Record Descriptor |
Char(5) |
N/A |
Identifies file trailer record type. Valid value is TTAIL |
File Line Identifier |
Number(10) |
N/A |
Sequential file line number |
|
File Record Counter |
Number(10) |
N/A |
Number of records/transactions processed in current file (only records between FHEAD & FTAIL) |
Upload of Franchise Sales (wfslsupld.ksh)
Module Name |
wfslsupld.ksh |
Description |
Upload of Franchise Sales to Merchandising |
Functional Area |
Franchise Management |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
RMS156 |
Wrapper Script |
batch_wfslsupld.ksh |
Design Overview
Non-stockholding franchise stores in Merchandising are used for retailers who have franchise or other business customers for whom they supply inventory, but don't manage it for them. However, even though inventory information will not be available for these locations in Merchandising, sales information will be able to be uploaded to Merchandising via this process to allow retailers to have better visibility to future demand from these customers. In addition to uploading sales information, this same batch script also purges old non-stockholding franchise store sales records from Merchandising. The script runs in 4 modes:
-
Load - this mode will load the data from the file into a staging table in Merchandising for processing; any errors encountered in validating the data on the upload are also written to the staging table (WFSLSUPLD_STAGING).
-
Process - this mode will process the records in the staging table that did not have errors during load, which includes both writing the data to the WF_NONSTOCKHOLDING_SALES table, as well as purging the processed records from the staging table.
-
Reject - this mode will process the records on the staging table that had errors on initial load. It will create a reject file for each location/report date with the data in error for that location/date. The records will then be deleted from the staging table.
-
Purge - this mode is used to purge old sales records from the WF_NON_STOCKHOLDING_SALES table. Records are deleted based on the system parameter Non-stockholding Franchise Sales History days (WF_NON_STOCK_SALES_HIST_DAYS).
Restart/Recovery
The program can be restarted by running the wfslsupld REJECT mode to create an input file of rejected records and wfslsupld LOAD/PROCESS mode to reprocess the rejected records.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Input file name is a parameter during runtime |
Integration Contract |
IntCon000111 |
Input File Layout
Table 6-56 Input File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record descriptor |
Char(5) |
FHEAD |
Identifies the file record type |
File Line Id |
Char(10) |
N/A |
Sequential file line number |
|
File type definition |
Char(4) |
WFSU |
Identifies the file type |
|
Customer Location |
Number(10) |
N/A |
Store number identifier for the customer location |
|
Report Date |
Char(14) |
N/A |
Report date of the file in YYYYMMDDHHMMSS format |
|
File Create Date |
Char(14) |
N/A |
File Create Date in YYYYMMDDHHMMSS format |
|
FDETL |
Record descriptor |
Char(5) |
FDETL |
Identifies the file record type |
File Line Id |
Char(10) |
N/A |
Sequential file line number |
|
Item |
Char(25) |
N/A |
Item number identifier |
|
Net Sales Quantity |
Number(12) |
N/A |
Sales Quantity with 4 implied decimal places |
|
Net Sales Quantity UOM |
Char(4) |
N/A |
Unit of Measure for the Net Sales Quantity |
|
Total Retail Amount |
Number(20) |
N/A |
Total Retail Amount with 4 implied decimal places |
|
Total Retail Amount Currency |
Char(3) |
N/A |
Currency code for the Total Retail Amount |
|
FTAIL |
Record descriptor |
Char(5) |
FTAIL |
Identifies the file record type |
File Line Id |
Number(10) |
N/A |
Sequential file line number |
|
File Record counter |
Number(10) |
N/A |
Number of records/transactions processed in current file (only records between head & tail) |
Other Inventory
Other inventory related, scheduled inbound integrations include:
External Transaction Data Upload (trandataload.ksh)
Module Name |
trandataload.ksh |
Description |
External Transaction Data Upload |
Functional Area |
Finance |
Module Type |
Integration |
Module Technology |
KSH |
Catalog ID |
RMS 376 |
Wrapper Script |
batch_trandataload.ksh |
Design Overview
This process, along with trandataprocess.ksh, provides a mechanism to write records directly into the TRAN_DATA tables based on a file from an external system. The primary purpose of this functionality is to allow additional costs to be included in stock ledger valuation that cannot be included based on existing Merchandise functionality. Records written to the TRAN_DATA tables do not necessarily have a connection to any Merchandising transaction, and are based on a determination made outside of Merchandising. The records written through this mechanism function exactly the same as records written by normal Merchandising processes. For cost based transactions, the information must be passed at an item/location level. For retail-based transactions, it can be at either an item/location or subclass/location level.
Note:
There is no support for recalculating or impacting unit inventory in Merchandising based on the transactions passed in, and only cost or retail value in the stock ledger is impacted - although the weighted average cost (WAC) may also be impacted if that method of accounting is used in Merchandising
The trandataload script loads the staging table STAGE_EXT_TRAN_DATA table from a flat file using SQL Loader and divides the data into chunks to be processed in parallel threads based on the commit_max_counter and num_threads value on RESTART_CONTROL table.
This script accepts the following input parameters:
-
Database Connect string
-
File load indicator – This indicator is passed as Y if a flat file has to be loaded into the table STAGE_EXT_TRAN_DATA else its N
-
Input file – This is the path of the input file. This is mandatory when File load indicator is Y.
The SQL loading from a flat file is optional in the script. If File load indicator is Y the program validates if the input file exists and logs an error in case the input file does not exist. The SQL Load (sqlldr) process loads the input file using control file - trandataload.ctl into the STAGE_EXT_TRAN_DATA table.
-
A fatal error from sqlldr will halt the process.
-
Rejected records are a non-fatal error and loader will continue processing and create bad file and discard files in case the input file does not match the expected format.
If you chose not to load data into the staging table (File load indicator 'N') then the batch assumes that data has been loaded on the staging table from a different source. After the loading process is complete, the batch divides the data into chunks. If the staging table is empty or all the records are in 'P'rocessed status then the batch logs an appropriate error.
Chunking Logic
-
Dense rank the staged records over Subclass, item and location.
-
Divide the rank value by the commit max counter.
-
Rounding the divided value gives the Chunk ID to which the particular value belongs to.
-
Item can be NULL on the staging table, when NULL consider item to be ‘-999'.
-
This will make sure the records with same subclass value and having item as NULL and NOT NULL are not grouped together in a chunk.
Since records with item have to be processed differently, (WAC recalculation and Variance postings) the batch makes sure that they fall in a different chunk to those records which do not have item value.
The Chunk data is inserted into STAGE_EXT_TRAN_DATA_CHUNK table.
I/O Specification - Input File Specification
This batch uses SQL Loader to populate the staging table. The input file should be in pipe delimited format. Sample record structure would look like:
<item>|<dept>l<class>|<subclass>|<location>|<loc_type>|<tran_date>|<tran_code>|<adj_code>|<units>|<total_cost>|<total_retail>|<ref_no_1>|<ref_no_2>|<GL_ref_no>|<Old_unit_retail>|<New_unit_retail>|<Sales_type>|<VAT_rate>|<av_cost>|<ref_pack_no>|<total_cost_excl_elc>|<WAC_reclculate_ind>|<status>|<create_timestamp>|
File Layout
The table below specifies the detail of each field in the record.
Table 6-57 File Layout
Field Name | Field Type | Default Value | Description / Constraints |
---|---|---|---|
Tran_id |
NUMBER(10,0) |
EXT_TRAN_DATA_SEQUENCE.NEXTVAL |
This value is defaulted to a system generated value by the program. |
Item |
VARCHAR2(25) |
Item is an optional field. Transactions can be uploaded at the Subclass level also. |
|
Dept |
NUMBER(4) |
Mandatory Field |
|
Class |
NUMBER(4) |
Mandatory Field |
|
Subclass |
NUMBER(4) |
Mandatory Field |
|
Loc_type |
VARCHAR2(1) |
Valid values - ‘S’, ‘W’, ‘E’ |
|
Location |
NUMBER(10) |
Mandatory Field |
|
Tran_data |
DATE |
Mandatory Field |
|
Tran_code |
NUMBER(4) |
Mandatory Field |
|
Adj_code |
VARCHAR2(1) |
Valid values – ‘C’, ‘U’, ‘A’ |
|
Units |
NUMBER(12, 4) |
Mandatory Field |
|
Total_cost |
NUMBER(20, 4) |
||
Total_retail |
NUMBER(20, 4) |
||
Ref_no_1 |
NUMBER(10) |
||
Ref_no_2 |
NUMBER(10) |
||
Gl_ref_no |
NUMBER(10) |
||
Old_unit_retail |
NUMBER(20, 4) |
||
New_unit_retail |
NUMBER(20, 4) |
||
Pgm_name |
VARCHAR2(100) |
||
Sales_type |
VARCHAR2(1) |
Valid values – ‘C’, ‘R’, ‘P’ |
|
Vat_rate |
NUMBER(12, 4) |
||
Av_cost |
NUMBER(20, 4) |
||
Ref_pack_no |
VARCHAR2(25) |
||
Total_cost_excl_elc |
NUMBER(20, 4) |
||
Wac_recalculate_ind |
VARCHAR2(1) |
If Weighted Average Cost of the Item-Location should be recalculated after uploading this transaction then this value should be passed as ‘Y’. |
|
Status |
VARCHAR2(1) |
‘N’ |
This value will be defaulted to ‘N’ by this program. It will be updated to ‘P’ once it has been processed else to ‘E’ in case of Error. |
Err_msg |
VARCHAR2(2500) |
||
Create_timestamp |
DATE |
Sysdate |
|
Last_updated_timestamp |
DATE |
Sysdate |
Upload and Process Inventory Reservations from Sales Audit (ordinvupld)
Module Name |
ordinvupld.pc |
Description |
Upload and Process Inventory Reservations from Sales Audit |
Functional Area |
RMS |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS113 |
Wrapper Script |
batch_ordinvupld.ksh |
Design Overview
This batch program processes the input file generated by the Sales Audit Inventory Export batch, which is generated to reserve and un-reserve inventory based on in-store customer orders and layaway. An in-store customer order is one where the customer is purchasing inventory present in the store, but will not take it home immediately. For example, with a large item like a sofa, the customer may pickup at a later time with a larger vehicle. Layaway is when a customer pays for an item over time and only takes the item home once it has been fully paid for. In processing this file, Merchandising updates the quantity of the item/location sent to either add or subtract from the quantity in the Customer Order inventory status type.
Restart/Recovery
The logical unit of work for this batch program is a valid item status transaction at a given store/location. The logical unit of work is defined as a group of these transaction records. The Oracle Retail standard file-based restart/recovery logic is used. Records are committed to the database when the maximum commit counter is reached.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000049 |
Input File Layout
Table 6-58 ordinvupld.pc - Input File
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record descriptor |
Char(5) |
FHEAD |
Identifies the file record type |
File Line Id |
Char(10) |
0000000001 |
Sequential file line number |
|
File type definition |
Char(4) |
ORIN |
Identifies the file type |
|
File Create Date |
Char(14) |
N/A |
File Create Date in YYYYMMDDHHMMSS format |
|
Location |
Number(10) |
N/A |
Store location number |
|
THEAD |
Record descriptor |
Char(5) |
THEAD |
Identifies the file record type |
File Line Id |
Char(10) |
N/A |
Sequential file line number |
|
Transaction Date & Time |
Char(14) |
Transaction Date |
Date and time of the order processed |
|
Transaction Type |
Char(6) |
‘SALE' |
Transaction type code specifies whether the transaction is sale or Return |
|
TDETL |
Record descriptor |
Char(5) |
TDETL |
Identifies the file record type |
File Line Id |
Char(10) |
N/A |
Sequential file line number |
|
Item Type |
Char(3) |
REF or |
Can be REF or ITM |
|
Item |
Char(25) |
ITM |
Id number of the ITM or REF |
|
Item Status |
Char(6) |
LIN - Layaway Initiate LCA - Layaway Cancel LCO - Layaway Complete PVLCO - Post void of Layaway complete ORI - Pickup/delivery Initiate ORC - Pickup/delivery Cancel ORD - Pickup/delivery Complete PVORD - Post void of Pick-up/delivery complete |
Type of transaction |
|
Dept |
Number(4) |
N/A |
Department of item sold or returned |
|
Class |
Number(4) |
N/A |
Class of item sold or returned. |
|
Sub class |
Number(4) |
N/A |
Subclass of item sold or returned |
|
Pack Ind |
Char(1) |
N/A |
Pack indicator of item sold or returned |
|
Quantity Sign |
Chanr(1) |
'P' or 'N' |
Sign of the quantity. |
|
Quantity |
Number(12) |
N/A |
Quantity * 10000 (4 implied decimal places), number of units for the given order (item) status |
|
Selling UOM |
Char(4) |
N/A |
UOM at which this item was sold |
|
Catchweight Ind |
Char(1) |
N/A |
Indicates if the item is a catchweight item. Valid values are Y or NULL |
|
Customer Order number |
Char(48) |
N/A |
Customer Order number |
|
Posting Store |
Number(10) |
Contains the store at which the item reservation/ reservation cancellation should occur in case of cross-store transactions happening at co-located stores. It is expected that this field will be populated only for items that are to be reserved (or have the reservation canceled) at a different store from the one at which the checkout happened. |
||
TTAIL |
File Type Record Descriptor |
Char(5) |
TTAIL |
Identifies file record type |
File Line Identifier |
Number(10) |
Specified by Sales Audit |
ID of current line being processed by input file. |
|
Transaction count |
Number(6) |
Specified by Sales Audit |
Number of TDETL records in this transaction set |
|
FTAIL |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file |
|
File Record Counter |
Number(10) |
N/A |
Number of records/transactions processed in current file (only records between FHEAD & FTAIL) |
Upload Item Availability for Type A & D Contracts from Suppliers (ediupavl)
Module Name |
ediupavl.pc |
Description |
Upload Item Availability for Type A & D Contracts from Suppliers |
Functional Area |
EDI - Contracts |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RMS50 |
Wrapper Script |
rmswrap_in_rej.ksh |
Design Overview
This module runs to upload supplier availability information, which is a list of the items that a supplier has available. This information is used by Merchandising for type A and D contracts which require supplier availability information. The data uploaded is written to the SUP_AVAIL table.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
Determined by runtime parameter |
Integration Contract |
IntCon000016 |
Input File Layout
Table 6-59 ediupavl.pc - File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record descriptor |
Char(5) |
FHEAD |
Describes file line type |
Line number |
Number(10) |
0000000001 |
Sequential file line number |
|
File type |
Char(4) |
SPAV |
N/A |
|
Create date |
Char(14) |
N/A |
File create date in YYYYMMDDHH24 MISS format |
|
FDETL |
Record descriptor |
Char(5) |
FDETL |
Describes file line type |
Line number |
Number(10) |
N/A |
Sequential file line number |
|
Transaction number |
Number(14) |
N/A |
Sequential transaction number |
|
Supplier |
Number(10) |
N/A |
Indicates the supplier for whom the data applies |
|
Item type |
Char(3) |
N/A |
Indicates the type of item contained in the file. Valid types are ‘ITM', ‘UPC', or ‘VPN' |
|
Item id |
Char(25) |
N/A |
Unique ID for the item |
|
Item supplement |
Char(5) |
N/A |
UPC supplement |
|
Available quantity |
Number(12) |
N/A |
Available quantity including 4 implied decimal places |
|
FTAIL |
Record descriptor |
Char(5) |
FTAIL |
Number(10) |
Line number |
Number(10) |
N/A |
Sequential file line number (total # lines in file) |
|
Number of detail records |
Number(10) |
N/A |
Number of FDETL lines in file |
Sales Processing
Merchandising and Sales Audit subscribe to data from point of sale (POS) and order management (OMS) solutions related to sales, returns, customer pick-ups, and so on. Generally, sales are first audited in Sales Audit and then sent to Merchandising for posting and inventory updates. However, customers can choose to bypass Sales Audit if using an external auditing solution or choosing not to audit sales data by sending data directly to Merchandising.
This section has been broken into the following sub-sections:
Sales Audit
The purpose of Sales Audit is to accept transaction data from point-of-sale (POS) and order management (OMS) solutions and move the data through a series of processes that culminate in “clean" data. Data that Sales Audit finds to be inaccurate is brought to the attention of the auditors who can use the features in Sales Audit to correct the exceptions.
For more information on Sales Audit processing see Merchandising Operations Guide Volume 1.
This chapter contains details about the following integration processes used to import data to Sales Audit:
Customer Engagement Promotion Import (CePromoBatch.ksh)
Module Name |
CePromoBatch.ksh |
Description |
Invokes the Customer Engagement Promotion web service to fetch the promotions and saves it to the CE promo tables that will be used by the sagetref module. |
Functional Area |
Sales Audit |
Module Type |
Integration |
Module Technology |
ksh |
Catalog ID |
N/A |
Wrapper Script |
rmswrap_shell.ksh |
Design Overview
The purpose of this script is to call the batch client that will execute the Oracle Retail Customer Engagement (ORCE) Promotion web service.
The values retrieved from the web service will populate the CE_PROMO and CE_PROMO_DEAL. These tables will be used by the Get Reference Data for Sales Audit Import Processing (sagetref) batch.
The list of valid promotions in ORCE will be extracted by using the retrieve promotions method under the Promotion Event Web Service offered by ORCE. This request will return promotion information including the promotion ID. Similarly the promotion component details in ORCE can be retrieved using the retrieve promotion deals method under the Promotion Event Web Service. The information returned through this request will include the deal ID. The data in the CE_PROMO and CE_PROMO_DEAL tables will be extracted into the promotion file format by the sagetref batch and will be used to validate the RTLOG files being imported into Sales Audit.
Key Tables Affected
Table | SELECT | INSERT | UPDATE | DELETE |
---|---|---|---|---|
CE_PROMO |
No |
Yes |
No |
Yes |
CE_PROMO_DEAL |
No |
Yes |
No |
Yes |
Design Assumptions
-
The CE promotion web service URL will be different for each deployment. The URL will be set up during deployment and will become part of the batch environment variables.
-
The ORCE web service is OAUTH enabled. The CePromoBatch.ksh will retrieve the necessary authentication through a REST API service call.
Import of Unaudited Transaction Data from POS to Sales Audit (saimptlog/saimptlogi)
Module Name |
saimptlog.c saimptlogi.c |
Description |
Import of Unaudited Transaction data from POS to Sales Audit |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RSA11a RSA11b |
Wrapper Script |
batch_saimptlogi.ksh |
Design Overview
Importing POS and Order Management System (OMS) data to Sales Audit is a five or six-step process depending on whether saimptlogi or saimptlog is used. Saimptlog produces SQL*Loader files while saimptlogi does inserts directly into the database. Saimptlogi is meant for use in a trickle feed environment.
To import POS and OMS data, perform the following:
-
SAGETREF must be run to generate the current reference files:
-
Items
-
Wastage
-
Sub-transaction level items
-
Primary variant relationships
-
Variable weight PLU
-
Store business day
-
Code types
-
Error codes
-
Store POS
-
Tender type
-
Merchant code types
-
Partner vendor
-
Supplier vendors
-
Employee ids
-
Banner ids
-
Currency File
-
Promotions File
-
Warehouse File
-
Inventory Status File
These files are all used as input to SAIMPTLOG and SAIMPTLOGI. Because SAIMPTLOG and SAIMPTLOGI can be threaded, this boosts performance by limiting interaction with the database.
-
-
Either SAIMPTLOG or SAIMPTLOGI must be run against each file. The files are the transaction log files in an Oracle Retail compatible format called RTLOG. The retailer is responsible for converting its transaction logs to RTLOGs. Both SAIMPTLOG and SAIMPTLOGI create a write lock, depending on the locking level specified in the Sales Audit System Options. It will create a write lock for a store/day combination on Sales Audit tables if the locking level indicated is Store Day. Otherwise, it will create a write lock for a transaction on Sales Audit tables if the locking level indicated is transaction. It will then set the data_status to loading until SAIMPTLOGFIN is executed. SAIMPTLOG generates distinct SQL*Loader files for that store/day for the sa_tran_head, sa_tran_head_attrib, sa_tran_item, sa_tran_item_attrib, sa_tran_disc, sa_tran_disc_attrib, sa_tran_igtax (item Level Tax not VAT), sa_tran_igtax_attrib (item Level Tax Attribute not VAT Attribute), sa_tran_payment (Payment details), sa_tran_tax, sa_tran_tax_attrib, sa_tran_tender, sa_tran_tender_attrib, sa_error, sa_customer, sa_cust_attrib, sa_tran_write_lock and sa_missing_tran tables, whereas SAIMPTLOGI inserts data to the database directly. Both produce an Oracle Retail formatted voucher file for processing.
-
SQL*Loader is executed to load the transaction tables from the files created by SAIMPTLOG. The store/day SQL*Loader files can be concatenated into a single file per table to optimize load times. Alternatively, multiple SQL*Loader files can be used as input to SQL*Loader. SQL*Loader may not be run in parallel with itself when loading a table. Header data (primary keys) must be loaded before ancillary data (foreign keys). This means that the sa_tran_head table must be loaded first, sa_tran_item before sa_tran_disc, and sa_customer before sa_cust_attrib. The main tables of each attribute table must be loaded first, before its attributes. This means that the sa_tran_item must be loaded first, before sa_tran_item_attrib; the sa_tran_disc must be loaded first, before sa_tran_disc_attrib; the sa_tran_igtax must be loaded first, before sa_tran_igtax_attrib; the sa_tran_tender must be loaded first, before sa_tran_tender_attrib; the sa_tran_tax must be loaded first, before sa_tran_tax_attrib. The remaining tables may be loaded in parallel.
-
SAVOUCH is executed to load each of the voucher files in Oracle Retail standard formatted. SAVOUCH may not be multi-threaded.
-
SAIMPTLOGFIN is executed to populate the sa_balance_group table, cancel post voided transactions and vouchers, validate missing transactions, and to mark the import as either partially or fully complete loaded. SAIMPTLOGFIN may not be multi-threaded.
Note:
This design covers only Steps 2 and 3.
File Upload Error Handling
For each RTLOG file, a record is written to the FILE_UPLOAD_STATUS table. In cases where a non-fatal error occurs after validating a record in the file, the error is written to the error file and a corresponding record is also inserted to the FILE_UPLOAD_ERRORS table.
I/O Specification
Integration Type |
Upload to Sales Audit |
File Name |
Determined by runtime parameter |
Integration Contract |
Inputs from sagetref.pc: IntCon000113 (itemfile) IntCon000114 (wastefile) IntCon000115 (refitemfile) IntCon000116 (primvariantfile) IntCon000117 (varupcfile) IntCon000118 (storedayfile) IntCon000119 (promfile) IntCon000120 (codesfile) IntCon000121 (errorfile) IntCon000122 (storeposfile) IntCon000123 (tendertypefile) IntCon000124 (merchcodesfile) IntCon000125 (partnerfile) IntCon000126 (supplierfile) IntCon000127 (employeefile) IntCon000128 (bannerfile) IntCon000129 (promfile) IntCon000130 (whfile) IntCon000131 (invstatusfile) Inputs from POS: IntCon000048 (RTLOG) |
Outputs (if using saimptlog SQL Loader Option note that saimptlogi inserts directly into Sales Audit tables and does not create these output files) IntCon000160 (SAVO) IntCon000161 (satdisc.ctl) IntCon000162 (saigtax.ctl) IntCon000163 (sacust.ctl) IntCon000164 (sathead.ctl) IntCon000165 (satitem.ctl) IntCon000166 (sattend.ctl) IntCon000167 (satypmt.ctl) IntCon000168 (samisstr.ctl) IntCon000169 (sattax.ctl) IntCon000170 (sacustatt.ctl) IntCon000171 (saerror.ctl) IntCon000172 (sathatt.ctl) IntCon000173 (saitatt.ctl) IntCon000174 (saidatt.ctl) IntCon000175 (saixatt.ctl) IntCon000176 (satxatt.ctl) IntCon000177 (sattatt.ctl) (satwritelock.ctl) |
The input files for this program are reference files generated by sagetref.pc and RTLOGs. Refer to the details for the sagetref.pc program for the input file specifications.
Output File Layout
Table 6-60 File Name: SAVO (Sales Audit Voucher File)
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
File Type Record Descriptor |
Char(5) |
FHEAD |
File type Record descriptor |
SA File Line No |
Char(10) |
N/A |
Sales Audit File Line number |
|
Translator Id |
Char(5) |
SAVO |
Identifies transaction type |
|
Sys Date |
Char(14) |
N/A |
System date in YYYYMMDDHHMMSS format |
|
Is business date |
Char(8) |
N/A |
Business date in YYYYMMDD format |
|
FDETL |
Record Descriptor |
Char(5) |
FDETL |
File Type Record descriptor |
SA File Line No |
Number(10) |
N/A |
Sales Audit File Line number |
|
Voucher seq Number |
Number(20) |
N/A |
Unique identifier for an entry to sa_voucher table |
|
Voucher No |
Char(25) |
N/A |
Voucher Number |
|
Voucher Type |
Number(6) |
N/A |
Voucher Type |
|
Assigned Business Date |
Char(8) |
N/A |
Business date in YYYYMMDD format |
|
Assigned Store |
Number(10) |
N/A |
Store to which the voucher is assigned |
|
Issuing Date |
Char(8) |
N/A |
Date this document was issued |
|
Issuing store |
Number(10) |
N/A |
Store this document was issued from |
|
Issuing POS Register |
Char(5) |
N/A |
Issuing Point Of Sale register |
|
Issuing Cashier |
Char(10) |
N/A |
Issuing cashier |
|
Issued Tran Seq No. |
Number(20) |
N/A |
Transaction sequence number |
|
Issued item seq number |
Number(4) |
N/A |
Will hold the item sequence of the item when the voucher is sold as an item (gift voucher) |
|
Issued Tender Seq No. |
Number(4) |
N/A |
Tender sequence number |
|
Issued Amount |
Number(20) |
N/A |
Issued Amount * 10000 (4 implied digits) |
|
Issued Cust Name |
Char(120) |
N/A |
Issued customer name |
|
Issued Customer Addr1 |
Char(240) |
N/A |
Issued customer addr1 |
|
Issued Customer Addr2 |
Char(240) |
N/A |
Issued customer addr 2 |
|
Issued Customer City |
Char(120) |
N/A |
City of the customer, the voucher is issued |
|
Issued Customer State |
Char(3) |
N/A |
State of the customer |
|
Issued Customer Postal Code |
Char(30) |
N/A |
Postal address of the customer |
|
Issued Customer Country |
Char(3) |
N/A |
Country of the customer the voucher was issued |
|
Recipient Name |
Char(120) |
N/A |
Name of the intended recipient |
|
Recipient State |
Char(3) |
N/A |
The state of the intended recipient |
|
Recipient Country |
Char(3) |
N/A |
The country of the intended recipient |
|
Redemption Date |
Char(8) |
N/A |
Date the voucher was redeemed |
|
Redemption Store |
Number(10) |
N/A |
Store, the voucher was redeemed at |
|
Redemption Register |
Char(5) |
N/A |
Register, the document was redeemed at |
|
Redemption cashier |
Char(10) |
N/A |
Cashier redeeming the voucher |
|
Redemption tran seq number |
Number(20) |
N/A |
Transaction number when the document was redeemed |
|
Redemption Tender seq number |
Number(4) |
N/A |
This column will hold the tender sequence of the tender within the transaction when a voucher is redeemed as tender |
|
Redemption Amount |
Number(20) |
N/A |
Amount the document was redeemed for*10000 (4 implied decimal places) |
|
Expiry Date |
Char(8) |
N/A |
Expiry date |
|
Status |
Char(1) |
N/A |
Indicator showing the document's status, issued or redeemed. Valid values = I - Issued, R - Redeemed |
|
Comments |
Char(2000) |
N/A |
Comments |
|
FTAIL |
Record Descriptor |
Char(5) |
FTAIL |
File Type Record descriptor |
SA File Line No. |
Number(10) |
N/A |
Sales Audit File Line Number |
|
#lines |
Number(10) |
N/A |
Total number of transaction lines in file (not including FHEAD and FTAIL) |
Control Files
Table 6-61 File Name: Satdisc.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_DISC |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
N/A |
ITEM_SEQ_NO |
Integer external |
4 |
21:24 |
N/A |
|
DISCOUNT_SEQ_NO |
Integer external |
4 |
25:28 |
N/A |
|
RMS_PROMO_TYPE |
Char |
6 |
29:34 |
N/A |
|
PROMOTION |
Integer external |
10 |
35:44 |
N/A |
|
DISC_TYPE |
Char |
6 |
45:50 |
N/A |
|
COUPON_NO |
Char |
40 |
51:90 |
N/A |
|
COUPON_REF_NO |
Char |
16 |
91:106 |
N/A |
|
QTY |
Decimal external |
14 |
107:120 |
N/A |
|
UNIT_DISCOUNT_AMT |
Decimal external |
21 |
121: 141 |
N/A |
|
STANDARD_QTY |
Decimal external |
14 |
142:155 |
N/A |
|
STANDARD_UNIT_DISC_AMT |
Decimal external |
21 |
156:176 |
N/A |
|
REF_NO13 |
Char |
30 |
177:206 |
N/A |
|
REF_NO14 |
Char |
30 |
207:236 |
N/A |
|
REF_NO15 |
Char |
30 |
237:266 |
N/A |
|
REF_NO16 |
Char |
30 |
267:296 |
N/A |
|
ERROR_IND |
Char |
1 |
297:297 |
N/A |
|
CATCHWEIGHT_IND |
Char |
1 |
298:298 |
N/A |
|
UOM_QUANTITY |
Integer external |
12 |
299:310 |
N/A |
|
PROMO_COMP |
Integer external |
10 |
311:320 |
This field maps to the OFFER_ID field from Pricing |
|
STORE |
Integer external |
10 |
321:330 |
N/A |
|
DAY |
Integer external |
3 |
331:333 |
N/A |
Table 6-62 File Name: Saigtax.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_IGTAX |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
N/A |
ITEM_SEQ_NO |
Integer external |
4 |
21:24 |
N/A |
|
IGTAX_SEQ_NO |
Integer external |
4 |
25:28 |
N/A |
|
TAX_AUTHORITY |
Char |
10 |
29:38 |
N/A |
|
IGTAX_CODE |
Char |
6 |
39:44 |
N/A |
|
IGTAX_RATE |
Decimal external |
11 |
45:65 |
N/A |
|
TOTAL_IGTAX_AMT |
Decimal external |
22 |
66:87 |
N/A |
|
STANDARD_QTY |
Decimal external |
14 |
88:101 |
N/A |
|
STANDARD_UNIT_IGTAX_AMT |
Decimal external |
21 |
102:122 |
N/A |
|
ERROR_IND |
Char |
1 |
123:123 |
N/A |
|
REF_NO_21 |
Char |
30 |
124:153 |
N/A |
|
REF_NO_22 |
Char |
30 |
154:183 |
N/A |
|
REF_NO_23 |
Char |
30 |
184:213 |
N/A |
|
REF_NO_24 |
Char |
30 |
214:243 |
N/A |
|
STORE |
Integer external |
10 |
244:253 |
N/A |
|
DAY |
Integer external |
3 |
254:256 |
N/A |
|
TAX_CALC_TYPE |
Char |
6 |
257:262 |
N/A |
Table 6-63 File Name: Sacust.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_CUSTOMER |
TRAN_SEQ_NO |
Integer external Date |
20 |
1 :20 |
N/A |
CUST_ID |
Char |
16 |
21 :36 |
N/A |
|
CUST_ID_TYPE |
Char |
6 |
37 :42 |
N/A |
|
NAME |
Char |
240 |
43 :162 |
N/A |
|
ADDR1 |
Char |
240 |
163:402 |
N/A |
|
ADDR2 |
Char |
240 |
403:642 |
N/A |
|
CITY |
Char |
240 |
643:762 |
N/A |
|
STATE |
Char |
3 |
763:765 |
N/A |
|
POSTAL_CODE |
Char |
30 |
766:795 |
N/A |
|
COUNTRY |
Char |
3 |
796:798 |
N/A |
|
HOME_PHONE |
Char |
20 |
799:818 |
N/A |
|
WORK_PHONE |
Char |
20 |
819:838 |
N/A |
|
E_MAIL |
Char |
100 |
839:938 |
N/A |
|
BIRTHDATE |
Date |
8 |
939:946 |
Format is YYYYMMDD |
|
STORE |
Integer external |
10 |
947:956 |
N/A |
|
DAY |
Integer external |
3 |
957:959 |
N/A |
Table 6-64 File Name: Sathead.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_HEAD |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
N/A |
REV_NO |
Integer external |
3 |
21:23 |
N/A |
|
STORE_DAY_SEQ_NO |
Integer external |
20 |
24:43 |
N/A |
|
TRAN_DATETIME |
Date |
14 |
44:57 |
Format is YYYYMM DDHH24MI SS |
|
REGISTER |
Char |
5 |
58:62 |
N/A |
|
TRAN_NO |
Integer external |
10 |
63:72 |
N/A |
|
CASHIER |
Char |
10 |
73:82 |
N/A |
|
SALESPERSON |
Char |
10 |
83:92 |
N/A |
|
TRAN_TYPE |
Char |
6 |
93:98 |
N/A |
|
SUB_TRAN_TYPE |
Char |
6 |
99:104 |
N/A |
|
ORIG_TRAN_NO |
Integer external |
10 |
105:114 |
N/A |
|
ORIG_REG_NO |
Char |
5 |
115:119 |
N/A |
|
REF_NO1 |
Char |
30 |
120:149 |
N/A |
|
REF_NO2 |
Char |
30 |
150:179 |
N/A |
|
REF_NO3 |
Char |
30 |
180:209 |
N/A |
|
REF_NO4 |
Char |
30 |
210:239 |
N/A |
|
REASON_CODE |
Char |
6 |
240:245 |
N/A |
|
VENDOR_NO |
Char |
10 |
246:255 |
N/A |
|
VENDOR_INVC_NO |
Char |
30 |
256:285 |
N/A |
|
PAYMENT_REF_NO |
Char |
16 |
286:301 |
N/A |
|
PROOF_OF_DELIVERY_NO |
Char |
30 |
302:331 |
N/A |
|
STATUS |
Char |
6 |
332:337 |
N/A |
|
VALUE |
Char |
22 |
338:359 |
Includes an optional negative sign and a decimal point |
|
POS_TRAN_IND |
Char |
1 |
360:360 |
N/A |
|
UPDATE_ID |
Char |
30 |
361:390 |
N/A |
|
UPDATE_DATETIME |
Date |
14 |
391:404 |
Format is YYYYMM DDHH24MI SS |
|
ERROR_IND |
Char |
1 |
405:405 |
N/A |
|
BANNER_NO |
Integer external |
4 |
406:409 |
N/A |
|
ROUND_AMT |
Integer external |
22 |
410:431 |
N/A |
|
ROUNDED_OFF_AMT |
Integer external |
22 |
432:453 |
N/A |
|
CREDIT_PROMOTION_ID |
Integer external |
10 |
454:463 |
N/A |
|
REF_NO25 |
Char |
30 |
464:493 |
N/A |
|
REF_NO26 |
Char |
30 |
494:523 |
N/A |
|
REF_NO27 |
Char |
30 |
524:553 |
N/A |
|
STORE |
Integer external |
10 |
554:563 |
N/A |
|
DAY |
Integer external |
3 |
564:566 |
N/A |
|
RTLOG_ORIG_SYS |
Char |
3 |
567:569 |
N/A |
|
TRAN_PROCESS_SYS |
Char |
3 |
570:572 |
N/A |
|
TRAN_DATE |
Date |
8 |
573:580 |
N/A |
|
REF_NO28 |
Char |
30 |
581:610 |
N/A |
|
REF_NO29 |
Char |
30 |
611:640 |
N/A |
|
REF_NO30 |
Char |
30 |
641:670 |
N/A |
|
REF_NO31 |
Char |
30 |
671:700 |
N/A |
Table 6-65 File Name: Satitem.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_ITEM |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
N/A |
ITEM_SEQ_NO |
Integer external |
4 |
21:24 |
N/A |
|
ITEM_STATUS |
Char |
6 |
25:30 |
N/A |
|
ITEM_TYPE |
Char |
6 |
31:36 |
N/A |
|
ITEM |
Char |
25 |
37:61 |
N/A |
|
REF_ITEM |
Char |
25 |
62:86 |
N/A |
|
NON_MERCH_ITEM |
Char |
25 |
87:111 |
N/A |
|
VOUCHER_NO |
Char |
25 |
112:136 |
N/A |
|
DEPT |
Integer external |
4 |
137:140 |
N/A |
|
CLASS |
Integer external |
4 |
141:144 |
N/A |
|
SUBCLASS |
Integer external |
4 |
145:148 |
N/A |
|
QTY |
Decimal external |
14 |
149:162 |
Includes an optional negative sign and a decimal point |
|
UNIT_RETAIL |
Decimal external |
21 |
163:183 |
Includes a decimal point |
|
UNIT_RETAIL_VAT_INCL |
Char |
1 |
184:184 |
Indicates whether unit retail includes or excludes VAT |
|
SELLING UOM |
Char |
4 |
185:188 |
N/A |
|
OVERRIDE_REASON |
Char |
6 |
189:194 |
N/A |
|
ORIG_UNIT_RETAIL |
Decimal external |
21 |
195:215 |
Includes a decimal point |
|
STANDARD_ORIG_UNIT_RETAIL |
Decimal external |
21 |
216:236 |
N/A |
|
TAX_IND |
Char |
1 |
237:237 |
N/A |
|
ITEM_SWIPED_IND |
Char |
1 |
238:238 |
N/A |
|
ERROR_IND |
Char |
1 |
239:239 |
N/A |
|
DROP_SHIP_IND |
Char |
1 |
240:240 |
N/A |
|
WASTE_TYPE |
Char |
6 |
241:246 |
N/A |
|
WASTE_PCT |
Decimal external |
12 |
247:258 |
Includes a decimal point |
|
PUMP |
Char |
8 |
259:266 |
N/A |
|
RETURN_REASON_CODE |
Char |
6 |
267:272 |
N/A |
|
SALESPERSON |
Char |
10 |
273:282 |
N/A |
|
EXPIRATION_DATE |
Date |
8 |
283:290 |
Format is YYYYMMDD |
|
STANDARD_QTY |
Decimal external |
14 |
291:304 |
Includes an optional negative sign and a decimal point |
|
STANDARD_UNIT_RETAIL |
Decimal external |
21 |
305:325 |
Includes a decimal point |
|
STANDARD_UOM |
Char |
4 |
326:329 |
N/A |
|
REF_NO5 |
Char |
30 |
330:359 |
N/A |
|
REF_NO6 |
Char |
30 |
360:389 |
N/A |
|
REF_NO7 |
Char |
30 |
390:419 |
N/A |
|
REF_NO8 |
Char |
30 |
420:449 |
N/A |
|
CATCHWEIGHT_IND |
Char |
1 |
450:450 |
N/A |
|
SELLING_ITEM |
Char |
25 |
451:475 |
N/A |
|
CUSTOMER_ORDER_LINE_NO |
Integer external |
6 |
476:481 |
N/A |
|
MEDIA_ID |
Integer external |
10 |
482:491 |
N/A |
|
UOM_QUANTITY |
Integer external |
12 |
492:503 |
N/A |
|
TOTAL_IGTAX_AMT |
Decimal external |
504:524 |
N/A |
||
UNIQUE_ID |
Char |
25 |
525:652 |
N/A |
|
STORE |
Integer external |
10 |
653:662 |
N/A |
|
DAY |
Integer external |
3 |
663:665 |
N/A |
|
CUST_ORDER_NO |
Char |
48 |
666:713 |
N/A |
|
CUST_ORDER_DATE |
Date |
14 |
714:727 |
Format is YYYYMMDDHH24MISS |
|
FULFILL_ORDER_NO |
Char |
48 |
728:775 |
N/A |
|
NO_INV_RET_IND |
Char |
1 |
776:776 |
N/A |
|
SALES_TYPE |
Char |
1 |
777:777 |
N/A |
|
RETURN_WH |
Integer external |
10 |
778:787 |
N/A |
|
RETURN_DISPOSITION |
Char |
10 |
788:797 |
N/A |
|
ORIG_STORE |
Integer external |
10 |
798:807 |
N/A |
|
ORIG_TRAN_NO |
Integer external |
10 |
808:817 |
N/A |
|
FULFILLMENT_LOC_TYPE |
Char |
2 |
818:820 |
N/A |
|
FULFILLMENT_LOC |
Integer external |
10 |
821:830 |
N/A |
|
POSTING_STORE |
Integer external |
10 |
830:839 |
N/A |
Table 6-66 File Name: Sattend.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_TENDER |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
N/A |
TENDER_SEQ_NO |
Integer external |
4 |
21:24 |
N/A |
|
TENDER_TYPE_GROUP |
Char |
6 |
25:30 |
N/A |
|
TENDER_TYPE_ID |
Integer external |
6 |
31:36 |
N/A |
|
TENDER_AMT |
Decimal external |
22 |
37:58 |
Includes an optional negative sign and a decimal point. |
|
CC_NO |
Integer external |
40 |
59:98 |
N/A |
|
CC_EXP_DATE |
Date |
8 |
99:106 |
FORMAT IS YYYYMMDD |
|
CC_AUTH_NO |
Char |
16 |
107:122 |
N/A |
|
CC_AUTH_SRC |
Char |
6 |
123:128 |
N/A |
|
CC_ENTRY_MODE |
Char |
6 |
129:134 |
N/A |
|
CC_CARDHOLDER_VERF |
Char |
6 |
135:140 |
N/A |
|
CC_TERM_ID |
Char |
5 |
141:145 |
N/A |
|
CC_SPEC_COND |
Char |
6 |
146:151 |
N/A |
|
CC_TOKEN |
Char |
40 |
152:191 |
N/A |
|
VOUCHER_NO |
Char |
25 |
192:216 |
N/A |
|
COUPON_NO |
Char |
40 |
217:256 |
N/A |
|
COUPON_REF_NO |
Char |
16 |
257:272 |
N/A |
|
CHECK_ACCT_NO |
Char |
30 |
273:302 |
N/A |
|
CHECK_NO |
Integer external |
10 |
303:312 |
N/A |
|
IDENTI_METHOD |
Char |
6 |
313:318 |
N/A |
|
IDENTI_ID |
Char |
40 |
319:358 |
N/A |
|
ORIG_CURRENCY |
Char |
3 |
359:361 |
N/A |
|
ORIG_CURR_AMT |
Decimal external |
22 |
362:383 |
N/A |
|
REF_NO9 |
Char |
30 |
384:413 |
N/A |
|
REF_NO10 |
Char |
30 |
414:443 |
N/A |
|
REF_NO11 |
Char |
30 |
444:473 |
N/A |
|
REF_NO12 |
Char |
30 |
474:503 |
N/A |
|
ERROR_IND |
Char |
1 |
504:504 |
N/A |
|
STORE |
Integer external |
10 |
505:514 |
N/A |
|
DAY |
Integer external |
3 |
515:517 |
N/A |
Table 6-67 File Name: Satpymt.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_PAYMENT |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
N/A |
PAYMENT_SEQ_NO |
Integer external |
20 |
21:24 |
N/A |
|
PAYMENT_AMT |
Decimal external |
5 |
25:46 |
N/A |
|
ERROR_IND |
Char |
10 |
47:47 |
N/A |
|
STORE |
Integer external |
6 |
48:57 |
N/A |
|
DAY |
Integer external |
3 |
58:60 |
N/A |
Table 6-68 File Name: Samisstr.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_MISSING_TRAN |
MISS_TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
N/A |
STORE_DAY_SEQ_NO |
Integer external |
20 |
21:40 |
N/A |
|
REGISTER |
Char |
5 |
41:45 |
N/A |
|
TRAN_NO |
Integer external |
10 |
46:55 |
N/A |
|
STATUS |
Char |
6 |
56:61 |
N/A |
|
RTLOG_ORIG_SYS |
Char |
3 |
62:64 |
N/A |
Table 6-69 File Name: Sattax.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_TAX |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
N/A |
TAX_CODE |
Char |
6 |
21:26 |
N/A |
|
TAX_SEQ_NO |
Integer external |
4 |
27:30 |
N/A |
|
TAX_AMT |
Decimal external |
22 |
31:52 |
Includes an optional negative sign and a decimal point |
|
ERROR_IND |
Char |
1 |
53:53 |
N/A |
|
REF_NO17 |
Char |
30 |
54:83 |
N/A |
|
REF_NO18 |
Char |
30 |
84:113 |
N/A |
|
REF_NO19 |
Char |
30 |
114:143 |
N/A |
|
REF_NO20 |
Char |
30 |
144:173 |
N/A |
|
STORE |
Integer external |
10 |
174:183 |
N/A |
|
DAY |
Integer external |
3 |
184:186 |
N/A |
Table 6-70 File Name: Sacustatt.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_CUST_ATTRIB |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
N/A |
ATTRIB_SEQSO |
Char |
4 |
21:24 |
N/A |
|
ATTRIB_TYPE |
Char |
6 |
25:30 |
N/A |
|
ATTRIB_VALUE |
Char |
6 |
31:36 |
N/A |
|
STORE |
Integer external |
10 |
37:46 |
N/A |
|
DAY |
Integer external |
3 |
47:49 |
N/A |
Table 6-71 File Name: Saerror.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_ERROR |
ERROR_SEQ_NO |
Integer external |
20 |
1:20 |
N/A |
STORE_DAY_SEQ_NO |
Integer external |
20 |
21:40 |
N/A |
|
BAL_GROUP_SEQ_NO |
Integer external |
20 |
41:60 |
N/A |
|
TOTAL_SEQ_NO |
Integer external |
20 |
61:80 |
N/A |
|
TRAN_SEQ_NO |
Integer external |
20 |
81:100 |
N/A |
|
ERROR_CODE |
Char |
25 |
101:125 |
N/A |
|
KEY_VALUE_1 |
Integer external |
4 |
126:129 |
N/A |
|
KEY_VALUE_2 |
Integer external |
4 |
130:133 |
N/A |
|
REC_TYPE |
Char |
6 |
134:139 |
N/A |
|
STORE_OVERRIDE_IND |
Char |
1 |
140:140 |
N/A |
|
HQ_OVERRIDE_IND |
Char |
1 |
141:141 |
N/A |
|
UPDATE_ID |
Char |
30 |
142:171 |
N/A |
|
UPDATE_DATE TIME |
Date |
14 |
172:185 |
Format is YYYYMMDDHH24MISS |
|
ORIG_VALUE |
Char |
70 |
186:255 |
N/A |
|
STORE |
Integer external |
10 |
256:265 |
N/A |
|
DAY |
Integer external |
3 |
266:268 |
N/A |
|
KEY_VALUE_3 |
Integer external |
4 |
269:272 |
N/A |
Table 6-72 File Name: Sathatt.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_HEAD_ATTRIB |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
|
ATTRIB_SEQ_NO |
Integer external |
4 |
21:24 |
||
ATTRIB_TYPE |
Char |
6 |
25:30 |
||
ATTRIB_VALUE |
Char |
120 |
31:150 |
||
STORE |
Integer external |
10 |
151:160 |
||
DAY |
Integer external |
3 |
161:163 |
||
ERROR_IND |
Char |
1 |
164:164 |
Table 6-73 File Name: Saitatt.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_ITEM_ATTRIB |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
|
ITEM_SEQ_NO |
Integer external |
4 |
21:24 |
||
ATTRIB_SEQ_NO |
Integer external |
4 |
25:28 |
||
ATTRIB_TYPE |
Char |
6 |
29:34 |
||
ATTRIB_VALUE |
Char |
120 |
35:154 |
||
STORE |
Integer external |
10 |
155:164 |
||
DAY |
Integer external |
3 |
165:167 |
||
ERROR_IND |
Char |
1 |
168:168 |
Table 6-74 File Name: Saidatt.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_DISC_ATTRIB |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
|
ITEM_SEQ_NO |
Integer external |
4 |
21:24 |
||
DISCOUNT_SEQ_NO |
Integer external |
4 |
25:28 |
||
ATTRIB_SEQ_NO |
Integer external |
4 |
29:32 |
||
ATTRIB_TYPE |
Char |
6 |
33:38 |
||
ATTRIB_VALUE |
Char |
120 |
39:158 |
||
STORE |
Integer external |
10 |
159:168 |
||
DAY |
Integer Exernal |
3 |
169:171 |
||
ERROR_IND |
Char |
1 |
172:172 |
Table 6-75 File Name: Saixatt.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_IGTAX_ATTRIB |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
|
ITEM_SEQ_NO |
Integer external |
4 |
21:24 |
||
IGTAX_SEQ_NO |
Integer external |
4 |
25:28 |
||
ATTRIB_SEQ_NO |
Integer external |
4 |
29:32 |
||
ATTRIB_TYPE |
Char |
6 |
33:38 |
||
ATTRIB_VALUE |
Char |
120 |
39:158 |
||
STORE |
Integer external |
10 |
159:168 |
||
DAY |
Integer external |
3 |
169:171 |
||
ERROR_IND |
Char |
1 |
172:172 |
Table 6-76 File Name: Satxatt.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_TAX_ATTRIB |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
|
TAX_SEQ_NO |
Integer external |
4 |
21:24 |
||
ATTRIB_SEQ_NO |
Integer external |
4 |
25:28 |
||
ATTRIB_TYPE |
Char |
6 |
29:34 |
||
ATTRIB_VALUE |
Char |
120 |
35:154 |
||
STORE |
Integer external |
10 |
155:164 |
||
DAY |
Integer external |
3 |
165:167 |
||
ERROR_IND |
Char |
1 |
168:168 |
Table 6-77 File Name: Sattatt.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_TENDER_ATTRIB |
TRAN_SEQ_NO |
Integer external |
20 |
1:20 |
|
TENDER_SEQ_NO |
Integer external |
4 |
21:24 |
||
ATTRIB_SEQ_NO |
Integer external |
4 |
25:28 |
||
ATTRIB_TYPE |
Char |
6 |
29:34 |
||
ATTRIB_VALUE |
Char |
120 |
35:154 |
||
STORE |
Integer external |
10 |
155:164 |
||
DAY |
Integer external |
3 |
165:167 |
||
ERROR_IND |
Char |
1 |
168:168 |
Table 6-78 File Name: Satwritelock.ctl
Table Name | Column Name | Field Type | Field Width | Position | Description |
---|---|---|---|---|---|
SA_TRAN_WRITE_LOCK |
STORE_DAY_SEQ_NO |
Integer external Date |
20 |
1:20 |
N/A |
TRAN_SEQ_NO |
Integer external Date |
20 |
21:40 |
N/A |
Sales Audit Interface File Layout [rtlog]
The following illustrates the file layout format of the Oracle Retail TLOG. The content of each Oracle Retail TLOG file is per store per day. The filename convention is RTLOG_STORE_DATETIME.DAT (for example, RTLOG_1234_01221989010000.DAT).
Involves round off fields, credit promotion id, tax (vat) at item level and payment amount of customer orders.
Document has been modified regarding tender types, logic of handling both VAT-TAX in the system has been added.
Retailers must ensure that credit card numbers are masked when sent through RTLOGs. Similarly, when the tender type is check, checking account numbers must be masked when sent through RTLOGs. When Sales Audit encounters an RTLOG with a non-masked credit card or checking account number, the entire file will be rejected and will not be processed.
FHEAD (Only 1 per file, required) THEAD (Multiple expected, one per transaction, required for each transaction) THATT (Attribute record specific to the THEAD record - Multiple allowed, optional) TCUST (Only 1 per THEAD record allowed, optional for some transaction types, see table below) CATT (Attribute record specific to the TCUST record - Multiple allowed, only valid if TCUST exists) TITEM (Multiple allowed per transaction, optional for some transaction types, see table below) ITATT (Attribute record specific to the TITEM record - Multiple allowed, optional and only valid if TITEM exists) IDISC (Discount record specific to the TITEM record - Multiple allowed per item, optional see table below) IDATT (Attribute record specific to the IDISC record - Multiple allowed, optional and only valid if IDISC exists) IGTAX (VAT/Tax record specific to the TITEM record - Multiple allowed per item, optional. Either TTAX or IGTAX should appear in a given RTLOG, if originating system is POS, but not both, see table below). If originating system is OMS, both IGTAX and TTAX can appear but only the one matching the store's tax type will be processed, the other record will be ignored. IXATT (Attribute record specific to the IGTAX record - Multiple allowed, optional and only valid if IGTAX exists) TTAX (Vat/Tax record specific to the THEAD record - Multiple allowed per transaction, optional. Either TTAX or IGTAX should appear in a given RTLOG, if originating system is POS, but not both, see table below). If originating system is OMS, both IGTAX and TTAX can appear but only the one matching the store's tax type will be processed, the other record will be ignored. TXATT (Attribute record specific to the TTAX record - Multiple allowed, optional and only valid if TTAX exists) TPYMT (Multiple allowed per transaction, will have the deposit amount for pickup/delivery/layaway orders, optional see table below) TTEND (Multiple allowed per transaction, optional for some transaction types, see table below) TTATT (Attribute record specific to the TTEND record - Multiple allowed, optional and only valid if TTEND exists) TTAIL (1 per THEAD, required) FTAIL (1 per file, required)
The order of the records within the transaction layout above is important. It aids processing by ensuring that the information is present when it is needed.
Fields expected in RTLog format based on the changes adopted -
Version Number | 1 | 2a | 2b | 3 | 4 |
---|---|---|---|---|---|
Version Description | Initial Version (V16.0.x SaaS) | Initial Version Plus Fulfilment Type and Location | Initial Version Plus Reference Numbers 28-31 | Initial Version Plus Fulfilment Type and Location and Reference Numbers 28-31 | Version 3 Plus Posting Store |
Reference No. 28 |
N |
N |
Y |
Y |
Y |
Reference No. 29 |
N |
N |
Y |
Y |
Y |
Reference No. 30 |
N |
N |
Y |
Y |
Y |
Reference No. 31 |
N |
N |
Y |
Y |
Y |
Fulfillment Location type |
N |
Y |
N |
Y |
Y |
Fulfillment Location |
N |
Y |
N |
Y |
Y |
Posting Store |
N |
N |
N |
N |
Y |
Table 6-79 File Name: rtlog
Record Name | Field Name | Field Type | Default Value | Description | Required? | Justification/Padding |
---|---|---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type. |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
Y |
Right/0 |
|
File Type Definition |
Char(4) |
RTLG |
Identifies file as Oracle Retail TLOG. |
Y |
Left/Blank |
|
File Create Date |
Char(14) |
Create date |
Date and time file was written by external system (YYYYMMDDHHMMSS). |
Y |
Left/None |
|
Business Date |
Char(8) |
Business Date to process |
Business date of transactions (YYYYMMDD). |
Y |
Left/None |
|
Location Number |
Char(10) |
Specified by external system |
Store or warehouse identifier. |
Y |
Left/None |
|
Reference Number |
Char(30) |
Specified by external system |
This may contain the Polling ID associated with the consolidated TLOG file or used for other purpose. |
N |
Left/Blank |
|
RTLOG Originating System |
Char(3) |
POS |
Identifies the system the RTLOG file originated from. Valid values are OMS and POS. |
Y |
Left/None |
|
Transaction Header |
File Type Record Descriptor |
Char(5) |
Char(5) THEAD |
Identifies file record type. |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
Y |
Right/0 |
|
Register |
Char(5) |
Transaction date |
Till used at the store. |
Y |
Left/Blank |
|
Transaction Date |
Char(14) |
N/A |
Date for the transactions that were processed at the POS (YYYYMMDDHHMMSS). |
Y |
Left/None |
|
Transaction Number |
Number(10) |
N/A |
Transaction identifier. If sa_system_options, wkstation_tran_append_ind is Y, then the first 3 digits indicate the workstation ID and last 7 digits indicate the transaction number. |
Y |
Right/0 |
|
Cashier |
Char(10) |
N/A |
Cashier identifier. |
N |
Left/Blank |
|
Salesperson |
Char(10) |
N/A |
Salesperson identifier. |
N |
Left/Blank |
|
Transaction Type |
Char(6) |
Refer to TRAT code_type for a list of valid types. |
Transaction type. |
Y |
Left/Blank |
|
Sub-transaction type |
Char(6) |
Refer to TRAS code_type for a list of valid types. |
Sub-transaction type. For sale, it can be employee, drive-off, and so on. |
N |
Left/Blank |
|
Orig_tran_no |
Number(10) |
N/A |
Populated only for post-void transactions. Transaction number for the original transaction that will be cancelled. |
N |
Right/0 |
|
Orig_reg_no |
Char(5) |
N/A |
Populated only for post-void even exchange and return transactions. Register number from the original transaction |
N |
Left/Blank |
|
Reason Code |
Char(6) |
Refer to REAC code_type for a list of valid codes. If the transaction type is PAIDOU and the sub transaction type is MV or EV, than the valid codes come from the non_merch_code_head table. |
Reason entered by the cashier for some transaction types. Required for Paid In and Paid out transaction types, but can also be used for voids, returns, and so on. |
N |
Left/Blank |
|
Vendor Number |
Char(10) |
N/A |
Supplier ID for a merchandise vendor paid out transaction; partner ID for an expense vendor paid out transaction. |
N |
Left/Blank |
|
Vendor Invoice Number |
Char(30) |
N/A |
Invoice number for a vendor paid out transaction. |
N |
Left/Blank |
|
Payment Reference Number |
Char(16) |
N/A |
The reference number of the tender used for a vendor payout. This could be the money order number, check number, and so on. |
N |
Left/Blank |
|
Proof of Delivery Number |
Char(30) |
N/A |
Proof of receipt number given by the vendor at the time of delivery. This field is populated for a vendor paid out transaction. |
N |
Left/Blank |
|
Reference Number 1 |
Char(30) |
Na |
Number associated with a particular transaction, for example, whether for a Store Conditions transaction. The SA_REFERENCE table defines what this field can contain for each transaction type. |
N |
Left/Blank |
|
Reference Number 2 |
Char(30) |
N/A |
Char(30) |
N |
Left/Blank |
|
Reference Number 3 |
Char(30) |
N/A |
Third generic reference number. |
N |
Left/Blank |
|
Reference Number 4 |
Char(30) |
N/A |
Fourth generic reference number. |
N |
Left/Blank |
|
Value Sign |
Char(1) |
Refer to SIGN code_type for a list of valid codes. |
Sign of the value. |
Y if Value is present. |
Left/None |
|
Value |
Number(20) |
N/A |
Value, with 4 implied decimal places. Populated by the retailer for TOTAL transaction, populated by Sales Audit for SALE and RETURN transactions. |
Y if tran is a TOTAL |
Right/0 when value is present. Blank when no value is sent. |
|
Banner id |
Number(4) |
N/A |
Banner ID of the location. |
Y |
Right/0 when value is present. Blank when no value is sent |
|
Rounded Amount Sign |
Char(1) |
Refer to SIGN code_type for a list of valid codes. |
Sign of rounded amount. Amount Sign is not used. |
Y |
Left/None |
|
Rounded Amount |
Number(20) |
N/A |
Total rounded amount, with 4 implied decimal places. Rounded Amount is not used. |
Y |
Right/0 when RoundedAmount is present otherwise blank |
|
Rounded Off Sign |
Char(1) |
Refer to SIGN code_type for a list of valid codes. |
Rounded Off Sign is not used. |
Y |
Left/None |
|
Rounded Off Amount |
Number(20) |
N/A |
Rounded off amount, with 4 implied decimal places. Rounded Off Amount is not used. |
Y |
Right/0 when RoundedAmount is present otherwise blank |
|
Credit Promotion Id |
Char(10) |
N/A |
Credit Promotional ID. |
Y |
Left/None |
|
Reference Number 25 |
Char(30) |
N/A |
N/A |
N |
Left/Blank |
|
Reference Number 26 |
Char(30) |
N/A |
N/A |
N |
Left/Blank |
|
Reference Number 27 |
Char(30) |
N/A |
N/A |
N |
Left/Blank |
|
Transaction Processing System |
Char(3) |
Valid values are OMS and POS. |
Contains the ID of the system that processed the transaction. |
N |
Left/None |
|
Reference Number 28 |
Char(30) |
Generic Reference Number. It can be ignored if not needed based on the type of RTLOG being used. |
N |
Left/Blank |
||
Reference Number 29 |
Char(30) |
Generic Reference Number. It can be ignored if not needed based on the type of RTLOG being used. |
N |
Left/Blank |
||
Reference Number 30 |
Char(30) |
Generic Reference Number. It can be ignored if not needed based on the type of RTLOG being used. |
N |
Left/Blank |
||
Reference Number 31 |
Char(30) |
Generic Reference Number. It can be ignored if not needed based on the type of RTLOG being used. |
N |
Left/Blank |
||
Transaction Header Attribute |
File Type Record Descriptor |
Char(5) |
THATT |
Identifies file record type |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file. |
Y |
Right/0 |
|
Attribute Type |
Char(6) |
Refer to 'SAHA' code_type for a list of valid types |
Type of transaction header attribute |
Y |
Left/Blank |
|
Attribute Value |
Char(120) |
Value of transaction header attribute |
Y |
Left/Blank |
||
Transaction Customer |
File Type Record Descriptor |
Char(5) |
TCUST |
Identifies the file record type. |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file |
Y |
Right/0 |
|
Customer ID |
Char(16) |
Customer identifier |
The ID number of a customer. |
Y |
Left/Blank |
|
Customer Type ID |
Char(6) |
Refer to CIDT code_type for a list of valid types. |
Customer ID type. |
Y |
Left/Blank |
|
Customer Name |
Char(120) |
N/A |
Customer name. |
N |
Left/Blank |
|
Address 1 |
Char(240) |
N/A |
Customer address. |
N |
Left/Blank |
|
Address 2 |
Char(240) |
N/A |
Additional field for customer address. |
N |
Left/Blank |
|
City |
Char(120) |
N/A |
City. |
N |
Left/Blank |
|
State |
Char(12) |
State identifier |
State. |
N |
Left/Blank |
|
Zip Code |
Char(30) |
Zip identifier |
Zip code. |
N |
Left/Blank |
|
Country |
Char(3) |
N/A |
Country. |
N |
Left/Blank |
|
Home Phone |
Char(20) |
N/A |
Telephone number at home. |
N |
Left/Blank |
|
Work Phone |
Char(20) |
N/A |
Telephone number at work. |
N |
Left/Blank |
|
|
Char(100) |
N/A |
E-mail address. |
N |
Left/Blank |
|
Birthdate |
Char(8) |
N/A |
Date of birth. (YYYYMMDD) |
N |
Left/Blank |
|
Customer Attribute |
File Type Record Descriptor |
Char(5) |
CATT |
Identifies file record type. |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
Y |
Right/0 |
|
Attribute type |
Char(6) |
Refer to SACA code_type for a list of valid types. |
Type of customer attribute |
Y |
Left/Blank |
|
Attribute value |
Char(6) |
Refer to members of SACA code_type for a list of valid values. |
Value of customer attribute. |
Y |
Left/Blank |
|
Transaction Item |
File Type Record Descriptor |
Char(5) |
TITEM |
Identifies file record type. |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
Y |
Right/0 |
|
Item Status |
Char(6) |
Refer to SASI code_type for a list of valid codes. |
Status of the item within the transaction. Valid values are: V - Void item S - Sold item R - Returned item ORI - Order Initiate ORC - Order Cancel ORD - Order Complete LIN - Layaway Initiate LCA - Layaway Cancel LCO - Layaway Complete ADJ - Appeasement/Adjustment |
Y |
Left/Blank |
|
Item Type |
Char(6) |
Refer to SAIT code_type for a list of valid codes. |
Identifies what type of item is transmitted. |
Y |
Left/Blank |
|
Item number type |
Char(6) |
Refer to UPCT code_type for a list of valid codes. |
Identifies the type of item number if the item type is ITEM or REF |
N |
Left/Blank |
|
Format ID |
Char(1) |
VPLU format ID |
Used to interpret VPLU items. |
N |
Left/Blank |
|
Item |
Char(25) |
Item identifier |
Identifies the merchandise item. |
N |
Left/Blank |
|
Reference Item |
Char(25) |
Item identifier |
Identifies the sub-transaction level merchandise item. |
N |
Left/Blank |
|
Non-Merchandise Item |
Char(25) |
Item identifier |
Item identifier Identifies a non-merchandise item. |
N |
Left/Blank |
|
Voucher |
Char(25) |
N/A |
Gift certificate number. |
N |
Right/0 |
|
Department |
Number(4) |
N/A |
Identifies the department to which this item belongs. This is filled in by saimptlog. |
N |
Right/Blank |
|
Class |
Number(4) |
Class of the item |
Class of item sold or returned. Not required from a retailer; populated by Sales Audit. This is filled in by saimptlog. |
N |
Right/Blank |
|
Subclass |
Number(4) |
Subclass of the item |
Subclass of the item sold or returned. Not required from a retailer; populated by Sales Audit. This is filled in by saimptlog. |
N |
Right/Blank |
|
Quantity Sign |
Char(1) |
Refer to SIGN code_type for a list of valid codes. |
Sign of the quantity |
Y |
Left/None |
|
Quantity |
Number(12) |
N/A |
Number of items purchased, with 4 decimal places. |
Y |
Right/0 |
|
Selling Unit of Measure |
Char(4) |
N/A |
Unit of measure of the item's quantity. |
Y |
Left/None |
|
Unit Retail |
Number(20) |
N/A |
Unit retail, with 4 implied decimal places. |
Y |
Right/0 |
|
Override Reason |
Char(6) |
Refer to ORRC code_type for a list of valid codes. |
This column is populated when an item's price has been overridden at the POS to define why it was overridden. |
Y if unit retail was manually entered |
Left/Blank |
|
Original Unit Retail |
Number(20) |
N/A |
Value, with 4 implied decimal places. This column is populated when the item's price was overridden at the POS and the item's original unit retail is known. |
Y if unit retail was manually entered |
Right/0 |
|
Taxable Indicator |
Char(1) |
Refer to YSNO code_type for a list of valid codes. |
Indicates whether or not item is taxable. |
Y |
Left/None |
|
Pump |
Char(8) |
N/A |
Fuel pump identifier. |
N |
Left/Blank |
|
Reference Number 5 |
Char(30) |
N/A |
Number associated with a particular item within a transaction, for example, special order number. The sa_reference table defines what this field can contain for each transaction type. |
N |
Left/Blank |
|
Reference Number 6 |
Char(30) |
N/A |
Second generic reference number at the item level. |
N |
Left/Blank |
|
Reference Number 7 |
Char(30) |
N/A |
Third generic reference number at the item level. |
N |
Left/Blank |
|
Reference Number 8 |
Char(30) |
N/A |
Fourth generic reference number at the item level. |
N |
Left/Blank |
|
Item_swiped_ind |
Char(1) |
Refer to YSNO code_type for a list of valid codes |
Indicates if the item was automatically entered into the POS system or if it had to be manually keyed. |
Y |
Left/None |
|
Return Reason Code |
Char(6) |
Refer to SARR code_type for a list of valid codes. |
The reason an item was returned. |
N |
Left/Blank |
|
Salesperson |
Char(10) |
N/A |
The salesperson who sold the item. |
N |
Left/Blank |
|
Expiration_date |
Char(8) |
N/A |
Gift certificate expiration date (YYYYMMDD). |
N |
||
Drop Ship Ind |
Char(1) |
Refer to YSNO code type for a list of valid codes. |
Indicates whether the item is part of a drop shipment. |
Y |
Left/None |
|
Uom_qty |
Number(12) |
N/A |
Quantity of items purchased in the given UOM, with 4 decimal places. |
Y |
Right/0 |
|
Catchweight_ind |
Char(1) |
Valid values are Y and N. |
Identifies if the item is a catchweight item. |
Left/None |
||
Selling item |
Char(25) |
Item identifier |
Identifies the selling item. |
N |
Left/Blank |
|
Customer order line no |
Number(6) |
N/A |
Identifies the customer order number. |
N |
Left/Blank |
|
Media id |
Number(10) |
N/A |
Identifies the customer media ID. |
N |
Left/Blank |
|
Total Igtax Amount |
Number(21) |
N/A |
Contains the Igtax amount. |
N |
Right/0 |
|
Unique ID |
Char(128) |
N/A |
N |
Left/Blank |
||
Customer Order Number |
Char(48) |
N/A |
Contains the customer order ID. |
N |
Left/None |
|
Customer Order Date |
Char(14) |
N/A |
Contains the customer order date. Format is: YYYYMMDDHHMMSS Customer orders and layaways require customer order date. |
N |
Left/Blank |
|
Fulfillment Order Number |
Char(48) |
N/A |
Contains the order ID of the fulfillment order. |
N |
Left/None |
|
No Inventory Return |
Char(1) |
N/A |
Indicates if there is an associated inventory with the return transaction with an External Customer Order sales type. |
N |
Left/Blank |
|
Sales Type |
Char(1) |
N/A |
Indicates if the transaction is an In Store Customer Order, External Customer Order, or Regular Sale |
N |
Left/Blank |
|
Return Warehouse |
Char(10) |
N/A |
Contains the ID of the physical warehouse to which the inventory is returned. |
N |
Left/Blank |
|
Return Disposition |
Char(10) |
N/A |
Contains the return disposition of the returned items. |
N |
Left/Blank |
|
Original Store |
Char(10) |
Contains the original store. |
N |
Left/Blank |
||
Original Transaction No |
Char(10) |
Contains the original transaction no. |
N |
Left/Blank |
||
Fulfillment Loc Type |
Char(2) |
Refer to 'FLTP' code type for a list of valid types. |
Contains the fulfillment order location type. It is needed only if the file is for an OMS transaction. |
N |
Left/Blank |
|
Fulfillment Loc |
Number(10) |
Fulfillment Location ID. It is needed only if the file is for an OMS transaction. |
N |
Left/Blank |
||
Posting Store |
Number(10) |
Contains the store at which the item sale/return should be accounted for in case of cross-store sales happening at co-located stores. It is expected that this field will be populated only for items that are checked out at a different store from the one at which they are originally managed. |
N |
Left/Blank |
||
Transaction Item Attribute |
File Type Record Descriptor |
Char(5) |
ITATT |
Identifies file record type |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file. |
Y |
Right/0 |
|
Attribute Type |
Char(6) |
Refer to 'SAIA' code_type for a list of valid types |
Type of item attribute |
Y |
Left/Blank |
|
Attribute Value |
Char(120) |
Value of item attribute |
Y |
Left/Blank |
||
Item Discount |
File Type Record Descriptor |
Char(5) |
IDISC |
Identifies the file record type. |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
Y |
Right/0 |
|
RMS Promotion Number |
Char(6) |
Refer to PRMT code_type for a list of valid types |
The Merchandising promotion type. |
Y |
Left/Blank |
|
Discount Reference Number |
Number(10) |
N/A |
Discount reference number associated with the discount type. For example, if the discount type is a promotion, this contains the promotion number. |
N |
Left/Blank |
|
Discount Type |
Char(6) |
Refer to SADT code_type for a list of valid types. |
The type of discount within a promotion. This allows a retailer to further break down coupon discounts within the In-store promotion, for example. |
N |
Left/Blank |
|
Coupon Number |
Char(40) |
N/A |
Number of a store coupon used as a discount. |
Y if coupon |
Left/Blank |
|
Coupon Reference Number |
Char(16) |
N/A |
Additional information about the coupon, usually contained in a second bar code on the coupon. |
Y if coupon |
Left/Blank |
|
Quantity Sign |
Char(1) |
Refer to SIGN code_type for a list of valid codes. |
Sign of the quantity. |
Y |
Left/None |
|
Quantity |
Number(12) |
N/A |
The quantity purchased for which the discount is applied, with 4 implied decimal places. |
Y |
Right/0 |
|
Unit Discount Amount |
Number(20) |
N/A |
Unit discount amount for this item, with 4 implied decimal places. |
Y |
Right/0 |
|
Reference Number 13 |
Char(30) |
N/A |
Number associated with a particular transaction type at the discount level. The sa_reference table defines what this field can contain for each transaction type. |
N |
Left/Blank |
|
Reference Number 14 |
Char(30) |
N/A |
Second generic reference number at the discount level. |
N |
Left/Blank |
|
Reference Number 15 |
Char(30) |
N/A |
Third generic reference number at the discount level. |
N |
Left/Blank |
|
Reference Number 16 |
Char(30) |
N/A |
Fourth generic reference number at the discount level. |
N |
Left/Blank |
|
Uom_qty |
Number(12) |
N/A |
Quantity of items purchased in the given UOM with 4 decimal places. |
Y |
Right/0 |
|
Catchweight_ind |
Char(1) |
Valid values are Y and N. |
Identifies if the item is a catchweight item. |
Left/None |
||
Promo component |
Number(10) |
N/A |
If the discount is a promotion, this field contains the promotion component value associated with the promotion (discount reference number). |
N |
Left/Blank |
|
Transaction Item Discount Attribute |
File Type Record Descriptor |
Char(5) |
IDATT |
Identifies file record type |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file. |
Y |
Right/0 |
|
Attribute Type |
Char(6) |
Refer to 'SADA' code_type for a list of valid types |
Type of transaction item discount attribute |
Y |
Left/Blank |
|
Attribute Value |
Char(120) |
Value of transaction item discount attribute |
Y |
Left/Blank |
||
Item Tax |
File Type Record Descriptor |
Char(5) |
IGTAX |
Identifies the file record type |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
Y |
Right/0 |
|
Tax Authority |
Char(10) |
N/A |
A free-form text field. Any value can be used as a default string describing the authority levying the tax. |
Y |
Left/Blank |
|
Igtax Code |
Char(6) |
Refer to tax_code/vat_code of tax_codes/vat_codes tables. |
IGtax code (tax code/VAT code) to represent whether it is a State, City, or some other tax code/VAT code. |
Y |
Left/Blank |
|
Igtax Rate |
Number(20) |
N/A |
Igtax rate, with 4 implied decimal places. |
Y |
Right/0 |
|
Igtax Amount Sign |
Char(1) |
Refer to SIGN code_type for a list of valid codes. |
Sign of the Igtax amount. |
Y |
Left/None |
|
Igtax Amount |
Number(21) |
N/A |
Total igtax amount for this item, with 5 implied decimal places. |
Y |
Right/0 |
|
Reference Number 21 |
Char(30) |
N/A |
N/A |
N |
Left/None |
|
Reference Number 22 |
Char(30) |
N/A |
N/A |
N |
Left/None |
|
Reference Number 23 |
Char(30) |
N/A |
N/A |
N |
Left/None |
|
Reference Number 24 |
Char(30) |
N/A |
N/A |
N |
Left/None |
|
Tax Calculation Type |
Char(6) |
Refer to the 'GTTT' code type for the list of valid values. |
Contains the tax calculation type. |
N |
Left/None |
|
Transaction Item Tax Attribute |
File Type Record Descriptor |
Char(5) |
IXATT |
Identifies file record type |
Y |
Left/None |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file. |
Y |
Right/0 |
|
Attribute Type |
Char(6) |
Refer to 'SAXA' code_type for a list of valid types |
Type of transaction item tax attribute |
Y |
Left/None |
|
Attribute Value |
Char(120) |
Value of transaction item tax attribute |
Y |
Left/None |
||
Transaction Tax |
File Type Record Descriptor |
Char(5) |
TTAX |
Identifies the file record type. |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
Y |
Right/0 |
|
Tax Code |
Char(6) |
Refer to TAXC code_type for as list of valid types. |
Tax code (tax code/VAT code) to represent whether it is a State, City, or some other tax code/VAT code. |
Y |
Left/Blank |
|
Tax Sign |
Char(1) |
Refer to SIGN code_type for a list of valid codes |
Sign of the tax amount. |
Y |
Left/None |
|
Tax Amount |
Number(20) |
N/A |
Total Tax amount for this item, with 4 implied decimal places. |
Y |
Right/0 |
|
Reference Number 17 |
Char(30) |
N/A |
N/A |
N |
Left/None |
|
Reference Number 18 |
Char(30) |
N/A |
N/A |
N |
Left/None |
|
Reference Number 19 |
Char(30) |
N/A |
N/A |
N |
Left/None |
|
Reference Number 20 |
Char(30) |
N/A |
N/A |
N |
Left/None |
|
Transaction Tax Attribute |
File Type Record Descriptor |
Char(5) |
TXATT |
Identifies file record type |
Y |
Left/None |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file. |
Y |
Right/0 |
|
Attribute Type |
Char(6) |
Refer to 'SAXA' code_type for a list of valid types |
Type of transaction tax attribute |
Y |
Left/None |
|
Attribute Value |
Char(120) |
Value of transaction tax attribute |
Y |
Left/None |
||
Transaction payment |
File Type Record Descriptor |
Char(5) |
TPYMT |
Identifies the file record type. |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
Y |
Right/0 |
|
Payment Sign |
Char(1) |
Refer to SIGN code_type for a list of valid codes. |
Sign of the deposit amount. |
Y |
Left/None |
|
Payment Amount |
Number(20) |
N/A |
Deposit amount paid, with 4 implied decimal places. |
Y |
Right/0 |
|
Transaction Tender |
File Type Record Descriptor |
Char(5) |
TTEND |
Identifies the file record type. |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
Y |
Right/0 |
|
Tender Type Group |
Char(6) |
Refer to TENT code_type for as list of valid types |
High-level grouping of tender types. |
Y |
Left/Blank |
|
Tender Type ID |
Number(6) |
Refer to the pos_tender_type_head table for as list of valid types. |
Low-level grouping of tender types. |
Y |
Left/Blank |
|
Tender Sign |
Char(1) |
Refer to SIGN code_type for a list of valid codes. |
Sign of the value. |
Y |
Left/None |
|
Tender Amount |
Number(20) |
N/A |
Amount paid with this tender in the transaction, with 4 implied decimal places. |
Y |
Right/0 |
|
Cc_no |
Char(40) |
N/A |
Credit card number. Merchandise is not a PCI compliant system. Full credit card numbers are not allowed in Merchandising. The value sent in the RTLOG should be masked so that it contains no more than the first 6 digits and last 4 digits in clear text. The remaining digits should be masked using the character defined in sa_system_options.cc_no_mask_char. If more than the first 6 and last 4 characters exist in any records, the transaction file will be rejected. Alternatively, the credit card number field can be left fully blank. |
N |
Left/Blank |
|
Cc_auth_no |
Char(16) |
N/A |
Authorization number for a credit card. |
N |
Left/Blank |
|
cc authorization source |
Char(6) |
Refer to CCAS code_type for as list of valid types. |
N/A |
N |
Left/Blank |
|
cc cardholder verification |
Char(6) |
Refer to CCVF code_type for as list of valid types |
N/A |
N |
Left/Blank |
|
cc expiration date |
Char(8) |
N/A |
YYYYMMDD |
N |
Left/Blank |
|
cc entry mode |
Char(6) |
Refer to CCEM code_type for as list of valid types. |
Indicates whether the credit card was swiped, thus automatically entered, or manually keyed. |
N |
Left/Blank |
|
cc terminal id |
Char(5) |
N/A |
Terminal number from which the transaction was sent. |
N |
Left/Blank |
|
cc special condition |
Char(6) |
Refer to CCSC code_type for as list of valid types. |
N/A |
N |
Left/Blank |
|
cc token |
Char(40) |
N/A |
Holds unique token when the tender type used is credit, debit card, PayPal, Fonacot or Others. |
N |
Left/Blank |
|
Voucher_no |
Char(25) |
N/A |
Gift certificate or credit voucher serial number. Voucher number needs to be included If a voucher is voided from a transaction. |
Y if voucher |
Right/0 |
|
Coupon Number |
Char(40) |
N/A |
Number of a manufacturer's coupon used as a tender. |
Y if coupon |
Left/Blank |
|
Coupon Reference Number |
Char(16) |
N/A |
Additional information about the coupon, usually contained in a second bar code on the coupon. |
Y if coupon |
Left/Blank |
|
Cheque Account Number |
Char(30) |
N/A |
Account number of the cheque. The value sent in the RTLOG is masked. |
N |
Left/Blank |
|
Cheque Number |
Number(10) |
N/A |
Check number. |
Required for the tender type CHECK |
Right/0 |
|
Identification Method |
Char(6) |
Refer to IDMH code_type for list of valid types. |
Identification Method (such as a driver's license number or photo credit card). |
N |
Left/Blank |
|
Identification Id |
Char(40) |
N/A |
Identification ID (license ID or photo card number). |
N |
Left/Blank |
|
Original Currency |
Char(3) |
Refer to the CURRENCIES table for valid currency codes. |
The original currency with which the customer made the payment. |
N |
Left/Blank |
|
Original Currency Amount |
Number(20) |
N/A |
Amount paid with this tender in the original currency, with 4 implied decimal places. |
N |
Right/0 |
|
Reference No 9 |
Char(30) |
N/A |
Number associated with a particular transaction type at the tender level. The sa_reference table defines what this field can contain for each transaction type. |
N |
Left/Blank |
|
Reference No 10 |
Char(30) |
N/A |
Second generic reference number at the tender level. |
N |
Left/Blank |
|
Reference No 11 |
Char(30) |
N/A |
Third generic reference number at the tender level. |
N |
Left/Blank |
|
Reference No 12 |
Char(30) |
N/A |
Fourth generic reference number at the tender level. |
N |
Left/Blank |
|
Transaction Tender Attribute |
File Type Record Descriptor |
Char(5) |
TTATT |
Identifies file record type |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file. |
Y |
Right/0 |
|
Attribute Type |
Char(6) |
Refer to 'SATA' code_type for a list of valid types |
Type of transaction tender attribute |
Y |
Left/Blank |
|
Attribute Value |
Char(120) |
Value of transaction tender attribute |
Y |
Left/Blank |
||
Transaction Trailer |
File Type Record Descriptor |
Char(5) |
TTAIL |
Identifies file record type. |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
Y |
Right/0 |
|
Transaction Record Counter |
Number(10) |
N/A |
Number of records processed in the current transaction (only those records between transaction head and tail). |
N/A |
N/A |
|
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies the file record type. |
Y |
Left/Blank |
File Line Identifier |
Number(10) |
Specified by external system |
ID of the current line being processed by input file. |
Y |
Right/0 |
|
File Record Counter |
Number(10) |
N/A |
Number of transactions processed in the current file (only the records between the file head and tail). |
Y |
Right/0 |
The RTLOG file is imported into the Sales Audit tables after validation by the batch program saimptlog. This section describes the requirements and validations performed on the records.
Common Requirements/Validations
This section details the common requirements and validations performed on all transactions. The following sections describe the specific requirements of each type of transaction. If a transaction is not mentioned, it does not have specific requirements.
Table 6-80 Record Type Requirements
Transaction Type | Includes item records? | Includes tender records? | Includes tax records? IG TAX? | Includes customer records? |
---|---|---|---|---|
OPEN |
No |
No |
No |
No |
NOSALE |
No |
Optional |
No |
No |
VOID |
Optional |
Optional |
Optional |
Optional |
PVOID |
No |
No |
No |
No |
SALE |
Optional |
Yes |
Optional |
Optional |
RETURN |
Yes |
Yes |
Optional |
Optional |
EEXCH |
Yes |
No |
Optional |
Optional |
PAIDIN |
No |
Yes |
No |
No |
PAIDOU |
No |
Yes |
No |
No |
PULL |
No |
Yes |
No |
No |
LOAN |
No |
Yes |
No |
No |
COND |
No |
No |
No |
No |
CLOSE |
No |
No |
No |
No |
TOTAL |
No |
No |
No |
No |
REFUND |
This transaction is not sent through the RTLOG. It is entered at the HQ level. The TITEM and TCUST records are optional. The TTEND record is required. A TTAX record should not be included if IGTAX appears in a transaction if originating system is POS. IGTAX is an item-level tax and TTAX is a transaction-level tax. Either IGTAX or TTAX can be used if originating system is POS, but not both. If originating system is OMS, both IGTAX and TTAX can appear but only the one matching the store's tax type will be processed, the other record will be ignored. |
|||
METER |
Yes |
No |
No |
No |
PUMPT |
Yes |
No |
No |
No |
TANKDP |
Yes |
No |
No |
No |
TERM |
TERM records are created by saimptlog and then loaded into the database. They do not come from the RTLOG file. They require one TITEM, one TTEND, one TTAX, one TCUST record, and one CATT record, IGTAX, and one TPYMT which is newly coming up. |
|||
DCLOSE |
No |
No |
No |
No |
SPLORD |
Optional |
Yes |
Optional |
Optional |
REOPEN |
No |
No |
No |
No |
Requirements per Record Type
Table 6-81 Requirements per Record Type
Record Type | Requirements |
---|---|
IDISC |
IDISC records must immediately follow their associated TITEM record. IDISC records should be after the ITATT record if it exists. |
IGTAX |
IGTAX will immediately follow TITEM or ITATT record (if it is present), if discount records are not present. Otherwise it should follow the IDISC or IDATT record (if it is present). Even if IGTAX is coming prior to IDISC, it will be processed, but for maintaining proper format, Sales Audit expects it to come after IDISC. |
TTAX |
Either this record or IGTAX should appear in the transaction. IGTAX and TTAX cannot be both used at the same time if originating system is POS. If originating system is OMS, both IGTAX and TTAX can appear but only the one matching the store's tax type will be processed, the other record will be ignored. |
TPYMT |
This record should be right before the TTEND record. It contains the deposit amount for pickup/delivery/layaway orders. |
CATT |
CATT records must immediately follow their associated TCUST record. |
THATT |
THATT records must immediately follow their associated THEAD record. |
ITATT |
ITATT records must immediately follow their associated TITEM record. |
IDATT |
IDATT records must immediately follow their associated IDISC record. |
IXATT |
IXATT records must immediately follow their associated IGTAX record. |
TXATT |
TXATT records must immediately follow their associated TTAX record. |
TTATT |
TTATT records must immediately follow their associated TTEND record. |
Code Type Validations
Table 6-82 Code Type Validations
Record Name | Field Name | Code Type |
---|---|---|
Transaction Header |
Transaction Type |
TRAT |
Sub-transaction Type |
TRAS |
|
Reason Code |
REAC or values from non_merch_code_head if the transaction type is PAIDOU and the sub-transaction type is MV or EV. |
|
Value Sign |
SIGN |
|
Vender No |
If the transaction type is PAIDOU and the sub-transaction type is MV, this field is validated against the supplier table. If the transaction type is PAIDOU and the sub-transaction type is EV, this field is validated against the partner table. |
|
Transaction Processing System |
TSYS |
|
Transaction Header Attribute |
Attribute Type |
SAHA |
Transaction Item |
Item Type |
SAIT |
Item Status |
SASI |
|
Item Number Type |
UPCT |
|
Quantity Sign |
SIGN |
|
Taxable Indicator |
YSNO |
|
Price Override Reason Code |
ORRC |
|
Item Swiped Indicator |
YSNO |
|
Sales Type |
SASY |
|
Return Disposition |
INV_STATUS_CODES table |
|
No Inventory Return |
YSNO |
|
Return Reason Code |
SARR |
|
Fulfillment Loc Type |
FLTP |
|
Transaction Item Attribute |
Attribute Type |
SAIA |
Item Discount |
RMS Promotion Type |
PRMT |
Discount Type |
SADT |
|
Quantity Sign |
SIGN |
|
Item Discount Attribute |
Attribute Type |
SADA |
Transaction Customer |
Customer ID Type |
CIDT |
Customer Attribute |
Attribute Type |
SACA |
Attribute value |
Code types from the codes in SACA. |
|
Item Tax |
Tax Calculation Type |
GTTT |
Tax Code |
TAXC from the CODE_DETAIL table or VATC from the VAT_CODES table |
|
Item Tax Attribute |
Attribute Type |
SAXA |
Transaction Tax |
Tax code |
TAXC from the CODE_DETAIL table or VATC from the VAT_CODES table. |
Tax sign |
SIGN |
|
Transaction Tax Attribute |
Attribute Type |
SAXA |
Transaction Payment |
Payment (Deposit Amount) Sign |
SIGN |
Transaction Tender |
Transaction Tender Tender Type Group |
TENT |
Tender Sign |
SIGN |
|
Tender Type ID |
Pos_tender_type_head table |
|
CC Authorization Source |
CCAS |
|
CC Cardholder Verification |
CCVF |
|
CC Entry Mode |
CCEM |
|
CC Special Condition |
CCSC |
|
Transaction Tender Attribute |
Attribute Type |
SATA |
The following dates are validated: Business Date, Transaction Date, and Expiration Date. Also, saimptlog accepts only business dates that are within the PERIOD.VDATE minus the SA_SYSTEM_OPTIONS.DAYS_POST_SALE value.
The store number is validated against the STORE table. Numeric fields are checked for non-numeric characters.
For transactions of type SALE, RETURN, and EEXCH, saimptlog checks whether a transaction is in balance. With the introduction of the Item level tax and Payment amount lines, the balancing logic has been changed as below. Also with introduction of handling VAT/TAX, the logic of balancing has been modified as below.
-
When TAX is on in the system (system_options.default_tax_type equals SALES):
Transaction Items (Unit Retail * Unit Retail Sign * Quantity) of items which are on Regular Sale, Return, or EEXCH
+ Item Discounts (Unit Discount Amount * Unit Discount Sign * Quantity) of items which are on Regular Sale, Return, or EEXCH
+ Item Level Tax (Total Igtax Amount) of items which are on Regular Sale, Return, or EEXCH
+ Transaction Tax (Tax Amount * Tax Sign)
+ Transaction payment (Payment Amount * Payment Sign)
equals Transaction Tenders (Tender Amount * Tender Sign)
saimptlog will populate the Value field (on THEAD) with the transaction's sales value (item value minus discount value plus tax value) from the preceding calculation if it was not provided in the RTLOG. The following change is made in the sale total balancing: Value field in THEAD will be: (item value - discount value + tax value) for items which are on Regular Sale, Return, or EEXCH + payment value.
Note:
If this Value field is being used in creating some totals, then accordingly, these totals needs to be modified to accommodate the extra amount coming in.
-
When VAT is on in the system (system_options.default_tax_type in GTAX, SVAT, GTS), look for the store level VAT indicator, which tells whether the unit retail is inclusive or exclusive of VAT. The logic of balancing will vary:
Transaction Items (Unit Retail * Unit Retail Sign * Quantity) of items which are on Regular Sale, Return, or EEXCH
+ Item Discounts (Unit Discount Amount * Unit Discount Sign * Quantity) of items which are on Regular Sale, Return, or EEXCH
+ Item Level Tax (Total Igtax Amount) of items which are on Regular Sale, Return, or EEXCH (when VAT is off at the item level).
+ Transaction Tax (Tax Amount * Tax Sign)
+ Transaction Payment (Payment Amount * Payment Sign)
equals Transaction Tenders (Tender Amount * Tender Sign)
Vouchers are treated as follows:
-
If an item sold is as a gift certificate (Transaction Item, Voucher field has a value), the issued information is written to the SA_VOUCHER table.
-
If the Transaction Type is RETURN, and the Transaction Tender Type Group is voucher (VOUCH), the issued information is written to the SA_VOUCHER table.
-
If the Transaction Type is SALE and the Transaction Tender Type Group is a voucher (VOUCH), the redeemed information is written to the SA_VOUCHER table.
-
When a gift certificate is sold, the customer information should always be included. A receiving customer name value should be populated in the ref_no5 field, receiving customer state value should be populated in the ref_no6 field, and receiving customer country should be populated in the ref_no7 field. These reference fields can be changed by updating the sa_reference table, but the code needs to be modified as well. The expiration date is put in the expiration_date field in the TITEM record.
Other validations and points to consider:
-
The salesperson in the TITEM record takes precedence over the salesperson in the THEAD record.
-
If an item sold is a sub-transaction (REF) item (Transaction Item, reference item field has a value and item does not), it will be converted to the corresponding transaction level item (ITEM).
-
If an item sold is an ITEM (Transaction Item, item field has a value), it will be validated against the Merchandising item tables.
-
The corresponding Department, Class, Subclass, and Taxable Indicator will be selected from the Merchandising tables and populated for an item.
The balancing level determines whether the register or the cashier fields are required:
-
If the balancing level is R (register), the register field on the THEAD must be populated.
-
If the balancing level is C (cashier), the cashier field on the THEAD must be populated.
-
If the balancing level is S (store), neither field is required to be populated.
-
The tax_ind and the item_swiped_ind fields can only accept Y or N values. If an invalid value is passed through the RTLOG, an error will be flagged and the value will be defaulted to Y.
Transaction of Type SALE
A transaction of type SALE is generated whenever an item is sold. If a sale is for an employee, the sub-transaction type is EMP. If it is a drive-off sale, when someone drives off with unpaid gas, the sub-transaction type is DRIVEO. A special type of sale is an odd exchange, sub-transaction type EXCH, where items are sold and returned in the same transaction. If the net value of the exchange is positive, then it is a sale. If the net value is negative, it is a return.
Requirements per record type (other than what is described in the preceding Layout section):
Table 6-83 Requirements per Record Type
Record Type | Requirements |
---|---|
THEAD |
N/A |
TITEM |
|
IDISC |
|
IGTAX |
|
TTAX |
|
TPYMT |
Payment (Deposit amount) sign and Payment (Deposit) amount fields are necessary if this line is appearing. Basically, this is the accumulation of various items being considered in one transaction, which are on pick up/delivery/lay away. |
TTEND |
If the tender type group is COUPON, the Coupon Number field must be populated. The Coupon Reference Number field is optional. |
Meaning of reference number fields:
Note:
The meaning of these reference number fields may be changed through the sa_reference table. The transaction type SPLORD is the same as SALE, but the inventory will not be reserved for the orders at its line level.
Table 6-84 Meaning of Reference Number Fields
Transaction Type | Sub-transaction Type | Item Type | Tender Type Group | Reference Number Field | Meaning of Reference Field | Req? |
---|---|---|---|---|---|---|
SALE |
N/A |
N/A |
N/A |
1 |
Speed Sale Number |
Y |
SALE |
N/A |
GCN |
N/A |
5 |
Recipient Name |
N |
SALE |
N/A |
GCN |
N/A |
6 |
Recipient State |
N |
SALE |
N/A |
GCN |
N/A |
7 |
Recipient Country |
N |
SALE |
N/A |
N/A |
CHECK |
9 |
Check Number |
N |
SALE |
N/A |
N/A |
CHECK |
10 |
Driver's License Number |
N |
SALE |
N/A |
N/A |
CHECK |
11 |
Credit Card Number |
N |
SALE |
DRIVEO |
N/A |
N/A |
1 |
Incident Number |
Y |
SALE |
EMP |
N/A |
N/A |
3 |
Employee Number of the employee receiving the goods. |
N |
Table 6-85 Expected Values for Sign Fields
TRANSACTION TYPE | TITEM.Quantity Sign | TEND.Tender Sign | TTAX.Tax Sign | IDISC.Quantity Sign |
---|---|---|---|---|
SALE |
P if item is sold; N if item is returned; reverse of original item if item is voided. |
P |
P |
P if item is sold; N if item is returned; reverse of original item if item is voided. |
SALE |
P if item is on ORI, LIN, ORD, or LCO; N if item is on ORC or LCA. |
P |
P |
P if item is on ORI, LIN, ORD, or LCO; N if item is on ORC or LCA. |
Transaction of Type PVOID
This transaction is generated at the register when another transaction is being post voided. The orig_tran_no and orig_reg_no fields must be populated with the appropriate information for the transaction being post voided. The PVOID transaction must be associated with the same store day as the original transaction. If the PVOID needs to be generated after the store day is closed, the transaction needs to be created using the forms.
Transaction of type RETURN
This transaction is generated when a customer returns an item.
This type of transaction has similar record type requirements as a SALE transaction.
Meaning of reference number fields:
Note:
The assumption is that new item statuses will not come under transaction type RETURN.
If a customer wants to return the items (ORI, LIN), these will come under SALE but with item statuses as ORC or LCA.
Note:
The meaning of these reference number fields may be changed through the sa_reference table.
Table 6-86 Meaning of Reference Number Fields
Transaction Type | Sub-transaction Type | Reference Number Field | Meaning of Reference Field | Req? |
---|---|---|---|---|
RETURN |
N/A |
1 |
Receipt Indicator (Y/N) |
Y |
RETURN |
N/A |
2 |
Refund Reference Number |
N |
RETURN |
EMP |
3 |
Employee Number of the employee returning the goods. |
N |
Table 6-87 Expected Values for Sign Fields
TRANSACTION TYPE | TITEM.Quantity Sign | TEND.Tender Sign | TTAX.Tax Sign | IDISC.Quantity Sign |
---|---|---|---|---|
RETURN |
P if item is sold; N if item is returned; reverse of original item if item is voided. |
N |
N |
P if item is sold; N if item is returned; reverse of original item if item is voided |
Transaction of type SPLORD
This transaction is generated when a customer picks up an item, which is not in stock. The item status can be ORI, ORC, or ORD. (Order Initiate, Order Cancel, or Order Complete).
Transaction of type EEXCH
This transaction is generated when there is an even exchange.
This type of transaction has similar record type requirements as a SALE transaction.
It is expected that the number of items returned equals the number of items sold. However, this validation is not performed by saimptlog. An audit rule could be created for this. Saimptlog only expects that there would be at least two item records.
No tender changes hands in this transaction.
Meaning of reference number fields:
Note:
The items, which are on customer order or layaway, should not be come under this transaction type.
The meaning of these reference number fields may be changed through the sa_reference table.
Table 6-88 Meaning of Reference Number Fields
Transaction Type | Sub-transaction Type | Reference Number Field | Meaning of Reference Field | Req? |
---|---|---|---|---|
EEXCH |
N/A |
1 |
Receipt Indicator (Y/N) |
Y |
EEXCH |
EMP |
3 |
Employee Number of the employee exchanging the goods. |
N |
Transaction of type PAIDIN
This type of transaction has only one TTEND record.
A reason code is required.
Meaning of reference number fields:
Note:
The meaning of these reference number fields may be changed through the sa_reference table.
Table 6-89 Meaning of Reference Number Fields
Reason Code | Reference Number Column | Meaning | Req? |
---|---|---|---|
NSF |
1 |
NFS Check Credit Number |
N |
ACCT |
1 |
Account Number |
N |
Transaction Type PAIDOU
This type of transaction has only one TTEND record.
A reason code is required (code type REAC). If the sub-transaction type is EV or MV, the reason code comes from the non_merch_codes_head table.
If the sub-transaction type is EV or MV, then at least one field among the vendor number, vendor invoice number, payment reference number, and proof of delivery number fields should be populated.
If the sub-transaction type is EV, the vendor number comes from the partner table. If the sub-transaction type is MV, the vendor number comes from the supplier table.
Meaning of reference number fields:
Note:
The meaning of these reference number fields may be changed through the sa_reference table.
Table 6-90 Meaning of Reference Number Fields
Sub Transaction Type | Reason Code | Reference Number Column | Meaning | Req? |
---|---|---|---|---|
EV |
N/A |
2 |
Personal ID Number |
N |
EV |
N/A |
3 |
Routing Number |
N |
EV |
N/A |
4 |
Account Number |
N |
NA |
PAYRL |
1 |
Money Order Number |
N |
NA |
PAYRL |
2 |
Employee Number |
N |
NA |
INC |
1 |
Incident Number |
N |
Transaction of Type PULL
This transaction is generated when cash is withdrawn from the register.
This type of transaction has only one TTEND record.
Expected values for sign fields
Table 6-91 Expected Values for Sign Fields
TRANSACTION TYPE | TITEM.Quantity Sign | TEND.Tender Sign | TTAX.Tax Sign | IDISC.Quantity Sign |
---|---|---|---|---|
PULL |
N/A |
N |
N/A |
N/A |
Transaction of Type LOAN
This transaction is generated when cash is added to the register.
This type of transaction has only one TTEND record.
Expected values for sign fields:
Table 6-92 Expected Values for Sign Fields
TRANSACTION TYPE | TITEM.Quantity Sign | TEND.Tender Sign | TTAX.Tax Sign | IDISC.Quantity Sign |
---|---|---|---|---|
LOAN |
N/A |
P |
N/A |
N/A |
Transaction Type Cond
This transaction records the condition at the store when it opens. There can be at most one COND record containing weather information and at most one COND record containing temperature information. Both of these pieces of information may be in the same COND record. There may be any number of COND records containing traffic and construction information.
This type of transaction does not have TITEM, IDISC, IGTAX, TTAX, TPYMT, or TTEND records
Note:
The meaning of these reference number fields may be changed through the sa_reference table.
Table 6-93 Meaning of Reference Number Fields
Reference Number Column | Meaning | Req? |
---|---|---|
1 |
Weather - code type WEAT |
N |
2 |
Temperature - a signed 3 digit number. |
N |
3 |
Traffic - code_type TRAF |
N |
4 |
Construction - code_type CONS |
N |
Transaction of Type TOTAL
This transaction records the totals that are reported by the POS and OMS. The value field must be populated. Some systems generate only one transaction number for all totals. In order to avoid duplicate errors being reported, only one total transaction can have a transaction number and the subsequent ones can have blank transaction numbers. In other words, a TOTAL transaction is not required to have a transaction number.
This type of transaction does not have TITEM, IDISC, IGTAX, TTAX, TPYMT, TTEND records.
Transaction of Type METER
This transaction is generated when a meter reading of a fuel pump is taken.
This type of transaction has only TITEM records.
Meaning of reference number fields:
Note:
The meaning of these reference number fields may be changed through the sa_reference table.
Table 6-94 Meaning of Reference Number Fields
Reference Number Column | Meaning | Req? |
---|---|---|
1 |
Reading Type: (A for adjustment, S for shift change, P for price change, or C for store close) |
Y |
5 |
Opening Meter Readings |
Y |
6 |
Closing Meter Reading |
Y |
7 |
If the reading type is P for price change, the old unit retail should be placed here. Decimal places are required. |
Y |
8 |
Closing Meter Value |
Y |
Transaction of Type PUMPT
This transaction is generated when a pump test is performed. This type of transaction has only TITEM records.
Transactions of Type TANKDP
This transaction is generated when a tank dip measurement is taken.
This type of transaction has only TITEM records.
Meaning of reference number fields:
Note:
The meaning of these reference number fields may be changed through the sa_reference table.
Table 6-95 Meaning of Reference Number Fields
Reference Number Column | Meaning of Reference Field | Req? |
---|---|---|
1 |
Tank identifier |
Y |
5 |
Dip Type (FUEL, WATER, and so on) |
Y |
6 |
Dip Height Major (decimal places required) |
Y |
7 |
Dip Height Minor (decimal places required) |
Y |
Transaction of Type DCLOSE
This transaction is generated when the day closed. The transaction number for this type of transaction has to be blank.
Note:
Vouchers are minimally handled by saimptlog. Voucher information is written to the savouch file which is passed to the program savouch.pc.
-
A voucher will appear on the TITEM record only if it was sold. When saimptlog encounters a SALE transaction with a voucher, it writes the voucher to the savouch file as an I for Issued voucher.
-
A voucher will be issued when it appears on the TTEND record of transactions of type RETURN and PAIDOU. In other words, saimptlog will write it to the savouch file with status I.
-
A voucher will be redeemed when it appears on the TTEND record of transactions of type SALE and PAIDIN. In other words, saimptlog will write it to the savouch file with status R.
Vouchers may not be returned. However, a transaction of type PAIDOU may be generated when the customer exchanges a voucher for another form of tender.
Design Assumptions
Table 6-96 Sales Audit Valid Transaction Type
Transaction Code | Transaction Type |
---|---|
OPEN |
Open |
CLOSE |
Close |
COND |
Daily Store Conditions |
DCLOSE |
Day close indicator |
LOAN |
Loan |
METER |
Meter Reading for Fuel |
NOSALE |
No Sale |
PAIDIN |
Paid In |
PAIDOU |
Paid Out |
PULL |
Pull |
PUMPT |
Pump Test for Fuel |
PVOID |
Post Void (A transaction that was rung later into the register to void something that occurred earlier at the same store/day. A post void updates the original transaction's sub-transaction type.) |
REFUND |
Return of customer's original check. |
RETURN |
Return |
SALE |
Sale |
TANKDP |
Tank Dip |
TOTAL |
POS generated totals |
EEXCH |
Even exchange |
VOID |
Void (aborted transaction) |
OTHER |
Others |
REOPEN |
Reopen Store Day from POS |
DCLOSE Transaction Type
When the retailer is sending only one file to the system, SAIMPTLOG.PC marks the store day record in the Sales Audit import log as partially or fully loaded in the database by looking for a transaction type of DCLOSE. However, if the retailer is sending more than one file (as in, for example, a trickle polling situation), the retailer can specify the number of files that the system should expect in combination with the DCLOSE transaction type. This ensures that the system receives all of the files, even if the DCLOSE transaction type is, for some reason, received before the final file.
For example, if 24 files are expected over a given amount of time, and the file with the DCLOSE transaction type is, for some reason, sent before the 24th file, the Merchandising system waits until the last file arrives before marking the store day record as partially or fully loaded in the database.
The import process is completed after SAIMPTLOGFIN.PC has updated the store, data, and audit status of each store day record.
The Reopen Transaction Type
When the retailer is sending transaction of type of REOPEN for store and business day system should expect REOPEN as first transaction in the file before any additional transactions.
When secondary DCLOSE transaction is sent after REOPEN transaction type system should expect count of files since the prior DLCOSE transaction (not the full count for store/day).
SAIMPTLOGFIN.PC batch program would sum up the file counts in case of multiple DCLOSE transactions for the store day and compare against the files loaded in Sales Audit and update the store, data and audit status.
Import Total Value Adjustments From External Systems (saimpadj)
Module Name |
saimpadj.pc |
Description |
Import Total Value Adjustments From External Systems to Sales Audit |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RSA07 |
Wrapper Script |
rmswrap_in_rej.ksh |
Design Overview
This module posts external system adjustments to the Sales Audit total value table.
The sales audit adjustments are passed to the module in an external file.
Records that fail necessary validations would be written to the reject file. The input and reject file names are passed as arguments.
Restart/Recovery
Restart/recovery logic for file-based processing is used. The logical unit of work for this module is a parameterized number defined in the restart tables.
Record level locking is done on sa_store_day before updating.
I/O Specification
Integration Type |
Upload to Sales Audit |
File Name |
Determined by runtime parameters. |
Integration Contract |
IntCon000047 |
Input File Layout
Table 6-97 Input File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type (the beginning of the input file). |
File Line Identifier |
Number(10) |
Sequential number |
ID of the current line being read from input file. |
|
File head descriptor |
Char(4) |
IMPA |
Describes file line type. |
|
Current date |
Char(14) |
N/A |
File date in YYYYMMDDHH24MISS format. |
|
FDETL |
File Type Record Descriptor |
Char(5) |
FDETL |
Identifies the file record type to upload a new deal header. |
File Line Identifier |
Number(10) |
Sequential number |
ID of the current line being read from input file. |
|
Data source |
Char(6) |
N/A |
Name of the external system that produced the file. |
|
New value sign |
Char(1) |
N/A |
Sign(+/-) for the new value. |
|
New Value |
Number(20) |
N/A |
Value for the total entered by Headquarters user*10000 (4 implied decimal places). |
|
Total seq no |
Number(20) |
N/A |
Identifies the unique result set for this total ID, total revision, or store/day. Balancing group and index values. |
|
Store |
Number(10) |
N/A |
Store number for a store/day combination. |
|
Business Date |
Char(8) |
N/A |
Date for store/day combination. |
|
Total id |
Char(10) |
N/A |
ID to uniquely identify the total. |
|
Ref no 1 |
Char(30) |
N/A |
The first reference value based by which the total is grouped. |
|
Ref no 2 |
Char(30) |
N/A |
The second reference value based by which the total is grouped. |
|
Ref no 3 |
Char(30) |
N/A |
The third reference value based by which the total is grouped. |
|
FTAIL |
File Type record descriptor |
Char(5) |
FTAIL |
Identifies the file record type (the end of the input file). |
File Line Identifier |
Number(10) |
Sequential number |
ID of the current line being read from input file. |
|
File Record Counter |
Number(10) |
Sequential number |
Number of records/transactions in the current file (only records between head and tail). |
Sales Audit Voucher Upload (savouch)
Module Name |
savouch.pc |
Description |
Sales Audit Voucher Upload |
Functional Area |
Oracle Retail Sales Audit |
Module Type |
Integration |
Module Technology |
ProC |
Catalog ID |
RSA08 |
Wrapper Script |
batch_savouch.ksh |
Design Overview
Because gift certificates can enter the Sales Audit system as either items or tender, processing must be done to match up the sales and redemptions. This module is used to aggregate gift certificate and voucher records. It compares records in the input files to the database. If a record for the voucher does not exist on the database, the record is inserted. If the voucher already exists on the database, the record should be updated with the appropriate information. The voucher details are updated to SA_VOUCHER table.
Some retailers assign gift certificates to a given store, which means that before a gift certificate is sold at a store, it is assigned to a given store. When a retailer assigns a gift certificate to a given store, a record is written to the database. When the gift certificate is then sold by the store and redeemed by the consumer, this existing record must be updated to include the sale and redemption information. Some retailers choose not to assign gift certificates and instead simply sell gift certificates. In that case, the record will be inserted into the database when the gift certificate is sold and then updated when the gift certificate is redeemed.
Restart/Recovery
Restart/recovery logic for file-based processing is used. Records will be committed to the database when the commit_max_ctr defined in the RESTART_CONTROL table is reached.
I/O Specification
Integration Type |
Upload to Sales Audit |
File Name |
The input file name is not fixed; the input file name is determined by a runtime parameter. Records rejected by the import process are written to a reject file. The reject file name is not fixed; the reject file name is determined by a runtime parameter. |
Integration Contract |
IntCon000160 (SAVO) |
Input File Layout
Table 6-98 Input File Layout
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
FHEAD |
Record descriptor/ |
Char(5) |
FHEAD |
File head marker. |
Line id |
Number(10) |
0000000001 |
Unique line ID. |
|
Translator id |
Char(5) |
SAVO |
Identifies transaction type. |
|
File create date |
Char(14) |
N/A |
Vdate in YYYYMMDDHH24MISS format. |
|
Business Date |
Char(8) |
Business Date |
Vdate in YYYYMMDD format. |
|
FDETL |
Record descriptor/ |
Char(5) |
FDETL |
File head marker. |
Line id |
Number(10) |
N/A |
Unique line ID. |
|
Voucher seq Number |
Number(20) |
N/A |
Unique identifier for an entry to the SA_VOUCHER table. |
|
Voucher No |
Char(16) |
N/A |
Serial Number of the voucher. |
|
Tender Type Id |
Number(6) |
N/A |
Type of Voucher (Valid values for tender type are maintained in the pos_tender_type_head table with tender_type_group as VOUCH. |
|
Assigned Date |
Char(8) |
N/A |
Date the voucher was assigned. |
|
Assigned store |
Number(10) |
N/A |
Store to which the voucher is assigned. |
|
Issuing Date |
Char(8) |
N/A |
Date this document was issued. |
|
Issuing store |
Number(10) |
N/A |
Store this document was issued from. |
|
Issuing Register |
Char(5) |
N/A |
Register this document was issued from. |
|
Issuing Cashier |
Char(10) |
N/A |
Cashier issuing the document. |
|
Issued transaction number |
Number(20) |
N/A |
Transaction number at the time of issuance. |
|
Issued item seq number |
Number(4) |
N/A |
Will hold the item sequence of the item when the voucher is sold as an item (gift voucher). |
|
Issued tender seq number |
Number(4) |
N/A |
Will hold the tender sequence of the tender when the voucher is sold as a tender (Merchandise Credit). |
|
Issued Amount |
Number(20) |
N/A |
Amount the voucher was issued for*10000 (4 implied decimal places). |
|
Issued Customer Name |
Char(120) |
N/A |
Name of the customer, who was issued the voucher. |
|
Issued Customer Addr1 |
Char(240) |
N/A |
The address of the customer who was issued the voucher. |
|
Issued Customer Addr2 |
Char(240) |
N/A |
The second line address of the customer who was issued the voucher. |
|
Issued Customer City |
Char(120) |
N/A |
City of the customer, the voucher is issued. |
|
Issued Customer State |
Char(3) |
N/A |
State of the customer. |
|
Issued Customer Postal Code |
Char(30) |
N/A |
Postal address of the customer. |
|
Issued Customer Country |
Char(3) |
N/A |
Country of the customer where the voucher was issued. |
|
Recipient Name |
Char(120) |
N/A |
Name of the intended recipient. |
|
Recipient State |
Char(3) |
N/A |
The state of the intended recipient. |
|
Recipient Country |
Char(3) |
N/A |
The country of the intended recipient. |
|
Redemption Date |
Char(8) |
N/A |
Date the voucher was redeemed. |
|
Redemption Store |
Number(10) |
N/A |
Store at which the voucher was redeemed. |
|
Redemption Register |
Char(5) |
N/A |
Register at which the document was redeemed. |
|
Redemption cashier |
Char(10) |
N/A |
Cashier redeeming the voucher. |
|
Redemption tran seq number |
Number(20) |
N/A |
Transaction Number when the document was redeemed. |
|
Redemption Tender seq number |
Number(4) |
N/A |
This column will hold the tender sequence of the tender within the transaction when a voucher is redeemed as tender. |
|
Redemption Amount |
Number(20) |
N/A |
Amount the voucher was redeemed for*10000 (4 implied decimal places). |
|
Expiry Date |
Char(8) |
N/A |
Expiry Date. |
|
Status |
Char(1) |
N/A |
ndicator showing the document's status - issued or redeemed. Valid values = I - Issued, R - Redeemed. |
|
Comments |
Char(2000) |
N/A |
Comments. |
|
FTAIL |
Record type |
Char(5) |
FTAIL |
Describes file record and marks the end of file. |
Line id |
Number(10) |
N/A |
Unique file line ID. |
|
#lines |
Number(10) |
N/A |
Total number of transaction lines in file (not including FHEAD and FTAIL). |
Sales Posting
All sales data, whether imported from Sales Audit or directly from POS and OMS solutions, are uploaded into Merchandising using one of the following scheduled inbound integrations are included in this functional area:
For more on sales processing, see Merchandising Operations Guide – Volume 1.
Process Multiple POSU Files (uploadsales_all.ksh)
Module Name |
uploadsales_all.ksh |
Description |
Process Multiple POSU Files |
Functional Area |
Sales Posting |
Module Type |
Integration |
Module Technology |
Ksh |
Catalog ID |
RMS157 |
Wrapper Script |
batch_uploadsales.ksh |
Design Overview
The purpose of this script is to execute the uploadsales.ksh module for all POSU files that are for upload. This wrapper will simplify the sales upload process for multiple POSU files, removing the need to call the uploadsales.ksh individually for each file.
Performance Considerations
The number of threads, the amount of waiting time, number for retries, and average volume of data should be considered. RETRY_WAIT_TIME shouldn't be increased significantly.
The rows, bindsize and readsize parameter of the sqlldr command can be configured for better performance. This gives more control over how many times the inserts are committed/executed.
Upload POSU File for Processing (uploadsales.ksh)
Module Name |
uploadsales.ksh |
Description |
Upload POSU File for Processing |
Functional Area |
Sales Posting |
Module Type |
Integration |
Module Technology |
Ksh |
Catalog ID |
RMS112 |
Wrapper Script |
batch_uploadsales.ksh |
Design Overview
The purpose of this module is to upload the contents of the POSU file from Sales Audit or 3rd Party POS to the staging table for further processing.
Performance Considerations
The number of threads, the amount of waiting time, number for retries, and average volume of data should be considered. RETRY_WAIT_TIME shouldn't be increased significantly.
The rows, bindsize and readsize parameter of the sqlldr command can be configured for better performance. This gives more control over how many times the inserts are committed/executed.
I/O Specification
Integration Type |
Upload to Merchandising |
File Name |
POSU_<store>_<tran_date>_<sysdate>.<thread_val> |
Integration Contract |
IntCon000044 |
Input File Layout
Table 6-99 Input File
Record Name | Field Name | Field Type | Default Value | Description |
---|---|---|---|---|
File Header |
File Type Record Descriptor |
Char(5) |
FHEAD |
Identifies file record type |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file |
|
File Type Definition |
Char(4) |
POSU |
Identifies file as ‘POS Upload' |
|
File Create Date |
Char(14) |
N/A |
Date file was written by external system |
|
Location Number |
Number(10) |
N/A |
Store identifier |
|
Vat include indicator |
Char(1) |
N/A |
Determines whether or not the store stores values including vat. Not required but populated by Sales Audit |
|
Vat region |
Number(4) |
N/A |
Vat region the given location is in. Not required but populated by Sales Audit |
|
Currency code |
Char(3) |
N/A |
Currency of the given location. Not required but populated by sales audit |
|
Currency retail decimals |
Number(1) |
N/A |
Number of decimals supported by given currency for retails. Not required but populated by Sales Audit |
|
Transaction Header |
File Type Record Descriptor |
Char(5) |
THEAD |
Identifies transaction record type |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file |
|
Transaction Date |
Char(14) |
Transaction date |
Date sale/return transaction was processed at the POS |
|
Item Type |
Char(3) |
REF or ITM |
Item type will be represented as a REF or ITM |
|
Item Value |
Char(25) |
N/A |
The ID number of an ITM or REF |
|
Dept |
Number(4) |
N/A |
Dept of item sold or returned. Not required but populated by Oracle Retail Sales Audit |
|
Class |
Number(4) |
N/A |
Class of item sold or returned. Not required but populated by Oracle Retail Sales Audit |
|
Subclass |
Number(4) |
N/A |
Subclass of item sold or returned. Not required but populated by Oracle Retail Sales Audit |
|
Pack Indicator |
Char(1) |
N/A |
Pack indicator of item sold or returned. Not required but populated by Oracle Retail Sales Audit |
|
Item level |
Number(1) |
N/A |
Item level of item sold or returned. Not required but populated by Oracle Retail Sales Audit |
|
Tran level |
Number(1) |
N/A |
Tran level of item sold or returned. Not required but populated by Oracle Retail Sales Audit |
|
Wastage Type |
Char(6) |
N/A |
Wastage type of item sold or returned. Not required but populated by Oracle Retail Sales Audit |
|
Wastage Percent |
Number(12) |
N/A |
Wastage Percent*10000 (4 implied decimal places.), wastage percent of item sold or returned. Not required but populated by Oracle Retail Sales Audit |
|
Transaction Type |
Char(1) |
S - sales R - return |
Transaction type code to specify whether transaction is a sale or a return |
|
Drop Shipment Indicator |
Char(1) |
Y N |
Indicates whether the transaction is a drop shipment or not. If it is a drop shipment, indicator will be 'Y'. This field is not required, but will be defaulted to 'N' if blank |
|
Total Sales Quantity |
Number(12) |
N/A |
Total sales quantity * 10000 (4 implied decimal places), number of units sold at a particular location |
|
Selling UOM |
Char(4) |
N/A |
UOM at which this item was sold |
|
Sales Sign |
Char(1) |
P - positive N - negative |
Determines if the Total Sales Quantity and Total Sales Value are positive or negative |
|
Total Sales Value |
Number(20) |
N/A |
Total Sales Value * 10000 (4 implied decimal places), sales value, net sales value of goods sold |
|
Last Modified Date |
Char(14) |
N/A |
For VBO future use |
|
Catchweight Indicator |
Char(1) |
NULL |
Indicates if the item is a catch weight item. Valid values are ‘Y' or NULL |
|
Actual Weight Quantity |
Number(12) |
NULL |
Actual Weight Quantity*10000 (4 implied decimal places), the actual weight of the item, only populated if catchweight_ind = ‘Y' |
|
Sub Trantype Indicator |
Char(1) |
NULL |
Tran type for Sales Audit Valid values are ‘A', ‘D', NULL |
|
Total Igtax Value |
Number(20) |
N/A |
Total Igtax Value * 10000 (4 implied decimal places), goods sold or returned |
|
Sales Type |
Char(1) |
N/A |
Indicates whether the line item is a Regular Sale, a customer order serviced by OMS (External CO) or a customer order serviced by a store (In Store CO). Valid values are ‘R','E', or 'I' |
|
No Inventory Return Indicator |
Char(1) |
N/A |
Contains an indicator that identifies a return without inventory. This is generally a non-required column, but in case of Returns, this is required. Valid values are ‘Y' or 'N' |
|
Return Disposition |
Char(10) |
N/A |
Contains the disposition code published by RWMS as part of the returns upload to OMS |
|
Return Warehouse |
Number(10) |
N/A |
Contains the physical warehouse ID for the warehouse identifier where the item was returned |
|
Customer Order No |
Char(48) |
N/A |
This column contains the customer order number ID. |
|
Fulfillment Order No |
Char(48) |
N/A |
This column contains the fulfillment order number ID. |
|
Fulfillment Loc Type |
Char(2) |
N/A |
This column contains the fulfillment location type. Code for the fulfillment loc type from code_detail where code_type = 'FLTP' |
|
Fulfillment Loc |
Number(10) |
N/A |
This column contains the fulfillment loc ID. |
|
Orig Store |
Number(10) |
N/A |
This column contains the original store value for a Return transaction. |
|
POS Tran Id |
Number(20) |
N/A |
This column contains the unique identifier for a sale transaction. This is an Optional field. Customer needs to provide a unique identifier for a sale transaction. If not provided, Merchandising assigns a unique value from a DB sequence. |
|
Posting Store |
Number(10) |
This column contains the store at which the item sale/return should be accounted for in case of cross-store sales happening at co-located stores. It is expected that this field will be populated only for items that are checked out at a different store from the one at which they are originally managed. |
||
Transaction Tax |
File Type Record Descriptor |
Char(5) |
TTAX |
Identifies the file record type |
File Line Identifier |
Number(10) |
Specified by external system |
Sequential file line number |
|
Tax Code |
Char(6) |
N/A |
Holds the tax code associated to the item |
|
Tax Rate |
Number(20) |
N/A |
Tax rate*10000000000(10 implied decimal places), holds the tax rate for the tax code associated to the item |
|
Total Tax Value |
Number(20) |
N/A |
Total Tax value*10000(4 implied decimal places), total tax amount for the line item |
|
Transaction Detail |
File Type Record Descriptor |
Char(5) |
TDETL |
Identifies transaction record type |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file |
|
Promotional Tran Type |
Char(6) |
N/A |
Code for promotional type from code_detail, code_type = ‘PRMT' |
|
Promotion Number |
Number(10) |
N/A |
Promotion number from the Merchandising |
|
Sales Quantity |
Number(12) |
N/A |
Sales quantity*10000 (4 implied decimal places.), number of units sold in this prom type |
|
Sales Value |
Number(20) |
N/A |
Sales value*10000 (4 implied decimal places.), value of units sold in this prom type |
|
Discount Value |
Number(20) |
NA |
Discount quantity*10000 (4 implied decimal places.), value of discount given in this prom type |
|
Promotion Component |
Number(10) |
N/A |
Links the promotion to additional pricing attributes |
|
Transaction Trailer |
File Type Record Descriptor |
Char(5) |
TTAIL |
Identifies file record type |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file |
|
Transaction Count |
Number(6) |
Specified by external system |
Number of TDETL records in this transaction set |
|
File Trailer |
File Type Record Descriptor |
Char(5) |
FTAIL |
Identifies file record type |
File Line Identifier |
Number(10) |
Specified by external system |
ID of current line being processed by input file |
|
File Record Counter |
Number(10) |
N/A |
Number of records/transactions processed in current file (only records between fhead & ftail) |
Fields expected in POSU format based on changes adopted:
V16 | V16+ Customer Order Changes | V19 | |
---|---|---|---|
Fulfillment Order No |
No |
Yes |
Yes |
Fulfillment Loc Type |
No |
Yes |
Yes |
Fulfillment Loc |
No |
Yes |
Yes |
Orig Store |
No |
Yes |
Yes |
POS Tran Id |
No |
No |
Yes |
Design Assumptions
Multiple taxes for an item if sent from POS to Sales Audit, will be summed to a single tax in Merchandising and assigned one of the applicable tax codes.
Rolling up transactions to the item/store/price point
The program uploadsales.ksh requires that transactions be rolled up the item/store/price point level. The tables below give a hypothetical (though not particularly realistic) example of the type of rollup required by upload_sales.ksh.
Table 6-100 Sales for Item Number 1234 (at one store during one period of the day)
Transaction Number | Number of Items Sold | Amount (in specified currency unit) | Price point (price reason) |
---|---|---|---|
167 |
1 |
9.99 |
Regular |
395 |
2 |
18.00 |
Promotional |
843 |
1 |
7.99 |
Clearance |
987 |
3 |
27.00 |
Promotional |
1041 |
1 |
9.99 |
Regular |
1265 |
4 |
31.96 |
Clearance |
Note:
The variation of the price per item in different transactions. This is the result of the price applied at the time of sale—the price point. Now look at the next table that shows the same transactions rolled up by item and price point.
Table 6-101 Sales for Item Number 1234
Number of Items Sold | Price Reason (price point) | Total Amount for Item-Price point (in currency) |
---|---|---|
2 |
Regular price |
19.98 |
5 |
Promotional price |
45.00 |
5 |
Clearance price |
39.95 |
uploadsales.ksh takes the totals and looks for any discounts for transactions in the POSU file. It applies the discounts to an expected total dollar amount using the price listed for that item from the pricing table (PRICE_HIST). It next compares this expected total against the reported total. If the program finds a discrepancy between the two amounts, it is reported. If the two totals match, the rollup is considered valid. If value-added tax (VAT) is included in any sales transaction amounts, it is removed from those transactions prior to the validation process.
Forecasting
Merchandising has the ability to upload forecast data from an external source. Forecasts can be uploaded by week or by day.
Scheduled forecast integration processes include:
Daily Demand Item Forecast Subscription API
This section describes the Daily Demand Item Forecast Subscription API.
Design Overview
This API is used to import daily forecast data from Oracle Retail Demand Forecast Cloud Service (RDFCS) to Merchandising. It uses BDI (Bulk Data Integration), which is an integration layer that facilitates the bulk transfer of information between solutions. On this particular integration, the data flow is from RDFCS to BDI, and then BDI to Merchandising. To accomplish this data transfer, BDI will invoke a Merchandising owned API that will pull data from the BDI integration layer and load into the Merchandising daily forecast table (DAILY_ITEM_FORECAST).
Note:
The job that manages this import is scheduled in RDFCS, rather than as part of the Merchandising batch schedule.
Weekly Demand Item Forecast Subscription API
This section describes the Weekly Demand Item Forecast Subscription BDI.
Design Overview
This API is used to import weekly forecast data from Oracle Retail Demand Forecast Cloud Service (RDFCS) to Merchandising. It uses BDI (Bulk Data Integration), which is an integration layer that facilitates the bulk transfer of information between solutions. On this particular integration stream, the data flow is from RDFCS to BDI, and then BDI to Merchandising. To accomplish this data transfer, BDI will invoke a Merchandising-owned API that will pull data from BDI integration layer BDI table and load into the Merchandising weekly forecast table (ITEM_FORECAST). This process begins by preserving the previous 4 weeks of forecasted sales data in ITEM_FORECAST_HIST and then the ITEM_FORECAST table is truncated. Then the new forecast data is imported.
Note:
The job that manages this import is scheduled in RDFCS, rather than as part of the Merchandising batch schedule.
Weekly/Daily Item Forecast Upload (load_item_forecast)
Module Name |
load_item_forecast.ksh |
Description |
Load daily/weekly item forecast from Oracle Retail Demand Forecasting (RDF) Cloud Service |
Functional Area |
Integration - Forecast |
Module Type |
Integration |
Module Technology |
Ksh |
Catalog ID |
N/A |
Wrapper Script |
rmswrap_shell_in.ksh |
Design Overview
This script loads item forecast data into the Merchandising forecast tables.
The forecast data comes from Demand Forecasting in a CSV (comma separated) format file. Merchandising expects a single comma-delimited input file (that is, a csv file) in the format specified in the sqlldr control scripts load_item_forecast.ctl (for Weekly) and load_daily_item_forecast.ctl (for Daily). Please refer to the "Integration Contract" for more details. A run-time parameter (that is, run type) of ‘D' or ‘W' indicates whether the Daily or Weekly forecast data is being loaded into Merchandising. If the forecast is a daily forecast, information is written to the DAILY_ITEM_FORECAST table. If the forecast is a weekly forecast, information is written to the ITEM_FORECAST table. Depending on the run type parameter, the batch truncates the respective forecast table prior to loading.
Restart/Recovery
Evaluate the successful load of the data.
In case of any failures:
SQL load – SQL load dumps invalid records that do not meet certain technical requirements (that is, data type inconsistencies, and so on). The rejected record is written either to a bad file or to a discard file. The discard file contains records that do not satisfy conditions such as missing or invalid record types. Records with other technical issues are written to the bad file.
Note:
A non-fatal code is returned by the program and a message will be written to the log file if reject files are created.
User Action: When such conditions exist, you may update either the bad or the discard file and attempt to reload using the same files. You may also fix the data input file and reload, so that the item forecast tables will be truncated and upload item forecast tables with the corrected the data.
Integration Contract
If a run-time parameter of 'weekly' is used, the input file is a single comma-delimited file (that is, a CSV file):
Field Name | Field Type | Required | Description |
---|---|---|---|
EOW_DATE |
Date(8) |
Yes |
Item_forecast.eow_date (YYYYMMDD) |
ITEM |
Char(25) |
Yes |
Item_forecast.item |
LOC |
Char(10) |
Yes |
Item_forecast.loc |
FORECAST_SALES |
Double(14) |
Yes |
Item_forecast.forecast_sales Note - this field can contain decimal quantities. Unlike quantity fields in Merchandising ProC Batch files, this qty field is not assumed to be extended to significant digits. |
FORECAST_STD_DEV |
Double(14) |
Yes |
Item_forecast.forecast_std_dev Note - this field can contain decimal quantities. Unlike quantity fields in Merchandising ProC Batch files, this qty field is not assumed to be extended to significant digits. |
If a run-time parameter of 'daily' is used, the input file is a single comma-delimited file (that is, a CSV file):
Field Name | Field Type | Required | Description |
---|---|---|---|
DATA_DATE |
Date(8) |
Yes |
Daily_item_forecast.data_date (YYYYMMDD) |
ITEM |
Char(25) |
Yes |
Daily_item _forecast.item |
LOC |
Char(10) |
Yes |
Daily_item _forecast.loc |
FORECAST_SALES |
Double(14) |
Yes |
Daily_item_forecast.forecast_sales Note - this field can contain decimal quantities. Unlike quantity fields in Merchandising ProC Batch files, this qty field is not assumed to be extended to significant digits. |
FORECAST_STD_DEV |
Double(14) |
Yes |
Daily_item_forecast.forecast_std_dev Note - this field can contain decimal quantities. Unlike quantity fields in Merchandising ProC Batch files, this qty field is not assumed to be extended to significant digits. |
Footnote Legend
Footnote 1:Input parameter is not required and is defaulted to N that will disable the generate the retry file functionality for locked records.