When you need this
Drivers arrive on your site and have multiple (un)loading transactions to complete, each identified by a unique reference:
You want to avoid that drivers have to register multiple times
Your dispatchers need to have a clean look of progress:
Only one transaction is dispatched at a time
Maintain a clear overview of preceding or follow-up transactions
Respect the predetermined sequence of transactions
It is important to have a digital trace of all transactions that were processed on your site
Main idea
Creating a combined transport
A carrier has combined different transactions that will be operated by 1 driver
The driver registers with one reference
The registration process identifies that the reference is part of a group of transactions
All required information is collected during the registration process covering all references in the group
A driver claims to have different references during registration at the kiosk
The driver can enter multiple references during registration
The correctness of each reference is checked
All required information is collected during the registration process, covering all references in the group
Handling a combined transport
A dispatcher handles a driver with multiple transactions
the different transactions are automatically linked
only 1 transaction at a time can be dispatched according to a defined sequence
the dispatcher has a detailed view on preceding or follow-up (un)loading transactions
the dispatcher can add or remove transactions from the combined transport
Wont' do / limitations
Pre-registration
Multiple Check-in visitors
Visitors with multiple check-ins cannot be combined in a transport with other visitors (both multiple and non-multiple check-in). Since each check-in creates a 'clone' of the original visitor, the clone will not be included in the combined transport.
Excel import
Visitor that are created using the Excel import, can’t be added to a combined transport.
Registration
Required fields on kiosk: only for the first visitor in the sequence
The registration process will cover only the questions for the profile of the first visitor in the sequence. Please see next example:
Combined Transport Sequence | Profile | Required fields on kiosk |
Visitor 1 | Inbound | Mobile number, carrier |
Visitor 2 | Outbound | Mobile number, |
In this setup, the registration process will be started for the Inbound profile, regardless the reference that was used for identification. This means that the ‘destination’ field will not be asked during registration!
Document scanning: only for the first visitor in the sequence
Documents will only be scanned for the first visitor in the sequence. When a driver registers with a reference that is part of a combined transport, the registration flow will initiate for the profile of the first visitor (according to the sequence). If document scanning is required for any other visitors in the combined transport, it will be ignored for now.
Certified persons: only for the first visitor in the sequence
The certification flow will kick in when it is required for the first visitor in the sequence. In next setup, the driver will not be asked for certification:
Combined Transport Sequence | Profile | Certification required |
Visitor 1 | Inbound | No |
Visitor 2 | Outbound | Yes |
Adding visitors during registration based on E-ticket
When registering a combined transport, the driver can add additional visitors by entering their reference numbers. Please note that e-tickets are not supported.
Adding ‘ad-hoc’ visitors during registration
When the driver creates a combined transport during registration, adding ad-hoc visitors is not supported. In other words, the provided references must match pre-registered visitors, and no manual fallback is allowed in this process.
Changing a pre-registered combined transport during registration
When a combined transport has been pre-registered, the driver will not be able to modify its details during registration:
the driver cannot add additional references
the driver cannot remove any reference
the driver cannot change the sequence
Transition the visitor to checked-in after auto-approval
To ensure proper visitor flow in a Combined Transport, visitors must first transition to waiting sequence to determine the dispatch order. Therefore, configuring visitors to move directly to checked-in after auto-approval is not permitted. If this configuration is applied, the following will occur:
No confirmation screen will appear on the kiosk; instead, the landing page will reload.
The Combined Transport will be created, but all visitors will remain in Expected.
Dispatch
Unique PIN code for each visitor in the combined transport
It is not possible to obtain a single PIN code that is valid for all visitors in the combined transport. The following scenarios apply:
The PIN-code is only used for site entry: generate the PIN code only for the first visitor
The PIN-code is used for both site entry and checkout: generate PIN codes for both the first and last visitors
The PIN code is required for all visitors (e.g., for onsite barriers, weighing, …): generate a PIN code for each visitor
This logic can be achieved by a new condition that has been added to the trigger ‘when a visitor status changes’:
Checkout
Document signing and printing: not supported
A new condition is required:
All visitors are ready for checkout
When this condition is added to Triggers & Actions, it is possible to create automation to send the driver to the exit to sign and print documents. However this will only print documents that are attached to the visitor that was used for checkout (typically the last visitor in the sequence).
Workaround created for Versele-Laga enables document handling with combined transport. Please check below in the expanded window
Versele-Laga solution
Versele-Laga solution
Versele-Laga requires every visitor (PINcode) to be used in the Check-out process, so visitor can print all transport documents.
In general, we remove visitors from the Combined transport in order to allow them to be checked-out after they have their status set to Departed by the Combined transport automation.
Following triggers have been created to allow that visitor would only proceed to check-out after all documents are available:
Inbound/Outbound/Internal > Ready for Check-out (Last in sequence) > previous status is NOT: ready for check-out | Check-out Order is not: Second > Send SMS template: Check-out
Condition “Check-out order is not: second” is included to avoid that every visitor receives the same SMS to proceed to SSK check-out
Inbound/Outbound (any in sequence) > Departed > Linked Reference is not Empty | Last Modified by SSK > Set Checked-out Order to First
When a visitor checks-out using one of the PIN codes, the visitor linked to the PIN code will be updated as the first one checked-out.
Last Modified by SSK is used to identify which one has been set to Departed by the SSK check-out
Inbound/Outbound (any in sequence) > Departed > Linked Reference is not Empty | Last Modified by CTA > Set Checked-out Order to Second | Clean Linked Reference | Set Status to Checked in | Finish yard operation
When a visitor checks-out at SSK, all visitors part of the combined transport are also set to Departed. This trigger identifies the visitors that have been put to Departed by the Combined transport automation (CTA), i.e.: they have not checked-out at SSK and documents have not yet been printed
We will set a field to identify that he is the second to check-out (not first), remove visitor from Combined transport using a webhook to have an empty field, and then virtually set visitor to Checked-in and immediately finish the yard operation
Attention point: eventual SMSs or API calls that takes into consideration these status changes
Inbound/Outbound (any position) > Departed > Checkout Order: Second | Linked Reference is NOT empty | ACS is not empty > ACS Change: Peripass-ExitOnly | send SMS ready to leave
This trigger will make sure that the PIN code is only enabled in the Exit after the second visitor has checked-out and printed the document
Inbound/Outbound> Departed > Linked Reference is empty | ACS is not empty > ACS Change: Peripass-ExitOnly | send SMS ready to leave
This separate trigger is just to make sure that single visitors (not part of a combined registration) are immediately enable at exit and ready to leave.
If you have more than 2 combined transports, they will also be able to check-out at kiosk as all the other visitors (not first in sequence) will be removed from the combined transport. But after the second reference has been checked-out at SSK, PIN will be already enabled at exit.
Weighing: first and second weight needed for each visitor
When weighing is used in combination with combined transports, the first weight of the second visitor will match the second weight of the first visitor. However, there is no automation to synchronize these weights.
Combined Transport Sequence | First weight | Second weight | Net weight |
Visitor 1 | 1 000 | 1500 | 500 |
Visitor 2 | 1500 | 1700 | 200 |
Visitor 3 | 1700 | 1 800 | 100 |
In the case of weighing within a combined transport, the driver will need to perform both a first and second weighing for each visitor.
More information
Visitor status Waiting sequence
In a combined transport, only one visitor at a time can have the status of Waiting dispatch or Checked-in. When a combined transport is placed in a dispatch queue, all visitors will transition to a new status Waiting sequence. Automation will then determine the first visitor in the sequence (based on configuration) and activate it by either:
Transitioning the first visitor to Waiting dispatch
Auto-dispatching the visitor so it transitions to Checked-in
Profile validities
When adding a visitor to a combined transport, ensure the transport includes at least one visitor with a valid profile for today or a future date.
Registration process of a combined transport
Pre-registered combined transport
When a driver enters a reference that is part of a combined transport, the registration flow will start for the first visitor in the sequence, regardless the reference that was used by the driver.
On the spot created combined transport by the driver
When a driver enters a reference that is not part of a combined transport,
and the tenant is configured to allow the creation of combined transports during registration,
and the driver registers with a profile that is eligible for combined transports,
then the driver will be able to provide additional references.
Each of these references will be matched to pre-registered visitors. In case of a match, the reference will be added to the combined transport.
Operating a combined transport
Copy fields when a combined transport is placed in the dispatch queue
Different events can place the combined transport in the queue:
Automation after a successful registration on the kiosk
Manual action by a user in the UI
API operation
When the combined transport is placed in the dispatch queue, following data is copied from the visitor imitating the change to all other visitors in the combined transport:
Fields marked as ‘copied fields' in the configuration settings
Timestamps of ‘registration started’ and ‘registration ended’
Language
When a visitor from a combined transport arrives onsite
The location of all visitors in a combined transport is synchronized. Thus when a visitor is set to , all visitors in the combined transport are set to .
When a visitor from a combined transport is processed
When a visitor is processed, it transitions to or . The sequence is re-evaluated and the next visitor is activated (transitioned to or auto-dispatched).
A visitor is added to a combined transport
When a combined transport is ‘in progress’, it can only be joined by visitors that are ‘not arrived / approved’. When joined, the data is copied from a random visitor in the combined transport to the joiner.
When a combined transport is ‘departed’ then visitors cannot join anymore.
Removing a visitor from a combined transport is always allowed.
A note on status transitions
Status transitions can impact all visitors in the group
When a visitor is transitioned to a new status, it can happen that all visitors will be updated. This will be reflected in the visitor actions menu:
We define 3 groups of statuses in a combined transport:
Not arrived / approved | In progress | Departed |
Expected Waiting for approval
| Waiting sequence Waiting dispatch Checked-in Waiting for documents Ready for checkout | Departed |
Summarized: when a visitor in a combined transport is transitioned to another status group, all visitors in the combined transport will be updated. Some examples:
A visitor is set to Departed → all visitors are set to Departed
An expected visitor is placed in the queue → all visitors transition to Waiting sequence, and the first in sequence is activated
A visitor in Waiting dispatch transitions to Checked-in: no effect on other visitors in the group.
Blocking a visitor that is part of a combined transport
A blocked visitor can never be part of a combined transport. When a visitor is blocked, it is removed from the combined transport.
Advanced asset management
Drop-off full and Pick-up full
When drivers need to drop-off a full asset (with reference) and pick-up a full asset (with another reference), this can be organized with combined transports:
Combined Transport Sequence | Profile | Operation type |
Visitor 1 | Inbound | Drop-off full |
Visitor 2 | Outbound | Pick-up full |
When this combined transport is pre-registered, the driver only needs to enter one of the references.
If the driver creates the combined transport during registration, both references will be approved before they can be combined into a single transport.
Drop-off and pick-up on different dispatch dashboard
When drop-off and pick-up transactions are organized within a combined transport, it is possible to operate both actions on different dispatch dashboards.
⚙ How to configure
At this moment, only 1 combined transport definition is supported per tenant (across all sites):
⚙ Configuration > Combined Transport
Configuration highlights:
Reference field: unique identifier shared by all visitors in a combined transport
This reference field must be configured but can remain empty during visitor pre-registration. When the driver combines visitors at the kiosk, the system automatically generates and fills in this reference field.
This reference field can no longer be changed once the first combined transport has been created!
Transaction sequence: visitors are sorted using a two-level approach
Sorting level | How to use |
Profile-based sorting | Visitors are first ordered by profile: starting with Inbound, followed by Outbound, and so on. |
Custom Field Sorting (Two Levels) | Custom Field 1 – e.g., differentiating Just-In-Time flow from Stock flow
Custom Field 2 – e.g., based on Slot Start time |
Copied fields after registration: when a visitor is placed in the queue, these fields will be synchronized to all other visitors in the combined transports (! this happens only once !)
Configuration guidelines
Import translations
We have introduced a new kiosk screen to enable drivers to combine different transports during the registration process. This screen requires translations for various text labels, which you can manually add in the configuration settings: ⚙ Configuration > Combined Transports > Translations.
To help you get started, you can import the provided Excel file containing standard translations for the text labels:
Ready for Checkout: Free up yard location
The yard location of a regular visitor is automatically cleared when they transition to 'Departed.' However, for visitors in a Combined Transport, you might want to free up locations earlier to prevent the same driver from occupying multiple spots. The recommended flow should be as follows:
The first visitor transitions to 'Ready for Checkout.'
The second visitor is added to the queue.
The yard location of the first visitor is cleared.
To achieve this behavior, you will need to add a trigger that frees up the yard location when the status changes to 'Ready for Checkout.' You can also add a condition (e.g., 'CT Reference is not empty') to ensure this only applies to visitors in a Combined Transport.
Sending Different Text Messages on Re-dispatch
You may want to customize the SMS content sent to drivers based on whether it's their initial dispatch or a subsequent re-dispatch.
First Dispatch Example:
“Welcome to our site. Please use the following PIN code to open the barrier and proceed to D-01.”
Re-dispatch Example:
“Please proceed to D-03 for your next operation.”
How to Configure:
Use the conditions ‘Is first in sequence’ or ‘Is not first in sequence’ within your status change triggers. This allows you to send different messages based on the position in the dispatch sequence.
No redispatch: all visitors are (un)loaded at the same dock
You can configure next trigger:
Trigger: on status change to ‘Waiting dispatch’
Condition: if not first visitor in sequence (see above)
Action: transition the visitor ‘Finish yard operation’
Guidelines for integrations
When visitors are created by host systems (ERP, WMS, TMS) or Time Slot Management systems, integration should be configured to align with the desired handling of combined transports:
Will the various orders on the transport be loaded at the same dock?
Will the orders frequently require (un)loading at different docks, necessitating redispatching on site?
Transporeon standard integration - combine and book
Be careful, the combine and book features will not create combined transports (see case 2 of the image above): Transporeon has the option to let the carrier combine different bookings to one grouped slot. This is known as the feature ‘Combine and book’. The resulting grouped slot will be synchronized to Peripass as a single visitor. Some fields of that visitor can be multivalued, reflecting values from the individual bookings, e.g. order number. If such a multi-valued fields is used for automatic approval, the driver can identify with any reference from that list during registration.
Troubleshooting
My visitors are not displayed in the correct order …
Let’s explain sorting by looking at next example:
The visitors are displayed in next order:
First all visitors in status Wating for documents, Ready for checkout and Departed
These visitors are sorted by the time their yard operation was finished
! If the combined transport is departed, all visitors in the sequence are sorted this way
Then the visitor in the status Checked-in
Finally the dynamic calculated sequence of all remaining visitors
First according to profile sorting
Next based on customer field (selected for sorting)
Finally based on creation_date in the database (lowest visitor id first)