285987

DHL MTS

WCS Loading & Unloading

FUNCTIONAL SPECIFICATION - 10.6

- 1.0

Reference: FS 285987 AD-8DYG8J

Client Requirement

Change Request Summary:

Develop loading and unloading functionality within the WCS solution. Antony Truin / Daventry/UK/Exel

Change Request Details:

Develop loading and unloading functionality within the WCS solution. Reference section 3 in BRD version 3.1.

Solution

Introduction

The Auto Alliance loading and unloading solution will be based on and where possible will take the same functionality as implemented in the DHL Dunelm Leicester X-Dock.

The implementation will build on the WCS C-TMS integration already implemented in Auto Alliance to support scan based creation of orders, specifically the allocation of cages to transport orders generated onto daily route schedules in C-TMS.

Functional Overview

The loading and unloading solution will integrate into the systemised transport process.

Deliveries to Dealerships - Once transport orders are generated from the standard planning templates and cages and loose items scanned, labelled and assigned; the cages and loose items will be made available for loading for despatch from the origin warehouse. The cages and loose items will be load scan confirmed to the despatch vehicle (trip) and the load closed. If routed via a X-Dock location, the scanning solution will be pre-advised of the receipt of the cage or loose item at the X-Dock depot. When the vehicle arrives, the scanning solution will allow the cages and loose items to be tipped and positively received. The receipt will pre-advise the scanning solution for loading at the depot. Assuming a delivery plan (an outbound trip) is available for the transport order, the cage or loose item will be directly cross-docked to the appropriate despatch lane and once loading is released, a positive load scan will be made. Otherwise, the cage will be assigned to a generic GRID location until either the respective transport order is planned, or the cage or loose item is loaded to a delivery trip. The final delivery to dealership will be scanned on the Microlise HHT to confirm delivery and to POD.

Empty Collection – Microlise will support an ad-hoc collection by the driver. The integration with C-TMS will create a new empty collection transport order from the dealership location to the asset origin. The asset origin is referenced from the asset database (and will default if a new asset not known to C-TMS based on the dealer type). This transport order will automatically be assigned to the trip being executed and so retrospectively planned back into the return depot of the trip. The scanning solution will be pre-advised of the empty assets.

Once the trips returns to depot, the empty assets will be positively scanned into the depot. If the depot is the asset origin, operationally the empty asset will be taken back into stock. If a x-dock location, and an onward delivery plan is available for the trunk to the asset origin, the empty assets will be cross-docked directly to the appropriate despatch lane. Otherwise the empty asset will be position in a generic GRID location waiting onward planning or loading. The empty assets will then be loaded by a positive load scan and despatched to the final asset origin (perhaps via another X-Dock location). Once the vehicle arrives at the final asset location, the asset will be scan received into the depot and marshalled to stock.

Return Collection – The dealer will use the Dealership Portal functionality to pre-advise return collections. This input will create a transport order in C-TMS and will enable the dealer to generate a collection manifest and label the cages and or loose items. The collection transport orders will be planned in C-TMS and a corresponding pre-advice created in WCS. The return collection cages and loose items will be collected and as the vehicle returns to the depot, the cages and loose items will be receipt scanned into the depot. If the depot is the final destination of the collection transport order, the cages and loose items will be POD confirmed through C-TMS debrief; otherwise, the cages and loose items will be either directly cross-docked if a delivery plan for the transport order exists or else marshalled to a generic GRID location. Once a trunk plan is created in C-TMS and a trip available to load the return collection cages and lose items will be positively load scanned to despatch from the depot. The loading will pre-advise the receiving depot WCS and once the vehicle arrives the cages and loose items will be receipt scanned.

Delivery Process

Using a typical scenario of cages originating Milton Keynes and delivered to a dealership in Liverpool via Rochdale, the following process steps and functional components will support the operation

	Process Step	Narrative	Development Requirement
1	Trips generated from Fixed Schedule.	Creates Trips and Orders.
2	Cages and loose items scanned to (Liverpool) order and label created.	Order identified based current location and Liverpool dealership destination scanned or input. Item record created for the selected order.	New unique item no generated for every item to support systems integration with WCS. Asset id will be moved to AKA field.
2a	Pre-advise WCS for loading.	C-TMS sends a 441 pre-advice message to ready WCS for load scan.	441 message sending unique item no and asset id. Pre-advise is for loading to next location so Rochdale Depot (and not Liverpool).
3	Cage deleted.	Cages can be deleted if not used.
3a	Delete Pre-advise	C-TMS sends a deletion of pre-advise	New message or extension of 441 to delete loading advice items in WCS.
4	Load Management Screen used to assign despatch lane to trips to be loaded from depot.	Defines in system the despatch lane that cages and lose items will be loaded from per trip. As despatch lane is assigned, items are systematically assigned to that lane.	Support loading from mid-points on a trip (PKs). Loading at Dunelm is always the SU (1st location) of a trip. Operationally in AA, a trunk vehicle could load at a depot mid way through the trip.
4a	Load Management Screen used to release loading trip by trip.	Enables the loading of each trip on the WCS system, sends a 442
	Process Step	Narrative	Development Requirement
5	Dispatcher signs in to RDT to load trip (Rochdale Trunk).	Loading menu option on RDT
5a	Enter the trip number on RDT	Enter FIX- number from route schedule	Can scan trip number from trip sheet if required. Print trip number bar code on trip sheet.
5b	RDT dialogue takes user through reverse loading of trip.	Reverse loading based on delivery stops of trip.	Trunking depot destination in reverse sequence.
5c	Each item is scanned to confirm loaded.	WCS validates the scan is not a duplicate and that the item is for the correct destination. Once scanned successfully a load confirmation message 841 is sent to C-TMS. Pre-advice sent to WCS for receipting into Rochdale.	C-TMS processes successful load and if the order is being trunked to another depot will automatically create a receipting pre-advise for the destination depot. 841 message processed in C-TMS creates a receipt message back to WCS for next depot 431 where required.
5d	RDT dialogue, once all destinations complete, allows any final scans and close loading for the trip (Rochdale).	WCS finalises the load for the trip and sends an 841 loading complete message to C-TMS.
6	Trip Sheet Printed.	Driver briefed.	Consider printing trip sheet showing cages and items actually loaded rather than planned to load?
7	Trip set to EN-ROUTE as depart from Milton Keynes.	EN-ROUTE by Microlise geo-fence breaks or set manually in C-TMS. The EN-ROUTE event in C-TMS pre-advises WCS of trip arrival at Rochdale and sends a 432 messages that groups the items pre-advised in step 5c above. Enables Rochdale to receive the trunk trip.
8	Vehicle arrives Rochdale.
8a	Receipt bay identified.	Receipt bay scanned or entered on RDT and validated by C-TMS (821 from WCS and validation message 421 returned).
8b	Cages and Loose items scanned into X-Dock (Rochdale).	Item receipted by 831, invalid unrecognised scans by 832 and trip unload complete 833. Immediately received, C-TMS pre-advises WCS of loading pre-advice 441.
9	Items marshalled in X-Dock location (Rochdale).	Cages and loose items moved to GRID or directly to despatch lane if assigned
9a	Despatch lane assigned to delivery trip.	Load Management screen used to assign despatch lane ahead of, during or after receipt.
9b	Cages and Loose items physically moved to despatch lanes.
10	Trip released for Loading.	Load Management screen used to release trip for loading. C-TMS creates 442 message to WCS to allow loading.
11	Dispatcher signs in to RDT to load radial delivery trip (Including Liverpool Dealership).	Loading menu option on RDT
11a	Enter the trip number on RDT	Enter FIX- number from route schedule	Can scan trip number from trip sheet if required. Print trip number bar code on trip sheet.
11b	RDT dialogue takes user through reverse loading of trip.	Reverse loading based on delivery stops of trip. Delivery dealership destination in reverse sequence.
11c	Each item is scanned to confirm loaded.	WCS validates the scan is not a duplicate and that the item is for the correct destination. Once scanned successfully a load confirmation message 841 is sent to C-TMS.
11d	RDT dialogue, once all destinations complete, allows any final scans and close loading for the radial delivery trip including Liverpool Dealership.	WCS finalises the load for the trip and sends an 841 loading complete message to C-TMS.
12	Trip Sheet Printed.	Driver briefed.	Consider printing trip sheet showing cages and items actually loaded rather than planned to load?
13	Trip set to EN-ROUTE as depart from Rochdale.	EN-ROUTE by Microlise geo-fence breaks or set manually in C-TMS. If any collections on the radial delivery trip, the EN-ROUTE event in C-TMS pre-advises WCS of trip departure from Rochdale and sends a 432 messages that groups the items pre-advised for collection (see collection return process below).

Return Collection Process (for example Warranty Parts)

Using a typical scenario of loaded cages or return parts originating a dealership in Liverpool collection into Rochdale depot and x-docked to Milton Keynes (Mercedes), the following process steps and functional components will support the operation.

	Process Step	Narrative	Development Requirement
1	The dealership creates a return collection order using the Dealership Portal.	Collection Order created for network planning and RMA number generated.	Supplier Portal entry screen (see relevant RIO) allows dealership to create return collection order. The dealership location is associated to a final destination so for Liverpool Mercedes, the order is created final destination Milton Keynes.
1a	Cages and loose items assigned to return collection order by Liverpool Dealership. Collection labels printed.	Dealership labels each cage and loose item assigned to the collection return order.	Confirmation of return collection order in dealership portal updates C-TMS and C-TMS immediately pre-advises WCS of expected receipt into collecting depot creating a 431 message to WCS.
1b	Collection Manifest printed by Liverpool Dealership.	Dealership collection manifest generated from Dealership portal.	Collection Manifest format to be defined.
2	DHL Plan Collection Return Orders.	DHL Control Tower manually plan the Collection Return orders into the traffic plan. Assume that collections will be added to appropriate radial delivery trips.	Consider whether the portal displays the collection plan so dealership knows what day and time to release the return cage and loose items for collection.
2a	Collection Planned	Collection into Rochdale planned.
2b	Trunk Planned	Collection Orders planned from X-Dock to final destination.
3	As the Trip is set to EN-ROUTE, Microlise is updated.	An electronic manifest is sent to Microlise for the collection trip including deliveries and return collection orders.
4	Trip Executed on Microlise.
5	Vehicle arrives back to Rochdale having completed the radial delivery round including collections.
6	Steps 8 – 12 of the X-Dock process in the delivery process described above (same intake, move and load out of x-dock).	X-dock receipt, marshal and load trunk vehicle of return collections. Each cage and loose item is receipt scanned, advised to WCS for loading onto trunk trips where appropriate, moved to despatch lane and loaded out of X-dock. Once load scanned at Rochdale, a pre-advice is sent to WCS for receipting into the destination depot of the trunk, so Milton Keynes.	C-TMS processes successful load and if the order is being trunked to another depot will automatically create a receipting pre-advise for the destination depot. 841 message processed in C-TMS creates a receipt message back to WCS for next depot 431 where required.
7	Trip set to EN-ROUTE as depart from Rochdale.	EN-ROUTE by Microlise geo-fence breaks or set manually in C-TMS. If any return collections on the trunk trip, the EN-ROUTE event in C-TMS pre-advises WCS of trip departure from Rochdale and sends a 432 messages that groups the items pre-advised for delivery and receipt into Milton Keynes
8	Trunk vehicle arrives at Milton Keynes
9	Collect return items received into Milton Keynes. Step 8 of the X-Dock process in the delivery process described above.	Positive receipt into destination depot completes the collection return process.

Empty Ad-hoc Cage Collection Process

Using a typical scenario ad-hoc collection of cages originating a dealership in Liverpool collection from Rochdale and x-docked to Milton Keynes (Mercedes), the following process steps and functional components will support the operation.

	Process Step	Narrative	Development Requirement
1	Microlise creates ad-hoc collection of empty cages (no pre-plan in C-TMS of pickup) at Liverpool Dealership.	Update from Microlise of ad-hoc collection confirmation creates an order in C-TMS listing each cage scanned. Process Microlise PocPod and create order and auto-plan to collection trip (to SCHED_COLL) status.	Create ad-hoc collection of cages from dealership to known asset base (e.g. Milton Keynes for Mercedes) C-TMS pre-advises WCS of receipt of cages into final depot of collection trip, this sends both 431 for each cage and 432 for trip.
2	Vehicle returns to Rochdale (with Liverpool ad-hoc empty cages and possibly planned collection returns as well).
3	Steps 5-9 of the return collection process described above	Ad-hoc collections receipted, x-docked at Rochdale and loaded to Milton Keynes trunk. Loading to trunk will auto-plan to trunk trip.

Observations and Assumptions

The X-Dock solution is designed for multi-depot but has only so far been implemented at Dunelm as a single x-dock sortation hub.

The solution and functionality changes described above cover both delivery and return logistics scenarios.

Ad-hoc collection of cages and pre-planned collection returns will be routed to a single final destination depot/warehouse based on a grouping of the dealership origin. The means, for example, all Mercedes collections will route to Milton Keynes automatically, either via input into the Dealership portal or from ad-hoc collections of empty cages through the Microlise system.

Planned collection return orders will be confirmed, labelled and manifested from each dealership. The label is assumed to be the same as the delivery label generated from the current phase 1 C-TMS solution.

The X-Dock scanning solution will be integrated will generate Asset tracking movement transactions. This means that loading will transact specific assets from the depot location into ‘TRANSIT’ and receipting specific assets into depot.

To fully implement the X-Dock scanning solution, related developments to Asset Tracking and Supplier Portal will be required.

It is assumed that same or similar RDT devices currently in use in the AA operation and those implemented at Dunelm will be utilised and that where possible the WCS server software, functionality projected as dialogue with the user and integration with C-TMS will be retained and re-used.

An airport style arrivals and departures board will be developed to allow locations to enquire on inbound and trips, orders, loaded and empty cages and loose items. This enquiry will allow query by intake showing respective loading outbound; and query by loading outbound to see respective intake.

From the WCS scanning solution implemented at Dunelm, the receipting and loading functions will be the focus of the implementation. It is assumed that internal moves of assets within the X-dock will be a manual process and no movement scanning will be required.

The WCS solution already allows damaged items to be notified resulting in instructions to SINBIN the item.

The solution also supports QC check holds which for the moment is deemed out of scope of this solution. The functionality will be retained but not used.

The WCS to C-TMS integration is designed to be ‘fluid’ meaning that scanning exceptions ‘off plan’ are managed automatically and C-TMS will split orders, auto-plan orders according to successful scanning or recognised assets into and out of the x-dock. This functionality therefore will accommodate early or late collection of empty returns in relation to the collection plan; roll-over of assets left in the x-dock depot due to burst loads and receipt or load of additional trips to known destinations additional to routes generated from standard fixed route plan.

Scope

This change will be applied to system version 10.6.0 on AAMTST and once approved AAMPRD.

Set-up

Pre-requisites

New RDT messages, tables and system parameters will need to be setup.

Menu Structure

‘Unchanged’

Data

See Appendix A.

Functional Description

Overview of Cross-docking Functionality

The cross-docking functionality allows the unloading and loading of trips at an RF-enabled depot RF-enabled depots are identified by the tick-box ‘RF Cross-dock’ in the ‘Locations’ screen: if it is ticked then the depot is enabled to use the WCS interface, for example:

The unloading process will allow the users to identify the trip, enter the receipt bay and then scan each label on the delivery.

The loading process will allow the users to identify the trip, enter the despatch bay and then scan each label for the delivery.

The WCS reason codes for the order items are maintained in the ‘Import Maintenance’ screen:

The reason codes set for the order may be seen in the ‘Orders’ screen with a description of the reason based on the reason code usage type ‘ITEM_NON_CON’ as obtained from the table ’SCH_REASON_CODE’:

The order items will be given a reason code when scanned into or out of the depot:

Unloading:

• SU (Successfully Received)
• LN (Unplanned Late Receipt)
• ON (Unplanned Receipt)
• EN (Unplanned Early Receipt)
• LP (Recd Late on different Trip)
• OP (Recd on different Trip)
• EP (Recd Early on different Trip)
• MI (Item Recd on different Trip)
• DM (Damaged Goods)

If an order item is received on the wrong trip then it will be transferred from its existing order to a new order that will then be assigned to the trip for which it was scanned and unloaded. The item on the original order will then be prefixed with a ‘X’ to effectively cancel the item.

Loading:

• SL (Successfully Loaded)
• XL (Item Loaded to different Trip)
• OL (Unplanned Delivery Loaded)
• UL (Unplanned Collection Loaded)
• ML (Loaded to different Trip)
• DL (Damaged on Load)

RF Application

N.B. The naming convention is for a message between C-TMS and WCS to start with a ‘4’ and between WCS and C-TMS to start with an ‘8’.

The existing message types at Auto Alliance are as below:

• 404 (Order Pre-advice)
• 405 (Trip Accepted)
• 804 (Item Added To Order)

There will be a number of new message types introduced to Auto Alliance for the order/trip creation, unloading, loading and location validation processes which may be considered in the following sequence:

Creation:

• 431 (Item Pre-advice)

Loading:

• 441 (Load Item)
• 442 (Load Trip)
• 841 (Item/Trip Loaded)

Unloading:

• 432 (Trip Orders Pre-advice)
• 831 (Unload Item)
• 832 (Unload Unknown Item)
• 833 (Unload Complete)

Location Validation:

• 421 (Location Validation Request)
• 821 (Location Validation Response)

Locations will be validated through a combination-style check. When directed to a location, the system will request the user to enter either a bar-coded location or key in check digits. If the user enters using the scanned barcode, the RDT will validate that this entry is the same as the location the user has been directed to. If the user enters using the keyboard, the RDT will validate that this entry is the same as the location’s check digits.

If a location is being entered by the RF user (when repositioning or entering a location for the item) the RF user will scan or enter the location. This will be validated with the WCS (and C-TMS) that this is a valid location. If this is valid, a message will be returned detailing the check digits. If the user enters the same check digits, this will be accepted as a valid location.

The process may be represented by a flowchart:

[[Image:]]

C-TMS Changes

‘Loading Management’ Screen (LOAD_MAN)

The ‘Loading Management’ screen will enable the user to find outbound trips for despatch lane assignment and to send the ‘Release Loading’ message. The trips may be found for a schedule and a loading depot, and, optionally, a trip itself.

The orders assigned to each trip will be displayed in the section to the right of the screen. The ‘Order’ will display the external reference of the order; the ‘Store’ will display the delivery location of the order (i.e. the dealership); the ‘DUs Planned’ will display the quantity of the order items received into the depot; the ‘DUs Loaded’ will display the quantity of the order items loaded onto the outbound trip from the depot; the ‘RPEs Planned’ will display the RPE equivalent of the ‘DUs Planned’ for the ‘DU Type’.

The order items received into the depot are identified using the following reason codes set when scanning the item into the depot:

• SU
• LN
• ON
• EN
• LP
• OP
• EP

The order items loaded for delivery from depot are identified using the following reason codes set when scanning the item onto the outbound trip:

• SL
• XL
• OL
• UL

The sequence in which the orders are displayed is based on the ascending sequence of the trip stop number, external reference (i.e. ‘Order’), delivery location (i.e. ‘Store’) and DU type.

A new system parameter called ‘ALLOW_PICK_UP_LOADING’ (‘Allow loading management of pick-up stops’) will be introduced and it may be set to ‘Y’ to allow a despatch bay to be set for the outbound trip where the owning depot of the trip is not the depot.

The ‘Owning Depot’ parameter will become simply the depot in which the loading will occur and will be renamed as the ‘Loading Depot’. The despatch bays will then be validated that they exist in the loading depot parameter set to select the trips.

A change will be required to support loading on a pick-up stop of the trip (i.e. stop type ‘PK’) as well as the start-up stop of the trip (i.e. stop type ‘SU’) at the owning depot. The owning depot of the trip will need to be excluded if pick-up stops may be processed so that the pick-up occurs at the loading depot.

The ‘Carrier’ is the carrier of the trip, whereas the ‘Trailer’ is the trailer assigned to the first stop on the trip; both fields may be entered and a list of values is available.

The status of the trip may be ‘EN-ROUTE’ should there be a pick-up stop and not just ‘PLANNED’ or ‘ACCEPTED’ for a start-up stop.

The ‘Trip Status’ (i.e. the loading status) will need to be switched to the trip stop for the loading activity and the not the trip itself since the stop type may be for pick-ups and start-ups at the loading depot. The trip status is not the status of the trip (e.g. ‘EN-ROUTE’) but a loading status of which there may be three:

• PENDING
• LOADING
• LOADED

‘PENDING’ indicates that a trip has not sent a ‘Release Loading’ type ‘442’ message.

‘LOADING’ indicates that a trip has sent a Release Loading’ type ‘442’ message.

‘LOADED’ indicates that a trip has sent a Release Loading’ type ‘442’ message and has received a ‘Trip Loaded’ type ‘841’ message (i.e. with status code ‘LC’ or ‘LE’).

The ‘442’ message for the loading check for the trip will need to check the location of the stop instead of the owning depot of the trip and then send the location in the message so that it is sent to the correct depot.

A screenshot of the screen is shown below:

The screen allows the despatch lane of a trip to be entered and for the ‘442’ message to be generated should the trip have its ‘Release Loading’ box ticked when the ‘Save’ button is pressed. The ‘Release Loading for all Trips’ box when ticked will tick the ‘Released Loading’ boxes for each trip (removing the tick will do the opposite).

The despatch lane of a trip may be set automatically from a default despatch lane for the customers that have an order on the trip for deliveries or the next depot for cross-docking (i.e. the next unloading activity). The default despatch lane will be assessed for each order in turn in the sequence displayed on screen. The automatic population of the ‘Despatch Lane’ of the trips with the ‘Despatch Bay’ will occur should the user tick the ‘Set Despatch Bay for all Trips’ box and the trip satisfies certain conditions:

• The trip does not have a despatch lane
• The trip has not departed if it starts at the depot (it may be en route if it picks-up at the depot)

See the next section for the setup of these default despatch lanes.

‘Locations’ Screen (LOCATION)

The ‘Default Despatch Lane’ may store the despatch bay from which the deliveries of orders on the trips for the customer are usually despatched. The customer may be considered the location of the ‘Store’ in the ‘Loading Management’ screen in this example. Alternatively, the next depot may be used for the cross-docking of orders.

Auto Alliance Order/Trip Creation

‘404’ Message Generation

The ‘404’ message will be sent to the depot to pre-advise the orders created and assigned to the trip. The format of the message will not be changed.

‘804’ Message Generation

A new item ‘ADDITIONAL_FLAGS’ will be included:

Field	Type	Length	Value
RECORD_TYPE	Character	03	‘804’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT	Character	12	Depot Code
OMS_REF	Character	12	Order Reference
DU_TYPE	Character	12	DU Type
ITEM_ID	Character	20	Item ID (i.e. Asset/Loose Item)
STATUS_CODE	Character	01	Status Code
ADDITIONAL_FLAGS	Character	20	Loose Item Scanned ‘Y/N’

The first character of the item ‘ADDTIONAL_FLAGS’ will be used to indicate whether the item scanned is an asset or a loose item: if the flag is not ‘Y’ then an asset has been scanned and C-TMS will know to create a new asset ID for the item identifier and store the asset ID in the new database tables. See the section below for the format of the asset ID.

If the item scanned is an asset then the next sequence number for that asset will be obtained and stored in the column ‘ITEM_IDENTIFIER’ of the table ‘SCH_ORD_ITEMS’ and the asset ID itself (i.e. without the suffix) will be stored in the column ‘ITEM_AKA_CODE’ of the table ‘SCH_ORD_ITEMS’.

If the item scanned is not an asset but is a loose item then the item ID will be stored in the column ‘ITEM_IDENTIFIER’ of the table ‘SCH_ORD_ITEMS’.

The successful scan of an item will generate a ‘441’ message should the trip be in a despatch bay.

If an asset is scanned then it will be stored in the new tables ‘ASSET_DETAIL’ and ‘ASSET_HISTORY’ for tracking purposes.

The table ‘ASSET_DETAIL’ will store the current location of the asset and its trip (i.e. route); the table ‘ASSET_HISTORY’ will store a record of the transit, arrival and departure of the asset at each stage of its journey.

A new procedure in package ‘DP_RDT_AUTO’ will be created for the inserting and updating of the asset tables.

‘Asset ID’ Format

The item ID of the order will be used to store the cage/asset ID and since the cages may be re-used the format will be changed to be:

{Truncated Asset ID} + ‘-‘ + {Sequence Number}

The sequence number will be a 4 digit number that will count the number of times that the cage has been used, the sequence number will start with the suffix ‘-0001’ and increment by ‘1’ every time that the cage is assigned to an order.

If the cage has been used before (i.e. it exists on the ‘ASSET_DETAIL’ table) then the sequence number will be simply incremented by 1.

If the cage has not been used before then the suffix will be ‘-0001’.

‘405’ Message Generation

The ‘405’ message will be sent to the depot when the trip is accepted. The format of the message will not be changed.

Unloading

‘831’ Message Generation

The format of the message is shown below:

Field	Type	Length	Value
RECORD_TYPE	Character	03	‘831’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT	Character	12	Depot Code
TRIP_ID	Character	12	Trip ID
CONSIGNMENT_NO	Character	20	Consignment Number
ITEM_ID	Character	20	Item ID (i.e. Asset/Loose Item)
RECEIPT_BAY	Character	12	Receipt Bay
DAMAGED_FLAG	Character	01	Damaged Flag
USER_ID	Character	02	User ID

The ‘831’ message will be sent to C-TMS when an item is unloaded and scanned where it will be determined if the item has been received on the expected trip or if it is damaged.

‘832’ Message Generation

The format of the message is shown below:

Field	Type	Length	Value
RECORD_TYPE	Character	03	‘832’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT	Character	12	Depot Code
TRIP_ID	Character	12	Trip ID
ITEM_ID	Character	20	Item ID (i.e. Asset/Loose Item)
RECEIPT_BAY	Character	12	Receipt Bay
DAMAGED_FLAG	Character	01	Damaged Flag
USER_ID	Character	02	User ID

The ‘832’ message will be sent to C-TMS when an item is scanned on an unplanned trip but this information will only be used to write an audit record.

‘833’ Message Generation

The format of the message is shown below:

Field	Type	Length	Value
RECORD_TYPE	Character	03	‘833’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT	Character	12	Depot Code
TRIP_ID	Character	12	Trip ID
RECEIPT_BAY	Character	12	Receipt Bay
STATUS_FLAG	Character	02	Status Flag
USER_ID	Character	02	User ID

The ‘833’ message will be sent to C-TMS when the unloading of the trip is completed but this information will only be used to write an audit record.

Loading

‘441’ Message Format

A new item ‘ACTION’ will be included to denote the action required:

Field	Type	Length	Value
RECORD_TYPE	Character	03	‘441’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT	Character	12	Depot Code
TRIP_ID	Character	12	Trip ID
CONSIGNMENT_NO	Character	20	Consignment Number (i.e. OMS Reference)
STORE_NO	Character	12	Store Number (i.e. Dealership)
ITEM_ID	Character	20	Item ID (i.e. Asset/Loose Item)
ITEM_UOM	Character	12	Unit of Measure (i.e. DU Type)
ITEM_DESCRIPTION	Character	70	Description
ITEM_AKA	Character	30	Alternative Description
ACTION	Character	01	Action Required

The action will only be required for when cages are deleted as they are not going to be used, therefore if a ‘D’ is sent to the WCS system then it will indicate that the cage will not be scanned and it may be deleted from the list. In all other circumstances at present the action will be a null value.

‘441’ Message Generation

The ‘441’ message will be generated when the item is moved to the despatch bay when the trip is assigned a despatch lane.

The package ‘DP_RDT_FAST_LOAD’ will need to be changed so that the new format is used in the type ‘TY_TMS_ITEM_LOAD’ and the procedure ‘SEND_WCS_ITEM_LOAD’.

The items may not just be going to their final destination for delivery so this procedure must include items being unloaded at another RF-enabled depot.

This procedure will also need to account for pick-up stops as described in section 3.2.1 as the trip status may be ‘EN-ROUTE’ and not ‘PLANNED’ or ‘ACCEPTED’.

‘442’ Message Validation

The format of the message is shown below:

Field	Type	Length	Value
RECORD_TYPE	Character	03	‘442’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT	Character	12	Depot Code
TRIP_ID	Character	12	Trip ID
BAY_NUMBER	Character	12	Despatch Bay
BAY_CD	Character	03	Despatch Bay Check Digit
TRAILER_ID	Character	12	Trailer ID
CARRIER_ID	Character	12	Carrier ID
STORE_ARRAY_NO	Character	100	Store Number
STORE_ARRAY_NAME	Character	200	Store Name
STORE_ARRAY_ARRIVE	Character	200	Store Arrival Date/Time in format ‘YYYYMMDDHH24MISS’

The ‘442’ message will be generated via the ‘Loading Management’ screen when the load may be released.

The package ‘DP_RDT_FAST_LOAD’ will need to be changed so that the procedure ‘SEND_WCS_TRIP_LOAD’ accounts for pick-up stops as described in section 3.2.1 as the trip status may be ‘EN-ROUTE’ and not ‘PLANNED’ or ‘ACCEPTED’.

‘841’ Message Validation

The format of the message is shown below:

Field	Type	Length	Value
RECORD_TYPE	Character	03	‘841’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT	Character	12	Depot Code
TRIP_ID	Character	12	Trip ID
CONSIGNMENT_NO	Character	20	Consignment Number (i.e. OMS Reference)
ITEM_ID	Character	20	Item ID (i.e. Asset/Loose Item)
DESPATCH_BAY	Character	12	Despatch Bay
STATUS_CODE	Character	02	Status Code
USER_ID	Character	03	User ID

The package ‘DP_RDT_FAST_LOAD’ will need to be changed so that procedure ‘RECVD_WCS_FAST_LOAD_CONF’ accounts for pick-up stops as described in section 3.2.1 as the trip status may be ‘EN-ROUTE’ and not ‘PLANNED’ or ‘ACCEPTED’.

The ‘431’ message will also be sent to the next RF-enabled depot when the item is scanned onto the trip.

When the loading of the trip is complete and the status of ‘LC’ or ‘LE’ is sent then the loading status of the trip will be updated from ‘LOADING’ to ‘LOADED’ as displayed in the ‘Loading Management’ screen..

‘431’ Message Generation

The format of the message is shown below:

Field	Type	Length	Value
RECORD_TYPE	Character	03	‘431’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT	Character	12	Depot Code
SUPPLIER_CODE	Character	12	Supplier Code
CONSIGNMENT_NO	Character	20	Consignment Number (i.e. OMS Reference)
ORDER_NO	Character	20	Order Number
ITEM_ID	Character	20	Item ID (i.e. Asset/Loose Item)
UOM	Character	12	Unit of Measure (i.e. DU Type)
DESCRIPTION	Character	70	Description
ITEM_AKA	Character	30	Alternative Description
STORE_NO	Character	12	Store Number (i.e. Dealership)

The ‘431’ message will need to be generated for each item when the return collection order is created via the Supplier Portal so that every RF-enabled depot may be pre-advised that the item may be received. The existing trigger ‘TRG_SOM_SUPP_CONF’ will be used for this purpose as the table ‘SCH_ORD_MANF’ will be populated and the supplier confirmed; the manifest number will be the prefix ‘RET-‘ plus the OMS reference of the order created.

‘432’ Message Generation

The format of the message is shown below:

Field	Type	Length	Value
RECORD_TYPE	Character	03	‘432’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT	Character	12	Depot Code
TRIP_ID	Character	12	Trip ID
CONSIGNMENT_NO	Character	20	Consignment Number (i.e. OMS Reference)

The ‘432’ message will be sent to the next cross-docking depot for the unloading activity of the outbound trip when it is en route.

Location Validation

‘821’ Message Validation

The format of the message is shown below:

Field	Type	Length	Value
RECORD_TYPE	Character	03	‘821’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT	Character	12	Depot Code
LOCATION	Character	12	Location Code
RDT_ID	Character	02	RDT ID
STATUS	Character	02	Status Code

The ‘821’ message will be sent to C-TMS for verification whenever a WCS location is scanned. The message will be processed and a response sent immediately in the ‘421’ message to ensure quick processing.

‘421’ Message Generation

The format of the message is shown below:

Field	Type	Length	Value
RECORD_TYPE	Character	03	‘421’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT	Character	12	Depot Code
LOCATION	Character	12	Location Code
LOC_CD	Character	03	Location Code Check Digit
RDT_ID	Character	02	RDT ID
LOC_STATUS	Character	02	Location Status

The ‘421’ message will be sent to WCS to advise that the WCS location is valid. The location status will be ‘Y’ if an active WCS location has been found in the depot, otherwise it will be ‘N’.

Assumptions

It is expected that the standard asset ID is not more than 13 characters so that the 6 digit sequence number may be used to identify its movements with a separator.

It is expected that the cage will not be relabelled until the previous order has completed its processing.

It will be necessary to ensure that the WCS location in each depot is unique so that the owning depot may be obtained when the WCS location is scanned, for example, when a despatch bay is assigned to a trip.

Driver Trip Sheet

Format to be confirmed.

WCS Changes

Wherever the current X-Dock functionality in WCS refers to delivery locations on the RDT it is labelled as a “Store” whereas for Auto Alliance this will need to be changed to ‘Drop’. A new warehouse rule called ‘Delivery_Location_Title’ will be added to allow this label to be set as required.

Order Creation

C-TMS needs to know if an item being added to an order is an asset or a loose item. To accommodate this, and any potential future requirements, a new field will be added to the ‘804 Order Creation’ message. The field will be 20 characters in length and the first character will be set to “Y” if the item is a loose item and not an asset.

Field	Type	Length	Value
MESSAGE_TYPE	Character	03	‘804’
DATE_TIME_STAMP	Character	14	Date/Time in format ‘YYYYMMDDHH24MISS’
DEPOT_CODE	Character	12	Depot Code
OMS_REF	Character	12
DU_TYPE	Character	12	LCAGE, SCAGE etc.
ITEM_ID	Character	20	Item ID (i.e. Cage/Asset ID)
STATUS_CODE	Character	01
ADDITIONAL_FLAGS	Character	20

Loose items will have a unique identifier generated by the WCS and printed on a label to be affixed to the item. In all other cases the item identifier being scanned will not be unique within the WCS as the assets are continuously reused. Therefore when the C-TMS receives the ‘804’ message it will append a four-digit, zero-padded sequence number on the end of the item id separated with a hyphen to make it unique from this point on until the end of the trip.

Loading

The loading process begins with the receipt of a ‘441 Loading Pre-Advice’ message from C-TMS which is created in response to the adding of cages and loose items to orders and trips. When the WCS receives a ‘441’ message the item is added to the TMS_Load_Detail table. If an item is removed from an order another ‘441 Loading Pre-Advice’ message will be received with the ‘Action’ field set to ‘D’ which will cause the WCS to remove the applicable item from the TMS_Load_Detail table. This is as per current functionality.

Once the trip is released for loading in C-TMS a ‘442’ message is received and a new record is added to the TMS_Load_Header table and the trip is now available for loading by the WCS. The loading process is as follows;

• User selects X-Dock Loading from the RDT menu.

• User scans trip from documentation or entered the trip number to load.

• The RDT will display the ‘Drop’ which is to be loaded first will be the last location of this trip.

• RDT starts loading the items by scanning each item identifier. As mentioned earlier the item identifier being scanned is the ‘asset tag’ and apart from loose items, will not be unique in the system. Therefore the RDT will identify the correct item record by selecting the latest record in the TMS_Load_Detail table within the depot of the user with a matching asset tag prefix.

• When an item is successfully loaded an ‘841 Load Confirmation’ message is sent to C-TMS.

• The RDT will show a scrollable list of all items loaded showing the asset id without the additional sequence number suffix.

• The user will indicate that a Drop is fully loaded by pressing the F1 function key, as per current functionality. If any items remain to be loaded the RDT will display a list of outstanding items. The user can continue to scan items or press the function key again to move on to the next Drop.

• The process repeats for the next Drop until all Drops are complete.

• The RDT then offers the user the chance to scan any additional items now in the despatch area and these can be scanned regardless of which Drop destination so long as the Drop is a destination of the trip.

• The user completes final loading by pressing the function key F1. If any items are left on site for the trip a Supervisor password override is required. The supervisor will select a reason code for the missing items and then close the load.

It is assumed that the user can identify damage using a function key F2 and leave off an item from the load accordingly.

The system will use the ‘*’ prefix notation in the item list on the RDT display to denote an item has been scanned onto the trip that wasn’t planned to be loaded.

Unloading

The unloading process begins with the receipt of a ‘431 Receipt Pre-Advice’ message from C-TMS which is created in response to the loading of an item on to a trip. When the WCS receives a ‘431’ message the item is added to the TMS_Receipt_Detail table. Once the trip is flagged as EN-ROUTE by Microlise the C-TMS sends a ‘432’ message that when received by the WCS a record is written to the TMS_Receipt_Header and makes the trip available for unloading. The unloading process on the RDT is as follows;

• User selects X-Dock Unloading from the RDT menu.

• User scans the trip from the documentation or enters the trip number to load.

• The user is prompted to enter the receiving bay where the trip will be unloaded to.

• The user unloads all items by scanning each item identifier. As mentioned earlier, the item identifier will not be unique, the WCS will identify the correct em record by selecting the latest record in the TMS_Receipt_Detail table within the depot of the user with a matching asset tag prefix.

• When an item is successfully unloaded an ‘831 Receipt Confirmation’ message is sent to C-TMS.

• If an item is scanned and is not recognised the user is instructed to take the item to the ‘SINBIN’ and an ‘832 Receipt Item Unknown’ message is sent to C-TMS.

• The RDT will show a scrollable list of all items unloaded without the additional sequence number suffix, added to as each item is unloaded.

• The user will indicate that the trip is fully unloaded by pressing the F1 function key. If any items remain to be unloaded the RDT will display a scrolling list of outstanding items and the user can continue to scan the missing items or press the F1 function key again where a supervisor password will be required to complete the unload.

• When the trip is fully unloaded an ‘833 Receipt Complete’ message is sent to C-TMS.

Supplier Portal Changes

The supplier portal will be changed to enable the collections of items to be planned: the loose items may be placed into an asset ready for an order to be created for its collection for its return to the origin of the asset.

For example,

New tables will be required for the collection of returns (see Appendix A):

• ASSET_DETAIL_ITEMS
• SCH_ORD_ITEM_CONTENT

The table ‘ASSET_DETAIL_ITEMS’ will be used to store the planned collection of items placed in the asset for return to its origin, therefore this table will be temporary and the data will be deleted once the asset has been confirmed as collected via the ‘POC’ message from Microlise.

The table will store the following data in the columns:

• ASSET_ID – Asset
• ASSET_ITEM – Loose Item
• ITEM_DESCRIPTION – Asset
• ITEM_TYPE – Asset

The table ‘SCH_ORD_ITEM_CONTENT’ will be populated with the planned collection of items placed in the asset when the order is created once enough items have been planned to justify a trip being made.

The table will store the following data in the columns:

• ITEM_IDENTIFIER – Asset ID with suffix
• ITEM – Asset ID without suffix
• ITEM_DESCRIPTION – Asset
• ITEM_TYPE – Asset
• ITEM_QTY – Asset

Asset Tracking Changes

See functional specification ‘FS-285989 AD-8DQSF3 Develop Asset Tracking Functionality’ for further information.

N.B. The asset ID itself will be stored in the column ‘ITEM_AKA_CODE’ on the table ‘SCH_ORD_ITEMS’ but the asset ID for the order will be stored in the column ‘ITEM_IDENTIFIER’ on the table ‘SCH_ORD_ITEMS’.

Further changes will be required for the collections of empty assets and returned items.

An empty asset will be an asset that has been collected but not for an order, therefore the cage itself will be empty of items.

A collection of returned items will be made for an order created via the supplier portal.

Both types of collections will be confirmed via the ‘POC’ message via Microlise; if a planned collection is confirmed then the temporary data on the table ‘ASSET_DETAIL_ITEMS’ for the asset on the order will be deleted as it will no longer be required.

N.B. The ‘POC’ message will also need to write the appropriate messages to send to WCS for scanning should any ad-hoc collections have occurred: this will involve generating a ‘431’ message for the items to the next RF-enabled depot.

Table Updates Required

ASSET_DETAIL:

Name	Type	Size	Nullable
ASSET_ID	VARCHAR2	30	N
OWNER	VARCHAR2	12	Y
ASSET_TYPE	VARCHAR2	10	Y
ORIGIN	VARCHAR2	12	Y
CURRENT_LOCATION	VARCHAR2	12	Y
ROUTE	VARCHAR2	12	Y
STATUS	VARCHAR2	12	Y
COMMENTS	VARCHAR2	150	Y
CREATED_BY	VARCHAR2	50	Y
CREATED_DATE	DATE		Y
INACTIVE	VARCHAR2	1	Y
ASSET_ITEM_TYPE	VARCHAR2	12	Y
OPEN_CLOSE	VARCHAR2	12	Y
ASSET_SEQ	NUMBER		Y

ASSET_HISTORY:

Name

Type

Size

Nullable

ASSET_ID	VARCHAR2	30	Y
DATE	DATE		Y
LOCATION	VARCHAR2	12	Y
ACTION	VARCHAR2	12	Y
ACTION_BY	VARCHAR2	50	Y
PROCESS	VARCHAR2	30	Y

ASSET_STATUS:

Name

Type

Size

Nullable

STATUS	VARCHAR2	12	Y
INACTIVE	VARCHAR2	1	Y

ASSET_ORIGINS:

Name

Type

Size

Nullable

LOCATION	VARCHAR2	12	Y
OWNER	VARCHAR2	12	Y

ASSET_DETAIL_ITEMS:

Name

Type

Size

Nullable

ASSET_ID	VARCHAR2	30	N
ASSET_ITEM	VARCHAR2	30	N
ITEM_DESCRIPTION	VARCHAR2	50	Y
ITEM_TYPE	VARCHAR2	20	Y

SCH_ORD_ITEM_CONTENT:

Name

Type

Size

Nullable

ITEM_IDENTIFIER	VARCHAR2	20	N
ITEM	VARCHAR2	30	N
ITEM_DESCRIPTION	VARCHAR2	50	Y
ITEM_TYPE	VARCHAR2	20	Y
ITEM_QTY	NUMBER		Y

References

Ref No	Document Title & ID	Version	Date
1	EST-285987 AD-8DYG8J WCS Loading & Unloading v0.2.doc	0.2	04/03/11
2	FS-285989 AD-8DQSF3 Develop Asset Tracking Functionality’	1.0	16/03/11

Glossary

Term or Acronym	Meaning
C-TMS	Calidus TMS.
RDT	Radio Data Terminal. The RF hand held terminals.
RF	Radio Frequency.
TMS	Transport Management System. The OBS TMS is Calidus TMS.
TOL	TMS Online: a system designed for end users to view and amend their orders, print labels and manifests, etc.
WCS	Warehouse Control System. The OBS RF system Calidus 3pl-Mobile.
WMS	Warehouse Management System. The OBS WMS is Calidus 3pl

Document History

Version	Date	Status	Reason	Initials
0.1	14/03/11	Draft	Initial version	PDR
1.0	16/03/11	Issue	Reviewed and Issued	MJC

AUTHORISED BY

Matt Crisford	Development Manager
Peter Greer	TMSCC MTS Product Manager