View source for FS 302901 Pentland RF Scanning

<div class="noprint">
{{#vardefine:Client|PENT}}
{{#vardefine:ClientName|Pentland}}
{{#vardefine:System|Dynamics NAV}}
{{#vardefine:Doc_Title|Pentland RF Scanning}}
{{#vardefine:Version|0.6}}
{{#vardefine:Date|14th February 2013}}
{{#vardefine:Reference|302901}}
{{#vardefine:Year|2013}}
</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}}
}} 

<!-- TOC --> 
<div class="noprint">
= Functional Overview  =

== Client Requirement  ==
The customer requires RF Scanning functionality at Picking within the warehouses (Equipment and Spares).

Additionally, there must be Loading scanning for the picked items.

== Solution Overview  ==
The operation is picking by order, for Spares picking. For Equipment, this is also normally the case, however, the users will be allocated orders to pick from Dynamics NAV by route (i.e. vehicle and load), comprising one or more orders.

The operation currently decides on picking sequence, routing and loading tasks from information presented to them by their systems - those decisions are made concurrently by different operatives (a planner plans the routes, a warehouse operative plans the picking).

The picking process for equipment (at the main warehouse) differs because of the time and space constraints. Effectively the warehouse staff pre-pick, based on expected despatches, before the routes have been finalised and therefore before the picking list has been finalised. This allows them to move equipment to the marshalling area in preparation for loading. Once the route has been confirmed a final picking list will be available and any remaining stock that isn’t in the marshalling area will be picked (and stock that had previously been picked but is no longer required will be moved back into stock). 

{{Note}} Pre-picking is essential in those instances where equipment may require modification prior to despatch, which may be done a few days before the planned shipment date. The need for modification will be flagged on the picking list, and entering the serial number and confirming the pick will indicate confirmation that the equipment has been modified.

Note that the Dynamics NAV Load Lists created will be modified to have a Vehicle Registration added, in a large font.

Dynamics NAV provides the option to generate pick lists order by order or to consolidate multiple orders into a single pick. Each pick must be assigned to the Warehouse employee (i.e. Dynamics NAV user) responsible for completing the activity.

The Dynamics NAV user will print labels for the picked items at this stage. 
One label will be printed for:
*	Each Equipment Item to be picked
*	All the spares stock to be picked (to clarify, one label only for all of the stock).
Each label printed will contain the following information:
*	A system-generated unique Item ID, to identify that particular picked item of equipment or box of spares, barcoded and human-readable.
*	The Customer (Shipment) Name and Address.
*	The Dealer Name and Address
*	A piece of user-definable text, indicating the reorder method, expected to be "To reorder, contact http://www.pentlandparts.co.uk". Regardless, this text will not exceed 50 characters.

Note that these labels need not be printed for any stock that is not being despatched by Pentland vehicles i.e. spares through DPD or TNT.

The user will use the mobile units in the warehouses to complete the picking tasks.

The user will log on to the system through the mobile device, using a username and password provided to them.

The user will be shown a menu - they will choose Picking.

The first Load allocated to the user will be selected.

The user will collect the pick labels at this time.

Note that there will not be a printer in the Spares warehouse for despatch labels, as the printer stock differs to that available there. The labels will be printed to the printer in the Equipment warehouse and collected from there. As there will be only approximately 3 orders per week that are despatched via the Pentland network, this should not prove difficult to achieve.

The user will be sent to a location and asked to scan a product barcode, applied during receipt, and to confirm the quantity picked.

The system will request the user to enter which serial number has been picked, for serial-numbered items only.

The system will request the user to enter the unique item ID from the label to associate to this picked item, if the item is being delivered by Pentland vehicles.

{{Note}} For Spares picking: The system will request the pick label item ID for each time an item is picked. If no more stock can be picked into the box, the user will print another label from Dynamics NAV. All subsequent picks will then be allocated to the newly-printed item ID.

This prompting for Item ID at each pick allows for some future flexibility in picking whereby two boxes could be picked at the same time.

When all items are picked, they are taken to a marshalling area (of extremely limited space).

EPOD will use these applied Despatch label barcodes to scan for delivery.

{{Note}} Spare parts are delivered through DPD or other external carriers, so will be labelled through a separate mechanism, and will not be delivered through ''CALIDUS'' ePOD.

{{Note}} Spare parts that are part of orders with large spares or cabinets (mixed orders) will be delivered through ePOD.

{{Note}} For Mixed orders, the Spares stock will be picked and packed at the Spares warehouse and then transferred to the main warehouse for loading once the routes/loads for the vehicles have been finalised and the requirement for the goods is therefore confirmed.

At the end of the Picking process it is expected that:
*	Each cabinet will have a Despatch label with a unique Item ID on it. The unique Item ID will be associated in Dynamics NAV to the picked product’s serial number.
*	Each large spare will have a Despatch label with a unique Item ID on it.
*	Each box of spares or small parts will have a single Despatch label with a unique Item ID on it.

A Load Planner will plan the orders together in Dynamics NAV into Loads. These loads will be assigned to a vehicle. Note that these vehicles in Dynamics NAV will be identical to those that the drivers and loaders use in ''CALIDUS'' ePOD - the two systems will use an interface to ensure that any vehicles added in Dynamics NAV is automatically created within ''CALIDUS'' ePOD.

Dynamics NAV will send the Loads and the associated Orders to ''CALIDUS'' ePOD at this stage, which will create Loads and Jobs from the associated information. These will be sent immediately upon completion of the pick, to ensure that the data is available for loading immediately.

The orders will be split into two loads:
*	One load for loading the orders at the main warehouse. These will all be planned from the warehouse address, and all containers (pallets, boxes and potentially loose items) will have their unique ID and description planned onto one order, in the sequence in which they should be loaded. {{Note}} These jobs will be planned in a separate job group within CALIDUS ePOD, to ensure that a different PDA configuration can be used (i.e. this does not act like a normal collection job).
*	One load for delivering the orders to their end points. There will be multiple jobs (orders) on this load, sequenced in the order in which they should be delivered by the driver.

== Scope  ==
{{warning}} Questions for NAV:
* "The operation is picking by order, for Spares picking". How does NAV send these to pick? For Equipment orders being picked, they allocate the lot together onto a manifest, then assign the manifest to a picker. How will this work when it's a single order to be picked?

* How will mixed orders be allocated? For example, we have 2 orders:
** Order 1 is an equipment order only, requesting two products (ORDER1_EQUIP1 and ORDER1_EQUIP2)
** Order 2 is a mixed order, requesting 4 products (ORDER2_EQUIP1, ORDER2_SPARE1, ORDER2_SPARE2, ORDER2_SPARE3)
So, we allocate order1 and 2 onto a manifest (for the picking of all the equipment for the two orders). How do the three Spare items get split out onto a different pick? Which picker will be allocated? Is this the same order number or different?

* What is the process for re-allocating a 'pick' from one picker to another in NAV? How will this be affected by the above two points?

* For Loading, the customer requires that the loading tasks per item are in reverse drop sequence. How is this defined in NAV? What field is used?

<!-- NEW PAGE --> 

= Set-up  =

== Pre-requisites  ==

== Menu Structure  ==

== Data  ==
<!--
'''NRF_LOAD_HEADER''' 
* NLH_ID - UID of the created record. Long, Auto-incremented.
* NLH_SITE_ID - UID of the SITE. Varchar(10)
* NLH_LOAD_ID - UID of the Load. Varchar(20)
* NLH_USER_ID - UID of the user to whom the tasks have been allocated. Varchar(20)
* NLH_VEHICLE_ID - UID of the vehicle that is allocated to the load. Varchar(20)
* NLH_STATUS_CODE - A status code indicating the status of the processing of the load. Varchar(2)

'''NRF_ORDER_HEADER''' 
* NOH_ID - UID of the created record. Long, Auto-incremented.
* NLH_ID - Foreign key of NRF_LOAD_HEADER
* NOH_SITE_ID - UID of the SITE. Varchar(10)
* NOH_LOAD_ID - UID of the Load. Varchar(20)
* NOH_ORDER_ID - UID of the Order. Varchar(20)
* NOH_DROP_SEQUENCE - Drop sequence for delivery. Integer. 
* NOH_ORDER_REF_1 - External references for future dev.  Varchar(20)
* NOH_ORDER_REF_2 - External references for future dev.  Varchar(20)
* NOH_ORDER_REF_3 - External references for future dev.  Varchar(20)
* NOH_STATUS_CODE - A status code indicating the status of the processing of the order. Varchar(2)

'''NRF_ORDER_DETAIL''' 
* NOD_ID - UID of the created record. Long, Auto-incremented.
* NOH_ID - Foreign key of NRF_ORDER_HEADER
* NOD_PRODUCT_CODE - UID of the product to be picked, Varchar(20)
* NOD_PRODUCT_DESCRIPTION - Description of the product to be picked. Varchar(100)
* NOD_PRODUCT_TYPE - the type of product. Varchar(20)
* NOD_TO_PICK_QTY - Integer
* NOD_PICKED_QTY - Integer
* NOD_SERIAL_NO - Varchar(20)
* NLD_ID - Foreign key of NRF_LOAD_DETAIL
* NOD_STATUS_CODE - A status code indicating the status of the picking of the stock. Varchar(2)

'''NRF_LOAD_DETAIL''' 
* NLD_ID - UID of the created record. Long, Auto-incremented.
* NLH_ID - Foreign key of NRF_LOAD_HEADER
* NLD_LABEL_ID - Entered label ID against the picked stock. Varchar(20)
* NLD_STATUS_CODE - A status code indicating the status of the processing of the item. Varchar(2)
-->

EPOD_LOAD:
* Add new field (EPL_LOAD_TYPE) to indicate this is a Picking "P" or Loading "L" load, not a Delivery "D" load. This will be added to the index to keep the Load ID unique.
* Add new field EPL_OPTIONS, to control what options are required for the Picking and Loading

EPOD_PRODUCT:
* Add new field (EPL_OPTIONS) to control the options required for Picking
<!-- NEW PAGE --> 
= Functional Description  =
== RF Picking ==
=== Generate RF Picking Tasks ===
A Load Planner will plan the orders together in Dynamics NAV into Loads. These loads will be assigned to a vehicle. Note that these vehicles in Dynamics NAV will be identical to those that the drivers and loaders use in ''CALIDUS'' ePOD - the two systems will use an interface to ensure that any vehicles added in Dynamics NAV is automatically created within ''CALIDUS'' ePOD.

Dynamics NAV provides the option to generate pick lists order by order or to consolidate multiple orders into a single pick. Each pick must be assigned to the Warehouse employee (i.e. Dynamics NAV user) responsible for completing the activity. {{warning}} See scope above for question about how this works for Mixed and Spares orders.

This process will trigger a send of the Pick tasks to ''CALIDUS'' ePOD. This triggered process will create EPOD_LOAD, EPOD_JOB, EPOD_CONTAINER and EPOD_PRODUCT records within the system.
<!-- NRF_LOAD_HEADER, NRF_ORDER_HEADER and NRF_ORDER_DETAIL records within the system. -->

{{warning}} this must be mapped from Dynamics NAV.
* The Load will be marked as "Pick" type
* The Job Type will be marked as "Pick" type.
* A Loose Products container will be created.
* Product records will be created for each product to be picked.
** Ordered Qty will be set to the To Pick qty.

{{note}} For equipment items, each should have their own product line. So, if the user has ordered 2 fridge units, there should be two products on the job, each with quantity 1. For Spares items (i.e. non-equipment), the full quantity can be put on a single line.

{{note}} Reassigning a pick from one user to another will require the messages to be resent to ePOD. {{warning}} NAV process to be defined. See scope for questions regarding this.

The ePOD LOAD DAL object will be modified to allow updating and searching of tasks that for particular types only, and existing DAL objects will be modified to display only Delivery load types.

The Dynamics NAV user will print labels for the picked items at this stage. Labels will only be produced for those orders that require them. {{warning}} The customer has confirmed that they require a SO# and PO# on the labels.

=== User Modifications ===

The user will use the mobile units in the warehouses to complete the picking tasks.

The user will log on to the system through the mobile device, using a username and password provided to them.

The existing EPOD_USER table will be modified to indicate the the user ID is a Warehouse user.

=== PDA Login ===
The PDA client will be modified to allow the user to log on with a Warehouse type user.

If the user is a Warehouse user, they will be shown a main menu consisting of:
* Picking
* Loading
These will just be two large buttons.

{{Note}} If a pick is in progress on the device, and the Loading button is pressed, the user should not be allowed to Load, and vice versa.

=== PDA Picking ===
The user will choose the Picking option.

The PDA will send back a Load Request option, but modified to indicate this is a picking request.

The ePOD Server will be modified to identify this.

ePOD Server will retrieve the first Loads assigned to the user that are Picking tasks only.

This will be built into a standard Load Response message to the ePOD and returned.

If no load is found, the PDA client will issue an Error (No Pick Found). Clearing this error will return to the menu.

If found, the PDA will display the standard Job List screen.

The user will collect the pick labels at this time.

The user will select an order to pick from the list.

A screen will be displayed similar to the existing Collection screen. This will show only:
* Info tab.
* Products tab.
The products tab will act similarly to the existing one, in that it will allow selecting of products to collect, by the Grid, manual entry or scanning.

Note that any text showing as Collect or similar will be changed to Pick.

The user will scan a product barcode, applied during receipt. If the barcode is unavilable or not scanning, the user can enter the product code directly rather than use the scanner.

If this does not match a product on the load, an error will be displayed.

If found, a pop-up screen will be displayed, showing:
* Product Code
* Product Description
* Product Type
* To Pick qty
* A text box to confirm the picked qty (stored in EPL_PRODUCT_QTY_ACTUAL). 
* A text box to enter the Serial number, if the options against the product indicate this is required (stored in EPL_CUST_REF). The first character of EPL_OPTIONS will indicate this "Y" or "N".
* A text box to enter the Label ID, if the options against the product indicate this is required (stored in EPL_ITEM_TYPE). The second character of EPL_OPTIONS will indicate this "Y" or "N".

The user can enter items in the text boxes by clicking on them, and then using the keypad or scanner.

A Cancel button will be provided - if pressed, all entry will be discarded and the user will be returned to the product list.

A Confirm button will be provided - if pressed, the program will validate:
* All text items have been entered.
* The serial number is less than 20 characters
* The quantity is equal to or less than the ordered quantity.
If not, an error will be issued. Clearing this error will return the user to the popup screen to correct the issue.

Furthermore, the pick quantity will be checked whether it is equal to the ordered qty. If not, the user will be warned that the pick quantity differs, but allowed to confirm or cancel. If cancelled, the user will be returned to the popup screen to correct the issue, if confirmed, the reason code on the product will automatically be set to "NP" and the pick confirmed.

When the item are confirmed picked, the user will be returned to the product list, with the picked item removed from the list.

{{note}} For equipment items, each should have their own product line. So, if the user has ordered 2 fridge units, there should be two products on the job, each with quantity 1. If the user scans a product that is duplicated on the list, only one should be removed.

When all items are picked for the order, a confirmation message will be displayed and the user will be returned to the Order List. The ePOD Server will be informed as the orders are completed.

For the Equipment warehouse, as items are picked they will be taken to the marshalling area (of extremely limited space).

For the Spares warehouse, when all items are picked, they are taken to a marshalling area.

Once all orders have been picked, the user will be returned to the main menu.

At the end of the Picking process it is expected that:
*	Each cabinet will have a Despatch label with a unique Item ID on it. The unique Item ID will be associated in Dynamics NAV to the picked product’s serial number.
*	Each large spare will have a Despatch label with a unique Item ID on it.
*	Each box of spares or small parts will have a single Despatch label with a unique Item ID on it.

== Update Completed Picks in Dynamics NAV ==
It has been noted that the interface for updating Dynamics NAV is not applicable in this case, as this requires the Web Services interface. 

{{note}} the existing triggers for the updating of completed Deliveries must be modified to check the Load Type.
* If "P" Pick, no action (sent through a webservice)
* If "L" Loading, no action (sent through a webservice)
* If "D" Delivery, call the existing package.

This requires a web service created within Dynamics NAV:
* to allow the entire pick to be sent through, with individual pick details, in one web request
* through a SOAP rather than HTTP request
* return no errors through the webservice - these will be handled and audited directly within Dynamics NAV.
* {{note}} any picks that have been marked as amended(i.e. the reason code is set) should result in the pick NOT being set to Picked status, and therefore no further action will be taken (regarding sending loading tasks , etc). This order will require manual completion in NAV, which will then generate the Loading tasks.
{{warning}} NAV developer required to do this.

This interface will be configured through the standard XF_CONFIG system within ePOD, which will require the following changes:
* A new XF_ID of "Pick" will be required, to configure an interface of this type. This will be set up with the web service settings required to send via SOAP.
* When Pick Updates are returned from the device, the system will check for this configuration on the site. If so, the data will be interfaced out to the webservice defined immediately. This will be through a threaded process, to ensure that this does not delay processing of subsequent device messages.

{{Note}} Once sent, all the relevant picking information will be deleted from ePOD.

== Generate Loading Tasks ==
Dynamics NAV will send the Loads and the associated Orders to ''CALIDUS'' ePOD at this stage, which will create Loads and Jobs from the associated information. These will be sent immediately upon completion of the pick, to ensure that the data is available for loading immediately.

This will be triggered within the database once the manifest has been set to Picked status.

{{Note}} Some orders will not have Loading tasks generated for them. They are:
* Orders that are designated as Customer Collections - the process will trigger instead the creation of the Delivery manifest to ePOD.
* Orders that are being delivered via another haulier (i.e. DPD delivery of spares-only orders) - the process will not trigger any further processing in this case.

A load will be created for loading the orders at the main warehouse. These will all be planned from the warehouse address, and all containers (pallets, boxes and potentially loose items) will have their unique ID and description planned onto one order, in the sequence in which they should be loaded. {{Note}} These jobs will be planned in a separate job group within ''CALIDUS'' ePOD, to ensure that a different PDA configuration can be used (i.e. this does not act like a normal collection job).

The data will be configured as follows:
* Load ID will be set to the Manifest
* Load Type will be set to "L"
* Vehicle will be set to the Vehicle delivering the load
* Planned date and time will be set to the current date and time (i.e. immediate loading)
* One job will be created, with the Date and Time set as the Job Code
* The Job Group will be set to "LOAD"
* All label IDs entered during picking will be created as Containers.
* All containers will be placed on the list in the sequence they are to be loaded. {{warning}} NAV to confirm what field this is.

== Loading ==

The user will trigger the loading process on the RF gun by choosing the loading option from the menu. {{note}} These Loading tasks will not be capable of being retrieved through the standard Delivery functionality.

The user will be prompted to enter a vehicle at this time, from a drop-down list. The user should select the vehicle that is ready to load.

The PDA will send a message to the server, requesting a Loading-type manifest, associated to the vehicle ID entered on the previous screen.

The server will be modified to allow this request and retrieve only loading manifests - this will require a modification to the Load DAL.

If none are found, the PDA should display an error message and return to the Vehicle Request screen.

If one is found, the standard Job List screen should be displayed.

The functionality from this point forward will be as a Collection process.

{{note}} If some containers are not found for loading, this should be investigated manually. Containers can be marked as not loaded by cancelling them on the device.

The Job Group "LOAD" will be configured so that no signature is requested.

On completion of loading, the ePOD server will be informed through a standard Job Update message.

== Updating Completed Loading in Dynamics NAV ==

When loading is complete (or this order is a customer collect order), this will trigger the update of the pick to Loaded.

{{warning}} Does this require the Web Service update as the Picking process before? Assuming it does...

This requires a web service created within Dynamics NAV:
* to allow the entire Load to be sent through, with individual Load details, in one web request
* through a SOAP rather than HTTP request
* return no errors through the webservice - these will be handled and audited directly within Dynamics NAV.
* {{note}} any items marked as not loaded (i.e. the reason code is set) should result in the manifest NOT being set to Loaded status, and therefore no further action will be taken (regarding sending delivery tasks , etc). This order will require manual completion in NAV, which will then generate the Delivery tasks.
{{warning}} NAV developer required to do this.

This interface will be configured through the standard XF_CONFIG system within ePOD, which will require the following changes:
* A new XF_ID of "Loading" will be required, to configure an interface of this type. This will be set up with the web service settings required to send via SOAP.
* When Loading Updates are returned from the device, the system will check for this configuration on the site. If so, the data will be interfaced out to the webservice defined immediately. This will be through a threaded process, to ensure that this does not delay processing of subsequent device messages.

{{Note}} Once sent, all the relevant Loading information will be deleted from ePOD.

== Generate Delivery Tasks ==
A load will be created for delivering the orders to their end points. There will be multiple jobs (orders) on this load, sequenced in the order in which they should be delivered by the driver.

This will be triggered within the database once the manifest has been set to Loaded status.

This has already been developed.
<!-- NEW PAGE --> 
{{Doc_Appendix
|Appendix=A
|Estimate=N
|Glossary=EPOD
|Ref1=REQ 302901 Pentland Wholesale ePOD NAV WMS v3.0.docx
|RefV1=3.0
|RefDate1=08/11/2012
|REQ=0
|EST=0
|FS=0
|TS=0
|DEV=0
|ST=0
|IMP=0
|Client={{#var:Client}}
|Year={{#var:Year}}
|FSEST=Y
|Rev1=Julie Taylor
|Rev1Title=OBS Project Manager
|Rev2=Richard Hinchliffe
|Rev2Title=NAV
|Rev3=Leigh Simons
|Rev3Title=NAV
}}</div> 
[[Category:{{#var:Client}} FS]]