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.

13 Transfers, Allocation, and RTV

Transfers, Allocations and Return to Vendor (RTV) transactions move inventory among locations. The majority of processing associated with these transactions occurs through the user interface and near real-time RIB integration with store systems, such as Oracle Retail Store Inventory and Operations Cloud Service (SIOCS), and warehouse systems, such as Oracle WMS Cloud. However, Merchandising uses a variety of batch programs to maintain the data related to these transactions.

Program Summary

The following batch designs are included in this chapter:

• Close Mass Return Transfers (mrtupd)

• Close Overdue Transfers (transfer_close_job) - background process

• Close Overdue Transfers (tsfclose)

• Close Transactions with no Expected Appointments, Shipments or Receipts (doc_queue_close_job) - background process

• Close Transactions with no Expected Appointments, Shipments or Receipts (docclose)

• Create Book Transfers for Allocations Between Warehouses in the Same Physical Warehouse (allocbt)

• Create Return to Vendor for Mass Return Transfer (mrtrtv)

• Create Transfers for Mass Return Transfer (mrt)

• Detail Receive Damaged or Tampered with Cartons (tamperctn)

• Purge Aged Mass Return Transfers and RTV (mrt_purge_job) - background process

• Purge Aged Mass Return Transfers and RTV (mrtprg)

• Purge Aged Returns to Vendors (rtv_purge_job) - background process

• Purge Aged Returns to Vendors (rtvprg)

• Purge Aged Transfers (transfer_purge_job) - background process

• Purge Aged Transfers (tsfprg)

• Reconcile Received Dummy Carton IDs with Expected Cartons (dummyctn)

• Stage Regular Price Changes on Open Allocations/Transfers so Publishing Sends New Retail to Subscribing Applications (distropcpub)

• Aggregation of RTV Records to Invoice (aggregrate_rtv_to_invoice.ksh)

Aggregation of RTV Records to Invoice (aggregrate_rtv_to_invoice.ksh)

Schedule

Oracle Retail Merchandising Batch Schedule.

Design Overview

The AGGREGRATE_RTV_TO_INVOICE.KSH module aggregates eligible return-to-vendor records in RTV_AGGREGATE_TEMP and creates Invoice Matching staging records. It creates one aggregated invoice for each eligible supplier site and location grouping.

Records are staged when transaction code 24 is posted and the supplier-site aggregation frequency is Daily, Weekly, or Monthly. Consignment RTVs continue through the existing consignment flow.

Eligibility is based on VDATE , supplier setup, and the relevant SYSTEM_VARIABLES date. Virtualwarehouse records are aggregated at the supplier-site and physical-warehouse level. The generated reference is AGGR_<Supplier Site ID>_<Location ID>_<Frequency>_<Frequency End Date DDMONYYYY> and is retained on INVC_HEAD.EXT_REF_NO and RTV_HEAD.RTV_AGGREGATE_ID .

After rows are staged in the INVC_* tables, EDIDLINV generates the Invoice Matching output.

Restart/Recovery

The logical unit of work is the thread ID assigned to rows in RTV_AGGREGATE_TEMP . Eligible rows are assigned a thread ID and status I ; in-process rows are picked up on the next execution. Successfully processed rows are marked C and deleted after successful completion.

Security Considerations

N/A

Close Mass Return Transfers (mrtupd)

Module Name mrtupd.pc Description Close Mass Return Transfers Functional Area Transfers, Allocations and RTVs Module Type Admin Module Technology ProC Catalog ID RMS276 Wrapper Script rmswrap_multi.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This program updates the status of MRTs and their associated transfers to closed status, for MRTs or transfers associated with an MRT that remain open after the transfer and/or RTV not after dates have passed. MRTs that have transfers in progress (shipped but not received) will not be closed by this program.

Restart/Recovery

The logical unit of work for this program is warehouse. This program is multi-threaded using the restart all locations view.

Design Assumptions

N/A

Close Overdue Transfers (transfer_close_job)

Module Name transfer_close_job Description Close Overdue Transfers Functional Area Transfers, Allocations and RTVs Module Type Admin - Ad hoc Module Technology Background Processing Catalog ID N/A Wrapper Script b8dwrap.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This background job is composed of two steps processing. It will have a threading assignment and a business logic processing.

Thread assignment program will filter eligible records from transfer header table and other associated transfer-related tables. Based on its system parameter settings, it will process unshipped and partially shipped ‘overdue’ transfers. If this functionality is enabled (by setting the system parameter Transfer Close Overdue to Yes), then this program will evaluate transfers to determine if they are overdue. The way that a transfer is considered overdue depends on the source and destination locations. There are separate system parameters for each of store to store, store to warehouse, warehouse to store, and warehouse to warehouse types of transfers. . These records are chunked and Thread ID is assigned for each. They will be stored temporarily in a staging table.

The Business logic program will process all records from the staging table. Using bulk processing, this program will update the records from transfer header and other associated transfer tables. For unshipped transfers, the transfer status is updated to delete and transfer reserved and expected inventory is backed out on ITEM_LOC_SOH for the sending and receiving locations respectively. For transfers that are shipped but not fully received, an entry is

made into doc_close_queue table. These transfers are picked up by docclose batch and closed after reconciliation. It will free up and clean the staging table afterwards. There is a STOP ON NEXT feature in bulk processing (through a loop) where Administrators can stop this batch with a flip of this indicator.

Restart/Recovery

N/A

Key Tables Affected

Table 13-1 Key Tables Affected

Table	Select	Insert	Update	Delete
SYSTEM_OPTIONS	Yes	No	No	No
INV_MOVE_UNIT_OPTIONS	Yes	No	No	No
RMS_BATCH_STATUS	Yes	No	No	No
B8D_PROCESS_CONFIG	Yes	No	No	No
JOB_AUDIT_LOGS	No	Yes	No	No
B8D_TRANSFER_CLOSE_STG	YEs	Yes	No	Yes
TSFHEAD	Yes	No	Yes	No
ALLOC_HEADER	Yes	No	Yes	No
ITEM_MASTER	Yes	No	No	No
V_PACKSKU_QTY	Yes	No	No	No
ITEM_LOC_SOH	Yes	No	Yes	No
DOC_CLOSE_QUEUE	No	Yes	No	No

Design Assumptions

N/A

Close Overdue Transfers (tsfclose)

Module Name tsfclose.pc Description Close Overdue Transfers Functional Area Transfers, Allocations and RTVs Module Type Admin Module Technology ProC Catalog ID RMS379 Wrapper Script rmswrap_multi.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Close Transactions with no Expected Appointments, Shipments or Receipts (doc_queue_close_job)

Design Overview

This batch program processes unshipped and partially shipped transfers that are considered ‘overdue’, based on system parameter settings. If this functionality is enabled, then this program will evaluate transfers to determine if they are overdue. The way that a transfer is considered overdue depends on the source and destination locations. There are separate system parameters for each of store to store, store to warehouse, warehouse to store, and warehouse to warehouse types of transfers.

For unshipped transfers, the transfer status is updated to delete and transfer reserved and expected inventory is backed out from the table for the sending and receiving locations respectively. For transfers that are shipped but not fully received, an entry is made into the document close queue table. These transfers are picked up by docclose batch and closed after reconciliation.

Restart/Recovery

The logical unit of work for this module is defined as a unique tsf_no. The restart transfer view is used for threading. This batch program uses table-based restart/recovery. The commit happens in the database when the commit max counter is reached.

Design Assumptions

N/A

Close Transactions with no Expected Appointments, Shipments or Receipts (doc_queue_close_job)

Module Name doc_queue_close_job Description Close Transactions with no Expected Appointments, Shipments or Receipts Functional Area Transfers, Allocation, and RTVs Module Type Admin - Ad hoc Module Technology Background Processing Catalog ID N/A Wrapper Script b8dwrap.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This background job is composed of two steps processing. It will have a threading assignment and a business logic processing.

Thread assignment program will filter eligible records from document close queue table based on un-Closed status of POs, Transfers and Allocations. These unique documents that do not have any outstanding appointments, shipments or receipts expected, receipts without appointments will be recorded on the document close queue table. Likewise, allocations

sourced from an inbound receipt of another document (for example, POs, Transfers, Allocations, ASNs and BOLs) can only be closed if the sourcing document is closed. These records are chunked and Thread ID is assigned for each. They will be stored temporarily in a staging table.

The Business logic program will process all records from the staging table. Using bulk processing, this program will update the records of each document type to attempt closure of each document. PO-type documents will call APPT_DOC_CLOSE_SQL.CLOSE_PO program. Transfer-type documents will call APPT_DOC_CLOSE_SQL.CLOSE_TSF program. Allocationtype documents will call APPT_DOC_CLOSE_SQL.CLOSE_ALL_ALLOCS program. All successful closure of document will be removed its entry from document close queue table. It will free up and clean the staging table afterwards. There is a STOP ON NEXT feature in bulk processing (through a loop) where Administrators can stop this batch with a flip of this indicator.

Restart/Recovery

N/A

Key Tables Affected

Table 13-2 Key Tables Affected

Table	Select	Insert	Update	Delete
RMS_BATCH_STATUS	Yes	No	No	No
B8D_PROCESS_CONFIG	Yes	No	No	No
JOB_AUDIT_LOGS	No	Yes	No	No
B8D_DOC_CLOSE_QUEUE_ST G	Yes	Yes	No	Yes
DOC_CLOSE_QUEUE	Yes	No	No	Yes
ORDHEAD	No	No	Yes	No
DEAL_CALC_QUEUE	No	No	No	Yes
ITEM_LOC_SOH	No	No	Yes	No
TSFHEAD	No	No	Yes	No
ALLOC_HEADER	No	No	Yes	No

Design Assumptions

N/A

Close Transactions with no Expected Appointments, Shipments or Receipts (docclose)

Module Name Description Functional Area Module Type

docclose.pc

Close Transactions with no Expected Appointments, Shipments or Receipts Transfers, Allocation, and RTVs Business Processing

Module Technology ProC Catalog ID RMS219 Wrapper Script rmswrap.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This program will be used to attempt to close POs, transfers, and allocations that do not have any outstanding appointments, shipments or receipts expected. Receipts without appointments are recorded on a queue table. Allocations sourced from an inbound receipt of another document (such as, POs, Transfers, Allocations, ASNs and BOL) can only be closed if the sourcing document is closed. This batch program will retrieve unique documents from the table and use existing functions to attempt closure for each.

Restart/Recovery

The logical unit of work is a unique doc and doc_type combination. The program is restartable on the doc number

Design Assumptions

N/A

Create Book Transfers for Allocations Between Warehouses in the Same Physical Warehouse (allocbt)

Module Name allocbt.ksh Description Create Book Transfers for Allocations Between Warehouses in the Same Physical Warehouse Functional Area Inventory Movement Module Type Business Processing Module Technology ksh Catalog ID RMS175 Wrapper Scripts rmswrap_shell.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

In Merchandising, when an allocation is received that involves a movement of stock between two warehouses, it should be determined if the source and any of the destination warehouses belong to the same physical warehouse. If so, that portion of the allocation should be treated

as a book transfer and not sent down to RWMS for processing. This batch job identifies such allocations and creates book transfers once the allocation source is received and/or the release date for the allocation is reached.

Allocations can be sourced either from a warehouse’s available inventory or from an inbound receipt. These allocations are integrated into Merchandising’s Allocation tables and can be identified as the following:

1. Warehouse Sourced Allocations:

• a. Order number is NULL and doc is NULL on the allocation header table.

2. Purchase Ordered Sourced Allocations (Cross Doc POs):

• a. Order number holds the PO number and doc type is ‘PO’ on the allocation header table.

• b. Linked shipments are identified through the order number value on the shipment and the allocation header tables.

3. Transfer Sourced Allocations:

• a. Order number holds the transfer number and doc type is ‘TSF’ on the allocation header table.

• b. Linked shipments are identified through the distro number on the shipment/item table and the order number on the allocation header table.

4. Allocation Sourced from an Inbound Allocation:

• a. Order number holds the allocation number and doc type is ‘ALLOC’ on the allocation header table.

• b. Linked shipments are identified through the distribution number on the shipment/item table and the order number on the allocation header table.

5. ASN Sourced Allocations:

• a. Doc holds the ASN number and doc type is ‘ASN’ on the allocation header table.

• b. Linked shipments are identified through the ASN on the shipment table and the doc on the allocation header table.

6. BOL Sourced Allocations:

• a. Doc holds the BOL number and doc type is ‘BOL’ on the allocation header table.

• b. Linked shipments are identified through the BOL number on the shipment table and the doc value on the allocation header table.

This batch job supports all above allocation scenarios and calls a core package function to create book transfers.

Restart/Recovery

N/A

Design Assumptions

N/A

Create Return to Vendor for Mass Return Transfer (mrtrtv)

Module Name mrtrtv.pc Description Create Return To Vendor for Mass Return Transfer Functional Area Transfers, Allocations and RTVs Module Type Business Processing Module Technology ProC Catalog ID RMS275 Wrapper Script rmswrap_multi.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch program creates RTVs for approved mass return transfers that require an RTV to be created automatically and have an RTV create date earlier than or equal to the current date. RTVs are created in either Input or Approved status, depending on how the MRT was created. The program will then set the status of all processed MRTs to ‘R’ in the MRT table, which indicates that the RTVs have been created.

Restart/Recovery

The logical unit of work for this program is set at the warehouse level. Threading is done by store using the restart all locations view.

Design Assumptions

N/A

Create Transfers for Mass Return Transfer (mrt)

Module Name mrt.pc Description Create Transfers for Mass Return Transfer Functional Area Transfers, Allocations and RTVs Module Type Business Processing Module Technology ProC Catalog ID RMS273 Wrapper Script rmswrap_multi.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch program creates individual transfers for each ‘from’ location on an approved Mass Return Transfer. Transfers will be created in approved status, however for MRTs with a Quantity Type of ‘Manual’, meaning the MRT was created for a specific quantity rather than ‘All Inventory’, if the SOH at the sending location is lower than the requested quantity the status will be created in Input status. In addition, if the Transfer Not After Date specified on the MRT is earlier than or equal to the current date, the status of the associated transfers will also be set to Input.

Restart/Recovery

The logical unit of work is a from/to location combination. This may represent a transfer of multiple items from a location (store or warehouse) to a warehouse, depending on how the MRT was created. Restart/recovery is based on from/to location as well. The batch program uses the restart all locations view to thread processing by warehouse (to location).

Design Assumptions

N/A

Detail Receive Damaged or Tampered with Cartons (tamperctn)

Module Name tamperctn.pc Description Detail Receive Damaged or Tampered with Cartons Functional Area Transfers, Allocations and RTVs Module Type Business Processing Module Technology ProC Catalog ID RMS371 Wrapper Script rmswrap.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This program looks for items that were intended to be received as a pack and attempts to match based on component quantity. It reads records from the staging table for the carton ID for pack items not received and attempts to match on the components of the pack and quantity. If a match is found, then the dummy carton is received against the matching carton. If a match is not found, an error is written to an error file and the record remains on the staging table. These unprocessed records are eventually purged from the staging table when the receipt transaction date is older than the current date minus Close Open Shipments After Days.

This program is only run if the Receive Pack Component system parameter is set to Yes.

Restart/Recovery

N/A

Design Assumptions

N/A

Purge Aged Mass Return Transfers and RTV (mrt_purge_job)

Module Name mrt_purge_job Description Purge Aged Mass Return Transfers and RTVs Functional Area Transfers, Allocations and RTVs Module Type Admin - Ad hoc Module Technology Background Processing Catalog ID N/A Wrapper Script b8dwrap.ksh

Design Overview

This background job is composed of two-step processing. It will have a threading assignment and a business logic processing.

Thread assignment program will filter eligible records from mass return transfer (MRT) table based on its purge criteria from system parameter settings. The MRT Transfer Retention days parameter will determine the time elapsed with MRT close date is less than the current date. Only MRTs with closed status (and all associated transfers that are also closed) are captured for deletion. These records are chunked and Thread ID is assigned for each. They will be stored temporarily in a staging table.

The Business logic program will process all records from the staging table. Using bulk processing, this program will purge the records from mass return transfer (MRT) table and its associated transfers and RTVs. It will free up and clean the staging table afterwards. There is a STOP ON NEXT feature in bulk processing (through a loop) where Administrators can stop this batch with a flip of this indicator.

Restart/Recovery

N/A

Key Tables Affected

Table 13-3 Key Tables Affected

Table	Select	Insert	Update	Delete
PERIOD	Yes	No	No	No
SYSTEM_OPTIONS	Yes	No	No	No
RMS_BATCH_STATUS	Yes	No	No	No

Table 13-3 (Cont.) Key Tables Affected

Table	Select	Insert	Update	Delete
B8D_PROCESS_CONFIG	Yes	No	No	No
JOB_AUDIT_LOGS	No	Yes	No	Yes
B8D_MRT_PURGE_STG	Yes	Yes	No	Yes
TSFHEAD	Yes	No	No	Yes
TSFDETAIL	No	No	No	Yes
MERCHAPI_EXT_SHIPMENT	No	No	No	Yes
SHIPMENT	No	No	No	Yes
SHIPSKU	Yes	No	No	Yes
SHIPITEM_INV_FLOW	No	No	No	Yes
CARTON	No	No	No	Yes
APPT_HEAD	Yes	No	No	Yes
APPT_DETAIL	Yes	No	No	Yes
DOC_CLOSE_QUEUE	No	No	No	Yes
INVC_HEAD	Yes	No	No	Yes
INVC_DETAIL	Yes	No	No	Yes
MRT	Yes	No	No	Yes
MRT_ITEM	Yes	No	No	Yes
MRT_ITEM_LOC	Yes	No	No	Yes
RTV_HEAD	Yes	No	No	Yes
RTV_DETAIL	No	No	No	Yes
TSFDETAIL_CHRG	No	No	No	Yes

Design Assumptions

N/A

Purge Aged Mass Return Transfers and RTV (mrtprg)

Module Name mrtprg.pc Description Purge Aged Mass Return Transfers and RTVs Functional Area Transfers, Allocations and RTVs Module Type Admin Module Technology ProC Catalog ID RMS274 Wrapper Script rmswrap_multi.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

The purpose of this module is to purge mass return transfer (MRT) records, and their associated transfers and RTVs. Only MRTs with a status of closed in which all transfers associated with the MRT are also closed and where the time elapsed between the current date and the close date is at least equal to the system parameter value for MRT Transfer Retention days.

Restart/Recovery

The logical unit of work for this batch program is a warehouse location. The program is multithreaded using restart all locations view.

Design Assumptions

N/A

Purge Aged Returns to Vendors (rtv_purge_job)

Module Name rtv_purge_job Description Purge Aged Returns to Vendors Functional Area Transfers, Allocations and RTVs Module Type Admin - Ad hoc Module Technology Background Processing Catalog ID N/A Wrapper Script b8dwrap.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This background job is composed of two steps processing. It will have a threading assignment and a business logic processing.

Thread assignment program will filter eligible records from return-to-vendor header table based on its purge criteria from system parameter settings. The RTV Order History Months parameter will determine the number of months between their completion date and current date exceeds as defined to be outdated records. These old/outdated RTV records should have all debit memos associated to have been posted. These records are chunked and Thread ID is assigned for each. They will be stored temporarily in a staging table.

The Business logic program will process all records from the staging table. Using bulk processing, this program will delete the records from return-to-vendor header and other related/associated RTV tables. It will free up and clean the staging table afterwards. There is a STOP ON NEXT feature in bulk processing (through a loop) where Administrators can stop this batch with a flip of this indicator.

N/A

Restart/Recovery

Key Tables Affected

Table 13-4 Key Tables Affected

Table	Select	Insert	Update	Delete
RMS_BATCH_STATUS	Yes	No	No	No
B8D_PROCESS_CONFIG	Yes	No	No	No
JOB_AUDIT_LOGS	No	Yes	No	No
B8D_RTV_PURGE_STG	Yes	Yes	No	Yes
RTV_HEAD	No	No	No	Yes
RTV_DETAIL	No	No	No	Yes
INVC_HEAD	Yes	No	No	Yes
INVC_DETAIL	No	No	No	Yes
INVC_NON_MERCH	Yes	No	No	Yes
INVC_MERCH_VAT	Yes	No	No	Yes
INVC_DETAIL_VAT	Yes	No	No	Yes
INVC_MATCH_QUEUE	Yes	No	No	Yes
INVC_DISCOUNT	Yes	No	No	Yes
INVC_TOLERANCE	Yes	No	No	Yes
ORDLOC_INVC_COST	Yes	No	Yes	No
INVC_MATCH_WKSHT	Yes	No	No	Yes
INVC_XREF	Yes	No	No	Yes
RTVITEM_INV_FLOW	No	No	No	Yes
RTV_HEAD_CFA_EXT	No	No	No	Yes

Design Assumptions

N/A

Purge Aged Returns to Vendors (rtvprg)

Module Name rtvprg.pc Description Purge Aged Returns to Vendors Functional Area Transfers, Allocations and RTVs Module Type Admin Module Technology ProC Catalog ID RMS320 Wrapper Script rmswrap.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This batch program purges outdated RTV transactions from Merchandising. RTVs are considered outdated if they number of months between their completion date and the current date exceeds the system parameter RTV Order History Months and where all debit memos associated with the RTV have been posted.

Restart/Recovery

N/A

Design Assumptions

N/A

Purge Aged Transfers (transfer_purge_job)

Module Name transfer_purge_job Description Purge Aged Transfers Functional Area Transfers, Allocations and RTVs Module Type Admin - Ad hoc Module Technology Background Processing Catalog ID N/A Wrapper Script b8dwrap.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This background job is composed of two steps processing. It will have a threading assignment and a business logic processing.

Thread assignment program will filter eligible records from transfer header table and other associated transfer-related tables based on its purge criteria from system parameter settings. The Transfer History Months parameter will determine what transfer records are ready for purging that are considered closed or deleted in status and comparison of transfer close date with tomorrow’s current date. These records are chunked and Thread ID is assigned for each. They will be stored temporarily in a staging table.

The Business logic program will process all records from the staging table. Using bulk processing, this program will delete the records from transfer header and other associated transfer tables. It will free up and clean the staging table afterwards. There is a STOP ON NEXT feature in bulk processing (through a loop) where Administrators can stop this batch with a flip of this indicator.

N/A

Restart/Recovery

Key Tables Affected

Table 13-5 Key Tables Affected

Table	Select	Insert	Update	Delete
PERIOD	Yes	No	No	No
SYSTEM_OPTIONS	Yes	No	No	No
RMS_BATCH_STATUS	Yes	No	No	No
B8D_PROCESS_CONFIG	Yes	No	No	No
JOB_AUDIT_LOGS	No	Yes	No	No
B8D_TRANSFER_PURGE_STG	Yes	Yes	No	Yes
TSFHEAD	Yes	No	No	Yes
TSFDETAIL	No	No	No	Yes
ALLOC_HEADER	Yes	No	No	Yes
ALLOC_DETAIL	No	No	No	Yes
ALLOC_CHRG	Yes	No	No	Yes
ALLOC_PURGE_QUEUE	Yes	No	No	No
DOC_PURGE_QUEUE	Yes	No	No	No
SHIPSKU	Yes	No	No	Yes
MERCHAPI_EXT_SHIPMENT	No	No	No	Yes
SHIPMENT	No	No	No	Yes
CARTON	No	No	No	Yes
TSFHEAD_CFA_EXT	No	No	No	Yes
TSFHEAD_L10N_EXT	No	No	No	Yes
TSF_ITEM_COST	No	No	No	Yes
TSF_ITEM_WO_COST	No	No	No	Yes
TSF_PACKING	Yes	No	No	Yes
TSF_PACKING_DETAIL	No	No	No	Yes
TSF_XFORM	Yes	No	No	Yes
TSF_XFORM_DETAIL	No	No	No	Yes
TSF_WO_HEAD	Yes	No	No	Yes
TSF_WO_DETAIL	No	No	No	Yes
TSFDETAIL_CHRG	No	No	No	Yes
ORDCUST	Yes	No	No	Yes
ORDCUST_CUSTOMER_DETAI L	No	No	No	Yes
ORDCUST_DETAIL	No	No	No	Yes
ORDCUST_PUB_INFO	No	No	No	Yes
SHIPITEM_INV_FLOW	No	No	No	Yes

Table 13-5 (Cont.) Key Tables Affected

Table	Select	Insert	Update	Delete
SHIPSKU_PRG_HIST	No	Yes	No	No
ORDCUST_DETAIL_PRG_HIST	No	Yes	No	No
ORDCUST_PRG_HIST	No	Yes	No	No
TSFDETAIL_CHRG_PRG_HIST	No	Yes	No	No
TSF_WO_DETAIL_PRG_HIST	No	Yes	No	No
TSF_WO_HEAD_PRG_HIST	No	Yes	No	No
TSF_XFORM_DETAIL_PRG_HIS T	No	Yes	No	No
TSF_XFORM_PRG_HIST	No	Yes	No	No
TSF_PACKING_DETAIL_PRG_HI ST	No	Yes	No	No
TSF_PACKING_PRG_HIST	No	Yes	No	No
TSF_ITEM_WO_COST_PRG_HI ST	No	Yes	No	No
TSF_ITEM_COST_PRG_HIST	No	Yes	No	No
TSFDETAIL_PRG_HIST	No	Yes	No	No
TSFHEAD_L10N_EXT_PRG_HI ST	No	Yes	No	No
TSFHEAD_CFA_EXT_PRG_HIS T	No	Yes	No	No
TSFHEAD_PRG_HIST	No	Yes	No	No

Design Assumptions

N/A

Purge Aged Transfers (tsfprg)

Module Name tsfprg.pc Description Purge Aged Transfers Functional Area Transfers, Allocations and RTVs Module Type Admin Module Technology ProC Catalog ID RMS380 Wrapper Script rmswrap_multi.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This module purges closed or deleted transfers and their associated records after a set number of days, based on the Transfer History Months system parameter.

Restart/Recovery

This batch program is multithreaded using the restart transfer view. The logical unit of work is a transfer number. This batch program commits to the database for every commit max counter number of transfers processed.

Design Assumptions

• This batch program does not process Mass Return Transfers (MRT) and Franchise transfers (FO and FR). Purging of MRT and Franchise Order and Return records are done by mrtprg, wfordprg, wfrtnprg respectively.

Purge Stock Order Reconciliation Induction Staging Tables (sor_indctn_purge)

Module Name sor_indctn_purge.ksh Description Purge stock order reconciliation induction staging tables Functional Area Inventory Management Module Type Admin Module Technology Shell Script Catalog ID Wrapper Script N/A

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

The purpose of this module is to remove old stock order reconciliation records from the induction staging tables. Records that are candidates for deletion are:

• Processes that have successfully been processed or processed with warnings that have been uploaded to Merchandising or downloaded to S9T

• Processes in error status where all other related records containing the process ID have been processed successfully

• Processes that are past the data retention days (that is, the action date is earlier than the retention date)

Restart/Recovery

Restart ability will be implied, because the records that are selected from the cursor will be deleted before the commit.

Design Assumptions

N/A

Reconcile Received Dummy Carton IDs with Expected Cartons (dummyctn)

Module Name dummyctn.pc Description Reconcile Received Dummy Carton IDs with Expected Cartons Functional Area Transfers, Allocations and RTVs Module Type Business Processing Module Technology ProC Catalog ID RMS233 Wrapper Script rmswrap.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

When stock orders are received, if a carton number or barcode cannot be read due to damage to the box or other factors, a dummy ID is assigned to it and its detail received at the store or warehouse. The dummy ID and the details of the carton received are then written to a staging table during the receiving process. This batch process scans stock orders to find transfers or allocations that contain cartons that were not received to see if any shipments contain unreceived cartons that match the dummy carton receipt (both item and quantity). If a match is found, then the dummy carton is received against the matching carton. If a match is not found, an error is written to an error file and the record remains on the staging table.

These unprocessed records are eventually purged from the staging table when the receipt transaction date is older than the current date minus Close Open Shipments After Days.

Restart/Recovery

This program deletes from the dummy carton staging table. The program will restart by processing the records that remain on the dummy carton staging table.

Design Assumptions

N/A

Stage Regular Price Changes on Open Allocations and Transfers (distropcpub)

Module Name distropcpub.pc Description Stage Regular Price Changes on Open Allocations/Transfers so Publishing Sends New Retail to Subscribing Applications Functional Area Transfers, Allocations, and RTV Module Type Integration Module Technology ProC Catalog ID RMS216 Wrapper Script rmswrap_multi.ksh

Schedule

Oracle Retail Merchandising Batch Schedule

Design Overview

This program will look for any regular price change (transaction type 4 or 11 from the price history table) that is due to go into effect tomorrow. Then, for any open allocations or transfers where the ‘to’ location and items that have price changes going into effect, it places a record on the allocation or transfer publishing queue tables, such that they can be picked up by the RIB and sent to the subscribing systems.

Restart/Recovery

The logical unit of work is store. The driving cursor retrieves all item/locations that have price changes in effect from the next day. It also gets all of the component items of the non-sellable packs that have price changes.

I/O Specification

Integration Type Download from Merchandising File Name N/A Integration Contract IntCon000196 ALLOC_MFQUEUE table Integration Type Download from Merchandising File Name N/A Integration Contract IntCon000197 TSF_MFQUEUE table

Design Assumptions

N/A

---

In this guide

• Guide: Batch Operations Guide
• Previous: 12 Inventory
• Next: 14 Sales Posting

Related chapters

• 5 Purchase Order — Batch Operations Guide · shares ALLOC_CHRG, ALLOC_DETAIL, ALLOC_HEADER, APPT_DETAIL
• F Appendix: Publication Tables and Triggers — Merchandising Cloud Services Data Conversion Implementation Guide · shares ALLOC_DETAIL, ALLOC_HEADER, ALLOC_MFQUEUE, ORDCUST_PUB_INFO
• 5 ReSTful Web Services — Inbound and Outbound Integration Guide · shares ALLOC_CHRG, ALLOC_DETAIL, ALLOC_HEADER, APPT_DETAIL
• 10 Invoice Matching — Batch Operations Guide · shares INVC_DETAIL, INVC_DETAIL_VAT, INVC_DISCOUNT, INVC_HEAD