276897: Difference between revisions
(New page: =2276897 - AS-856KX8/ Enhanced Cross-Dock= Copyright OBS Logistics © 2010 The information contained herein is the property of OBS Logistics and is supplied without liability for errors...) |
No edit summary |
||
Line 150: | Line 150: | ||
! style="background:darkblue;color:white;"| Value | ! style="background:darkblue;color:white;"| Value | ||
|- | |- | ||
| style="border:3px solid darkblue;"|''' | | style="border:3px solid darkblue;"|'''Message_Type''' | ||
| style="border:3px solid darkblue;"| | | style="border:3px solid darkblue;"|Character|} | ||
|} | | style="border:3px solid darkblue;"|3|} | ||
| style="border:3px solid darkblue;"|821|} | |||
<br/> | <br/> | ||
<br/> | <br/> |
Revision as of 10:41, 21 April 2011
2276897 - AS-856KX8/ Enhanced Cross-Dock
Copyright OBS Logistics © 2010
The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied
FUNCTIONAL OVERVIEW
Client Requirement
Client Request
Static Data to define loading lanes and put away storage locations and timing events. Generate sequenced movement tasks and interface to WCS for unload to QA, to loading lane and put away. Receive updates and confirmation of tasks from WCS Manage status, locations and audit trail for movements through the facility. WCS and RDT functions to issue movement tasks and confirmations to operator.
Interface loading manifest to WCS to enable scanning of loading. Update C-TMS with scanning loading from WCS, deal with clean and discrepancies. WCS scanning loading and integration with C-TMS.
Status and update to identify trailers arrived in Yard. Receiving Query & Report to identify consignments for loading out of the NSC. Interface inbound manifest to WCS to enable scanning of receipt. Update C-TMS with scanning intake from WCS, deal with clean unload, overs, unders, planned audit and quarantine status. Manage planned audit process, holding outbound until audit released in NSC. WCS scanning intake and integration with C-TMS.
Solution
Solution Overview
The operation requires the ability to unload stock from inbound manifests. The manifest will be created in TMS from a series of orders (consignment) created from the client systems. Once created in TMS, these will be forwarded to TOL, which will allow the users to create a delivery manifest, print unique labels for each item on the delivery and produce documentation. When this is completed, TMS will be updated with the details of the items on each of the orders on the manifest. Once this is completed, the inbound manifest will be forwarded to the WCS by TMS. This will form the preadvice of the receipt being unloaded. The preadvice details will contain:
- • The Trip
- • The consignments on the trip
- • The details of each item to be received on each of the consignments.
The unloading process will allow the users to identify the trip, enter the receipt bay and then scan each label on the delivery. Each item scanned will be marked in TMS as received. If an additional item is scanned that it not on the manifest, this will be directed to QA – the user will be prompted to move this to one side for completion later. When the user has finished scanning the manifest, they will confirm scanning is complete. The unit will check all the scanned items and compare against the preadvice. If any items are missing from consignments, the user will be prompted to find all these items first. If the users confirm that these items cannot be found, the receipt will be completed and TMS informed. An exception will be raised.
TMS will be updated for each item on the consignments, with the location of the items. TMS will also be informed that scanning is complete for the manifest. If some items on a consignment have not been received, TMS will generate movement tasks for the items actually received on these consignments to the SinBin location. If all items have been received on a consignment, TMS will check to see the status of the outbound trip and marshalling bays. If the outbound trip is planned and there is an available marshalling bay, TMS will generate movement tasks for the items on the consignment to the marshalling bay. If no bay is available, or the outbound trip is neither ready nor likely to be ready, the items on the consignment will be directed to a storage location in the grid.
When movement tasks arrive in WCS, they will be made available for RF drivers to complete, when they request them. The moves will be grouped as follows:
- • If the move is to QC or SinBin, the moves will be grouped together with the tasks on that consignment from that location.
- • If the move has an outbound trip identified, the moves will be grouped together with the tasks on that outbound trip from that location.
- • If the move has no outbound trip, the moves will be grouped together with the tasks for that store from that location.
When the driver requests a movement task, the WCS will allocate work to them as follows:
- • Any tasks of a higher priority than others will be completed first.
- • If the item is on a consignment that has been planned onto an outbound trip, the task will have a planned departure date and time. These tasks will be completed first, in ascending departure date and time sequence.
- • If a task is not yet planned, all tasks that aren’t of type “Move to QC” will be completed in first-come, first-served basis, Moves to QC will always be completed last.
All of the moves grouped together will be reserved for that driver at this point, as the driver may move all of the items in one movement.
The RF process will direct the user to the location where the items for that group are at that time. The user will be prompted to scan as many of the items as they can move – a list will be provided of all the items in that group, to help them identify the moves. Once the user has scanned the items and confirmed that they can take no more (or there are no more available), they will indicate this and be directed to move the items to the destination location and confirm. Any remaining tasks on this group will be released for other drivers to complete. Once they have confirmed this, they will be assigned a new move task.
Each item will be updated as completed on TMS, showing the new destination location. Once all items on a consignment are moved, TMS will check the status of the outbound trip. If all consignments on that trip are now moved to the assigned marshalling bay, the consignments will be made available for loading. If the trip now has a marshalling bay and is ready, and the tasks on the consignment were moved to storage, tasks will be generated for each of these items to the marshalling bay. Note: A version of this process will be running continually in TMS, checking the status of outbound trips and generating moves where necessary. If items are in the process of being moved already (to a storage location), the tasks will be replaced with tasks to move the pallets to the marshalling bay.
Once a set of consignments on an outbound trip have been confirmed into a marshalling bay, TMS will generate a load checking and loading task.
First the outbound bay must be checked that it has all the correct stock, using load checking. Once the user enters the load checking module, they will be directed to a trip to be loaded (with the capability of choosing another). Once the trip to be checked is confirmed, the RDT will direct the user to the marshalling lane and require confirmation. Once confirmed, the RDT will require the user to scan each item to be checked for all the consignments. Once the user has completed scanning all items, they will confirm the trip as checked. If items are on the trip but have not yet been scanned, the RDT will display a list of all the missing items and request the user to find them. If the items are confirmed as not found, an exception will be raised in the WCS and the trip will be marked as incomplete. This trip will then require completion within TMS. If all items are scanned, the tasks will be marked as Load Checked within WCS.
It is expected that at this stage the supervisor will allocate a bay door to an outbound trip within WCS. It is to be noted that this allocation of a bay door could take place at any time after the Load tasks have been received by WCS. Once the bay door is allocated, the trip will be available for loading.
Once the user enters the loading module, they will be directed to a trip to be loaded (with the capability of choosing another). Once the trip to be loaded is confirmed, the RDT will direct the user to the marshalling lane and require confirmation. Once confirmed, the RDT will display the first store to be loaded (in reverse drop sequence), then require the user to scan each item to be loaded for that store. Once all items for a store have been scanned, the RDT will direct the user to the next store to be scanned. Once the user has completed scanning all items for a store, they will confirm the store as loaded. If items for a store are on the trip but have not yet been scanned, the RDT will display a list of all the missing items and request the user to find them. If the items are confirmed as not found, an exception will be raised in the WCS and the trip will be marked as incomplete. This trip will then require completion within TMS. If all items on all stores are scanned, the items, consignments and trip will be marked as loaded in TMS.
A selection of standard WCS interfaces and maintenance screens will be required for the users to maintain the system.
WCS Maintenance screens:
- • Users Maintenance, allowing finding amending and creation of users.
- • User Group Settings, allowing the ability to set the items each user has on their main RDT menu.
- • Unloading Enquiry, showing the status of the Unloading tasks.
- • Move Maintenance (Including reprioritisation, holding and errors), allowing the users to see and amend move tasks
- • Loading Maintenance (showing the status of loads from checking through to loaded), allowing the user to see the status of the outbound loads.
- • Activities and Exceptions enquiry, allowing the user to enquire on any tasks that have been completed and any exceptions raised during the completion of these tasks.
- • Current Activities and Current Exceptions, allowing the user to see users and their current activity and to see exceptions as they are raised.
All of these maintenance screens will be built in a new version of WCS Maintenance specifically for this system.
Scope
The changes for the WCS programs will be implemented in a new build of WCS.
Data
Pre-requisites
A Calidus 3pl –Mobile WCS system must be installed and configured. Calidus TMS must be set up and configured to communicate with the WCS.
Menu Structure
N/A
Data
N/A
FUNCTIONAL DESCRIPTION
RF Main Application
Logon
The RDT will require the user to log on, using the following criteria:
- • Depot Code
- • User ID
- • Password.
Main Menu
Once logged on, the user will be shown a main menu with the requisite menu items, as follows:
- • Unloading
- • Moves
- • Load Checking
- • Loading
Location Validation
Locations will be validated through a combination-style check. When directed to a location, the system will request the user to enter either a barcoded 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 first item going to store for a group), the RF user will scan or enter the location. This will be validated with the WCS (and 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 file layouts for the Location Validation messages are as follows:
Field | Type | Length | Value | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Message_Type | Character|} | 3|} | 821|}
REFERENCES
DOCUMENT HISTORY
AUTHORISED BY
|