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 CS (SIOCS), and warehouse systems, such as Oracle WMS Cloud. However, Merchandising does use 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 Overdue Transfers (transfer_close_job) - background process
-
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)
-
Purge Aged Mass Return Transfers and RTV (mrt_purge_job) - background process
-
Purge Aged Returns to Vendors (rtv_purge_job) - background process
-
Purge Aged Transfers (transfer_purge_job) - background process
-
Reconcile Received Dummy Carton IDs with Expected Cartons (dummyctn)
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 |
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.
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 |
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.
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 |
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 |
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.
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 |
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. Allocation-type 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.
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_STG |
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 |
Close Transactions with no Expected Appointments, Shipments or Receipts (docclose)
Module Name |
docclose.pc |
Description |
Close Transactions with no Expected Appointments, Shipments or Receipts |
Functional Area |
Transfers, Allocation, and RTVs |
Module Type |
Business Processing |
Module Technology |
ProC |
Catalog ID |
RMS219 |
Wrapper Script |
rmswrap.ksh |
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.
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 |
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:
-
Warehouse Sourced Allocations:
-
Order number is NULL and doc is NULL on the allocation header table.
-
-
Purchase Ordered Sourced Allocations (Cross Doc POs):
-
Order number holds the PO number and doc type is 'PO' on the allocation header table.
-
Linked shipments are identified through the order number value on the shipment and the allocation header tables.
-
-
Transfer Sourced Allocations:
-
Order number holds the transfer number and doc type is 'TSF' on the allocation header table.
-
Linked shipments are identified through the distro number on the shipment/item table and the order number on the allocation header table.
-
-
Allocation Sourced from an Inbound Allocation:
-
Order number holds the allocation number and doc type is 'ALLOC' on the allocation header table.
-
Linked shipments are identified through the distribution number on the shipment/item table and the order number on the allocation header table.
-
-
ASN Sourced Allocations:
-
Doc holds the ASN number and doc type is 'ASN' on the allocation header table.
-
Linked shipments are identified through the ASN on the shipment table and the doc on the allocation header table.
-
-
BOL Sourced Allocations:
-
Doc holds the BOL number and doc type is 'BOL' on the allocation header table.
-
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.
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 |
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.
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 |
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).
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 |
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.
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.
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 |
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 |
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 |
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 |
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.
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 |
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.
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 |
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 |
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.
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 |
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.
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 |
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_DETAIL |
No |
No |
No |
Yes |
ORDCUST_DETAIL |
No |
No |
No |
Yes |
ORDCUST_PUB_INFO |
No |
No |
No |
Yes |
SHIPITEM_INV_FLOW |
No |
No |
No |
Yes |
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_HIST |
No |
Yes |
No |
No |
TSF_XFORM_PRG_HIST |
No |
Yes |
No |
No |
TSF_PACKING_DETAIL_PRG_HIST |
No |
Yes |
No |
No |
TSF_PACKING_PRG_HIST |
No |
Yes |
No |
No |
TSF_ITEM_WO_COST_PRG_HIST |
No |
Yes |
No |
No |
TSF_ITEM_COST_PRG_HIST |
No |
Yes |
No |
No |
TSFDETAIL_PRG_HIST |
No |
Yes |
No |
No |
TSFHEAD_L10N_EXT_PRG_HIST |
No |
Yes |
No |
No |
TSFHEAD_CFA_EXT_PRG_HIST |
No |
Yes |
No |
No |
TSFHEAD_PRG_HIST |
No |
Yes |
No |
No |
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 |
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.
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 |
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 un-received 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.
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 |
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.