FS 302901 Pentland RF Scanning
Pentland
Pentland RF Scanning
Dynamics NAV
12th February 2013 - 0.5
Reference: FS 302901
Contents
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, as well as spares picked as part of a service, for vehicles’ service product.
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
Set-up
Pre-requisites
Menu Structure
Data
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
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.
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.
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.
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.
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 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".
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 (of extremely limited space).
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.
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.
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.
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.
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.
Appendix A: Quote & Document References
| Warning: | Unknown costs for client/year (PENT/2013) |
| Cost Details | ||||
| Activity | Estimate No. of Days |
No. of Days | Rate per Day (£) | Cost (£ Exc. VAT) |
| Requirements | 0.00 | 0.00 | 0 | £0.00 |
| Change Request Evaluation | 0.00 | 0.00 | 0 | £0.00 |
| Functional Specification | 0.00 | 0.00 | 0 | £0.00 |
| Technical Specification | 0.00 | 0.00 | 0 | £0.00 |
| Development | 0.00 | 0.00 | 0 | £0.00 |
| Testing and Release | 0.00 | 0.00 | 0 | £0.00 |
| Implementation | 0.00 | 0.00 | 0 | £0.00 |
| Project Management | First argument to "number_format" must be a number. | First argument to "number_format" must be a number. | 0 | £First argument to "number_format" must be a number. |
| TOTAL | First argument to "number_format" must be a number. | First argument to "number_format" must be a number. | £First argument to "number_format" must be a number. | |
| Estimate excludes training, release to live and go live support. |
A.1 References
| Ref No | Document Title & ID | Version | Date |
| 1 | Reference1 | 0.1 | 01/01/2011 |
A.2 Glossary
| Term | Definition |
|---|---|
| EPOD | Electronic Proof of Delivery. The OBS EPOD system is CALIDUS ePOD. |
| CALIDUS eSERV | The OBS mobile system to complete Service functionality in the field. This is part of the CALIDUS ePOD system. |
| PDA | The mobile device on which the C-ePOD system will run in the field. This can be a Phone, EDA or industrial PDA, running Android. |
| DAL | Data Access Layer. A mechanism for accessing data by the system that is removed from the application, allowing for simplified access and providing protection to the data, as only approved DAL methods can be used to modify it. |
| GPS | Global Positioning System. A mechanism of retrieving accurate positioning information in the form of Latitude and Longitude (Lat-Long) co-ordinates from a device. |
| GPRS, 3G, HSDPA, Data Service | All terms referring to mobile device network connectivity, and the speed at which the device connects to the internet. |
A.3 Authorised By
Richard Hinchliffe | NAV | _____________________________ |
