| Oracle® Retail Warehouse Management System Operations Guide Release 14.1 E58976-01 |
|
 Previous |
 Next |
| Oracle® Retail Warehouse Management System Operations Guide Release 14.1 E58976-01 |
|
Previous |
Next |
This chapter consists of the following:
All batch files passed between an outside system and RWMS consist of one or more records in the upload or download files. These records contain printable ASCII characters (with space characters between each field) and are of a fixed length based on the transaction type.
Fields that are defined within transaction records have an associated template that defines the arrangement, length, and logical content of the field. They appear as one of the following types:
Table 5-1 Different Types of Fields
| Template | Meaning |
|---|---|
|
A |
A character data type. |
|
N |
A numbered digit (0 through 9). |
|
N(p) |
An unsigned p-digit number. |
|
N(p)vN(q) |
A fixed point number with a decimal point, p digits to the left of the decimal and q digits to the right. |
|
sN(p) |
A p-digit number that has a sign ('+' or '-') as its first significant character. |
|
X |
An alphanumeric character. |
|
X(p) |
A p-character string. |
|
YYYYMMDDHHMI |
A date/time, with a 4-digit year followed by a 2-digit month followed by a 2-digit day followed by a 2-digit hour, a 24 hour format, followed by a 2-digit minute. |
|
Note: Numeric fields are always right justified with leading zeros. Character fields are left justified with trailing blanks, unless otherwise stated. |
This file specifies the outstanding store orders to be fulfilled to the Unit Pick System.
Table 5-2 Store Orders
| Field Description | Template | Destination |
|---|---|---|
|
Facility id (dc) |
X (2) |
Code for the DC |
|
Unit pick system code |
X (4) |
Code for Unit Pick System |
|
Wave number |
N (3) |
Unique identifier of wave |
|
Item id |
X (25) |
Unique identifier of the item. |
|
Dest id |
X (10) |
Identifier of the ship destination. |
|
Unit qty |
N (8) v N (4) |
Number of units |
|
Logical chute |
X (10) |
Logical chute assigned to group |
|
Group id |
N (4) |
Identifier for a set of orders |
|
Slot |
N (3) |
Identifier with a group associated to an order |
|
To container id |
X (20) |
System generated container ID merchandise to be packed |
This file specifies the carton content and the associated wave to the Unit Pick System.
Table 5-3 Carton Content
| Field Description | Template | Destination |
|---|---|---|
|
Facility id (dc) |
X (2) |
Code for the DC |
|
Unit pick system code |
X (4) |
Code for Unit Pick System |
|
Wave number |
N (3) |
Unique identifier of wave |
|
Container id |
X (20) |
Unique identifier of the source container. |
|
Item id |
X (25) |
Unique identifier of the item. |
|
Requested unit qty |
N (8) v N (4) |
Number of units |
This file serves as a notification from a Unit Pick System to RWMS concerning contents of a picked container, the associated wave number and the outbound destination ID.
Table 5-4 Notification
| Field Description | Template | Destination |
|---|---|---|
|
Facility ID (DC) |
X (2) |
Code for the DC |
|
Transaction Date/Time |
YYYYMMDD HH24MI |
Date and time this record was created. |
|
Wave Number |
N (3) |
Unique identifier of wave |
|
Container ID |
X (20) |
Unique identifier of the container. |
|
Item ID |
X (25) |
Unique identifier of the item |
|
Distributed Unit Qty |
N (8) v N (4) |
Number of distributed units |
|
Dest ID |
X (10) |
Identifier of the ship destination. |
The Pick By Light system (PBL) requires a variety of information from a host in order to drive its paperless picking processes. These transactions are sent periodically; the frequency is determined by the urgency of the transaction type. The host is either RWMS or, as in standalone operations, some other application. Data is exchanged through text files. With text file data exchange, PBL is not concerned with the specifics of how the files were created or how they arrived in the upload or download directories. Each customer selects an approach to suit the preferred communication methods.
All download files are placed in a directory that is named by the UNIX environment variable DOWNLOAD_DIR. All upload files are placed in a directory that is named by the UNIX environment variable UPLOAD_DIR.
The download and upload files have set names as listed in the following table. The files are listed in the order in which they are run because each download may depend upon a previous one.
Table 5-5 Files and Directories
| Interface Name | Script Name | File Name |
|---|---|---|
|
Destination Container Download |
dest_container_download.sh |
dest_container_download.dat dest_cont_item_download.dat |
|
Distribution Item Download |
distro_item_download.sh |
distro_item_download.dat |
|
Inventory Adjustment Download |
inv_adj_download.sh |
inv_adj_download.dat |
|
Ship Destination Download |
pps_ship_dest_upload.sh |
ship_dest_upload.dat |
|
Distro Item Upload |
create_distro_item_upload.sh |
distro_item_upload.dat |
|
Expected Source Container Upload |
create_exp_container_upload.sh |
exp_container_upload.dat |
|
Source Container Upload |
generate_source_container_upld.sh |
source_container_upload.dat |
The PBL downloads include several fields that are future use. These fields are included to allow for the future growth in RWMS and to allow the PBL to work standing alone, without RWMS. PBL download errors are recorded in the local RWMS error log, and are not uploaded to the host. The user can view and maintain this log in the Error Log screen.
The Destination Container download files are built by PBL for use by RWMS. They contain PBL built containers and the items and quantities in them that are added back to inventory or shipped. If the destination is marked as the DC, the container is sent to stock; otherwise, a distribution is assumed, and the container is routed appropriately. When PBL has finished creating the files, they are first copied to the download directory by PBL. Then, the script in RWMS for this download is started by PBL. The script reads the files, loads the data into RWMS, and adds the container information to RWMS.
The Destination Container Download consists of a Header file and a Detail file.
The Header file, which describes the container, has the following format:
Table 5-6 Destination Container Download
| Field Description | Template | Description |
|---|---|---|
|
Transaction Date/Time |
YYYYMMDD HH24MISS |
Date and time this record was created (future use) |
|
Record Type |
A |
Record type in PBL. Always a Z for a Destination Container Download header record (future use). |
|
Facility ID |
X (2) |
Identifier for the facility. |
|
Company Number |
N (1) |
Company Number (future use). |
|
Destination ID |
X (10) |
Identification of the ship destination. |
|
Container ID |
X (20) |
Identifier for the container. |
|
Destination Name |
X (30) |
Descriptive name of the ship destination (future use). |
|
Address 1 |
X (30) |
First address line of the ship destination (future use). |
|
Address 2 |
X (30) |
Second address line of ship destination (future use). |
|
Address 3 |
X (30) |
Third address line of the ship destination (future use). |
The Detail file, which describes the contents of the closed picking container, has the following format:
Table 5-7 Detail File
| Field Description | Template | Description |
|---|---|---|
|
Transaction Date/Time |
YYYYMMDD HH24MISS |
Date and time this record was created (future_use). |
|
Record Type |
A |
Record type in PBL. Always a Y for a Destination Container Download detail (future use). |
|
Facility ID |
X (2) |
Identifier for the facility. |
|
Container ID |
X (20) |
Identifier for the container. |
|
Distribution/Order Number |
X (10) |
Identifier for the distribution or order. |
|
Item ID |
X (25) |
Identifier for the item. |
|
Unit Qty |
N (8) v N (4) |
Unit quantity that was picked for this item. |
|
Item Description |
X (60) |
Text description of the item (future use). |
Errors due to data integrity with the download are recorded in the error log and the record is ignored. Possible errors include:
Facility ID does not exist in RWMS.
Container already exists in RWMS.
Non-existent Destination ID.
Duplicate Item ID/Distro Nbr (or Item/Order) on the container detail.
Non-existent Item ID.
The Distribution Item Download file is built by PBL and sent to RWMS. Therefore, pick directive records are deleted and stock allocations adjusted as needed. When PBL has finished creating the files, they are first copied to the download directory by PBL. Then the script in RWMS for this download starts by PBL. The script reads the file, loads the data into RWMS, and updates the picking information in RWMS as required.
The format for the Distribution Item Download is as follows:
Table 5-8 Distribution Item Download
| Field Description | Template | Description |
|---|---|---|
|
Transaction Date/Time |
YYYYMMDD HHMISS |
Date and time this record was created (future use). |
|
Record Type |
A |
Record type in PPS. Always an X for a Destination Container Download header record (future use). |
|
Facility ID |
X (2) |
Identifier for the facility. |
|
Company Number |
N (1) |
Company Number (future use). |
|
Distro Number |
X (10) |
Identifier for the distribution or order. |
|
Item ID |
X (25) |
Identifier for the item. |
|
Destination ID |
X (10) |
Identifier for the shipping destination. |
|
Requested Unit Qty |
N (8) v N (4) |
Number of units of this item requested for picking. |
|
Distributed Unit Qty |
N (8) v N (4) |
Number of units of this item actually picked. |
Errors due to data integrity with the download are recorded in the error log and the record is ignored. Possible errors include:
Non-existent Facility ID.
Non-existent Destination ID.
Non-existent Item ID.
No pick for the distro/item/destination.
The Inventory Adjustment Download file is built by PBL and sent to RWMS when there is a difference between the quantity sent on the Source Container Upload and the actual quantity picked. RWMS validates the data in the file and sends the information in an Inventory Adjustment Upload to the host system. This is the only action RWMS takes on this; no change in RWMS data occurs. After PBL creates the files, they are copied to the download directory by PBL. Then PBL starts the script in RWMS, or this download. The script reads the files, validates the data, and inserts the information into the Inventory Adjustment Upload table in RWMS for upload to the host (reason code to the host for this adjustment is 30).
The format for the Inventory Adjustment Download is as follows:
Table 5-9 Inventory Adjustment Download
| Field Description | Template | Description |
|---|---|---|
|
Transaction Date/Time |
YYYYMMDD HHMISS |
Date and time this record was created (future use). |
|
Record Type |
A |
The record type in PBL. This is always sent as W for an Inventory Adjustment Download (future use). |
|
Facility ID |
X (2) |
Identifier for the facility. |
|
Company Number |
N (1) |
A single digit number for the company. This is a new system parameter in RWMS (future use). |
|
Distro Number |
X (10) |
The identifier for the distribution (future use). |
|
Item ID |
X (25) |
The identifier for the item. |
|
Adjusted Unit Qty |
sN (8) v N (4) |
The difference between source container units and the number of units of this item actually picked. A positive number means more were picked than expected; a negative number means fewer were picked than expected. |
Errors due to data integrity with the download are recorded in the error log and the record is ignored. Possible errors include:
Non-existent Item ID.
The Ship Destination Upload file is spooled from the Shipping Destination table and sorted by Facility ID, Company Number, and Shipping Destination. This file is empty unless an adjustment action (add/modify/delete) is sent to RWMS from the host, or performed in the Destination Editor screen. Whenever an adjustment is performed, all shipping destinations that RWMS knows about are sent to PBL via the upload. Thus, this upload is an all or nothing data file.
The format for the Ship Destination Upload is as follows:
Table 5-10 Ship Destination Upload
| Field Description | Template | Description |
|---|---|---|
|
Transaction Date/Time |
YYYYMMDD HHMISS |
Date and time this record was created. |
|
Record Type |
A |
Record type in PBL. Always an 'A' for a Ship Destination Upload. |
|
Facility ID |
X (2) |
Identifier for the facility. |
|
Company Number |
N (1) |
Company Number. |
|
Destination ID |
X (10) |
Identification of the ship destination. |
|
Destination Name |
X (30) |
Descriptive name of the ship destination. |
|
Address 1 |
X (30) |
First address line of the ship destination. |
|
Address 2 |
X (30) |
Second address line of ship destination. |
|
Address 3 |
X (30) |
Third address line of the ship destination. |
The Distro Item Upload file contains records that indicate to PBL which items, and how many, are shipped to specified destinations. After the distribution process runs, this file is built from all remaining sorted allocation records that are eligible to be processed by PBL (the item does not have a FPL defined). Records are sorted by facility number, company number, distribution/order number, item, distro/order creation time stamp, and shipping destination.
The format for the Distro Item Upload is as follows:
Table 5-11 Distro Item Upload
| Field Description | Template | Description |
|---|---|---|
|
Transaction Date/Time |
YYYYMMDD HHMISS |
Date and time this record was created. |
|
Record Type |
A |
Record type in PBL. Always a B for a Distro Item Upload. |
|
Facility ID |
X (2) |
Identifier for the facility. |
|
Company Number |
N (1) |
Company Number. |
|
Distro Number |
X (10) |
Identifier for the distribution or order. |
|
Item ID |
X (25) |
Identifier for the item. |
|
Distro Create Date/Time |
YYYYMMDD HHMISS |
Date and time the distribution/order was created |
|
Destination ID |
X (10) |
Identifier for the shipping destination. |
|
Unit Qty |
N (8) v N (4) |
Number of units of this item to be shipped. |
|
Item Dept |
X (4) |
Department of the item. |
|
Item Description |
X (60) |
Item description. |
This Expected Source Container Upload file contains records identifying all Inventory containers necessary to fulfill the PBL requirements determined by the last distribution run. This information is used by PBL to know ahead of time what containers are needed by PBL. This file is built after each distribution run. Records are sorted by facility number, company number, distribution/order number, item, distribution/order creation time stamp, and container ID.
The format of the Expected Source Container Upload is as follows:
Table 5-12 Expected Source Container Upload
| Field Description | Template | Description |
|---|---|---|
|
Transaction Date/Time |
YYYYMMDD HH24MISS |
Date and time this record was created. |
|
Record Type |
A |
Record type in PBL. Always a C for an Expected Source Container Upload. |
|
Facility ID |
X (2) |
Identifier for the facility. |
|
Company Number |
N (1) |
Company Number. |
|
Distro Number |
X (10) |
Identifier for the distribution or order. |
|
Item ID |
X (25) |
Identifier for the item. |
|
Distro Create Date/Time |
YYYYMMDD HH24MISS |
Date and time the distribution/order was created. |
|
Container ID |
X (20) |
Identifier for the container. |
|
Requested Qty |
N (8) v N (4) |
Unit quantity that is requested for picking of this item. |
The Source Container Upload file is built as PBL Source containers are picked and dropped off at the PBL staging area. The upload file is used to match up expected containers with actual source containers delivered to PBL. It has no sorted order.
|
Note: The value of Actual Quantity in the Upload is 0 (zero) if the pick was canceled either by the user or indirectly via a system function (such as a location marked for cycle count). |
The format for the Source Container Upload is as follows:
Table 5-13 Source Container Upload
| Field Description | Template | Description |
|---|---|---|
|
Transaction Date/Time |
YYYYMMDD HH24MISS |
Date and time this record was created. |
|
Record Type |
A |
Record type in PBL. Always a D for a Source Container Upload. |
|
Facility ID |
X (2) |
Identifier for the facility. |
|
Container ID |
X (20) |
Identifier for the container. |
|
Actual Qty |
N (8) |
Unit quantity in the container. |
Due to the increased use of UCC-128 labeled containers and the addition of WIP code functionality to RWMS, the Oracle Retail Distribution Management Sortation module now sends container divert instruction messages to the sortation system to control the flow of containers on the conveyor.
Each message that RWMS sends to the sortation system informs it of the next logical destination for a container. The divert instruction could be, but is not limited to, one of the following: any type of processing area, QA sampling, palletization, putaway staging, or shipping lane divert instructions. Initially, a message is sent to the sorter whenever a container is created on RWMS. However, subsequent messages are sent to the sorter if the container is assigned one or more WIP codes. The sortation system is only sent the next logical destination for a container.
The sortation system continues to notify RWMS of any container diverts that occur on the conveyor system. Depending on the type of divert that has taken place, RWMS either attempts to auto-receive, move, or manifest the container.
All files are placed in a directory that is named by the UNIX environment variable SORTATION_DIR. The files have set names as listed below. They are listed in the order in which they should be run because each download may depend upon a previous one.
The sortation system sends a message when a container is scanned, indicating whether it was scanned as an induction, diverted to a processing area, or diverted to a shipping lane. If the container was inducted, RWMS performs an auto-receiving function. If the container is diverted to a processing area, RWMS updates the location of the container. When a divert to a shipping lane is sent, RWMS adds the container to the manifest for the trailer if one is available. For more details, refer to the RWMS Shipping Module in the Oracle Retail Warehouse Management System UI User Guide.
The Container Divert Message Download file has the following format:
Table 5-15 Container Divert Message Download
| Field Description | Template | Description |
|---|---|---|
|
Container ID |
X (20) |
Identifier of the container. |
|
Divert Type |
A |
I = Induction D = Shipping Lane Divert. |
|
Logical Destination |
X (4) |
Area of the DC to which the container was sorted. |
|
Tracking ID |
X (25) |
Tracking ID (if any) applied to the container by a carrier for tracking purposes. |
|
Divert Timestamp |
YYYYMMDD HH24MISS |
Date/Time the container was scanned by the sortation system. |
RWMS sends a Container Divert Instruction Message to the sortation system to control the flow of containers on the conveyor system. If a container must be diverted to several areas in the distribution center before it is ready to be putaway or shipped, RWMS only informs the sortation system of the next logical destination for the container. This way, the sortation system does not need to keep track of all divert instructions for a container. The first divert instruction for a container is sent when the container ID is first created on RWMS.
When the receiving allocation module creates a container, RWMS calculates a pallet group identifier in order to provide a palletization operator a quickly recognized code that helps to group cartons together on pallets. RWMS assigns a four-digit number to each PO/Item/Destination and concatenates this with the total number of cartons expected for the pallet group to make up the pallet group identifier.
The Container Divert Instruction Message Upload file has the following format:
The MMS uses the merchandise carton ID to form an Oracle Data Base Compliant (ODBC) query into the RWMS data base. This query gathers the information necessary for generating a shipping label and manifesting the carton.
Merchandise, planned and picked, using the logic currently implemented in RWMS, is first taken to a shipping station. Each shipping station is a PC running a MMS with interfaces to a user interface terminal and often to a scale.
The label applied by the RWMS picker is then scanned to retrieve the carton ID necessary for the ODBC query.
When containers are shipped through third party system, it is communicated back to RWMS with the Shipping Carrier, Carrier Service, Container Tracking ID and Shipment Number for the container.
RWMS then processes the container to Manifest (M) status and populates the container data with Carrier, Carrier Service, Container Tracking ID and Shipment Number. RWMS also processes the BOL data as though the container was manually loaded to a trailer through the RWMS RF Load Container screen.
When the MMS carrier service trailer(s) is closed (shipped), it is communicated to RWMS again, and RWMS processes it in a manner similar to RWMS Ship Trailer process.
Package for processing a container to Manifest status in RWMS when a request for the same has been triggered by the external manifest system.
The RWMS data base, which the MMS queries is through the MMS Container View.
The values in the CARRIER and SERVICE fields are set by the host system, or it could be blank. If the values are blank, the user must input data at the shipping station. The MMScan changes the values of CARRIER and SERVICE fields, even if the fields are not blank.
RWMS downloads the SHIP_TO_ADDRESS with the stock order. If this field is blank in the order download, the information is supplied by the SHIP_DEST table. The MMS can change the value of the SHIP_TO_ADDRESS, even if the field is not blank.
The format of the MMS Container view is as follows:
Table 5-17 MMS Container
| Field Description | Template | Description |
|---|---|---|
|
Facility ID |
X (2) |
Identifier for the facility |
|
Container ID |
X (20) |
Identifier for the container |
|
Carrier |
X (4) |
Carrier identifier |
|
Service |
X (6) |
Carrier service code for the delivery (such as First Class). |
|
Company Name |
X (241) |
Name of the company or store |
|
Name |
X (241) |
Name of the contact person |
|
Ship Address1 |
X (30) |
Shipping Address Line 1 |
|
Ship Address2 |
X (30) |
Shipping Address Line 2 |
|
Ship Address3 |
X (30) |
Shipping Address Line 3 |
|
City |
X (25) |
Shipping City |
|
State |
X (3) |
Shipping State |
|
Zip |
X (10) |
Shipping Zip |
|
Country |
X (3) |
Shipping country |
|
Phone |
X (20) |
Contact phone |
|
Note: A default value using nvl or decode statements should be supplied for any null values. |
RWMS interfaces with Rapistan through socket interfaces. RWMS still generates directives based on logical destination IDs associated to locations setup in RWMS.
For RWMS generated directives (message sent to the control system), a trigger calls stored procedures used in the socket interface for various message types. Different message types are generated depending on where the container is going in the facility due to data required by the control system. RWMS determines the message type and call the appropriate procedure.
For control system confirmations (message received from the control system), divert confirmations are sent to RWMS via stored procedures. Similar to the directive procedures, the upload confirmation procedures is created based on the message type sent from the control system.
|
Note: Sorter_dnls.sh script will load the data file and process it in RWMS. Process_diverts.sh does not load the data file but process the pre-loaded data in RWMS.The process_diverts_a.sh calls the database package, process_diverts.pkg. The sorter_dnld.sh calls the process_diverts_a.sql. In the upcoming release these scripts will be streamlined to call the common code base. |
This table is used for all container transactions from the control system to RWMS, including inbound, outbound, and movements within the facility.
Table 5-18 Table for Container Transactions
| Field Name | Field Type | Primary Key? | Req? | Description |
|---|---|---|---|---|
|
facility_id |
X (2) |
N |
N |
Facility identifier |
|
sorter_seq |
N (9) |
Y |
Y |
Sorting Sequence |
|
container_id |
X (20) |
Y |
Y |
RWMS container identifier |
|
logical_dest_id |
X (4) |
N |
Y |
Logical destination ID that relates to a location within RWMS. |
|
divert_type |
X (1) |
N |
||
|
divert_ts |
DATETIME |
N |
N |
Date/time stamp |
|
tracking_id |
X (25) |
N |
N |
Current field. |
|
pallet_id |
N (6) |
N |
N |
Rapistan pallet identifier. |
|
expected_cont_qty |
N (6) |
N |
N |
Number of cases on pallet ID. |
|
scale_weight |
N (4) v N (3) |
N |
N |
Scale weight |
|
Length |
N (4) v N (2) |
N |
N |
Measured length |
|
Width |
N (4) v N (2) |
N |
N |
Measured width |
|
Height |
N (4) v N (2) |
N |
N |
Measured height |
|
packer_id |
X (10) |
N |
N |
Populated for shipping cartons for audit purposes. |
|
ink_jet_message |
X (16) |
N |
N |
Textual message to be inkjetted on container. |
|
transaction_ts |
DATETIME |
N |
N |
Date/time stamp, transaction was processed. |
The third party routing interface determines the order in which outbound containers are picked and loaded onto trailers. The estimated cube and weight to be shipped for a given set of stores for a specified ship date is loaded into a file in RWMS for the third party routing system to process. The routing system then defines the routes used for that date and the order in which each store's stock is loaded onto trailers shipped that day. This information is then used in RWMS to determine the order in which outbound containers are picked so that they are loaded in the proper sequence.
Procedures and functions used to select stock orders based on user-defined criteria, calculate estimated weight and cube by ship destination, populate the Ship Cube Inquiry screen with the results, and generate a route data file used as input for the third party routing system.
Procedures used to read and process route information returned from the third party routing system and update stock orders with the carrier service route and ship date provided.
RWMS sends a file containing estimated weights and cubes for the ship destinations by stock order number for which picking and shipping occurs on a given ship date. This file is created in the Ship Cube Inquiry screen, and placed in the directory specified in the DOWNLOAD_DIR environmental variable.
Route data files created have the following naming convention:
route_data_facility ID_YYYYMMDDHH24MISS.dat
where Facility ID is the 2-character facility identifier and YYYYMMDDHH24MISS is a date time stamp from the point of creation. Multiple route data files may be created for a single ship date, though this is not a recommended practice.
The route data file has the format:
Table 5-19 Format of Route Data File
| Field Name | Field Type | Primary Key? | Req? | Description |
|---|---|---|---|---|
|
Dest_id |
X (10) |
Y |
Y |
Ship destination identifier. |
|
Distro_nbr |
X (10) |
Y |
Y |
Stock order identifier. |
|
Total_cube |
N(10)V(2) |
N |
N |
Total cube for destination ID in the stock order. |
|
Total_weight |
N(9)V(3) |
N |
N |
Total weight for destination ID in the stock order. |
|
Ship_date |
YYYYMMDD |
Y |
Y |
Date stock is to be picked and shipped. |
|
Order_cube_UDA1 |
X(10) |
N |
N |
User defined attribute. |
|
Order_cube_UDA2 |
X(10) |
N |
N |
User defined attribute. |
|
Order_cube_UDA3 |
X(10) |
N |
N |
User defined attribute. |
|
Order_cube_UDA4 |
X(10) |
N |
N |
User defined attribute. |
The files created by the third party routing package are placed in a directory named by the UNIX environment variable UPLOAD_DIR. The files are named with any set of numbers or characters as a prefix, but must end with the following character strings:
Table 5-20 File Format
| File | File Naming Conventions |
|---|---|
|
Distro Route Upload |
…distro_route.dat |
|
Carrier Service Route Upload |
…carrier_service_route.dat |
|
Route Date Upload |
…route_date.dat |
|
Route Dest Upload |
x |
Multiple files named with different prefixes may exist for a single data type (for example, 001_route_dest.dat, 002_route_dest.dat). RWMS processes spool data from the routing files into corresponding upload tables, then each file processed is renamed with an extension of .baknnn, where nnn is a UNIX session ID.
There are no interdependencies across the four routing upload files. Any or all of them may exist in the upload directory and processed at the same time.
The distribution route data file contains the ship date, carrier, service, and route codes to assign to a given stock order. The carrier service route must be a valid entry in the carrier_service_route table in RWMS.
Table 5-21 Distribution Route Data File
| Field Name | Field Type | Primary Key? | Req? | Description |
|---|---|---|---|---|
|
Facility_id |
X(2) |
N |
Y |
Facility identifier |
|
Transaction_ts |
YYYYMMDDHH24MI |
N |
N |
Date time stamp |
|
Distro_nbr |
X (10) |
N |
Y |
Stock order identifier |
|
Carrier_code |
X(4) |
N |
Y |
Carrier identifier |
|
Service_code |
X(6) |
N |
Y |
Service identifier |
|
Route |
X(10) |
N |
Y |
Route identifier |
|
Ship_date |
YYYYMMDDHH24MI |
N |
Y |
Date stock is to be picked and shipped. |
|
Distro_route_UDA1 |
X(10) |
N |
N |
User defined attribute |
|
Distro_route_UDA2 |
X(10) |
N |
N |
User defined attribute |
|
Distro_route_UDA3 |
X(10) |
N |
N |
User defined attribute |
|
Distro_route_UDA4 |
X(10) |
N |
N |
User defined attribute |
|
Distro_route_UDA5 |
X(10) |
N |
N |
User defined attribute |
|
Dest_id |
X(10) |
N |
N |
Store or DC dest id |
|
Item_id |
X(25) |
N |
N |
Item id/code |
The carrier service route data file contains carrier service route combinations are stored in the RWMS carrier_service_route table. Carrier code and route must be valid entries in the carrier and route tables in RWMS respectively.
Table 5-22 Carrier Service Route Upload
| Field Name | Field Type | Primary Key? | Req? | Description |
|---|---|---|---|---|
|
Facility_id |
X(2) |
Y |
Y |
Facility identifier |
|
Transaction_ts |
YYYYMMDDHH24MI |
N |
N |
Date time stamp |
|
Carrier_code |
X(4) |
Y |
Y |
Carrier identifier |
|
Service_code |
X(6) |
Y |
Y |
Service identifier |
|
Route |
X(10) |
Y |
Y |
Route identifier |
|
Location_id |
X(12) |
N |
N |
Optional location ID where containers for this carrier service route are staged for loading. |
The route date upload file contains routes and the order in which they are picked and loaded for a given ship date. If a route coming from the third party routing system is not already defined in the RWMS route table, an entry in this table is created for it.
Table 5-23 Route Date Upload File
| Field Name | Field Type | Primary Key? | Req? | Description |
|---|---|---|---|---|
|
Facility_id |
X(2) |
Y |
Y |
Facility identifier |
|
Transaction_ts |
YYYYMMDDHH24MI |
N |
N |
Date time stamp |
|
Route |
X(10) |
Y |
Y |
Route identifier |
|
Ship_date |
YYYYMMDDHH24MI |
Y |
Y |
Shipping date for which route sequence applies. |
|
Route_sequence |
N(3) |
N |
N |
Sequence in which the route is loaded with other routes for the same day. |
The route destination upload file contains all of the ship destinations for a given route and the order in which they are loaded onto a trailer. The route and destination ID values must be valid in The RWMS route and ship_dest tables respectively.
Ship date is a required entry for each record in the route destination upload file. A default value of 01-Jan-1900 (190001011200) may be used for static route destination sequences that do not change from day to day. Ship destination sequences loaded for any other date are valid only for that ship date.
Table 5-24 Route Destination Upload File
| Field Name | Field Type | Primary Key? | Req? | Description |
|---|---|---|---|---|
|
Facility_id |
X(2) |
Y |
Y |
Facility identifier |
|
Transaction_ts |
YYYYMMDDHH24MI |
N |
N |
Date time stamp |
|
Route |
X(10) |
Y |
Y |
Route identifier |
|
Dest_id |
X (10) |
Y |
Y |
Ship destination identifier |
|
Ship_date |
YYYYMMDDHH24MI |
Y |
Y |
Shipping date for which load sequence applies. |
|
Load_sequence |
N(3) |
N |
N |
Sequence in which the containers for a given destination ID are loaded with other ship destinations in the same route. |
