282438
DHL C-TMS
X-Dock Loading New Business Requirements
FUNCTIONAL SPECIFICATION - 10.6
09/10/2010 - 2.1
Reference: 282438 AS-8ACH8L
Client Requirement
To change the Cross-Dock Loading function to allow users to commence trip loading even though not all product due for delivery that day or previous is available in the despatch lane assigned to that trip.
Users should enter the trip number or scan the trip barcode to commence loading for that trip, despatch lane to load from is displayed on screen but no location scan is required to move forward.
Scan trailer barcode (location in WCS as type 'trailer' and this update C-TMS trip with the trailer to be used).
System shows first store to load. Ensure that outbound trips are loaded in reverse drop sequence order.
User scans items for first store to be loaded and once complete user presses F1 to soft close.
At this point the system gives a message to advise more product is expected to be loaded for that store according to the DUs on site or on trips which have not been received yet. If the user wishes to proceed short for the drop a supervisor override is required.
The system then proceeds to the next drop.
Once the last store load is completed trip can be hard closed or user can reopen a store drop to add additional DUs for that store drop.
At hard load closure user is asked to specify reason code for all missing DUs (missing equates to DUs on site). The user should be given the opportunity to scan these DUs onto the load before closing down.
If the load is being closed down with DUs missing for whatever reason a supervisor override is required.
At this point DUs loaded are set to location ‘shipped’.
Further requirement is to allow despatch units to loaded against a trip regardless of it’s current status and provided it is for a valid store and is either manifested, receipted, or pending despatch via a different trip.
The business require flexibility to load outbound any despatch unit, provided the outbound load trip matches the corresponding store and the despatch unit (DU) is known (manifested, receipted, pending on different trip, in grid, sinbin etc).
If the DU is part of a multiple DU’s on a single OMS reference, a new OMS reference will need to be created and the DU moved accordingly.
If subsequent DU’s for the same order are moved, the same newly created OMS reference can be used as per the inbound functionality.
All rules governing load sequence and load shortage must be maintained as per current functionality.
Non conformance will profile information to show that the DU has been loaded against a different trip if necessary or was not originally planned.
The Driver Trip Sheet will reflect any additional DU’s scanned that were not originally planned. (including backup sheet)
As the financial part in the C-TMS is retained at the purchase order level, a method must be agreed to ensure that the revenue generated is reflective and accurate.
A thorough impact assessment for this change should be carried out and corresponding recommendations provided
Solution
Receipting (background information).
As each DU is receipt scanned, the WCS application sends an update message to C-TMS (831). This message confirms the receipt of the DU into the X-Dock. Currently, if the PO relating to the DU is planned for delivery and a despatch bay assigned to the delivery trip, the DU is immediately updated to be located in the despatch lane. This logic is in place to ‘ready’ the loading function and will be retained until the revised ‘moves’ logic is implemented within the X-Dock. In the circumstance where the related PO is not planned for delivery, or if planned and a despatch lane not assigned to the trip, the DU is located to GRID.
Advising WCS of load DUs available.
Immediately that a DU is set into a despatch location (typically by the receipt scan described above, but could be manual update in TMS), the DU will be interfaced from C-TMS to the WCS database to instruct WCS that the DU is available for loading once loading is commenced.
This DU available for loading message generated by C-TMS (441) will send a transaction for each DU showing the message type, date and time stamp, depot, delivery trip id (if planned), order number(consignment), store number, unique DU id and DU type.
The trigger to send this message will be the assignment of a despatch lane to the DU in C-TMS. This despatch lane can be set in different ways as follows;
Automatically by receipt scan
Manually DU by DU if releasing from GRID or SINBIN (updating the DU in the order items screen)
Automatically by setting a despatch lane against a delivery trip in C-TMS
Point 1 and 2 are explained in the narrative above.
A new function will be developed to process point 3. When a despatch lane is assigned to a trip, C-TMS will check that all the DUs planned on the trip that have been received and are in GRID or released from QC are updated to the matching despatch lane location. Released from QC means the consignment QC field is unchecked but the associated DUs are located in QC area. Immediately that the despatch lane location is set on the individual DU’s they will be interfaced to WCS as DUs available to load as described above.
Despatch Lanes and Loading Management
A new form will be developed in C-TMS that will allow quick assignment of despatch lanes to trips and will allow trips to be released for loading.
The form will list all the delivery trips on screen for a schedule. Each row of the screen will be each delivery trip sequenced in planned despatch time order. The display will show the trip number, planned time of despatch, carrier or own fleet, driver, tractor and destination store(s). A column will allow quick entry of the despatch lanes for each trip. It is anticipated that the despatch lanes will be assigned a.m. each day the day before despatch. This means the despatch lanes are assigned for the delivery loading ahead of receipting product into the X-Dock.
The same form will be used to assign trailer numbers and release trips to be available for loading. The function to release trips for loading will be a simple check box (tick box). It is assumed that operationally, each trip will be released for loading at an appropriate time as sufficient product is available in the despatch lanes. Important to note that this ‘start loading’ decision will be purely operational and scan loading can commence, once the trip is released for loading, before all receipts are complete and before all DUs have found their way to the appropriate despatch lane.
For own fleet resourced trips, it will be mandatory to have assigned a trailer number to the trip in C-TMS using the Loading Management Form before the trip can be released for loading. The trip must be in a status ACCEPTED.
Releasing the trip for loading in C-TMS will immediately send a new trip load message to WCS (442). This message will instruct WCS that scan loading can commence for the trip(s) released. The load message will contain message type, date and time stamp, depot, delivery trip id, planned despatch time, carrier (or own fleet), trailer, despatch lane, destination store(s) and planned arrival time at store(s).
WCS Message Handling (advise of DU and Load)
WCS will process 441 messages and create new DU transactions to ready the RDT system to scan each DU label. For each new trip identified in 441, a new trip header record will be created in pending status. Once the 442 trip message is received, the trip header record will be updated with the final trip resource and route (drops) information and trip despatch lane and the status will be set as loadable.
RDT User Interaction
The embedded flow chart describes the function process to be developed that governs the user interaction on the RDT devices.
In summary, the interaction with the user will function as follows;
User selects X-Dock loading from the RDT menu.
User scans trip from documentation or entered the trip number to load.
RDT shows the despatch lane to load from.
User scans trailer barcode or keys the trailer number if own fleet else keys the subcontractor code to identify the correct unit.
RDT starts main load pass for last store drop (loading in reverse sequence) and shows loading store XXXXXX.
User scans each DU for the store and a list of scanned items builds up on the RDT screen.
The RDT will show an expected list reducing as the scanning process proceeds based on what WCS knows is available to load.
User completes store load by function key. If DUs left for store the RDT displays the list of DUs left. User can continue to scan or function key again to move to next store.
The process repeats for the next store until all stores complete.
The RDT then offers the user the chance to scan any additional DUs now in the despatch lane and these can be scanned regardless of which store destination so long as the store is a destination of the trip.
User completes final loading by function key and if any DUs left on site for the trip will require Supervisor password override. The supervisor will select a reason code for the missing DUs, then closes the load.
It is assumed that the user can identify damage using a function key and leave off a DU from the load accordingly.
The system will use the * notation in the DU lists on the RDT display to denote an item has been scanned onto the trip that wasn’t planned to be loaded.
WCS Scanning exceptions and processing rules
Clean scans of expected and planned DUs will be processed by WCS and a confirmation message sent to C-TMS. The points below define the scope of exceptions and the outcomes of scans under the described circumstances.
A DU is scanned that is not recognised by WCS - the user will be informed to take to SINBIN.
A DU is scanned that belongs to a store for the current trip being loaded but the user is loading a different store at that time – scan rejected, user advised to complete current store and come back to this DU later.
A DU is scanned that is for the current store being loaded but a different trip – scan is accepted so DU loaded but DU marked * on the RDT display. (the trip could be from prior day or a second trip for the store same day).
A DU is scanned that is for the current store but not planned for delivery (sched_coll status in C-TMS) – scan is accepted so DU loaded but DU marked * on the RDT display.
A DU is scanned that is for a different store not part of the current trip being loaded – scan is rejected, user asked to inform supervisor of DU in wrong despatch lane.
A DU is scanned that is for the current store but not planned (manifested and not scan received into the X-Dock) - scan is accepted so DU loaded but DU marked * on the RDT display.
WCS DU Load Confirmation and Load Close
WCS will generate a message to C-TMS for every recognised DU scan and final as the load is closed (841). This message will instruct C-TMS to process the loading event for each DU and process any left off DUs as the load is closed. The message will contain the message type, date and time stamp, depot, delivery trip id, order number (consignment), unique DU id, despatch lane, reason code and status code. The status code can be ‘Y’ meaning DU loaded or ‘D’ meaning DU damaged or ‘LC’ meaning load complete or ‘LE’ meaning loaded with exceptions.
C-TMS message handling and processing rules (incl. left off)
For DUs scanned successfully and loaded to the trip, the following processing will be required;
If a DU is loaded to the planned trip as expected, the DU will be updated with a positive reason code ‘SL’ successfully loaded and the item location will be cleared to null.
~If a DU is loaded to a different trip than expected (assuming the different trip is for the correct store destination), C-TMS will split the consignment. A new consignment will be created with the same PO, supplier and store destination with the unique DU identifier and this consignment will be allocated to the trip it was loaded onto. The original consignment, whether planned or not, will be updated to mark the DU as ‘X’ meaning DU moved to another consignment. This update maintains an audit trail to track how DUs were transferred from one consignment to another and the original trip they were planned to. Subsequent DUs of the same consignment scanned in the same circumstances will transfer to the new consignment and the original will be updated for audit trail accordingly.
If a DU is loaded to a trip that is from a consignment in an unplanned status, either not planned at all or planned for collection but not delivery, C-TMS will assign the full consignment to the trip the (first) DU was loaded to. If the consignment is in UNSCHEDULED status, this means additionally assigning to an inbound trip on the previous schedule for the supplier – this assumes the receipt automatically of the DU for the system. If the consignment is in SCHED_COLL status, the consignment is assigned to the delivery trip that the DU was loaded to.
Once a load is completed, C-TMS will receive a load complete message. This will contain either code ‘LC’ or ‘LE’ as mentioned above. The ‘LE’ exceptions code means that the trip load is complete and any planned items not loaded (physically still in the X-dock) will be processed as ‘left offs’.
By immediately splitting and creating SCHED_COLL orders leaves orders outstanding for planning which, depending on timing, could be exported to Paragon and planned for the wrong delivery day (+48 hours rather than +24 hours). It is proposed that a better solution is simply to leave the DUs left off associated and planned on the original delivery trip. The following day, when load scanned to an alternative trip, the split order functionality will process the DU and allocate it to the new trip on the next operational schedule as scanned. See the section noted ~ above.
A new system batch job will be developed that will run automatically each day and;
- Set a ‘failed to receive’ reason code for manifested collections not scanned into depot after 7 days has elapsed from planned collection trip
- Set a ‘failed to load’ reason code for deliveries receipted but not scanned out of the depot after 7 days has elapsed from the planned delivery trip
This system batch job is designed to close the tracking audit trail of manifested DUs either not received or not loaded after an operation week. Note that the 7 days elapsed will be a system parameter so can be easily varied depending on operation requirements.
Other Considerations and System Impact
The C-TMS to WCS DU receipt pre-advise message will be extended to allow C-TMS to send the destination store code of each DU. This will enable WCS to validate a load scan of an un-receipted item is for the correct store. Under this circumstance, WCS will allow the DU to be loaded and will clear the receipt pre-advise record as received.
Depending on the reason codes used, the interpretation of successfully loaded on trip sheet, extracts and Zetes might need minor change to accommodate. (i.e. ‘SL’ successfully loaded on plan, ‘XL’ successfully loaded unexpected trip and ‘OL’ successfully loaded off plan).
As with the receipt functionality, specifically splitting consignments, the original consignment will retain the planned qty and the new consignment will be created with planned qty 0.
Scope
This change will be applied to C-TMS system version 10.6.
Set-up
Pre-requisites
A running implementation of the revised X-Dock receiving functionality. Configuration of WCS master data in C-TMS to allow despatch lanes to be assigned to the transport schedule trip by trip.
System Registries
No new system registries are required to be implemented to support this development.
C-TMS Functional Description
The following sections cover the functional description of C-TMS change including the interface flows definitions between C-TMS and WCS.
New Load Message Formats (Pre-advise loading to WCS)
C-TMS will pre-advise the WCS access database of all DUs that have been received into the X-Dock. Once the operation decide to commence loading for a particular trip; the assumption being that by now, the trip is at PLANNED or ACCEPTED status, a despatch lane has been assigned to the trip, and a trailer type and trailer reference OR a carrier has been assigned to the trip, C-TMS will send a Trip Load Pre-advise to WCS.
This will enable load scanning and validation of the DU labels to the designated trip. The WCS will allow any scanned DU to be loaded to the trip providing that the DU store destination is a planned delivery point of the trip. This means any left off DUs from the previous delivery plan or any DUs received earlier than expected can be loaded to the current day trip.
The trip load pre-advise is designed to provide WCS with the trip header details such as loading despatch lane, trailer, carrier and store destinations and the sequence of drops.
The definition of the new loading messages is as follows:
DU Load Pre-advice (C-TMS to WCS), message code 441:
| Field | Type | Value | |
|---|---|---|---|
| Message_Type | Character | 441 | |
| Date_Time_Stamp | Character | Date/time in format YYYYMMDDHH24MISS | |
| Depot_Code | Character | NSC | |
| Trip_ID | Character | ST.TRIP_ID | |
| Consignment_No | Character | SO.OMS_REF | |
| Store_No | Character | SO.TO_LOC | |
| Item_ID | Character | SOI.ITEM_IDENTIFER | |
| UOM | Character | SOI.DU_TYPE | |
| Description | Character | SOI.ITEM_DESCRIPTION | |
| Item_AKA | Character | SOI.ITEM_AKA |
Trip Load Pre-advice (C-TMS to WCS), message code 442:
| Field | Type | Value | |
|---|---|---|---|
| Message_Type | Character | 442 | |
| Date_Time_Stamp | Character | Date/time in format YYYYMMDDHH24MISS | |
| Depot_Code | Character | NSC | |
| Trip_ID | Character | ST.TRIP_ID | |
| Location | Character | ST.BAY_NUMBER | |
| Location_CD | Character | WL.LOCATION_CD | |
| Trailer_ID | Character | STS.TRAILER_ID | |
| Carrier_ID | Character | ST.CARRIER_ID | |
| Store_Array_No | Character | STS.LOCATION_ID | |
| Store_Array_Name | Character | GL.LOCATION_NAME | |
| Store_Array_Arrive | Character | STS.ARRIVE |
Note that the ‘store array no’ field is a list of stores for delivery on the trip plan and will be formatted as a comma separated list of store numbers in drop number sequence.
Similarly, the ‘store array name’ field is a list of stores for delivery on the trip plan and will be formatted as a comma separated list of store names in drop number sequence.
The ‘store array arrive’ field is a list of planned arrival times at the stores formatted as YYYYMMDDHH24MI.
As a result of the load scanning and validation in WCS and finally the loading closure of a trip, the following update message will be generated by WCS for C-TMS to process.
DU Load Scanned (WCS to C-TMS):
| Field | Type | Value | |
|---|---|---|---|
| Message_Type | Character | 841 | |
| Date_Time_Stamp | Character | Date/time in format YYYYMMDDHH24MISS | |
| Depot_Code | Character | From incoming message | |
| Trip_ID | Character | From incoming message | |
| Consignment_No | Character | From incoming message | |
| Item_ID | Character | As scanned | |
| Location | Character | Despatch Bay | |
| Status Code | Character | ‘Y’ or ‘LC’/’LE’ | |
| User_ID | Character | User doing the task |
Note that the ‘status code’ will be set to ‘Y’ for each DU loading confirmation transaction OR to ‘D’ if the DU is designated damaged on the RDT; a damaged DU is expected to be moved to SINBIN and not loaded to the trip.
The same format message will be used to confirm load completion and the ‘status code’ then will be set to either ‘LC’ meaning load completion or ‘LE’ meaning loaded with errors or discrepancies.
Creating the Loading pre-advise 441 message - SOI Trigger
The C-TMS to WCS pre-advise of DUs available to be loaded will be automatic and based on a trigger coded to detect the change of the DUs location being a valid despatch lane. This trigger will automatically generate a 441 message as described above.
There are in principle, three system events that will result in the despatch lane being set for a DU:
Despatch lane automatically set as a result of receipt scan of DU while unloading the inbound trips; this assumes the despatch lane of the corresponding delivery trip is set at the point of receipt scanning.
Despatch lane manually updated using C-TMS order screen.
Despatch lane set onto a trip, this has the effect of ‘pulling’ any DUs currently in GRID to the despatch lane systemically i.e. the DU location is set to the despatch lane for all DUs on the planned trip.
The new trigger will be created against the SCH_ORD_ITEMS table and will be called TRG_SOI_DESPATCH.
Whenever the CURRENT_LOCATION of a DU is changed the trigger will activate and first check to establish whether the new location value is a despatch lane from the WCS master data maintained in C-TMS.
The logic for this process is described as follows;
Loin the new location value for the DU to the WCS_LOCATION (WL) table using the DEPOT (SCH_ORD.GROUP_NAME obtained using the OMS_REF) and LOCATION_ID of the DU (SCH_ORD_ITEMS.CURRENT_LOCATION).
If the LOCATION_TYPE = ‘D’ this confirms the DU is assigned to a despatch lane.
The trigger process will then check the APP_REC table to see if the MESSAGE_TYPE of ‘441’ is currently active (ACTIVE = ‘Y’).
The process will then join through SCH_HAULAGE_ACTITIVITY (SHA), SCH_TRIP_STOP (STS) and SCH_TRIP (ST) to obtain the delivery trip information for the delivery leg (ST.LOCATION_ID = SO.TO_LOC) of the DU.
The process will then check that the trip is at a suitable status (‘PLANNED’ or ‘ACCEPTED’) before it will allow message to be sent.
The process will use the standard type declaration (see TYPE TY_WCS_ITEM_LOAD_PREADV in the new DP_RDT_FAST_LOAD package) for the 441 message to build up an outbound message in the correct format and to send it using the standard DP_WCS_IF.SEND_EDI_TO_WCS procedure.
| Field | Value |
|---|---|
| Message_Type | ‘441’ |
| Date_Time_Stamp | Date/time in format ‘YYYYMMDDHH24MISS’ |
| Depot_Code | SCH_ORD.GROUP_NAME |
| Trip_ID | ST.TRIP_ID |
| Consignment_No | SO.OMS_REF |
| Store_No | SO.TO_LOC |
| Item_ID | SOI.ITEM_IDENTIFER |
| UOM | SOI.DU_TYPE |
| Description | SOI.ITEM_DESCRIPTION |
| Item_AKA | SOI.ITEM_AKA |
Note that the message release function is NOT using the WCS_OUT_CONTROL table because the 441 message is defined at the same data level as the trigger (Item Level) and so it will have minimum/no effect on the interactive speed of processing.
Calls to SOI-Trigger
The trigger specified above will be invoked within C-TMS in one of three ways:
- Automatically as part of the unloading/receipting process.
- Manually changing the current location on the item to a despatch lane.
- Manually entering or changing the despatch lane on a trip to be a valid despatch lane.
These following sections described the three scenarios in more detail.
Existing Unloading / Receipting Processing
Immediately that an 831 message (new DU level unload scan) has been sent from WCS to C-TMS and processed successfully in C-TMS then a new 441 message (new load pre-advice message at DU level) will be generated so long as the DU belongs to an order (a PO) which is planned on a delivery trip, the trip is at an appropriate status and it also has a despatch lane code assigned to it.
No changes will need to be made to the DP_RDT_FAST_UNLOAD package as this function already determines the despatch lane on the delivery trip for the item being unloaded and populates the current location on the DU accordingly.
By automatically setting the current location on the DU to the corresponding despatch lane for the delivery trip then this will invoke the new trigger which in turn will send the ‘441’ message to the WCS access database.
Manual Change Location of a DU
Whatever the circumstance, usually representing manual intervention of some sort, if a user manually sets the current location of a DU into a despatch lane, this action will invoke the new trigger and send the ‘441’ message to WCS.
Manual Change to Despatch Lane on Trip
If the bay number is set to a despatch lane on delivery trips ahead of receipt unloading commencing, no action is required to generate the appropriate loading pre-advise to WCS from C-TMS. This will be totally automated based on the C-TMS detecting the current location change of the DU and the trigger code being invoked as described above.
If however some DUs have already been unloaded into the ‘GRID’ locations then these DUs will systemically need to be moved to the same despatch bay.
It process will join through all of the SCH_TRIP_STOP (STS) records link to all of the corresponding SCH_HAULAGE_ACTIVITY (SHA) records to get the OMS_REF and then join this to all of the corresponding SCH_ORD_ITEMS records selecting any that have ‘GRID’ in the CURRENT_LOCATION.
The process will then update all of these DUs to be located in the despatch lane specified and by doing so it will then invoke the new trigger code to send the ‘441’ messages to the WCS system.
A further functional check will be made to see if any of the items are currently in the quality control area but their corresponding order (SO.QUALITY_CHECK) has been un-checked (so the flag is no longer set to ‘Y’). This will be interpreted as QC released ready for delivery and the DUs will be assigned to the planned trip despatch lane.
The ‘Quality Control’ location will be obtained by obtaining the LOCATION_ID field from the WCS_LOCATION (WL) table for the DEPOT (ST.OWNING_DEPOT) with a
LOCATION_TYPE = ‘Q’.
If this is the case then the DUs will be assigned into the despatch lane and this update will immediately invoke the new trigger to send the ‘441’ messages to the WCS system.
Loading Management - Creation of Load Release message 442
A new C-TMS form will be developed called Loading Management to enable despatch lane assignment more easily and also to allow loading release messages to be sent to WCS as message code 442.
The form will be called from the menu system for authorised users. The user will select the trip schedule corresponding to the trips to be loaded on that shift. All the trips planned for store delivery will be displayed, one row per trip. The trips will be displayed sequentially in start time order so the earliest dispatches first in the list.
The user can highlight any trip using a mouse click and this will display all the corresponding PO’s planned for the trip showing the PO store destination on the right hand side panel.
The screen view below shows the proposed layout of the form. The Bay Number heading will be labelled Despatch Lane. Users will be able to quickly assign despatch lanes to each trip and a default will be available. This default will be offered based on a new field that will be added to the store location form. This will allow the normal despatch lane for a store to be defined. A column will be introduced to display the carrier (showing either a carrier code or own fleet as planned). A further column will be introduced to allow the trailer number for own fleet to be displayed and entered.
The Send Load Check heading will be labelled Release Loading. The Order panel on the right hand side of the form will display the POs and store destinations and a count of the DUs planned and the total RPE planned per PO and an overall total – this will give visibility of the forecasted planned load volume per trip.
The Release Loading check box will be used to send a ‘442’ message to WCS. One or many trips can be released for loading by setting the appropriate check boxes and updating the input.
An additional column will be included that will define the loading status of each trip and will display as PENDING, LOADING and LOADED. PENDING will be while waiting for a release loading message, LOADING once the release loading message sent and finally LOADED once the final 841 Load complete message is received by C-TMS from WCS.
A right click menu option will be added that will allow the Trip Sheet to be printed. This menu will allow the summary or the detail version to be printed (the detail version includes the store delivery manifest pages).
When creating and sending the trip 442 load release message, the function will firstly check the APP_REC table to see if the MESSAGE_TYPE of ‘442’ is currently active (ACTIVE = ‘Y’).
The process will check next that the trip is at the correct status to be sent (‘PLANNED’ or ‘ACCEPTED’) and that all of the required information (Despatch Lane, Carrier ID and for own fleet trips the Trailer ID) is populated.
The process will also derive a list of stores (STS.LOCATION_ID) that this trip is planned to deliver to by joining all of the STS records to GEO_LOCATION (GL) where GL.DEPOT = ‘BRANCH’ (i.e. only stores visited on this trip and not suppliers or RDC’s). These will be retrieved in STS.STOP_NO sequence so the message will advise WCS of the stop sequence and so the required loading sequence.
The data to be written to the 442 message and will be formatted to the layout based on the type declaration (see TYPE TY_WCS_TRIP_LOAD_PREADV in the new DP_RDT_FAST_LOAD package).
| Field | Value |
|---|---|
| Message_Type | 442 |
| Date_Time_Stamp | Date/time in format YYYYMMDDHH24MISS |
| Depot_Code | ST.OWNING_DEPOT |
| Trip_ID | ST.TRIP_ID |
| Location | ST.BAY_NUMBER |
| Location_CD | WL.LOCATION_CD |
| Trailer_ID | STS.TRAILER_ID |
| Carrier_ID | ST.CARRIER_ID |
| Store_Array_No | STS.LOCATION_ID (Comma separated array) |
| Store_Array_Name | GL.LOCATION_NAME (Comma separated array) |
| Store_Array_Arrive | STS.ARRIVE (Comma separated array) |
The 442 message will then be sent to WCS using the DP_WCS_IF.SEND_EDI_TO_WCS procedure.
Note that the message release function is NOT using the WCS_OUT_CONTROL table because the 442 message is defined at the same data level as the form (Trip Level) and so it will have minimum/no effect on the interactive speed of processing.
The Trip screens will be modified to remove the option to send the load check message or will need amending in line with all of the above changes.
Load Update Messages from WCS to C-TMS - Process 841
The WCS application and the user interaction with the RDT scanners will be used to manage and validate the loading of the trailers. The functionality and the user dialogue with the RDT screens is described later in this specification.
As each DU is scanned and loaded, update messages will be generated by the WCS application and sent to C-TMS.
The standard procedure DP_WCS_IF.RECVD_REC will be used in reading the WCS messages from the oracle advanced queue.
If the message type is ‘841’ then the package will be changed to call the new procedure PROCESS_841 from the new DP_RDT_FAST_LOAD package.
This new procedure will firstly break down the message into is appropriate parts as defined in its TYPE declaration TY_WCS_ITEM_LOAD_SCAN.
The function will firstly check what status code WCS is passing back to C-TMS.
The value of status will determine which of the 3 types of processing are required for the message; either a load confirmation (‘Y’), a damaged DU (‘D’) or a load completion (‘LC’ or ‘LE’).
Each of these response values will initiate a distinct update in C-TMS as follows;
Damaged DU
If the DU is updated as damaged on the RDT in WCS then it will not be loaded onto the delivery trip and instead will be moved into the ‘SINBIN’ location for the depot.
It function will check that the DU (ITEM_ID) provided by WCS exists uniquely in C-TMS (on SCH_ORD_ITEMS - SOI) and that it belongs to an order that is at the correct status (SCH_ORD.STATUS is ‘UNSCHEDULED’, ‘SCHED_COLL’ or ‘SCHEDULED’).
The ‘SINBIN’ location code will be derived by obtaining the LOCATION_ID field from the WCS_LOCATION (WL) table for the DEPOT (as received in 841 message) and LOCATION_TYPE = ‘S’ (SINBIN).
The DU (SOI record) will then be updated to set its CURRENT_LOCATION to be the obtained ‘SINBIN’ location.
An appropriate non-conformity record will be generated for the DU (SCH_ORD_ITEMS_REASONS) using a decoded reason (‘DL’ – ‘Damaged at Loading’ against the standard decode name ‘WCS_REASON_CODE’).
Load Confirmation – Loaded
When a DU is confirmed as having been load scanned then it will be updated as left the depot (by setting a blank value for the current location on each DU) and a positive non-conformity will be generated to denote successful loading.
This function will check that the DU (ITEM_ID) provided by WCS exists uniquely in C-TMS (on SCH_ORD_ITEMS - SOI) and that it belongs to an order that is at the correct status (SCH_ORD.STATUS is ‘UNSCHEDULED’, ‘SCHED_COLL’ or ‘SCHEDULED’).
C-TMS will detect whether each DU successfully loaded was loaded onto the planned delivery trip for the DU, a different trip for the DU either on the same schedule or a different schedule or was unplanned for delivery (UNSCHEDULED or SCHED_COLL status).
The function will join through SCH_HAULAGE_ACTITIVITY (SHA), SCH_TRIP_STOP (STS) and SCH_TRIP (ST) to obtain the trip information for the delivery leg (ST.LOCATION_ID = SO.TO_LOC).
Loaded on Planned Delivery Trip as expected
If the trip provided by WCS matches the planned delivery trip in C-TMS and the trip is at status ‘ACCEPTED’ then C-TMS will create a positive non-conformance (successfully loaded) for the DU using a decoded reason (‘SL’ - ‘Successfully Loaded’ against the standard decode name ‘WCS_REASON_CODE’) and blank the CURRENT_LOCATION on the DU as it is no longer in the depot.
Loaded on Different Delivery Trip to the one Planned
If the trip provided by WCS is not the same trip that C-TMS has the DU planned on for delivery then the function will check the status of both the trip provided by WCS (as loaded to) and the planned trip in C-TMS (Note that this will only occur when a DU is loaded early or on an alternative trip on the same schedule. If a DU it is loaded late due to being left off the previous delivery plan, then the DU will already have been split and the new PO order split made available at a SCHED_COLL status for subsequent loading – see Loading Unplanned sub-section below).
The original planned delivery trip could be at any status and the trip being loaded must be at status ’PLANNED’ or ‘ACCEPTED’. The function will validate that the delivery trip being loaded delivers to the store destination of the DU.
The order (that the DU belongs to) will then be split to enable the DU to be allocated by C-TMS to the alternate trip as load scanned. The original order will retain an audit record of the DU and the item identifier will be prefixed with ‘X’ very like the split functionality utilised in the X-Dock receiving functionality.
The split logic checks to see if the split for this order already exists on the delivery trip being processed with the same supplier manifest (BOOKING_REF), store (TO_LOC) and PO Ref (EXTERNAL_REF).
If the split already exists then the function will also check that the found order was collected and received on the same trip as the order that the item is being split from – this will retain the integrity of any previous order split initiated by the receiving functionality into the X-Dock.
If a new split order is created it will be automatically allocated to the same collection trip as the original order and allocated to the delivery trip currently being load scanned ( from the 841 message).
The function then adds the scanned DU to the new split order (which will be created with a blank CURRENT_LOCATION as the DU has been loaded already).
Note that the ordered quantity of split orders will be created as zero qty to keep consistent approach with the receiving functionality. The planned order qty always is retained on the original SAP orders.
Next, the function will create or update the corresponding order line (SCH_ORDER_LINE using DU_TYPE) to represent the number of items loaded. This update sets the ACTUAL_DESPATCHED_QUANTITY on the order line.
An audit record of the original DU prior to the split update will be created; the original DU will be updated to prefix ‘X’ the ITEM_IDENTIFIER and also blank the CURRENT_LOCATION, then
update any associated non-conformities to also add the ‘X’ on the ITEM_IDENTIFIER.
Then create an appropriate new non-conformity (‘ML’ - ‘ Moved to a different order at Loading’ against the standard decode name ‘WCS_REASON_CODE’ ) on the original DU to indicate that the DU was not delivered under the originally planned trip.
Create a positive non-conformance on the new DU (‘XL’ - ‘Successfully Loaded on a Different Trip to the one Planned’ against the standard decode name ‘WCS_REASON_CODE’).
Loaded when Unplanned
Loaded when unplanned is defined as if a DU is scanned and loaded that is currently part of order whose delivery leg is unplanned, so is either at ‘UNSCHEDULED’ or ‘SCHED_COLL’ status.
The update functionality will ensure that the delivery trip being loaded for the DU scanned visits the store destination for the DU.
If the order is at ‘UNSCHEDULED’ status (meaning not planned on a collection trip and arrived unexpectedly and not receipt scanned) then the DU will be automatically assigned to an appropriate collection trip. The function will select the most recent (before today) collection trip for the supplier and allocate the collection leg for the order onto this trip.
The function will create an unload non-conformity reason of ‘UL’ (‘Loaded not receipt scanned’ against the standard decode name ‘WCS_REASON_CODE’).
Note that to enable WCS scanning to validate loading a DU that has not been receipt scanned, a change will be made to allow the destination store to be added to the receipt pre-advise message; this additional field will be added to the existing 431 message.
The functionality will be based on an assumption that all of the DUs for a PO are going to be loaded on this delivery trip; so for the first DU scanned, the complete PO will be allocated to the delivery trip. Note that any DU’s not load scanned for a PO assigned to the delivery trip will be split as left offs as described earlier in this specification.
The update functionality will create a positive non-conformance for the item being loaded (‘OL’ - ‘Loaded not planned’ against the standard decode name ‘WCS_REASON_CODE’) and the CURRENT_LOCATION of the DU will be set as blank to denote left the depot.
Load Completion
Once the load is complete and designated as such by input into the RDT device, the final 841 update message will be sent and processed by C-TMS. The status provided by WCS will be either ‘LC’ or ‘LE’.
This message will update C-TMS and the status of the trip on the Load Management screen will change to loaded. A new loading status field will be added to the SCH_TRIP table with values PENDING, LOADING or LOADED.
Any DUs left off from loading will retain their current location in the despatch lane. When loading against a delivery trip on the following operational schedule day, the splitting functionality described in section 3.5.2.2 above will manage the allocation of the DU to the new trip.
Close DUs not Received or not Loaded
From the document reviews, it has been decided to remove this function from scope. If a DU is received late, it will need to be loaded and POD’d and invoiced.
Analysis of late and missing receipts and missing loading will be managed through extracts and reporting.
Electronic Manifest and Zetes POD
While not the subject of this specification and so out of scope of this development, comments are included below to position requirements and highlight development changes which will need to be agreed and implemented to facilitate processing Zetes POD.
C-TMS will release the electronic manifest to the Zetes store receiving system for each trip as the trip is set to EN-ROUTE status.
Zetes will send the same format message back to C-TMS with the POD scan information added and reason codes for any discrepancies found.
The Zetes upload processing will update the POD regardless of trip status, although users would still have to debrief the trip fully to facilitate invoicing.
It is possible that Zetes will send a POD for a DU not loaded. C-TMS should accept the POD and allow invoicing (assuming the trip is debriefed) regardless of the missing load scan. Following the logic already implemented for receiving and are developing for loading, if the POD is received from Zetes for a DU on a different trip than planned or even if the order is UNSCHEDULED or SCHED_COLL status, C-TMS will need to allocate the DU and PO and Order to the trip and split where necessary with appropriate reason codes. This all assumes Zetes have the functionality to scan DUs additional to what is advised in the electronic delivery manifest that C-TMS provides. Note that Zetes POD message has to be for a specific trip.
WCS Functional Description
This section documents the changes required to the X-Dock Loading function for the WCS application and RDT dialogue.
Notification from TMS
C-TMS will notify WCS that a DU is available for loading via a 441 message. This message will be sent as soon as the individual DU is ready for loading. The message will also include a list of the Stores to be visited on the specific Trip on which the DU is due to be loaded. The layout of the 441 message is as follows:
Message 441
| Field | Type | Length | Value |
| Message_Type | Character | 3 | 441 |
| Date_Time_Stamp | Character | 14 | Date/time in format YYYYMMDDHH24MISS |
| Depot_Code | Character | 12 | Depot Code |
| Trip_ID | Character | 12 | Trip ID |
| Consignment_No | Character | 20 | Consignment Number |
| Store_No | Character | 12 | Store Number |
| Item_ID | Character | 12 | Item ID (DU) |
| UOM | Character | 12 | Unit of measure (DU Type) |
| Description | Character | 70 | Description |
| Item_AKA | Character | 30 | Alternative description |
WCS will process this message and create a new record on the TMS_Load_Detail table as follows. Note that the Header_ID column will initially be unpopulated.
TMS_Load_Detail
| Name | Type | Length | Value |
|---|---|---|---|
| ID | Autonumber | ||
| Header_ID | Number | Long | |
| Store_No | Character | 20 | From 441 msg |
| Consignment_No | Character | 20 | From 441 msg |
| Drop_Sequence | Number | N/A for XDOCK phase 2, but retained for backward compatibility. | |
| Item_ID | Character | 20 | From 441 msg |
| UOM | Character | 12 | From 441 msg |
| Description | Character | 70 | From 441 msg |
| Status_Flag | Character | 2 | “P” = “Pending” |
| Terminal_ID | Character | 20 | |
| Depot_Code | Character | 12 | From 441 msg |
| Trip_ID | Character | 12 | From 441 msg |
When a trip is released for Loading in TMS a 442 message will be sent to WCS. WCS will process this message, creating a record on the TMS_Load_Header table. This will also update the related records on the TMS_Load_Detail table, setting the value of the Header_ID column to the ID from the TMS_Load_Header record.
442 message
| Field | Type | Length | Value |
| Message_Type | Character | 3 | 442 |
| Date_Time_Stamp | Character | 14 | Date/time in format YYYYMMDDHH24MISS |
| Depot_Code | Character | 12 | NSC |
| Trip_ID | Character | 12 | Trip ID |
| Location | Character | 12 | Bay Number |
| Location_CD | Character | 3 | Bay Number check digit |
| Trailer_ID | Character | 12 | Trailer ID |
| Carrier_ID | Character | 12 | Carrier ID |
| Store_Array_No | Character | 100 | Comma separated list of store numbers |
| Store_Array_Name | Character | 200 | Comma separated list of store names |
| Store_Array_Arrive | Character | 200 | Comma separated list of store arrival times |
Note that the ‘store array no’ field is a list of stores for delivery on the trip plan and will be formatted as a comma separated list of store numbers in drop number sequence.
Similarly, the ‘store array name’ field is a list of stores for delivery on the trip plan and will be formatted as a comma separated list of store names in drop number sequence.
The ‘store array arrive’ field is a list of planned arrival times at the stores formatted as YYYYMMDDHH24MI.
TMS_Load_Header
| Name | Type | Length | Value |
|---|---|---|---|
| ID | Autonumber | ||
| Depot_Code | Character | 12 | From 442 msg |
| Trip_ID | Character | 12 | From 442 msg |
| Departure_DateTime | Date Time | N/A for XDOCK phase 2, but retained for backward compatibility. | |
| Marshall_Bay | Character | 12 | Location from 442 msg |
| Marshall_Bay_CD | Character | 3 | Location_CD from 442 msg |
| Status_Flag | Character | 2 | ‘C’ – implies Load Checking has been completed for this Trip and it is ready for Loading |
| DateTime_Received | Date Time | Set to current date & time | |
| Terminal_ID | Character | 20 | |
| Trailer_ID | Character | 12 | From 442 msg |
| Carrier_ID | Character | 12 | From 442 msg |
Additionally, processing of the 442 message will create a set of records on the new TMS_Load_Trip_Store_XRef table. A record will be created on this table for each store that is to be visited on the trip, according to the 442 message. If a record already exists for the given Trip_ID / Store_No then the record will be updated with the Store_Planned_Arrival_Time from the 442.
TMS_Load_Trip_Store_Xref
| Name | Type | Length | Value |
|---|---|---|---|
| Header_ID | Number | Long | From TMS_Load_Header |
| Store_No | Character | 20 | From 442 msg |
| Store_Name | Character | 30 | From 442 msg |
| Store_Planned_Arrival_Time | Date/Time | From 442 msg |
There is also a change to the 431 message layout to include the Store_No on the Order pre-advice. This will require a change to the layout of the TMS_Receipt_Detail table.
431 message
| Field | Type | Length | Value |
|---|---|---|---|
| Message_Type | Character | 3 | 431 |
| Date_Time_Stamp | Character | 14 | Date/time in format YYYYMMDDHH24NNSS |
| Depot_Code | Character | 12 | NSC |
| Supplier Code | Character | 12 | LOV01 |
| Consignment_No | Character | 12 | OMS Ref |
| Order_No | Character | 20 | External Ref |
| Item_ID | Character | 20 | Item ID |
| UOM | Character | 12 | DU Type |
| Description | Character | 70 | Desc |
| Item_AKA | Character | 30 | Item_AKA |
| Store_No | Character | 12 | Store Number |
TMS_Receipt_Detail
| Name | Type | Length | Value |
|---|---|---|---|
| ID | Autonumber | ||
| Header_ID | Number | Long | |
| Consignment_No | Character | 20 | From 431 msg |
| Item_ID | Character | 20 | From 431 msg |
| UOM | Character | 12 | From 431 msg |
| Description | Character | 70 | From 431 msg |
| Item_AKA | Character | 30 | From 431 msg |
| Status_Flag | Character | 2 | “P” = “Pending” |
| Terminal_ID | Character | 20 | |
| Depot_Code | Character | 12 | From 431 msg |
| Receipt_Bay | Character | 12 | |
| Receipt_DateTime | Date/Time | Timestamp of receipt of message from TMS | |
| Store_No | Character | 12 | Store Number |
Loading Process
The loading process will begin with the operator selecting “X-dock Load” from the RDT main menu. A new depot level rule will be introduced to determine whether the original version or the new version of this function is to be used.
In the new version of the function, the first action will be an automated deletion of records from the TMS_Load tables that are over a given age. The time period will be specified by a depot-level rule.
A check will be made to ensure that there are trips available for Loading. If there are no trips available then the message “No trips available for loading” will be displayed on the RDT.
If there are trips available then the user will be prompted to scan the trip number. This will be validated to ensure that it is loadable, i.e. that a 442 message has been received for the trip. If the trip is not loadable then the message “Trip not loadable” is displayed on the RDT.
If the trip is loadable then the RDT will display the Despatch Lane to load from. It is no longer necessary for this to be scanned on the RDT and, therefore, does not need to be validated.
The RDT will prompt the user to scan the trailer barcode or enter the subcontractor code. This will be validated against the trailer sent on the 442 message and, if incorrect, the message “Incorrect trailer” will be displayed on the RDT.
If the trailer barcode is correct then the message “Start loading store XXXX (n of m)” will be displayed on the RDT, where:
- n is the relative position of the store in reverse drop sequence, determined by the Store_Planned_Arrival_Time column on the TMS_Load_Trip_Store_Xref table.
- m is the total number of stores on the trip.
The RDT will then prompt the user to scan DU’s. When a DU is scanned one of the following actions will take place.
Scenarios when scanning an item
| No. | Scenario | Action |
| 1. | DU is expected on the current trip and for the current store. | The item will be marked as loaded, setting Status_Flag to ‘D’ on TMS_Load_Detail. An 841 message will be sent to TMS with a status code of ‘Y’. |
| 2. | DU is expected on the current trip, but not for the store currently being loaded. | The message “Item not for store XXXX” will be displayed on the RDT. |
| 3. | DU is not expected on the current trip but is destined for the current store being loaded. | The item will be marked as loaded, setting Status_Flag to ‘D’ on TMS_Load_Detail. An 841 message will be sent to TMS with a status code of ‘Y’. |
| 4. | DU is not expected on the current trip and is not destined for the current store being loaded. | The message "Item not for a store on this trip" will be displayed on the RDT. |
| 5. | DU has already been loaded onto the current trip. | The message “Item already loaded” will be displayed on the RDT. |
| 6. | DU has already been loaded onto a different trip. | The message “Item already loaded on trip XXX-00000000” will be displayed on the RDT. |
| 7. | DU is not available for loading, i.e. a 441 message has not been received, but a 431 message has been received for the DU and the Store_No on the 431 matches the store currently being loaded. | The item will be marked as loaded, setting Status_Flag to ‘D’ on TMS_Load_Detail. An 841 message will be sent to TMS with a status code of ‘Y’. If the item currently has a status of ‘P’ on TMS_Receipt_Detail then this will be updated ‘D’. |
| 8. | As per 7, but DU is destined for a store on the trip, not the one currently being loaded. | The message “Item not for store XXXX” will be displayed on the RDT. |
| 9. | As per 7, but DU is not destined for any of the stores on the current trip. | The message "Item not for a store on this trip" will be displayed on the RDT. |
| 10. | DU is not available for loading, i.e. a 441 message has not been received. Additionally, a 431 message has not been received. | The message “Unknown item” will be displayed on the RDT. |
If an item is damaged this can be indicated by pressing the F2 key on the RDT prior to scanning the item. An 841 message will be sent to TMS with a status code of ‘D’ indicating that the DU is damaged. The message “Take damaged item to Sin Bin” will be displayed on the RDT. The item will be marked as processed, setting Status_Flag to ‘D’ on TMS_Load_Detail.
As items are scanned they are added to the list of scanned items displayed on the RDT, as shown in the example below. Items that were not expected on the current trip but can be loaded because they are destined for the current store being loaded (scenario 2 in the table above), are prefixed with a “*” in the list.
Sample screen showing items scanned
Whilst scanning items the user will have the option to press F1 to close loading for the current store. When this occurs a check will take place to determine whether there are any additional items expected for the current trip / store (i.e. whether any further 441 messages have been received). If this is the case then a summary of the missing items will presented to the user on the RDT, as per the example below.
Summary of missing items
The user has the option to press F1 to confirm that loading is complete for the current store with items missing. Alternatively, they can press ESC to continue scanning items for the current store. They also have the option to press F5 to display a detailed list of the missing items as per the example below.
Detailed screen showing missing items
On this detailed screen the user still has the options to press ESC to continue scanning items for the current store or press F1 to confirm that loading for the given store is complete. F5 will toggle back to the summary screen.
Once loading for a store has been completed a check will be made to determine whether there are further stores to be loaded on the trip. If so then the message “Start loading store XXXX (n of m)” will be displayed on the RDT and the process described above will be repeated.
Once loading of all stores has been completed a summary list of all missing items for the trip is displayed on the RDT, showing the number of missing items for each DU Type. The F5 key can be used to toggle between this summary list and a detailed list, which will display the full Item ID for each missing item.
The user will have the option to press either F1 to close the trip or F2 to scan additional DUs. This will be the case even if there are no missing DUs, allowing additional DUs to be loaded onto the trip if they are destined for one of the stores on the trip.
If F2 is selected then the RDT will allow the user to start scanning items as described previously. It will be possible to load DUs for any of the stores on the trip at this point. Rather than displaying the Store number the RDT will show “FINAL SCANS”. As items are scanned they will be validated to ensure that they are destined for one of the stores on the current trip. If valid, the DU will be added to list displayed on the RDT. The user has the same function key options as before; F2 to scan a damaged item and F1 which, in this case, is to complete loading of the trip.
If F1 is selected the RDT will prompt for the Supervisor Override password. Once the supervisor has entered the override password then, if there are still any outstanding DUs for the trip, a message will be displayed on the RDT requesting the supervisor to select a reason code for the missing DUs. A list of available reason codes will then be displayed on the RDT allowing the Supervisor to enter the correct code. This list will be generated from a rule stored on the WMS database. Only one reason code will be entered per trip.
Once the Supervisor has closed the trip, the message “Loading of trip XXX-00000000” is displayed on the RDT and a final 841 message is sent to TMS. The Status Code on this message will either be ‘LC’, meaning load completed, or ‘LE’, meaning ‘LE’, meaning loaded with exceptions, if there were missing DUs on the trip. The Item_ID will be empty on the final 841 message.
841 message
| Message_Type | Character | 841 | ||
| Date_Time_Stamp | Character | Date/time in format YYYYMMDDHH24MISS | ||
| Depot_Code | Character | From incoming message | ||
| Trip_ID | Character | From incoming message | ||
| Consignment_No | Character | From incoming message | ||
| Item_ID | Character | As scanned | ||
| Location | Character | Despatch Bay | ||
| Status Code | Character | Valid values:
‘D’ – damaged item sent to Sin Bin ‘LC’ – trip load completed ’LE’ – trip loaded with exceptions
| ||
| User_ID | Character | User doing the task |
Document History
| Initial version | ||||
| New 442 Message and other changes | ||||
| Merge C-TMS and WCS and review | ||||
| Revised Left Off processing and mark missing scans as failed after 7 days elapsed. | ||||
| Remove batch job to mark late receipts, comments regarding Zetes and PODs, add printing Trip Sheets from Load Management |
AUTHORISED BY
| Matt Crisford | Development Manager | |
| Dave Meir | C-TMS Product Manager |
