View source for REQ 290107 Nightfreight RF Requirements

<div class="noprint">
{{#vardefine:Client|PACE}}
{{#vardefine:ClientName|Nightfreight Pacemaker}}
{{#vardefine:System|Calidus Mobile}}
{{#vardefine:Doc_Title|Nightfreight RF Requirements}}
{{#vardefine:Version|1.0}}
{{#vardefine:Date|15th July 2011}}
{{#vardefine:Reference|290107}}
</div>
{{Doc_Title
|Client={{#var:ClientName}}
|System={{#var:System}}
|Title={{#var:Doc_Title}}
|Reference=FS {{#var:Reference}}
|Version={{#var:Version}}
|Date={{#var:Date}}
}} 

<!-- TOC --> 
<div class="noprint">
= Introduction  =
<!-- The introduction will detail the initial requirements supplied by the client -->
This document is the {{#var:Doc_Title}}.

== Objective  ==
The primary purpose of this document is to document the requirements gathered from {{#var:ClientName}}, at the OBS Logistics offices in Liverpool, on 6-7th July 2011.

<!-- List all amendments to the requirements here, and reference in final section, e.g. The document also encompasses the follow-up meeting held at X, with Y and Z attending, where the requirements were modified. See the minutes of the meeting referenced as item X in appendix B --> 

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 workshops with {{#var:ClientName}}.

<!-- ANY scope or limitations, bulleted. -->
* The changes will be made in the latest version 3.4 of the Calidus 3pl-Mobile system, and version 7.70 of the Calidus WMS system.
* The client has decided that the initial implementation will be for Goods In processes only. 

<!-- NEW PAGE -->

= Client Requirements =
Listed below are the proposed processes that will be followed by the warehouse operatives using ''Calidus'' Mobile. Also shown are the SCRs required for this to be achieved. 

== Operational Information ==
The current client in this operation is Carpetright.

'''Note:''' There are other clients held within the warehouse as well as plans to expand the operation. However, the processes discussed are those required for the Carpetright operation and may need to be reviewed for different clients.


The stocked items are beds, mattresses, bed frames, mattresses, bed heads, etc.

There are 2 types of products stored for this operation:

* MTO - Made to Order
* Stocked - Off-the-shelf products

MTO items are expensive, manufactured on demand and shipped to the warehouse, for a specific customer order. This Buyer's Ref/Item Ref/Manufacturer's PO is stored in ''Calidus'' WMS as the Customer Rotation or Batch.

Stocked items are popular and pre-manufactured and stored at the warehouse. As these products are not manufactured for a specific order, there is no buyer's reference stored against them.


Each product is configured with a 'pack quantity' in the stock Pack Size field in ''Calidus'' WMS. 

For example, a divan bed (the SKU) consists of a 2-part divan base and a mattress, hence the Pack Size is set to 3. A bed head is a single part, so has a Pack Size of 1.

This is referred to as the number of items.

The product type for all products is the same.


There are two order types within the operation: 

* Hub - delivered from the warehouse to a hub, where the items are sorted and then sent on to the customers.
* Pacemaker - deliver direct to customer's home (D2H)

Standard order quantities are 1 or 2 products, although there are exceptions, they are in the vast minority.


The number of users required for the operation is:

* 3 picking teams
* 2 at intake (one receiving, one putaway)
* 1 loading team.

Therefore the minimum number of concurrent users for this operation is 4. 

RF hardware (including but not limited to RF access ports, RF wireless router, RF site survey, and power and cabling) will be sourced by the client.

The RF units must be:

* Wavelink Studio compatible.
* Have easily accessible cursor keys, ESC/CLR key and function keys.
* Compatible with the wireless backbone in the warehouse.

5 RF units should be sourced (1 as a spare) with sufficient charging cradles, spare batteries and accessories as required by the operation.

OBS recommend the Motorola MC9000 series of units, although many other hardware makes and models are available and supported.

== Standard Processing ==
=== Locations ===
There are the following aisles within the operation:

* A - Beds and mattresses. Multiple locations.
* B
* C
* D
* M - Mezzanine. Stocked items only. All one location.
* Z - Wood. Currently 2 locations.

All locations are non-palletised.


The locations in the warehouse will be barcodes with a CODE-128 barcode containing the location code only. This will also be human-readable. The printing of the barcodes and subsequent labelling of the locations will be undertaken by the operation.

== Goods In ==
=== Standard Goods Receipt ===
'''Current Process'''

A spreadsheet is emailed from the supplier, showing that 10 MTO products are to be received. The file received will detail:

* SKU (12 digit), 
* Batch (Buyers Ref)
* Qty

This file is received 24-48 hours before delivery.


Receipts can consist of a combination of MTO and stocked items.


When the stock arrives, the operation has 2 hours to unload and receive all the stock.

All of the stock is labelled to a degree.

The operation prints two copies of the preadvice spreadsheet.

The operation checks for damages and missing parts - any damages or missing parts are returned to the driver and will not be received.

The operation then places all complete products onto trolleys for putaway and notes the details against the preadvice spreadsheet.

It was noted that the ''Calidus'' WMS preadvice sheet may be unsuitable for the operation. If so, a small change could be made to the report. 

'''SCR:290107-1: Change to WMS preadvice sheet to show the number of stocked items per line i.e. if preadvice of 10 stocked items, should be 10 lines on the sheet, so the operation can enter the details.'''


When receipt is complete, the operation sign only for the stock that they have received, by comparing the delivery notes with the preadvice spreadsheet, matching up the items that were received against the delivery paperwork.

Note that the operation enters all the details manually in the ''Calidus'' WMS Receipt Confirmation screen when all products have been putaway.


Most suppliers label their delivery products through a Supplier Label Portal system, provided by Nightfreight.

The Supplier also confirms their despatch through this system.


This system will be modified to provide an EDI preadvice. '''Note: '''This Portal will need to be modified to allow suppliers to enter the stocked items to be delivered and print labels for them here.

'''SCR-290107-2: Import EDI file from customer's Portal system.'''


Additionally, the format of the delivery labels from this system must change.

The labels will be changed to a UCC/EAN-128-style label showing SKU, Batch (if present i.e. for MTO products) and a unique item ID or SSCC-ID (made from Manifest Number and Manifest Item No) of 18 digits.

2 GS1-compliant barcodes will be produced, one for the SSCC-ID and one for the stock code and batch.

Both barcodes will be in UCC/EAN-128 barcode format.

The first will be subset C (numeric pairs only) and will encode a 00 followed by the 18-digit SSCC-ID.

The second will begin the subset A and encode a 240. This will then switch to subset C and encode the 12-digit product code followed by a separator (FNC1), then a 10 followed by the 20-digit batch code.

In both instances, the barcodes should be of comparable width (not exceeding 165mm), height (15% of the width or 13mm, whichever is greater) with a suitable quiet zone (blank space) at each end. The blank space required is dependent on the density of the barcode itself; however 10mm space on either side is sufficient, regardless of barcode density.


One supplier (up to 40% of the stock received in the system) does not use this Supplier Portal, but instead produce their own labels. Therefore this supplier will not be able to provide an EDI file, but they '''must''' change their label formats to match the above if the following RF-enabled process is to be used on their stock. If not, then receipts from this supplier must be received through a different process, requiring use of pre-printed roll of stationary for the SSCC-ID.


'''RF Receipt Process'''

The operation will ensure that all products are together (if in multiple pieces) and inspected before they are received on the RF gun.


The user will enter the Goods Receipt module from the main RF menu.

The user will be prompted to Scan or Enter the GRN or ASN. The RF unit is configurable in which item it will request, and the user can switch which item is used using the F5 function key.

Once entered, the user will be prompted to scan or enter the unique pallet ID. This will be through scanning the SSCC-ID on the new delivery labels.

The user will then be prompted to scan or enter the product. This will be through the scanning of the SKU barcode on the new delivery labels.

The RF unit will be configured to not allow re-receipt of any already-received SSCC-IDs on this receipt, will not allow over-receipt of any advised product and will not allow receipt of any unadvised product. 

The RF unit will then display the entered information and request more details. 

For MTO products, the user will be prompted to scan or enter the batch. Note that Stocked products will not request this entry. The entry of Batch is controlled by the Lot_Traceability flag against the product in ''Calidus'' WMS being set to 'None' for Stocked products and 'Cust Batch Only' against the MTO products.


The user will then be prompted for Quantity and Pallet Type - for this operation, the users will enter 1 in the quantity field and enter over the Pallet Type field.

Once all required details have been entered, the RF unit will display the details of the pallet to be received and request the user to confirm. The user can press F2 to amend the data entered, or F1 to confirm the pallet as received.


At this point, the details of the pallet received will be sent back to ''Calidus'' WMS, where the pallet will be marked as received. All normal audit trail records are maintained. The process will suggest a putaway location for the pallet, which will be a default floor location.

Note: It is possible to automatically suggest locations directly for some products (i.e. loose wood). This may also be set up for the Stocked products, as they will all be located in the same location (the mezzanine).

'''Note:''' A bespoke Owner rule blanks the rotation field within the goods receipt confirmation screen if the product has a product group of 01. The ''Calidus'' WMS RF programs will need to be modified to replicate this functionality. 

'''SCR-290107-3: Amend ''Calidus'' WMS RF Goods Receipt process to blank the rotation field.'''


Once the message is sent, the RF unit will display that the receipt of this pallet has been completed, and request the user as to whether they wish to continue receiving pallets against this GRN. If there are more products, the user will continue to receive until all are completed.

'''Note:''' More than one user may receive against a GRN at a time.


If all the products on the preadvice are received as expected, the ''Calidus'' WMS process will automatically confirm the GRN as Received. If there is a discrepancy (i.e. products not received) the GRN will not be automatically confirmed.


Once the receipt is completed, the operator will check the GRN within ''Calidus'' WMS for completion. They will use the information on this screen to sign the delivery notes only for the items that have been received.

The user will check each delivery note against the ''Calidus'' WMS Goods Receipt Confirmation screen. In order to achieve this, the operation will position a WMS terminal in or near the gods in bay. The screen will show a line for each product and batch, showing the amount expected and the amount received through the RF system.

If the amounts match, the user will sign that delivery note and move to the next.

If the amount received is less than the amount on the delivery note, the user will amend the delivery note to show that less than preadvised was received.

If none of the stock was received, the user will not sign the delivery note for that product.

The user will then close down the receipt by using this screen to Receipt Confirm the GRN.


'''Note:''' The GRMK (Goods Receipt Confirmation) EDI is sent for MTO receipts at the point of receipt confirmation.

The GRMK EDI for stocked items is delayed until when a product has been picked. The reason for this is that a message to the client must always include a Buyer's Ref. A Buyers ref is received on the Order EDI regardless of whether it is for a stocked or MTO product, so when the product is picked the system then knows what the buyer's ref is and therefore can add it to the EDI.


It was noted that there may be potential to receive stock through a reduced number of barcode scans, by combining the scans of the delivery labels' UCC/EAN barcodes and extracting all the information as possible in one process. This functionality is being produced within the product at this time, but is not yet available. Once this is available, the process will be checked by the operation to see if it is suitable without modification. 

=== RF Putaway Process ===
'''Current Process'''

Currently the operation locates the stock into the locations and marks a copy of the preadvice spreadsheet with the locations. They then key in al this receipt and putaway information directly into the ''Calidus'' WMS Goods Receipt Confirmation screen manually and confirm the receipt completely.


'''RF Putaway Process'''

The user will enter the Putaway module from the RF main menu.

The user will be prompted to go to the receiving area and scan or enter the pallet ID. This will be scanned from the Delivery label SSCC-ID barcode. If there is no putaway for this product, then the RDT will display this.

The RF unit will direct the user to take to pallet to a default putaway location. The user can confirm the stock into this location or choose to reposition the product in a different location, using the F4 function key. 

For standard putaway, the user will choose this Reposition option.

The RF unit will prompt the user to enter a new location for the stock. The user will scan the location barcode on the location into which the stock is being positioned. '''Note:''' For products that have automatically had a location other than a default putaway location suggested (e.g. loose wood, stocked products), the user can confirm the putaway of the product into this location by scanning the location barcode.

* For Stocked products, there is only one location (the mezzanine) and so these pallets will be confirmed as put away when the truck driver lifts the products up to the mezzanine and confirms that they are located there.
* For loose wood, the putaway will be confirmed using the ''Calidus'' WMS Goods Receipt Putaway Confirmation process.

Once the new location is scanned or entered, the RF unit will display that the pallet has been put away. The user can choose to continue putaway on other products or return to the main menu.

The products will be marked as putaway immediately in ''Calidus'' WMS and all standard audit trails will be maintained. 

Once all products are put away in this fashion, the GRN will be automatically confirmed as putaway within ''Calidus'' WMS.


'''Note:''' Almost all locations in the warehouse are marked as non-palletised. As the RF putaway process is predominantly for palletised stock, the ''Calidus'' WMS RF Receipt and Putaway processes must be checked that they will correctly de-palletise the stock when located in these locations.

'''SCR-290107-4: Ensure that the ''Calidus'' WMS Receipt and putaway processes correctly de-palletise stock.'''

=== Loose Wood Goods In Process ===
'''Note:''' Julien Bowen and Bentley are received in full sets as the above standard process, and as such will not follow the process below.


'''Current Process'''

Loose wood is sorted and separated into piles of style/type/colour.

Note that the majority of loose wood is MTO stock.

The loose wood received comes with a 'label pack' - all the labels for all the wood will be stored here rather than on the wood itself.

Each MTO product is counted and labels are removed from the pack where stock is missing.

The wood is then stored in one of two locations, depending on space and general product location.

Each label is then manually keyed into the ''Calidus'' WMS Goods Receipt screen, including the product code and batch code, before manually confirming the stock is in the locations.


'''RF Process'''

Once the wood is separated, counted and unused labels discarded, each label will then be receipted and scanned using the RF Goods Receipt process above.

For MTO products, the user will identify the GRN or Advice, and then scan the SSCC-ID, the stock code and the batch barcodes on the labels for each label. As all the product information is entered for each label, the stock will be receipt confirmed within ''Calidus'' WMS.

For Stocked products, the user will count the total of a stocked product being received, and will then receive this as a single pallet of that total quantity. For example, if the preadvice showed that there should be 50 of a Stocked product, nut only 47 were found, the user would enter the RF Goods Receipt process, enter the GRN or Advice, scan a SSCC-ID, Scan the product barcode, enter a quantity of 47 and confirm this as received. Only one scan would be required per Stocked product.


'''Loose Wood Putaway'''

Loose wood is currently stored in Z60A01 and Z60A02.

The intention is to ensure that the putaway of loose wood can be done through the ''Calidus'' WMS Goods Receipt Putaway Confirmation process, rather than scanning each individual product into the locations.


There are two ways to configure the system to do this.


'''Process 1'''

Change the configuration of the two loose wood locations into one location on the system, for example Z60A01. Each of the loose wood products will be configured to automatically suggest this location on receipt. The user will then use the ''Calidus'' WMS Goods Receipt Putaway Confirmation process to confirm that all of the product is located in this location.


'''Process 2'''

The products will be separated on the system to either being received into location Z60A01 or Z60A02. The decision as to which products will be located in which area will be made by the operation. The receipt process will then automatically suggest this location for those products. The user will then use the ''Calidus'' WMS Goods Receipt Putaway Confirmation process to confirm that all of the product is located in this location.


It is necessary to confirm that the ''Calidus'' WMS Goods Receipt Putaway Confirmation process can successfully suggest these non-palletised locations, and that the required de-palletising occurs correctly through this mix of RF and manual receipt and putaway.

'''SCR-290107-5: Ensure that combination of RF receipt and manual putaway correctly de-palletises the product received.'''

=== Rolled up Mattresses Goods In Process ===
The process is much like the loose wood process, but in this case the users are not able to see the labels, as they are positioned in the middle of the rolls. 


Instead, the suppliers should labels the mats at the end of the roll, so that the warehouse can actually see them. Then the process followed will be as loose wood above.


'''Note:''' If this supplier labelling issue cannot be resolved, rolled up Mats will not be RF received.

=== Cross-Dock ===
A manual process will decide whether a receipt will be going out later that day. If so, the stock will be confirmed as putaway into the default floor location.

The user will follow the standard goods receipt process for all the products, which will suggest all the pallets to a default floor location.

The putaway will then be confirmed using the ''Calidus'' WMS Goods Receipt Putaway Confirmation process.

=== Returns ===
At this time Returns are not processed through the ''Calidus'' WMS or RF system.

== Stock Control ==
There are a small number of non-palletised stock movements within the operation. These can be RF-enabled. The process for RF stock moves is as follows:

:When the user enters the 'Stock Move' module they will be prompted to enter a printer if the 'Print Part Replen Labels' rule is not set to 'Disabled'. On confirmation of the printer, the RDT will request the label format from the WCS.

:The RDT will then request a Stock Move task to be completed for the user. The user will be directed to the first available high priority stock move in a location efficient manner. 

:The RDT will prompt the user to go to the source location. The user will confirm the location by scanning/entering the location or check digits depending upon setup. 

:The RDT will then tell the user which pallet to get. The user will confirm that the correct pallet has been found by entering the required details. This will be determined by the 'Pick By' rule which could be set to one of the following:
:* Pallet Id
:* Stock Code
:* Stock Code and Batch
:* Pallet Id and Stock Code
:* Pallet Id, Stock Code and Supplier

:The RDT will then inform the user of the number of boxes required to be collected for the stock move. 

:The user will confirm by entering the quantity taken from the pallet. The user will have the ability to change the quantity being replenished by entering a different value or entering 0 (zero) if no stock can be picked. In this case, the user will be prompted to enter a reason code, as standard. 


:Once the user has confirmed the quantity of stock being picked, the RDT will request the user how many pallet labels are required for this stock move, if the 'Print Part Replen Labels' rule is not set to 'Disabled'. The user should enter the number of labels required to label each box.

:The RDT will print the number or labels in the required format on the entered printer. If there is an issue with the printer or the labels do not appear, the user will have the option of reprinting the labels or changing the printer at this point, before confirming that the labels are printed OK.

:Once this is completed, the RDT will display a dialogue confirming that this stock has been collected.

:The RDT will also send a message to the WCS, confirming that the Stock Move has been completed. This will be done using the standard Pick Qty Update message from the Part Picking function.

:If the user chooses to continue, the RDT will request the next available high priority stock move, in a location efficient manner and then repeat the above process.

:Should the user choose to take the stock to the destination location (or there are no more stock move tasks available at this time), the user will be prompted which 'pallet' of stock to deliver first. The RDT will display this as “Take Stock to Pick”, and prompt for Pallet ID. 

:The user will scan the pallet id on one of the cartons collected. 

:The RDT at this point will retrieve the details of the previous stock moves collected, checking against the 'Pallet Id From' from the pick tasks completed so far. If the pallet id does not exist, the RDT will display an error (“Pallet not found”) and request the user to enter a pallet again.

:Once the pallet has been identified, the RDT will retrieve the destination location from the previous stock move task and direct the user to this location with the prompt “Go to Pick Face”, followed by the destination location. The screen will also display the total quantity (or cases/units). 

:The RDT will request the user to confirm arrival at the destination location by scanning/entering the destination location or check digits depending upon setup.

:At this point, the user will take all of the stock off the pallet for that pallet and top up the destination location. The labels on the boxes (printed at pick) will be used to identify the pallets in the destination location.

:The user will have the option of reprinting the pallet labels at this point (via an F4 function key press), in case the labels on the boxes are unusable or discarded. If the user chooses this option, they will be asked how many pallet labels are required for this stock move. The user should enter the number of labels required to label each box being moved. The RDT will print this number of labels in the required format. If there is an issue with the printer or the labels do not appear, the user will have the option of reprinting the labels or changing the printer at this point, before confirming that the labels are printed correctly.

:Once all of the stock is in the destination location and labelled, the user will confirm that the stock move has been completed by scanning/entering the destination location or check digits. At this point, the RDT will send a message to the WCS to confirm that this stock move is wholly completed.

:If there are more destination locations to top up from the stock collected, the RDT will then direct the user to scan the next pallet and repeat the above process.

:If there are no more destination locations to top up in this run, i.e. all the stock collected has been delivered to the destination locations, the RDT will display a completion message and ask the user if they want to continue moving stock.


:If the user chooses to continue, then the user will repeat the above process. If the user does not continue with the 'Stock Move' module then the RDT will return to the main menu.

It was decided that this process may be enabled in a later phase if required but was not part of the project at this time.


It is also possible to allow RF users the ability to move stock from one location to another using a RF process called Ad-Hoc Stock Moves. The process for this is as follows:

:The user will enter Stock Move Function on the RF unit.

:The module will request the user to enter or scan a location. 

:Once there, the RDT will request the user to confirm a SKU. The WCS will check the availability of the stock for a movement at this time with the WMS. If the stock is unavailable for movement (i.e. it is already on a move, or any stock is allocated), the RDT will display an error.

:'''Note:''' Only one user will be able to move stock from one location at one time - if stock is already held for ad hoc move by another user, the RDT will display an error.

:If the stock is available, the WMS process will reserve the stock for Ad Hoc Moves (with a predefined system reason code) and tell the RDT how much stock is available.

:The RDT will prompt for the user to enter the amount of stock to be moved, validating against the available quantity.

:Once entered, the RDT will prompt the user to take the stock collected to its destination.

:Once confirmed, a message will be sent to the WMS to confirm all the reserved stock into this location.

It was decided that this process may be enabled in a later phase if required but was not part of the project at this time.


The same functionality for moving pallets from one location to another (either system-driven through Pallet Moves or user-driven through Ad-Hoc Pallet Moves) is not applicable to operation and will not be enabled.


The operation mentioned that the system did not allow the users to move allocated stock and requested that this functionality be added, as long as the allocated stock had not yet been placed onto a pick list.

'''SCR-290107-6: Allow WMS and RF Stock and Pallet moves to move allocated stock.'''


The standard RF Location Enquiry module is available to check the contents of each location.

The user scans a location and the RF unit will display limited information as to the contents of the location.

If there are multiple products or batches in the location, the RF unit will allow the user to page through each product/batch as they are listed in the location.

The standard RF Pallet Enquiry would have no use for the operation. However, they requested an ability to scan a batch code instead to get this information.

'''SCR-290107-7: Create an RF Batch Enquiry Module.'''


The RF system allows the users to check the stock in locations at any time. This Perpetual Inventory process works as follows:

:The user is prompted to go to a location. The user will scan the location to be checked. The WCS will then check what is in that location with the WMS.

:The user will then be prompted to enter the stock found in the location. Once the pallet has been identified, the user will be prompted to blind enter the quantity on the pallet. Should the user enter the quantity as expected, the check will be confirmed and the RDT will request if there are any more pallets in the location. The checks continue in similar fashion until all pallets are checked.

:Should the quantity entered not be the same as on the WMS, the user will be required to re-confirm the amount counted. Only when the user has confirmed two identical counts in a row will the value be accepted.

:On confirming a pallet, a message will be sent to the WMS with the count details. The WMS will not perform any required adjustments, although this is configurable.

:Any discrepancies discovered by the process are fully documented on the WMS, accessible through an Ad Hoc Stock Take report. This report can show, by date, owner and /or stock, the pallets checked and discrepancies discovered.


'''Note:''' The PI process works with the assumption that any changes to the locations' stock is achieved immediately by the RF system in picking, putaway and moves. As the picking process will be modified to not immediately update the changes to a location until all items on the order have been reflected, using the PI system whilst picking is in process may show unpredictable results.


The RF system allows the users to make adjustments directly on stock in a location. 

The Adjustments process is as follows:

:The User selects the Stock Adjustment Function on the RF main menu.

:The User scans a location barcode. 

:The User scans a stock barcode. The WCS will retrieve the details from the WMS of the stock in that location at that point. 

:The RF unit will then display the details of the stock code (including descriptions) and the content of the location.

:The User then enters actual stock quantity in location

:The User enters an adjustment reason code. This is validated that the reason code used is valid.

:The User confirms the adjustment using “F1” - the adjustment is sent to the WMS.

:If the user has not confirmed the adjustment by using the “F1” key the user will be able to cancel the adjustment by pressing “CLR”, or amend the quantity entered by pressing “F2”.

:Each adjustment will be sent to the WMS, which will automatically make the adjustments requested. This process will also update the Last Adjusted Date/Time field on the pallet record affected.

It was decided that this process may be enabled in a later phase if required but was not part of the project at this time.

== Order Process ==
=== Current Order Process ===
Orders can consist of a combination of MTO and stocked items.

An order line always consists of a quantity of 1 all the time. So, if the customer orders two divans, there will be two order lines for the same SKU.


When orders arrive, they consist of the following:

* Product
* Quantity (always 1)
* Buyer's Ref (AKA Item Ref, Manufacturer's PO, Rotation No)

Regardless of whether the ordered product is MTO or stocked, there will always be a Buyer's reference associated to the order line.


For MTO products, the order line type is 'R', to allocate product to the order using the Batch code. For Stocked products, the order line type is '1', to allocate purely against the product code.

The orders are auto-allocated at this stage. Allocation will roll-back if the entire order cannot be allocated.

The reason for this auto-allocation is that the delivery cannot be booked until the operation knows that the whole order is going to be picked (i.e. it has been fully allocated).

The delivery is booked with the customer through the client's own booking system (D2H).

This then feeds information back into ''Calidus'' WMS, consisting of the following:

* Order Priority - this determined whether this is Hub (5) or Pacemaker (3)
* Delivery Date
* Pick Date
* Consignment Number

'''Note:''' The orders are split into two types:

* Hub - delivered from the warehouse to a hub, where the items are sorted and then sent on to the customers.
* Pacemaker - deliver direct to customer's home (D2H)

The operation then uses the Pick Wave screen to wave the picks, entering the following parameters:

* Pick Date
* Owner
* Order Priority being waved (hub or pacemaker - in general there will only be two waves in a day, unless there are emergency orders).
* Status 4 (allocated only)

A Load is then generated and pick listed.

The Pick lists are printed. When RF-enabled, this will also generate the RF tasks.

Despatch labels are generated from the D2H booking system, comprising:

* Consignment Number
* Part Number and total parts on order (i.e. 1 of 4)
* Hub
* Post Code
* DC
* Order Number
* Item Barcode (comprising Consignment Number and Part Number).

One label is printed per item on the order i.e. a bed comprising 3 parts and a bed head would be two order lines, but would comprise 4 items and therefore 4 labels).

These labels are stapled to the pick sheet.

The pick sheets and the item labels are sorted by aisle but left in order sequence. Any orders with multiple lines are assigned to the aisle from which the first pick is taken. '''Note:''' This must be confirmed as the common process for all shifts by the operation. 

Z (wood) is always picked separately, whether it is on an order with other products or not. This is to be confirmed by the operation.

Each aisle's picks are placed in a tray, keeping them separated.

A picker selects the sheets for the load for one aisle tray and picks by paper, marking the sheets as to whether the product has been picked.

The picker matches the location, product and batch (if MTO product).

If all the product cannot be found (including all parts of multi-item products), the user returns the item to the location. If there are other items on the order that have already been picked, all the previous items will be returned to the locations.

If the item is picked correctly, the user will place the labels onto each item on the pick and leave the picked product in the centre of the aisle, ready for a second team to complete load preparation.

If there are multiple items on the order, the user may then change to a different aisle, to ensure that all items for an order are picked.

Once all items on their allocated pick sheets are complete, the paperwork is returned to the office and the system is updated: all completed picks are confirmed, whilst all incomplete picks are left. '''Note:''' This process of leaving incomplete picks must be confirmed by the operation.

=== RF Picking Process ===
The RF Picking process will be modified to fit with the requirements listed above. The first and major modification is to ensure that the RF picking tasks are delivered to the operators in exactly the same sequence as now.

'''SCR-290107-8: The RF Pick Task Allocation process will be modified to match the operation.'''


The task allocation will be by Load/Aisle i.e. a user will tell the RF unit what aisle they are picking. The RF unit will allocate the tasks for the highest priority load (likely there will only be one at that time) with tasks from that aisle.

The exception is where a multi-product order is being picked and the items are in two separate aisles (except Z which will always be picked separately). In this case, the task in a later aisle will also be assigned to this earlier aisle.

Picks will be sorted by Order Number, then sequence on the order.


Examples:


{| width="100%" border="1px"
! Aisle
! colspan="6" | Orders with picks in the aisle

|-
| '''A'''
| Order 1
| Order 3
| Order 2
| Order 5
| Order 4
| 

|-
| '''B'''
| Order 6
| Order 7
| Order 7
| 
| 
| 

|-
| '''C'''
| Order 6
| Order 8
| 
| 
| 
| 

|-
| '''D'''
| Order 2
| 
| 
| 
| 
| 

|-
| '''M'''
| Order 5
| Order 6
| 
| 
| 
| 

|-
| '''Z'''
| Order 1
| Order 2
| Order 9
| 
| 
| 

|}
1 Picking in Aisle A will pick, in this sequence:

* Order 1 from aisle A
* Order 3 from aisle A
* Order 2 from aisle A
* Order 2 from aisle D
* Order 5 from aisle A
* Order 5 from aisle M
* Order 4 from aisle A

'''Note''' that the stock in aisle Z for order 1 and 2 is left separate and not instructed to be picked as part of this sequence.

'''Note''' that the picking sequence is by order, not by location efficient sequencing.

2 Picking in aisle B will pick, in this sequence:

* Order 6 from aisle B
* Order 6 from aisle C
* Order 6 from aisle M
* Order 7 from aisle B (first product)
* Order 7 from aisle B (second product)

3 Picking in aisle C will pick, in this sequence:

* Order 8 from aisle C

'''Note''' that the task for order 2 will not be given to the users in aisle C, even if they start first, as the task has been marked for completion by the users in aisle B.

4 There is no picking available from aisle D at all, even if they start first, as the task in aisle D is to be completed by the users picking aisle A.
5 There is no picking available from aisle M at all, even if they start first, as the tasks in aisle M are to be completed by the users picking aisle A and B.
6 Picking in aisle Z will be:

* Order 1
* Order 2
* Order 9

'''Technical Note:''' The WCS will sequence each of the aisles. When pick tasks are received, it will add picks to a header based on the Load and Aisle sequence as now. A further check will be added, checking to see if the aisle sequence is 0 (aisle Z). If not, the process will check for other picks for that order with an aisle sequence less than the current picks aisle (excluding any with sequence 0). If one is found, the current pick will be placed in the pick group of the found pick with the lesser aisle sequence. 


The picker will log into the Part Picking module on the RF unit and enter an aisle in which they will start picking. This will be decided by the operator by checking the paper pick lists and labels to see what is available.

The RF unit will display the route/load being picked.

The user will collect the paper pick list and labels from the aisle and load being picked.

The user will be directed to the location of the first pick, which will be confirmed by scanning the location label.

The user will be prompted to confirm the product, which they will do by scanning the inbound label barcode or the EAN code on the product.

If the product is batch-controlled (i.e. MTO) the RF unit will then prompt for confirmation of the batch (buyer's ref), which they will do by scanning the inbound label barcode.

The picker will then be asked to confirm the number of items picked by scanning a barcode on each item for every item required in that pick.

'''SCR-290107-9: Change the Pick Quantity confirmation to request scanning of Item barcodes.'''

The RDT will require the scanning of a unique item barcode from the item labels. This will be validated a unique and valid for the item being picked (i.e. the right consignment, the item number has not been used before, is part of the order being picked). Each label scanned will reduce the amount of items remaining to be picked.

For example, in this location, the user is required to pick 2 divans. The product has 3 items (a 2-part divan and a mattress). Therefore the RF unit will display that there are 6 items that need to be scanned.

The user will scan the first item label (by convention, the users will use the item 1 label first, then item 2, item 3, etc). The screen will display that 5 are now required. The user will label the item picked with the despatch label.

The user will continue to scan until all items for that product and order are picked and labelled. 


Each item will be removed from the locations and left in the aisle, awaiting a second team's arrival to perform load preparation.

Once complete, the user will be prompted to move to the next location. This may be in a different aisle (to complete an order pick).

Once all tasks for that aisle (more accurately, the pick group containing orders who's first product to pick comes from that aisle) have been picked, the RDT will not direct the user to a marshalling location.

The prompt for Take to Marshalling will be removed and instead the RF unit will display the 'Picking Complete' dialogue immediately.

'''SCR-290107-10: Remove the Marshalling prompt from the RF Picking dialogue.'''

=== Pick Exceptions ===
The user will have the ability at any stage to cancel the pick task being performed, when they will be prompted for a reason code. This will inform the WMS that the pick has been cancelled. The new item scanning module above will have a button to completely cancel the pick - there will not be an option in this picking process to partially pick (i.e. pick 1 of 2) - the option will only be to cancel the pick in its entirety.


If this cancellation is part of a multi-product order, the user will return to the location of any previous items picked and put the product he picked back into the location. This will be identified as now, from the paper pick list.

Any pick shortages will be identified in the RF system immediately, so admin staff can immediately investigate.

The RF system must also delete any other pick tasks for that order in the system.

'''SCR-290107-11: Delete any unconfirmed pick tasks if there are any exceptions.'''


Because of this process to short picks, the WMS RF Pick update process must change, as follows:

For a single-product order, the pick and the order can confirm as normal.

For a multi-product order:

When a pick update comes in, the line must be marked as picked with a new flag.

When all picks for an order are completed fully (i.e. confirmed, not shorted or cancelled) the picking process will then run the confirm process for each line picked, ensuring that they are pick confirmed. The order will then be confirmed as normal.

'''SCR-290107-12: Delay confirmation of picked items until the whole order is picked.'''


Additionally, loading tasks will be generated to the WCS for each item to be load scanned. This process will also be added to the WMS pick confirmation process.

If any pick for an order is cancelled (short picked, zero picked, not picked), then the new Picked flags will be cleared on any line picked, so that the order can be reprocessed if required. No loading tasks will be sent to the RF system for tasks that have been cancelled.

'''SCR-290107-13: Create Loading Tasks.'''


Confirmation is required from the operation as to the further processing of these orders if they are then required by the client. For example, 

* What happens if the user requires the items that can be picked?
* What happens to the items they do not want?
* What happens if the order is cancelled?
* What if you can replace with returned stock?

== Load Preparation ==
This comprises the following:

* Double-bagging the items to protect for transit.
* Aisle Cleaning, involving taking the picked items to the vehicle to be loaded.

These are manual (i.e. non-RF) tasks.

== Loading ==
The requirements for the loading process are as follows:

* Scan every item that is loaded
* Scan D2H item barcode, consisting of consignment number (booking reference) and item number.
* Interface results of scanning back to the D2H system
* Error if the user scans an invalid item (i.e. not picked, not for this order type)
* Automatically despatch confirm orders that have been fully loaded.
* Scan everything for all order types (Hub and Pacemaker)
* Have a final check process, to check/show whether all items have been loaded.
* Ask question at the start whether they are loading hub or pacemaker
* All enquiries and reports on this process will be run through the D2H system.

=== Loading RF Process ===
'''SCR-290107-14: A new RF Loading process is required by the operation.'''


The creation of loading tasks from WMS will generate a table of the loading task in both WMS and WCS. These will be marked as incomplete (not scanned).


The RF user will enter the Loading module on the RF Unit.

The user will be asked if they are loading Hub or Pacemaker.

Once they have identified the type of orders being scanned, the RF unit will request the users to scan the items to be marked as loaded. The RF unit will validate that:

* The items are of the correct order type
* The items have a loading task.

If this fails validation, the RF unit will display an appropriate error.

The user will be allowed to continue scanning items to be marked as loaded.

The user can stop loading items at any time, so that loading can continue later in the day, on a second vehicle, etc.

As each item is scanned, the information is sent back to the WMS and the item scanned marked as loaded. When all items for an order are scanned loaded, the WMS will automatically despatch confirm the order.


The user will also be allowed to press a function key to identify that loading is complete for this order type.

The RF unit will then check whether there are items still to be loaded. If so, the RF unit will display:

* Part-loaded order items in detail
* A total of the unloaded items for this order type.

The user can then confirm that the loading is complete for the day, or continue loading.

If loading is complete for the day, all loading tasks for that order type will be removed from the RF system.

The RF system will log the scans as loading activities, which can be enquired upon.


<!-- MEDIA LANDSCAPE YES --> 

= Appendix A: Table of SCRs and Ballpark Estimates  =
<!-- If there’s only one system being discussed here, the system column can be removed.
Ballpark estimates may not be required to be included in this document. If they are, include the column, and note 1. Estimates should be rounded up, and should be produced using the standard mechanism of estimates (i.e. any standard spreadsheet designed to automate the production of estimates). The total line need only be added if the estimates are being produced at this point
The description should be the description from the text in the main sections. 
The Notes column can be used for many things: grouping optional changes, showing whether the client or OBS originated the gap, etc. -->

{{ #vardefine: SCR | 0 }}
{{REQ_SCR_Header}}{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WMS
|Area=Preadvice
|Description=Change to WMS preadvice sheet to show the number of stocked items per line i.e. if preadvice of 10 stocked items, should be 10 lines on the sheet, so the operation can enter the details.
|Estimate=1750
|Notes=
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WMS
|Area=EDI
|Description=Import EDI file from customer's Portal system.
|Estimate=1750
|Notes=2
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WMS
|Area=RF Receipt
|Description=Amend ''Calidus'' WMS RF Goods Receipt process to blank the rotation field.
|Estimate=2000
|Notes=
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WMS
|Area=RF Receipt/ Putaway
|Description=Ensure that the ''Calidus'' WMS Receipt and putaway processes correctly de-palletise stock.
|Estimate=2500
|Notes=3
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WMS
|Area=RF Receipt
|Description=Ensure that combination of RF receipt and manual putaway correctly de-palletises the product received.
|Estimate=2000
|Notes=3
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WMS
|Area=Stock Moves
|Description=Allow WMS and RF Stock and Pallet moves to move allocated stock.
|Estimate=7000
|Notes=
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WCS
|Area=Enquiries
|Description=Create an RF Batch Enquiry Module.
|Estimate=4000
|Notes=
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WCS
|Area=Picking
|Description=The RF Pick Task Allocation process will be modified to match the operation.
|Estimate=5500
|Notes=
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WCS
|Area=Part Picking
|Description=Change the Pick Quantity confirmation to request scanning of Item barcodes.
|Estimate=5000
|Notes=
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WCS
|Area=Part Picking
|Description=Remove the Marshalling prompt from the RF Picking dialogue.
|Estimate=1750
|Notes=
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WCS
|Area=Part Picking
|Description=Delete any unconfirmed pick tasks if there are any exceptions.
|Estimate=1750
|Notes=
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WMS
|Area=RF Pick Update
|Description=Delay confirmation of picked items until the whole order is picked.
|Estimate=5750
|Notes=
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WMS
|Area=RF Loading
|Description=Create Loading Tasks.
|Estimate=3500
|Notes=
}}
{{REQ_SCR_Line|SCR={{ #vardefineecho: SCR | {{ #expr: {{ #var: SCR }} + 1 }} }}
|System=WMS/WCS
|Area=RF Loading
|Description=A new RF Loading process is required by the operation.
|Estimate=7500
|Notes=
}}
{{REQ_SCR_Line|SCR=
|System=
|Area=
|Description='''Total'''
|Estimate=51200
|Notes=
}}
{{REQ_SCR_Footer}}

Notes:
# Any high level ballpark estimates for development are based on the basic information provided and are subject to detailed design and creation of an SCR.
# A nominal cost has been included here to cover 2 days' analysis and possible development. It may be that the EDI format used will match the existing WMS EDI Preadvice format. If this is the case, then this cost will be reduced or removed. If the EDI format is significantly different, this cost will increase.
# A nominal cost has been included against these items to cover potential development costs. However, it may be that, once analysis has begun, changes are not required. In this case the cost will be removed. It may be that the items overlap in their functionality. In that case, the costs may be reduced when combined. After analysis, the changes may be more extensive than could be covered with this cost. In that case, the cost will increase.
# The estimates above include functional specification, development and testing. Additional project-related charges, such as project management and implementation are not included.

In order to achieve RF go-live for the inbound process (Receipt and Putaway), the following minimum changes would be required: 3, 4 and 5, with a total cost of £6,500.00.


In order to achieve RF go-live for the full operation, the following minimum changes would be required: 3, 4, 5, 8, 11, 12, 13 and 14, with a total cost of £30,500.



<!-- MEDIA LANDSCAPE NO --> 
{{Doc_Appendix
|Appendix=B
|Estimate=N
|Glossary=WCS
|Ref1=&nbsp;
|RefV1=&nbsp;
|RefDate1=&nbsp;
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client=
|Year=
|FSEST=Y
|Rev1=Julie Scott
|Rev1Title=OBS Representative
|Rev2=Jonathan Davies
|Rev2Title=Client Representative
}}</div> 
[[Category:{{#var:Client}} REQ]]