10.0-CAP47.0 (21.05.2025)

It is now possible to specify Service level agreement (aka. SLA) during order registration in the customer portal. Default SLA is initialized from the customer account, but can be manually overridden during order registration.

Please note: the service level agreement intelligent 'finder' (ie. action button) is not available on the customer portal.

Via "portal blocking" conflicts it is possible to restrict transmission of orders that have eg. ADR co-loading restriction applied (ie. that would lead to loading/unloading of 'not allowed combination' of dangerous goods on the order lines).

Via new parameter 'No transport costs in portal' on the customer account, the transport related costs can be suppressed (ie. not shown) in the customer portal.
When parameter is activated, following restrictions are applied on the customer portal, for portal users that are eligible for management of orders of such customer account:
- Transport order & Offer & Invoices screens are not shown in main menu
- Price calculation action button is hidden (so no price calculation can be performed, and no price calculation details are shown)

'Address search auto-complete radius' logic was removed already in R46 (due to implementation of "Google API (new)" version, in R47 the parameter was removed also physically from GUI.

New feature represents a possibility to offer subcontracting request(s) to one or more carriers (aka. vendor accounts), for transporting the tour. Subcontracting requests contain the agreed price (for carriers with agreed price tariffs), or individual spot price (ie. manually set price) or carriers can specify (ie. offer) the price by themselves.

Received feedback from the carriers (eg. confirmation or rejection) is then processed in D365 dispatching module/GPB and selected subcontracting request is transformed into full featured subcontracting order, which follows usual subcontracting order lifecycle.

The communication (and interaction) with carriers happens entirely via CAPcargo Carrier portal (that requires a separate licence).
Furthermore, the possibility to send status messages to vendors or vendor contacts is introduced. The vendor can be informed when certain events occur, e.g. new subcontracting request is created.

A new feature was added for better visualization In the GPB Order Screen of the time planned for load and unload using custom colors.
Time window fields, as well as corresponding 'From' and 'Till' can be now customized for background and font color (separately for 'Load' and 'Unload').
The setup is done in GPB parameters > Transport orders /-legs > Setup background colors for column fields (separate tabs for Load and Unload time windows).

Prior to this feature being introduced, there were 2 ways to reserve a transfer or sales order line:
- manually/automatically on the order line
- by the release to warehouse process

The new feature not only offers a new way to reserve order lines - based on the CAPcargo transport leg entity - but it can be done both automatically (based on advanced filtering) and manually (on transport leg and shipment line levels).
Furthermore, besides the reservation function, it also introduces a new status field: Reservation status. This field provides the reservation information on transport leg and shipment line levels. Also available in GPB 'Transport orders/-legs' screen..

The new reservation function is only available in shipment builder v3.

Key points:
- New parameter "Empties exchange" in the portal parameters
- If activated, then "Empties exchange" flag is shown (and can be set) in the new address creation dialogs on the customer portal.

Please note:
- Setting the "Empties exchange" during address creation on the portal will automatically create a transport address, as the flag "Empties exchange" is stored on transport address only.

Key points:
- new action button "Remove not confirmed legs/packages from the tour" in GPB gantt screens (under Tour confirmation action button section)
- new action button "Remove not confirmed legs/packages from the tour" in D365 "Dispatch light - Tours"

The Department lookup was already available on the Driver masterdata (CAPcargo Transport > General > Defaults) and Vehicle Masterdata (General > Vehicle). This lookup was now added to the Driver and Vehicle creation wizards as well.

Customer tab in Transport order creation form is enhanced with new field Transport type which is located next to the SLA field. The field is a duplicate of the same field in General tab. Changing Transport type value in any of these fields will automatically change it in the other one.

Before the introduction of the latest subcontracting mode ('tour subcontracting' - see CAP46, ADO112106), there were only two vendor sources possible for tour additional cost: Resource subcontracting and Tr-Leg subcontracting (lookup in Transport Parameters > Dispatching > Subcontracting).

With the introduction of 'Tour subcontracting', there was now a new source of vendor for tour additional cost, which implied potentially many complex combinations at tour level between these vendor sources. The process of finding the vendor source for tour additional costs was thus simplified to take into account the new subcontracting mode, as well as future new subcontracting modes.

Changes in parameterization setup:
- existing lookup 'Vendor source for tour add. cost' (found in Transport Parameters > Dispatching > Subcontracting) was removed
- existing flags 'Vendor from Tr-Leg subcontracting' and 'Vendor from Resource subcontracting' from form 'Surcharge type' were removed and replaced with flag 'Vendor from subcontracting'
- existing flags 'Vendor from Tr-Leg subcontracting' and 'Vendor from Resource subcontracting' from form 'Tariff surcharge groups' were removed and replaced with flag 'Vendor from subcontracting'

Changes in logic of finding vendor for tour additional costs (whether surcharges are created manually of triggered automatically from confirmation of activities setup with tariff surcharge groups):

Check flag 'Vendor from subcontracting' :
If False, then check if Default vendor account is filled
- If True, select vendor
- If False, stop process, display error: "No vendor identified. Please select vendor manually."
if True, then, look in Subcontracting table on the particular tour:
- if NO subcontracting order found, check if Default vendor is filled
-- if True, select vendor
-- if False, stop process, display error: "No vendor identified. Please select vendor manually."
- if only one subcontracting order found (of any type: TrLeg, Resource, Tour) take the Vendor from that subcontracting order and use it for tour additional cost
- if multiple subcontracting orders found, but only one unique vendor found on all of them (regardless of whether same or different type), take the Vendor and use if for tour additional cost
- if multiple subcontracting orders found AND more than one unique vendors found on them, stop the process without selecting any vendor, and display error to user: "Multiple unique vendors identified (vendor 1 ID, vendor 2 ID, vendor 3 ID, etc.). Please select vendor manually"

At pre-dispatching of a transport order, there is a validation within the order if co-loading ready, also across the order lines. If not, and splitting is allowed, the dispatching process automatically creates part deliveries, where the order lines are split off, leading to separate transport leg(s). If splitting is not allowed (see also 113813), system will block.

If direct dispatch is called for a co-loading restriction, the system also blocks. There is no point in splitting apart 2 co-loading restricted dangerous goods as separate legs, and then auto-plan them in to the same tour. Dispatcher has to handle this via pre-dispatching.

Previously, the load/unload dates on the transport order creation form were always initialized based on default settings from Transport Parameters>General>Transport order>Default values. Based on Rules rough scheduling, or any other rules which could influence pre-dispatching (route/zone setup, cross-docking rule setup, address opening hours etc.), the actual Initial load/Final unload of the transport order could differ significantly from the dates initialized on the transport order itself.

It is now possible to simulate actual load/unload dates (based on all applicable rules for lead-time and transit time) even in the phase of transport order creation, so that transport order load/unload dates could basically match the load date of initial transport leg (or only leg) and the unload date of final transport leg (or only leg) in pre-dispatching. This can help the user get realistic suggestions for load/unload dates even before the transport order is actually pre-dispatched.

Following enhancements were done to achieve this:
- New parameter on Transport type>Order Management>Lead time: 'Date initialization load/unload'. Two possible values can be selected from lookup. When 'Static' is selected, no active initialization is done ('old' mode). When 'Dynamic' is selected, the new functionality is enabled (new button on transport order create form and transport order ribbon).
- When 'Dynamic' transport type is enabled, another parameter on transport type can be set 'Number of days used in iteration', which can be set to maximum value of 100, and represents the maximum number of days, added in +1 increments to the start date, used to generate load/unload options which will be displayed by default.
- When a 'Dynamic' transport type is used while creating a new transport order, a new button 'Load/Unload scheduling date options' appears under the load/unload date sections.
By pressing this button, a new form is opened, where the load and unload dates are automatically initialized with the first load/unload date pair starting with 'Now' which is found by the new algorithm. For additional options, user can press 'Show next options' button and will be shown one or more lines which can be selected to be initialized on the transport order.
- A duplicate 'Transport type' field was added in the General section of the transport order creation form, for more transparency to the user of the way that the transport type selection affects the auto-initialized load/unload dates.
- On the transport order details screen, the button appears on the ribbon (Transport order>Maintain>Load/Unload scheduling date options), providing same functionality. However, when user edits an existing order, the changing of the elements potentially influencing the load/unload dates (customer, load/unload address, transport type, SLA) does not automatically initialize the load/unload dates on the transport order. When transport order is in a status past 'Registered', the selection of any lines from this form does not have any effect on load/unload dates.
- Rules rough scheduling form was also enhanced. A new transport type field was added, and only the 'Dynamic' transport types can be selected.
Since some of the functionalities of the rules rough scheduling and transport order creation deadline rules are somewhat similar, please note that there can be colliding setups in particular constellations, leading to undesirable behaviors, even though technically correct. CAP does not recommend using both setups at the same time affecting same data (ex. transport type).
- A new periodic function was implemented: 'Generate pre-dispatching simulation metadata'. In order for the 'Load/unload scheduling date options' to work correctly, this periodical needs to run every time changes are made to route/zone / crossdocking rules (including setting of criteria). After release code deployment, it is necessary to run this function at least once, even if no changes are done.

This functionality is also available on the Customer portal, if enabled (ie. if "Dynamic" mode is enabled on transport type).
- A new parameter on Transport type>Order management>Portal order>Route/zone required. When toggled to 'Yes', user is prevented from creating/using on TRO addresses which do not belong to a route/zone. Please note the known issue for this point.
- When creating Transport orders while using 'Dynamic' Transport types, user is limited to selecting only from the load/unload date options available in the calendar widget, never in the past.

Manual adjustments/override can only be done in D365 TAL.

Please note the related known issue 114343, for missing parameter of address validation process.

For consistency, several places still using the term 'Passenger' were adjusted to use 'Additional driver'.

Previously, even though multi-select of subcontracting orders was possible, the Delete action only affected one subcontracting order at a time. Now, all selected subcontracting orders can be deleted at the same time.

Following enhancements were added, for better management of public address:
- new info message on the customer portal, when users performs "Request address to be public"
- Possibility to declare address as public already in the address creation wizard
- "Public address" buttons were added also to transport address form
- Indication (of whether address is public) was added to transport order form and to address details (in the global address book)
- "Request for public address" form was added to inquires in the main menu

With US 113537, a new parameter, 'Time window required', was introduced on SLA, with default value 'Not required'.
In the followith setup constellation:
- this 'Time window required' parameter is set to one of the other values in lookup (Load/Unload/Both) AND
- existing Transport Type parameter 'Trigger automatic SLA search at order creation' = Yes (True)

the order creation process fails to write to the newly created Transport order header the matching SLA (if found).
This happens both during manual creation of Transport orders and automatic creation via data import.

These parameters are not designed to work together, and the conflicting scenario will be fixed on-demand, once constellation is needed and reported as such.

Data migration task for 112123.

Previously it was not possible to set up Depot app without having Truck loading app license installed (and without having at least one depot enabled for Truck loading app). As depot app users could only be linked to depots which were enabled for Truck loading app. The issue is corrected and Depot app now can be used without activated license configuration key for Truck loading app.

The issue was especially happening when high amount of tours were loading onto gantt screen and users started to scroll down.

The issue was especially happening when more resources were on a tour and some of them were deleted. Then level 1 and level 3 were refreshed but level 2 was not refreshed. This was fixed and now level 2 is updated when resources are deleted from the tour.

The issue was especially happening when dragging a driver from source tour (from level 2) and dropping the driver to another tour (to level 1). Then the level 1 of source tour got stuck in endless refresh/spinning wheel.
Please note that issue was only GUI cosmetic (ie. failed refresh), the underlying data for moving drivers between tours were generated correctly.

The issue was corrected. Insert tour stop and Change address GPB dialogs are not blocking the GPB client anymore.

The issue was especially happening when original sales order contained more order lines, with same item. The issue was affecting only shipment builder V3.

Previously, the Transport order header flags 'Automatically generate sender delivery leg' and 'Automatically generate receiver pickup leg' were not properly activated and available for changes as soon as their corresponding flags (Sender delivery and Receiver pickup) were set to Yes.

Previously, when a Transport order was predispatched, and one of the Transport legs was directly subcontracted (without tour), if user created another line on the Transport order, the new line did appear on the direct Tr-leg subcontracting order, but it did so as many times as there were Transport legs related to that Transport order, instead of only once.
The issue was present both in the UI and in the underlying TALSubcontractingOrderLine table. The direct subcontracting order confirmation form and process were not affected.

This task contains the fix for the issue. In the next release, a data migration job will further be delivered, to clean up such wrongly data generated before this fix was applied.