Mirror of Oracle documentation

Converted for search and offline reading. Authoritative source: Oracle. Diagrams and some complex tables are simplified — check the PDF when in doubt.

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 masterdetail, 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	Char(14)	Specified by	Used to force unique
	Control Number		external system	transaction check.

Record Name	Field Name	Field Type	Default Value	Description
	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.

When will files be unzipped?

This will be unzipped when it is moved to the input folder (data/in).

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.

How will rejected files be reprocessed?

Reprocessing the files would require manual intervention. Upload a corrected file to Object Storage with an “incoming/” prefix. Ensure the filename is the same as the rejected file.

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 .zip

Template name must correspond to
S9T_TEMPLATE.TEMPLATE_KEY

poindbatch.ksh Input file name is provided by user.
Must end in *.xml .zip

Template name must correspond to
S9T_TEMPLATE.TEMPLATE_KEY

replindbatch.ksh Input file name is provided by user.
Must end in *.xml .zip

Template name must correspond to
S9T_TEMPLATE.TEMPLATE_KEY

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* No zip file.

RDWF* Input file is from saexpdw.

RDWS*
RDWC*

lcmt730 lcmt730 lcmt730.zip

lcmt798 lcmt798 lcmt798.zip

lifstkup lifstkup lifstkup.zip

ordinvupld ORIN* ORIN*.zip

sa_rules_total_upload.ksh

sartexp_*

sartexp*.zip
saimptlogfin	storedayfile	No zip file.
		Input file is from sagetref.
saimptlogi	RTLOG__.dat	RTLOG*.zip

Batch	Input File Name	Zip File Name
saimptlogtdup_upd	storedayfile storeposfile	No zip file. Input file is from sagetref.
savouch	savouch	savouch.zip
stlgdnld	stlgdnld	stlgdnld.zip
stockcountupload.ksh	STK*.	STK*.zip
trandataload.ksh	trandataload	trandataload.zip
uploadsales.ksh	POSU_<tran_date> .<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:

Brand Publication API (BDI_Brand_Fnd_PF_From_RMS_EOW_JOB)
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 Export (export_diffgrp.ksh)
• Diff Group Publication API (BDI_DiffGrp_Fnd_PF_From_RMS_JOB) • Diff ID and Type Export (export_diffs.ksh) • Diff ID Publication API (BDI_Diff_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) • Merchandise Hierarchy Export (export_merchhier.ksh)
Organization Hierarchy Publication API (BDI_OrgHier_Fnd_PF_From_RMS_JOB)
Organizational Hierarchy Export (export_orghier.ksh)
Partner Address Publication API (BDI_PartnerAddr_Fnd_PF_From_RMS_JOB)
• Partner Org Unit Publication API (BDI_PartOrgUnit_Fnd_PF_From_RMS_JOB) • Partner Publication API (BDI_Partner_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) • Store Publication API (BDI_Store_Fnd_PF_From_RMS_JOB)
Stores Export (export_stores.ksh)
Supplier Address Publication API (BDI_SupplierAddr_Fnd_PF_From_RMS_JOB)
• Sups Publication API (BDI_Supplier_Fnd_PF_From_RMS_JOB)
Tax Download - Brazil (taxdnld)
Ticket Download (tcktdnld)
UDA Publication API (BDI_Uda_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)
• VAT Codes, Regions, and Rates Export (export_vat.ksh)
VAT Publication API (BDI_Vat_Fnd_PF_From_RMS_JOB)
Warehouse (BDI_Wh_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.

Functional Area

Foundation Data

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 feld contains the brand name.
Brand Description	Always	This feld contains the description of the brand.

Updated Brand

Updating a brand triggers a message to be sent to notify external systems. Brand name and description are sent as part of the update message.

Deleted Brand

Deleting a brand triggers a message sent to notify external systems. The brand name is sent as part of the delete message.

Table 6-2 Brand – Delete

Message Element	Included?	Notes
Brand name	Always	This feld contains the brand name being deleted.

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

Message Types	Message Type Description	XML Schema Definition (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.

Functional Area

Foundation

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.

Data Definition XML

The BDI interface staging tables are generated based on the XML schema definition

Data Flow	Description	XML Schema Definition (XSD)
Calendar	Calendar upload to BDI	Calendar_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
CALENDAR_OUT	No	Yes	No	No
V_BDI_DAY_LEVEL_CALENDAR	Yes	No	No	No

Code Detail Publication API (BDI_CodeDetail_Fnd_PF_From_RMS_JOB)

This section describes the Code Detail Publication BDI.

Functional Area

Cross Pillar

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.

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.

Data Definition XML

The BDI interface staging tables are generated based on the XML schema definition

Data Flow	Description	XML Schema Definition (XSD)
Code Detail	Code Detail upload to BDI	CodeDetail_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
CODE_DETAIL_OUT	No	Yes	No	No
CODE_DETAIL	Yes	No	No	No

Code Head Publication API (BDI_CodeHead_Fnd_PF_From_RMS_JOB)

This section describes the Code Head Publication BDI.

Functional Area

Cross Pillar

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.

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)
Code Head	Code Head upload to BDI	CodeHead_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
CODE_HEAD_OUT	No	Yes	No	No
CODE_HEAD	Yes	No	No	No

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.

Functional Area

Foundation

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.

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	Company Closed Exceptions upload to	CompanyClosedExcep_Fnd_BdiInterfaceModule.xml
Exceptions	BDI

Tables

TABLE	SELECT	INSERT	UPDATE	DELETE
COMPANY_CLOSED_OUT	No	Yes	No	No
COMPANY_CLOSED_EXCEP_OUT	No	Yes	No	No
COMPANY_CLOSED_ECXEP	Yes	No	No	No
COMPANY_CLOSED	Yes	No	No	No

Currency Conversion Rates Publication API

(BDI_CurrConvRates_Fnd_PF_From_RMS_EOW_JOB)

This section describes the Currency Conversion Rates Publication BDI.

Functional Area

Foundation

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 Merchandisingowned 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.

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)
Currency Conversion	Currency Conversion Rates	CurrConvRates_Fnd_BdiInterfaceModule.xml
Rates	upload to BDI

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
CURR_CONV_RATES_OUT	No	Yes	No	No
MV_CURRENCY_CONVERSION_RA TES	Yes	No	No	No
SYSTEM_OPTIONS	Yes	No	No	No
STORE	Yes	No	No	No
WH	Yes	No	No	No

Delivery Slot Publication API (BDI_DeliverySlot_Fnd_PF_From_RMS_JOB)

This section describes the Delivery Slot Publication BDI.

Functional Area

Cross Pillar

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.

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)
Delivery Slot	Delivery Slot upload to BDI	DeliverySlot_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
DELIVERY_SLOT_OUT	No	Yes	No	No
DELIVERY_SLOT	Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

I/O Specification

Integration Type Extract from Merchandising File Name diffgrphdr_date_[full/delta]_[#ofLines].dat diffgrpdtl_date_[full/delta]_[#ofLines].dat Integration Contract IntCon000212.html IntCon000213.html

Design Assumptions

N/A

Diff Group Publication API (BDI_DiffGrp_Fnd_PF_From_RMS_JOB)

This section describes the Diff Group Publication BDI.

Functional Area

Foundation

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.

Data Definition XML

The BDI interface staging tables are generated based on the XML schema definition

Data Flow	Description	XML Schema Definition (XSD)
Diff Group	Diff Group upload to BDI	DiffGrp_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
DIFF_GRP_OUT	No	Yes	No	No
DIFF_GRP_DTL_OUT	No	Yes	No	No
DIFF_GROUP_HEAD	Yes	No	No	No
DIFF_TYPE	Yes	No	No	No
DIFF_GROUP_DETAIL	Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

I/O Specification

Integration Type Extract from Merchandising File Name diffs_date_[full/delta]_[#ofLines].dat Integration Contract IntCon000206.html

Design Assumptions

N/A

Diff ID Publication API (BDI_Diff_Fnd_PF_From_RMS_JOB)

This section describes the Diff ID Publication BDI.

Functional Area

Foundation

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.

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 Type	Description	XML Schema Definition (XSD)
Diff Id	Diff Id upload to BDI	Diff_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
DIFF_OUT	No	Yes	No	No
DIFF_IDS	Yes	No	No	No
DIFF_TYPE	Yes	No	No	No

Finisher Address Publication API (BDI_FinisherAddr_Fnd_PF_From_RMS_JOB)

This section describes the Finisher Address Publication BDI.

Functional Area

Foundation

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.

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)
Finisher Address	Finisher Address upload to BDI	FinisherAddr_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
FINISHER_ADDR_OUT	No	Yes	No	No
ADD_TYPE_MODULE	Yes	No	No	No
WH	Yes	No	No	No
V_ADD_TYPE_TL	Yes	No	No	No
COUNTRY	Yes	No	No	No
STATE	Yes	No	No	No
ADDR	Yes	No	No	No
PARTNER	Yes	No	No	No

Location Closed Publication API (BDI_LocClosed_Fnd_PF_From_RMS_JOB)

This section describes the Location Closed Publication BDI.

Functional Area

Foundation

Design Overview

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.

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)
Location	Location Closed upload	LocationClosed_Fnd_BdiInterfaceModule.xml
Closed	to BDI

Tables

TABLE	SELECT	INSERT	UPDATE	DELETE
LOCATION_CLOSED_OUT	No	Yes	No	No
LOCATION_CLOSED	Yes	No	No	No

Merch Hierarchy Publication API (BDI_MerchHier_Fnd_PF_From_RMS_JOB)

This section describes the Merch Hierarchy Publication BDI.

Functional Area

Foundation

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.

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)
Merchandise	Merchandise Hierarchy upload	MerchHier_Fnd_BdiInterfaceModule.xml
Hierarchy	to BDI

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
MERCH_HIER_OUT	No	Yes	No	No
DIVISION	Yes	No	No	No
COMPHEAD	Yes	No	No	No
GROUPS	Yes	No	No	No
DEPS	Yes	No	No	No
CLASS	Yes	No	No	No
SUBCLASS	Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

I/O Specification

Integration Type Extract from Merchandising File Name merchhierarchy_[Date]_[full/delta]_[#ofLines].dat Integration Contract IntCon000207

Design Assumptions

N/A

Organization Hierarchy Publication API (BDI_OrgHier_Fnd_PF_From_RMS_JOB)

This section describes Organization Hierarchy Publication BDI.

Functional Area

Foundation

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 Merchandisingowned 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.

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.

Table Impact

Data Flow	Description		XML Sche	ma Definition (X	SD)
Org Hierarchy	Org Hierarchy u	pload to BDI	OrgHier_Fn	d_BdiInterfaceM	odule.xml
TABLE		SELECT	INSERT	UPDATE	DELETE
ORG_HIER_OUT		No	Yes	No	No
WH		Yes	No	No	No
AREA		Yes	No	No	No
CHAIN		Yes	No	No	No
COMPHEAD		Yes	No	No	No
DISTRICT		Yes	No	No	No
REGION		Yes	No	No	No
STORE		Yes	No	No	No
WH		Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

I/O Specification

Integration Type Extract from Merchandising File Name orghierarchy_[Date]_[full/delta]_[#ofLines].dat Integration Contract IntCon000203

Design Assumptions

N/A

Partner Address Publication API (BDI_PartnerAddr_Fnd_PF_From_RMS_JOB)

This section describes the Partner Address Publication BDI.

Functional Area

Foundation

Business Overview

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.

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)
Partner Address	Partner Address upload to BDI	PartnerAddr_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
PARTNER_ADDR_OUT	No	Yes	No	No
ADDR	Yes	No	No	No
V_ADD_TYPE_TL	Yes	No	No	No
ADD_TYPE_MODULE	Yes	No	No	No
STATE	Yes	No	No	No
COUNTRY	Yes	No	No	No
PARTNER	Yes	No	No	No

Partner Org Unit Publication API (BDI_PartOrgUnit_Fnd_PF_From_RMS_JOB)

This section describes the Partner Org Unit Publication BDI.

Functional Area

Foundation

Business Overview

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.

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

Table Impact

Data Flow	Description	XML	Schema Defini	tion (XSD)
Partner Org Unit	Partner Org Unit u BDI	pload to Partn	erOrgUnit_Fnd	_BdiInterfaceMo	dule.xml
TABLE		SELECT	INSERT	UPDATE	DELETE
PARTNER_ORG_	UNIT_OUT	No	Yes	No	No
PARTNER_ORG_	UNIT	Yes	No	No	No

Partner Publication API (BDI_Partner_Fnd_PF_From_RMS_JOB)

This section describes the Partner Publication BDI.

Functional Area

Foundation

Business Overview

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.

Data Definition XML

The BDI interface staging tables are generated based on the XML schema definition

Data Flow	Description	XML Schema Definition (XSD)
Partner	Partner upload to BDI	Partner_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
PARTNER_OUT	No	Yes	No	No
PARTNER	Yes	No	No	No

Store Address Publication API (BDI_StoreAddr_Fnd_PF_From_RMS_JOB)

This section describes the Store Address Publication BDI.

Functional Area

Foundation

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.

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)
Store Addr	Store Address upload to BDI	StoreAddr_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
STORE_ADDR_OUT	No	Yes	No	No
V_ADD_TYPE_TL	Yes	No	No	No
ADDR	Yes	No	No	No
STORE	Yes	No	No	No
STATE	Yes	No	No	No
COUNTRY	Yes	No	No	No
ADD_TYPE_MODULE	Yes	No	No	No

Store Hours Publication API (BDI_StoreHours_Fnd_PF_From_RMS_JOB)

This section describe the Store Hours Publication BDI.

Function Area

Foundation

Design Overview

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.

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)
Store	Store upload to BDI	StoreHours_Fnd_BdiInterfaceModule.xml

Tables

TABLE	SELECT	INSERT	UPDATE	DELETE
STORE_HOURS_OUT	No	Yes	No	No
STORE_HOURS	Yes	No	No	No

Store Publication API (BDI_Store_Fnd_PF_From_RMS_JOB)

This section describes the Store Publication BDI.

Functional Area

Foundation

Business Overview

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.

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)
Store	Store upload to BDI	Store_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
STORE_OUT	No	Yes	No	No
CODE_DETAIL	Yes	No	No	No
CHANNELS	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

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

I/O Specification

Integration Type Extract from Merchandising File Name store_[Date]_[full/delta]_[#ofLines].datstoreaddr_[Date]_[full/ delta]_[#ofLines].dat Integration Contract IntCon000204 IntCon000205

Design Assumptions

N/A

Supplier Address Publication API (BDI_SupplierAddr_Fnd_PF_From_RMS_JOB)

This section describes the Supplier Address Publication BDI.

Functional Area

Foundation

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.

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)
Supplier	Supplier Address upload to	SupplierAddr_Fnd_BdiInterfaceModule.xml
Address	BDI

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
SUPPLIER_ADDR_OUT	No	Yes	No	No
ADDR	Yes	No	No	No
V_ADD_TYPE_TL	Yes	No	No	No
STATE	Yes	No	No	No
COUNTRY	Yes	No	No	No
SUPS	Yes	No	No	No
ADD_TYPE_MODULE	Yes	No	No	No

Sups Publication API (BDI_Supplier_Fnd_PF_From_RMS_JOB)

This section describes the Sups Publication BDI.

Functional Area

Foundation

Business Overview

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.

Data Definition XML

The BDI interface staging tables are generated based on the XML schema definition

Data Flow	Description	XML Schema Definition (XSD)
Supplier	Supplier upload to BDI	Supplier_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
SUPS_OUT	No	Yes	No	No
SUPS	Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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 ’YYYMMDDHHMI SS’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_t	Char(6)	S - Store	Item number type
	ype		W - Warehouse
	format_id	Char(1)	N/A	Format id
	prefix	Char(2)	N/A	Prefix
	ref_item	Char(25)	N/A	Reference Item
	ref_item_numb er_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_bas is	Char(1)	N/A	Calculation basis

Table 6-3 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

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

Table 6-4 (Cont.) tcktdnld.pc - Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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

Design Assumptions

N/A

UDA Publication API (BDI_Uda_Fnd_PF_From_RMS_JOB)

This section describes the UDA Publication BDI.

Functional Area

Foundation

Business Overview

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.

Data Definition XML

The BDI interface staging tables are generated based on the XML schema definition

Data Flow	Description	XML Schema Definition (XSD)
UDA	UDA upload to BDI	Uda_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
UDA_OUT	No	Yes	No	No
UDA	Yes	No	No	No

UDA Values Publication API (BDI_UdaValues_Fnd_PF_From_RMS_JOB)

This section describes the UDA Values Publication BDI.

Functional Area

Foundation

Business Overview

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.

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)
UDA Values	UDA Values upload to BDI	UdaValues_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
UDA_VALUES_OUT	No	Yes	No	No
UDA_VALUES	Yes	No	No	No

UOM Class Publication API (BDI_UomClass_Fnd_PF_From_RMS_JOB)

This section describes the UOM Class Publication BDI.

Functional Area

Cross Pillar

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.

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)
Uom Class	Uom Class upload to BDI	UomClass_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
UOM_CLASS_OUT	No	Yes	No	No
UOM_CLASS	Yes	No	No	No

UOM Conversion Publication API (BDI_UomConversion_Fnd_PF_From_RMS_JOB)

This section describes the UOM Conversion BDI.

Functional Area

Cross Pillar

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 Merchandisingowned 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.

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)
Uom	Uom Conversion upload to	UomConversion_Fnd_BdiInterfaceModule.xml
Conversion	BDI

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
UOM_CONVERSION_OUT	No	Yes	No	No
UOM_CONVERSION	Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

I/O Specification

Integration Type Extract from Merchandising File Name vat_date_[full/delta]_[#ofLines].dat Integration Contract IntCon000215

Design Assumptions

N/A

VAT Publication API (BDI_Vat_Fnd_PF_From_RMS_JOB)

This seciton describes the VAT Publication BDI.

Functional Area

Foundation

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.

Data Definition XML

The BDI interface staging tables are generated based on the XML schema definition.

Data Flow	Description	XML Schema Definition (XSD)
Vat	Vat upload to BDI	Vat_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
VAT_OUT	No	Yes	No	No
VAT_CODES	Yes	No	No	No
VAT_CODE_RATES	Yes	No	No	No
VAT_REGION	Yes	No	No	No

Warehouse (BDI_Wh_Fnd_PF_From_RMS_JOB)

This section describes Warehouse Publication BDI.

Functional Area

Foundation

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.

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)
Warehouse	Warehouse upload to BDI	Wh_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
WH_OUT	No	Yes	No	No
WH	Yes	No	No	No

Warehouse Address Publication API (BDI_WhAddr_Fnd_PF_From_RMS_JOB)

This section describes Warehouse Address Publication BDI.

Functional Area

Foundation

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.

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)
Warehouse Address	Warehouse Address upload to BDI	WhAddr_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
WH_ADDR_OUT	No	Yes	No	No
ADDR	Yes	No	No	No

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 Export (export_itemloc.ksh)
Item Location Publication API (BDI_ItemLoc_Fnd_PF_From_RMS_JOB)
Item Master Export (export_itemmaster.ksh)
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)
• Item VAT Rates Export (export_itemvat.ksh) • Pack Item Publication API (BDI_PckitemBrkout_Fnd_PF_From_RMS_JOB) • POS Configuration Data to 3rd Party POS (poscdnld) • Price History Publication API (BDI_PriceHist_Fnd_PF_From_RMS_JOB) • Related Items Export (export_relitem.ksh) • 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) • Capture Item Inventory Records (maintain_ilseod_hist.ksh)
Maintain Item Cost Records (maintain_isc_hist.ksh)

Item Image Publication API (BDI_ItemImage_Fnd_PF_From_RMS_JOB)

This section describes the Item Image Publication BDI.

Functional Area

Item

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.

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)
Item Image	Item Image upload to BDI	ItemImage_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
ITEM_IMAGE_OUT	No	Yes	No	No
ITEM_MASTER	Yes	No	No	No
ITEM_IMAGE	Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

I/O Specification

Integration Type Extract from Merchandising File Name itemloc_[#date]_[#loc_type]_[#location]_[full/delta]_[#ofLines].dat itemhdr_[#date]_[#store_id]_delta_[#ofLines].dat Integration Contract IntCon000209 IntCon000208

Design Assumptions

N/A

Item Location Publication API (BDI_ItemLoc_Fnd_PF_From_RMS_JOB)

This section describes the Item Location Publication BDI.

Functional Area

Foundation

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.

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)
Item Location	Item Location upload to BDI	ItemLoc_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
ITEM_LOC_OUT	No	Yes	No	No
ITEM_LOC	Yes	No	No	No
ITEM_LOC_TRAITS	Yes	No	No	No
STORE	Yes	No	No	No
WH	Yes	No	No	No
PARTNER	Yes	No	No	No
ITEM_MASTER	Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

I/O Specification

Integration Type Extract from Merchandising File Name itemhdr_[#date]_corp_[full/delta]_[#ofLines].dat itemhdr_[#date]_[location]_full_[#ofLines].dat IntCon000208

Integration Contract

Design Assumptions

N/A

Item Master Publication API (BDI_ItemHdr_Fnd_PF_From_RMS_JOB)

This section describes the Item Master Publication BDI.

Functional Area

Foundation

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.

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

Data Flow	Description	XML Schema Definition (XSD)
Item Master	Item Master upload to BDI	ItemHdr_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
ITEM_HDR_OUT	No	Yes	No	No
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_OPTIONS	Yes	No	No	No

Item Supplier Country Dimensions Publication API (BDI_ItSupCtryDim_Fnd_PF_From_RMS_JOB)

This section describes the Item Supplier Country Dim Publication BDI.

Functional Area

Item

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 Merchandisingowned 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.

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)
Item Supplier	Item supplier country Dim	ItSupCtryDim_Fnd_BdiInterfaceModule.xml
Country Dim	upload to BDI

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
ITEM_SUP_CTY_DIM_OUT	No	Yes	No	No
ITEM_MASTER	Yes	No	No	No
ITEM_SUPP_COUNTRY_DIM	Yes	No	No	No

Item Supplier Country Publication API (BDI_ItSupCtry_Fnd_PF_From_RMS_JOB)

This section describes the Item Supplier Country Publication BDI.

Functional Area

Item

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 Merchandisingowned 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.

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)
Item Supplier Country	Item supplier country upload to BDI	ItSupCtry_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
ITEM_SUPP_COUNTRY_OUT	No	Yes	No	No
ITEM_MASTER	Yes	No	No	No
ITEM_SUPP_COUNTRY	Yes	No	No	No

Item Supplier Manufacturing Country Publication API (BDI_ItSupManCtry_Fnd_PF_From_RMS_JOB)

This section describes the Item Supplier Manufacturing Country Publication BDI.

Functional Area

Item

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.

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)
Item Supplier Manufacturing	Item supplier Manufacturing	ItSupManCtry_Fnd_BdiInterfaceModu
Country	Country upload to BDI	le.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
ITEM_SUP_MAN_CTY_OUT	No	Yes	No	No
ITEM_MASTER	Yes	No	No	No
ITEM_SUPP_MANU_COUNTRY	Yes	No	No	No

Item Supplier Publication API (BDI_ItemSupp_Fnd_PF_From_RMS_JOB)

This section describes the Item Supplier Publication BDI.

Functional Area

Item

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.

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

Table Impact

Data Flow Description	X	ML Schema De	finition (XSD)
Item supplier Item Supplier uplo	ad to BDI I	temSupplier_Fn	d_BdiInterfaceMo	dule.xml
TABLE	SELECT	INSERT	UPDATE	DELETE
ITEM_SUPPLIER_OUT	No	Yes	No	No
ITEM_MASTER	Yes	No	No	No
ITEM_SUPPLIER	Yes	No	No	No

Item Supplier UOM Publication API (BDI_ItemSuppUom_Fnd_PF_From_RMS_JOB)

This section describes the Item Supplier UOM Publication BDI.

Functional Area

Item

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 Merchandisingowned 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.

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)
Item supplier UOM	Item Supplier UOM upload to BDI	ItemSuppUom_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
ITEM_SUPP_UOM_OUT	No	Yes	No	No
ITEM_MASTER	Yes	No	No	No
ITEM_SUPP_UOM	Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

I/O Specification

Integration Type Extract from Merchandising File Name vatitem_[#date]_corp_[full/delta]_[#ofLines].dat vatitem_[#date]_[location]_[full/delta]_[#ofLines].dat Integration Contract IntCon000214

Design Assumptions

N/A

Pack Item Publication API (BDI_PckitemBrkout_Fnd_PF_From_RMS_JOB)

This section describes the Pack Item Publication BDI.

Functional Area

Item

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.

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)
Pack Item	Pack Item upload to BDI	PackItem_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
PACK_ITEM_OUT	No	Yes	No	No
ITEM_MASTER	Yes	No	No	No
PACKITEM	Yes	No	No	No

Populate ITEM_LOC_SOH_EOD table for RDE Extract (maintain_ilseod_hist)

Module Name	maintain_ilseod_hist.ksh
	(ilseodhistsqls.pls/ ilseodhistsqlb.pls)

Description	Populate`ITEM_LOC_SOH_EOD_HIST`
	table for RDE Extract
Functional Area	Stock Ledger
Module Type	Business Processing
Module Technology	PLSQL
Catalog ID
Wrapper Script	rmswrap_shell.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch program copies current data from ITEM_LOC_SOH_EOD into ITEM_LOC_SOH_EOD_HIST and drops old partitions based on defined retention days

( SYSTEM_OPTIONS.ILS_EOD_HIST_RETENTION_DAYS ). It inserts a row into the

RMS_RDE_BATCH_STATUS table stating that the INVENTORY_SNAPSHOT staging is complete for the business date.

Restart/Recovery

In the case of a restart from failure, it rebuilds records on ITEM_LOC_SOH_EOD_HIST for the current business date.

Design Assumptions

N/A

Populate ITEM_SUPP_COUNTRY_HIST and ITEM_SUPP_COUNTRY_LOC_HIST table (maintain_isc_hist)

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch program copies data from ITEM_SUPP_COUNTRY into ITEM_SUPP_COUNTRY_HIST and drops old partitions based on defined retention days

( SYSTEM_OPTIONS.ISC_HIST_RETENTION_DAYS ). It also populates ITEM_SUPP_COUNTRY_LOC_HIST based on ITEM_SUPP_COUNTRY_LOC . The data is as of the SCN stored in the FLASHBACK_SNAPSHOT_INFO table.

This accepts an optional parameter of I_business_date which will then be used to extract the SCN data from FLASHBACK_SNAPSHOT_INFO that will be the basis for the extract from ITEM_SUPP_COUNTRY and ITEM_SUPP_COUNTRY_LOC . The SCN stored at this table should still be accessible. If the I_business_date input parameter is not provided, it uses the current PERIOD.VDATE .

This job should not be skipped. If it is skipped as part of the nightly batch, it should run immediately after the nightly has completed with the I_business_date equal to the latest

business_date stored in the FLASHBACK_SNAPSHOT_INFO table. The data that is available to extract is based on the availability of the redo data for the SCN query.

Restart/Recovery

In the case of a restart from failure, it rebuilds records on ITEM_SUPP_COUNTRY_HIST and ITEM_SUPP_COUNTRY_LOC_HIST for the business date (current vdate is no input parameter passed in).

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Table 6-5 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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	N/A
			’AP’ - Applicant
			’BK’ - Bank
			’BR’ - Broker
			’CN’ - Coonsignee
			’CO’ -
			Consolidator
			’FA’ - Factory
			’FF’ - Freight Forwarder
			’IM’ - Importer
			’SU’ - Supplier
	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

Table 6-5 (Cont.) Output File Layout

Field Name	Field Type	Default Value	Description
POS Product Restriction	Char(6)	‘PPRT’ include: ‘STMP’ - Food	N/A
Type		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
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	Char(14)	N/A	Date on which a
Restriction			specified product restriction is applied in ’YYYYMMDD HHMMSS’ format
Before Time Restriction	Char(6)	N/A	N/A
After Time	Char(6)	N/A	N/A
Restriction
Day Restriction	Char(6)	N/A	N/A
Max Qty	Number(124)	N/A	N/A
Amount	,

Table 6-5 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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	N/A
			’ERR’ - Error, ‘SOCASS’ - Social Assistance, ‘TERM’ -
			Termination Record,
			‘DRIVEO’ - Drive Off,
			‘EBS’ - Electronic Benefits ( Food Stamps)
	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	N/A
			’D’ - Delete
			’C’ - Change
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

Table 6-5 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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

Design Assumptions

N/A

Price History Publication API (BDI_PriceHist_Fnd_PF_From_RMS_JOB)

This section describes the Price History Publication BDI.

Functional Area

Foundation

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.

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)
Price History	Price History upload to BDI	PriceHist_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
PRICE_HIST_OUT	No	Yes	No	No
PRICE_HIST	Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

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

Design Assumptions

N/A

This section describes the Related Item Publication BDI.

Functional Area

Foundation

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.

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)
Related Item	Related Item upload to BDI	RelatedItem_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
RELATED_ITEM_OUT	No	Yes	No	No
RELATED_ITEM_DTL_OUT	No	Yes	No	No
RELATED_ITEM_HEAD	Yes	No	No	No
RELATED_ITEM_DETAIL	Yes	No	No	No
ITEM_MASTER	Yes	No	No	No

UDA Item Date Publication API (BDI_UdaItemDate_Fnd_PF_From_RMS_JOB)

This section describes the UDA Item Date Publication BDI.

Functional Area

Foundation

Business Overview

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.

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)
UDA ITEM DATE	UDA Item Date upload to BDI	UdaItemDate_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
UDA_ITEM_DATE_OUT	No	Yes	No	No
UDA_ITEM_DATE	Yes	No	No	No

UDA Item FF Publication API (BDI_UdaItemFF_Fnd_PF_From_RMS_JOB)

This section describes the UDA Item FF Publication BDI.

Functional Area

Foundation

Business Overview

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.

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)
UDA ITEM FF	UDA Item FF upload to BDI	UdaItemFF_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
UDA_ITEM_FF_OUT	No	Yes	No	No
UDA_ITEM_FF	Yes	No	No	No

UDA Item LOV Publication API (BDI_UdaItemLov_Fnd_From_RMS_JOB)

This section describes the UDA Item LOV Publication BDI.

Functional Area

Foundation

Business Overview

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.

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)
UDA ITEM LOV	UDA Item LOV upload to BDI	UdaItemLov_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
UDA_ITEM_LOV_OUT	No	Yes	No	No
UDA_ITEM_LOV	Yes	No	No	No

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)
Finance General Ledger to RFI (BDI_RFI_FinGenLdgr_Tx_PF_From_RMS_JOB)
Financial Data Publish Extract (fif_gl_publish_extract)
Invoice Matching Accounts Payable Detail Outbound Publish Extract (fif_ap_detail_publish_extract)
Invoice Matching Accounts Payable Header Publish Extract (fif_ap_head_publish_extract)
Fixed Deal Income (dealfinc)
Franchise Billing Extract (wfbillex.ksh)
General Ledger Cross Reference Dynamic Mapping (fif_gl_dynamic_map)
Item/Location Daily Stock Ledger Transactions (fifgldn1)
Monthly Stock Ledger Transactions (fifgldn3)
Open to Buy Download Stock Ledger (otbdlsal)
RMS Financial Data Publish (fif_gl_publish)
Rolled Up Daily Stock Ledger Transactions (fifgldn2)
Stage G/L Extracts (gl_extract.ksh)
Tran Data Publication (BDI_TranData_Tx_PF_From_RMS_EOW_JOB)
Capture Stock Ledger Cut-off Time for Business Date (stockledger_switchtime.ksh)
• Maintain Transaction Data Records (maintain_iftd_hist.ksh)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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

Table 6-6 (Cont.) Input File Layout

Field Name	Field Type	Default Value	Description
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)

Table 6-7 (Cont.) Output File Layout

Field Name	Field Type	Default Value	Description
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)

Table 6-7 (Cont.) Output File Layout

Field Name	Field Type	Default Value	Description
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)

Table 6-7 (Cont.) Output File Layout

Field Name	Field Type	Default Value	Description
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)

Design Assumptions

N/A

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.

Scheduling Constraints

Schedule Information	Description
Processing Cycle	End of Day
Frequency	Daily
Scheduling Consideration	N/A
Pre-Processing	N/A
Post-Processing	N/A
Threading Scheme	N/A

Data Definition XML

The BDI interface staging tables are generated based on the XML schema definition.

Data Flow	Description	XML Schema Definition (XML)
Finance	General Ledger upload to BDI	FinGenLdgr_Tx_BdiInterfaceModule.xml

Financial Data Publish Extract (fif_gl_publish_extract)

Module Name	ff_gl_publish_extract.ksh
Description	Financial Data Publish Extract
Functional Area	General Ledger
Module Type	Business Processing
Module Technology	ksh
Catalog ID
Wrapper Script	batch_ff_gl_publish_extract.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch job will have the following runtime parameters:

Parameter	Description
application_name	Source of the GL record. Example: RMS or IM or RFM
fle_prefx	Prefx for the generated fle.
num_records_per_fle	Number of records extracted per fle. If -1, only 1 fle will be generated.
upload_to_object_store	Default value N. Indicates if the generated fle will only be uploaded to object store.
republish_ind	Default to N for nightly batch, Y for adhoc run to republish records.
republish_date	Required when republish_ind is Y. Extract date of records to republish [YYYYMMDD]

During nightly run, this job will extract records from FIF_GL_PUBLISH for the application name (either RMS or IM or RFM) where journal_entry_create_date = current date, write to file, and upload to object storage

Example: /outgoing/RMS_ACCOUNT_ENTRY_20250131024118.zip

The zip can contain the files like: RMS_ACCOUNT_ENTRY_20250131_20250131_00.csv

The num_records_per_file parameter should be big enough because the program can only generate up to 100 files that is packaged in the zip.

During adhoc run, records from FIF_GL_PUBLISH where journal_entry_create_date = republish date will be extracted.

If upload_to_object_store is Y, this job will extract records from FIF_GL_PUBLISH, write to file, and upload to object storage.

If upload_to_object_store is N, this job will invoke the merch background engine which will extract data from FIF_GL_PUBLISH table into a csv file, zip the file and publish to Fusion Financials using theCFIN by invoking a ReST end point.

Restart/Recovery

N/A

Key Tables Affected

Table	Select	Insert	Update	Delete
FIF_GL_PUBLISH	Yes	No	No	No
FIF_PUBLISH_STATUS	Yes	Yes	Yes	Yes
PERIOD	Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

I/O Specification

Integration Type Download from Merchandising File Name N/A Integration Contract IntCon000019 STG_FIF_GL_DATA table

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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__ 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	Char(5)	FHEAD	Identifies the file
	descriptor			record type
	File Line Id	Char(10)		Sequential file line number

Table 6-8 (Cont.) Output File Layout Format 1

Record Name	Field Name	Field Type	Default Value	Description
	File type definition	Char(4)	WFBX	Identifies the file type
	File Create	Char(14)		File Create Date
	Date			in YYYYMMDDHH MMSS 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	Char(20)		Reference number provided
	Reference Number			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

Table 6-8 (Cont.) Output File Layout Format 1

Record Name	Field Name	Field Type	Default Value	Description
	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	Number(20)		Unit restocking
	Restocking Fee			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

Table 6-8 (Cont.) Output File Layout Format 1

Record Name	Field Name	Field Type	Default Value	Description
	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 YYYYMMDDHH MMSS 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	Char(20)		Reference
	Order			number provided
	Reference Number			by the franchise customer
	Franchise	Number(10)		Franchise Order
	Order Number			Number
	Transaction Type	Char(6)		SALES or RETURN
	RMA Number	Number(10)		Return Merchandise Authorization Number for the return

Table 6-9 (Cont.) Output File Layout Format 2

Record Name	Field Name	Field Type	Default Value	Description
	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	Number(20)		Return cost for
	Cost			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	Number(20)		Unit restocking
	Restocking Fee			fee charged for received items
	VAT Code	Char(6)		VAT code for the item

Table 6-9 (Cont.) Output File Layout Format 2

Record Name	Field Name	Field Type	Default Value	Description
	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	Number(6)		Number of
	Counter			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)

Design Assumptions

N/A

General Ledger Cross Reference Dynamic Mapping (fif_gl_dynamic_map)

Module Name fif_gl_dynamic_map.ksh Description General Ledger Cross Reference Dynamic Mapping Functional Area General Ledger Module Type Business Processing Module Technology ksh Catalog ID Wrapper Script rmswrap_shell.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

If the system is set up to use dynamic segments

( FINANCIAL_UNIT_OPTIONS.USE_DYNAMIC_SEGMENTS = Y ) and there are changes to either GL cross reference or dynamic segment records, this program calls the DYNAMIC_MAPPING_SQL.PROCESS function to perform the following:

Synchronize fully formed GL cross reference records between the FIF_GL_CROSS_REF and FIF_GL_CROSS_REF_DYNAMIC tables.
Build fully formed combinations in FIF_GL_CROSS_REF_DYNAMIC using dynamic segment mappings and GL cross reference records based on the following order:
- GL cross reference rows missing minimal segments to rows with maximal segments.
- Fully formed GL cross reference rows with base indicator set.
- Fully formed GL cross reference rows.
When a GL cross reference record is deleted, all child records in FIF_GL_CROSS_REF_DYNAMIC will also be deleted. The program will attempt to rebuild the combination using existing GL Cross Reference records.
When a dynamic segment mapping is deleted, all records in FIF_GL_CROSS_REF_DYNAMIC using this dynamic segment will be deleted.
When a GL cross reference record is updated, all child records in FIF_GL_CROSS_REF_DYNAMIC will also be updated. The account combination will need to be re-validated.
When a dynamic segment mapping is updated, all records in FIF_GL_CROSS_REF_DYNAMIC using this dynamic segment will be updated. The account combination will need to be revalidated.
After building the combinations, validate the account against the FIF_GL_ACCT table. If the account does not exist, it will be deleted from FIF_GL_CROSS_REF_DYNAMIC .

Records from FIF_GL_CROSS_REF_DYNAMIC are used by fifgldn1 , fifgldn2 , fifgldn3 , and dealfinc batch programs when getting General Ledger cross-reference mappings for the transaction data.

Restart/Recovery

N/A

Design Assumptions

Invoice Matching Accounts Payable Detail Outbound Publish Extract (fif_ap_detail_publish_extract)

Module Name	ff_ap_detail_publish_extract.ksh
Description	Invoice Matching Accounts Payable Detail Publish Extract
Functional Area	General Ledger
Module Type	Business Processing
Module Technology	ksh
Catalog ID
Wrapper Script	batch_ff_ap_publish_extract.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch job will have the following runtime parameters:

Parameter	Description
application_name	Source of the GL record. Valid values: IM or RFM
fle_prefx	Prefx for the generated fle.
num_records_per_fle	Number of records extracted per fle. If -1, only 1 fle will be generated.
upload_to_object_store	Default value N. Indicates if the generated fle will only be uploaded to object store.
republish_ind	Default to N for nightly batch, Y for adhoc run to republish records.
republish_date	Required when republish_ind is Y. Extract date of records to republish [YYYYMMDD]
republish_date_run_id	Run Id from the extract date of records to republish. Valid values between 1 and 9999. Optional. Defaulted to 1 if Null.

During nightly run, this job will extract records from FIF_AP_DETAIL_PUBLISH for the application name (either IM or RFM) where im_create_date = current date , write to file, and upload to object storage.

Example: /outgoing/INVOICE_DETAIL_20250131024118.zip

The zip can contain the files like: INVOICE_DETAIL_20250131_20250131_00.csv

The num_records_per_file parameter should be big enough because the program can only generate up to 100 files that is packaged in the zip.

Invoice publish from Invoice Matching to AP can happen multiple times in a day if the job is scheduled to run multiple times in a day. Each run is assigned a one up number, starting from 1 for that day.

extract_date_run_id = republish_date_run_id will be extracted. If republish_date_run_id is not provided, then records with extract_date_run_id = 1 will be extracted.

Restart/Recovery

N/A

Key Tables Affected

Table	Select	Insert	Update	Delete
FIF_AP_DETAIL_PUBLISH	Yes	No	Yes	No
FIF_PUBLISH_STATUS	Yes	Yes	Yes	Yes
PERIOD	Yes	No	No	No

Invoice Matching Accounts Payable Header Publish Extract (fif_ap_head_publish_extract)

Module Name	ff_ap_head_publish_extract.ksh
Description	Invoice Matching Accounts Payable Header Publish Extract
Functional Area	General Ledger
Module Type	Business Processing
Module Technology	ksh
Catalog ID
Wrapper Script	batch_ff_ap_publish_extract.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch job will have the following runtime parameters:

Parameter	Description
application_name	Source of the GL record. Valid values: IM or RFM
fle_prefx	Prefx for the generated fle.
num_records_per_fle	Number of records extracted per fle. If -1, only 1 fle will be generated.
upload_to_object_store	Default value N. Indicates if the generated fle will only be uploaded to object store.
republish_ind	Default to N for nightly batch, Y for adhoc run to republish records.

Parameter	Description
republish_date	Required when republish_ind is Y. Extract date of records to republish [YYYYMMDD]
republish_date_run_id	Run Id from the extract date of records to republish. Valid values between 1 and 9999. Optional. Defaulted to 1 if Null.

During nightly run, this job will extract records from FIF_AP_HEAD_PUBLISH for the application name (either IM or RFM ) where im_create_date = current date, write to file, and upload to object storage.

Example: /outgoing/INVOICE_HEADER_20250131024118.zip

The zip can contain the files like: INVOICE_HEADER_20250131_20250131_00.csv

The num_records_per_file parameter should be big enough because the program can only generate up to 100 files that is packaged in the zip.

Invoice publish from Invoice Matching to AP can happen multiple times in a day if the job is scheduled to run multiple times in a day. Each run is assigned a one-up number, starting from 1 for that day.

During republish to AP for exception scenarios, the run ID for the batch run ( republish_date_run_id ) can be provided to selectively republish a particular job run. In this case, if a run ID is not provided, it is defaulted to 1. That is, during republish, records from FIF_AP_HEAD_PUBLISH where im_create_date = republish date and extract_date_run_id = republish_date_run_id are extracted. If republish_date_run_id is not provided, then records with extract_date_run_id = 1 will be extracted.

If upload_to_object_store is Y , this job will extract records from FIF_AP_HEAD_PUBLISH , write to file, and upload to object storage.

If upload_to_object_store is N , this job will extract data from FIF_AP_HEAD_PUBLISH and FIF_AP_DETAIL_PUBLISH table into a csv file, zip the file and publish to Fusion Financials using the ReST end point.

Restart/Recovery

N/A

Key Tables Affected

Table	Select	Insert	Update	Delete
FIF_AP_HEAD_PUBLISH	Yes	No	Yes	No
FIF_AP_DETAIL_PUBLISH	Yes	No	Yes	No
FIF_PUBLISH_STATUS	Yes	Yes	Yes	Yes
PERIOD	Yes	No	No	No

Item/Location Daily Stock Ledger Transactions (fifgldn1)

Module Name fifgldn1sqls.pls/fifgldn1sqlb.pls Description Interface to General Ledger of Item/Loc Level Transactions Functional Area General Ledger

Module Type Integration Module Technology PLSQL Catalog ID RMS66 Wrapper Script rmswrap_plsql.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

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:

1. 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.

2. 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.

3. 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.

4. 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 month-end processing is typically executed on the End of Month (EOM) date plus Close Month After Days to allow for late-posted transactions to be attributed to the correct month. If on this date, clearing accounts are not defined and unresolved mappings continue to exist, then the month will remain open for an additional number of days specified in Force Close Month After Additional Days . After this duration, the fifgldn1 module will move the recordspending posting from TRAN_DATA_ERRORS to STG_FIF_GL_EOM_ERRORS and proceed to close the month without failure. The STG_FIF_GL_EOM_ERRORS table is available through DAS/RDS to enable extraction and processing of unposted transaction records.

Restart/Recovery

The logical unit of work is department/class/subclass/location/item. The batch is multithreaded using the restart department view.

I/O Specification

Integration Type Download from Merchandising File Name N/A

Integration Contract

IntCon000019 STG_FIF_GL_DATA table

Design Assumptions

N/A

Monthly Stock Ledger Transactions (fifgldn3)

Module Name Fifgldn3sqls.pls/fifgldn3sqlb.pls Description General Ledger Interface 3 Functional Area Interface to General Ledger of Month Level Information Module Type Integration Module Technology PLSQL Catalog ID RMS68 Wrapper Script rmswrap_plsql.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

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:

1. 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.

2. 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.

3. 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.

4. 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 month-end processing is typically executed on the End of Month (EOM) date plus Close Month After Days to allow for late-posted transactions to be attributed to the correct month. If

on this date, clearing accounts are not defined and unresolved mappings continue to exist, the fifgldn3 module will move the records-pending posting from TRAN_DATA_ERRORS and MONTH_DATA_ERRORS to STG_FIF_GL_EOM_ERRORS and proceed to close the month without failure. The STG_FIF_GL_EOM_ERRORS table is available through DAS/RDS to enable extraction and processing of unposted transaction records.

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.

I/O Specification

Integration Type Download from Merchandising File Name N/A Integration Contract IntCon000019 STG_FIF_GL_DATA table

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Locking Strategy

N/A

Security Considerations

N/A

Performance Considerations

N/A

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

Table 6-10 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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	Number(20,4)	N/A	The retail
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

Table 6-10 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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	Number(20,4)	N/A	The cost stock adjustments
Cost			summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period
Purchases	Number(20,4)	N/A	The retail
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

Table 6-10 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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	Number(20,4)	N/A	The retail promotional
Retail			markdowns
			summed from the DAILY_DATA table *10000 (implied 4 decimal places)
			for this stock ledger period

Table 6-10 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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	Number(20,4)	N/A	The retail
Discount Retail			employee discounts amount
			summed from the DAILY_DATA table *10000 (implied 4
			decimal places) for this stock
			ledger period
Workroom	Number(20,4)	N/A	The workroom
Amount			amount summed
			from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period
Cash Discount	Number(20,4)	N/A	The cash
Amount			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

Table 6-10 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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	Number(20,4)	N/A	The retail markup cancellations
Retail			summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period
Clearance	Number(20,4)	N/A	The retail
Markdowns			clearance
Retail			markdowns
			summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period
Permanent	Number(20,4)	N/A	The retail
Markdowns Retail			permanent markdowns
			summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period
Freight Claim	Number(20,4)	N/A	The retail freight
Retail			claim summed from the DAILY_DATA table *10000 (implied 4 decimal places)
			for this stock
			ledger period

Table 6-10 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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	Number(20,4)	N/A	The retail stock adjust COGS
Sold (COGS) Retail			summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period
Stock Adjust	Number(20,4)	N/A	The cost stock
Cost of Goods			adjust COGS
Sold (COGS)			summed from the
Cost			DAILY_DATA table *10000 (implied 4
			decimal places) for this stock ledger period
Inter-company	Number(20,4)	N/A	The Inter-
In Retail			company In retail
			summed from the DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period
Inter-company	Number(20,4)	N/A	The Inter-
In Cost			company In cost summed from the DAILY_DATA table *10000 (implied 4 decimal places)
			for this stock ledger period

Table 6-10 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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	Number(20,4)	N/A	The Inter-
Markup			company Markup summed from the
			DAILY_DATA table *10000 (implied 4 decimal places) for this stock ledger period
Inter-company	Number(20,4)	N/A	The Inter-
Markdown			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

Table 6-10 (Cont.) File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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

Design Assumptions

N/A

Populate FLASHBACK_SNAPSHOT_INFO table (stockledger_switchtime)

Module Name	stockledger_switchtime.ksh (fashbacksnapshots.sql/ fashbacksnapshotb.sql)
Description	Populate`FLASHBACK_SNAPSHOT_INFO`table with database SCN and timestamp values
Functional Area	Stock Ledger
Module Type	Business Processing
Module Technology	PLSQL
Catalog ID
Wrapper Script	rmswrap_shell.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch capture the current VDATE , timestamp, and the corresponding SCN into a table named FLASHBACK_SNAPSHOT_INFO . This SCN value will be used to extract the point in time data from various tables as part of other batch processing such as maintain_isc_history .

It will also delete the previous day record. If corresponding records from the previous day do not exist, this batch will fail and will require troubleshooting to ensure that no data is lost for the RDE extract and other dependent modules.

Restart/Recovery

This is restartable.

Design Assumptions

N/A

Populate IF_TRAN_DATA_HIST and IF_FUTURE_TRAN_DATA_HIST tables for RDE Extract (maintain_iftd_hist)

Module Name	maintain_iftd_hist.ksh (iftdhistsqls.pls/ iftdhistsqlb.pls)
Description	Populate`IF_TRAN_DATA_HIST`and `IF_FUTURE_TRAN_DATA_HIST`tables for RDE Extract
Functional Area	Stock Ledger
Module Type	Business Processing
Module Technology	PLSQL
Catalog ID
Wrapper Script	rmswrap_shell.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch program copies current data from IF_TRAN_DATA into IF_TRAN_DATA_HIST and drops old partitions based on defined retention days ( SYSTEM_OPTIONS.IFTD_HIST_RETENTION_DAYS ). It will also extract data into IF_FUTURE_TRAN_DATA_HIST based on IF_FUTURE_TRAN_DATA . It inserts a row in RMS_RDE_BATCH_STATUS table stating that the TRAN_DATA staging is complete for the business date.

Restart/Recovery

In the case of a restart from failure, it rebuilds records on IF_TRAN_DATA_HIST for the current business date.

Design Assumptions

N/A

RMS Financial Data Publish (fif_gl_publish)

Module Name	ff_gl_publish.ksh
Description	RMS Financial Data Publish
Functional Area	General Ledger

Module Type	Business Processing
Module Technology	ksh
Catalog ID	N/A
Wrapper Script	rmswrap_shell.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch job calls the program FIF_GL_PUBLISH_SQL.PROCESS that loads records from STG_FIF_GL_DATA for the current date to the FIF_GL_PUBLISH table. The reference and attribute columns in this table will be populated with the value from the STG_FIF_GL_DATA column based on the mappings defined in the FIF_OUT_ATTRIBUTE_MAPPING table. If no mapping is defined for any of the fields in this table, a direct copy is performed.

If the set of books from STG_FIF_GL_DATA does not have an external reference ID defined in FIF_GL_SETUP , this program creates an error.

Restart/Recovery

N/A

Key Tables Affected

Table	Select	Insert	Update	Delete
FIF_OUT_ATTRIBUTE_MAPPING	Yes	No	No	No
RMS_PLSQL_BATCH_CONFIG	Yes	No	No	No
CODE_DETAIL	Yes	No	No	No
STG_FIF_GL_DATA	Yes	No	No	No
FIF_GL_PUBLISH	Yes	Yes	No	Yes
FIF_GL_SETUP	Yes	No	No	No

Rolled Up Daily Stock Ledger Transactions (fifgldn2)

Module Name Fifgldn2sqls.pls/fifgldn2sqlb.pls Description Interface to General Ledger of Rolled Up Transactions Functional Area Integration - General Ledger Module Type Integration Module Technology PLSQL Catalog ID RMS67 Wrapper Script rmswrap_plsql.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

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:

1. 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.

2. 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.

3. 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.

4. 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 month-end processing is typically executed on the End of Month (EOM) date plus Close Month After Days to allow for late-posted transactions to be attributed to the correct month. If on this date, clearing accounts are not defined and unresolved mappings continue to exist, then the month will remain open for an additional number of days specified in Force Close Month After Additional Days . After this duration, the fifgldn2 module will move the recordspending posting from TRAN_DATA_ERRORS to STG_FIF_GL_EOM_ERRORS and proceed to close the month without failure. The STG_FIF_GL_EOM_ERRORS table is available through DAS/RDS to enable extraction and processing of unposted transaction records.

Restart/Recovery

I/O Specification

Integration Type Download from Merchandising File Name N/A Integration Contract IntCon000019 STG_FIF_GL_DATA table

Design Assumptions

N/A

Stage G/L Extracts (gl_extract.ksh)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

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

Record Name	Field Name
	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

Record Name Field Name PRIM_ENTERED_DR_AMOUNT PRIM_ENTERED_CR_AMOUNT FIN_GL_SEQ_ID PROCESSED_FLAG

Design Assumptions

N/A

Tran Data Publication (BDI_TranData_Tx_PF_From_RMS_EOW_JOB)

This section describes the Tran Data Publication BDI.

Functional Area

Transactional Data

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.

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)
Tran Data	Tran Data upload to BDI	TranData_Tx_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
TRAN_DATA_OUT	No	Yes	No	No
V_BDI_MFP_TRAN_DATA	Yes	No	No	No

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
Import Management
Invoices
Inventory

Purchasing

Merchandising has scheduled integration for the following purchasing related data:

Download Contracts to Suppliers (edidlcon)
Download Current & Future OTB by Subclass (otbdnld)
Download Purchase Orders to Suppliers (edidlord)
Download Summary of Outstanding Orders on OTB by Subclass (otbdlord)
On Order Publication API (BDI_OnOrder_Tx_PF_From_RMS_EOW_JOB)
Replenishment Item Location Publication API (BDI_ReplItemLoc_Fnd_PF_From_RMS_JOB)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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 YYYYMMDDHH 24MISS 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

Table 6-11 (Cont.) edidlcon.pc- File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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

Table 6-11 (Cont.) edidlcon.pc- File Layout

Field Name	Field Type	Default Value	Description
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’

Table 6-11 (Cont.) edidlcon.pc- File Layout

Record Name	Field Name	Field Type	Default Value	Description
	Location	Number(10)		Contains a
	number			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
tions This module shou nt & Future OTB b Module Name	ld only be run if contractin y Subclass (otbdnld) otbdnld.pc	g is turned on	in the system.
Description	Download Current & Futur	e OTB by Subcl	ass
Functional Area	Open To Buy
Module Type	Integration
Module Technology	ProC
Catalog ID	RMS130
Wrapper Script	rmswrap_out.ksh

Design Assumptions

This module should only be run if contracting is turned on in the system.

Download Current & Future OTB by Subclass (otbdnld)

Schedule

Oracle Retail Merchandising Batch Schedule

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-ofweek 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

Table 6-12 (Cont.) otbdnld.pc - Output File

Field Name	Field Type	Description
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 ’YYYYMMDDH HMMSS’
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	Number(20)	The amount of
Amount		approved non- basic (order type N/B) orders for the budgeted
		period; value includes 4 implied decimal
		places
N Receipts	Number(20)	The amount of
Amount		non-basic
		(order type N/B) orders due in the budgeted
		period that have been received;
		value includes 4
		implied decimal
		places

Table 6-12 (Cont.) otbdnld.pc - Output File

Record Name	Field Name	Field Type	Default Value	Description
	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	Number(20)		The amount of
	Amount			buyer-
				replenished
				basic (order type BRB)
				orders due in
				the budgeted
				period that have been received; value includes 4
				implied decimal
				places
	A Approved	Number(20)		The amount of
	Amount			approved auto- replenished
				basic (order type ARB)
				orders for the budgeted
				period; value includes 4
				implied decimal places
	A Receipts	Number(20)		The amount of
	Amount			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	Char (5)	FTAIL	Identifies file
	descriptor			record type
	File Line	Number (10)		Keeps track of
	Sequence			the record’s
	Number			position in the
				file by line number

Table 6-12 (Cont.) otbdnld.pc - Output File

Record Name	Field Name	Field Type	Default Value	Description
tions N/A	Number of lines	Number (10)		Total number of all transaction lines, not including file header and trailer
hase Orders to Su Module Name	ppliers (edidlord) edidlord.pc
Description	Download of Purchase Or	der from Mercha	ndising to Suppliers
Functional Area	Purchase Order
Module Type	Integration
Module Technology	ProC
Catalog ID	RMS46
Wrapper Script	rmswrap_multi_out.ksh

Design Assumptions

N/A

Download Purchase Orders to Suppliers (edidlord)

Schedule

Oracle Retail Merchandising Batch Schedule

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 Summary Across Versions

Version Number	Record Name	Length
1	File Header - FHEAD	34
	Transaction Order Header Information – TORDR	5827
	Transaction Order Item Information – TITEM	900
	Transaction Pack Component Information – TPACK	978
	Transaction Shipment Information –TSHIP	318
	Transaction Customer Order Information –TCUST	3777
	Transaction Trailer - TTAIL	35
	File Trailer - FTAIL	25
2	File Header - FHEAD	34
	Transaction Order Header Information – TORDR	5847
	Transaction Order Item Information – TITEM	900
	Transaction Pack Component Information – TPACK	978
	Transaction Shipment Information –TSHIP	318
	Transaction Customer Order Information –TCUST	3777
	Transaction Trailer - TTAIL	35
	File Trailer - FTAIL	25
3	File Header - FHEAD	34
	Transaction Order Header Information – TORDR	5848
	Transaction Order Item Information – TITEM	900
	Transaction Pack Component Information – TPACK	978
	Transaction Shipment Information –TSHIP	318
	Transaction Customer Order Information –TCUST	3777
	Transaction Trailer - TTAIL	35
	File Trailer - FTAIL	25

Output File Layout

Record	Field Name	Field	Default	Description	Added in
Name		Type	Value		version
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)		Vdate in YYYYMMDDHH24MISS format
TORDR	Record descriptor	Char(5)	TORDR	Order header information
	Line id	Number( 10)		Unique file line id
	Transaction id	Number( 10)		Unique transaction id
	Order change type	Char(2)		‘CH’ (changed) or ‘NW’ (new)
	Order number	Number( 12)		Internal Oracle Retail order no
	Supplier	Number( 10)		Internal Oracle Retail supplier id
	Vendor order id	Char(15)		External vendor_order_no (if available)
	Order written	Char(14)		Order created date in
	date			YYYYMMDDHH24MISS format
	Original order approval date	Char(14)		Original order approval date in YYYYMMDDHH24MISS format
	Old Currency Code	Char(3)		Old order currency_code (ISO standard)
	New Currency Code	Char(3)		Changed order currency_code (ISO standard)
	Old Shipment Method of payment	Char(2)		Old ship_pay_method
	New Shipment Method of Payment	Char(2)		Changed ship_pay_method
	Old Transportation Responsibility	Char(2)		Old fob_trans_res
	Old	Char(250		Old fob_trans_res_desc
	Transportation	)
	Responsibility Description

Field Name	Field Type	Description
New Transportation Responsibility	Char(2)	Changed fob_trans_res
New Trans. Resp. Description	Char(250 )	New fob_trans_res_desc
Old Title Passage Location	Char(2)	Old fob_title_pass
New Title Passage Location	Char(2)	Changed fob_title_pass
Old Title Passage Description	Char(250 )	Old fob_title_pass_desc
New Title Passage Description	Char(250 )	Changed fob_title_pass_desc
Old not before date	Char(14)	Old not_before_date in YYYYMMDDHH24MISS format
New not before date	Char(14)	Changed not_before_date in YYYYMMDDHH24MISS format
Old not after date	Char(14)	Old not_after_date in YYYYMMDDHH24MISS format
New not after date	Char(14)	Changed not_after_date in YYYYMMDDHH24MISS format
Old Purchase type	Char(6)	Old Purchase type
New Purchase type	Char(6)	New Purchase type
Backhaul allowance	Char(20)	Backhaul allowance
Old terms	Char(240	Old terms description from
description	)	terms table
New terms description	Char(240 )	New terms description from terms table
Old pickup date	Char(14)	Old pickup date YYYYMMDDHH24MISS
New pickup date	Char(14)	New pickup date YYYYMMDDHH24MISS
Old ship method	Char(6)	Old ship method
New ship method	Char(6)	New ship method
Old comment	Char(200	Old comment description
description	0)

Record Name	Field Name	Field Type Default Value	Description	Added in version
	New comment description	Char(200 0)	New comment description
	Supplier DUNS number	Char(9)	Supplier DUNS number
	Supplier DUNS location	Char(4)	Supplier DUNS location
	Customer order number	Char(48)	Master customer order number from the Order Management System
	Fulfillment order number	Char(48)	Master Fulfillment order number from the Order Management System
	File ID	Char(20)	To support supplier pooling via the buyer worksheet, the recommended order quantities for the individual suppliers are linked together for logistical purposes while generating orders from the worksheet based on this identifier.	2
	Non-Self Invoice Indicator	Char(1)	To support vendor invoicing for Consignment POs, these POs will need to be communicated to the supplier. This will serve as an indicator to the supplier that the PO is being sent only for purposes of consignment invoicing and doesn’t need to be processed.	3
TITEM	File record descriptor	Char(5)	TITEM	Item info
	Line id	Number( 10)	Unique line id
	Transaction id	Number( 10)	Unique transaction id
	Item Number Type	Char(6)	Item_number_type
	Item	Char(25)	Item (For a pack item, this will be the pack number)
	Old Ref Item Number type	Char(6)	Item_number_type for old ref_item
	Old Ref Item	Char(25)	Old Ref_Item
	New Ref Item Number type	Char(6)	Item_number_type for new ref_item
	New Ref Item	Char(25)	Changed Ref_Item
	Vendor catalog number	Char(30)	Supplier_item (VPN)
	Free Form Description	Char(250 )	Item_desc

Record Name	Field Name	Field Type	Default Value	Description
	Supplier Diff 1	Char(120 )		Supplier’s diff 1
	Supplier Diff 2	Char(120 )		Supplier’s diff 2
	Supplier Diff 3	Char(120 )		Supplier’s diff 3
	Supplier Diff 4	Char(120 )		Supplier’s diff 4
	Pack Size	Number( 12)		Supplier defined pack size * 10000 (4 implied decimal places)
	Item_line_no	Number( 10)		Indicates the detail item line number.
TPACK	File record descriptor	Char(5)	TPACK	Pack component info
	Line id	Number( 10)		Unique line id
	Transaction id	Number( 10)		Unique transaction id
	Pack id	Char(25)		Packitem_breakout.pack_no (same as item for the pack item)
	Inner pack id	Char(25)		Inner pack identification
	Pack Quantity	Number( 12)		Packitem_breakout.pack_item _qty*10000 (4 implied decimal places)
	Component Pack Quantity	Number( 12)		Packitem_breakout.comp_pac k_qty*10000 (4 implied decimal places)
	Item Parent Part Quantity	Number( 12)		Packitem_breakout.item_pare nt_pt_qty*10000 (4 implied decimal places)
	Item Quantity	Number( 12)		Packitem_breakout.item_qty*1 0000 (4 implied decimal places)
	Item Number Type	Char(6)		Item number type
	Item	Char(25)		Item
	Ref Item Number Type	Char(6)		Ref_item_number_type
	Ref Item	Char(25)		Ref_item
	VPN	Char(30)		Supplier item (vpn)
	Supplier Diff 1	Char(120 )		Supplier’s diff 1
	Supplier Diff 2	Char(120 )		Supplier’s diff 2
	Supplier Diff 3	Char(120 )		Supplier’s diff 3

Record Name	Field Name	Field Type	Default Value	Description
	Supplier Diff 4	Char(120 )		Supplier’s diff 4
	Item Parent	Char(25)		Required when Pack Template is not NULL
	Pack template	Number( 8)		Pack template associated w/ style (packitem_breakout.pack_tmpl _id)
	Template description	Char(250 )		Description of pack template. sups_pack_tmpl_desc.supp_p ack_desc
TSHIP	Record type	Char(5)	TSHIP	Describes the file record- shipment information
	Line id	Number( 10)		Unique file line number
	Transaction id	Number( 10)		Unique transaction number
	Location type	Char(2)		‘ST’ store or ‘WH’ warehouse
	Ship to location	Number( 10)		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)		Old unit cost*10000 (4 implied decimal places)
	New unit cost	Number( 20)		New unit cost*10000 (4 implied decimal places)
	Old quantity	Number( 12)		Old qty_ordered 10000 or qty_allocated10000 (4 implied decimal places)
	New quantity	Number( 12)		Changed qty_ordered10000 or qty_allocated10000 (4 implied decimal places)
	Old outstanding	Number(		Old (qty_ordered-
	quantity	12)		qty_received)10000 or (qty_allocated-qty transferred)10000 for an allocation
				(4 implied decimal places)
	New outstanding quantity	Number( 12)		Changed qty_ordered- qty_received (4 implied decimal places)(or qty_allocated-qty_transferred, for an allocation)
	Cancel code	Char(1)
	Old cancelled quantity	Number( 12)		Previous quantity cancelled (4 implied decimal places)
	New cancelled	Number(		Changed quantity cancelled (4
	quantity	12)		implied decimal places)

Record Name	Field Name	Field Type	Default Value	Description
	Quantity type flag	Char(1)		‘S’hip to ‘A’llocate
	Store or warehouse indicator	Char(2)		‘ST’ (store) or ‘WH’ (warehouse)
	Old x-dock location	Number( 10)		Alloc_detail location (store or wh)
	New x-dock location	Number( 10)		Alloc_detail location (store or wh)
	Case length	Number( 12)		Case length (4 implied decimal places)
	Case width	Number( 12)		Case width (4 implied decimal places)
	Case height	Number( 12)		Case height (4 implied decimal places)
	Case LWH unit of measure	Char(4)		Case LWH unit of measure
	Case weight	Number( 12)		Case weight (4 implied decimal places)
	Case weight unit of measure	Char(4)		Case weight unit of measure
	Case liquid volume	Number( 12)		Case liquid volume (4 implied decimal places)
	Case liquid volume unit of measure	Char(4)		Case liquid volume unit of measure
	Location DUNS number	Char(9)		Location DUNS number
	Location DUNS loc	Char(4)		Location DUNS loc
	Old unit cost init	Number( 20)		Old unit cost init (4 implied decimal places)
	New unit cost init	Number( 20)		New unit cost init (4 implied decimal places)
	Item/loc discounts	Number( 20)		Item/loc discounts (4 implied decimal places)
TCUST	Record type	Char(5)	TCUST	Describes the file record- customer order information
	Line id	Number( 10)		Unique file line number
	Transaction id	Number( 10)		Unique transaction number
	Delivery first name	Char(120 )		First name for the delivery address on the order
	Delivery	Char(120		Phonetic first name for the
	phonetic first name	)		delivery address on the order

Field Name	Field Type Default Value	Description
Delivery last name	Char(120 )	Last name for the delivery address on the order
Delivery phonetic last name	Char(120 )	Phonetic last name for the delivery address on the order
Delivery preferred name	Char(120 )	Preferred name for the delivery address on the order
Delivery company name	Char(120 )	Company name for the delivery address on the order
Delivery address Line 1	Char(240 )	First line of the delivery address of the customer
Delivery address Line 2	Char(240 )	Second line of the delivery address of the customer
Delivery address Line 3	Char(240 )	Third line of the delivery address of the customer
Delivery county	Char(250 )	County portion of the delivery address
Delivery city	Char(120 )	City portion of the delivery address
Delivery state	Char(3)	State portion of the delivery address
Delivery country ID	Char(3)	Country portion of the delivery address
Delivery post	Char(30)	Postal code portion of the delivery address
Delivery jurisdiction	Char(10)	Jurisdiction code of the delivery country-state relationship
Delivery phone	Char(20)	Phone number in the delivery information
Billing first name	Char(120 )	First name for the billing address on the order
Billing phonetic first name	Char(120 )	Phonetic first name for the billing address on the order
Billing last name	Char(120 )	Last name for the billing address on the order
Billing phonetic last name	Char(120 )	Phonetic last name for the billing address on the order
Billing preferred name	Char(120 )	Preferred name for the billing address on the order
Billing company name	Char(120 )	Company name for the billing address on the order
Billing address Line 1	Char(240 )	First line of the billing address of the customer
Billing address Line 2	Char(240 )	Second line of the billing address of the customer
Billing address	Char(240	Third line of the billing address
Line 3	)	of the customer

Record Name	Field Name	Field Type	Default Value	Description
	Billing county	Char(250 )		County portion of the billing address
	Billing city	Char(120 )		City portion of the billing address
	Billing state	Char(3)		State portion of the billing address
	Billing country ID	Char(3)		Country portion of the billing address
	Billing post	Char(30)		Postal code portion of the billing address
	Billing jurisdiction	Char(10)		Jurisdiction code of the billing country-state relationship
	Billing phone	Char(20)		Phone number in the billing information
TTAIL	Record type	Char(5)	TTAIL	Describes file record – marks end of order
	Line id	Number( 10)		Unique file line id
	Transaction id	Number( 10)		Unique transaction id
	`#Lines` in transaction	Number( 10)		Number of lines in transaction
FTAIL	Record type	Char(5)	FTAIL	Describes file record – marks end of file
	Line id	Number( 10)		Unique file line id
	`#lines`	Number( 10)		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

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-13 otbdlord.pc - Output File

Record Name	Field Name	Field Type	Default Value	Description
File Header	File Type	Char(5)	FHEAD	Identifies file
	Record			record type
	Descriptor

Table 6-13 (Cont.) otbdlord.pc - Output File

Record Name	Field Name	Field Type	Default Value	Description
	File Line Sequence Number	Number(10)	N/A	Keeps track of the record’s position in the file by line number
	File Type	Char(4)	OOEX	Identifies file as
	Definition			‘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(10)	N/A	Keeps track of the record’s
	Number			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

Table 6-13 (Cont.) otbdlord.pc - Output File

Record Name	Field Name	Field Type	Default Value	Description
	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

Design Assumptions

N/A

On Order Publication API (BDI_OnOrder_Tx_PF_From_RMS_EOW_JOB)

This section describes the On Order Publication BDI.

Functional Area

Inventory Tracking

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.

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)
On Order	On Order upload to BDI	OnOrder_Tx_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
ON_ORDER_OUT	No	Yes	No	No
V_BDI_MFP_ON_ORDER	Yes	No	No	No

Replenishment Item Location Publication API (BDI_ReplItemLoc_Fnd_PF_From_RMS_JOB)

This section describes the Replenishment Item Location Publication BDI.

Functional Area

Item

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.

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)
Replenishment Item Location	Replenishment Item Location upload to BDI	ReplItemLoc_Fnd_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
REPL_ITEM_LOC_OUT	No	Yes	No	No
ITEM_MASTER	Yes	No	No	No
REPL_ITEM_LOC	Yes	No	No	No

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)
Letter of Credit Amendment Download (lcmdnld)
- SWIFT File Conversion – Letter of Credit Amendment (lcmt707)
Letter of Credit Application Download (lcadnld)
- SWIFT File Conversion - Letter of Credit Application (lcmt700)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-14 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 YYYYMMDDHH2 4MISS 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	YYYYMMDDHH2 4MISS 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.summ ary date	YYYYMMDDHH2 4MISS 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.import er_id	N/A
	Import Country	Char(3)	ce_head.import _country_id	N/A
	Currency Code	Char(3)	ce_head.curren cy_code	N/A
	Exchange Rate	Number(20,10)	ce_head.excha nge_rate*1000 0000000 (with 10 implied decimal places)	N/A

Table 6-14 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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.consig nee_id	N/A
	Live Indicator	Char(1)	ce_head.live_in d	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.liquida tion_amt*10000 (4 implied decimal places)	N/A
	Liquidation Date	Date	ce_head.liquida tion_date	YYYYMMDDHH2 4MISS format
	Reliquidation Amount	Number(20,4)	ce_head.reliqui dation_amt*100 00 (4 implied decimal places)	N/A
	Reliquidation Date	Date	ce_head.reliqui dation_date	YYYYMMDDHH2 4MISS format
	Merchandise Loc	Char(40)	ce_head.merch andise_loc	N/A
	Location Code	Char(4)	ce_head.locatio n_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.ve ssel_id	N/A
	Voyage Flt ID	Char(10)	ce_shipment.vo yage_flt_id	N/A
	Estimated Departure Date	Date	ce_shipment.es timated_depart _date	YYYYMMDDHH2 4MISS format
	Vessel SCAC Code	Char(6)	ce_shipment.ve ssel_scac_cod e	N/A
	Lading Port	Char(5)	ceshipment.la	N/A
			_ ding_port

Table 6-14 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	Discharge Port	Char(5)	ce_shipment.di scharge_port	N/A
	Tran Mode ID	Char(6)	ce_shipment.tr an_mode_id	N/A
	Export Date	Date	ce_shipment.ex port_date	YYYYMMDDHH2 4MISS
	Import Date	Date	ce_shipment.im port_date	YYYYMMDDHH2 4MISS
	Arrival Date	Date	ce_shipment.ar rival_date	YYYYMMDDHH2 4MISS
	Export Country	Char(3)	ce_shipment.ex port_country_id	N/A
	Shipment Number	Number(10)	ce_shipment.sh ipment_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.or der_no	N/A
	Item	Char (25)	ce_ord_item.ite m	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.inv oice_id	N/A
	Invoice Date	Date	ce_ord_item.inv oice_date	YYYYMMDDHH2 4MISS format
	Invoice Amount	Number(20,4)	ce_ord_item.inv oice_amt*1000 0 (4 implied decimal places)	N/A
	Currency Code	Char(3)	ce_ord_item.cu rrency_code	N/A
	Exchange Rate	Number(20,10)	ce_ord_item.ex change_rate*10 000000000 (10 implied decimal places)	N/A
	Manifest Item Quantity	Number(12,4)	ce_ord_item.m anifest_item_qt y*10000 (4 implied decimal places)	N/A

Table 6-14 (Cont.) Output File Layout

Field Name	Field Type	Default Value	Description
Manifest Item Quantity UOM	Char(4)	ce_ord_item.m anifest_item_qt y_uom	N/A
Carton Quantity	Number (12,4)	ce_ord_item.ca rton_qty*10000 (4 implied decimal places)	N/A
Carton Quantity UOM	Char(4)	ce_ord_item.ca rton_qty_uom	N/A
Gross Weight	Number(12,4)	ce_ord_item.gr oss_wt*10000 (4 implied decimal places)	N/A
Gross Weight UOM	Char(4)	ce_ord_item.gr oss_wt_uom	N/A
Net Weight	Number(12,4)	ce_ord_item.ne t_wt*10000 (4 implied decimal places)	N/A
Net Weight UOM	Char(4)	ce_ord_item.ne t_wt_uom	N/A
Cubic	Number(12,4)	ce_ord_item.cu bic*10000 (4 implied decimal places)	N/A
Cubic UOM	Char(4)	ce_ord_item.cu bic_uom	N/A
Cleared Quantity	Number(12,4)	ce_ord_item.cle ared_qty*10000 (4 implied decimal places)	N/A
Cleared Quantity UOM	Char(4)	ce_ord_item.cle ared_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	YYYYMMDDHH2 4MISS format
Rush Indicator	Char(1)	ce_ord_item.ru sh_ind	N/A
Related Indicator	Char(1)	ce_ord_item.rel ated_ind	N/A
Tariff Treatment	Char(10)	ce_ord_item.tar iff_treatment	N/A
Ruling Number	Char(10)	ce_ord_item.rul ing_no	N/A
Do Number	Char(10)	ce_ord_item.do _no	N/A

Table 6-14 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	Do Date	Date	ce_ord_item.do _date	YYYYMMDDHH2 4MISS 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.lice nse_visa_type	N/A
	License/Visa ID	Char(30)	ce_lic_visa.lice nse_visa_id	N/A
	License/Visa Quantity	Number(12,4)	ce_lic_visa.lice nse_visa_qty*1 0000 (4 implied decimal places)	N/A
	License/Visa Quantity UOM	Char(4)	ce_lic_visa.lice nse_visa_qty_u om	N/A
	Quota Category	Char (6)	ce_lic_visa.quo ta_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.hold er_id	N/A

Table 6-14 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
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.pac k_item	N/A
	HTS	Char(10)	ce_charges.hts	N/A
	Effect From Date	Date	ce_charges.effe ct_from	YYYYMMDDHH2 4MISS format
	Effect To Date	Char(14)	ce_charges.effe ct_to	YYYYMMDDHH2 4MISS format
	Component ID	Date	ce_charges.co mp_id	N/A
	Component Rate	Number(20,4)	ce_charges.co mp_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.co mp_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.do c_id	N/A
	Received_date	Date	Missing_doc.re ceived_date	YYYYMMDDHH2 4MISS 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)

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-15 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’

Table 6-15 (Cont.) File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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.issuin g_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_i d	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_l c_id	The BANK_LC_ID off the LC_HEAD table
	Currency Code	Char(3)	lc_head.curren cy_code	The CURRENCY_CODE off the LC_HEAD table
	Date of Issue/ Transfer of the Credit	Char(14)	lc_head.confir med_date	Date the Issuing Bank thinks is the date of issue–when it was officially confirmed, formatted to ‘YYYYMMDDHH24MISS’

Table 6-15 (Cont.) File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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.benefic iary	Party in favor of which the LC is being issued
	Beneficiary Name	Char(240)	sups.sup_nam e	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_i d	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_amendment s.amend_no	Holds the amendment number for the amendment
	Order_no	Number (8)	lc_amendment s.order_no	Order_no, if applicable, that is attached to the LC that is being amended
	Item	Char(25)	lc_amendment s.item	Item being amended, either a Style or Staple sku

Table 6-15 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
Value Being Amended	Char(6)	lc_amendment s.amended_val ue	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.co de_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_amendment s.original_valu e	Current value of field that is being amended
New Value of Amended Field	Char (2000)	lc_amendment s.new_value	New value of the field that is being amended
Description of New Value	Char(40)	code_detail.co de_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.amendment s.effect	Effect that amendment will have on LC if amendment to change qty or cost of a PO or amount of LC itself

Table 6-15 (Cont.) File Layout

Record Name	Field Name	Field Type	Default Value	Description
	Date of Amendment	Char(14)	Lc_amendmen ts.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

Schedule

See Oracle Merchandising Batch Schedule.

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-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 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 ‘YYYYMMDDHH 24MISS’
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

Table 6-16 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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.advisin g_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’

Table 6-16 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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_i d	The LC_REF_ID off the LC_HEAD table
Form Type	Char(6)	lc_head.form_t ype	The level of detail that the LC will send to the issuing bank
Form Type Description	Char(40)	code_detail.cod e_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	Char(40)	code_detail.cod	Describes the LC
Type Description		e_desc	type: Master, Normal, Revolving
Form of Letter of Credit – I	Char(1)	sup_import_attr .revocable_ind	The REVOCABLE_IN D from the SUP_IMPORT_A TTR table
Form of Letter of Credit – II	Char(1)	lc_head.transfe rable_ind	Indicates if LC transferable
Application Date	Char(14)	lc_head.applica tion_date	Date the LC is created within Import Management/ Merchandising, formatted to
			’YYYYMMDD HH24MISS’

Table 6-16 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
Expiration Date	Char(14)	lc_head.expirati on_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.applica nt	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.benefici ary	Party in favor of which the LC is being issued
Beneficiary	Char(240)	sups.sup_name	Beneficiary
Name			(supplier) name from the SUPS table

Table 6-16 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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.curren cy_code	The country of origin for the orders on the LC
Exchange Rate	Number (20,10)	lc_head.exchan ge_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.presen tation_terms	Code for the terms of presentation
Presentation Terms	Char(40)	desc is retrieved	Description of the terms of
Description		through a decode	presentation
Purchase Type	Char(6)	lc_head.purcha se_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

Table 6-16 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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.issuan ce	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.amoun t_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.amoun t	The total amt of the Letter of Credit
Variance Percent	Number (12,4)	lc_head.varianc e_pct	Allowed currency variance percent for the LC
Specification	Char(6)	lc_head.specifi cation	Code for any condition for the credit, such as,. “maximum”, and so on
Specification Description	Char(40)	desc is retrieved	Description of condition for the
		through a decode	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

Table 6-16 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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

Table 6-16 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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.negotia ting_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.confirm ing_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

Table 6-16 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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.transfe rring_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	Char(1)	lc_head.transsh	Indicates whether
Indicator		ipment_ind	goods covered by LC can be
			partially shipped or not

Table 6-16 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
Fob Title Pass	Char(6)	lc_head.fob_titl e_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	Char(5)	lc_head.transp	Describes the
to		ortation_to	FOB_TITLE_PAS S - could be city name and so on
Transportation to description	Char(150)	outloc.outloc_d esc	Transportation to location
With Recourse Indicator	Char(1)	lc_head.with_re course_ind	Description of transportation to location
Latest	Char(14)	lc_head.latest_	Indicates
Shipment Date		ship_date	conditional payment on the part of the bank as instructed by the buyer
Earliest	Char(14)	lc_head.earliest	Latest ship date
Shipment Date		_ship_date	for all Pos included in the LC, formatted to ’YYYYMMDD HH24MISS’
Letter of Credit	Number(3)	lc.head.lc_neg_	The number of
Negotiation	replaces x	days	days to negotiate
Days	in the string “DOCUMENTS TO BE PRESENTED WITHIN x DAYS AFTER ISSUANCE OF THE SHIPPING DOCUMENTS BUT WITHIN THE VALIDITY OF THIS CREDIT”		documents

Table 6-16 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
Bank’s LC reference id	Number(8)	lc_head.bank_l c_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.comme nts	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_te xt	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	Number(10)	line number in	ID of current line
Sequence Number		file	being created for output file

Table 6-16 (Cont.) File Layout

Field Name	Field Type	Default Value	Description
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.st andard_uom	Standard unit of measure of the quantity of the item for the order on the LC
Earliest Ship Date	Char(14)	lc_detail.earlies t_ship_date	The earliest date an order on the LC can be shipped, formatted to ’YYYYMMDDHH 24MISS
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.de sc_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	Number(10)	sequence	Used to force
Control Number		number	unique file check

Table 6-16 (Cont.) File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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.comm ents	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	ID of current line being created for
			Created by program.	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 Description

lcmt707

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

Schedule

Oracle Retail Merchandising Batch Schedule

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

Schedule

Oracle Retail Merchandising Batch Schedule

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:

Stage Complex Deal Invoice Information (vendinvc)
Stage Fixed Deal Invoice Information (vendinvf)
Download of Invoice for Invoice Matching (edidlinv)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-17 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)	000000000 1	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)	05	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).

Table 6-17 (Cont.) edidlinv.pc - Output File Layout

Record	Field Name	Field Type	Default	Description
Name			Value
	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.

Table 6-17 (Cont.) edidlinv.pc - Output File Layout

Field Name	Field Type	Default Value	Description
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.

Table 6-17 (Cont.) edidlinv.pc - Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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.
	Fiscal ID	Char(240)	NULL	This is fiscal document ID. Always blank from Merchandising.
	Best Terms Date	Char(14)	NULL	Basis Date for calculating the Payment Date. 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_T YPE is GTS.

Table 6-17 (Cont.) edidlinv.pc - Output File Layout

Record	Field Name	Field Type	Default	Description
Name			Value
	Original Tax rate	Number (20,10)		Tax Rate for the Tax code/item. This will be Blank if the SYSTEM_OPTIONS.DEFAULT_TAX_T YPE 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_T YPE 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.

Table 6-17 (Cont.) edidlinv.pc - Output File Layout

Record	Field Name	Field Type	Default	Description
Name			Value
	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_T YPE 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_T YPE 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.

Table 6-17 (Cont.) edidlinv.pc - Output File Layout

Record Name	Field Name	Field Type	Description
	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_T YPE 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_T YPE 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_T YPE 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_T YPE being GTS, this will be populated only when the tax calc type is ‘P’.

Table 6-17 (Cont.) edidlinv.pc - Output File Layout

Record Name	Field Name	Field Type	Description
	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_T YPE 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_T YPE 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.

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

When the max commit point is reached, the data is updated.

I/O Specification

Integration Type Download from Merchandising File Name N /A Integration Contract IntCon000009

Records are written to the stage_complex_deal_head and stage_complex_deal_detail tables.

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

I/O Specification

Integration Type Download from Merchandising File Name N /A Integration Contract IntCon000009

Records are written to the stage_complex_deal_head and stage_complex_deal_detail tables.

Design Assumptions

N/A

Inventory

Merchandising has scheduled integration for inventory and sales data through the following processes:

Download Sales and Stock on Hand to Suppliers (edidlprd)
Future Available Inventory Publication API (BDI_COFutureAvail_Tx_PF_From_RMS_JOB)
Inventory Publication API (BDI_Inventory_Tx_PF_From_RMS_EOW_JOB)
Item Location History (BDI_ItemLocHist_Tx_PF_From_RMS_JOB)
Reject POSU Transactions (salesgenrej.ksh)
Store Available Inventory Publication API (BDI_InvAvailStore_Tx_PF_From_RMS_JOB)
Warehouse Inventory Publication API (BDI_InvAvailWh_Tx_PF_From_RMS_JOB)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-18 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

Table 6-18 (Cont.) edidlprd.pc - Output File

Record Name	Field Name	Field Type	Default Value	Description
	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_Typ e	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

Table 6-18 (Cont.) edidlprd.pc - Output File

Record Name	Field Name	Field Type	Default Value	Description
	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

Design Assumptions

A data translator will be used to convert the flat file produced by Merchandising to the required EDI data format.

Only data for items where the supplier is indicated as the primary supplier/origin country for the item will be included in the report.

Future Available Inventory Publication API (BDI_COFutureAvail_Tx_PF_From_RMS_JOB)

This section describes the Future Available Inventory Publication BDI.

Functional Area

Inventory

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.

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)
CO Future Avail	CO Future Availability	COFutureAvail_Tx_BdiInterfaceModule .xml

Tables

TABLE	SELECT	INSERT	UPDATE	DELETE
CO_FUTURE_AVAIL_OUT	No	Yes	No	No
V_BDI_CO_FUTURE_AVAIL	Yes	No	No	No

Inventory Publication API (BDI_Inventory_Tx_PF_From_RMS_EOW_JOB)

This section describes the Item Inventory Publication BDI.

Functional Area

Inventory

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.

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)
Inventory	Inventory upload to BDI	Inventory_Tx_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
INVENTORY_OUT	No	Yes	No	No
V_BDI_MFP_INVENTORY	Yes	No	No	No

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

Restart/Recovery

N/A

Key Tables Affected

Table	Select	Insert	Update	Delete
ITEM_LOC_HIST	Yes	No	No	No
ITEM_LOC_HIST_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

Refer to ItemLocHist_Tx_BdiInterfaceModule.xml.

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

Schedule

Oracle Retail Merchandising Batch Schedule

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 Indicator1) 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).

Restart/Recovery

N/A

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.

Retry File:

If the retry input indicator is set to Y, then a retry file is going to be generated if the error is due to locking only. This will be automatically be placed at the input directory ready to be picked up by the next sales upload and processing.

Store Available Inventory Publication API (BDI_InvAvailStore_Tx_PF_From_RMS_JOB)

This section describes the Store Available Inventory Publication BDI.

Functional Area

Foundation

Business Overview

1 Input parameter is not required and is defaulted to N that will disable the generate the retry file functionality for locked records.

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.

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)
Store Inventory	Store inventory upload to BDI	InvAvailStore_Tx_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
INV_AVAIL_STORE_OUT	No	Yes	No	No
ITEM_MASTER	Yes	No	No	No
ITEM_LOC_SOH	Yes	No	No	No
STORE	Yes	No	No	No

Warehouse Inventory Publication API (BDI_InvAvailWh_Tx_PF_From_RMS_JOB)

This section describes the Warehouse Inventory Publication BDI.

Functional Area

Foundation

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.

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)
Warehouse Inventory Avail	Wh Available Inventory	InvAvailWh_Tx_BdiInterfaceModule.xml

Table Impact

TABLE	SELECT	INSERT	UPDATE	DELETE
INV_AVAIL_WH_OUT	No	Yes	No	No
ITEM_MASTER	Yes	No	No	No
ITEM_LOC_SOH	Yes	No	No	No
WH	Yes	No	No	No

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-19 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-20 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-21 Integration to Oracle Retail Inventory Planning Optimization Cloud Service - Demand Forecasting

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_wrap per.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

Schedule Information	Description
Post-Processing	N/A
Threading Scheme	N/A

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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

Module Name

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 Inventory Planning Optimization Cloud Service - Demand Forecasting
- 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

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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

Field Name	Field Type	Required	Description
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 Inventory Planning Optimization Cloud Service - Demand Forecasting
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

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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_CO DE	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).

Field Name Field Type Required Description 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

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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.

Field Name	Field Type	Required	Description
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 Inventory Planning Optimization Cloud Service - Demand Forecasting
- 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

Restart/Recovery

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

Table	SELECT	INSERT	UPDATE	DELETE
BDI_DWNLDR_IFACE_MOD_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT	Yes	No	No	No
L
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_DE SC	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

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.

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.

If there is no item parent, it will contain the transaction level item.

Concatenated value consisting of the class number with name.

Concatenated value consisting of the department ID and name.

Field Name	Field Type	Required	Description
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

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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 Name

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 Inventory Planning Optimization Cloud Service - Demand Forecasting
- 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

Restart/Recovery

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

Table	SELECT	INSERT	UPDATE	DELETE
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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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

Field Name	Field Type	Required	Description
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_DESCRI PTION	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 Inventory Planning Optimization Cloud Service - Demand Forecasting

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

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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

Module Name

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 Inventory Planning Optimization Cloud Service - Demand Forecasting
- 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

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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_DESCRI PTION	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

Module Name

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

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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

Schedule Information	Description
Post-Processing	N/A
Threading Scheme	N/A

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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_UNIT S	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_RETAI L	Number(20,4)	No	tran_data_history.total_retail: tran_code = 1 and sales type = R
NET_SALES_PROMO_U NITS	Number(12,4)	No	tran_data_history.units: tran_code = 1 and sales type = P
NET_SALES_PROMO_C OST	Number(20,4)	No	tran_data_history.total_cost: tran_code = 1 and sales type = P
NET_SALES_PROMO_R ETAIL	Number(20,4)	No	tran_data_history.total_retail: tran_code = 1 and sales type = P
NET_SALES_CLEAR_UN ITS	Number(12,4)	No	tran_data_history.units: tran_code = 1 and sales type = C

Field Name	Field Type	Required	Description
NET_SALES_CLEAR_CO ST	Number(20,4)	No	tran_data_history.total_cost: tran_code = 1 and sales type = C
NET_SALES_CLEAR_RE TAIL	Number(20,4)	No	tran_data_history.total_retail: tran_code = 1 and sales type = C
NET_SALES_REG_RETAI L_VAT_EXCL	Number(20,4)	No	tran_data_history.total_retail: tran_code = 2 and sales type = R
NET_SALES_PROMO_R TL_VAT_EXCL	Number(20,4)	No	tran_data_history.total_retail: tran_code = 2 and sales type = P
NET_SALES_CLR_RETAI	Number(20,4)	No	tran_data_history.total_retail:
L_VAT_EXCL			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_UNI TS	Number(12,4)	No	tran_data_history.units: tran_code = 4 and sales type = P
RETURNS_PROMO_COS T	Number(20,4)	No	tran_data_history.total_cost: tran_code = 4 and sales type = P
RETURNS_PROMO_RET AIL	Number(20,4)	No	tran_data_history.total_retail: tran_code = 4 and sales type = P
RETURNS_CLEAR_UNIT S	Number(20,4)	No	tran_data_history.units: tran_code = 4 and sales type = C
RETURNS_CLEAR_COS T	Number(20,4)	No	tran_data_history.total_cost: tran_code = 4 and sales type = C
RETURNS_CLEAR_RETA IL	Number(20,4)	No	tran_data_history.total_cost: tran_code = 4 and sales type = C
REG_MARKDOWN_RETA IL	Number(20,4)	No	tran_data_history.total_retail: tran_code 13 - tran_code 14 (Markdown Cancel) - tran_code 11 (Markup)
PROMO_MARKDOWN_R ETAIL_REG	Number(20,4)	No	tran_data_history.total_retail: tran_code = 15 - if the item is not on clearance EOW
PROMO_MARKDOWN_R ETAIL_CLEAR	Number(20,4)	No	tran_data_history.total_retail: tran_code = 15 - if the item is on clearance EOW
CLEAR_MARKDOWN_RE TAIL	Number(20,4)	No	tran_data_history.total_retail: tran_code = 16
WF_MARKDOWN_RETAI L	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

Field Name	Field Type	Required	Description
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_UNIT S	Number(12,4)	No	tran_data_history.units: tran_code = 23
NON_SHRINK_ADJ_COS T	Number(20,4)	No	tran_data_history.total_cost: tran_code = 23
NON_SHRINK_ADJ_RET AIL	Number(20,4)	No	tran_data_history.total_retail: tran_code = 23
DEAL_INCOME_PURCH ASES	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_MARK UP	Number(20,4)	No	tran_data_history.total_retail: tran_code 17
INTERCOMPANY_MARK DOWN	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

Field Name	Field Type	Required	Description
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_BOO K	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_MARGI N	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_UNI TS	Number(12,4)	No	tran_data_history.units: tran_code = 82
FRANCHISE_SALES_CO ST	Number(20,4)	No	tran_data_history.total_cost: tran_code = 82
FRANCHISE_SALES_RE TAIL	Number(20,4)	No	tran_data_history.total_retail: tran_code = 82

Field Name	Field Type	Required	Description
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

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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 Inventory Planning Optimization Cloud Service - Demand Forecasting
- 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

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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 Inventory Planning Optimization Cloud Service - Demand Forecasting

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

Restart/Recovery

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_DA TA_CTL	Yes	No	No	No
BDI_DWNLDR_IFACE_DATA_CT L	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 from Sales Audit to Oracle Retail Insights (saexpdw)
Export Inventory Reservation/Release for In Store Customer Order & Layaway Transactions (saordinvexp)
Export of POS transactions from Sales Audit to Merchandising (saexprms) (file-based integration)
Export of POS Transactions from Sales Audit to Merchandising Based on Direct Table Load (saexprocsales) (table-based integration)
Export of Revised Sale/Return Transactions from ReSA to SIM/SIOCS (saexpsim)
Export of Revised Sale/Return Transactions from Sales Audit to Store Inventory Management (saexport_sales_to_sim)
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

Schedule

Oracle Retail Merchandising Batch Schedule

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-22 Output File

Record Name	Field Name	Field Type	Default Value	Description
ACH File	Section No.	Number(3)	101	Constant number.
Header	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	Section No.	Number(4)	5225	Constant number.
Batch Header	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.

Table 6-22 (Cont.) Output File

Record Name	Field Name	Field Type	Default Value	Description
	Batch No	Number(7)		Batch number.
ACH CBR	Section No.	Number(4)	5225	Constant number.
Batch Header	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.

Table 6-22 (Cont.) Output File

Record Name	Field Name	Field Type	Default Value	Description
	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	Section No.	Number(3)	701	Constant number.
Addendum	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	Section No.	Number(4)	8225	Constant number.
Control	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).

Table 6-22 (Cont.) Output File

Record Name	Field Name	Field Type	Default Value	Description
	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	Section No.	Number(1)	9	Constant number.
Control	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).

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

I/O Specification

Integration Type	Download from Sales Audit
File Name	N/A
Integration Contract	IntCon000039

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Integration Contract

Integration Type	Download from Sales Audit
File Name	N/A
Integration Contract	IntCon00004
	INVC_HEAD table

Design Assumptions

N/A

Export from Sales Audit to Oracle Retail Analytics (saexport_sales_to_dw)

Module Name saexport_sales_to_dw.ksh 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

Schedule

Oracle Retail Merchandising Batch Schedule

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 them into the interface tables SA_EXPDW_RDW* . Retail Data Store (RDS) views have been written on the top of these interface tables so that the Oracle Retail Analytics application can fetch the exported sales and return data through Retail Data Store (RDS). 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.

The batch has been designed to integrate with either Oracle Retail Insights or a 3rd Party Retail Analytics system. For integration with Oracle Retail Insights, this batch will export RDWT and RDWF data to three tables at the store day level:

SA_EXPDW_RDWT_HEAD – Transaction head and transaction items are exported to this table.
SA_EXPDW_RDWT_DETAIL – Transaction discounts are exported to this table.
SA_EXPDW_RDWF_DETAIL – Form of payment (tender) is exported to this table.

For integration with a third-party Retail Analytics system, this batch will additionally export RDWS and RDWC data to two more tables at the store day level:

SA_EXPDW_RDWS_DETAIL – Store Totals are exported to this table.
SA_EXPDW_RDWC_DETAIL – Cashier/Register Totals are exported to this table.

The export of RDWS and RDWC data to SA_EXPDW_RDWS_DETAIL and SA_EXPDW_RDWC_DETAIL is controlled by a Y/N flag defined in the MERCH_BATCH_PARAM table with a batch_name of SAEXPDW_EXPORT_JOB and param_key of EXPORT_DW_S_C . The default value of the flag is N .

For customers using Oracle Retail Insights, EXPORT_DW_S_C should be set to N to prevent the batch from writing to SA_EXPDW_RDWS_DETAIL and SA_EXPDW_RDWC_DETAIL , because Oracle Retail Insights doesn’t need the RDWS and RDWC data.

For customers using a third-party Retail Analytics and requiring Store Totals or Cashier/ Register Totals, the EXPORT_DW_S_C flag needs to be set to Y to extract RDWS and RDWC data.

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
SA_EXPDW_RDWS_DETAIL	No	Yes	No	No
SA_EXPDW_RDWC_DETAIL	No	Yes	No	No
SA_TOTAL	Yes	No	No	No
SA_TOTAL_HEAD	Yes	No	No	No
SA_TOTAL_USAGE	Yes	No	No	No
SA_HQ_VALUE	Yes	No	No	No
SA_STORE_VALUE	Yes	No	No	No
SA_SYS_VALUE	Yes	No	No	No
SA_POS_VALUE	Yes	No	No	No
SA_STORE_EMP	Yes	No	No	No
SA_BALANCE_GROUP	Yes	No	No	No
SA_ERROR	Yes	No	No	No
SA_ERROR_IMPACT	Yes	No	No	No
IF_ERRORS	No	Yes	No	No
SA_EXPDW_WC_WS_TEMP	Yes	Yes	Yes	Yes

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-23 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 YYYYMMDDHH24 MISS	Yes
Transaction Header	File Type Record Descriptor	Char(5)	THEAD	Identifies transaction record type

Table 6-23 (Cont.) RDWT File

Field Name	Field Type	Default Value	Description	Required
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 YYYYMMDDHH24 MISS (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

Table 6-23 (Cont.) RDWT File

Field Name	Field Type	Description	Required
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

Table 6-23 (Cont.) RDWT File

Field Name	Field Type	Default Value	Description	Required
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	No. Required if
			item or gift certificate.	Item Type is not null.

Table 6-23 (Cont.) RDWT File

Record	Field Name	Field Type	Default	Description	Required
Name			Value
	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	Number(20)		Sales value, net sales value of	No
	Value			goods sold/returned with 4 implied decimal places.
	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	Char(1)	‘P’- positive		No
	sign		‘N’ – negative

Table 6-23 (Cont.) RDWT File

Record	Field Name	Field Type	Default	Description	Required
Name			Value
	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

Table 6-23 (Cont.) RDWT File

Field Name	Field Type	Description	Required
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

Table 6-23 (Cont.) RDWT File

Record	Field Name	Field Type	Default	Description	Required
Name			Value
	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	Char(30)			No
	Number 28

Table 6-23 (Cont.) RDWT File

Record	Field Name	Field Type	Default	Description	Required
Name			Value
	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

Table 6-23 (Cont.) RDWT File

Record	Field Name	Field Type	Default	Description	Required
Name			Value
	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

Table 6-23 (Cont.) RDWT File

Record Name	Field Name	Field Type	Default Value	Description	Required
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-24 File Layout

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 YYYYMMDDHH24M ISS	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

Table 6-24 (Cont.) File Layout

Record	Field Name	Field Type	Default	Description	Required
Name			Value
	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

Table 6-24 (Cont.) File Layout

Field Name	Field Type	Default Value	Description	Required
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

Table 6-24 (Cont.) File Layout

Record	Field Name	Field Type	Default	Description	Required
Name			Value
	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

Table 6-24 (Cont.) File Layout

Field Name	Field Type	Default Value	Description	Required
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

Table 6-24 (Cont.) File Layout

Record	Field Name	Field Type	Default	Description	Required
Name			Value
	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

Table 6-24 (Cont.) File Layout

Field Name	Field Type	Default Value	Description	Required
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	Char(1)	‘P’- positive		Yes
Sign		‘N’ – negative

Table 6-24 (Cont.) File Layout

Record	Field Name	Field Type	Default	Description	Required
Name			Value
	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	Char(30)			No
	Number 31

Table 6-24 (Cont.) File Layout

Field Name	Field Type	Description	Required
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-25 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

Table 6-25 (Cont.) RDWF File

Record Name	Field Name	Field Type	Default Value	Description	Required
	File Create Date	Number(14)	create date	Date file was written by external system. Format YYYYMMDDHH2 4MISS	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 YYYYMMDDHH2 4MISS	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

Table 6-25 (Cont.) RDWF File

Record	Field Name	Field Type	Description	Required
Name
	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	Char(30)		No
	Number 11

Table 6-25 (Cont.) RDWF File

Record Name	Field Name	Field Type	Default Value	Description	Required
	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-26 Form of Payment File

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 YYYYMMDDHH2 4MISS	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

Table 6-26 (Cont.) Form of Payment File

Record	Field Name	Field Type	Description	Required
Name
	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 Grou is
				p ‘COUPON’.

Table 6-26 (Cont.) Form of Payment File

RDWS File

Record Name	Field Name	Field Type	Default Value	Description	Required
	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
Table 6-27 Record Name	RDWS File 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 YYYYMMDDHH2 4MISS	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

Table 6-27 RDWS File

Table 6-27 (Cont.) RDWS File

Record Name	Field Name	Field Type	Default Value	Description	Required
	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-28 Store Totals Information

Record	Field Name	Field Type	Description	Required
Name
	Business date	Number(8)	Format	Yes
			YYYYMMDD

Table 6-28 (Cont.) Store Totals Information

Field Name	Field Type	Default Value	Description	Required
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-29 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 YYYYMMDDHH2 4MISS	Yes

Table 6-29 (Cont.) RDWC File

Record Name	Field Name	Field Type	Default Value	Description	Required
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		Yes
			‘N’ – negative

Table 6-29 (Cont.) RDWC File

Record Name	Field Name	Field Type	Default Value	Description	Required
	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-30 Cashier/Register Totals Information

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

Table 6-30 (Cont.) Cashier/Register Totals Information

Field Name	Field Type	Default Value	Description	Required
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

Design Assumptions

N/A

Export Inventory Reservation/Release for In Store Customer Order & Layaway Transactions (saordinvexp)

saordinvexp.pc

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

Schedule

Oracle Retail Merchandising Batch Schedule

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_<tran_date>
Integration Contract	IntCon000049

Output File Layout

Table 6-31 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.

Table 6-31 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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	Type of transaction.
			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
	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.

Table 6-31 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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).

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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 consignment rate review process is used, then consignment transactions eligible for review will not be exported from Sales Audit to Merchandising until the transaction has either been marked as reviewed or the review period specified has elapsed. Once the review period has elapsed, the batch will mark the transactions still pending review as expired and export them to Merchandising.

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 releases the lock. 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 ReSA
File Name	“POSU_” appended with store number, business date and system date
Integration Contract	IntCon000044

Table 6-32 File Layout

Record	Field Name	Field Type	Default Value	Description
Name
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)		File Create Date in YYYYMMDDHHMMSS format
	Store	Number(10)		Store location

Table 6-32 (Cont.) File Layout

Record	Field Name	Field Type	Default Value	Description
Name
	Vat include indicator	Char(1)		Determines whether or not the store stores values including vat. Not required but populated by Oracle Retail sales audit
	Vat region	Number(4)		Vat region the given location is in. Not required but populated by Oracle Retail sales audit
	Currency code	Char(3)		Currency of the given location. Not required but populated by Oracle Retail sales audit
	Currency retail decimals	Number(1)		Number of decimals supported by given currency for retails. Not required but populated by Oracle Retail sales audit
THEAD	Record descriptor	Char(5)	THEAD	Identifies the file record type
	File Line Id	Char(10)		Sequential file line number
	Transaction date	Char(14)		Transaction date in YYYYMMDDHHMMSS format. Corresponds to the date that the sale/return transaction was processed at the POS
	Item Type	Char(3)	REF or ITM	Can be REF or ITM
	Item	Char(25)		Id number of the ITM or REF
	Dept	Number(4)		Department of item sold or returned.
	Class	Number(4)		Class of item sold or returned.
	Sub Class	Number(4)		Subclass of item sold or returned.
	Pack Ind	Char(1)		Pack indicator of item sold or returned.
	Item Level	Number(1)		Item level of item sold or returned.
	Tran level	Number(1)		Transaction level of item sold or returned.
	Wastage Type	Char(6)		Wastage type of item sold or returned
	Wastage pct	Number(12)		Waste pct (4 implied decimal places)
	Tran type	Char(1)		Transaction type code to specify whether transaction is a sale or a return
	Drop Shipment indicator	Char(1)		Indicates whether the transaction is a drop shipment or not.
	Total sales qty	Number(12)		Total sales quantity (4 implied decimal places)
	Selling UOM	Char(4)		Selling Unit of Measure for the item

Table 6-32 (Cont.) File Layout

Field Name	Field Type	Description
Sales sign	Char(1)	Determines if the Total Sales Quantity and Total Sales Value are positive or negative.
Total Sales Value	Number(20)	Total sales value of goods sold/ returned (4 implied decimal places)
Last Date time modified	Char(14)	Date and time of last modification in YYYYMMDDHHMMSS format. For VBO future use
Catchweight indicator	Char(1)	Indicates if item is a catchweight item.
Total weight	Number(12)	The actual weight of the item, only populated if catchweight_ind = ‘Y’
Sub Tran type indicator	Char(1)	Tran type for ReSA Valid values are ‘A’, ‘D’, NULL
Total IGTAX Value	Number(20)	This will indicate total of all IGTAX amount for the item.
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).
No Inventory Return Indicator	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.
Return Disposition	Char(10)	This column will contain the disposition code published by RWMS as part of the Returns upload to OMS.
Return Warehouse	Char(10)	This column contains the physical warehouse ID for the warehouse identifier where the item was returned.
Customer Order No	Char(48)	This column contains the customer order number ID.
Fulfillment Order No	Char(48)	This column contains the fulfillment order number ID.
Fulfillment Loc Type	Char(2)	This column contains the fulfillment location type. Code for the fulfillment loc type from code_detail where code_type = ‘FLTP’
Fulfillment Loc	Number(10)	This column contains the fulfillment loc ID.
Orig Store	Number(10)	This column contains the original store value for a Return transaction.

Table 6-32 (Cont.) File Layout

Record	Field Name	Field Type	Default Value	Description
Name
	POS Tran Id	Number(20)		This column contains the unique identifier for a sale transaction. This is anOptionalfield.
	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.
	Consignment Rate	Number(12)		This column contains the consignment rate that should be applied while posting the sales/ returns to Merchandising. (4 implied decimal places)
	Consignment Unit Cost	Number(20)		This column contains the consignment unit cost that should be applied while posting the sales/ returns to Merchandising. (4 implied decimal places)
	Inventory Identifier Type	Char(6)		This column contains the inventory identifier type passed in Sales/ Return transactions. Valid values are found under the Inventory Identifier Types (IIDT) code type, for e.g Lot (L), Expiry Date (E), Import Document (D).
	Inventory Id	Char(120)		This column contains the inventory id value being passed in sales/ return transactions.
TTAX	Record descriptor	Char(5)	TTAX	Identifies the file record type
	File Line Id	Char(10)		Sequential file line number
	Tax Code	Char(6)		The Tax Code of the item
	Tax Rate	Number(20)		The tax rate of the item (10 implied decimal places)
	Total Tax Amount	Number(20)		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)		Sequential file line number
	Promo Tran Type	Char(6)		Code for the promotional type from code_detail where code_type = ‘PRMT’
	Promotion Number	Number(10)		Promotion number from Merchandising

Table 6-32 (Cont.) File Layout

Record Name	Field Name	Field Type	Default Value	Description
	Sales quantity	Number(12)		Sales quantity sold for this promotion type (4 implied decimal places)
	Sales value	Number(20)		Sales value for this promotion type (4 implied decimal places)
	Discount value	Number(20)		Discount value for this promotion type (4 implied decimal places)
	Promotion component	Number(10)		Links the promotion to additional pricing attributes. This contains the OFFER_ID from Pricing.
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)

Fields expected in POSU format based on changes adopted:

	V16	V16 with Customer Order Changes	V19	V19.3	V24	V25
Fulfillment Order No	No	Yes	Yes	Yes	Yes	Yes
Fulfillment Loc Type	No	Yes	Yes	Yes	Yes	Yes
Fulfillment Loc	No	Yes	Yes	Yes	Yes	Yes
Orig Store	No	Yes	Yes	Yes	Yes	Yes
POS Tran Id	No	No	Yes	Yes	Yes	Yes
Posting Store	No	No	No	Yes	Yes	Yes
Consignment Rate/ Unit Cost	No	No	No	No	Yes	Yes
Inventory Identifier Type	No	No	No	No	No	Yes
Inventory Id	No	No	No	No	No	Yes

Design Assumptions

1. 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.

2. POS can send either transactional level tax details in TTAX lines or item-level tax details in IGTAX lines through the RTLOG file to ReSA. 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 ReSA 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.

3.

Export of POS Transactions from Sales Audit to Merchandising Based on Direct Table Load (saexprocsales)

Module Name saexprocsales.ksh Description Export of POS transactions from Sales Audit to Merchandising based on direct table load Functional Area Oracle Retail Sales Audit Module Type Integration Module Technology ksh Catalog ID RSA01 Wrapper Script rmswrap_shell.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch module fetches 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 store/day/transaction/item/price point/sales type level for the SALES transaction type and store/day/transaction/item/price point/sales type/no inventory return indicator/return disposition/return warehouse level for the RETURN transaction type.

If the 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 consignment rate review process is used, then consignment transactions eligible for review will not be exported from Sales Audit to Merchandising until the transaction has either been marked as reviewed, or the specified review period has elapsed. Once the review period has elapsed, the batch will mark the transactions still pending review as expired and export them to Merchandising.

If the transaction has a status of Deleted and it has previously been transmitted, a reversal of the transaction will be sent.

Transactions are exported to the Merchandising Sales process global temporary tables and the sales postings are processed.

The execution of this batch is controlled through a Sales Audit System option that indicates whether a table-based or file-based export is to be used.

Design Assumptions

For exports from Sales Audit to Merchandising, either saexprocsales or saexprms can be used to export Sales Audit transactions, depending on the configuration of Sales Audit.

For Merchandising, importing sales transactions is supported through both the saexprocsales table-based integration or POSU-file-based import modes.

POS can send either transaction-level tax details in TTAX lines or item-level tax details in IGTAX lines through the RTLOG file to Sales Audit. These tax details are passed on to Merchandising in relevant sales processing, global, temporary table records.

For a non-GTS environment, 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 the Merchandising sales upload process and assigned one of the applicable tax codes when writing tran_data 88 .

When GTS is set as the Default Tax type in the system options, the sales process batch should be capable of both processing multiple records in sales processing global temporary tables, and posting multiple lines for transaction code 88 , with one line for each tax detail record.

When GTS is set to the Default Tax type in the system options, the sales process batch can process multiple TTAX lines in the POSU file and post multiple lines for transaction code 88 , one for each TTAX line.

Restart/Recovery

The logical unit of work for this module is defined as a unique store/day combination. The rollback segment should be large enough to hold all inserts into sa_exported for one store/day.

The number of threads running in parallel is based on the RMS_PLSQL_BATCH_CONFIG.MAX_CONCURRENT_THREADS column value with the SA_EXPROC_SALES_SQL program name.

Key Tables Affected

Table	Select	Insert	Update	Delete
SA_STORE_DAY	Yes	No	No	No
SA_EXPORT_LOG	Yes	No	Yes	No
MV_SA_RESTART _EXPORT_RMS	Yes	No	No	No
STORE	Yes	No	No	No
CURRENCIES	Yes	No	No	No
SA_TRAN_HEAD	Yes	No	No	No
SA_ERROR	Yes	No	No	No
SA_ERROR_IMPA CT	Yes	No	No	No
SA_EXPORTED	Yes	Yes	No	No
SA_TRAN_SEQ_T EMP	No	Yes	No	Yes
SA_TRAN_HEAD_ REV	Yes	No	No	No
SA_EXPORTED_R EV	Yes	No	No	No
SA_SYSTEM_OPT IONS	Yes	No	No	No

Table	Select	Insert	Update	Delete
SA_TRAN_ITEM_ REV	Yes	No	No	No
ITEM_MASTER	Yes	No	No	No
SA_TRAN_DISC_ REV	Yes	No	No	No
SA_TRAN_DISC	Yes	No	No	No
SA_TRAN_ITEM	Yes	No	No	No
SA_TRAN_SEQ_T EMP	Yes	Yes	No	Yes
SA_STORE_DAY_ READ_LOCK	No	Yes	No	Yes
SA_TRAN_IGTAX_ REV	Yes	No	No	No
SA_TRAN_IGTAX	Yes	No	No	No
SA_TRAN_TAX	Yes	No	No	No
SA_TRAN_TAX_R EV	Yes	No	No	No
VAT_ITEM	Yes	No	No	No
VAT_HISTORY	No	Yes	Yes	No
DAILY_SALES_DIS COUNT	No	Yes	Yes	No
JOB_AUDIT_LOG	No	Yes	No	No
SA_EXPROC_SAL ES_ERROR	No	Yes	No	No
SVC_TRAN_HEAD _GTT	No	Yes	No	No
SVC_POSUPLD_F HEAD_GTT	No	Yes	No	No
SVC_POSUPLD_T HEAD_GTT	No	Yes	Yes	Yes
SVC_POSUPLD_T TAX_GTT	No	Yes	No	No
SVC_POSUPLD_T DETL_GTT	No	Yes	No	No
DEAL_HEAD	Yes	No	No	No
DEAL_COMP_PR OM	Yes	No	No	No
DEAL_ACTUALS_ FORECAST	Yes	No	No	No
ITEM_LOC	Yes	No	No	No
ITEM_LOC_SOH	Yes	No	Yes	No
VAT_ITEM	Yes	No	No	No
ITEM_SUPP_COU NTRY	Yes	No	No	No
ITEM_SUPPLIER	Yes	No	No	No

Table	Select	Insert	Update	Delete
SUPS	Yes	No	No	No
TERMS	Yes	No	No	No
PRICE_HIST	Yes	No	No	No
TEMP_TRAN_DAT A	No	Yes	No	No
ITEM_LOC_HIST	Yes	Yes	Yes	No
ITEM_LOC_HIST_ MTH	Yes	Yes	Yes	No
EDI_DAILY_SALES	Yes	Yes	Yes	No
ORDHEAD	Yes	Yes	No	No
INVC_HEAD	Yes	Yes	No	No
INVC_MERCH_VA T	Yes	Yes	Yes	No
INVC_XREF	No	Yes	No	No
INVC_DETAIL_TE MP2	No	Yes	No	No
INVC_DETAIL	Yes	No	No	No
CODE_DETAIL	Yes	No	No	No
UOM_CLASS	Yes	Yes	No	No
ITEM_XFORM_HE AD	Yes	No	No	No
ITEM_XFORM_DE TAIL	Yes	No	No	No
ITEM_SUPP_COU NTRY_LOC	Yes	No	No	No
TRAN_DATA	No	Yes	No	No
INVC_DETAIL_TE MP	No	Yes	No	No
INVC_HEAD_TEM P	No	Yes	No	No
CONCESSION_DA TA	No	Yes	No	No
DEAL_ACTUALS_I TEM_LOC	Yes	Yes	Yes	No
V_PACKSKU_QTY	Yes	No	No	No
RTV_HEAD	Yes	No	No	No

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-33 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.

Table 6-33 (Cont.) Output File

Record Name	Field Name	Field Type	Default Value	Description
	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.

Table 6-33 (Cont.) Output File

Record Name	Field Name	Field Type	Default Value	Description
	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).

Design Assumptions

N/A

Export of Revised Sale/Return Transactions from Sales Audit to Store Inventory Management (saexport_sales_to_sim)

Module Name saexport_sales_to_sim.ksh Description Export of Revised Sale/Return Transactions from ReSA to SIOCS in a Direct Database integration. Functional Area Oracle Retail Sales Audit Module Type Integration Module Technology KSH Catalog ID Wrapper Script

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

The purpose of this batch module is to fetch all revised sale and return transactions that do not have SIOCS errors from the Sales Audit database tables for transmission to Store Inventory Operations System (SIOCS). 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 , then the whole store/day is skipped if any SIOCS error is found. If this value is T , then only transactions with SIOCS errors are skipped.

The batch will only export transactions whose quantity has been revised. The batch will write these revised transactions to the SA_EXPSIM_REVISED_SALES_HEAD and

SA_EXPSIM_REVISED_SALES_DETAIL interface tables along with a reversal of the quantity. It will also populate the ICL_SA_REVISED_SALES table to signal the Store Inventory Operations system to process the data.

Note

This batch can be run in two modes – trickle mode and batch mode. If Y is passed as a parameter while running the batch, then the batch would run in trickle mode else if N or no parameter is passed, it would then run in normal batch mode.

Restart/Recovery

The logical unit of work for this module is defined as a unique store/day combination. 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 store all inserts into SA_EXPORTED for one store/ day.

Tables Affected

Table	Select	Insert	Update	Delete
ICL_SA_REVISED_SALES	No	Yes	No	No
SA_EXPSIM_REVISED_SALES_HEAD	No	Yes	No	No
SA_EXPSIM_REVISED_SALES_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_ERROR	Yes	No	No	No
SA_ERROR_IMPACT	Yes	No	No	No

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-34 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.

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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_.xml
Integration Contract	IntCon000018

Output File Layout

Table 6-35 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.

Table 6-35 (Cont.) Output File Layout

Field Name	Field Type	Description
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.

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

I/O Specification

Integration Type	Download from Sales Audit
File Name	N/A
Integration Contract	IntCon000019
	TG_FIF_GL_DATA

Design Assumptions

N/A

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)
Upload Items and Cost Changes (iindbatch.ksh)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-36 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 YYYYMMDDHH2 4MISS format.
File Detail	File Type Record	CHAR (5)	FDETL	Value that identifies the
	Descriptor			record type.
	File Line Identifier	NUMBER (10)		Sequential file line number.

Table 6-36 (Cont.) Input File Layout

Field Name	Field Type Default Value	Description
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 YYYYMMDDHH2 4MISS 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	NUMBER(10)	Numeric value
Store ID		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 YYYYMMDD24M ISS format.
Competitive	NUMBER(20,4)	Numeric value
Retail Price		that represents
		the retail price at
		the competitor’s store. Format for this value should
		include four
		implied decimal
		places.

Table 6-36 (Cont.) Input File Layout

Field Name	Field Type	Default Value	Description
Competitive	CHAR(6)	R, P, C	Value that
Retail Type			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
			YYYYMMDDHH2 4MISS format.
Promotion End	CHAR (14)		Effective end
Date			date of the competitor’s
			price. It should be in the YYYYMMDDHH2 4MISS format.
Offer Type	CHAR(6)		Alphanumeric
Code			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.

Table 6-36 (Cont.) Input File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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.

Design Assumptions

Items included in the file must be defined as transaction level items in Merchandising.

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_multi_in.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

Design Assumptions

N/A

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
Import Management
Stock Counts
Franchise
Other Inventory

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:

Upload of Deals from 3rd Party Systems (dealupld)
Upload Order Data (poindbatch.ksh)
Upload OTB Budget from Planning Systems (otbupld)
Upload Purchase Order and Purchase Order Change Acknowledgements from Suppliers to RMS (ediupack)
Upload Replenishment Data (replindbatch.ksh)

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 the submitted ( S ) or approved ( A ) status as well based on the Deal Upload Status configuration for the supplier. In case of any validation errors during the deal submission or approval, it will be created in the worksheet status and the user needs to manually rectify the error through the Deal UI to approve it.

Note

This functionality is limited to Supplier-based deals. Deals created for other Partners can only be created in the worksheet status.

Backward Compatibility

Added additional parameter to indicate version. If no parameter is given, then the version defaults to 1 (initial version).

Assumptions

1. The fields noted below can be omitted from the file format if you are not creating deals with a billing type of Clearance Consignment Rate (CCR), Promotional Consignment Rate (PCR) or Vendor Funded Promotion (VFP).

Consignment Rate in the TDETL record for Transaction Detail Record Type DCDTL .
The CPDTL section of the file, including THEAD , TDETL , and TTAIL .
a. Clearance Consignment Rate ( CCR ):
The DCDTL TDETL Consignment Rate must be included in the upload.
The CPDTL section is not required for CCR type.
b. Promotional Consignment Rate ( PCR ):
- The CPDTL section is required for PCR type.

Note

The CPDTL TDETL expects only File Type Record Descriptor, File Line Identifier, Prom ID, Promo Comp Id, Consignment Rate, Reference Line.

c. Vendor Funded Promotion ( VPF ):
- The CPDTL section is required for VPF type.

Note

The CPDTL TDETL expects File Type Record Descriptor, File Line Identifier, Prom ID, Promo Comp Id, Consignment Rate (to be defaulted to 0 as not required for VFP ), Reference Line, Vendor Contrib Type, Contrib Value, and Promo Source.

This is to support backward compatibility.

The Promo Source field usage is based on the file version being used.
- If the file version is 1
  - Promo Source (in the CPDTL TDETL ) is not required and will not be validated.
- If the file version is 2
- The Promo Source (in the CPDTL TDETL ) is a required field in the CPDTL TDETL

2. In File version number 3, a new billing type Allowance ( ALW ) has been introduced. Version number 3 need to be explicitly specified by user while calling the batch to create ALW deals.

3. If the input file contains billing type as BB and rebate indicator as Y , then the billing type will be converted to BBR while inserting into the DEAL_HEAD table.

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-37 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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Field Name	Field Type	Default Value	Description/Constraints
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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Field Name	Field Type	Default Value	Description/Constraints
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	Currency code of the deal’s currency. All costs on the deal will be held in this currency.
		string)	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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record Name	Field Name	Field Type	Default Value	Description/Constraints	Added in Version
	Billing Type	Char(6)	REQUIRED	Billing type of the deal component. Valid values are ‘OI’ for off- invoice, ‘BB’ for bill-back, ‘BBR’ for bill-back rebate, ‘VFP’ for vendor funded promotion, ‘VFM’ for vendor funded markdown, ‘CCR’ for clearance consignment rate and ‘PCR’ for promotional consignment rate and ‘ALW’ for allowance. 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 ‘BBR’ or ‘VFP’ or ‘VFM’. Valid bill back period codes are ‘W’, ‘M’, ‘Q’, ‘H’, ‘A’. If Billing Type is ‘BB’ or ‘BBR’, 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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record Name	Field Name	Field Type	Default Value	Description/Constraints	Added in Version
	Deal Invoicing Basis	Char(6)	Blank (space character string)	Indicates when and how the deal component should be applied for invoicing for Purchase Based Bill Back deals. Valid values are ‘O’ for Approved POs, ‘R’ for Net Receipts, ‘G’ for Gross Receipts, and ‘S’ for Shipment. These values will be held on the codes tables under a code type of ‘AALC’. In case of ‘O’ – Approved POs, the deal would apply based on when the PO was approved, in case of ‘R’ – Net Receipts and ‘G’ – Gross Receipts, the deal would apply based on when receipt was made and in case of ‘S’ – Shipment, the deal would apply based on when shipment was made. In case of Net Receipts, receipts are adjusted for Returns to Vendor (RTVs) and Receiver Unit and Cost Adjustments; while in case of Gross Receipts, gross value of receipts are considered. This attribute is not applicable to an M-type deal (vendor funded markdown) and must be NULL.
	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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Field Name	Field Type	Default Value	Description/Constraints
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 ‘BB’, ‘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’.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record Name	Field Name	Field Type	Default Value	Description/Constraints
	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	Char(6)	Blank (space character	Indicates if the rebate should be applied to purchases or sales. Valid values are ‘P’ for
	Application Indicator		string)	purchases, ‘S’ for sales, and ‘I’ for issues. 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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record Name	Field Name	Field Type	Default Value	Description/Constraints
	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’ or ‘BBR’ 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’ or ‘BBR’ then Collect End Date must not be blank, otherwise it has to be blank.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Field Name	Field Type	Default Value	Description/Constraints
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. It must be N for ‘ALW’ deal.
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’, ‘PCR’, and ‘ALW’ deals.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Field Name	Field Type	Default Value	Description/Constraints
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’ or ‘BBR’, then the Threshold Value Type must be ‘A’ or ‘P’. If billing type is ‘ALW’ it can have values ‘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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Field Name	Field Type	Default Value	Description/Constraints
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	Number(12, 4)	All 0s.	Indicates the targeted purchase level for all locations on a
Target Quantity			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	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
Quantity Per Location			value is required for quantity threshold value type deals. Otherwise it has to be 0.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Field Name	Field Type	Default Value	Description/Constraints
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’, ’PCR’, and ‘ALW’ deals, the valid value is ‘N’. No DIDTL or PPDTL records may be present for a Transaction Level Discount DCDTL record.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record Name	Field Name	Field Type	Default Value	Description/Constraints
	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.
	Consignme nt 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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record Name	Field Name	Field Type	Default Value	Description/Constraints	Added in Version
	Prom ID	Number (10)	All 0s.	Promotion identification number.
	Promo Comp Id	Number (10)	All 0s.	Promotion offer identification number.
	Consignme nt 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.
	Vendor Contrib Type	Varchar2(6)	Blank (space character string).	Vendor Contribution Type can be ‘P’ Percent or ‘A’ Amount, and is required for VFP Deal. This field is not required for PCR Deal
	Contrib Value	Number(20, 4)	All 0s	Rate used to capture the deal Contribution Value applicable for the set of item/location combinations that are included in the deal during the deal timeframe.
				If Vendor Contrib Type is ‘P’, then the value should be between 0 and 100. For Vendor Contrib Type ‘A’, a positive value is required.
	Promo Source	Varchar2(2)	Blank (space character string).	This contains the Promo Source. Valid values are ‘MP’ (Merch Pricing) or ’CE’ (Customer Engagement). If the Promo Source is ‘MP’, the promo_id and promo_comp_id (offer_id) should be from Pricing.	2
				If the Promo Source is ‘CE’, the promo_id (promotion_id) and promo_comp_id (deal_id) should be from the Customer Engagement (CE).
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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record Name	Field Name	Field Type	Default Value	Description/Constraints
	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.
	Merchandis e 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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Field Name	Field Type	Default Value	Description/Constraints
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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Field Name	Field Type	Default Value	Description/Constraints
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 Grandparen t	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).
Differentiato r 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.
Differentiato r 2	Char(10)	Blank (space character	Diff_group or diff_id that differentiates the current item from its item_parent.
		string)	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.
Differentiato r 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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Field Name	Field Type	Default Value	Description/Constraints
Differentiato r 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.
Organizatio nal 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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record Name	Field Name	Field Type	Default Value	Description/Constraints
	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	Unique alphanumeric value that identifies the item.
			character string)	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	Numeric ID(6)	Sequential number	Number of records/transactions in current transaction set (only
	Counter		Created by program.	records between thead and ttail).

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record Name	Field Name	Field Type	Default Value	Description/Constraints
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 Performanc e 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 Performanc e 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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record Name	Field Name	Field Type	Default Value	Description/Constraints
	Proof of Performanc e 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 Recommen ded Start Date	Char(14)	Blank (space character string)	This column holds the date that the vendor recommends that the POP begin.
	Vendor Recommen ded 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).

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record Name	Field Name	Field Type	Default Value	Description/Constraints
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).

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Record	Field Name	Field Type	Default	Description/Constraints	Added in
Name			Value		Version
	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_typ e 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.
	Allowance_ comp_id	Char(10)	Blank (space character string)	This field will hold an allowance component that contains the details on how the allowance is to be calculated. This field is mandatory if the billing type is ‘ALW’.	3
	Allowance_ comp_rate	Number(20, 4)	Blank (space character string)	The field will hold the rate for an allowance	3
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.

Table 6-37 (Cont.) dealupld.pc - Input File Layout

Field Name	Field Type	Default Value	Description/Constraints
File Record Counter	Numeric ID(10)	Sequential number	Number of records/transactions in current file (only records
		Created by	between head and tail).
		program.

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`

Vendor Contrib	Varchar2(6)	Blank (space	Vendor
Type		character string).	Contribution Type can be ‘P’ Percent or ‘A’ Amount, and is required for VFP Deal. This field is not required for PCR Deal
Contrib Value	Number(20,4)	All 0s	Rate used to capture the deal Contribution Value applicable for the set of item/ location combinations that are included in the deal during the deal timeframe. If Vendor Contrib Type is ‘P’, then the value should be between 0 and 100.
			For Vendor Contrib Type ‘A’, a positive value is required.

Promo Source Varchar2(2) Blank (space This contains 2 character the Promo string). Source. Valid values are ‘MP’ (Merch Pricing) or ’CE’ (Customer Engagement). If the Promo Source is ‘MP’, the promo_id and promo_comp_id (offer_id) should be from Pricing. If the Promo Source is ‘CE’, the promo_id (promotion_id) and promo_comp_id (deal_id) should be from the Customer Engagement (CE). 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_multi_in.ksh

Upload Order Data (poindbatch.ksh)

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-38 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 YYYYMMDDHH 24MISS 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 YYYYMMDDHH 24MISS 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

Table 6-38 (Cont.) otbupld - Input File

Record Name	Field Name	Field Type	Default Value	Description
	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 YYYYMMDDHH 24MISS 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

Design Assumptions

POs with an Order Type of DSD and Customer Order do not impact open to buy.

Upload Purchase Order and Purchase Order Change Acknowledgements from Suppliers to RMS (ediupack)

Module Name

Description

ediupack.pc

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

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This program has four functions:

1. to acknowledge vendor receipt of a buyer-generated order without changes (acknowledge type AK)

2. to acknowledge vendor receipt of a buyer-generated order with date, cost or quantity modifications (acknowledge type AK)

3. to notify buyer of a new or updated vendor-generated order (acknowledge type AP)

4. 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 File Name Integration Contract

Upload to Merchandising Determined by runtime parameter IntCon000014

Input File Layout

Table 6-39 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)

Table 6-39 (Cont.) ediupack - Input File

Record Name	Field Name	Field Type	Default Value	Description
	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

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

Design Assumptions

N/A

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)
Letter of Credit Confirmation Upload (lcupld)
- SWIFT File Conversion - Letter of Credit Confirmation (lcmt730)
Letter of Credit Drawdowns and Charges Upload (lcup798)
- SWIFT File Conversion - Letter of Credit Drawdowns and Charges (lcmt798)
Transportation Upload (tranupld)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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. Once the HTS definitions have been updated in Merchandising, if the system settings indicate that updates of items and/or purchase orders should be performed, the program will update items and purchase orders if definitions of the HTS classifications that are associated with the items or orders were updated.

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-40 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

Table 6-40 (Cont.) Input File Layout

Record Name	Field Name	Field Type	Default Value	Description
	HTS Line	Char(418)	N/A	The HTS Line is broken down into subsections, V1, V2, V3, and V4 or VL. These subsections are concatenated together. The V1 and V2 subsections are required, but the V3, V4 and VL subsections are optional.The data in the V4 and VL subsections is not used by Merchandising/ Import Management, if provided, the data is ignored. For US imports, special programs are provided in the US HTS file in sections V3 and VD. The special program codes in both of these records should be concatenated together in the Oracle Retail HTS Upload Input File’s THEAD HTS Line’s V3 subsection. See HTS Line breakdown below for details
TDETL	Record	Char(5)	TDETL	Describes file line
	Descriptor			type
	Line number	Number(10)	N/A	Sequential file line number
	Transaction id	Number(14)	N/A	Unique transaction id

Table 6-40 (Cont.) Input File Layout

Record Name	Field Name	Field Type	Default Value	Description
	Tax/fee line	Char(95)	N/A	The Tax/Fee Line is broken down into subsections V5, V6, V7, V8, V9, VA, VB, and VC. Each subsection is optional and when provided, is expected to be on a separate TDETL line.
				If there is no data for a subsection, the entire TDETL record will not be present in the file, which means for some THEAD records there may not be any TDETL lines.
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	Number(10)	N/A	Number of lines
	Lines			between FHEAD and FTAIL

Input File THEAD – HTS Line Subsections

For each tariff (also referred to as an HTS classification), the HTS Line in THEAD is broken into concatenated subsections: V1, V2, V3, and V4 or VL. Subsections V1 and V2 are mandatory. Subsections V3, V4 and VL are optional, which means the entire subsection can be blank.

The inclusion of a V4 or VL subsection in the THEAD record will not cause any errors in the program. However, any data provided in subsections V4 or VL is not currently used in Merchandising/Import Management. Because neither is utilized by Merchandising/Import Management, they should be omitted from the input file completely.

If one or more special programs (tariff treatments) are associated with an HTS in the V3 subsection, and no corresponding V5-VC records are provided, the rates of the special program are assumed to be zero (that is, duty free).

Reco	Field Name	Field Type	Default Value	Description
rd Nam e
V1	Control identifier	Char(1)	V	Identifies start of record
a
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.

Reco rd	Field Name	Field Type Default Value	Description
Nam e
h	1^streporting 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. If this number is less than 4 positions, it is left justified.
I	2^ndreporting 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. If this number is less than 4 positions, it is left justified.
j	3^rdreporting 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. If this number is less than 4 positions, it is left justified.
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.

Reco	Field Name	Field Type	Default Value	Description
rd Nam e
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.
V2	Control identifier	char(1)	V	Identifies start of record
a
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.

Reco rd	Field Name	Field Type	Default Value	Description
Nam e
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.

Reco	Field Name	Field Type	Default Value	Description
rd Nam e
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	Blank space fill.
V3	Control identifier	char(1)	V	identifies start of record
a
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). Up to 10 2-position country codes.
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.

Reco d	Field Name	Field Type	Default Value	Description
r Nam e
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 thirty 2 position codes can be reported. Left justify, meaning if the SPI code is 1-position, space fill position 2. The tariff treatment codes are not reported in any sequence. For US imports, special programs are provided in the US HTS file in sections V3 and VD. The special program codes in both of these records should be concatenated together in the Oracle Retail HTS Upload Input File’s THEAD HTS Line’s V3 subsection.
V4 a	Control identifier	char(1)	V	Identifies start of record. The entire V4 record not used in Merchandising/Import Management. If provided, it will be ignored.
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.

Reco rd	Field Name	Field Type	Default Value	Description
Nam e
e	value low bounds	Number (10)		A value representing the minimum value edit. Five decimal places are implied. If this record contains date edits this field will contain, 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 this field will contain, 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 this field will contain, 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 this field will contain, 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 this field will contain, 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 this field will contain, space fill.

Reco	Field Name	Field Type	Default Value	Description
rd Nam e
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 this field will contain, 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 this field will contain, 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 this field will contain, space fill.
VL a	Control identifier	char(1)	V	Identifies start of record. The entire VL record not used in Merchandising/Import Management. If provided, it will be ignored.
b	Record type	char(1)	L	Identifies the 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.

Reco Field Name Field Type rd Nam e d Participating char(60) Government Agency (PGA) Codes e space fill char(8) blanks

Default Value

Description

Codes that indicate special requirements by participating government agencies (PGAs) must or may apply. Up to 20 3- position PGA codes can be provided. PGAs are not supported in MFCS at this time. This data is ignored by the system. blank space fill

Input File TDETL – TaxFee Line Subsections

The Tax/Fee Line in TDETL contains tax/fee information and rates for special programs (tariff treatments), and all have the same structure. The Tax/Fee Line is broken into optional subsections V5-V9, VA, VB, and VC. Each of these subsections is in its own TDETL line.

Record Name	Field Name	Field Type	Default Value	Description
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.

Record Name	Field Name	Field Type	Description
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.

Record Name	Field Name	Field Type	Default Value	Description
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 Merchandising/ Import Management.
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.
				If this field is filled with 0’s when no tax/fee class code,
				computation code, or flag are provided, HTS upload will ignore the rates. Meaning a rate filled with 0’s is the same as leaving the field blank.
l	tax/fee ad valorem	Number (12)	blank if no value, or filled with 0’s	The ad valorem rate of duty required to compute taxes and/or fees. Eight decimal places are implied.
				If this field is filled with 0’s when no tax/fee class code, computation code, or flag are provided, HTS upload will ignore the rates. Meaning a rate filled with 0’s is the same as leaving the field
				blank.
m	space fill	char(1)	blank	Space fill.

Note: V6, V7, V8, V9, VA, VB, and VC subsections have the same fields as the V5 subsection described above.

Note

The HTS Line in THEAD and the Tax/Fee Line in TDETL have subsections that start with a two-character code such as V1, V3, VA, and so on, which correspond to records provided by US Customs and Border Protection in the electronic file publication of the US Harmonized Tariff Schedule. The VD record in the US HTS file is used as an overflow for the V3 record in the event that the HTS tariff has more than 14 special programs (or tariff treatments). The Oracle Retail HTS Upload input file format supports additional special program codes in the V3 subsection of the THEAD HTS Line that is long enough to accept codes from both of the US HTS file’s V3 and VD records.

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-41 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 ‘YYYYMMDDHH 24MISS’ 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_l c_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.activit y_date	YYYYMMDDHH2 4MISS format
	Comments	Char(2000)	lc_activity.com ments	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

Table 6-41 (Cont.) Input File Layout

Record Name Field Name Field Type Default Value Description Total number Number(10) N/A Total number of lines lines in file not including FHEAD and FTAIL 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

Letter of Credit Drawdowns and Charges Upload (lcup798)

Schedule

Oracle Retail Merchandising Batch Schedule

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-42 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 YYYYMMDDHH2 4MISS 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

Table 6-42 (Cont.) Input File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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
version - Letter of Module Name	Credit Confirmation (l lcmt730	cmt730)
Description	SWIFT File Conversion –	Letter of Credit	Confirmation
Functional Area	Oracle Retail Trade Mana	gement
Module Type	Integration
Module Technology	Perl
Catalog ID	RMS138
Wrapper Script	batch_lcmt730.ksh

SWIFT File Conversion - Letter of Credit Confirmation (lcmt730)

Schedule

Oracle Retail Merchandising Batch Schedule

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-43 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 -	16x	LC number	FDETL	This field maps
Receiver’s Reference		assigned by the Receiver (retailer)	- Receiver’s reference, Number(8) (NOREF used if unknown)	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.

Table 6-43 (Cont.) 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
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	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:
		the message being acknowledged		If YY>79 then YYMMDD = 19YYMMDD
		was sent.		Else YYMMDD = 20YYMMDD.
32a -	Option B	Contains the	FDETL	Current position
Amount of	- 3!a15d	currency code	-Upload_type =	-
Charges	Option D - 6!n3!a15d	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).	’C’onfirmation	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.

Table 6-43 (Cont.) 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
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-44 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_l d_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.activit y_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.applicati on_date) ‘YYYYMMDD’ format

Table 6-44 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	Comments	Char(2000)	lc_activity.com ments	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

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-45 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

Table 6-45 (Cont.) Input File Layout

Swift Tag	Description	Regd?	Datatype	Merchandising Field
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_co de Varchar2(3) Lc_activity.activity_date Date

Table 6-45 (Cont.) Input File Layout

Swift Tag	Description	Regd?	Datatype	Merchandising Field
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_co de 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_co de Varchar2(3)
				Lc_activity.activity_date Date

Table 6-45 (Cont.) Input File Layout

Swift Tag	Description	Regd?	Datatype	Merchandising Field
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_co de 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)dir ectly 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-46 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 ‘YYYYMMDDHH24MI SS’
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	Identifies the type of transaction that occurred
			Charge – ‘B’ f the transaction is a Drawdown – ‘D’	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’

Table 6-46 (Cont.) Output File Layout

Field Name	Field Type	Default Value	Description
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,	Contains the activity’s currency code
		32D	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

Table 6-46 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
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

Schedule

Oracle Retail Merchandising Batch Schedule

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-47 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

Table 6-47 (Cont.) Input File Layout

Record	Field Name	Field Type	Default	Description Added in
Name			Value	Version
	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’

Table 6-47 (Cont.) Input File Layout

Field Name	Field Type	Description
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

Table 6-47 (Cont.) Input File Layout

Record Name	Field Name	Field Type	Default Value	Description Added in Version
	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 Fie	ld Type	Default Value Description Added in Version
FTRAN		Record descriptor Ch	ar(5)	FTRAN File head marker
		Line id Nu	mber(10)	0000000001 Unique line id
		File type definition Ch	ar(4)	TRUP Identifies program as tranupld
		File create date Ch	ar(14)	Current date YYYYMMDDH HMISS format
DTRAN		Record descriptor Ch	ar(5)	DTRAN Vessel, Voyage, ETD, Container, BL, Invoice File head

Field Name	Field Type	Default Value	Description
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_DETAI L 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’

Record Name	Field Name	Field Type	Default Value	Description
	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_TY PE table
	Freight Size	Char(6)	N/A	Code that identifies the container size. Validated against the FREIGHT_SIZ E 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

Field Name	Field Type	Default Value	Description
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 CURRENCIE S 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	Char(3)	N/A	Identifies
Country id			where the PO/ Item was made

Field Name	Field Type	Default Value	Description
Consolidatio n 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_DETAI L
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(wit h 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

Record Name	Field Name	Field Type	Default Value	Description
	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)

Design Assumptions

N/A

Stock Counts

Merchandising subscribes to data related to stock counts from stores, warehouses, and thirdparty counters.

The following scheduled inbound integrations are included in this functional area:

Conversion of Warehouse Stock Count Results File (lifstkup)
Upload Stock Count Results from Stores/Warehouses (stockcountupload.ksh)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-48 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-49 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

Table 6-49 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	stocktake_date	Date (14)	N/A	The date on which the count occurred, formatted as YYYYMMDDHH2 4MISS
	file create date	Date (14)	N/A	Date on which the file was created, formatted as YYYYMMDDHH2 4MISS
	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

Table 6-49 (Cont.) Output File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-50 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
				YYYYMMDDHH2 4MISS format
	Stock take date	Char(14)	N/A	Date on which stock count will take place in YYYYMMDDHH MISS 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

Table 6-50 (Cont.) Input File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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)
	Inventory Identifier Type	Char(6)		This field contains the inventory identifier type value being passed in physical stock count upload file.
	Inventory Id	Char(120)		This field contains the inventory ID value being passed in physical stock count upload file.
FTAIL	File record descriptor	Char(5)	FTAIL	Marks end of file
	File line	Number(10)	N/A	ID of current line
	identifier			being processed, internally incremented
	File record count	Number(10)	N/A	Number of detail records

Design Assumptions

This program uses grep to search log files for errors. The GREP function should point to the /usr/xpg4/bin/ directory instead of /usr/bin directory to utilize the “-E” option. Otherwise, it will fail with an “illegal option” error message.

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:

Franchise Customer Upload (fcustomerupload)
Franchise Order Upload (wfordupld.ksh)
Franchise Return Upload (wfretupld.ksh)
Upload Cost Buildup Template (fcosttmplupld)
Upload of Franchise Sales (wfslsupld.ksh)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-51 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

Table 6-51 (Cont.) File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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	Number(10)	N/A	Customer group
	Customer			ID
	group ID
	Franchise Customer	Char(120)	N/A	Customer group name. This field
	group Name			is optional for delete
Transaction Detail	File Record	Char(5)	N/A	Identifies
	Descriptor			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	Char(120)	N/A	Customer Name
	Customer Name

Table 6-51 (Cont.) File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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)

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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. The check for inventory availability is subject to the setting of the “Validate Availability for External Franchise Orders” system option. If the option is set to Yes, then Franchise Order creation will be subject to checks for inventory availability. If set to No, Franchise Order creation would be carried out without checking for inventory availability.

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-52 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.

Table 6-52 (Cont.) SQL Loder Input File Layout

Field Name	Field Type	Null allowed?	Default Value	Description
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.
				If the source location is warehouse then both physical and virtual warehouses are allowed.
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’ .

Table 6-52 (Cont.) SQL Loder Input File Layout

Record Name	Field Name	Field Type	Null allowed?	Default Value	Description
	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.

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-53 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.

Table 6-53 (Cont.) SQL Loader Input File Layout

Record Name	Field Name	Field Type	Null Allowed?	Default Value	Description
	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

Table 6-53 (Cont.) SQL Loader Input File Layout

Record Name	Field Name	Field Type	Null Allowed?	Default Value	Description
	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.

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

1. 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.

2. 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-54 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

Table 6-54 (Cont.) SQUL Loader Input File Layout

Record Name	Field Name	Field Type	Default Value	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

Table 6-54 (Cont.) SQUL Loader Input File Layout

Field Name	Field Type	Description
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)

Table 6-54 (Cont.) SQUL Loader Input File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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)

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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 File Name Integration Contract

Upload to Merchandising Input file name is a parameter during runtime IntCon000111

Input File Layout

Table 6-55 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 YYYYMMDDHH MMSS format
	File Create Date	Char(14)	N/A	File Create Date in YYYYMMDDHH MMSS 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	Char(4)	N/A	Unit of Measure
	Quantity UOM			for the Net Sales Quantity
	Total Retail Amount	Number(20)	N/A	Total Retail Amount with 4 implied decimal places
	Total Retail Amount	Char(3)	N/A	Currency code for the Total
	Currency			Retail Amount
FTAIL	Record descriptor	Char(5)	FTAIL	Identifies the file record type

Table 6-55 (Cont.) Input File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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)

Design Assumptions

N/A

Other Inventory

Other inventory related, scheduled inbound integrations include:

External Transaction Data Upload (trandataload.ksh)
Upload and Process Inventory Reservations from Sales Audit (ordinvupld)
Upload Item Availability for Type A & D Contracts from Suppliers (ediupavl)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

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-56 File Layout

Field Name	Field Type	Default Value	Description / Constraints
Tran_id	NUMBER(10,0)	EXT_TRAN_DA TA_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)

Table 6-56 (Cont.) File Layout

Field Name	Field Type	Default Value	Description / Constraints
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

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-57 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 YYYYMMDDHH MMSS 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

Table 6-57 (Cont.) ordinvupld.pc - Input File

Field Name	Field Type	Default Value	Description
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	Type of transaction
		ORD - Pickup/ delivery Complete
		PVORD - Post void of Pick-up/ delivery complete
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

Table 6-57 (Cont.) ordinvupld.pc - Input File

Record Name	Field Name	Field Type	Default Value	Description
	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	ID of current line being
			system	processed by input file

Table 6-57 (Cont.) ordinvupld.pc - Input File

Record Name	Field Name	Field Type	Default Value	Description
	File Record Counter	Number(10)	N/A	Number of records/ transactions processed in current file (only records between FHEAD & FTAIL)

Design Assumptions

N/A

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

Schedule

See Oracle Merchandising Batch Schedule.

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.

Restart/Recovery

N/A

I/O Specification

Integration Type	Upload to Merchandising
File Name	Determined by runtime parameter
Integration Contract	IntCon000016

Input File Layout

Table 6-58 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
				YYYYMMDDHH 24
				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)

Table 6-58 (Cont.) ediupavl.pc - File Layout

Field Name	Field Type	Default Value	Description
Number of	Number(10)	N/A	Number of
detail records			FDETL
			lines in file

Design Assumptions

This module will only be run if contracting is turned on in the system.

Fiscal Document Generation (FDG)

The Merchandising solution supports Fiscal Document Generation functionality. Fiscal document related data can be uploaded into FDG through scheduled inbound integration.

The following scheduled inbound integration is included in this section:

Fiscal Document Upload into FDG (fdg_reim_job)

Fiscal Document Upload into FDG (fdg_reim_job)

Module Name fdg_reim_job Description The script calls the FDG in order to migrate data between ReIM and FDG. Functional Area Rfm Module Type Admin – Ad hoc Module Technology Background Processing Catalog ID Wrapper Script fdg_reim_batch_sql.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

The purpose of this process is to migrate data from ReIM tables to FDG tables and then follow the existing process in the FDG module to finish the migration. ReIM will be the owner of the data to be stored in their staging tables, which will be consumed by batch, and will begin the migration process to FDG.

Restart/Recovery

N/A

Key Tables Affected

TABLE IM_FDG_DOC_HEAD	SELECT Yes	INSERT No	UPDATE Yes	DELETE Yes
IM_FDG_DOC_ETT	Yes	No	No	Yes
IM_FDG_DOC_DTL	Yes	No	No	Yes
IM_FDG_DOC_DTL_PACK_COMP	Yes	No	No	Yes
IM_FDG_DOC_REF	Yes	No	No	Yes
IM_FDG_DOC_NON_MERCH	Yes	No	No	Yes
IM_FDG_DOC_TAX	Yes	No	No	Yes
IM_FDG_DOC_TEXT	Yes	No	No	Yes
IM_FDG_DOC_EXT	Yes	No	No	Yes
SVC_FDG_HDR	Yes	Yes	Yes	Yes
SVC_FDG_ETT	Yes	Yes	No	Yes
SVC_FDG_DTL	Yes	Yes	No	Yes
SVC_FDG_DTL_PACK	Yes	Yes	No	Yes
SVC_FDG_REF	Yes	Yes	No	Yes
SVC_FDG_NON_MERCH	Yes	Yes	No	Yes
SVC_FDG_TAX	Yes	Yes	No	Yes
SVC_FDG_TEXT	Yes	Yes	No	Yes
SVC_FDG_EXT	Yes	Yes	No	Yes
FDG_HDR	No	Yes	No	No
FDG_ETT	No	Yes	No	No
FDG_DTL	No	Yes	No	No
FDG_REF	No	Yes	No	No
FDG_NON_MERCH	No	Yes	No	No
FDG_TAX	No	Yes	No	No
FDG_DTL_PACK	No	Yes	No	No
FDG_TEXT	No	Yes	No	No
FDG_EXT	No	Yes	No	No
FDG_ERROR	No	Yes	No	No

Design Assumptions

N/A

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
Sales Posting

Sales Audit

For more information on Sales Audit processing see the Merchandising Batch Operations Guide .

This chapter contains details about the following integration processes used to import data to Sales Audit:

Customer Engagement Promotion Import (CePromoBatch.ksh)
Import of Unaudited Transaction Data from POS to Sales Audit (saimptlog/saimptlogi)
Import Total Value Adjustments From External Systems (saimpadj)
Sales Audit Voucher Upload (savouch)

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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:

1. 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.

2. 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.

3. SQLLoader is executed to load the transaction tables from the files created by SAIMPTLOG. The store/day SQLLoader files can be concatenated into a single file per table to optimize load times. Alternatively, multiple SQLLoader files can be used as input to SQLLoader. 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.

4. SAVOUCH is executed to load each of the voucher files in Oracle Retail standard formatted. SAVOUCH may not be multi-threaded.

5. 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.

Restart and Recovery

N/A

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-59 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	Char(8)	N/A	Business date in YYYYMMDD
	Business Date			format

Table 6-59 (Cont.) File Name: SAVO (Sales Audit Voucher File)

Field Name	Field Type	Default Value	Description
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

Table 6-59 (Cont.) File Name: SAVO (Sales Audit Voucher File)

Record Name	Field Name	Field Type	Default Value	Description
	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-60 File Name: Satdisc.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
SA_TRAN_DIS C	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_TYP E	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

Table 6-60 (Cont.) File Name: Satdisc.ctl

Column Name	Field Type	Field Width	Position	Description
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_IN D	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-61 File Name: Saigtax.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
SA_TRAN_IGT AX	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_AM T	Decimal external	22	66:87	N/A
	STANDARD_QTY	Decimal external	14	88:101	N/A
	STANDARD_UNIT_I GTAX_AMT	Decimal external	21	102:122	N/A
	ERROR_IND	Char	1	123:123	N/A

Table 6-61 (Cont.) File Name: Saigtax.ctl

Column Name	Field Type	Field Width	Position	Description
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-62 File Name: Sacust.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
SA_CUSTOME R	TRAN_SEQ_NO	Integer external	20	1 :20	N/A
		Date
	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-63 File Name: Sathead.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
SA_TRAN_HE AD	TRAN_SEQ_NO	Integer external	20	1:20	N/A
	REV_NO	Integer external	3	21:23	N/A

Table 6-63 (Cont.) File Name: Sathead.ctl

Column Name	Field Type	Field Width	Position	Description
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_N O	Char	30	256:285	N/A
PAYMENT_REF_N O	Char	16	286:301	N/A
PROOF_OF_DELIV ERY_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_DATETIM E	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

Table 6-63 (Cont.) File Name: Sathead.ctl

Column Name	Field Type	Field Width	Position	Description
ROUND_AMT	Integer external	22	410:431	N/A
ROUNDED_OFF_A MT	Integer external	22	432:453	N/A
CREDIT_PROMOTI ON_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-64 File Name: Satitem.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
SA_TRAN_ITE M	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_ITE M	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

Table 6-64 (Cont.) File Name: Satitem.ctl

Column Name	Field Type	Field Width	Position	Description
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_REAS ON	Char	6	189:194	N/A
ORIG_UNIT_RETAI	Decimal	21	195:215	Includes a
L	external			decimal point
STANDARD_ORIG_ UNIT_RETAIL	Decimal external	21	216:236	N/A
TAX_IND	Char	1	237:237	N/A
ITEM_SWIPED_IN D	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

Table 6-64 (Cont.) File Name: Satitem.ctl

Column Name	Field Type	Field Width	Position	Description
CATCHWEIGHT_IN D	Char	1	450:450	N/A
SELLING_ITEM	Char	25	451:475	N/A
CUSTOMER_ORD ER_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_AM T	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_DA TE	Date	14	714:727	Format is YYYYMMDDH H24MISS
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_DISPOSI TION	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_LO C_TYPE	Char	2	818:820	N/A
FULFILLMENT_LO C	Integer external	10	821:830	N/A
POSTING_STORE	Integer external	10	830:839	N/A
CONSIGNMENT_R ATE	DECIMAL EXTERNAL	14	840:853	INCLUDES A DECIMAL POINT.
CONSIGNMENT_U NIT_COST	DECIMAL EXTERNAL	21	854:874	INCLUDES A DECIMAL POINT.

Table 6-64 (Cont.) File Name: Satitem.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
	INVENTORY_IDEN TIFIER_TYPE	CHAR	6	875:880	This field contains the inventory identifier type passed in Sales/Return transactions. Valid values are found under the Inventory Identifier Types (IIDT) code type; for example, Lot (L), Expiry Date (E), Serial Number (S), Import Document (D).
Table 6-65	INVENTORY_ID File Name: Sattend.	CHAR ctl	120	881:1000	This field contains the inventory ID value being passed in sales/return transactions.
Table Name	Column Name	Field Type	Field Width	Position	Description
SA_TRAN_TE NDER	TRAN_SEQ_NO	Integer external	20	1:20	N/A
	TENDER_SEQ_NO	Integer external	4	21:24	N/A
	TENDER_TYPE_G ROUP	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

Table 6-65 File Name: Sattend.ctl

Table 6-65 (Cont.) File Name: Sattend.ctl

Column Name	Field Type	Field Width	Position	Description
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-66 File Name: Satpymt.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
SA_TRAN_PA YMENT	TRAN_SEQ_NO	Integer external	20	1:20	N/A
	PAYMENT_SEQ_N O	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-67 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-68 F Table Name	ile Name: Sattax.ct Column Name	l Field Type	Field Width	Position	Description
SA_TRAN_TA X	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-68 File Name: Sattax.ctl

Table 6-69 File Name: Sacustatt.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
SA_CUST_AT TRIB	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

Table 6-69 (Cont.) File Name: Sacustatt.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
	DAY	Integer external	3	47:49	N/A

Table 6-70 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_OVERRID E_IND	Char	1	140:140	N/A
	HQ_OVERRIDE_IN D	Char	1	141:141	N/A
	UPDATE_ID	Char	30	142:171	N/A
	UPDATE_DATE TIME	Date	14	172:185	Format is YYYYMMDDH H24MISS
	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-71 File Name: Sathatt.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
SA_TRAN_HE	TRAN_SEQ_NO	Integer	20	1:20
AD_ATTRIB		external

Table 6-71 (Cont.) File Name: Sathatt.ctl

Column Name	Field Type	Field Width	Position
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-72 File Name: Saitatt.ctl

Table Name	Column Name	Field Type	Field Width	Position
SA_TRAN_ITE M_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-73 File Name: Saidatt.ctl

Table Name	Column Name	Field Type	Field Width	Position
SA_TRAN_DIS C_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

Table 6-73 (Cont.) File Name: Saidatt.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
Table 6-74	ERROR_IND File Name: Saixatt.c	Char tl	1	172:172
Table Name	Column Name	Field Type	Field Width	Position	Description
SA_TRAN_IG AX_ATTRIB	T 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-74 File Name: Saixatt.ctl

Table 6-75 File Name: Satxatt.ctl

Table Name	Column Name	Field Type	Field Width	Position
SA_TRAN_TA X_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-76 File Name: Sattatt.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
SA_TRAN_TE	TRAN_SEQ_NO	Integer	20	1:20
NDER_ATTRIB		external

Table 6-76 (Cont.) File Name: Sattatt.ctl

Column Name	Field Type	Field Width	Position
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-77 File Name: Satwritelock.ctl

Table Name	Column Name	Field Type	Field Width	Position	Description
SA_TRAN_WR ITE_LOCK	STORE_DAY_SEQ _NO	Integer external	20	1:20	N/A
		Date
	TRAN_SEQ_NO	Integer external	20	21:40	N/A
		Date

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	5	6
Version Description	Initial Version (V16.0.x SaaS)	Initial Version Plus Fulfilmen t Type and Location	Initial Version Plus Referen ce Number s 28-31	Initial Version Plus Fulfilment Type and Location and Reference Numbers 28-31	Version 3 Plus Posting Store	Version 4 Plus Consignm ent Rate/ Cost	Version 5 Plus Inventory Identifier Type/ Inventory Id
Reference No. 28	N	N	Y	Y	Y	Y	Y
Reference No. 29	N	N	Y	Y	Y	Y	Y
Reference No. 30	N	N	Y	Y	Y	Y	Y
Reference No. 31	N	N	Y	Y	Y	Y	Y
Fulfillment Location type	N	Y	N	Y	Y	Y	Y
Fulfillment Location	N	Y	N	Y	Y	Y	Y
Posting Store	N	N	N	N	Y	Y	Y

Version Number	1	2a	2b	3	4	5	6
Version Description	Initial Version (V16.0.x SaaS)	Initial Version Plus Fulfilmen t Type and Location	Initial Version Plus Referen ce Number s 28-31	Initial Version Plus Fulfilment Type and Location and Reference Numbers 28-31	Version 3 Plus Posting Store	Version 4 Plus Consignm ent Rate/ Cost	Version 5 Plus Inventory Identifier Type/ Inventory Id
Consignmen t Rate/Cost	N	N	N	N	N	Y	Y
Inventory Identifier Type	N	N	N	N	N	N	Y
Inventory Id	N	N	N	N	N	N	Y

Table 6-78 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 (YYYYMMDD HHMMSS).	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

Table 6-78 (Cont.) File Name: rtlog

Record Name	Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
	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 (YYYYMMDD HHMMSS).	Y	Left/None
	Transaction Number	Number(10)	N/A	Transaction identifier. If sa_system_op tions, 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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
Reference Number 1	Char(30)	Na	Number associated with a particular transaction, for example, whether for a Store Conditions transaction. The SA_REFERE NCE 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	Y if tran is a TOTAL	Right/0 when value is present.
			places. Populated by the retailer for TOTAL transaction, populated by Sales Audit for SALE and RETURN transactions.		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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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 RoundedAmo unt 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 RoundedAmo unt 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

Table 6-78 (Cont.) File Name: rtlog

Record Name	Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
	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

Table 6-78 (Cont.) File Name: rtlog

Record Name	Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
	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
	E-mail	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

Table 6-78 (Cont.) File Name: rtlog

Record Name	Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
	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	Y	Left/Blank
				ORI - Order Initiate
				ORC - Order Cancel
				ORD - Order Complete LIN - Layaway Initiate LCA - Layaway Cancel LCO - Layaway Complete ADJ - Appeasement/ Adjustment
	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	Identifies the type of item number if the	N	Left/Blank
			for a list of valid codes.	item type is ITEM or REF

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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_d ate	Char(8)	N/A	Gift certificate expiration date (YYYYMMDD) .	N

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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: YYYYMMDDH HMMSS 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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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

Table 6-78 (Cont.) File Name: rtlog

Record Name	Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
	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
	Consignment Rate	Number(12)		Consignment Rate with 4 implied decimal places.	N	Right/0
	Consignment Unit Cost	Number(20)		Consignment Unit Cost with 4 implied decimal places.	N	Right/0
	Inventory Identifier Type	Char(6)		Contains the inventory identifier type passed in Sales/Return transactions.	N	Left/Blank
	Inventory Id	Char(120)		Contains the inventory id passed in Sales/Return transactions.	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

Table 6-78 (Cont.) File Name: rtlog

Record Name	Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
	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
	Merchandisin g Promotion Type	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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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

Table 6-78 (Cont.) File Name: rtlog

Record Name	Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
	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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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

Table 6-78 (Cont.) File Name: rtlog

Record Name	Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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

Table 6-78 (Cont.) File Name: rtlog

Record Name	Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
	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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
Tender Type ID	Number(6)	Refer to the pos_tender_t ype_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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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_op tions.cc_no_m ask_char. If	N	Left/Blank
			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.
Cc_auth_no	Char(16)	N/A	Authorization number for a credit card.	N	Left/Blank
cc authorization	Char(6)	Refer to CCAS	N/A	N	Left/Blank
source		code_type for as list of
		valid types.

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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

Table 6-78 (Cont.) File Name: rtlog

Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
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.	N	Left/Blank
			The value sent in the RTLOG is masked.
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 CURRENCIE S 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

Table 6-78 (Cont.) File Name: rtlog

Record Name	Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
	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

Table 6-78 (Cont.) File Name: rtlog

Record Name	Field Name	Field Type	Default Value	Description	Required?	Justification/ Padding
	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-79 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

Table 6-79 (Cont.) Record Type Requirements

Transaction Type	Includes item records?	Includes tender records?	Includes tax records? IG TAX?	Includes customer records?
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 TITEM and TCUST record should not b system is POS. IG Either IGTAX or TT originating system matching the store’	not sent through the records are optional e included if IGTAX a TAX is an item-level t AX can be used if ori is OMS, both IGTAX s tax type will be pro	RTLOG. It is entered a . The TTEND record is ppears in a transactio ax and TTAX is a trans ginating system is POS and TTAX can appear cessed, the other recor	t the HQ level. The required. A TTAX n if originating action-level tax. , but not both. If but only the one d will be ignored.
METER	Yes	No	No	No
PUMPT	Yes	No	No	No
TANKDP	Yes	No	No	No
TERM	TERM records are do not come from t TTAX, one TCUST newly coming up.	created by saimptlog he RTLOG file. They record, and one CAT	and then loaded into t require one TITEM, on T record, IGTAX, and	he database. They e TTEND, one one TPYMT which is
DCLOSE	No	No	No	No
SPLORD	Optional	Yes	Optional	Optional
REOPEN	No	No	No	No
PREPAY	No	Yes	No	Optional

Requirements per Record Type

Table 6-80 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.

Table 6-80 (Cont.) Requirements per Record Type

Record Type	Requirements
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-81 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

Table 6-81 (Cont.) Code Type Validations

Record Name	Field Name	Code Type
	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 nonnumeric 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, subtransaction 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-82 Requirements per Record Type

Record Type	Requirements
THEAD	N/A

Table 6-82 (Cont.) Requirements per Record Type

Record Type

Requirements

TITEM

•
Item Status is a required field; it determines whether the item is Sold
(S), Returned (R), or Voided (V). If the item status is S, the quantity sign
is expected to be P. If the item status is R, the quantity sign is expected
to be N. Also, if the item status is ORI, LIN, ORD, or LCO, the quantity
sign should be P. In the case of ORC or LCA, it should be N.
Item status ADJ is to support appeasement transactions from OMS,
where a customer is partially refunded for their original purchase based
on an agreed-to price adjustment, or other reasons.
•
If the item status is V, the quantity sign is the reverse of the quantity sign
of the voided item. That is, if an item with status S is voided, the quantity
sign would be N. Furthermore, the sum of the quantities being voided
cannot exceed the sum of the quantities that are Sold or Returned.
Note: Neither of the two validations are performed by saimptlog, but an
audit rule could be created to check this.
•
The following item statuses are used for handling items on customer
order layaway:
ORI - Order Initiate
ORD - Order Complete
ORC - Order Cancel
LIN - Layaway Initiate
LCA - Layaway Cancel
LCO - Layaway Complete
•
In a typical sale, the items all have a status of S. In the case of an odd
exchange, some items will have a status of R.
•
In a typical return, the items all have a status of R. In the case of an odd
exchange, some items will have a status of S.
•
If an item has status R, then the Return Reason Code field may be
populated. If it is, it will be validated against code type SARR. Also, it is
better to capture the Return Reason Code in the case of items on ORC
or LCA, but it is not mandatory. No validation is kept for these new item
statuses for checking of SARR.
•
If the price of an item is overridden, the Override Reason and Original
Unit Retail fields must be populated.

IDISC

•
The Merchandising Promotion Type field must always be populated with
values of code type PRMT.
•
The Promotion field is validated, when a value is passed, against the
promhead table.
•
If the promotion is In Store (code 1004), the Discount Type field must be
populated with values of code type SADT.
•
The Discount Reference Number is a promotion number which is of
status A, E, or M.
•
If the Discount Type is SCOUP for Store Coupon, the Coupon Number
field must be populated. The Coupon Reference Number field is
optional.

Table 6-82 (Cont.) Requirements per Record Type

Record Type	Requirements
IGTAX	• The IGTAX_CODE field must always be populated depending on the system’s default tax type. For a default tax type of SALES, this field will be populated with values of code_type TAXC. For a default tax type of SVAT, GTAX, or GTS, this field will be populated with VATC (vat_code from vat_codes table). IGTAX is an Item-level tax. • The TAX_AUTHORITY field must always be populated. This is a free form text and any value can be used as a default string describing the authority levying the tax. • If Item Status is ADJ (appeasement transaction), the IGTAX Tax Code from OMS is TOTAX.
TTAX	• The TAX_CODE field must always be populated depending on the system’s default tax type. For a default tax type of SALES, this field will be populated with values of code_type TAXC. For a default tax type of GTAX, SVAT, or GTS, this field will be populated with VATC (vat_code from vat_codes table). TTAX is a Transaction-level tax.
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-83 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

Table 6-83 (Cont.) 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	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-84 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	P	P	P if item is on
	ORI, LIN, ORD, or LCO; N if item is on ORC or LCA.			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.

Table 6-85 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-86 Expe TRANSACTION TYPE	cted Values for Sign TITEM.Quantity Sign TE	Fields ND.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

Table 6-86 Expected Values for Sign Fields

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-87 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:

The meaning of these reference number fields may be changed through the sa_reference table.

Table 6-88 Meaning of Reference Number Fields

Reason Code	Reference Number Column	Meaning	Req?
NSF	1	NFS Check Credit	N
		Number
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 subtransaction 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-89 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-90 Expected Values for Sign Fields

TRANSACTION	TITEM.Quantity	TEND.Tender Sign	TTAX.Tax	IDISC.Quantity Sign
TYPE	Sign		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-91 Expected Values for Sign Fields

TRANSACTION	TITEM.Quantity	TEND.Tender Sign	TTAX.Tax	IDISC.Quantity Sign
TYPE	Sign		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

The meaning of these reference number fields may be changed through the sa_reference table.

Table 6-92 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-93 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

Table 6-93 (Cont.) Meaning of Reference Number Fields

Reference Number Column	Meaning	Req?
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-94 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.

Transaction of Type REOPEN

This transaction is generated when a store day which was closed needs to be reopened to process additional transactions. Transaction number for this type of transaction has to be blank.

Transaction of Type OTHER

This transaction is a generic transaction type to support Micros Xstore integration. This will identify all the other transaction types that are not currently supported. This type of transaction has only THEAD and TTAIL records.

Note

Sales Audit typically doesn’t allow transactions to exist outside of a store day or to be uploaded against a closed store day. To allow for exception cases where the store might perform internal processing related checks ( such as clock in, training, and so on) outside the purview of a store day, flexibility has been provided to allow for only transactions with TRAN_TYPE and SUB_TRAN_TYPE of TYPE=’OTHER’ to be uploaded against closed store days. Upload of such transactions does not impact the store days accounting transactions and will automatically update the count of the files/ transactions uploaded.

Transaction of Type PREPAY

This type of transaction is generated when a liability advance is accepted by the business without the requirement to capture item details. It carries THEAD, TTEND and an optional TCUST record. Optional Custom Attributes associated with these records lines (that is, THATT, TTATT, CATT) are also supported.

Meaning of reference number fields (When integrated from OMS):

Note

The meaning of these reference number fields may be changed through the sa_reference table.

Reference Number Column	Meaning	Req?
1	Customer Order Number	N

Design Assumptions

Table 6-95 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
PREPAY	Prepayment

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-96 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).

Design Assumptions

N/A

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

Schedule

Oracle Retail Merchandising Batch Schedule

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-97 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	Char(240)	N/A	The address of the customer who
	Customer Addr1			was issued the voucher.

Table 6-97 (Cont.) Input File Layout

Record Name	Field Name	Field Type	Default Value	Description
	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.

Table 6-97 (Cont.) Input File Layout

Record Name	Field Name	Field Type	Default Value	Description
	`#lines`	Number(10)	N/A	Total number of transaction lines in file (not including FHEAD and FTAIL).

Design Assumptions

N/A

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:

Process Multiple POSU Files (uploadsales_all.ksh)
Upload POSU File for Processing (uploadsales.ksh)

For more on sales processing, see the Merchandising Batch Operations Guide .

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

Locking Strategy

N/A

Security Considerations

N/A

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.

Security Considerations

N/A

I/O Specification

Integration Type Upload to Merchandising File Name POSU_<tran_date>.<thread_val> Integration Contract IntCon000044

Input File Layout

Refer to the Input File Layout section in uploadsales.doc.

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

Schedule

Oracle Retail Merchandising Batch Schedule

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.

Restart/Recovery

N/A

Locking Strategy

N/A

Security Considerations

N/A

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.

Security Considerations

N/A

I/O Specification

Integration Type Upload to Merchandising File Name POSU_<tran_date>.<thread_val> Integration Contract IntCon000044

Input File Layout

Table 6-98 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

Table 6-98 (Cont.) Input File

Record Name	Field Name	Field Type	Default Value	Description
	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

Table 6-98 (Cont.) Input File

Field Name	Field Type	Default Value	Description
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’

Table 6-98 (Cont.) Input File

Field Name	Field Type	Default Value	Description
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 anOptionalfield.
			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.

Table 6-98 (Cont.) Input File

Record Name	Field Name	Field Type	Default Value	Description
	Consignment Rate	Number(12)		This column contains the consignment rate that should be applied while posting the sales/returns to Merchandising. (4 implied decimal places)
	Consignment Unit Cost	Number(20)		This column contains the consignment unit cost that should be applied while posting the sales/returns to Merchandising. (4 implied decimal places)
	Inventory Identifier Type	Char(6)		This column contains the inventory identifier type passed in Sales/Return transactions. Valid values are found under the Inventory Identifier Types (IIDT) code type; for example, Lot (L), Expiry Date (E),Import Document (D).
	Inventory Id	Char(120)		This column contains the inventory ID value being passed in sales/return transactions.
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

Table 6-98 (Cont.) Input File

Record Name	Field Name	Field Type	Default Value	Description
	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	V19.3	V24	V25
Fulfillment Order No	No	Yes	Yes	Yes	Yes	Yes
Fulfillment Loc Type	No	Yes	Yes	Yes	Yes	Yes
Fulfillment Loc	No	Yes	Yes	Yes	Yes	Yes
Orig Store	No	Yes	Yes	Yes	Yes	Yes
POS Tran Id	No	No	Yes	Yes	Yes	Yes
Posting Store	No	No	No	Yes	Yes	Yes
Consignment Rate/Unit Cost	No	No	No	No	Yes	Yes
Inventory Identifier Type	No	No	No	No	No	Yes
Inventory Id	No	No	No	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-99 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-100 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.

Reject File

The module produces a reject file similar to the input file if it is found to have missing or duplicate FHEAD or FTAIL records. Records in these types of files are loaded to the svc_posupld_load table, but not in the svc_posupld_staging table.

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
Weekly Demand Item Forecast Subscription API
Weekly/Daily Item Forecast Upload (load_item_forecast)

Daily Demand Item Forecast Subscription API

This section describes the Daily Demand Item Forecast Subscription API.

Functional Area

Foundation

Design Overview

This API is used to import daily forecast data from Oracle Retail Inventory Planning Optimization - Demand Forecasting 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 Inventory Planning Optimization - Demand Forecasting 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 Inventory Planning Optimization - Demand Forecasting, rather than as part of the Merchandising batch schedule.

Data Definition XML

The BDI interface staging tables are generated based on the XML schema definition.

Data Flow	Description	XML Schema Definition (XSD)
Daily Demand Item	Import daily demand item	DlyDmdFst_Tx_BdiInterfaceModule.xml
Forecast	forecast from BDI

Tables

TABLE	SELECT	INSERT	UPDATE	DELETE
DLY_DMND_FRCST_IN	Yes	No	No	No
DAILY_ITEM_FORECAST	No	Yes	Yes	Yes

Weekly Demand Item Forecast Subscription API

This section describes the Weekly Demand Item Forecast Subscription BDI.

Functional Area

Foundation

Design Overview

This API is used to import weekly forecast data from Oracle Retail Inventory Planning Optimization - Demand Forecasting 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 Inventory Planning Optimization - Demand Forecasting 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 Inventory Planning Optimization - Demand Forecasting, rather than as part of the Merchandising batch schedule.

Data Definition XML

The BDI interface staging tables are generated based on the XML schema definition.

Data Flow	Description	XML Schema Definition (XSD)
Weekly Demand	Import weekly demand item	WklyDmdFst_Tx_BdiInterfaceModule.xml
Item Forecast	forecast from BDI

Tables

TABLE	SELECT	INSERT	UPDATE	DELETE
WKLY_DMND_FRCST_IN	Yes	No	No	No
ITEM_FORECAST	No	Yes	Yes	Yes
ITEM_FORECAST_HIST	No	Yes	No	Yes

Weekly/Daily Item Forecast Upload (load_item_forecast)

load_item_forecast.ksh

Module Name load_item_forecast.ksh Description Load daily/weekly item forecast from Oracle Retail Inventory Planning Optimization Cloud Service - Demand Forecasting Functional Area Integration - Forecast Module Type Integration

Module Technology Ksh Catalog ID N/A Wrapper Script rmswrap_shell_in.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This script loads item forecast data into the Merchandising forecast tables.

The forecast data comes from Inventory Planning Optimization - 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 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)

Field Name	Field Type	Required	Description
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_sale s
			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.

I/O Specification

N/A

Design Assumption

Domain is not a relevant concept any more. Domain_id on ITEM_FORECAST and DAILY_ITEM_FORECAST will always be 1.

In this guide

Guide: Inbound and Outbound Integration Guide
Previous: 5 ReSTful Web Services

19 Sales Audit — Batch Operations Guide · shares ES_ERROR, RESTART_CONTROL, RMS_PLSQL_BATCH_CONFIG, SA_BALANCE_GROUP
10 Invoice Matching — Batch Operations Guide · shares CODE_DETAIL, FDG_DTL, FDG_DTL_PACK, FDG_ERROR
5 ReSTful Web Services — Inbound and Outbound Integration Guide · shares ADD_TYPE_MODULE, CODE_DETAIL, CODE_HEAD, CODE_TYPE
2 Custom Flex Attributes — Merchandising Cloud Services Customization and Extension Guide · shares DEAL_HEAD, ITEM_SUPPLIER, ITEM_SUPP_COUNTRY, ITEM_SUPP_COUNTRY_LOC
17 Stock Ledger — Batch Operations Guide · shares DAILY_DATA, FLASHBACK_SNAPSHOT_INFO, IF_TRAN_DATA, MONTH_DATA
F Appendix: Publication Tables and Triggers — Merchandising Cloud Services Data Conversion Implementation Guide · shares CODE_DETAIL, CODE_HEAD, COMPANY_CLOSED, DELIVERY_SLOT

Oracle Retail Knowledge Base

Explorer

6 Scheduled Integration

File-based Integration Overview

Standard File Layouts

Detail-Only Files

Example 6-1 Detail-Only Files

Master and Detail Files

Example 6-2 Master and Detail Files

Integration Batch Wrapper FAQ

For input files, are there any specific file format names?

dealupld #SysOpt.dbwallet dealupld

How and where will files be moved?

When will files be unzipped?

What will happen to the files once they are processed?

Will processed file be archived?

What will happen if the file is rejected?

How will rejected files be reprocessed?

Input/Output File Naming Convention

Bulk Data Integration Overview

Outbound Scheduled Integration

Foundation Data

Brand Publication API (BDI_Brand_Fnd_PF_From_RMS_EOW_JOB)

Functional Area

Business Overview

New Brand

Updated Brand

Deleted Brand

Error Handling

Message XSD

Calendar Publication API (BDI_Calendar_Fnd_PF_From_RMS_EOW_JOB)

Functional Area

Foundation

Business Overview

Package Impact

Filename: bdifoundationb.pls.pls

Data Definition XML

Table Impact

Code Detail Publication API (BDI_CodeDetail_Fnd_PF_From_RMS_JOB)

Functional Area

Business Overview

Package Impact

Filename: bdicrosspillarb.pls

Data Definition XML

Table Impact

Code Head Publication API (BDI_CodeHead_Fnd_PF_From_RMS_JOB)

Functional Area

Business Overview

Package Impact

Filename: bdicrosspillarb.pls

Data Definition XML

Table Impact

Company-wide Closings and Company Closed Exceptions (BDI_CompanyClosed_Fnd_PF_From_RMS_JOB)

Functional Area

Foundation

Design Overview

Package Impact

Filename: bdifoundations.pls

Filename: bdifoundationb.pls

Data Definition XML

Tables

Currency Conversion Rates Publication API

(BDI_CurrConvRates_Fnd_PF_From_RMS_EOW_JOB)

Functional Area

Business Overview

Package Impact

Filename: bdifoundationb.pls.pls

Data Definition XML

Table Impact

Delivery Slot Publication API (BDI_DeliverySlot_Fnd_PF_From_RMS_JOB)

Functional Area

Business Overview

Package Impact

Filename: bdicrosspillarb.pls

Data Definition XML

Table Impact

Diff Group Export (export_diffgrp.ksh)

Schedule

Design Overview

Restart/Recovery

`dealupld #SysOpt.dbwallet dealupld`