Last updated: 19.07.2024
Valid from: Opter 2024.06.00
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

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. 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. ![]() 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 |
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 | ![]() |
Price item mandatory | ![]() |
Require name |
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 |
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 |
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 |
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.
|
Require image | Applies to Opter Driver and Opter Terminal.
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 |
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.
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 |
|
Display on the menu in Opter Driver |
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 |
|
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 =
|
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 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. 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.
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.
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 |
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.
For more information, see POD for partial deliveries. 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. |

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. 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 |
|
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). ![]()
The order date on the copy will be the day after the POD date.
The order date on the copy will be the day after the date of the original order. |
Use POD-date as order date |
|
Copy resource to spawn order Assign new order |
|
Saturday is working day |
|
Sunday is working day | ![]() |
Copies are not counted in the number of automatically created orders |
|

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.
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 |
|
Default | Fallback if no code matches when exporting/importing proofs of delivery.
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. |