Calidus HUB - User contributions [en-gb]

EST 316159 Partnerlink Cancel and Redelivery method

2014-03-27T11:54:02Z

Pjh:

{{Template:Estimate
|Supimix_Client_Code=PART
|Supimix_Project_Code=DEV
|Supimix_Site_Code=PART
|Supimix_Client_Reference= 
|Supimix_Number=316159
|The_version_of_the_document=0.2
|Your_Name=A Walker
|Supimix_PO_Reference=Unknown
|Supimix_Priority=3
|Date_(DD/MM/YY)=27/03/2014
|Clients_Customer=N/A
|System_Version_being_changed=Latest
|Free_Of_Charge=Y
|Client_Request=ePOD functionality required for Cancellation and Redelivery.
|OBS_Solution={{#vardefine:System|''CALIDUS'' ePOD}}

'''Description of problem'''

The Auto-Import functionality for the Partnerlink JobShare format currently checks whether the job already exists by checking the Site, Job Code and Type (Collection or Delivery) passed in the uploaded data file.
If the job is found, this is seen to be an update of the existing job. As the job that is found has been cancelled already in the application, the system will not update the job to preserve the activity trail.

'''Solution'''

The upload process will be modified to recognise that confirmed jobs (at completed or cancelled status) should not be updated, but instead a new job created if the Load specified on the incoming file is different to what the system already has recorded against the job.

If the job is found in progress or pending, the job will be updated - this means that the job will be moved from the existing load to a different one and the details updated, if the incoming file specifies this.

This change allows the TMS systems to re-plan jobs until they have been completed. Re-planning jobs after completion result in new jobs being created.

{{Note}} This does not allow for jobs with the same reference to be planned onto multiple loads at the same time (for example, multi-legged trips, split deliveries). This is not expected to occur for Partnerlink.

In detail:
* If the Job does not exist, a new job will be created.
* If the Job exists, at status Completed or Cancelled, and the Load ID on file is different to that in the incoming file, a new job will be created.
* If the Job exists, at status Completed or Cancelled, and the Load ID on file is the same as the incoming file, the job update will not occur - the file will not be rejected, the processing for other jobs will occur.
* If the Job exists, at status In Progress or Pending, the job found will be updated with the details on the incoming file.
<br />
<br />
<br />
<br />

|Requirements_Days=0
|Estimation_Days=0.25
|Functional_Specification_Days=0.25
|Technical_Specification_Days=0
|Development_Days=1.0
|Testing_and_Release_Days=0.5
|Implementation_Days=0.0
|Project_Management_Days=0
|Year=2014}}

REQ 298608 Selby Container Yard Requirements

2012-06-18T10:24:17Z

Pjh: Minor edit of text

<div class="noprint">
{{#vardefine:Client|POT}}
{{#vardefine:ClientName|Potter Group}}
{{#vardefine:System|''CALIDUS'' WMS}}
{{#vardefine:Doc_Title|Selby Container Yard Requirements}}
{{#vardefine:Version|0.3}}
{{#vardefine:Date|15th June 2012}}
{{#vardefine:Reference|298608}}
{{#vardefine:Year|2012}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}}.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, at Selby Container Yard, on 24th May 2012.

== Scope and Limitations ==
* The system will be a new build, with Administration and Mobile Device functionality, written in Visual C#.NET.
* The database will be the standard WMS database, with some new tables added for the specific container yard functionality described below.
* Invoicing requirements have not been included as part of this system and will be costed separately as required.
* The existing Oracle Form for maintaining Locations will be modified slightly to allow for Container Yard locations.


=Requirements=
The system will be a new build, with Administration and Mobile Device functionality, written in a Web-based client-server language (e.g. .NET, JSP).

The database will be the standard WMS Oracle database, with some new tables added for the specific container yard functionality described below.

The general Company and Warehouse will be set up through the standard WMS Warehouse screens.

The EDI will be controlled and set up through the standard WMS EDI configuration screens.

Users will be created and set up through the standard WMS User maintenance screens.

= Menus =
The following menu items will be available within the new system. The menus will be offered to the user based on the setup of the user itself. There are 3 main menus, as shown below.

==Admin User Menu==

* Processes
** Container Control
** Inbound Rail
** Outbound Rail
** Location Administration
** Container Task Maintenance
* Enquiries
** Location Enquiry
** Task Enquiry
* Maintenance
** Container Maintenance
** Container Type Maintenance
** Location Maintenance

==Customer Menu==
* Customer Container Enquiry screen
* Latest Audit Records

==PDA Menu==
* Work In Progress
* Relocate Container
* Change Container Status

= Screens =
Each screen listed above is described in detail in this section.

In all screens, the basic warehousing fields of Company Code and Warehouse ID will not be displayed as part of the working screen panel, but will be defaulted to ensure that they are set up against the user when they log in. They will be displayed in a standard header or footer on the Administration screens.

During this section, several input types will be mentioned, defined below:
* Drop-down List or DDL - this allows the user to select from several fields, all shown in a list that drops down below the entry field. typically the user is not allowed to enter any value other than those in the list.
* Auto-complete - this is similar to a DDL, in that the user is typically only allowed to choose items from a list. The user will type part of the required information, and the system will search for matching results and display them in a list below the entry field. The user clicks one of the provided samples to enter the data.
* Check-box - this is used to define a simple Yes/No field, and is displayed graphically as a small box. If the value is Yes, a tick appears in the box. the user can tick or un-tick the box by clicking on the field.
* Button - a button to click to complete a specific action, usually labelled on the button itself.
* List Button or Menu Button - a button combined with a DDL - the user chooses the action to be taken, then presses the button. This is useful when space is limited.
* Grid - tabulated data, usually used for several rows of data entry or display.

==Container Control Screen==
This screen is used to enter a new task, a combination of Inbound and/or outbound tasks.

General fields entered:
* Registration - The vehicle registration; Required Entry.
* Account - DDL, defaulted to the user's default account (MED01)
* Haulier - Auto-complete. If the Haulier does not exist, it will be automatically added when saving the data.
* Date/Time - Defaulted to the current date and time.

Inbound fields:

These will be displayed in a grid. There can be up to 2 containers entered here.
* Order # - This will not validated by the system - it will manually checked by the users; Required Entry.
* Container ID - Required Entry; Validated to the standard Container pattern with Mod 11 Check Digit calculation.
* Type - DDL; Defaulted if the Container ID has already been known in the system.
* Weight (Limit Max) - DDL; Prompted only and Required Field if the Container Type is 20Ft; From a choice of 24/27/30. Defaulted if Container ID has already been known in the system.
* Full/Damaged - DDL; System-maintained values from (currently) , E/F/ED/FD/U.
* Hazardous - Check-box; Defaults to unchecked.
* UN No - Auto-complete; Values are taken from the preloaded UN Numbers with in the WMS tables; Entered only if the Container is marked as Hazardous.

Outbound fields:

These will be displayed in a grid. There can be up to 2 containers entered here.
* Order # - This will not validated by the system - it will manually checked by the users; Required Entry.
* Container ID - Validated to the standard Container pattern with Mod 11 Check Digit calculation. Optional Entry - if entered, the information below will be displayed from the Container record found.
* Type - If the container is unknown or no Container has been entered; DDL; Defaulted if the Container ID has already been known in the system.
* Weight (Limit Max) - If the container is unknown or no Container has been entered; DDL; Prompted only and Required Field if the Container Type is 20Ft; From a choice of 24/27/30; Defaulted if Container ID has already been known in the system.
* Full/Damaged - If the container is unknown or no Container has been entered; DDL; System-maintained values from (currently) , E/F/ED/FD/U; Defaulted if Container ID has already been known in the system.
* Hazardous - If the container is unknown or no Container has been entered; Check-box; Defaults to unchecked; Defaulted if Container ID has already been known in the system.
* UN No - If the container is unknown or no Container has been entered; Auto-complete; Values are taken from the preloaded UN Numbers with in the WMS tables; Entered only if the Container is marked as Hazardous; Defaulted if Container ID has already been known in the system.

A '''Save''' button is provided to save the data entered. On pressing:
* The data will be validated and the user prompted to confirm the entry or correct problems. If everything passes validation, the system will:
** Create records on the Task table. The Inbound records will always be written first, to ensure that the tasks appear in the correct sequence.
** Create Containers if they were previously unknown.
** Create a Haulier if it was previously unknown.

Once saved, the screen will blank all entered fields, ready for next entry.

== Inbound Rail ==
The inbound rail screen allows the user to set up the preadvice of tasks arriving through the rail network. On entry to the screen, the system will prompt for the following data.

General Fields:
* Account - DDL; defaulted to the user's default account (MED01)
* Date/Time - Validated as a date/time; not defaulted.
* Registration - Default to IMP{Date:YYMMDD}(Time:HHNN} after the date and time have been entered.

Container Fields:

These will be displayed in a grid. There is no limit to the number of records that can be entered. Entering a row of data will automatically show the data above and extend the grid by another line.
* Container ID - Required Entry; Validated to the standard Container pattern with Mod 11 Check Digit calculation.
* Type - DDL; Defaulted if the Container ID has already been known in the system.
* Weight (Limit Max) - DDL; Prompted only and Required Field if the Container Type is 20Ft; From a choice of 24/27/30. Defaulted if Container ID has already been known in the system.
* Full/Damaged - DDL; System-maintained values from (currently) , E/F/ED/FD/U; Defaulted to Full (F)
* Hazardous - Check-box; Defaults to unchecked.
* UN No - Auto-complete; Values are taken from the preloaded UN Numbers with in the WMS tables; Entered only if the Container is marked as Hazardous.

A '''Save''' button is provided to save the Inbound Rail advice.

A '''Search''' button will be provided for the user to search by Registration (auto-complete) for a saved Inbound Rail Advice, choosing whether to look for confirmed or unconfirmed (defaulted to unconfirmed) and display all the details.

A '''Confirm''' button will be provided for the user to confirm that the Inbound Rail Advice is completed, and present it to the drivers for completion.

If an item in the grid is clicked, the user is allowed to edit it (if the task is unconfirmed).

Once the Inbound Rail Advice is confirmed, an '''Export''' button will be available to export the advice to CSV, so the user can print this if required.

== Outbound Rail ==

This screen is similar to the Inbound Rail screen, except for:
* Registration is defaulted to EXP rather than IMP
* The user is allowed to link an Outbound Rail advice to an Inbound Rail advice.
* The user is allowed to specify the position in the train.

On entry to the screen, the system will prompt for the following data.

General Fields:
* Account - DDL; defaulted to the user's default account (MED01)
* Date/Time - Validated as a date/time; not defaulted.
* Registration - Default to EXP{Date:YYMMDD}(Time:HHNN} after the date and time have been entered.
* Linked Inbound - Optional Entry; DDL of unconfirmed inbounds on same day up to day -3.

Container Fields:

These will be displayed in a grid. There is no limit to the number of records that can be entered. Entering a row of data will automatically show the data above and extend the grid by another line.
* Container ID - Required Entry; Validated to the standard Container pattern with Mod 11 Check Digit calculation.
* Type - DDL; Defaulted if the Container ID has already been known in the system.
* Weight (Limit Max) - DDL; Prompted only and Required Field if the Container Type is 20Ft; From a choice of 24/27/30. Defaulted if Container ID has already been known in the system.
* Full/Damaged - DDL; System-maintained values from (currently) , E/F/ED/FD/U; Defaulted to Full (F)
* Hazardous - Check-box; Defaults to unchecked.
* UN No - Auto-complete; Values are taken from the preloaded UN Numbers with in the WMS tables; Entered only if the Container is marked as Hazardous.
* Position code - Numeric; Required Entry.

A '''Save''' button is provided to save the Inbound Rail advice.

A '''Search''' button will be provided for the user to search by Registration (auto-complete) for a saved Inbound Rail Advice, choosing whether to look for confirmed or unconfirmed (defaulted to unconfirmed) and display all the details.

A '''Confirm''' button will be provided for the user to confirm that the Inbound Rail Advice is completed, and present it to the drivers for completion.

If an item in the grid is clicked, the user is allowed to edit it (if the task is unconfirmed).

Once the Inbound Rail Advice is confirmed, an '''Export''' button will be available to export the advice to CSV, so the user can print this if required.

== Location Administration ==
This screen allows the user to find a location and see all of the containers in FIFO sequence. The user will be able to change the sequence of containers in the location and save the results.

The user will also be able to select a second location and move containers into or out of that location by clicking buttons to move the top-most containers from one location to another.

== Container Task Maintenance ==
This screen allows the user to select the jobs and;
* edit the details
* cancel/delete the job
* complete the job manually

The screen will allow the user to find tasks by any or all of the following:
* Date or Date Range
* Account
* Type (IR/IG/OR/OG)
* Registration

The results will be displayed in a grid showing:
* Date/Time
* Container ID
* Order #
* Type
* Weight
* Full/Damaged
* Hazardous
* UN No
Only jobs that have not been completed will be shown.

The screen will allow the user to select a task. A popup will show:
* All the container details
* A '''Delete''' button, to remove the job completely.
* A '''Complete''' button, to complete the task
* An '''Edit''' button, to allow the user to change the details.

The '''Delete''' button will ask the user to confirm the request and, if confirmed, will remove the task.

The '''Complete''' button will allow the user to complete the task. Depending on the task type, the system will prompt for a location in which to place the container (Inbound) or just confirm the outbound.

Saving the changes will mark the task as complete by the Admin user.

The '''Edit''' button will allow the user to change the details against the task. A '''Save''' button will save the changes.

After completing any of these actions, the search results grid will be refreshed.

== Location Enquiry ==
This screen allows the user to view container information through the entry of Location or Container.

The user will be able to filter data through:
* Location code
* Container ID

The results matching will be displayed in a grid showing:
* Date/Time
* Container ID
* Order #
* Type
* Weight
* Full/Damaged
* Hazardous
* # Days on site

The grid will be sorted by clicking on a column header, and can be exported to CSV. The existing format can be seen in the document referenced as item 3 in Appendix A.

Clicking on a container will show a screen showing the container and all historical transactions for the container.

== Task Audit Enquiry ==
This screen allows the user to view the historical tasks that have happened to a container through the entry of Date, Location or Container.

Filter data through:
* Date or Date Range (required)
* Location code
* Container ID

The results will be displayed in a grid showing
* Date/Time
* Container ID
* Order #
* Type
* Weight
* Full/Damaged
* Hazardous

The grid will be sorted by clicking on a column header, and can be exported to CSV.

== Container Maintenance ==
This screen allows the user to see the stored details of a container.

Filter data through:
* Account ID
* Container ID

The results will be displayed in a grid showing
* Date/Time
* Account ID
* Container ID
* Type
* Weight

Clicking on a container will display a popup which will display the full details of the container and allow the user to edit the details, saving the data with a '''Save''' button provided. A new container can be added through the use of a '''New''' button.

== Container Type Maintenance ==
This screen allows the user to maintain container types used by the system.

The screen will display all container types in a paginated grid immediately.

The grid will show:
* Container Type
* Description

Clicking the '''Select''' button will display a popup showing the details, allowing the user to '''Edit''' or '''Delete''' the container type (deleting requesting confirmation). The user can add a container type through the use of a '''New''' button.

== Location Maintenance ==
This screen allows the user to maintain the locations visible to the system.
The user is allowed to filter data through:
* Location Code

The results will be displayed in a grid showing
* Location Code
* A '''Delete''' button.

Clicking on the '''Delete''' button will allow the Location to be deleted, if there are no Containers in the location, pending confirmation from the user. A New location can be added by clicking a '''New''' button.

== Customer Container Enquiry Screen ==
This screen is linked to directly from a web-site page, for customers to view the status of their containers.

This screen will display a filter of Container code.

Under this will be the last 20 transactions for that customer (Account)
The Account will be passed into the screen as a parameter.

When a container is entered and the '''Search''' button is displayed, the screen will call the existing Container Enquiry Results screen, as shown above in the Location Enquiry screen.

== PDA Work In Progress ==
This is a series of screens to allow the drivers to move containers in and out of the yard.

Initially, the process shows a Vehicle List.

Each item shown is the Registration (or train), plus the type. e.g. AB123 BVC (IG/OG)
Types are:
* IG - Inbound Gate
* OG - Outbound Gate
* IR - Inbound Rail
* OR - Outbound Rail
If there are multiple tasks for a Gate task (Inbound and Outbound) they are shown here as IG/OG.

If there are more tasks than can be shown on the screen, '''Prev''' and '''Next''' buttons will be shown.

Unlinked IR and OR Rail tasks are always shown separately. e.g. INP120525 (IR), EXP120525 (OR)

Linked IR and OR Rail tasks will be shown as one e.g. I/E120525 (IR/OR)

This screen shows all the outstanding tasks, with a date less-than or equal to today's date, with the eldest shown first.

The user clicks the registration.

* If the type is IG/OG:
** The unit shows the containers associated to the registration, with an indication of Full or Empty. e.g. ALCU1234567 (F), ALCU1234567 (ED).
** All IG types will be shown first, followed by all OG types.
* If the type is IR or IR/OR:
** The unit shows the containers associated to the registration, with an indication of Full or Empty e.g. ALCU1234567 (F), ALCU1234567 (ED).
** All IR containers are shown if they exist, in Container ID sequence.
** A '''Switch''' button on the top will allow the user to switch to the linked OR type, if there is one.
* If the type is IR or IR/OR:
** All OR containers are shown in Position sequence, with an indication of the position e.g. ALCU1234567 (Pos 1), ALCU1234567 (Pos 49).
** A '''Switch''' button on the top will allow the user to switch to the linked IR type, if there is one.

A Container marked as Hazardous is identified as Red text with an 'X' icon in the top right hand corner.

The user then clicks a container to complete this task.

If the type is IG or IR:

The device shows the container details and a suggestion of where to take container.

Location is suggested by listing all locations available. They are ordered as:
* Suitability
** If damaged status then DAMAGES Location.
** Contains the same Container Type already or is Empty
** Contains a different Container Type
* Type:
** PREP if IG Full only else BAY
** BAY if not IG Full else PREP
** YARD
** TRAIN (if IR only)
** DAMAGES (If not already shown)
* Partially Full
** Already has containers of that type (Green Tick)
** Empty (Orange Tick)
** Else (No formatting)
The user then clicks the chosen location, and then clicks the '''Confirm''' button.

The Task is marked as completed in the system, marked with the current date and time, and the user that completed it.

If the type is OG Full or OR:

The device shows the container details and shown the location to get the container.

The user clicks a location to see the containers in the location.

At this point the user has the option to click '''Relocate''' and a container to be offered a list of locations in which to relocate the container specified.

Once the container is found, the user clicks '''Confirm'''.

The Task is marked as completed in the system, marked with the current date and time, and the user that completed it.

If the type is OG Empty:

The device shows the container details required, and the locations that contain that type.

The user clicks a location to see the containers available in the location (sorted in LIFO sequence), indicating which containers are empty.

At this point the user has the option to click '''Relocate''' and a container to be offered a list of locations in which to relocate the container specified.

Once the container is found, the user clicks '''Confirm'''.

The Task is marked as completed in the system, marked with the current date and time, and the user that completed it.

For type IG/OG:

Once confirm is clicked, the Containers moved are shown (all IG and OG types).

The Terms & Conditions required are displayed on the screen.

The driver clicks '''Confirm'''.

The driver is required to enter their signature.

Once confirm is clicked, the system saves the data.
* The Driver Signature is saved, stamped with the Date and Time and a unique ID.
* The Signature ID is marked against the completed tasks.

{{Note}} Although this screen is created for use on the mobile devices, this screen will also work and be accessible by logging on as a PDA user on a normal browser. This functionality can be achieved through the standard Admin Container Task Maintenance screen.

Samples of the existing screen layouts are available in the file referenced as item 4 in Appendix A.

== PDA Relocate Container ==
This screen allows the user to manually relocate containers.

The user is shown a list of locations, sequenced as follows:
* BAY
* PREP
* YARD
* DAMAGES
* TRAIN.
The user selects one.

The device then displays a list of the containers in this location. The user can then click one of the containers in the list.

The device displays the container information a lists a series of new locations.

The user can click a new location (or a '''Back''' button)

Once a new location is chosen, the user can click a '''Confirm''' button to confirm the changes and exit to the menu, or '''Confirm...''' to confirm the changes and start another relocation.

{{Note}} Although this screen is created for use on the mobile devices, this screen will also work and be accessible by logging on as a PDA user on a normal browser. This functionality can be achieved through the standard Admin Location Administration screen.

Samples of the existing screen layouts are available in the file referenced as item 4 in Appendix A.

== PDA Change Container Status ==
This screen allows the user to change the status of a specific container.

The user is shown a list of locations, sequenced as follows:
* BAY
* PREP
* YARD
* DAMAGES
* TRAIN.
The user selects one.

The device then displays a list of the containers in this location. The user can then click one of the containers in the list.

The device displays the current status of the container and buttons for each of the available statuses to change to.

The user can then hit the '''Confirm''' button to confirm the changes and exit, or '''Confirm...''' to confirm the changes and start another change of container status.

{{Note}} Although this screen is created for use on the mobile devices, this screen will also work and be accessible by logging on as a PDA user on a normal browser. This functionality can be achieved through the standard Admin Container Maintenance screen.

Samples of the existing screen layouts are available in the file referenced as item 4 in Appendix A.

= Database =
The following tables will be used.

==CY_CONTAINERS (NEW)==
This is a new table, to store the information about containers that have been seen in the system before.

Fields:
* COMPANY_CODE
* WAREHOUSE_ID
* CONTAINER_ID
* ACCOUNT_ID
* TYPE_CODE
* WEIGHT_CODE
* LOCATION_CODE
* LOCATION_SEQ

Indexes:
# COMPANY_CODE/WAREHOUSE_ID/CONTAINER_ID
# COMPANY_CODE/WAREHOUSE_ID/ACCOUNT_ID/CONTAINER_ID
# COMPANY_CODE/WAREHOUSE_ID/LOCATION_CODE/LOCATION_SEQ

==CY_MOVES (NEW)==
This is a new table, to store the information about every container move that has happenend within the container yard.

Fields:
* COMPANY_CODE
* WAREHOUSE_ID
* REGISTRATION
* TYPE_CODE
* CONTAINER_ID
* ACCOUNT_ID
* HAULIER_CODE
* ORDER_NO
* STATUS_CODE
* HAZARDOUS_FLAG
* UN_NO
* DATE
* TIME
* FROM_LOCATION
* TO_LOCATION
* STATUS
* LINKED_REGISTRATION
* USER_ID
* SIGNATURE_ID

Indexes:
# COMPANY_CODE/WAREHOUSE_ID/REGISTRATION/TYPE_CODE/CONTAINER_ID
# COMPANY_CODE/WAREHOUSE_ID/CONTAINER_ID/DATE/TIME
# COMPANY_CODE/WAREHOUSE_ID/ACCOUNT_ID/DATE/TIME
# COMPANY_CODE/WAREHOUSE_ID/STATUS/TYPE_CODE

==CY_SIGNATURES (NEW)==
This table stores the signatures of the drivers. As a separate table, this can be cleared independently of the Moves tables.

Fields:
* SIGNATURE_ID
* SIGNATURE

Index:
# SIGNATURE_ID

==WARE_LOCATION==
This tables stores the locations used in the container yard.

Fields:
* COMPANY_CODE
* WAREHOUSE_ID
* LOCATION_CODE
* LOCATION_TYPE set to "Y"

Index:
# COMPANY_CODE/WAREHOUSE_ID/LOCATION_CODE/LOCATION_TYPE

==CONTAINER_TYPE==
This is a lookup table for the container types.

Fields:
* CONTAINER_TYPE
* DESCRIPTION

Index:
# CONTAINER_TYPE

==STK_STOCKIST==
This table is used to store the Accounts

Fields:
* STOCKIST_CODE
* STOCKIST_SUB_CODE (001)
* NAME

Index:
# STOCKIST_CODE/STOCKIST_SUB_CODE

==HAULIERS==
This table stores the Hauliers.

Fields:
* COMPANY_CODE
* WAREHOUSE_ID
* HAULIER_CODE
* NAME
* STOCKIST_CODE
* STOCKIST_SUB_CODE (001)

Index:
# COMPANY_CODE/WAREHOUSE_ID/HAULIER_CODE

==CONTAINER_STATUS==
This is a lookup table for the container status.

Fields:
* COMPANY_CODE
* WAREHOUSE_ID
* CONTAINER_STATUS_CODE
* DESCRIPTION

Index:
# COMPANY_CODE/WAREHOUSE_ID/CONTAINER_STATUS_CODE

==TRANSLATION_TABLE==
This generic lookup table is used to store the weights for 20ft containers.
* COMPANY_CODE
* WAREHOUSE_ID
* TRANSLATION_ID = "CWGHT"
* CODE
* DESCRIPTION
* CODE2 = the CONTAINER TYPE used to identify a 20ft container.

Index:
# COMPANY_CODE/WAREHOUSE_ID/TRANSLATION_ID/CODE

==FXM_USERS==
A generic table to store the basic user information

Fields:
* FXM_USERNAME
* FXM_DESCRIPTION
* FXM_PASSWORD

==FLEX_USER_COMP_WAREHOUSES==
A generic table to store the users' default warehouse.

Fields:
* COMPANY_CODE
* WAREHOUSE_ID
* LOGON_ID

==FLEX_USER_COMP_OWNERS==
A generic table to store the users' default account.

Fields:
* COMPANY_CODE
* LOGON_ID
* STOCKIST_CODE
* STOCKIST_SUB_CODE (001)

= EDI =
Each import and export of data can be created to work through the existing EDI capabilities of ''CALIDUS'' WMS, removing the need to have specific screens created within the Container Yard system to maintain them.

It is expected that a process will be created to sweep the system every 5 minutes for transactions that have completed but have not yet been sent via EDI.

If found, an email message will be sent per container.

The format of this message is defined in the document referenced as item 1 in Appendix A.

It is currently being investigated as to whether this process is going to change as part of this system refresh.


{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=WMS
|Ref1=MSC CODECO EDI.zip
|RefV1=N/A
|RefDate1=N/A
|Ref2=2007 to 2012.xls
|RefV2=N/A
|RefDate2=N/A
|Ref3=Stock Holding Report.xlsx
|RefV3=N/A
|RefDate3=N/A
|Ref4=Container screen shots.docx
|RefV4=N/A
|RefDate4=N/A
|REQ=0
|EST=0
|FS=3
|TS=0
|DEV=35
|ST=10
|IMP=5
|PM=5
|Client=PROD
|Year=2012
|FSEST=N
|Rev1=Phil Harding
|Rev1Title=OBS Project Manager
}}</div>
[[Category:{{#var:Client}} REQ]]

FS 295993 MY-8QPDRH Location and CD Scanning

2012-03-15T15:26:10Z

Pjh: v1.0 - issued after review

<div class="noprint">
{{#vardefine:Client|EXL}}
{{#vardefine:ClientName|DHL}}
{{#vardefine:System|''CALIDUS'' Mobile}}
{{#vardefine:Doc_Title|Location and CD Scanning}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|15th March 2012}}
{{#vardefine:Reference|295993 MY-8QPDRH}}
{{#vardefine:Year|2012}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
|Year={{#var:Year}}
}}


<div class="noprint">
= Functional Overview =

== Client Requirement ==
'''Change Request Summary:'''

Location & Check Digit scanning functionality required in WCS

'''Change Request Details:'''

At present the system will not recognise the location code and check digit if the barcode contains both. The requirement is to be able to recognise barcodes containing both the location code and the check digits as well as what it’s currently setup as.

Operations are ideally after an option that would let us to ALL the following
#Scan the location OR
#Manually enter the check digits OR
#Scan the location AND check digit combined.

Benefits identified as a result of the change:

:To help with the load scanning functionality.

Additional functionality was requested to be added to this change, by Mo Yasin of the Coventry site, as follows:

:Add support for "Pick By Quantity".

== Solution Overview ==
A new value will be added to the drop-down list for the "Bespoke Site Rule" rule on ''CALIDUS'' Mobile. The new value will allow the RDT/WCS to recognise the location code when a barcode is scanned that contains both the location and check digit values combined.
The new "Bespoke Site Rule" value will work in all scanning of locations and check digits, regardless of the setting of the Owner/Warehouse "Check Digits?" rule.

Currently when the "Check Digits?" rule is set to "Combo Check", the user can either scan the location code or manually enter the check digits.

At present, if the user scans a barcode containing both the location code and check digits then the RDT/WCS will not recognise the location code.

If the "Bespoke Site Rule" is set to the new value then the system will be changed to extract the first x characters from the barcode where x is equal to the "Aisle Length", "Bay Length" and "Level length" values added together, i.e. the length of the location code values.

{{Note}} It is assumed that the barcode values containing the combined location code and check digit values do not contain any location delimiters, e.g. "/", "\", "-", ":", etc.

At present, the site have the "Bespoke Site Rule" set to "DHL EXEL Whitwood" in order to utilise functionality to remove the leading "00" from SSCC values where the SSCC value is in a UCC-128 barcode format but the barcode itself is not a UCC-128 barcode.

The new "Bespoke Site Rule" value will remove the two leading zeros ("00" or "(00)") from the SSCC value (Customer Pallet) when the barcode format is not UCC-128.

{{Note}} If the barcode format is not UCC-128 but the SSCC value does not contain two leading zeros at the start of the value then nothing will be removed from the SSCC value. Also, the two leading zeros will only be removed if the user scans the SSCC value. If the user manually enters a SSCC value with two leading zeros, e.g. "001234567890123456", then this will value be accepted and the leading zeros will not be removed.

The bespoke functionality to remove the two leading zeros from the SSCC value will be utilised whenever the RDT prompts the user to enter a customer pallet value including:
* Goods Receipt
* Putaway
* Part Picking
* Picking
* Pallet Moves
* Replenishments
* Stock Moves
* Select Move
* Stock Transfer
* Ad Hoc Pallet Moves
* Stock Take
* Bulk PI
* Pallet Enquiry
* Move Enquiry

The operation want picks to be assigned to users in descending order of quantity to be picked. The existing rule "Picks by Quantity" currently orders the picks in "Picked Quantity" sequence. This will be modified to order the picks in "Picked Quantity" then "To Pick Quantity" sequence, both descending. This will ensure that the incomplete picks are always passed to the user in "To Pick Quantity" sequence, as the Picked Quantity for these incomplete picks (in the way that the operation's system is configured) will always be zero.

{{Note}} This affects only Pick Allocation By Order Page.

== Scope ==
* This change will be made to version 4.14 of the ''CALIDUS'' Mobile system only.
{{Note}} There is existing functionality controlled by the Bespoke Site Rule when set to the Whitwood site as follows:
* Location and Check Digit functionality:
** to control Barcode Type
** to extract the CD and location from the same barcode content
* SSCC (Customer Pallet) scanning in all modules:
** to ensure that CODE-128 barcodes are used as well as UCC-128 barcodes
** to remove extraneous parentheses ("(" and ")") from the barcode
** to validate that these barcodes always begin with "00"
* Multi-field scanning in Receipt
** Changing the title of the scanning box displayed
** giving an error given when scanning the wrong barcode types
** allowing CODE-128 and UCC-128 barcode types instead of UCC-128 only
* Check Receipt SSCC scanning functionality, forcing blind quantity entry
* Stock Barcode types (limiting UCC Stock barcodes to AI type 24 only)
* Login Password (forcing only entry of I2of5 barcode types only)

Mo Yasin of the Coventry operation confirmed that only the following functionality was required:
* Location and Check Digit functionality:
** to control Barcode Type
** to extract the CD and location from the same barcode content
* SSCC (Customer Pallet) scanning in all modules:
** to ensure that CODE-128 barcodes are used as well as UCC-128 barcodes
** to remove extraneous parentheses ("(" and ")") from the barcode
** to validate that these barcodes always begin with "00"
All other functionality would not be used, although it has been noted that certain owners and warehouses set up their operation already use:
* Check Receipt
* Multi-field scanning.
None of the Whitwood bespoke functionality other than that required by the operation will be added to the new Coventry Bespoke Site rule.



= Set-up =

== Pre-requisites ==
A valid and connected ''CALIDUS'' Mobile system.

== Menu Structure ==
N/A

== Data ==
* The Warehouse or Owner "Bespoke" Rule "Bespoke Site Rule" set to the new value of "DHL Coventry".
* The Warehouse or Owner "Bespoke" Rule "Pick By Quantity" set to "Enabled".
* The Warehouse or Owner "General" Rule "Check Digits?" set to "Combo Check".
* The Warehouse or Owner "General" Rules "Aisle Length", "Bay Length" and "Level Length" set to the correct values for the operation.
* The Warehouse or Owner "Pick" Rule "Pick Page Allocation" set to "By Order Page".
{{Note}} These rules should be set against all Warehouses in the system and all Owners that have been set up as restricted Owners (i.e. the owners that have their own rule set).


= Functional Description =
== Database ==
A new value will be added to the rule category associated to the Bespoke rule "Bespoke Site Rule". This will be set to value "COV" and will have the human-readable text "DHL Coventry".

== WCS Server Changes ==
The operation want picks to be assigned to users in descending order of quantity to be picked. The existing rule "Picks by Quantity" currently orders the picks in "Picked Quantity" sequence. This will be modified to order the picks in "Picked Quantity" then "To Pick Quantity" sequence, both descending.

The existing function PickSelect in module RDT_Pick will be modified. The flag "FLAG_PICKS_BY_QUANTITY" controls the existing functionality, which sorts the data as follows:
*Picking.[User Order] ASC,
*Picking.[order number] ASC,
*Picking.[Picked Qty] DESC,
*picking.[page number] ASC,
*picking.[seq number] ASC
This will be modified to:
*Picking.[User Order] ASC,
*Picking.[order number] ASC,
*Picking.[Picked Qty] DESC,
*'''Picking.[To Pick Qty] DESC,'''
*picking.[page number] ASC,
*picking.[seq number] ASC

{{Note}} The sorting under rule setting "Regroup Order by Stock" should also be amended in this way.

== RDTMenu1 Changes ==
The procedure InputProcessor_SetValue in module InputProcessorModRDT_Fields will be modified.

For Customer Pallet fields (FIELD_PALLET_CUST), a new section will be added for bespoke site rule "COV". This will act as follows:

If the entry has been scanned in any barcode type, the process will:
* Check for a leading "00" or "(00)".
** If there is, remove these leading 2 or 4 characters, then extract the following 18 characters as the Customer Pallet data.
** If there is not, accept the data scanned without modification.
If the entry has not been scanned (i.e. keyed), the data entered will be accepted without modification.

For Check Digit fields (FIELD_CD), a new section will be added for bespoke site rule "COV". This will act as follows:

If the entry has been scanned in any barcode type, the process will perform the following:
* The values of the Aisle, Bay and Level Length rules active for that Warehouse and Owner will be retrieved and added together, to give a location length.
* The first characters (up to the location length calculated) will be removed from the entered data, and the remaining returned as the Check Digit.
If the entry has not been scanned (i.e. keyed), the data entered will be accepted without modification.

For Location fields (FIELD_LOCATION, FIELD_LOCATION_CONFIRMATION), a new section will be added for bespoke site rule "COV". This will act as follows:

The process will perform the following:
* The values of the Aisle, Bay and Level Length rules active for that Warehouse and Owner will be retrieved and added together, to give a location length.
* For FIELD_LOCATION, or if the data has been scanned, the first characters (up to the location length calculated) will be extracted from the entered data and returned.
* For non-scan entry (i.e. keyed) of type FIELD_LOCATION_CONFIRMATION, the first characters (up to the location length calculated) will be removed from the entered data, and the remaining returned.

As this is completed at an Input level rather than at the process level, this change will be active in any process that requires:
*Location Entry
*Check Digit Entry
*Location Confirmation by Combo Check.
*Cust Pallet Entry



= Appendix A: TEST PLAN =

{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=To test the functionality created here
|MenuAccess=Main menu
|Prerequisites=Set up as in the [[#Set-up|Set-up]] section
|Objective=To test: allocating picks by Quantity; Location/CD entry and confirmation and; Customer Pallet Entry.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=WCS Maintenance
|Notes=
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check that the Warehouse "Bespoke" rule "Bespoke Site Rule" can be set to the value "DHL Coventry" and saved.
|Result=The data can be changed and saved.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Check that the Owner "Bespoke" rule "Bespoke Site Rule" can be set to the value "DHL Coventry" and saved.
|Result=The data can be changed and saved.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Allocate Picks by Quantity
|Notes=Set up ''CALIDUS'' Mobile as specified and allocated and pick list an order with several part picks across several stock codes, ensuring all have different pick quantities.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start part picking and complete the order to pick.
|Result=The picks will be allocated to the user in descending pick amount.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Customer Pallet and Location/CD Entry
|Notes=Set up ''CALIDUS'' Mobile as specified and ensure that you have multiple tasks of the following types available:
* Goods Receipt
* Putaway
* Part Picking
* Picking (Full Pallet)
* Pallet Moves
* Replenishments
* Stock Moves
* Select Move
* Stock Take
{{Note}} As the changes have been completed at an input rather than process level, it is necessary to test only one example of data input of Cust Pallet, Location, Check Digit and Location Confirmation.
}}{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Start a putaway and scan a pallet barcode with no leading zeroes.
|Result=The data is accepted as-is
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan a pallet barcode with leading "00" or "(00)"
|Result=The leading zeroes are removed
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter (key) a barcode with no leading zeroes.
|Result=The data is accepted as-is
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Key a pallet barcode with leading "00" or "(00)"
|Result=The data is accepted as-is
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan a location barcode with the location only in it
|Result=The location should be accepted
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan a location barcode with the location and check digit in it
|Result=The location should be accepted
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan a location barcode with the check digit only in it
|Result=The system should display an error (location invalid).
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan a location barcode with a different location and check digit in it
|Result=The system should display an error (location invalid).
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter (key) an invalid check digit.
|Result=The system should display an error (check digit invalid).
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter (key) any location code, valid or invalid.
|Result=The system should display an error (check digit invalid).
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter (key) the valid check digit.
|Result=The check digit should be accepted.
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Reposition a putaway and scan a location barcode containing only a location.
|Result=The system should prompt for a check digit.
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Backout and scan a location barcode containing only a check digit or invalid location
|Result=The system should display an error (location invalid).
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter (key) an invalid location.
|Result=The system should display an error (location invalid).
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter (key) a valid location.
|Result=The system should prompt for a check digit.
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan a location barcode containing only a location
|Result=The system should display an error (check digit invalid).
|Remarks=
|PassFail=
}}

{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Enter an invalid check digit
|Result=The system should display an error (check digit invalid).
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Scan a location barcode containing a valid location and check digit.
|Result=The system should accept the check digit.
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=Reposition another putaway. Enter a valid location. Enter (key) a valid check digit.
|Result=The system should accept the check digit.
|Remarks=
|PassFail=
}}
{{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=As the changes have been completed at an input rather than process level, it is necessary to test only one example of data input of Cust Pallet, Location, Check Digit and Location Confirmation. However, the following areas and functionality may also be tested:
* Goods Receipt
** Blind Receipt
** Check Receipt
* Putaway
* Part Picking
* Picking (Full Pallet)
* Pallet Moves
** Reposition
* Replenishments
* Stock Moves
* Select Move
* Ad Hoc Pallet Moves
* Stock Take
* Bulk PI
* Pallet Enquiry
* Move Enquiry
* Location Enquiry
|Result=As Expected
|Remarks=
|PassFail=
}}
{{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=WCS
|Ref1=EST 295993 MY-8QPDRH Location & CD Scanning v1.0.doc
|RefV1=1.0
|RefDate1=31/01/2012
|REQ=0
|EST=1
|FS=1.25
|TS=0
|DEV=3.25
|ST=1.75
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Phil Harding
|Rev1Title=OBS Project Manager
|Rev2=Mo Yasin
|Rev2Title=Client Representative
}}</div>
[[Category:{{#var:Client}} FS]]

REQ 294817 Clinical Trials Global Order Well

2011-12-20T12:13:17Z

Pjh: A minor edit made and the remaining is accepted

<div class="noprint">
{{#vardefine:Client|DHL}}
{{#vardefine:ClientName|DHL Clinical Trials}}
{{#vardefine:System|''CALIDUS'' Portal}}
{{#vardefine:Doc_Title|Global Order Well Requirements}}
{{#vardefine:Version|0.1}}
{{#vardefine:Date|20th December 2011}}
{{#vardefine:Reference|294817}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
}}
{{ #vardefine: SCR | 0 }}

<div class="noprint">
= Introduction =

This document is the {{#var:Doc_Title}} document.

== Objective ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, at Cherwell, on 9th December 2011.

This document has been written in a manner such that it can be approved by non-technical representatives of {{#var:ClientName}} whilst also being of sufficient detail to allow the Functional or Technical Specification phase for this area to begin.

== Scope and Limitations ==
* This document is based on the documentation provided by {{#var:ClientName}}, as referred to in the appendices, as well as information gleaned from the workshop with {{#var:ClientName}}.


*The changes will be made in the latest version of the ''CALIDUS'' Portal system.



= Client Requirements =
The business requirements are covered within a DHL document that has not yet been provided. This was reviewed by the OBS and DHL team on the meeting referenced above, along with a Concept of Systems screen prototype document.

The basic requirement is to allow access to basic inbound and outbound warehousing functions to satellite warehouse depots operating the Clinical Trials business, where they have no direct access to DHL's secure network and therefore the ''CALIDUS'' WMS system.

= Functional Description =

==Inbound==
A screen is required to update receipts.

The preadvice will be created in ''CALIDUS'' WMS by the Cherwell staff, either manually (for returns and direct supplier deliveries) or automatically (from Inter-Warehouse Transfers from the central Cherwell warehouse).
The preadvice is created in the depot warehouse with Serial Number information.

A new screen within ''CALIDUS'' Portal will display a list of all available GRNs for that depot (warehouse).
A number of filters will be available for the users to filter what is displayed:
* A drop-down list of Studies (i.e. Owners) will be available to allow the users to see GRNs just for a particular study. Note that the Study list should show only studies with GRNs - this data is available from the Supplier field against the GRN.
* A check box will be available to allow the users to elect to show all GRNs rather than just incomplete ones, only if the user has chosen to filter a particular study.
* Filter boxes to allow the user to enter a specific GRN or Advice Note (matching anything close to the reference entered).
The filters will default to all incomplete receipts for all studies.

The screen will limit the number of preadvices displayed on the grid to a reasonable number (e.g. 20), with buttons to fetch the next/previous pages of data.

The details displayed for GRNs found will be:
* Alert - showing whether a problem has been reported.
* Inbound to be Processed - GRN or Advice Note number
* Status:
**Pending - Available for receipt
**Complete - Receipt Completed
**Error - an alert has been raised.
* Expected Delivery Date
* Return - If the receipt is marked as a Return in ''CALIDUS'' WMS, then this column will be checked.
Note that the operation also discussed a 'Ready To Use' column, but that this was rejected by the meeting, as the functionality had little use.

When a GRN has been selected, the system will display a details screen.

This screen shows header information for the GRN (as per the previous screen).

A detailed grid will show the detailed product information:
*Product
*Quantity
*Batch
*Sell-by Date

A '''Print''' button is available to print the Preadvice List - this will be a simple screen displayed within Portal showing the details against the products, and all the required serial numbers. The depot will print this list direct from their browser. {{Note}} The prints throughout this document (Preadvice List, Pick List and Despatch Note) can be simple web lists, CSV extracts or PDF documents. If multiples of these types are required, this will increase cost.

The users will then receive the goods.

If there is any issue with the receipt, the user will report a problem by pressing a '''Report Problem''' button provided for this purpose. On pressing this button, the screen will display a confirmation dialogue, displaying the GRN information, requesting that the user confirm that they are reporting an issue. The user's name should be prominently displayed on this dialogue, ensuring that they are aware that they are responsible for this process.

Pressing '''No''' will return to the GRN detail form.

Pressing '''Yes''' on the screen will allow the user to enter details of an email. The Email recipient and some of the details will be pre-set on the form. On clicking OK, the email will be sent to the central contact email. The details of the email will also be saved in ''CALIDUS'' WMS on a new table created for this purpose.

The central contact email will be set up against the users' group within ''CALIDUS'' Portal.

{{Note}} This Confirmation Dialogue will be used extensively throughout the product, whenever the user confirms data that will update ''CALIDUS'' WMS. This will ensure that the user is made aware of their responsibility when updating the system, as they will be tracked within ''CALIDUS'' WMS.

If a GRN has a problem identified against it, the GRN should be highlighted in the GRN select grid with an Alert icon against it. If so, this GRN can no longer be actioned by the Depot staff, but clicking on the icon should display the details of the problem reported.

If there is no problem with a GRN receipt, the users will press a button to update the GRN. Again, a confirmation dialogue will be displayed, showing the GRN details and the user name, as before.

If the user confirms that they wish to go ahead with the GRN confirmation, the system will create all pallets in their default putaway locations with all preadvised serial numbers received as if 100%. The screen will also mark the GRN as putaway confirmed. Standard processing (automatically holding the stock until the temperature has been confirmed) will remain in place.

When a supplier is going to send stock direct into the depots without routing through Cherwell, the Cherwell users will manually create a preadvice with all serial numbers. Once created, this will appear on the GRN list within ''CALIDUS'' Portal.

It was discussed that an email be sent to each depot, once per day, indicating the preadvices arriving in on that day. The meeting rejected the proposal, as this either encouraged lazy processes, or the messages will simply be ignored.

It was also noted that the Business Requirements Document (section 9.4.1) suggested that Carrier, Temp, Packaging and Monitor requirements were to be preadvised. The meeting decided that this was probably not required, but that this should be confirmed by the operation (Lukasz Danel of the DHL team to confirm).

'''SCR-{{#var:Reference}}-{{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}: Create Portal Inbound Confirmation screen'''

==Outbound==
The order will be created in ''CALIDUS'' WMS and allocated by the Cherwell staff.

Any orders that have been created through the EDI process will simply be allocated by the Cherwell staff.

Any orders that have been manually entered by the Cherwell staff must be double-checked (to ensure that the Serial Number information has been keyed correctly). The process for this will be:
* The order will be keyed by one user.
* A second user will regularly show a list of all manually-entered orders at Entered status, through the standard ''CALIDUS'' WMS reports. The list will show all serial numbers entered against the orders.
* For each order on the list, the user will check the serial numbers on this list. If they are correct, this user will then allocate the order and move onto the next on the list, until all are completed.
* If the order's serial numbers do not match, the user will cancel the order and re-enter a new order with the serial numbers.

A new screen within ''CALIDUS'' Portal will display a list of all available orders for that depot.

A number of filters will be available for the users to filter what is displayed:
* A drop-down list of Studies (i.e. Owners) will be available to allow the users to see Orders just for a particular study.
* A check box will be available to allow the users to elect to show all Orders (included completed ones) rather than just pending ones, only if the user has chosen to filter a particular study.
* A Drop-down List of Statuses will be available to allow the user to see Orders at that particular status.
* A filter box to allow the user to enter a specific Order Number (matching anything close to the reference entered).
The filters will default to show all incomplete orders for all studies.

The screen will limit the number of Orders displayed on the grid to a reasonable number (e.g. 20), with buttons to fetch the next/previous pages of data.

The details displayed for Orders found will be:
* Alert - showing whether a problem has been reported.
* Order Reference - Order Number
* Priority
* Status:
**Pending - Any orders at status Allocated or Pick Listed.
**Picked - Any orders at status Pick Confirmed.
**Packed - Any orders at status Pick Confirmed with Pack information entered against them.
**Issued - Any later order status (Despatched, POD Confirmed, Invoiced, etc).
* Selected - this will be a check box for the user to select which orders are to be actioned. There will also be a button above this column allowing the user to select all orders displayed on the grid. Note that if there are multiple pages of orders, only those displayed on the grid can be selected at the same time.

A number of action buttons will be provided to work on the orders selected. These buttons will be disabled depending on the status of the orders, as described below.

A '''Print''' button will be available. If the orders are at status 'Pending', this button will print Pick Lists for all the orders selected. Multiple orders can be selected when clicking this button. On printing pick lists, this button will update the status of the selected orders to Pick Listed, if they are not already at Pick Listed status.

The Pick List produced will be a simple list of the order information, followed by each product, then the Serial Numbers against each product. The Serial numbers will be displayed in the sequence in which they are held on ''CALIDUS'' WMS. A Watermark will be shown behind each page, showing that this list is for internal use only. The lists can then be printed directly from the user's browser.

If the orders selected are at 'Complete' status, this button will print a Despatch note for all the orders selected. Multiple orders can be selected when clicking this button.

The Despatch note produced will be a simple list of the order information, followed by each product, then the Serial Numbers against each product. The Serial numbers will be ordered ascending and displayed in this sequence. The notes can then be printed directly from the user's browser.

{{Note}} If orders at multiple statuses are selected, all buttons will be immediately disabled - only orders at a single status can be processed together.

{{Note}} If any order selected has an Alert against it, all buttons will be immediately disabled, as all processing of orders against with an alert will be completed through ''CALIDUS'' WMS by the Cherwell staff.

{{Note}} If an order is selected that is not at Pending or Issued status, this button will be disabled.

A '''Pick/Pack Confirm''' button will be available. If the order selected is at status 'Pending', this button will call a Pick Pack screen, described later. Note that only a single order can be processed by this button - if more than one order is selected, the button should be disabled.

{{Note}} If an order is selected that is not at Pending status, this button should be disabled.

A '''Despatch''' button will be available. If the order selected is at status 'Packed', this button will display a confirmation dialogue, showing the Order details and the user name, as before.

If the user confirms that they wish to continue with the despatch, the system will update the order to Despatched within ''CALIDUS'' WMS. The Despatched date and time will be set to the current date and time, and the user will be set to the logged-in user ID. Once completed, the Despatch note will be displayed (as with the Print button above).

{{Note}} Only a single order can be processed by this button - if more than one order is selected, the button should be disabled.
{{Note}} If an order is selected that is not at Packed status, this button will be disabled.

A '''Report Problem''' button will be available at any status. If this button is pressed, this button will display a confirmation dialogue, showing the Order details and the user name, as before.

If the user confirms that they wish to continue with reporting a problem, the system will display a form to allow the user to enter details of an email. The Email recipient and some of the details will be pre-set on the form. On clicking OK, the email will be sent directly through the client's email program. The details of the email will also be saved in ''CALIDUS'' WMS on a new table created for this purpose.

{{Note}} Only a single order can be processed by this button - if more than one order is selected, the button should be disabled.

'''SCR-{{#var:Reference}}-{{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}: Create Portal Outbound Control screen'''

==Pick/Pack Screen==
This screen is used to capture the information regarding which serial numbers have been picked and packed into which cartons.

The screen will display some basic order information on the top of the screen.

The screen will allow entry of Air Way Bill and Carrier. Neither will be validated, other than they have been entered.

A grid will show all packs created for the order. Each pack created will display:
* Pack ID - A unique numeric counter for each pack
* Box Used - the Consumable Box Type used (the stock code and description)
* TM Used - the Consumable Temperature Monitor used (the stock code and description)
* TM Serial - The Serial Number of the TM used above.
* Action - An 'Edit' button will be provided to edit the details entered if this data has not been interfaced back to ''CALIDUS'' WMS.

A '''New''' button will be available on the screen to add new packs to the order.
When pressed, the screen will display an entry form with the following fields:
* Box Used - the Consumable Box Type used. If WMS Packing has been enabled to require the entry of consumable box types, a drop-down list of all available box types will be shown here, showing the Code, Description and Quantity available). The user must select a box type from here.
* TM Used - the Consumable Temperature Monitor used. If WMS Packing has been enabled to require the entry of consumable temperature monitors, a drop-down list of all available temperature monitors will be shown here, showing the Code, Description and Quantity available. The user must select a monitor from this list.
* TM Serial - The Serial Number of the TM used above. If WMS Packing has been enabled to require the entry of consumable temperature monitors and the monitor type selected above requires serial number entry, a drop-down list of all available serial numbers of that monitor type will be shown here. The user must select a monitor serial number from this list.

{{Note}} The Drop-down List of Consumable Box Types, Monitors and Monitor Serials may be displayed as a lookup screen instead. Regardless, the screen should account for consumable media used on this order.

{{Note}} The information regarding which of the above have been used will not be interfaced to ''CALIDUS'' WMS until the order is confirmed packed. This means that multiple users may attempt to use the same monitor - this must be manually controlled by the operations.

A '''Save''' button will be available to save the new pack. A '''Cancel''' button will discard the new changes.

If the user elects to edit an existing pack, the entry form above will be shown, pre-populated with the data from the grid (including showing the pack ID). In this case, the same validation is applied as above.

Additionally, a 'Delete' button will be shown, allowing the user to remove the created Pack.

If detailed packing is required, the screen should only allow one pack to be created. If more are required, then a problem should be reported (directly from this screen), following the normal problem reporting process. So, if the user presses the button to add another pack on a detailed packing trial, a confirmation dialogue will appear explaining the issue. The user's name will be shown as normal. If the user elects to continue, they will be taken to the screen to enter the problem, an email will be sent and a problem message created. When complete, the user will be returned to the Order Select screen, where the order will be marked with an alert.
Note: Only trials for UCB will be configured within ''CALIDUS'' WMS for detailed packing. All other trials will be configured for Pack level only and will be able to create multiple packs.

A '''Confirm''' and '''Cancel''' button will be available on the screen.

The '''Cancel''' button will discard all changes and return the user to the Order Select screen.

The '''Confirm''' button will display a confirmation dialogue, displaying details of the order and requesting whether the user wishes to continue with pick/pack confirmation for this order. The user name will be displayed on this dialogue.

If the user selects '''No''', they will be returned to the Pick/Pack confirmation screen where they left it, with all data unsaved but intact.

If the user selects '''Yes''', ''CALIDUS'' Portal will update ''CALIDUS'' WMS. The process will be as follows:

First, the order will be pick confirmed completely. The following data will be set:
* User - will be defaulted to the user logged in
* Date - current date
* Time start - current time, minus 10 minutes
* Time stop - current time minus 1 minute.
The Order Status will be updated to Pick Confirmed and all audit data maintained as standard.

Once this is complete, the system will save the packing data entered by the user and close the pack as complete.

'''SCR-{{#var:Reference}}-{{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}: Create Portal Pick/Pack screen.'''

==Reports==
Several report requirements were discussed. The operation agreed to confirm all their reporting requirements would be able to be completed through the Oracle Data Extracts. If this was the case, then the Oracle Data Extract suite of reports would be made available through ''CALIDUS'' Portal, to allow the users to run their reports from there.

'''SCR-{{#var:Reference}}-{{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}: Include Oracle Data Extracts within Portal.'''

If any reports are required that cannot be covered by this functionality, development of new reports within ''CALIDUS'' Portal will be required.

=Optional Processes=
==Add Serial Numbers to Order Entry==
It was noted that the operation may wish to allow specific users the ability to create preadvices. This is to allow for the use of this by the depot staff, when returns come direct to the depot or a supplier wishes to deliver direct.

In this case, the users require the ability to create a preadvice of the products and quantity of each to be received, specifying Batch and Sell-by Date information, and with all serial numbers entered. The Batch and Sell-by Date and Serial numbers will be validated that they are required for the product. If Serial Number entry is required, the screen will validate the format required by the operation.

'''SCR-{{#var:Reference}}-{{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}: Amend Preadvice to allow Batch, Sell-by Date and Serial Number entry.'''

Note that this functionality will be specifically enabled or disabled through the user account, by adding the menu to the users requiring this functionality, so that specific users can be denied the Order Entry functionality.

==Handing Problem Items Back to the Depot==
The operation confirmed that the process of handling problems was that the processing of the problem item would be handed back immediately to the Cherwell team. However, it was noted that it may be required to hand the processing of the problem item back to the depot, once the problem is cleared.

When an issue is reported for any process, the Portal users cannot continue until the problem is resolved. Therefore the messages created must have a 'Resolved' flag against the message. Screens must check for a non-resolved problem message against an item to stop it being processed through ''CALIDUS'' Portal.

It would be necessary then to allow a higher security level user (i.e. a supervisor) to amend and clear problems raised against the order or preadvice.

This can be achieved be amending the screens created above so that, when the messaging icon is clicked against an order or preadvice and the messages are displayed, the supervisor would be given the option to click a flag to clear the message, and apply a comment against it to confirm that it is cleared.

Alternatively, a new screen can be created that allows the user to see all messages, filtering by Order, GRN or Message Status, to clear any messages raised in one screen.

The Inbound and Outbound screens will also be modified to indicate whether the item has un-cleared problem messages (for example, with a red background) or whether all the problem messages have been cleared (for example, with a green background). Items with only cleared messages will allowed to be actioned by the screens.

'''SCR-{{#var:Reference}}-{{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}: Implement Supervisor Message Handling within ''CALIDUS'' Portal'''

As an extension of this functionality, it should also be possible to email the user that raised the original problem message, identifying that the problem has now been resolved. In order to achieve this, it will be necessary to allow the users set up in ''CALIDUS'' Portal with an email address. When a message is cleared by a supervisor, the same messaging process used to send the original message can be called to send this resolution email.

'''SCR-{{#var:Reference}}-{{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}: Implement Problem Resolution emails within Portal.'''

==Messaging Functionality Within ''CALIDUS'' WMS==
The message handling processes could also be implemented within ''CALIDUS'' WMS as well, allowing for users of the WMS product to clear messages and send emails, as described above in both SCRs.

'''SCR-{{#var:Reference}}-{{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}: Implement Supervisor Message Handling within ''CALIDUS'' WMS.'''



= Appendix A: Table of SCRs and Ballpark Estimates =


{{ #vardefine: SCR | 0 }}
{{REQ_SCR_Header}}{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=Portal
|Area=Inbound
|Description=Create Portal Inbound Confirmation screen
|Estimate=0
|Notes=
}}{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=Portal
|Area=Outbound
|Description=Create Portal Outbound Control screen
|Estimate=0
|Notes=
}}{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=Portal
|Area=Outbound
|Description=Create Portal Pick/Pack screen.
|Estimate=0
|Notes=
}}{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=Portal
|Area=Reports
|Description=Include Oracle Data Extracts within Portal.
|Estimate=0
|Notes=2
}}{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=Portal
|Area=Inbound
|Description=Amend Preadvice to allow Batch, Sell-by Date and Serial Number entry.
|Estimate=0
|Notes=3
}}{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=Portal
|Description=Implement Supervisor Message Handling within ''CALIDUS'' Portal
|Estimate=0
|Notes=3
}}{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=Portal
|Description=Implement Problem Resolution emails within Portal.
|Estimate=0
|Notes=3
}}{{REQ_SCR_Line
|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WMS
|Description=Implement Supervisor Message Handling within ''CALIDUS'' WMS.
|Estimate=0
|Notes=3,4
}}{{REQ_SCR_Footer}}

Notes:
#Any high level ballpark estimates for development are based on the basic information provided, are provided as-is and are subject to detailed design and creation of an SCR. All estimates include Design, Specification, Development and Testing.
#This assumes that all reports required can be produced through the Oracle Data Extract suite. If other reports are required, further changes will be required incurring further cost.
#These items are optional and are not required to fulfil the core business requirements.
#This development can be used to replace the previous 2 changes, or can be completed as well.


{{Doc_Appendix
|Appendix=B
|Estimate=N
|Glossary=PORTAL
|Ref1=CoS111209.xls
|RefV1=
|RefDate1=09/12/2011
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year=2012
|FSEST=Y
|Rev1=Phil Harding
|Rev1Title=OBS Representative
|Rev2=Asa Tilley
|Rev2Title=DHL Representative
}}</div>
[[Category:{{#var:Client}} REQ]]

FS 291253 PW-8KRCWE Prioritise WMS-WCS Messages

2011-10-10T16:24:25Z

Pjh: v1.0 created

<div class="noprint">
{{#vardefine:Client|DHL}}
{{#vardefine:ClientName|DHL Atherstone}}
{{#vardefine:System|''CALIDUS'' WMS}}
{{#vardefine:Doc_Title|Prioritise WMS-WCS Messages}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|10th October 2011}}
{{#vardefine:Reference|291253 PW-8KRCWE}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
}}


<div class="noprint">
= Functional Overview =

== Client Requirement ==
Prioritise certain messages from WMS to WCS so that they take priority over standard messages and arrive before them into the WCS. The messages to be modified initially are the UPC responses to Receipt Precheck, Putaway and Pick Replacements from Pick Shortages.

== Solution Overview ==
The standard messaging function within ''CALIDUS'' WMS will be modified to ensure that all messages are sent at a standard message priority (i.e. 5), rather than accepting the default from the Oracle queues.

The UPC responses to Receipt Precheck, Putaway and Pick Replacements from Pick Shortages messages will be modified to be set at a high priority (i.e. 1-4). The messages affected by the high priority setting will not be modifiable by the user, so only these specific messages will be affected.

The Standard and High Priority values will be specified as system parameters.

This modification will ensure that the high-priority messages specified will be sent to the WCS before lower-priority messages.

== Scope ==
{{Note}} This modification affects the ''CALIDUS'' mobile system connecting to the Oracle ''CALIDUS'' WMS system only.

{{Note}} The message priority does not affect the content of the message, just the sequence in which they are sent to ''CALIDUS'' Mobile.

{{Warning}} This modification affects the core ''CALIDUS'' Mobile interface in ''CALIDUS'' WMS. This will require several programs to be recompiled and released, as well as a fundamental change to the Oracle Advance Queues within the database. As such, the installation of this will require scheduled downtime. No ''CALIDUS'' Mobile programs need to be released to implement this functionality, however.



= Set-up =

== Pre-requisites ==
A valid ''CALIDUS'' Mobile system must be connected to your ''CALIDUS'' WMS.

== Menu Structure ==
None

== Data ==
Warehouse rule 'RPCA' ("RF Picking - Create Amendments") must be created and set to value 'Y'.



= Functional Description =

==DP_WMS_IF==
This Oracle package will be changed to allow the WMS RF sending packages to specify a priority on the messages sent to ''CALIDUS'' Mobile.
All overloaded versions of procedure 'send_to_wcs' and 'send_edi_to_wcs' will be modified to receive a priority parameter. If no priority is specified (for the majority of messages), the priority will default to 5.

The priority of the record built to send (p_rec_dets) will be set to this parameter.

{{Note}} The contents of this procedure contain amendments for stock take developments and changes to the way that the common record are retrieved that must be reflected in the latest version - the version differences must be checked for this. The procedures to be checked are:
*get_session_qschema_agent
*get_edi_session_qschema_agent
*recvd_rec

==DP_RDT_STKENQ==
Procedure 'check_upc_code' will be modified so that, when messages are returned to ''CALIDUS'' Mobile with the UPC information, they are sent with priority value '2'. This is done when the procedure 'send_edi_to_wcs' is called at the end of the procedure.

==DP_RDT_PICK_CONF==
This package will be modified to set the priority of any pick replacement message returned to ''CALIDUS'' Mobile to '2'.

Pick Modification messages are only returned to ''CALIDUS'' Mobile if the warehouse rule 'RPCA' is set to 'Y', through procedure 'search_for_alternative', when there has been a shortage against a particular pick line.

If an alternative pick is found, the pick task on ''CALIDUS'' WMS is created and a pick task is sent using procedure 'send_to_pick'. This procedure is called only for this reason. This procedure will be modified to set the priority of the messages to '2' when the procedure 'send_edi_to_wcs' is called from here.

If no alternative pick is found, a message is returned to ''CALIDUS'' Mobile to inform the users that no alternative pick is available. This is sent from procedure 'send_blank_pick'. This procedure is called only for this reason. This procedure will be modified to set the priority of the messages to '2' when the procedure 'send_edi_to_wcs' is called from here.



= Appendix A: TEST PLAN =

{{TestPlan_Header
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=Test prioritisation of messages from WMS to WCS.
|MenuAccess=None
|Prerequisites=See Setup section
|Objective=To test that: all standard messages are defaulted to a default priority; high-priority messages are sent with the high priority and; messages at different priority levels are received in the sequence expected.
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Standard Message Sending
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.1 }} }}
|Action=Send all types of messages (for the client, this is standing data, picks). Check the sent messages on the WMS Queue and the WCS Incoming Log.
|Result=All messages enqueue with priority 5 and are received in the sequence they are sent.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Priority Message Sending
|Notes=
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.1 }} }}
|Action=Perform a UPC enquiry (from Blind Receipt or Putaway). Check the sent messages on the WMS Queue and the WCS Incoming Log.
|Result=Responses are received and were put on the queue at priority 2.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.1 }} }}
|Action=Perform a short pick of stock where there is replacement stock in the warehouse. Check the sent messages on the WMS Queue and the WCS Incoming Log.
|Result=Responses are received and were put on the queue at priority 2.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.1 }} }}
|Action=Perform a short pick of stock where there is no replacement stock in the warehouse. Check the sent messages on the WMS Queue and the WCS Incoming Log.
|Result=Responses are received and were put on the queue at priority 2.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}

{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Message Queue Sequencing
|Notes=Send through some standing data messages that will take time to perform (>1000 messages). All tests below should be completed before these messages have all been received.
}}  {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.1 }} }}
|Action=Perform a UPC enquiry (from Blind Receipt or Putaway).
|Result=A response is received in a timely fashion.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.1 }} }}
|Action=Perform a short pick of stock where there is replacement stock in the warehouse.
|Result=A response is received in a timely fashion.
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.1 }} }}
|Action=Perform a short pick of stock where there is no replacement stock in the warehouse.
|Result=A response is received in a timely fashion.
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


{{Doc_Appendix
|Appendix=B
|Estimate=Y
|Glossary=WCS
|Ref1=EST 291253 PW-8KRCWE Prioritise WMS-WCS Messages
|RefV1=1.0
|RefDate1=19/08/2011
|REQ=0
|EST=1.25
|FS=0.75
|TS=0
|DEV=1.5
|ST=1.5
|IMP=0
|Client={{#var:Client}}
|Year=2011
|FSEST=Y
|Rev1=Phil Harding
|Rev1Title=OBS Project Manager
|Rev2=Phil Isle
|Rev2Title=DHL Representative
}}</div>
[[Category:{{#var:Client}} FS]]