Proof of delivery types (window)

Settings > Proof of Delivery (POD) > Proof of delivery types

Use this window to set the POD types (proof of delivery types) that should be in the system and how they should work. For example, it is possible to control the POD types that can be registered in Opter Driver and on the webs, and the details that are required when registering a POD. For more information about POD types, see Introduction to POD (proof of delivery).

The window’s tabs

General

Function	Description
Name	The name of the type. Displayed in the list on the left.
Description	Free text field for internal notes. The description is not displayed anywhere else but here.
Notify operator by email	Enter an email address here if you want to send a message to someone when a POD of this type is registered. This can be useful if you have a POD type for important events that you do not want to risk missing. The Do not send notification checkbox (see below) must be deselected for the notification to be sent. Note: In order to send an email, you must have selected a report for Email to operator on POD in the office settings (the Reports tab).
POD type (if not last shipment)	If the proof of delivery type is only to be used on the last shipment of an order, select which type it should be replaced with if it is used on a shipment other than the last one. [None]: The POD type can be used on all shipments. Example Courier Services has decided that the Delivered POD type should only be used for successful deliveries to the final receiver. They therefore create the “Sub-shipment delivered” POD type and select that type in this drop-down list on the Delivered POD type. If a driver selects the Delivered POD type when unloading at a terminal (i.e. not the last shipment), the POD type is automatically changed to “Sub-shipment delivered”. For more information, see Preventing a proof of delivery type from being used for shipments other than the last one on the order.
Do not send notification	: No email is sent to the address in the Notify operator by email field above when a POD of this type is registered. : An email is sent to the address in the Notify operator by email field above when a POD of this type is registered. Check that the correct email address is shown in the Notify operator by email field above and that a report has been selected in the Email to operator on POD drop-down list on the Reports tab in the office settings.
Deviation type	Preselected deviation type when registering deviations via POD. Only applies to Opter Driver for iOS.
Deviation event	Preselected deviation event when registering deviations via POD. Only applies to Opter Driver for iOS.
Deviation reason	Preselected reason for deviation when registering deviations via POD. Only applies to Opter Driver for iOS.
Deviation mandatory	: The driver must add a deviation when registering the proof of delivery. Only applies to Opter Driver for iOS.
Price item mandatory	: The driver must add a price item on the order when registering the proof of delivery. Only applies to Opter Driver for iOS.
Require name	: The name of the receiver must be stated. Applies to order reception, Opter Driver and Opter Terminal. The setting can be overridden for individual customers by selecting Name always optional on the Proof of Delivery (POD) tab in the customer registry.
Require signature	: The receiver has to write their signature in the app. Applies to Opter Driver and Opter Terminal. It is not possible to enter a signature in order reception, but the signatures from the apps are displayed there. The setting can be overridden for individual customers by selecting Signature always optional on the Proof of Delivery (POD) tab in the customer registry.
Require remark	: The Remark field/column must be filled in. Applies to order reception, Opter Driver and Opter Terminal. The field can be shown/hidden in Opter Driver with the PodRemarkEnabled mobile data setting, see Mobile data settings (window). The setting can be overridden for individual customers by selecting Remark always optional on the Proof of Delivery (POD) tab in the customer registry.
Require comment	: The Comment field/column must be filled in. Applies to order reception, Opter Driver and Opter Terminal. The field can be shown/hidden in Opter Driver with the PodCommentEnabled mobile data setting, see Mobile data settings (window). The setting can be overridden for individual customers by selecting Remark always optional on the Proof of Delivery (POD) tab in the customer registry. For more information, see Adapting the POD view in Opter Driver for iOS.
Require time	Applies to order reception only. : The Time column must be filled in. The time indicates when the POD was registered.
Require image	Applies to Opter Driver and Opter Terminal. : A picture must be attached to the POD. The setting can be overridden for individual customers by selecting Image always optional on the Proof of Delivery (POD) tab in the customer registry.
Completed	: When the proof of delivery is registered on an order, the order is considered to have been completed and is deleted from dispatch in the daily clean-up. Note: The status of the order does not change. We recommend that Set status to delivered/unloaded is also selected on the Status and Spawns tab (see below).
Scan comment	Applies to Opter Driver only. Choose whether the driver should enter a comment manually or scan. If you want the driver to scan the comment (for example, scan a barcode), select the Scan comment checkbox. : The driver can or must scan the comment. : The driver can or must enter the comment manually in the Comment field. If it is to be mandatory for the driver to fill in the Comment field, select the Require comment checkbox above. For more information, see Adapting the POD view in Opter Driver for iOS.
Available in mobile device	: The POD type can be selected when registering the proof of delivery in Opter Driver and Opter Terminal.
Display on the menu in Opter Driver	: The POD type is displayed as a shortcut on the menu of the detail view in Opter Driver for iOS. Can only be selected if Available in mobile device (above) is selected, and if the POD type is a main POD type. For more information, see Setting the POD type as a shortcut on the menu in Opter Driver for iOS.
Available on the web	: The POD type can be selected when registering the proof of delivery on the resource webs.
Consider time failure Acceptable delay	If the order is delayed, i.e. was unloaded after the latest delivery time, you can indicate that the delay was acceptable (for example, if there was an accident on the road). Then the order will not be counted as late in the delivery time accuracy statistics, and will not be displayed when you search for delayed orders. These checkboxes assume that Acceptable delay = for the cause of delay specified on the order (see Delay reasons (window)). If Acceptable delay = for the cause of delay, these settings do not matter. In that case, the order does not count as delayed. This is therefore a way of indicating that a delay is acceptable in individual cases, even though the cause of the delay is not actually considered acceptable. + : The order is treated as delayed. + : The order is treated as delayed. + : The order is not treated as delayed. + : The order is treated as delayed.
Main POD type	If the POD type is to be a sub-POD type, select which main POD type it belongs to here. Only main POD types are shown in the list. [None]: The POD type is a main POD type. For more information, see Configuring main POD types and sub-POD types.
Use main POD type settings	Dimmed if [None] has been selected for Main POD type.. : The sub-POD type inherits all settings from the parent POD type. : Separate settings for the sub-POD type. The sub-POD type does not show that its settings are inherited from the main POD type, and you can change the settings on the sub-POD type and save it to make it look as though it has its own settings, but the main POD’s settings will apply. Note: The sub-POD type does not show that its settings are inherited from the main POD type, and you can change the settings on the sub-POD type and save it to make it look as though it has its own settings, but the main POD’s settings will apply. For more information, see Configuring main POD types and sub-POD types.
Show Sub POD types	Applies to main POD types only. : The sub-types of the main POD type are displayed to the user when a POD is registered. : Only the main POD type is displayed to the user when a POD is registered. Note: Does not apply to order reception. The sub-POD types are always displayed there. For more information, see Configuring main POD types and sub-POD types.
Require Sub-POD-type	Applies to main POD types only. : The user must select both a main POD type and a sub-POD type when registering a POD. : It is only necessary to select a main POD type when registering a POD. Note: Does not apply to order reception. There is no need to select a sub-POD type even if this option is selected. For more information, see Configuring main POD types and sub-POD types.
Partial delivery of packages + Create POD of this type when all packages are partially delivered	+ : When all the packages on an order are linked to a partial delivery POD, another POD of the type for which Create POD of this type when all packages are partially delivered is selected is registered. Note: If you select Create POD of this type when all packages are partially delivered for multiple POD types, the POD type that was first selected is used. + : No additional POD is registered. All POD types work as normal POD types. + : No additional POD is registered. All POD types work as normal POD types. + : No additional POD is registered. All POD types work as normal POD types. For more information, see POD for partial deliveries. Tip We recommend using automatic copies to manage partial deliveries instead. It can be set to ensure a new order is created automatically for the packages that have not yet been delivered. For more information, see Creating new orders automatically based on POD.

Status and Spawns

Set status

Set the status that an order should be given when a POD of the current type is registered here.

If it is mandatory to register a POD when the driver changes status in Opter Driver, the shipment will be given the status that the driver sets manually, not the status set here for the POD type. For more information, see Require POD for a change of status.

To ensure that it is not possible to change the status of the shipment when a POD is registered, select Set status to > [None].

Function	Description
Set status to pickup/loaded	The status of the order is set to the status defined as Pickup/Loaded in the life cycle when the POD is registered.
Only if all packages are picked up/loaded	The status only changes if all packages on the order have been scanned for pickup.
Set status to delivered/unloaded	The status of the order is set to the status defined as Delivered/Unloaded in the life cycle when the POD is registered.
Only if all packages are delivered/unloaded	The status only changes if all packages on the order have been scanned for delivery.
Set status to failed delivery	The status of the order is set to Failed delivery when the POD is registered.
Set status to	Select the status of the order when the POD is registered. [None]: The status of the shipment does not change. Note: To set the status to Picked up or Delivered, we recommend using Set status to pickup/loaded or Set status to delivered/unloaded instead of this field, as these options set the status associated with Pickup/Loaded or Delivered/Unloaded in the life cycle.

Available

Applies to Opter Driver only. These two checkboxes define when the POD type can be registered.

Function	Description
Before status Pickup/Loaded After status Pickup/Loaded	+ : The POD type can always be registered, regardless of the status of the order. + : The POD type can be registered on orders before they have reached the life cycle status defined as Pickup/Loaded. + : The POD type can be registered on orders only when they have a status that is later in the life cycle than Pickup/Loaded. + : The POD type can never be registered, regardless of the status of the order.

Function

Description

Before status Pickup/Loaded

After status Pickup/Loaded

+ : The POD type can always be registered, regardless of the status of the order.

+ : The POD type can be registered on orders before they have reached the life cycle status defined as Pickup/Loaded.

+ : The POD type can be registered on orders only when they have a status that is later in the life cycle than Pickup/Loaded.

+ : The POD type can never be registered, regardless of the status of the order.

Automatic creation of orders

This is where to set whether a new order should be created when the POD is registered. For more information and examples, see Creating new orders automatically based on POD.

Function	Description
Spawn type	New delivery: New delivery to the receiver. Return to sender: Transport back to sender. Return to terminal: Transport back to the previous terminal. Open delivery: The receiver address is deleted from the new order, but the name of the receiver is copied. Usually used for PODs of the New address type when the new order is going to an address that is different from the original order.
Copy packages	All: All the packages on the original order are copied to the new order, regardless of whether they have already been delivered or not. None: No packages on the original order are copied to the new order. Used for example when the new order relates to the transport of loose items back to a terminal. Not linked to POD: Packages for which a POD has been registered are not copied to the new order. Only packages that do not have a POD are copied. If all packages in the order already have a proof of delivery, no new order is created. This option can therefore be useful on partial delivery POD types, as no new order is created if a delivery POD has been registered for all packages. Linked to POD: Packages for which a POD has been registered are copied to the new order.
Service	Choose a service for the copy. [Default]: The same service as the original order.
Extra working days	Adds extra days to the copy’s order date based on the setting used for Use POD-date as order date (see below). Example Extra working days: “1” Use POD-date as order date: The order date on the copy will be the day after the POD date. Extra working days: “1” Use POD-date as order date: The order date on the copy will be the day after the date of the original order.
Use POD-date as order date	: The order date on the copy will be the same as on the original order. : The order date on the copy will be the date the POD is registered.
Copy resource to spawn order Assign new order	+ : The copy is not allocated a resource and must be manually assigned one in dispatch. + : The resource on the original order is pre-planned on the copy, but the shipment still has to be manually assigned in dispatch. + : The copy is automatically assigned to the same resource as the original order. + : The copy is not allocated a resource and must be manually assigned one in dispatch.
Saturday is working day	: Saturdays are treated as working days when the order date is inserted on the copy.
Sunday is working day	: Sundays are treated as working days when the order date is inserted on the copy.
Copies are not counted in the number of automatically created orders	: When a POD of this type is registered, the new order is treated as an automatic copy. A maximum of two automatic copies of the original order can be created via POD. : The automatic copy is not treated as a copy. Used when the receiver is not to be charged for a failed delivery, for example.

EDI

Note:

Do not change the settings on this tab as this may cause the EDI links to stop working. Any changes to EDI connections are charged on an hourly basis. Contact for more information.

This tab shows how the proof of delivery is transferred via EDI. The settings are retrieved from the Mappings window (the Proof of Delivery (POD) tab), and changing them here will also change the setting in the Mappings window. You have to change tabs to save your changes.

Tip

Only some settings for the POD type of the different mappings are displayed in this window. The Mappings window provides an overview of the settings for all POD types on mapping.

Column	Description
Mapping	The name of the mapping. The mappings are managed in the Mappings window (Settings > EDI > Mapping).
Code	The code is used to pair the POD type in Opter with the corresponding POD type in the external system.
Sub code	If several POD types have the same code, the subcode can be used to distinguish the POD types, thus pairing the POD type in Opter with the corresponding POD type in the external system.
Do not export	: Proofs of delivery of this type are not exported via EDI. : Proofs of delivery of this type are exported via EDI.
Default	Fallback if no code matches when exporting/importing proofs of delivery. : If no code or subcode for any POD type in the mapping in Opter and the external system matches, this POD type is registered when importing/exporting the order. : If no code or subcode for any POD type in the mapping in Opter and the external system matches, no proof of delivery is registered at all when importing/exporting the order. Note: It is not possible to see which POD type is selected by default in the mapping here unless you go through all the POD types one by one. It is possible to select several POD types by default on the mapping, but the one that was first selected by default will be used if no code matches. We recommend that this checkbox is not selected or deselected here but that this is done in the Mappings window instead, where it can be seen if any other POD type is already selected by default.

Reference Materials

Introduction to POD (proof of delivery)

Preventing a proof of delivery type from being used for shipments other than the last one on the order

Adapting the POD view in Opter Driver for iOS

Configuring main POD types and sub-POD types

POD for partial deliveries

Require POD for a change of status

Creating new orders automatically based on POD