Recurring transport orders
General
The recurring (transport) order functionality is an advanced approach to efficiently manage recurring transport needs. These orders are designed for situations where there is a repetition of similar transport tasks over a specific period. It could involve periodic deliveries to the same destination, returns, or other regularly recurring transport requirements.
Functionality
Through the recurring order page, the content of recurring orders can be configured in a flexible and consistent manner. The template provides the possibility to capture specific information at both a transport document header and line level.
Set up recurring order - GENERAL
| Field | Comment |
|---|---|
| Code | An unique code for the template |
| Description | Template description |
| Calculate from | This field allows the user to set the run date for the recurring order template. For example, if the value is set to +1D, the system will add 1 day to the current run date. The validation, including calendar checks and other criteria, will subsequently proceed with the new date (current date + 1D) to ensure compliance with various validations. |
| Valid from date | The valid from date specifies from which date the recurring order line can be determined as valid. The from date itself is included. |
| Calculate Calender Code | Select a calandar and define non-working dates so that on that date no orders will be generated. |
| Valid to date | The valid to date specifies until which date the recurring order template can run. The to date itself is included. If left empty, the valid to date is unlimited. |
| From address no. | From address no. reference |
| To address no. | To address no. |
| Batch | Parameter that specifies whether the template needs to be validated by the recurring order job queue |
| Last error | Display of error message in case the recurring order run was not successful. |
Set up recurring order - LINES
The fields defined via the recurring order lines section are linked to the corresponding fields at a Transport Document Header level. The logic of each individual field will be explained below.
| Field | Comment |
|---|---|
| Recurring order line no. | Recurring order line no. |
| Line description | Recurring order line description |
| Valid from date | The valid from date specifies from which date the recurring order line can be determined as valid. The from date itself is included. |
| Valid to date | The valid to date specifies from which date the recurring order line can be determined as valid. The to date itself is included. |
| Monday-Sunday | The system will validate the day of the calculated date [current date + calculate from value, see general tab]. For this day the system will validate whether a recurring order needs to be created. |
| Workday Calendar | Selecting a non-working day calendar will automatically shift the calculated (un)loading date if the date is on a non-working day. |
| From address no. | From address no. |
| To address no. | To address no. |
| Loading day calculation | Calculated from date + e.g. "+ 0D", "+ 2D" etc. |
| Loading time from | |
| Loading time to | |
| Unloading day calculation | Calculated from date + e.g. "+ 0D", "+ 2D" etc. |
| Unloading time from | |
| Unloading time to | |
| Workday calendar | The system will validate whether the loading and unloading date are valid workdates based on the configured calendar. If not, the system will find the next valid workday. The next valid workday will subsequently be used as the unloading or loading day. |
| Department | Default department value that can be defined for the transport order. |
| Customer no. | Default customer no. value that needs to be defined as part of the transport order. |
| Execute function set | Function set that can be used to define the logic of certain fields that needs to have a certain value as part of the transport order. |
Note
The default value any field that is not mentioned in the recuring order line can be via the "Edit default values" logic.
Set up recurring order - Detail lines
The fields defined via the recurring order detail lines section are linked to the corresponding fields at a Transport Document Line level. The logic of each individual field will be explained below.
| Field | Comment |
|---|---|
| Recurring order line no. | Recurring order line no. |
| Recurring order line no. | Recurring order detail line no. |
| Detail line description | Recurring order detail line description |
| Valid from date | The valid from date specifies from which date the recurring order detail line can be determined as valid. The from date itself is included. |
| Valid to date | The valid to date specifies from which date the recurring order detail line can be determined as valid. The to date itself is included. |
| Type | Line type, e.g. good, customer item etc. |
| No. | Transport goods no. |
| Description | Transport good line description |
| Quantity | Transport good line quantity |
| Unit of measure code | Unit of measure |
| Load meter | |
| Pallet unit place | |
| Gross weight | |
| Net weight | |
| Length | |
| Width | |
| Height | |
| Volume |
Note
The default value of all fields that are part of the transport document line can be defined via the "Edit default values" logic.
Example of recurring order functionality
Scenario 1 - Calculate from
In this scenario, we will dive into the logic behind the calculate from field. In this particular example, we execute the template on a Thursday. The calculate from value has been determined as +1D. This means that orders will start the proces of creating orders for Friday.
Note
- The creation of recurring orders will be triggered by means of clicking on the "Create orders" button. It will also be possible to trigger the creation of recurring orders by means of a job queue. This logic will be shown as part of scenario 4.
Scenario 2 - Day checkboxes
In this scenario, we will dive into the logic behind the day checkboxes. In this particular example, we execute the template on a Thursday. Based on this template, only line 20.000 will be generating a new order.
Scenario 3 - Unloading and loading day calculation + Workday calendar
In this scenario, we will dive into the logic behind the loading day and unloading day fields and the impact of the workday calendar configuration. In this particular example, we execute the template on a Wednesday 27-03-2024.
| No. | Field | Value | Remark |
|---|---|---|---|
| 1. | Calculate From | +2D | If excecution is started on 27-03-24 the date for creating the order will be set to 29-03-2024. |
| 2. | Calculate Calander Code | All Days | No exceptions have be set in this callender so orders will be created with Creation Date: 29-03-24. |
| 3. | Recuring Line No. | 10000 | Friday is Checked, the Loading-Day-Calculation: 0D results in: 29-03-2024. In the Workingday-Calender 29-03-24 is a workingday. The final determination of the loadingday is: 29-03-204. The Unloading-Day-Calculation: +1D results in 30-03-2024. In the Workingday-Calendar 30 and 31-03-2024 are non-workingdays. The final determniation of the unloadingday is: 01-04-2024. |
| 4. | Recuring Line No. | 20000 | Friday is Checked, the Loading-Day-Calculation: 0D results in: 29-03-2024. In the Workingday-Calender 29-03-24 is a workingday. The final determination of the loadingday is: 29-03-204. The Unloading-Day-Calculation: +1D results in 30-03-2024. In the Workingday-Calendar 30, 31-03 and 01-04-2024 are non-workingdays. The final determniation of the unloadingday is: 02-04-2024. |
Scenario 4 - Job queue
In the above examples it has been highlighted how the creation of recurring orders can be manually triggered. Besides this manual trigger option it will also be possible to trigger the creation of recurring orders periodically. The below job queue will validate for all recurring order templates for which the "batch" checkbox has been enabled whether new orders needs to be created.
