276897
276897 - 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
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
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:
RF Unloading (Receipt)
For a process flow, please see appendix A.3.
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 message will be populated as follows:
The WCS will recognise this message and populate new tables with these details, as follows:
Table 1: TMS_Receipt_Header
Table 2: TMS_Receipt_Detail
The unloading process will allow the users to identify the trip, enter the receipt bay and then scan each label on the delivery. When entering the Receipt module, the RDT will request the user to enter a Trip ID. The earliest Trip ID will be suggested automatically. The user can enter a different Trip ID. It is intended that the Trip ID will be barcoded on the Driver Trip Sheet produced from TMS. The WCS will look up the entered Trip and issue an error if the trip is not found for the user’s Depot (“Trip X not found”). If the Trip is found, but not at status “P” (Pending), an error will be issued “Trip X unavailable”. When confirmed, the Trip will be allocated to the user’s RDT (setting the status of the TMS_Receipt_Header record). The WCS will then check to see if the receipt has a Receipt bay entered against it yet. If found, the RDT will display the receipt bay. If not, the RDT will prompt for a receipt bay. Initially, it is not intended that this location entry will be validated – the receipt bays will be barcoded (or bus-stops will be used) to allow the user to scan this barcode, thereby reducing the chance of incorrect location entry. Note: It will be possible to create a simple validation message between TMS and WCS if required, but this is not seen as essential for the initial implementation. The RDT will then display a screen showing the Trip ID, the total number of items on the trip, the total number of items scanned as received. An area below this will be used to show the last few items scanned by the user.
Figure 1: Item Label
The barcode is a UCC/EAN-128 (GS1) barcode. The RDT will extract the data in the barcode as follows:
- 21 is the Item ID
- 240 is the Consignment Number
- 90 is the UOM
- 91 is the item count, comprising
- The item on this consignment
- The total of the items of this type on this consignment
- The total of the items on this consignment
Item ID (21) will be extracted – all other parts will be discarded. If the item scanned is not valid (i.e. not on this trip), the RDT will issue an error (“Item not on this load”) and will request the user to scan again. If the user enters the same ID again immediately, the RDT will display the message “Additional item found Investigation and move to QA required”. The operation will move this item to QA manually and investigate. The RDT will inform the WCS to raise an exception against this item.
If the item scanned is valid, the RDT will display the details of the scanned item in the Details area, with the list scrolling down each time a valid item is scanned. The number of scanned items will be incremented and displayed on the RDT. The WCS will update the TMS_Receipt_Detail record for this ID, marking the status as “Y” (Received). The WCS will send a message to TMS to confirm this receipt. The details will be:
The item scanned will be marked in TMS as received. The Consignment and item will be marked as being in the receipt bay identified.
If the user has not completed scanning but wishes to exit the scanning of this load, they can press CLR (or ESC) to do this. If the user does this, the RDT will request confirmation with a pop-up screen, displaying “Incomplete Receipt. F1-Leave incomplete. CLR-Continue Scanning”. If the user presses CLR, the user will be returned to the receipt scanning process. If the user presses F1, they will return to the main menu. The next time a user attempts to receive this Trip, the Marshalling location will already be set and displayed on the screen. The RDT will also display the number of pallets remaining to be scanned on the receipt.
When the user has finished scanning the manifest, they will confirm scanning is complete by pressing F1. The unit will check all the scanned items and compare against the preadvice. If any items are missing from consignments, the RDT will display a list of all these items to be found, along with the message “Warning: These items have not been received. F1-Confirm not found. CLR-Continue scanning”. If the user presses CLR (or ESC), the user will be returned to the scanning screen. If the user presses F1 again, the RDT will display “Trip X received”. Clearing this message will ask the user to enter another trip to receive. If all the items have been found when the user finishes scanning and presses F1, the RDT will display “Trip X received”. Clearing this message will ask the user to enter another trip to receive. The WCS will record activity time for the user against the inbound manifest. Activity Details: The WCS will also record any additional items found as an exception. Exception Details:
When a trip has been confirmed with F1, the WCS will send a final message to TMS, confirming the receipt. The message will be as follows:
When this message is received, 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 default QA 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 ready (or within a few minutes of being ready, 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. The messages to WCS will be in the following format:
WCS will store this movement onto new tables, called TMS_Moves_Header and TMS_Moves_Details, as follows: Table 3: TMS_Moves_Header
Table 4: TMS_Moves_Detail
The header record will group the moves. 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.
RF Movements (Putaways, Marshalling)
For a process flow, please see appendix A.4.
When movement tasks arrive in WCS, they will be made available for RF drivers to complete, when they request them. 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. This will be by changing the Status Flag of the TMS_Moves_Header to the RDT ID of the user allocated the task.
The RF process will direct the user to the location where the items for that group are at that time, as all the items will be in the same location. The user will be prompted to confirm that they are at this location by scanning the location code or entering the check digits. If the user enters the wrong location, the RDT will display an error “Incorrect Location” and prompt the user to confirm again. The user will then be prompted to scan as many of the items from this location as they can move, on the following screen:
In a similar way to the Receipt process, items will be displayed on the screen as they are scanned.
It the user presses F5, the user will be shown a screen of all remaining items to find, as follows:
In either screen (i.e. showing the items currently scanned or the items remaining to be scanned), the user can press the Up and Down cursor keys to show the items on the list not on the screen.
Once the user has scanned the items they want to move and pressed F1, they will 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.
Note: Where items are being moved to the storage grid, the tasks will not at that stage have a movement and will be marked as being sent to location “GRID”. In this instance, the RDT will recognise this and request the user to enter a location for the item(s). All other items of that group will be marked as being sent to that newly-entered location. Note: Where the movement type is “G” (moves to grid), the RDT will also offer the ability to reposition the items to a different location if the location they are directed to is unsuitable. All items in that group will be marked as being sent to that newly-entered location. Where a location is entered, the WCS will validate this with TMS as a valid location. The location validation file layouts and functional description can be seen in section 3.1.3.
Once they have confirmed this by scanning the destination location, they will be assigned new moves to complete.
Each item moved in this way and confirmed at the destination location 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. As such, messages will be sent to the WCS to inform users that loading is required, as follows:
The message will be populated as follows:
The WCS will recognise this message and populate new tables with these details, as follows:
Table 5: TMS_Load_Header
Table 6: TMS_Load_Detail
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, utilising the standard moves message generation process described above.
TMS Move Generation Process
For a process flow, please see appendix A.2.
The process of checking where a particular consignment should be at receipt confirmation, putaway and move confirmation has been covered within the appropriate sections. This process will also be accessible through a package that will be run at regular intervals within TMS. This process will check all received consignments to see whether they should be moved, or whether they should be loaded. This will result in messages to move or load tasks on consignments on a regular basis, without user interaction.
Load Checking
For a process flow, please see appendix A.5.
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 on a screen similar to the following:
This screen will operate in the same way as the Receipt screen, in that all scanned items will be validated and, when confirmed, will be placed on the Details pane of the screen. Each item scanned as load checked in this manner will have a message sent to TMS to confirm it has been loaded, in the following message format:
Once the user has completed scanning all items, they will confirm the trip as load checked by pressing F1.
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. Again, this will be similar to the receipt process described above.
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.
Loading
For a process flow, please see appendix A.6.
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 by entry of the marshalling lane again. 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, on a screen similar to the following:
This screen will operate in the same way as the Receipt screen, in that all scanned items will be validated and, when confirmed, will be placed on the Details pane of the screen. Each item scanned as loaded in this manner will have a message sent to TMS to confirm it has been loaded, in the following message format:
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, they will confirm the store as loaded by pressing F1. If items are on the trip for the store but have not yet been scanned, the RDT will display a list of all the missing items and request the user to find them. Again, this will be similar to the receipt process described above. 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. The message sent will be as follows:
If all items on all stores are scanned, the items, consignments and trip will be marked as loaded in TMS. The message sent will be as follows:
Further Generic Requirements
A selection of standard WCS interfaces and maintenance screens will be required for the users to maintain the system. Additionally the standard OAQ interfacing packages will need to be included into TMS.
WCSM screens:
- Users Maintenance (Simpler, linked to Depot, but allowing creation)
- Depot Settings (i.e. rules)
- User Group Settings (for the new modules)
- Unloading Enquiry
- Move Maintenance (Including reprioritisation, holding and errors)
- Loading Maintenance (showing the status of loads from checking through to loaded)
- Activities and Exceptions enquiry
- Current Activities and Current Exceptions
All of these maintenance screens will be built in a new version of WCS Maintenance specifically for this system.
TMS OAQ Packages
TMS will need to import the standard OAQ packages from Calidus 3PL, including (but not limited to):
- DP_AQ
- DP_RDT
Additionally, the following tables will need to be imported:
- APP_QUEUE
- APP_REC
- APP_WAREHOUSE_QUEUE_SCHEMA_AGENT (Changed to apply per Depot rather than Warehouse)
The OAQ Tables required for the messages will also have to be created. This consists of 1 queue from TMS to WCS, and at least 1 queue from WCS to WMS.
Users Maintenance
A new TMS Users Maintenance will be created, allowing the user to find, amend and create users for the depot. The screen will display:
- User ID
- User Name
- User Group
- Access Type
The user will be able to maintain Group and Access Type. Note: This will be based on the existing Users maintenance screen.
Depot Settings (i.e. rules)
A new Rules maintenance screen will be created to create Depot rules. This will be based on the existing Rules screen codes. Any rules relating to Depot will be stored here. Note: This will not be completed for the base product at this time.
User Group Settings (for the new modules)
New rules will be added to maintain the modules for the TMS users. As such, these rules will be based on a Depot/User combination and will only show these rules. Note: This will be based on the existing Group Rules screens.
Receipt Enquiry
A standard enquiry will be created to show the outstanding receipt tasks within WCS. Note: This will utilise the standard enquiry screen object to produce this screen. The user will only be able to view the data. The screen will display all the Receipt data on the form, as follows:
- Depot Code
- Trip ID
- Consignment Number
- Store
- Receipt Bay
- Item ID
- UOM
- Description
Move Maintenance (Including reprioritisation, holding and errors)
A standard enquiry will be created to show the outstanding movement tasks within WCS. Note: This will utilise the standard enquiry screen object to produce this screen. The user will be able to view, reprioritise, hold and error the data. This should be based on the existing Pick Enquiry screen.
The screen will display all the Receipt data on the form, as follows:
- Depot Code
- Consignment Number
- Store
- Item ID
- UOM
- Description
- Item AKA
- Location From
- Location To
- Priority (shown as “H” if value is 9)
- Status (shown as Pending if “P”, Error if “E”, In Progress if anything else)
Loading Enquiry
A standard enquiry will be created to show the outstanding loading tasks within WCS. Note: This will utilise the standard enquiry screen object to produce this screen. The user will only be able to view the data. The screen will display all the Receipt data on the form, as follows:
- Depot Code
- Trip ID
- Store
- Marshall Bay
- Status
- Bay Door
The screen will have the ability to enter a bay door against a Trip. If entered against a trip all lines for that trip will be updated. The screen will refresh
Activities and Exceptions Enquiry
The existing Activities and Exceptions screens will be ported to the new application. They will have Depot code added to both the table and the screen. In all other ways they will act as they do now.
Current Activities and Current Exceptions
The existing Current Activities and Current Exceptions screens will be ported to the new application. In all ways they will act as they do now.
REFERENCES
| EST-276897 AS-856KX8 Enhanced Cross Dock Functionality v1.0.doc |
DOCUMENT HISTORY
| Initial draft | ||||||
| After review in Stoke with client | ||||||
| Added Location Validation | ||||||
| Amended overview section; slight change to 401 message layout to conform with 402. | ||||||
| Add field lengths in layouts.
Updated WCS layouts to reflect interface layout definitions. Changed to Functional Specification layout. Added sections from Estimate document and included reference. Added Operational Flows sections from Visio document. |
| |||||
| Accepted all review changes so far and spell-check.
Added Location Check layouts. |
| |||||
| Revised as v1.0 | ||||||
| Set the CONSIGNMENT_NO to 20 characters in length for all messages. |
AUTHORISED BY
| Dave Meie | Project Manager | |
| Tony Walker | OBS Consultant |
