Using WCS from WMS

System Overview

Operation

As can be seen from the diagram, Calidus 3pl runs on an RS6000, while Calidus 3pl-Mobile runs on a Windows NT PC 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’s transmitter process, XMIT, sends messages to Calidus 3pl-Mobile’s receiver program, WCS Server. When messages are being sent back to Calidus 3pl, Calidus 3pl-Mobile’s transmitter program, also WCS Server, sends messages to Calidus 3pl’s receiver process, RECV.

The third part of the interface is the merge process. In Calidus 3pl, 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.

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.

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 program, RECV, which acknowledges receipt of the message.

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 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 ‘Interface Flag’ on system parameters.

[[Image:]]

Entering 99 at the action prompt allows you identify the default locations required.

[[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.

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.

[[Image:]]

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

RDT Start/Stop 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.

Processes can be started or stopped by entering the id number of the appropriate line, then selecting START or STOP from the selection.

In both of these cases, if you do not want to stop or start the process, choose CONTINUE from the selection.

Other procedures can be used from the action prompt:

• 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.

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, 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.

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 flag is turned on.

Preadvices

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

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 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 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.

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 ‘CONF’ is typed, 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, and ‘CONF’ is typed 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 ‘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 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.

If allocation has been set up to print the pick lists at the same time, you will be prompted to enter extra parameters:

[[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.

When allocation and pick list is completed, all identified pick tasks will be sent to the RDTs.

If you pick list by a separate process in the menus, you will be prompted to enter the extra parameters at this stage:

[[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.

When pick list is completed, all identified pick tasks will be sent to the RDTs.

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. No updating is required. 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.

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 updated, 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. These will then be re-sent to the RDTs, so that they may be checked again.

Receiving Procedures

WCS Exceptions Report

[[Image:]]

You are prompted to choose a date range (start and end) for selection. This will default to today’s date.

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.
• All (type ‘A’) – All of the above.

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

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.

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

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

• All stock movements enquiries
• Customer Pallet ID Enquiry
• Pallet Enquiry
• Order Enquiry