FS 302901 Pentland RF Scanning: Difference between revisions

From Calidus HUB
VisualWikitext
(v0.2 - added Updating of Picks and sending of Loading tasks)
(v0.6 - After customer feedback)
 
(3 intermediate revisions by the same user not shown)
Line 2: Line 2:
{{#vardefine:Client|PENT}}
{{#vardefine:Client|PENT}}
{{#vardefine:ClientName|Pentland}}
{{#vardefine:ClientName|Pentland}}
{{#vardefine:System|Dynamics NAV, etc}}
{{#vardefine:System|Dynamics NAV}}
{{#vardefine:Doc_Title|Pentland RF Scanning}}
{{#vardefine:Doc_Title|Pentland RF Scanning}}
{{#vardefine:Version|0.2}}
{{#vardefine:Version|0.6}}
{{#vardefine:Date|11th February 2013}}
{{#vardefine:Date|14th February 2013}}
{{#vardefine:Reference|302901}}
{{#vardefine:Reference|302901}}
{{#vardefine:Year|2013}}
{{#vardefine:Year|2013}}
Line 81: Line 81:
{{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 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}} 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.
{{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.
Line 99: Line 99:


== Scope  ==
== 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 -->  
<!-- NEW PAGE -->  
Line 155: Line 166:
EPOD_PRODUCT:
EPOD_PRODUCT:
* Add new field (EPL_OPTIONS) to control the options required for Picking
* Add new field (EPL_OPTIONS) to control the options required for Picking
<!-- NEW PAGE -->  
<!-- NEW PAGE -->  
= Functional Description  =
= Functional Description  =
== RF Picking ==
== RF Picking ==
=== Generate RF Picking Tasks ===
=== 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.
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.
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.
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.
Line 175: Line 183:
* Product records will be created for each product to be picked.
* Product records will be created for each product to be picked.
** Ordered Qty will be set to the To Pick qty.
** 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 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.  
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 ===
=== User Modifications ===
Line 224: Line 236:
Note that any text showing as Collect or similar will be changed to Pick.
Note that any text showing as Collect or similar will be changed to Pick.


The user will scan a product barcode, applied during receipt.
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 this does not match a product on the load, an error will be displayed.
Line 233: Line 245:
* Product Type
* Product Type
* To Pick qty
* To Pick qty
* A text box to confirm the picked 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. The first character of EPL_OPTIONS will indicate this "Y" or "N".
* 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. The second 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.
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.
Line 241: Line 269:
For the Equipment warehouse, as items are picked they will be taken to the marshalling area (of extremely limited space).
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).
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.
Once all orders have been picked, the user will be returned to the main menu.
Line 254: Line 282:


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


Line 261: Line 289:
* to allow the entire pick to be sent through, with individual pick details, in one web request
* to allow the entire pick to be sent through, with individual pick details, in one web request
* through a SOAP rather than HTTP request
* through a SOAP rather than HTTP request
* return no errors through the webservice, but instead in.
* 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.
{{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:
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.
* 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 ==
== 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.
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:
{{Note}} Some orders will not have Loading tasks generated for them. They are:
* Orders that are designated as Customer Collections  
* 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)
* 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).
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).
Line 285: Line 316:
* Planned date and time will be set to the current date and time (i.e. immediate loading)
* 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
* 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 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 ==
== Loading ==


{{warning}} Loading Process here
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.


When loading is complete (or this order is a customer collect order), 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 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.


<!-- MEDIA LANDSCAPE YES -->
{{Note}} Once sent, all the relevant Loading information will be deleted from ePOD.


= Appendix A: TEST PLAN  =
== 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.


{{TestPlan_Header
This will be triggered within the database once the manifest has been set to Loaded status.
|Title={{#var:Doc_Title}}
|Log={{#var:Reference}}
|Description=description of what is to be achieved
|MenuAccess=Where on the menus the item can be found
|Prerequisites=The prerequisites of the test
|Objective=The details of what each group of tests is to achieve
}}
{{ #vardefine: Cycle | 0 }}{{ #vardefine: SubCycle | 0 }}
{{TestPlan_CycleHeader
|Cycle={{ #vardefineecho: Cycle | {{ #expr: {{ #var: Cycle }} + 1 }} }}{{ #vardefine: SubCycle | {{ #var: Cycle }} }}
|Title=Area being tested in this cycle
|Notes=Any notes or prerequisites for the tests following.
}} <!--INSERT TESTS HERE --> {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=The actions to follow
|Result=The expected result
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=The actions to follow
|Result=The expected result
|Remarks=
|PassFail=
}} {{TestPlan_Test
|Test={{ #vardefineecho: SubCycle | {{ #expr: {{ #var: SubCycle }} + 0.01 }} }}
|Action=The actions to follow
|Result=The expected result
|Remarks=
|PassFail=
}} {{TestPlan_CycleFooter}}


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

Latest revision as of 14:29, 14 February 2013





Aptean Logo.png







Pentland

Pentland RF Scanning

Dynamics NAV

14th February 2013 - 0.6
Reference: FS 302901











































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 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 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 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 Note: Spare parts that are part of orders with large spares or cabinets (mixed orders) will be delivered through ePOD.

Note 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 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 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?


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

Warning 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 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 Note: Reassigning a pick from one user to another will require the messages to be resent to ePOD. Warning 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: Document References

A.1 References

Ref NoDocument Title & IDVersionDate
1REQ 302901 Pentland Wholesale ePOD NAV WMS v3.0.docx3.008/11/2012


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


Julie Taylor
OBS Project Manager		_____________________________

Richard Hinchliffe
NAV		_____________________________

Leigh Simons
NAV		_____________________________
Retrieved from ‘https://calidusassist.adcservices.apteancloud.com/calidus-assist/OBS/index.php?title=FS_302901_Pentland_RF_Scanning&oldid=1014’