281758
281758 - AS-89SCDZ/ Unload Scans
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
Change XDock Functionality
Part 1 – Goods Receipt
To change WCS to enable the receipt of any DU regardless of consignment, collection manifest or inbound trip as long as it is has been manifested by a supplier and is on the list of pre-advices within WCS.
Note – ops team to clear down old orders from this list at the end of each week.
Have the ability to report on DUs not received against their planned collection day.
Once DUs have been scanned at receipt they should be available to move before the receipt of the load has been completed in WCS. As receipt functionality has been opened up to receive from a list of DUs it is acknowledged that this will remove the ability to log a short DU at receipt and a historical report will be required to highlight DUs not received that day.
Maintain scan of trip number, then scan of inbound location and then scan of each DU off the trailer. When each DU is scanned it is confirmed received and is available for movement. Unexpected (not on pre-advice list) DUs scanned will return an error message to direct DU to SINBIN.
If a DU is noticed damaged at receipt the user should scan the DU to receive it but then use a function key command to mark the DU as 'damaged' and the moves process will move this DU to the SINBIN.
Requirement to back out of unloading using ESC at any time leaving what has been scanned as received actually received and what has not been scanned not received. Requirement to differ between DUs which are outstanding for receipt and missing from receipt. Ensure that the current functionality, in terms of being able to be received by trip against a specific set of planned orders, is retained under a separate function on the HHT not available on the menus so that it could be introduced at a later date if required.
Solution
High Level Summary of Solution
The existing C-TMS and WCS solution already developed should be retained but ‘switched off’ where appropriate in favour of the revised functionality requested. The revised functionality is designed to allow the X-dock process to flow more quickly and efficiently while retaining the appropriate checks and audit trail to allow throughput of volume, exceptions, shortage and overage to be measured.
The principle control and constraint of the existing solution to ensure a complete consignment is unloaded, moved and shipped together will be removed and much more emphasis placed on a more fluid unload, move and load based on each individual DU labelled item.
The operation will unload the vehicle and scan each DU off the inbound vehicle. Some sortation will be done manually as the vehicle is unloaded to prepare the product for moves to despatch lane for loading out of the facility. Moves will be initiated by the user scanning ‘what he sees’ rather than being instructed to find specific consignments.
Load checking functions will be removed altogether; the operation deems this to be time consuming and the benefit of a full load reconciliation at this stage not necessary.
Loading will become more fluid in that loading can be commenced ahead all of all DU’s being moved to the despatch lanes. The discipline of reverse drop loading will be retained to facilitate box trailer loading for multi-drop trips.
The underlying principle remains that product received should be loaded through the night and a clear floor policy promoted.
The system will retain a SINBIN for unrecognised items and damages. The GRID concept will be retained but as a generic area of the facility rather than a specific transient set of locations by trip or store. This removes the need for ‘follow-me’ logic into the grid area.
The QC area will be retained and orders will be diverted for QC check. This is still likely to place an additional transit day in the facility and delay the delivery of these orders by 24hrs.
Part 1 – Goods Receipt
C-TMS will send a pre-advice of each Order DU to WCS. WCS scanning will validate the receipt of each item received by reference to the pre-advice data, send the confirmation of receipt to C-TMS and continue to the next scan.
The logic controlling pre-advice sent to WCS and WCS management of the pre-advise will change as follows;
As a supplier manifest is confirmed and closed, the content of the manifest (order DUs) will be pre-advice messaged to WCS. Once the manifest is planned onto a C-TMS trip, the associated trip information will be pre-advice messaged to WCS. This means WCS will store all DUs manifested and trip planned for ‘current’ planning and collections received on or off plan.
The RDT goods receipt process will continue to be initiated by scanning the trip (or keying the trip number) and scanning (or keying) the unloading bay number. The operator can then scan every item from the inbound trailer. As each item is scanned, a receipt confirmation message will be sent to C-TMS and the item will be available for move transactions to be generated.
(As an interim step to allow revised receipting to be implemented without the new moves logic, the receipt message will immediately set the item scanned as moved to the appropriate despatch lane based on delivery plan, or failing that the lane associated with the store from the delivery plan. This will remove the need for OBS to run the utility script to set the data into this state).
Once the operator is satisfied that the un-load is complete and all items are receipt scanned, he confirms complete on the RDT. WCS will instruct the operator of any missing scans (a list of items) according to plan and supervisor override will be required to finish.
At any point during the receipting a function key will be available to allow the operator to mark the item on system as damaged.
Any items scanned not belonging to the trip will be positively received into the facility on system and marked as overage for the trip.
Any potential shortage identified from closing the unloading of the trip (with supervisor override) will be measured at end of day. It is recognised that short items could be received on another unload on the same or subsequent days.
As items are positively scanning into the facility, the WCS pre-advice will be cleared item by item once the unloading of the respective trip is completed and confirmed on the RDT.
Any items scanned and not recognised by WCS from the pre-advise table will be requested to be immediately moved to SINBIN for further investigation. Any double scan of the same item will be shown on the RDT during unloading of the trip and the operator asked to scan the next item. Otherwise, if the same item is scanned for unload again after completing the trip, logically no pre-advice will be available and the operator will be instructed to move the item immediately to SINBIN. (An enquiry scan to be developed under a separate RIO CR will allow the item to be interrogated and identified as potentially already shipped).
C-TMS will be required to process overage scans. The item and it’s order header will be planned to the trip it was physically unloaded from. This potentially means splitting the order to a new OMS reference while retaining the original SAP order number. This functionality will support receiving part orders over different trips on the same day or subsequent days. Following this, the orders will be planned or re-planned automatically by C-TMS (not Paragon) to the next day’s delivery plan as appropriate. If the item is received on another trip on the same planned collection day, the assumption is that no re-plan of the delivery is necessary. If received late, the item will be re-planned from the original delivery trip to tomorrow’s store trip and if received early, planned for the first time to tomorrow. If more than one store delivery trip exists, the re-planning will use the least utilised trip (by planned DU qty).
There is a potential timing issue in that C-TMS is making these re-planning adjustments early evening as vehicles are being unloaded and at the same time that Paragon planning is occurring. The C-TMS – Paragon interface will be modified to exclude manifests (or part thereof) already received early, both when interfacing unplanned manifests to Paragon and also when updating the Paragon plan back into C-TMS.
Shortages will be available for review each day through new reporting to be defined. Shortages could be resolved by an overage receipt on another trip on the same day inbound or over subsequent days. The operation will recognise a ‘true’ short after a period of days elapsed to be defined.
A system parameter of elapsed days will be introduced, for example set as 7 days but configurable, which will control the length of time an item pre-advised to WCS is available for receipt. If an item has not been received after this 7 days, the respective pre-advice transaction will be deleted. If an item then does arrive at the X-Dock but cannot be recognised through scanning, the operator will immediately be requested to move the unrecognised item to SINBIN.
If a delivery is missed and the trailer unloaded back into the X-Dock, according to the rules defined above, the pre-advice will have been deleted so the operator will be requested to move directly to SINBIN. A function will be developed in C-TMS to undo the original delivery trip stop, part of debriefing the delivery trip. The items will then be moved to the normal despatch lane for the store (or to additional dedicated vehicle). Load scanning will treat these items as overage and will C-TMS will auto-plan them to the new delivery trip. Alternatively, the items will fall into the next Paragon plan for delivery and follow the normal moves process to despatch lane.
Considerations and Risks.
Items will be available for receipt, x-dock and shipping to stores individually and not held and constrained by moving as full orders.
C-TMS will spilt orders to allow constituent items to be receipted, x-docked and shipped over several days. The split could be considered an operational part rebooking. The orders will retain the original SAP order reference but will be unique by the internal OMS reference.
Early receipting (of unplanned orders) could happen while Paragon is planning the same orders for collection tomorrow. The C-TMS planning interface needs to manage these potential conflicts (i.e. not plan something for collection already received).
The validation utilised by the Zetes store receiving system needs to be reviewed. It is important that stores can receive part orders over successive days, that item deliveries can be early, late or on-time based on expected in-store date issued by SAP. It is assumed that the C-TMS electronic manifest of all items scanned onto a delivery trip can be received by Zetes so long as the trip (and its loaded DUs) do arrive at store on the expected planned day.
Scope
This change will be applied to system version 10.6.
The estimate below covers the following developments and enhancements;
Revised C-TMS pre-advice based on manifested orders and trips
WCS management of pre-advice data including clear-down after x days system parameter
WCS revised receipting process on RDT including damage notification
C-TMS splitting and re-planning collection where necessary to accommodate early receipts and receipts on wrong trip.
C-TMS planning and / or re-planning deliveries based on early or late receipt into X-dock
C-TMS report of receipts and receipt exceptions daily
C-TMS report of recognised shorts after time-out period
Removal of Load Checking function from C-TMS and WCS
Note – Requirements gathering (meetings) has been purposefully excluded from this estimate; costs will be managed separately.
FUNCTIONAL DESCRIPTION
Outbound 431 : Pre-advice for Orders at Item Level
As soon as an order has been confirmed by the Manufacturer via the web portal then this new message will be sent to the WCS system to prepare it for the items to be received and unload scanned into the National Sortation Centre.
The new code will be added to the existing TRG_SOM_SUPP_CONF trigger on the table SCH_ORD_MANF which is where the web portal stores its values.
When the order is confirmed (SUPPLIER_CONFIRMED set to ‘Y’) then check to see if the 431 message is active.
If it is active then it will write a record to the WCS_OUT_CONTROL at order level for the new 431 message.
The standard procedure DP_WCS_IF.PR_READ_WOC_TABLE will be enhanced to include the call to some new code to produce the new message.
It will need to call the new procedure ‘SEND_WCS_MANIFEST_PREADV’ which will be added to a new package DP_RDT_PREADVICE to create the message.
The code will loop through all of the items (SCH_ORD_ITEMS – SOI) for the order (SCH_ORD – SO) being processed and generate a message for type ‘TY_WMS_MANIFEST_PREADV‘ with the following values :-
Outbound 432 : Pre-advice for Trips at Order Level.
As soon as a collection trip is set to status ‘EN-ROUTE’ then a new message will be sent to WCS stating all of the orders expected to be collected on this trip so that WCS can inform the operators when they unload scan an item that was not expected on the collection trip.
The existing trigger TIU_TRIP_STATUS on the table SCH_TRIP will be changed to check if the new message is active.
If it is active then a new record will be written to the WCS_OUT_CONTROL table at trip level.
The standard procedure DP_WCS_IF.PR_READ_WOC_TABLE will be enhanced to include the call to the new code to produce the new message.
It will need to call the new procedure ‘SEND_WCS_TRIP_PREADV’ which will be added to a new package DP_RDT_PREADVICE to create the message.
The code will loop through all of the orders for the trip being processed (linking TRIP_ID via SCH_TRIP_STOP – STS and then using the STOP_ID to link to SCH_HAULAGE_ACTIVITY - SHA) and generate a message for type ‘TY_WMS_TRIP_PREADV‘ with the following values :-
Inbound 831 : Unload Scan at Item Level.
Once an item has been unload scanned by WCS then for valid items (corresponding 431 record exists in WCS) then a new message will be passed back to C-TMS.
The standard DP_WCS_IF.RECVD_REC code will read the message.
This will need to be extended for the new message type.
It will then call the new procedure ‘RECVD_WCS_FAST_UNLOAD’ in the new package ‘DP_RDT_FAST_UNLOAD’.
The new code will then validate the data (raising appropriate error messages for missing or invalid data) before processing the message accordingly.
If this is the first message for this collection trip then the trip can be updated in C-TMS to be currently in the receipt bay passed through in the message.
There are 4 possible scenarios that need to be coded for :-
Item is received on the planned trip.
Item is received but was never planned.
Item is received on a different trip to the one that it was planned on.
Item is damaged.
Planned Trip
If the item is unload scanned against the same trip that C-TMS has it planned to be collected on then the code needs to :-
Create the positive item unload non-conformity of ‘SU’ (Successful Unload). Update the despatched (to deliver) quantities on the order item and corresponding line. Check if the order is on a delivery trip which has been assigned a despatch bay and put the item into this despatch bay otherwise put it into the default ‘GRID’ location.
Unplanned Trip
If the order has never been planned onto a trip (status is ‘UNSCHEDULED’) then :-
The item will need to be split off onto another order (either a brand new order that will need to be assigned to this collection trip or an existing order already on the collection trip with matching booking ref, external ref, from and to locations). Update old item with a prefix of ‘X’ for its item identifier. Create item non-conformity of ‘MI’ (Moved item) against old item. Create an appropriate item non-conformity of ‘EN’ (Early not planned), ‘LN’ (Late not planned) or ‘ON’ (On-time not planned) against the new item. Update the despatched (to deliver) quantities on the order item and corresponding line. If the delivery trip for the order is not yet planned then try to find an appropriate delivery trip (stopping at the correct store) and assign the order to it. Check if the order is on a delivery trip which has been assigned a despatch bay and put the item into this despatch bay otherwise put it into the default ‘GRID’ location.
Different Trip
The code for a different trip is identical to an unplanned trip except that the item non-conformities for the new item will be one of ‘EP’ (Early and Planned on a different trip), ‘LP’ (Late and Planned on a different trip) or ‘OP’ (On-time and Planned on a different trip).
Damaged Item
If the item is marked as damaged (DAMAGED_FLAG = ‘Y’) then the code will need to :-
Update the damaged flag on the item. Update the despatched (to deliver) quantities on the order item and corresponding line. Create the item non-conformity of ‘DM’ (Damaged). Put the item into the default ‘SINBIN’ location.
Inbound 832 : Unload Scan for an Invalid Item at Item Level.
The standard DP_WCS_IF.RECVD_REC code will read the message but as no action is required within C-TMS for this message then it will simply log the fact that it received a message.
Inbound 833 : Unload Task Completion at Trip Level.
The standard DP_WCS_IF.RECVD_REC code will read the message but as no action is required within C-TMS for this message then it will simply log the fact that it received a message.
Other Changes
All of the other changes mentioned in the scope section (including the changes to the WCS system) are not included in this functional specification.
REFERENCES
Not Applicable
DOCUMENT HISTORY
| Initial version | ||||
| Issued after Devt released & Live |
AUTHORISED BY
| Dave Meir | Development Manager | |
| Peter Greer | TMSCC MTS Product Manager |
