Using WCS from WMS: Difference between revisions

From WCS
VisualWikitext
(New page: = System Overview = == Operation == As can be seen from the diagram, Calidus 3''pl'' runs on an RS6000, while Calidus 3''pl''-Mobile runs on a Windows NT PC in this implementation. In th...)
 
No edit summary
Line 1: Line 1:
= System Overview =
= System Overview =
== Operation ==
== Operation ==
As can be seen from the diagram, Calidus 3''pl'' runs on an RS6000, while Calidus 3''pl''-Mobile runs on a Windows NT PC in this implementation.
As can be seen from the diagram, Calidus 3''pl'' runs on a UNIX server, while Calidus 3''pl''-Mobile runs on a Windows Server in this implementation.




Line 16: Line 18:




Both systems have an interface; Calidus 3''pl''’s is referred to as the WMS interface, Calidus 3''pl''-Mobile’s as the WCS interface. Both need transmitters (to send their messages) and receivers to get messages back. As can be seen from the diagram, Calidus 3''pl''’s transmitter process, XMIT, sends messages to Calidus 3''pl''-Mobile’s receiver program, WCS Server. When messages are being sent back to Calidus 3''pl'', Calidus 3''pl''-Mobile’s transmitter program, also WCS Server, sends messages to Calidus 3''pl''’s receiver process, RECV.  
Both systems have an interface; Calidus 3''pl''’s is referred to as the WMS interface, Calidus 3''pl''-Mobile’s as the WCS interface. Both need transmitters (to send their messages) and receivers to get messages back. As can be seen from the diagram, Calidus 3''pl ''sends messages to Calidus 3''pl''-Mobile’s receiver program, WCS Server through an Oracle Advance Queue. When messages are being sent back to Calidus 3''pl'', Calidus 3''pl''-Mobile’s transmitter program, also WCS Server, sends messages to Calidus 3''pl ''by enqueuing messages on Oracle Advance Queues in the WMS database.
 


The third part of the interface is the merge process. In Calidus 3''pl'', the MERGE consists of many processes which we route messages to using the route message processor, or RMP. RMP routes the messages to the dotted area of the RDT update programs.
The third part of the interface consists of the Merge processes. In Calidus 3''pl'', these consists of many processes which we route messages to using the Queue Reader processes. These route the messages to the Merge processes (dotted area of the RDT update programs).




So, let’s look at the progression of tasks through this system from start to finish. For this example, we’ll use a simple housekeeping pallet movement.
So, let’s look at the progression of tasks through this system from start to finish. For this example, we’ll use a simple housekeeping pallet movement.




When the task (move pallet 1 from A to B) is raised, the message is passed to the WMS Interface program, XMIT. XMIT passes to information to the WCS Server, which acknowledges receipt of the message. By acknowledging messages, we ensure that no tasks are lost between the two interfaces.
When the task (move pallet 1 from A to B) is raised, the message is passed to the WMS Interface Queue. The Queue passes the information to the WCS Server. Note: Only when the message is fully processed is this removed from the queue, ensuring messages are never lost).


Once WCS’s receiver has the message, merges the message to the database. This identifies the type of message (a pallet movement), and checks that everything is OK about the message’s contents. When satisfied of the contents, the task is put in the main WCS database, ready for use.
Once WCS’s receiver has the message, merges the message to the database. This identifies the type of message (a pallet movement), and checks that everything is OK about the message’s contents. When satisfied of the contents, the task is put in the main WCS database, ready for use.




When an RDT user requests a task, and they are to be allocated movement tasks, WCS will allocate the closest movement to that user’s location, or in priority order. In our example, this means they are given the movement we raised on Calidus 3''pl''. They are told to get the pallet 1 from location A and take it to location B, there scanning the check digits of the destination for confirmation.  
When an RDT user requests a task, and they are to be allocated movement tasks, WCS will allocate the closest movement to that user’s location, or in priority order. In our example, this means they are given the movement we raised on Calidus 3''pl''. They are told to get the pallet 1 from location A and take it to location B, there scanning the check digits of the destination for confirmation.  




Once they have completed the task, Calidus 3''pl''-Mobile sends a completion message to the Calidus 3''pl'' receiver program, RECV, which acknowledges receipt of the message.
Once they have completed the task, Calidus 3''pl''-Mobile sends a completion message to the Calidus 3''pl'' receiver queue.


The receiver passes the message to RMP, which identifies the type of message, in our example, a movement completion message. The message is then routed to the correct RDT update process.  
The Queue Reader associated to the queue identifies the type of message, in our example, a movement completion message. The message is then routed to the correct RDT update process. Again, messages are only removed from the queue when correctly processed.


The RDT update process examines the contents of the message for validity, and then updates all the Calidus 3''pl'' data files that you would expect if it was confirmed manually in the Pallet Move Confirmation screen.
The RDT update process examines the contents of the message for validity, and then updates all the Calidus 3''pl'' data files that you would expect if it was confirmed manually in the Pallet Move Confirmation screen.
Line 48: Line 49:


== System Parameters ==
== System Parameters ==
In order to send RDT messages or tasks to Calidus 3''pl''-Mobile, the Calidus 3''pl'' system must be informed that the Interface to Calidus 3''pl''-Mobile is present. This is enabled via the ‘Interface Flag’ on system parameters.  
In order to send RDT messages or tasks to Calidus 3''pl''-Mobile, the Calidus 3''pl'' system must be informed that the Interface to Calidus 3''pl''-Mobile is present. This is enabled via the ‘RDT Interface’ flag on system parameters.  


[[Image:]]
[[Image:]]




Entering 99 at the action prompt allows you identify the default locations required.
Click on the Default Locations tab to identify the default locations required.


[[Image:]]
[[Image:]]




Build up location 3 is the default putaway location, if the putaway algorithm finds no locations. Location 6 is a default marshalling lane, used by pick list and allocation.
Build up location 3 (Q/A) is the default putaway location, if the putaway algorithm finds no locations. Location 6 is a Default Marshalling Location, used by pick list and allocation.




== Owner parameters ==
== Owner parameters ==
An Interface flag also exists per Owner or Stockist. With this flag, we are able to determine whether, even if the warehouse allows RDT operations, the owner allows RDT operations.
An RDT Interface flag also exists per Owner or Stockist. With this flag, we are able to determine whether, even if the warehouse allows RDT operations, the owner allows RDT operations.




Line 70: Line 71:




== RDT Start/Stop Screen ==
== RDT Status Maintenance Screen ==
This screen is the major control screen for RDTs in Calidus 3''pl''
This screen is the major control screen for RDTs in Calidus 3''pl''


[[Image:]]
[[Image:]]


Each line controls not only the running of the update process in Calidus 3''pl'', but also the availability of the functions to standard Calidus 3''pl'' processing. So, for example, if the Pallet Receipt Update availability flag is ‘Y’, you have the ability to send receipt preadvice messages to WCS. If it is ‘N’, you can’t send those messages.  
Each line controls not only the running of the update process in Calidus 3''pl'', but also the availability of the functions to standard Calidus 3''pl'' processing. So, for example, if the Pallet Receipt Update availability flag is ‘Y’, you have the ability to send receipt preadvice messages to WCS. If it is ‘N’, you can’t send those messages.  


The use of the availability flags in the system will be explained for each sending process described in the next section.
The use of the availability flags in the system will be explained for each sending process described in the next section.


Processes can be started or stopped by entering the id number of the appropriate line, then selecting START or STOP from the selection.  
Use ‘Start Interface’ to start the RF interface programs.


In both of these cases, if you do not want to stop or start the process, choose CONTINUE from the selection.
Use ‘Stop Interface’ to stop the RF interface programs.


Other procedures can be used from the action prompt:
The light below these buttons indicates whether the interface is on or off.


* Use ‘NORM’ – This procedure checks the operating system to see if the processes are running or stopped, then updates or normalises the screen data so that it is accurate. This procedure is run on first entering the screen, and should be manually run at regular intervals whilst in the screen, to ensure the most accurate depiction of the system is displayed at all times.
* Use ‘F’ – The standard Find procedure gets the data from the file again. This will show if the update processes have changed the file. If these processes stop at any time, they will update this file to show that they have been stopped. In some cases, if these processes have changed the data, and you have not used ‘F’ or ‘NORM’, the screen may tell you to re-find the data to pick up the changes. This is normal.
* Use ‘MSG’ – This procedure starts the interface processes if they are stopped, or stops them if they are started.
* Use ‘STOP’ – This procedure stops all running update processes. It will not stop the interface processes – use ‘MSG’ for this.
* Use ‘START’ This procedure starts all stopped update processes. It will not start the interface processes – use ‘MSG’ for this.


'''The use of this screen should be limited to System Administrators only.'''
'''The use of this screen should be limited to System Administrators only.'''
Line 112: Line 108:




To perform an initial send of the data to Calidus 3''pl''-Mobile, type ‘SEND’ at the action prompt of the appropriate maintenance screen. If the interface flag on system parameters is set, the whole file will be sent.  
To perform an initial send of the data to Calidus 3''pl''-Mobile, enter the form and find data. Once found, click the Send button on the form, which will only be visible if the Interface flags for the owner and warehouse are enabled. The whole file will be sent.  




Also, during normal use of the screens, any added or deleted data is sent to Calidus 3''pl''-Mobile, to keep the files accurate. Simply use the screen as normal, and the data will be sent, as long as the interface flag is turned on.
Also, during normal use of the screens, any added or deleted data is sent to Calidus 3''pl''-Mobile, to keep the files accurate. Simply use the screen as normal, and the data will be sent, as long as the interface flags are turned on.




Line 122: Line 118:




Once all details have been entered, type ‘SEND’ at the action prompt on the main preadvice screen. Tasks per pallet will be sent to Calidus 3''pl''-Mobile. You can only send preadvice records this way if the availability flag of the Pallet Receipt Update process is set to ‘Y’.
Once all details have been entered, click the ‘Send’ button on the main preadvice screen. Tasks per pallet will be sent to Calidus 3''pl''-Mobile. You can only send preadvice records this way if the availability flag of the Pallet Receipt Update process is set to ‘Y’.


[[Image:]]
[[Image:]]
Line 130: Line 126:
Once pallets have been received on Calidus 3''pl''-Mobile and sent back to Calidus 3''pl'' they will automatically be updated.  
Once pallets have been received on Calidus 3''pl''-Mobile and sent back to Calidus 3''pl'' they will automatically be updated.  


'''Note:''' In unexpected scenarios (e.g. unexpectedly received pallets) the GR will NOT be automatically confirmed as received. The pallets, which have processed correctly, will have been confirmed but no action will have been taken on other pallets. You will still be able to put the correctly processed pallets away. In order to confirm the GRN fully, you must access the GR Confirmation screen and type ‘CONF’ at the prompt. Until this action is taken, the GRN will continue to appear on diagnostic reports. See section for more details.
'''Note:''' In unexpected scenarios (e.g. unexpectedly received pallets) the Goods Receipt Note will NOT be automatically confirmed as received. The pallets, which have processed correctly, will have been confirmed but no action will have been taken on other pallets. You will still be able to put the correctly processed pallets away. In order to confirm the GRN fully, you must access the GR Confirmation screen and use the Confirm process there. Until this action is taken, the GRN will continue to appear on diagnostic reports. See section 5.2 for more details.




Line 139: Line 135:




If, however, you have the availability flag of the Pallet Receipt Update process set to ‘N’ and the flag for Movement/Putaway Update process set to ‘Y’, you can send putaway messages a different way.
If, however, you have the availability flag of the Pallet Receipt Update process set to ‘N’ and the flag for Movement/Putaway Update process set to ‘Y’, you can send putaway messages a different way.


When the flags are set up this way, preadvice messages can’t be sent to WCS, but putaway messages can. When you have created the goods receipt in Calidus 3''pl'', enter locations as normal in Goods receipt confirmation.
When the flags are set up this way, preadvice messages can’t be sent to WCS, but putaway messages can. When you have created the goods receipt in Calidus 3''pl'', enter locations as normal in Goods receipt confirmation.


[[Image:]]
[[Image:]]


When ‘CONF’ is typed, the receipt is confirmed, and then putaway messages are sent to Calidus 3''pl''-Mobile, with the locations that you specified.
When the ‘Confirm’ option is chosen, the receipt is confirmed and then putaway messages are sent to Calidus 3''pl''-Mobile, with the locations that you specified.


Once the putaway messages have been processed, the pallets will be available in the system.
Once the putaway messages have been processed, the pallets will be available in the system.
Line 151: Line 147:


== Pallet Moves ==
== Pallet Moves ==
Pallet movements sent to Calidus 3''pl''-Mobile are processed in almost exactly the same way as normal. Pallet movements are raised via the Pallet Movement Request screen, and ‘CONF’ is typed as normal. In the Ticket Print screen, you will be prompted for two extra items:
Pallet movements sent to Calidus 3''pl''-Mobile are processed in almost exactly the same way as normal. Pallet movements are raised via the Pallet Movement Request screen as normal. In the Ticket Print screen, you will be prompted for two extra items:


[[Image:]]
[[Image:]]


If you do not want to print the move ticket, enter ‘N’ at the appropriate prompt. You must then enter a priority for the messages. This priority will indicate how quickly the messages are processed in Calidus 3''pl''-Mobile. The values range from 2 (the highest) to 9 (the lowest).
If you do not want to print the move ticket, enter ‘No’ at the appropriate prompt. You must then enter a priority for the messages. This priority will indicate how quickly the messages are processed in Calidus 3''pl''-Mobile. The values range from 2 (the highest) to 9 (the lowest).


After this entry, the request is processed as normal, but with movement messages being sent to Calidus 3''pl''-Mobile.
After this entry, the request is processed as normal, but with movement messages being sent to Calidus 3''pl''-Mobile.
Line 165: Line 161:


== Picks ==
== Picks ==
Pick tasks are sent to the RDTs at the normal pick list stage.  
Pick tasks are sent to the RDTs at the normal pick list stage. This stage can be reached through a number of screens, the most common being the Pick Wave screen.
 
 
=== Pick Wave ===
Orders can be found and allocated to a Pick Wave, using this screen.
 
[[Image:]]
 
Enter a default load then click ‘Find Orders’ to display the orders. Criteria can be entered here to narrow down the orders to be found.
 
Once found, assign the orders to the Load using the check box next to the order, then save.
 
[[Image:]]
 
Click the ‘Send to Alloc’ button to allocate the load.
 
Once allocation is complete, the order can be pick listed using the ‘Send To Pick’ button.
 
[[Image:]]


If allocation has been set up to print the pick lists at the same time, you will be prompted to enter extra parameters:
If the load is to be pre-assigned to one picker, the employee ID of this picker can be entered in the Picker field before sending to pick.


[[Image:]]
[[Image:]]


The Marshalling location is the lane to which you wish the picked pallets to go. If one is not entered, the system will default the location to the fourth build up location in the system parameters screen. The RDT priority affects how quickly the pick tasks will be allocated to a picker. As with other RDT process priorities, this can be set from 2 to 9, 2 being the highest priority.
The Marshalling location is the lane to which you wish the picked pallets to go. If one is not entered, the system will default the location to the Default Marshalling Location in the system parameters screen. The RDT priority affects how quickly the pick tasks will be allocated to a picker. As with other RDT process priorities, this can be set from 2 to 9, 2 being the highest priority.
 


When allocation and pick list is completed, all identified pick tasks will be sent to the RDTs.
When you have chosen the parameters, click the ‘Generate Pick List’ button. This will produce a paper pick list if desired, and will also transfer the pick tasks to Calidus 3pl-Mobile for completion.




If you pick list by a separate process in the menus, you will be prompted to enter the extra parameters at this stage:
=== Pick List ===
If you allocate and pick list by separate processes in the menus, you will be prompted to enter the extra parameters at the Pick List stage:


[[Image:]]
[[Image:]]


The Marshalling location is the lane to which you wish the picked pallets to go. The RDT priority affects how quickly the pick tasks will be allocated to a picker. As with other RDT process priorities, this can be set from 2 to 9, 2 being the highest priority.
The Marshalling location is the lane to which you wish the picked pallets to go. If one is not entered, the system will default the location to the Default Marshalling Location in the system parameters screen. The RDT priority affects how quickly the pick tasks will be allocated to a picker. As with other RDT process priorities, this can be set from 2 to 9, 2 being the highest priority.
 


When pick list is completed, all identified pick tasks will be sent to the RDTs.
When you have chosen the parameters, click the ‘Generate Pick List’ button. This will produce a paper pick list if desired, and will also transfer the pick tasks to Calidus 3pl-Mobile for completion.




== Pick Modifications ==
== Pick Modifications ==
If you have short-picked an item or the pickers have not found some pallets, these tasks will be sent back to Calidus 3''pl'', and will reduce the amount picked. The shortfall must be appended onto the order. This is achieved by adding lines at pick confirmation, but without confirming the order.
If you have short-picked an item or the pickers have not found some pallets, these tasks will be sent back to Calidus 3''pl'', and will reduce the amount picked. The shortfall must be appended onto the order. This is achieved by adding lines at pick confirmation, but without confirming the order.


First, find the order in the Pick confirmation by route/load/order screen:
First, find the order in the Pick confirmation by route/load/order screen:
Line 196: Line 214:
[[Image:]]
[[Image:]]


From here, append lines to the order as normal, but do not confirm the page. No updating is required. The appended pick task will be sent to Calidus 3''pl''-Mobile for processing. When completed, the task will be returned and updated automatically by Calidus 3''pl''.
From here, append lines to the order as normal, but do not confirm the page. When saved, the appended pick task will be sent to Calidus 3''pl''-Mobile for processing. When completed, the task will be returned and updated automatically by Calidus 3''pl''.
 
 
Pick tasks that have been manually short-picked or confirmed will also be interfaced to Calidus 3pl-Mobile, to reduce or remove the pick tasks outstanding.




Line 211: Line 232:
[[Image:]]
[[Image:]]


Once the data is checked for consistency, the cycle can be updated, using the stock take update screen.
Once the data is checked for consistency, the cycle can be confirmed (using the ‘Confirm’ button), making it ready for updating, using the Stock Take Update screen.


[[Image:]]
[[Image:]]


Good counts should be confirmed. If unsure about the counts, the cycle can be rejected or partially confirmed. In a partial confirmation, any records that were correct are confirmed, and any with modifications are left on the stock cycle. These will then be re-sent to the RDTs, so that they may be checked again.
Good counts should be confirmed. If unsure about the counts, the cycle can be rejected or partially confirmed. In a partial confirmation, any records that were correct are confirmed, and any with modifications are left on the stock cycle.




= Receiving Procedures =
= Receiving Procedures =
== WCS Exceptions Report ==
== Receipt Transaction Exceptions ==
[[Image:]]
[[Image:]]


You are prompted to choose a date range (start and end) for selection. This will default to today’s date.
Message types allow you to choose which processes’ messages you want to see on the report. A full list will be shown.


The error type allows you to choose from a range of message levels:
The error type allows you to choose from a range of message levels:


* Informational (type ‘I’) – Some processes write away messages to the report, showing successful completion of update. These are informational messages.
* Informational (type ‘I’) – Some processes write away messages to the report, showing successful completion of update. These are informational messages.
* Warning (type ‘W’) – Warnings show data that may need to be fixed, but the line has been updated anyway.
* Warning (type ‘W’) – Warnings show data that may need to be fixed, but the line has been updated anyway.
* Error (type ‘E’) – Errors show records that cannot be updated. The reason will be shown in the description. Data with errors must be entered and updated manually through the normal manual update screens.
* Error (type ‘E’) – Errors show records that cannot be updated. The reason will be shown in the description. Data with errors must be entered and updated manually through the normal manual update screens.
* All (type ‘A’) – All of the above.
* Debug messages (for support)
* All (type ‘A’) – All of the above.
 
You are prompted to choose a Date From. This will default to today’s date.
 


Message types allow you to choose which processes’ messages you want to see on the report. A full list will be shown.
[[Image:]]


The last two parameters control the clear-down of the RDT exception data file. This should be done on a regular basis. By default, no clear-down is done. If you choose to do the clear-down, you are prompted to enter a date. All data before this data will be deleted. Take care using this function as, once deleted, the exceptions data cannot be recovered.
The 'Cleardown' button shows the parameters required so that the exceptions log can be cleared. This should be done on a regular basis. By default, no clear-down is done. If you choose to do the clear-down, you are prompted to enter a date. All data before this data will be deleted. Take care using this function as, once deleted, the exceptions data cannot be recovered.




Line 240: Line 265:


* For GRNs:
* For GRNs:
* GRN’s not putaway confirmed
* GRN’s not putaway confirmed
* GR Discrepancies Report
* GR Discrepancies Report
* GRN’s advised not confirmed
* GRN’s advised not confirmed
* For Orders:
* For Orders:
* Order (status) report
* Order (status) report
Line 250: Line 275:
* Unconfirmed Movements
* Unconfirmed Movements
* Outstanding Movements Report
* Outstanding Movements Report
Additionally, the Data Extraction Suite allows the user to design reports to examine all of this data.


Various enquiries exist in the system, which will also aid identification:
Various enquiries exist in the system, which will also aid identification:
Line 257: Line 285:
* Pallet Enquiry
* Pallet Enquiry
* Order Enquiry
* Order Enquiry
# '''References / Glossary & History'''
'''References'''
{| class="prettytable"
| <center>Ref No</center>
| <center>Document Title & ID</center>
| <center>Version</center>
| <center>Date</center>
|-
| #
| C3PL-M Maintenance User Guide
| <center>4</center>
| <center>30/04/2008</center>
|-
| #
| C3PL-M Installation Guide
| <center>11.0</center>
| <center>08/05/2009</center>
|-
| #
| C3PL-M Set-up guide
| <center>7</center>
| <center>18/07/2008</center>
|-
|
|
|
|
|}
'''Glossary'''
{| class="prettytable"
! <center>Term or Acronym</center>
! <center>Meaning</center>
|-
| Calidus 3''pl''
| OBS Logistics’ full warehousing solution
|-
|
|
|-
| WMS
| Warehouse Management System. Another name for Calidus 3''pl'', or the portion of the Calidus 3''pl'' system which runs entirely on a manual basis (i.e. no RDTs)
|-
|
|
|-
| WCS; Calidus 3''pl''-Mobile
| Warehouse Control System. The portion of the Calidus 3''pl'' system that controls the RDTs in the warehouse.
|-
|
|
|-
| WCSM
| WCS Maintenance, the WCS’s administrative programs.
|-
|
|
|-
| RDT
| Radio Data Terminal. This is the hardware used in the warehouse to enter information.
|-
|
|
|-
| WCS Server
| This is the PC (running Windows Server 2000/2003) that the WCS and WCS interface inhabits.
|-
|
|
|-
| WMS Interface
| The portion of the WMS that communicates directly with the WCS. This is written in ‘C’.
|-
|
|
|-
| RDT Update processes
| Programs on the WMS that receive the messages from the RDT system, then update the WMS database with the required information.
|-
|
|
|-
| WCS Interface
| The portion of the WCS that communicates directly with the WMS. This is written in Microsoft â„¢ Visual Basic
|-
|
|
|-
| Wavelink
| 3<sup>rd</sup> party software used to control the RDTs over a wireless LAN
|-
|
|
|}

Revision as of 16:49, 13 May 2011

System Overview

Operation

As can be seen from the diagram, Calidus 3pl runs on a UNIX server, while Calidus 3pl-Mobile runs on a Windows Server in this implementation.


In the diagram, Calidus 3pl has been split into three areas.


The non-shaded area is the manual Calidus 3pl system, being the screens and methods currently used to enter and confirm tasks.


The wavy shaded area shows the portion of Calidus 3pl that sends messages to the WMS interface. These are covered in great detail in following sections.


The dotted area contains Calidus 3pl RDT update programs that automatically do the work of the confirmation processes in manual Calidus 3pl. For example, one of these processes might confirm movements; another might confirm orders as picked. They work by receiving confirmation of tasks completed from Calidus 3pl-Mobile. Those messages (of tasks to be completed, and confirmation of tasks completed) are sent by the interface.


Both systems have an interface; Calidus 3pl’s is referred to as the WMS interface, Calidus 3pl-Mobile’s as the WCS interface. Both need transmitters (to send their messages) and receivers to get messages back. As can be seen from the diagram, Calidus 3pl sends messages to Calidus 3pl-Mobile’s receiver program, WCS Server through an Oracle Advance Queue. When messages are being sent back to Calidus 3pl, Calidus 3pl-Mobile’s transmitter program, also WCS Server, sends messages to Calidus 3pl by enqueuing messages on Oracle Advance Queues in the WMS database.

The third part of the interface consists of the Merge processes. In Calidus 3pl, these consists of many processes which we route messages to using the Queue Reader processes. These route the messages to the Merge processes (dotted area of the RDT update programs).


So, let’s look at the progression of tasks through this system from start to finish. For this example, we’ll use a simple housekeeping pallet movement.


When the task (move pallet 1 from A to B) is raised, the message is passed to the WMS Interface Queue. The Queue passes the information to the WCS Server. Note: Only when the message is fully processed is this removed from the queue, ensuring messages are never lost).

Once WCS’s receiver has the message, merges the message to the database. This identifies the type of message (a pallet movement), and checks that everything is OK about the message’s contents. When satisfied of the contents, the task is put in the main WCS database, ready for use.


When an RDT user requests a task, and they are to be allocated movement tasks, WCS will allocate the closest movement to that user’s location, or in priority order. In our example, this means they are given the movement we raised on Calidus 3pl. They are told to get the pallet 1 from location A and take it to location B, there scanning the check digits of the destination for confirmation.


Once they have completed the task, Calidus 3pl-Mobile sends a completion message to the Calidus 3pl receiver queue.

The Queue Reader associated to the queue identifies the type of message, in our example, a movement completion message. The message is then routed to the correct RDT update process. Again, messages are only removed from the queue when correctly processed.

The RDT update process examines the contents of the message for validity, and then updates all the Calidus 3pl data files that you would expect if it was confirmed manually in the Pallet Move Confirmation screen.


RDT Control Processes

Menus

[[Image:]]

The menu is normally located on the top flexible menu.


System Parameters

In order to send RDT messages or tasks to Calidus 3pl-Mobile, the Calidus 3pl system must be informed that the Interface to Calidus 3pl-Mobile is present. This is enabled via the ‘RDT Interface’ flag on system parameters.

[[Image:]]


Click on the Default Locations tab to identify the default locations required.

[[Image:]]


Build up location 3 (Q/A) is the default putaway location, if the putaway algorithm finds no locations. Location 6 is a Default Marshalling Location, used by pick list and allocation.


Owner parameters

An RDT Interface flag also exists per Owner or Stockist. With this flag, we are able to determine whether, even if the warehouse allows RDT operations, the owner allows RDT operations.


[[Image:]]

In all ways, this bank of screens operates in the same way as the System parameters screens, described above.


RDT Status Maintenance Screen

This screen is the major control screen for RDTs in Calidus 3pl

[[Image:]]

Each line controls not only the running of the update process in Calidus 3pl, but also the availability of the functions to standard Calidus 3pl processing. So, for example, if the Pallet Receipt Update availability flag is ‘Y’, you have the ability to send receipt preadvice messages to WCS. If it is ‘N’, you can’t send those messages.

The use of the availability flags in the system will be explained for each sending process described in the next section.

Use ‘Start Interface’ to start the RF interface programs.

Use ‘Stop Interface’ to stop the RF interface programs.

The light below these buttons indicates whether the interface is on or off.


The use of this screen should be limited to System Administrators only.

SENDING DATA

Standing Data tables

See the C3PL-M Setup guide, for details of how this data is used in the Calidus 3pl-Mobile.


Various data tables on Calidus 3pl need to be sent to Calidus 3pl-Mobile. These tables are:

  • Employees
  • Truck Types
  • Pallet Types
  • Location Types
  • Reason Codes
  • Receipt Types
  • Aisles Status/Aisles
  • Stock information

The maintenance screens for these tables can be found (by default) on the Warehouse maintenance menu. The exception to this is the Stock Maintenance screen, normally found on the Stock menu.


To perform an initial send of the data to Calidus 3pl-Mobile, enter the form and find data. Once found, click the Send button on the form, which will only be visible if the Interface flags for the owner and warehouse are enabled. The whole file will be sent.


Also, during normal use of the screens, any added or deleted data is sent to Calidus 3pl-Mobile, to keep the files accurate. Simply use the screen as normal, and the data will be sent, as long as the interface flags are turned on.


Preadvices

Enter the preadvice as normal, either with or without pallet details.


Once all details have been entered, click the ‘Send’ button on the main preadvice screen. Tasks per pallet will be sent to Calidus 3pl-Mobile. You can only send preadvice records this way if the availability flag of the Pallet Receipt Update process is set to ‘Y’.

[[Image:]]

Sending the preadvices to Calidus 3pl-Mobile need only be done this way if the Goods had not been preadvised via EDI. In this process, all messages will be automatically sent to Calidus 3pl-Mobile on receipt of the EDI.

Once pallets have been received on Calidus 3pl-Mobile and sent back to Calidus 3pl they will automatically be updated.

Note: In unexpected scenarios (e.g. unexpectedly received pallets) the Goods Receipt Note will NOT be automatically confirmed as received. The pallets, which have processed correctly, will have been confirmed but no action will have been taken on other pallets. You will still be able to put the correctly processed pallets away. In order to confirm the GRN fully, you must access the GR Confirmation screen and use the Confirm process there. Until this action is taken, the GRN will continue to appear on diagnostic reports. See section 5.2 for more details.


Putaways

When the Goods Receipt has been processed on Calidus 3pl-Mobile, update messages are sent back to Calidus 3pl. The Pallet Receipt Update program, controlled by the RDT Start/Stop screen processes these. When the program processes the receipt messages, it will generate a putaway location for the pallet automatically. This is sent through to Calidus 3pl-Mobile as a putaway task.

If a location cannot be found for the pallet, the putaway location will default to the third build-up location on system parameters, the Q/A location.


If, however, you have the availability flag of the Pallet Receipt Update process set to ‘N’ and the flag for Movement/Putaway Update process set to ‘Y’, you can send putaway messages a different way.

When the flags are set up this way, preadvice messages can’t be sent to WCS, but putaway messages can. When you have created the goods receipt in Calidus 3pl, enter locations as normal in Goods receipt confirmation.

[[Image:]]

When the ‘Confirm’ option is chosen, the receipt is confirmed and then putaway messages are sent to Calidus 3pl-Mobile, with the locations that you specified.

Once the putaway messages have been processed, the pallets will be available in the system.


Pallet Moves

Pallet movements sent to Calidus 3pl-Mobile are processed in almost exactly the same way as normal. Pallet movements are raised via the Pallet Movement Request screen as normal. In the Ticket Print screen, you will be prompted for two extra items:

[[Image:]]

If you do not want to print the move ticket, enter ‘No’ at the appropriate prompt. You must then enter a priority for the messages. This priority will indicate how quickly the messages are processed in Calidus 3pl-Mobile. The values range from 2 (the highest) to 9 (the lowest).

After this entry, the request is processed as normal, but with movement messages being sent to Calidus 3pl-Mobile.


Replens

Replenishments are processed in the same way as pallet movements.


Picks

Pick tasks are sent to the RDTs at the normal pick list stage. This stage can be reached through a number of screens, the most common being the Pick Wave screen.


Pick Wave

Orders can be found and allocated to a Pick Wave, using this screen.

[[Image:]]

Enter a default load then click ‘Find Orders’ to display the orders. Criteria can be entered here to narrow down the orders to be found.

Once found, assign the orders to the Load using the check box next to the order, then save.

[[Image:]]

Click the ‘Send to Alloc’ button to allocate the load.

Once allocation is complete, the order can be pick listed using the ‘Send To Pick’ button.

[[Image:]]

If the load is to be pre-assigned to one picker, the employee ID of this picker can be entered in the Picker field before sending to pick.

[[Image:]]

The Marshalling location is the lane to which you wish the picked pallets to go. If one is not entered, the system will default the location to the Default Marshalling Location in the system parameters screen. The RDT priority affects how quickly the pick tasks will be allocated to a picker. As with other RDT process priorities, this can be set from 2 to 9, 2 being the highest priority.


When you have chosen the parameters, click the ‘Generate Pick List’ button. This will produce a paper pick list if desired, and will also transfer the pick tasks to Calidus 3pl-Mobile for completion.


Pick List

If you allocate and pick list by separate processes in the menus, you will be prompted to enter the extra parameters at the Pick List stage:

[[Image:]]

The Marshalling location is the lane to which you wish the picked pallets to go. If one is not entered, the system will default the location to the Default Marshalling Location in the system parameters screen. The RDT priority affects how quickly the pick tasks will be allocated to a picker. As with other RDT process priorities, this can be set from 2 to 9, 2 being the highest priority.


When you have chosen the parameters, click the ‘Generate Pick List’ button. This will produce a paper pick list if desired, and will also transfer the pick tasks to Calidus 3pl-Mobile for completion.


Pick Modifications

If you have short-picked an item or the pickers have not found some pallets, these tasks will be sent back to Calidus 3pl, and will reduce the amount picked. The shortfall must be appended onto the order. This is achieved by adding lines at pick confirmation, but without confirming the order.


First, find the order in the Pick confirmation by route/load/order screen:

[[Image:]]

Select the required page of the order. You will be taken to the confirm screen.

[[Image:]]

From here, append lines to the order as normal, but do not confirm the page. When saved, the appended pick task will be sent to Calidus 3pl-Mobile for processing. When completed, the task will be returned and updated automatically by Calidus 3pl.


Pick tasks that have been manually short-picked or confirmed will also be interfaced to Calidus 3pl-Mobile, to reduce or remove the pick tasks outstanding.


Stock Check

Generate the stock check cycle as normal in the generation screen. For messages to be sent to Calidus 3pl-Mobile, the interface flag (either from owner or system parameters) must be set, and the stock check availability flag and owner check flags must also be set in the RDT start/stop screen.

[[Image:]]

The cycle will either be a full stock check or a partial stock check. If neither, the stock check will be assumed to be a partial, or pre-advised, check.


Once stock details have been checked on the RDTs, the information is sent back to Calidus 3pl and updated into the stock take count input screen.

[[Image:]]

Once the data is checked for consistency, the cycle can be confirmed (using the ‘Confirm’ button), making it ready for updating, using the Stock Take Update screen.

[[Image:]]

Good counts should be confirmed. If unsure about the counts, the cycle can be rejected or partially confirmed. In a partial confirmation, any records that were correct are confirmed, and any with modifications are left on the stock cycle.


Receiving Procedures

Receipt Transaction Exceptions

[[Image:]]

Message types allow you to choose which processes’ messages you want to see on the report. A full list will be shown.

The error type allows you to choose from a range of message levels:

  • Informational (type ‘I’) – Some processes write away messages to the report, showing successful completion of update. These are informational messages.
  • Warning (type ‘W’) – Warnings show data that may need to be fixed, but the line has been updated anyway.
  • Error (type ‘E’) – Errors show records that cannot be updated. The reason will be shown in the description. Data with errors must be entered and updated manually through the normal manual update screens.
  • Debug messages (for support)
  • All (type ‘A’) – All of the above.

You are prompted to choose a Date From. This will default to today’s date.


[[Image:]]

The 'Cleardown' button shows the parameters required so that the exceptions log can be cleared. This should be done on a regular basis. By default, no clear-down is done. If you choose to do the clear-down, you are prompted to enter a date. All data before this data will be deleted. Take care using this function as, once deleted, the exceptions data cannot be recovered.


Diagnostics processes

In addition to the above report, several diagnostics reports exist that will aid in identifying possible problems:

  • For GRNs:
  • GRN’s not putaway confirmed
  • GR Discrepancies Report
  • GRN’s advised not confirmed
  • For Orders:
  • Order (status) report
  • Unconfirmed Orders
  • Unconfirmed Pick Pages Report
  • For Moves:
  • Unconfirmed Movements
  • Outstanding Movements Report

Additionally, the Data Extraction Suite allows the user to design reports to examine all of this data.


Various enquiries exist in the system, which will also aid identification:

  • All stock movements enquiries
  • Customer Pallet ID Enquiry
  • Pallet Enquiry
  • Order Enquiry
  1. References / Glossary & History

References


Ref No
Document Title & ID
Version
Date
#


C3PL-M Maintenance User Guide
4
30/04/2008
#


C3PL-M Installation Guide
11.0
08/05/2009
#


C3PL-M Set-up guide
7
18/07/2008

Glossary


Term or Acronym
Meaning
Calidus 3pl OBS Logistics’ full warehousing solution
WMS Warehouse Management System. Another name for Calidus 3pl, or the portion of the Calidus 3pl system which runs entirely on a manual basis (i.e. no RDTs)
WCS; Calidus 3pl-Mobile Warehouse Control System. The portion of the Calidus 3pl system that controls the RDTs in the warehouse.
WCSM WCS Maintenance, the WCS’s administrative programs.
RDT Radio Data Terminal. This is the hardware used in the warehouse to enter information.
WCS Server This is the PC (running Windows Server 2000/2003) that the WCS and WCS interface inhabits.
WMS Interface The portion of the WMS that communicates directly with the WCS. This is written in ‘C’.
RDT Update processes Programs on the WMS that receive the messages from the RDT system, then update the WMS database with the required information.
WCS Interface The portion of the WCS that communicates directly with the WMS. This is written in Microsoft â„¢ Visual Basic
Wavelink 3rd party software used to control the RDTs over a wireless LAN
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/WCS/index.php?title=Using_WCS_from_WMS&oldid=114’