276898
276898 - AS-856KTV/ WCS Interface for Dunelm
Copyright OBS Logistics © 2011
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
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
We will use as much of the existing WCS interface functionality out of the oracle WMS system as we can.
The file structures and the mechanics for passing information to and from WCS will remain unchanged and only the message types and contents will be changed.
The first task will we be to get this setup copied over and working in the MTS development database with a test WCS system.
(See specification for 276897 for more details about how the WCS side of this setup will work).
NB) WCS will only be used on the Dunelm database for the National Sortation Centre (NSC) but the design needs to take into account the possibly of extending this to further depots.
Modify existing WMS inbound process to process new messages to MTS received from WCS. Modify existing WMS outbound process to collate and send the new messages to WCS from MTS.
There are going to be 3 main areas of interaction between WCS and MTS :-
Receipts (outbound pre-advice and inbound confirmation and completion) Moves (outbound requests and inbound confirmation) Loading (outbound requests and inbound confirmation and completion)
Additional data that needs storing in MTS to accommodate these messages include :-
New location maintenance (internal locations in NSC including bays, floor and quarantine) Current Receipt Bay for Inbound Trips / Despatch Bay for Outbound Trips Current Location for Orders Current Location for Order Items
New outbound process to run nightly to provide WCS with a Pre-Advice for receipts expected that day. (Trigger to request re-send of data for inbound trips if anything is modified on MTS after the original send ?). Once the receipt completion message is received then as part of this process it will need to generate requests moves for all of the order items (grouped at order level) from the receipt bay to an appropriate location whether it is the floor or a despatch bay.
Despatch bays are going to be assigned to an outbound trip either manually or automatically.
When a despatch bay is manually assigned to an outbound trip then moves will be generated for all of the associated orders to move the items from their current location to the appropriate despatch bay.
NB) If manually changed when already set (or blanked) then new moves would need generating to move from the original despatch bay back to the floor or a new despatch bay and if not yet moved then the existing moves would need changing from the current location to the new despatch bay or deleting and left in the current floor location.
For automatic then a process will be running regularly checking for free despatch bays and determining the next outbound trip that is due for departure (and has not yet been assigned a despatch bay) and assigning this free bay to this trip which as above would then automatically generate the moves for all of the order items on this outbound trip from there current location to this bay.
NB) Unless the outbound trips are planned before the collection trips start arriving then there will never be any moves out of the receipt bay directly into the despatch bay. We may need a spin of paragon for planned deliveries in the morning and then a re-spin of paragon in the evening after the suppliers have confirmed the orders which will then be append the collection orders to the already planned delivery trips.
Once all of the items for all of the orders that are on an outbound trip are confirmed as being moved to the despatch bay then a loading request can be sent to WCS.
Scope
This change will be applied to system version 10.6.
FUNCTIONAL DESCRIPTION
Message Flows
There are 5 main areas of functionality required at the National Sortation Centre (NSC).
Receipts
Suppliers are providing goods which are collected by DHL and then received on an inbound trip into the NSC.
Movements
The goods are moved within the NSC
Loading
Checking that the goods are ready for loading onto an outbound trip from the NSC to the Dunelm stores. Including trip departure when an outbound trip leaves the NSC (trip status to ‘EN-ROUTE’).
Location Validation
Validation of the location for when WCS operators have to key the location code.
The receipt process is made up of 3 flows (outbound pre-advice, inbound confirmation and inbound completion), the movement process is made up of 2 flows (outbound requests and inbound confirmation) and the loading process is made up of 4 flows (outbound requests, inbound confirmation, inbound completion and outbound trip departure).
The flows are as follows :-
--Pre-Advice Receipt (401)==
A process will be written to run overnight to provide the WCS system with the details about what receipts that they can expect to arrive that day.
It has been decided that all outbound messages to WCS will be controlled from a single database job in a similar way to the outbound XML process. This means that this pre-advice receipt process (and all other outbound processes) will simply write a record to a new control table (WCS_OUT_CONTROL – see appendix A for details) which will then be picked up, the data collated and the outbound WCS message built by the standard process (see WCS Outbound Message Process section for details).
NB) The 401 message request generated here will always be at trip level so OMS_REF will be blank. For order level requests then the OMS_REF will be populated
This process will loop through all trips at status ‘ACCEPTED’ that are planned to arrive at the NSC location that day.
It will also check that some ‘Unload’ haulage activity records exist for this stop.
For each trip it finds that meets this criteria it will write an appropriate record to the WCS_OUT_CONTROL table for Message_Type 401.
(See section ‘WCS Outbound Message Process’ for layout of actual 401 message).
It is possible that some sort of update messages are required for when orders or trips are amended and also possibly for short collections.
This needs further investigation and the final solution has not yet been decided upon.
Goods Receipt Confirmation at Item Level (801)
A single WCS operator will be assigned the entire task of checking all of the goods received on each inbound trip.
They will firstly have scanned the trip sheet provided by the driver which will tell them which inbound trip that they are dealing with and using this to link back to the pre-advice data already provided then WCS will be able to confirm what is being scanned against what was expected to be received.
They will also have scanned the receipt bay number that the inbound trip pulled into (may be assigned manually by the gatehouse or warehouse manager).
NB) If for whatever reason they are unable to scan the receipt bay number then it can be entered manually and validated by the standard location enquiry interface (see later sections Location Validation Request and Response).
As each item is scanned then this message will be sent to MTS informing us that it has been scanned successfully.
The message will be written to the WOC_IN_CONTROL table for display on the new WCS interface errors form (or possibly just use MSG_LOG ?).
It will have some standard validation with any appropriate error descriptions written against a failed message (or possibly just use WCS_EXCEPTIONS ?).
The first successful item message by MTS received for an inbound trip will be used by MTS to update the receipt bay number on the trip.
The item message will then be used by MTS to update the current location of the item (using Item ID) to be the receipt bay number so long as the trip matches the one that we are expecting it be received on.
NB) If it is an item that should not have been received on this trip then WCS will get the item automatically moved to the sin bin area.
Once all of the items for a single order are received and updated in MTS as being in the receipt bay then this will also update the order with the same receipt bay number.
The item level receipt message passed by WCS to MTS will be in the format of :-
NB) Status of ‘RC’ is when the receipt has been completed.
Message received will be in the format :-
Goods Receipt Completion at Trip Level (801)
Once all of the items have been scanned for the entire trip then a receipt completion message will be sent by WCS for the inbound trip.
This message will be in exactly the same format as the item level 801 but will contain different information.
The message will be written to the WOC_IN_CONTROL table for display on the new WCS interface errors form (possibly ?).
It will be used by MTS to generate the any necessary non-conformity’s for the orders that have not been fully received and scanned (i.e. Any orders on the trip which have not had its current location updating to match the receipt bay on this message).
Non-conformities will be generated at order level (SCH_ORD_NON_CONFORM saying ‘Receipt confirmation into the NSC failed see the item level for more details’) and at order item level (SCH_ORD_ITEM_REASONS saying ‘Receipt at NSC failed’) will be created.
The message will be also be used by MTS to determine were all of the goods that are now in the receipt bay need to be moved too (see section Movements within Warehouse).
The message layout for the receipt confirmation will look like :-
Movement within Warehouse (411)
There will be 2 types of automatically generated moves within the warehouse.
The moves out of the receipt bay once the inbound trip has been receipt confirmed and the moves into the despatch bay when a bay becomes available and an outbound trip is ready to be prepared for loading.
There can also be some manual moves :-
Orders moved into the quality control area, out of the quality control and out of the sin-bin area. Manually setting of the despatch bay on an outbound trip (set, change and blank).
Moves Out of the Receipt Bay
Once MTS has been updated by the previous WCS flow to indicate that a receipt for an inbound trip has been confirmed then all of the items for all of the receipted orders on the inbound trip will need moving out of the receipt bay.
An outbound control record (WOC) will be written at trip level to inform the standard outbound WCS message that move messages need to be created for this trip.
It will have a MOVE_TYPE set to ‘R’ to indicate that it is a move of an inbound trip out of the receipt bay.
See section ‘Move Request Message’ for format of this message and all generated move messages.
Automatic Moves to the Despatch Bay A database job will be run every 5 minutes (or so) to check the planned departure times for the outbound trips (any trips planned to depart in the near future), the availability of the despatch bays (any bays free) and the availability of all of the orders on the outbound trip (none of the orders are currently in the sin bin or quality control location and are not planned to be moved into quality control).
NB) Orders still in the sin bin or quality control locations need manual intervention before they would be automatically assigned a despatch bay.
If it meets all of the above criteria then the free despatch bay will be assigned to the outbound trip (ST.CURRENT_BAY).
It will create a WOC record with a MOVE_TYPE set to ‘O’ for this trip to indicate that the goods for this trip now need moving out to the despatch bay.
This record will then be processed by the standard WCS outbound process (see later section).
Manual Moves There will also be a requirement for manual moves within the warehouse.
Order Level
There will be several types of manual moves within the MTS system that can be requested at order level.
It may be decided by DHL that the goods for an order need to be checked by the quality control team.
This will be achieved by manually setting the move location on the order (SCH_ORD.MOVE_LOCATION) to be the quality control location.
If the order has not yet been received into the NSC then the receipt confirmation will take care of the move into the Quality Control (QC) location but if it is already in the NSC then moves will need to be generated to move the items from their current location into QC.
It will create a WOC record for the order with a move type of ‘Q’.
Once the quality control team have finished inspecting the order in QC then they will manually request that order has to be moved out of QC and back to the Grid.
This will be achieved by manually setting the move location on the order (SCH_ORD.MOVE_LOCATION) to be the ‘GRID’ indicating that it needs to be moved back into the grid.
It will create a WOC record for the order with a move type of ‘C’.
When orders are short received then they will automatically be moved into the Sin Bin (SB) location by the receipt confirmation process.
If the missing items are received on a later trip, are already in SB from an earlier trip or DHL decide along with the store that they are happy for a short delivery then they will need to manually move the order into the grid (or to QC if required).
This will be achieved by manually setting the move location on the order (SCH_ORD.MOVE_LOCATION) to be the ‘GRID’ indicating that it needs to be moved into the grid or to QC location code.
It will create a WOC record for the order with a move type of ‘S’.
NB) If it needs moving out of SB to QC rather than to the grid then a move type ‘Q’ would have been created rather than ‘S’.
All of the above move messages will then be processed by the standard WCS outbound process.
Trip Level
DHL might decide that they want to prioritize an outbound trip and start the loading of this ahead of the normal time (i.e. not waiting for the automatic assignment of the trip to a despatch bay).
This will be done by manually setting the despatch bay on an outbound trip (SCH_TRIP.BAY_NUMBER) to be a free despatch bay.
Checks will be made to ensure that none of the orders are currently in the SB or QC but this will only be a warning and can be overwritten ?
It will create a WOC record for the outbound trip with a move type of ‘O’.
They may also want to manually change which despatch bay is going to be used for an outbound trip.
This will not need to do the additional checks on the orders as they will have already been performed when the original despatch bay was assigned.
It will also create a WOC record for the outbound trip with a move type of ‘O’.
Both of these will run exactly the same code in standard WCS outbound process as the automatically generated despatch bay moves as it needs to behave in exactly the same way.
Another possibility is that DHL decide that an outbound trip that had already been assigned a despatch bay is not yet ready to be loaded so they want to move the orders already moved to the despatch bay back to the grid to free up this bay.
This will be achieved by the user manually blanking the despatch bay against the outbound trip.
It will create a WOC record for the outbound trip with a move type of ‘P’.
Confirmation of Movement (811)
As each item is moved into its new location then WCS will confirm that the move has been completed.
The message will be written to the WOC_IN_CONTROL table for display on the new WCS interface errors form.
MTS will use this confirmation to update the current location of the item.
If this still does not match the move location of the order (i.e. a second move has been requested since the original request was sent) then a new move request will be generated to further move it to the new location (create a WOC record for message 411 but at item level and with a new move type ‘I’).
NB) Grid moves will just contain ‘GRID’ on the order move location (SO.MOVE_LOCATION) so when the first item is moved successfully then this can be updated to match the grid location confirmed by WCS.
Once all items are confirmed for an order then the current location of the order can be updated to match and the move location can be blanked (if confirming this move and not a previous move i.e. SO.MOVE_LOCATION = Destination Location from message).
Check Loading (402)
This will be used as both a check of the items in the despatch bay to ensure that all of the items expected to be loaded onto the truck are present and also as confirmation that a load has been completed.
The generation of these messages may be controlled automatically by either the last move to the despatch bay for the entire trip being confirmed (see previous message), on a timer so when we are getting closer to the planned departure time for the outbound trip or possibly on a manual trigger when the truck physically arrives (or trailer is moved into the despatch bay).
Last Move to Despatch Bay
When the last item for any order is confirmed as having been moved successfully into a despatch bay then the current location for the order will have been updated to match this despatch bay.
A further check will now be carried out to see if all of the orders on the same outbound trip have now been confirmed as having been moved into the despatch bay.
Once it has confirmed that all of the orders have been moved successfully into the despatch bay then we can generate the loading messages.
We will create a WOC record for the 402 message for the outbound trip.
This will then be processed by the standard WCS Outbound Interface process.
Confirmation of Load (802)
A single WCS user will be assigned the entire task of checking all of the goods to be despatched on the outbound trip.
As each item is scanned then this message will be sent to MTS informing us that it has been scanned.
The message will be written to the WOC_IN_CONTROL table for display on the new WCS interface errors form.
This will be used my MTS to update the current location of the item to be ‘TRANSIT’ to indicate that it has now left the NSC.
Once all items are confirmed for an order then the current location of the order can also be updated to say ‘TRANSIT’.
The message received will be in the format of :-
Completion of Load (802)
Once all of the items have been scanned for an outbound trip then a completion message will be sent by WCS.
The message will be written to the WOC_IN_CONTROL table for display on the new WCS interface errors form.
MTS will then check that all orders on this outbound trip have been updated to the correct despatch bay.
If any orders are in the incorrect location than an appropriate error message will be saved against the message and a non-conformity raised.
Non-conformities at order level (SCH_ORD_NON_CONFORM saying ‘Loading confirmation out off the NSC failed see the item level for more details’) and at order item level (SCH_ORD_ITEM_REASONS saying ‘Loading at NSC failed’) will be created.
The confirmation message
NB) Status ‘LC’ is when the loading was completed OK and ‘LE’ is when an error occurred during the loading process in WCS.
Trip to En-Route (403)
Whenever a outbound trip from the NSC is set to status ‘EN-ROUTE’ either manually or by the setting of the actual departure time from the NSC then a message is required to be sent to WCS system so that they can ensure that there are no outstanding requests for this trip and can tidy them up if necessary.
A record will be written to the WOC table for the 403 message at trip level.
This will then be processed by the standard WCS outbound interface process.
Location Validation Request (821)
Normally when an RF operator is sent to a location then the bar code for this location will immediately be scanned to validate that they are physically in the right location.
If for whatever reason they are unable to scan the location (bar code has been corrupted) then they need the ability to manually type in the location ID.
In most circumstances this can then be validated internally in WCS as the valid location is already known but when moves are being made to the Grid area then it is being left up to the operator as to which grid location the move is placed into so WCS can not validate it.
The 821 message will be written to the WOC_IN_CONTROL table for display on the new WCS interface errors form.
This manually entered grid location needs to be checked as a valid location within MTS so an appropriate message (821) will be sent and it will expect a response message (421) to be returned very quickly.
The format for the 821 message will be :-
Location Validation Response (421)
Once an 821 request (see previous section) has been received then a 421 message will immediately be generated.
It will check that the Location_ID entered in WCS exists on the WCS_LOCATION (WL) table.
The format for the message will be :-
NB) Status will be ‘Y’ if valid and ‘N’ if invalid.
Other possible values are ‘A’ when valid but not active.
Possible need to pass the location type as well so we can check that they are trying to use the right type of location.
Status could pass back ‘T’ for when the location is valid but it is the wrong type ?
WCS Outbound Message Process
A single data base (or one per Depot ?) will run regularly to pick up all messages that are waiting to be sent to WCS (WCS_OUT_CONTROL (WOC) records were PROC_FLAG is NULL).
It will create the WCS messages for the message type and specific Trip/Order/Item updating the control to set Proc_Flag to ‘Y’ once generated.
Before it process’s the message for each type it will need to double check that the related WCS advanced queue is active and started for this message type and depot (NSC).
Depending on the message type it will do one of the following process’s.
Pre-Advice Message (401)
If the request message is at Trip Level (i.e. TRIP_ID is set) then the code will need to loop through all of the ‘Unload’ haulage activities for that trip at that depot (NSC) and for each order then loop through all of the related items.
Check SCH_TRIP_STOP records for the trip with a LOCATION_ID (WOC.DEPOT).
Check SHA_HAULAGE_ACTIVITIES (SHA) for this stop (STOP_ID matches and ACTIVITY_NAME is ‘Unload’).
For every activity found then for each order (OMS_REF) it will need to get the corresponding order header (SCH_ORD with matching OMS_REF).
For every order (SO) then retrieve all of its corresponding item records (SCH_ORD_ITEMS with matching OMS_REF).
For every item found (SOI) then build a corresponding message string and send it to the WCS system.
The message will be populated as follows:
Loading Message (402)
A request to send loading messages for an outbound trip will have been generated.
The process will get all of the orders (get STS using WOC.TRIP_ID, link to SHA using STS.STOP_ID and SHA.ACTIVITY_NAME = ‘Load’ to get SHA.OMS_REF also STS.DEPART and ST.BAY_NUMBER) that are being loaded onto this outbound trip.
It will use the bay number to retrieve the related WCS_LOCATION (WL) record for the check digit.
For every order being loaded it then needs to get the order information and its items (get SO and SOI via OMS_REF).
For each of these a message will be sent to WCS for load checking.
The message will be in the format of :-
Outbound Trip Departed Message (403)
When an outbound trip leaves the NSC (trip status goes to EN-ROUTE) then a request for a 403 message will have been generated.
It will link the ST and STS records (via WOC.TRIP_ID and STS.STOP_TYPE = ‘SU’) to get the actual departure time and the bay number.
It will use the bay number to retrieve the related WCS_LOCATION (WL) record for the check digit.
The message will be at trip level only and will be in the following format :-
Move Request Message (411)
There will be various types of moves requested identified by the MOVE_TYPE field on the WOC record.
If the MOVE_TYPE is set to ‘R’ then this indicates that it is a move of an inbound trip out of the receipt bay.
If the MOVE_TYPE is set to ‘O’ then this indicates that an outbound trip is being moved to a despatch bay ready for loading.
If the MOVE_TYPE is set to ‘Q’ then this indicates that an order is being moved to the quality control location for inspection.
If the MOVE_TYPE is set to ‘C’ then this indicates that an order is being moved out of a QC back to the grid.
If the MOVE_TYPE is set to ‘S’ then this indicates that an order is being moved out of the Sin Bin location into the grid.
NB) If it is being moved to QC then it would have been a ‘Q’.
If the MOVE_TYPE is set to ‘P’ then this indicates that an outbound is being moved out of a despatch bay back to the grid.
NB) If it was being moved to another despatch bay then it would have been an ‘O’.
If the MOVE_TYPE is set to ‘I’ then this is an automatically generated move at order item level caused by a second move being requested whilst the first move was still in progress.
Moves Out of the Receipt Bay (R)
For each order on the inbound trip (link via TRIP_ID to ST and STS, via STOP_ID to SHA and finally OMS_REF to SO) it will firstly check to see if the current location (SO.CURRENT_LOCATION) for the order matches the receipt bay (ST.BAY_NUMBER) for the inbound trip.
If it is blank (i.e. not all items have been scanned by the receipt process) then all of the items (link via OML_REF to SOI) that are currently in the receipt bay (SOI.CURRENT_LOCATION) will need moving to the sin bin area and a move request will be generated for each item to be moved from its current location (receipt bay) into the sin bin area.
NB) A move will not be generated if the item does not have a current location (not yet scanned into NSC).
It will next check to see if the order has been manually set to be moved into the quality control area (Move Location on the order is set to Quality Control).
If it has then a move will be generated for each item on the order to be moved from its current location (receipt bay) into the quality control area.
It will next check to see if the order is planned onto an outbound trip and also if that outbound trip has already been assigned a despatch bay.
If it does have a despatch bay the moves will be generated for the items to the despatch bay.
If not then moves will be generated to the Grid area using a location to of ‘GRID’ as the location itself will be decided by the operator which will be at either outbound trip level (if one has been assigned) or at store level.
As well as generating the moves requests as below it will also update the move location (SO.MOVE_LOCATION) on the order to match the proposed move to location.
The planned departure time for the outbound trip will also be provided to help WCS prioritize its movement requests.
The check digits for the from and to locations will also be retrieved from WL and passed to WCS
NB) Move Type can be :- (Q)uality Control, (S)in Bin, (G)rid, (O)utbound.
Trip Moves to Despatch Bay (O)
Once it has been decided to move the goods for an outbound trip into a despatch bay then for each order on the outbound trip (link via TRIP_ID to ST and STS, via STOP_ID to SHA and finally OMS_REF to SO) it will update the move location (SO.MOVE_LOCATION) to match this despatch bay and then generate move requests for all of the items (link via OMS_REF to SOI) to this new location.
The fields for the WCS message will be identical to the previous section except that Location_To field will always be set to the despatch bay and the Move_Type will always be ‘O’.
Order To Quality Control (Q)
Any order items (linked via OMS_REF to SO and SOI) that have a current location (SOI.CURRENT_LOCATION is not blank) for the order (WOC.OMS_REF) being moved need a move record generating to the Quality Control location (double check that it is not already there).
Only one quality control location should be setup for the NSC and will be identified from the WCS_LOCATION table where the LOC_TYPE is ‘Q’.
NB) It could also double check that the order still needs moving to QC.
i.e. SO.CURRENT_LOCATION is not QC and SO.MOVE_LOCATION is QC.
The messages generated will look like :-
Order From Quality Control (C)
Double check that the order to moved (link to SO via OMS_REF from WOC) is still in QC (SO.CURRENT_LOCATION = <QC>) and that it is being moved into the grid (SO.MOVE_LOCATION = ‘GRID’).
Also double check that all of the items for the order (link to SOI via OMS_REF) are also still in the QC (SOI.CURRENT_LOCATION = <QC>).
It will also need to see if the order has been planned onto an outbound trip (link to SHA via SO.OMS_REF with an SHA.ACTIVITY_NAME = ‘Load’, to STS via SHA.STOP_ID with a STS.LOCATION_ID = <NSC> and if exists then use STS.TRIP_ID and also STS.DEPART).
It will then generate a move request for each of the orders items from QC to the ‘GRID’.
The messages generated will look like :-
Order From Sin Bin to Grid (S)
Only one Sin Bin location should be setup for the NSC and will be identified from the WCS_LOCATION table where the LOC_TYPE is ‘S’.
Double check that the order to moved (link to SO via OMS_REF from WOC) is still in SB (SO.CURRENT_LOCATION = <SB>) and that it is being moved into the grid (SO.MOVE_LOCATION = ‘GRID’).
Also double check that all of the items for the order (link to SOI via OMS_REF) are also still in the SB (SOI.CURRENT_LOCATION = <SB>).
It will also need to see if the order has been planned onto an outbound trip (link to SHA via SO.OMS_REF with an SHA.ACTIVITY_NAME = ‘Load’, to STS via SHA.STOP_ID with a STS.LOCATION_ID = <NSC> and if exists then use STS.TRIP_ID and also STS.DEPART).
It will then generate a move request for all of the orders items.
The message generated will look identical to the ones generated by the previous process.
Trip Moves out of the Despatch Bay to Grid (P)
If an outbound trip is being moved back to the grid from a despatch bay then all of the orders on that trip need moves generated.
Get the planned depart time from NSC for the outbound trip (WOC.TRIP_ID to STS where STS.LOCATION_ID = <NSC> and STS.STOP_TYPE = ‘SU’ to get STS.DEPART) to use later.
For each order (link WOC.TRIP_ID to STS with STS.LOCATION_ID = <NSC> and STS.STOP_ID to SHA with ACTIVITY_NAME = ‘Load’ to give SHA.OMS_REF which links to SO) on the outbound trip update the move location (SO.MOVE_LOCATION = ‘GRID’) unless it is already set to SB or QC.
For each item on the order (OMS_Ref to SOI) then generate a move request.
The messages generated will look like :-
Item Level Moves (I)
This will retrieve the related SOI record (via WOC.ITEM_IDENTIFIER), SO (via WOC.OMS_REF) and possible related outbound trip (link to SHA via SO.OMS_REF with an SHA.ACTIVITY_NAME = ‘Load’, to STS via SHA.STOP_ID with a STS.LOCATION_ID = <NSC> and if exists then use STS.TRIP_ID and also STS.DEPART).
It will generate a single 411 message with appropriate values .
The messages generated will look like :-
MTS Changes
New form called WCSMAINT to be used for maintaining all of the standing data required for the WCS interface process.
The first tab on this form will be called ‘Loc Type’ and will be used for maintaining the new table WCS_LOC_TYPE to hold a list of valid WCS location types.
Examples of possible data are :-
Location Type Description
R Receipt Bay
D Despatch Bay
S Sin Bin
Q Quality Control
G Grid Locations
NB) The location type should not be changed from these values as the code embedded in MTS will rely on these types but the description will be free text.
The next tab on this form will be called ‘Locations’ and will be used to maintain WCS Locations.
The Location ID must be a unique value.
The Location Type will be a dropdown list from the values entered on the previous tab.
The Location Status will also be a dropdown with possible values :-
N – Broken/Not Accessible
Y – OK for manual assignment
A – OK for automatic assignments (Despatch Bays only)
Maintain the bay number against trips (inbound and outbound).
Maintain current location against SOI and SO level.
Maintain move location against the order.
NB) Once all items have been moved to the matching current location then the current location on SO becomes the move location and the move location becomes null.
Additional Quality Check (QC) flag required against the order (or just manually set move location to QC) ?
WCS Control enquiry (selection by message type and include successful messages) for Inbound and Outbound.
An additional issue that we may need to change as part of this development is when quantities on SOI are changed manually then the corresponding values on SOL and SO should be updated automatically.
Does this include adding and deleting items ?
WCS Interfacing Technical Details
Extract and modify as required the code from D770 (also see functional specification for 276897 for more details).
DP_AQ (APP_REC – Depot to Queue)
DP_RDT
DP_WMS_IF (Renamed DP_WCS_IF)
Forms :-
New Form called WCSINTF will be created for the WCS interface information containing tabs to duplicate the code from the existing WMS forms.
WHS7920 – Start and stop interfaces at message type level for each location (WARE_RDT_STATS)
WHS7900 – Infos and Exceptions (WCS_EXCEPTIONS)
User Maint and Interface ?
Depot Rules ?
User Groups ?
Separate Receipt, Move and Loading maint/enquiries ?
OR single enquiry with message type selection ?
Current Activities and Exceptions ?
REFERENCES
Not Available
DOCUMENT HISTORY
| Initial version | ||||
| Added LOCATION_CD to the 401 message | ||||
| Set CONSIGNMENT_NO and ITEM_ID to 20 characters in length for all messages |
AUTHORISED BY
| Dave Meir | Development Manager | |
| Peter Greer | TMSCC MTS Product Manager |
