10.0-CAP48.0 (25.06.2025)

Reporting Emissions Respecting International Guidelines

The PTV Routing API is used to calculate emissions on tour level, according to the international recommended guidelines described in the GLEC framework which focuses on the new ISO Standard emission calculation *ISO 14083:2023*.

This new feature reports the CO2e emissions plus many more values, which can be used for reporting on individual tours, transport orders or sales/purchase order level, or as mass data BI reporting KPI to measure and report ecological footprint of the company.

In detail, the following functions will be available when released for General Availability (GA, V1) in release CAP49.
- Selection of the emissions calculation method, and several setup parameters
- Specification of the fuel consumption and several engine types
- Specification of loading/unloading sequence on the tour
- Correct sharing/allocation of the emission costs between all transport orders within a tour

*Point 1-3 available already in CTP 1.0 (preview) in CAP48

Specification of the fuel consumption:
Indicating of accurate fuel consumption is key. The feature and ISO standard allows several sources: (sorted from the most to the less accurate):
- Individual measurement: use the actually-measured average consumption of the vehicle which is executing the tour, if you know it.
- Average value typical for the route: use the saved consumption data of a regular and similar trip.
- Average value typical for the vehicle: use the known average fuel consumption of the selected vehicle.
- Fleet value: use the known average consumption of your vehicle fleet. Note: the average consumption should come from vehicles of the same type.

*Point 4 (often used in industry) available already in CTP 1.0 (preview) in CAP48

Previously, Optimizer dispatching was only able to consider grouped resources as a single unit. Thus, even if a truck was combined with a trailer (or even an additional trailer), they were considered a single unit, combining both capacities and qualifications provided.
It is now possible to consider the coloading relevant information separately, via the new extended coloading restriction Algorithm.
A new parameter ('Extended coloading restriction') was added to Optimizer parameters>Algorithm>Plan tour options. Default value is 'No'. The value set on this parameter in Optimizer parameters is also displayed on the Optimizer dispatching form, where it can still be turned on/off.
When 'Extended coloading restriction' = No, the Optimizer runs only 1 iteration (previously existing behavior) - considering all resources as 'one'.
When 'Extended coloading restriction' = Yes, the Optimizer runs multiple iterations, which depend on number of resources with capacity > 0 combined together, restrictions for combined loading taken into consideration and qualifications provided by each of the resources considered.
To differentiate which Transport legs are assigned to which resources, a new ' Carrying resource' field can now be added and visualized in the Optimizer tour details. When such tourplans are released, the actual TMS tours being created have automatically new carrying resource assignments being created according to the Optimizer tours.

Additional debugging data can be visualized in a downloadable json file added to the Tourplan>Download content data lookup.

As long as iterations are still running, the tourplan status remains 'Calculating' and any KPI values being displayed or Optimizer tours are not the final results.

Depending on complexity of scenario being run (which dictates potential number of iterations), the duration of Optimizer processing to return a result may exponentially increase.

The usage of Google API key (for consuming Google API services) was moved from proxy into end client. This ensures that whole Google API url command (which contains encoded API key) cannot be extracted & misused.
The usage of Google API key itself is not critically sensitive (as its usage can be managed by dedicated security management (in Google account), but the Google API url command is sensitive (as it bypasses such security management).

Additionally, all google api components now use the Google API key (as specified in Azure environment variables). Previously some component were still using the hardcoded Google API key.

The recently introduced optional validation (by means of route/zone) at order entry in customer portal - is the entered address covered/valid in the network of the transport company, respecting the selected transport type and service level agreement (SLA) - is now managed by new dedicated parameter "Valid route/zone required" on the transport type.
Previously, the optional validation was active only when Date initialization load/unload was set to "Dynamic".

Via this feature it is now possible to define which function buttons are available (and which not) in main grids in both portals. The configuration is done in D365 via so called "button template" where all function button visibility is managed (per each portal), The function button availability in the portal grids is then dynamically evaluated for each record (eg. order), on the level of customer/vendor assignments. Hence the same portal user can have access to different action buttons, depending on customer account or transport type (on customer portal), or depending on vendor account (on carrier portal).

Key points:
- the main setup is done in D365 (in "Portal button configuration"), where all templates are managed
- Default templates can be specified in main TMS parameters, on customer account or transport type (for customer portal), on vendor account (for carrier portal)
- The effective templates (ie. the ones that are really reflected on the portals), are then stored on each portal user assignment, where templates are initialized automatically (in fixed priority sequence)
- In case no template is specified then all function buttons are shown

The Depot app user creation was added into the same step of the Driver creation wizard as where the Driver app/Truck loading app user creation already was. The new fields are dependent on the corresponding Depot App configuration key.

Important:
In case of mobile app custom implementation (either Driver app or Truck loading app), the change of integration schema has to be reflected in the custom implementation, to ensure that mobile app continue working even after the upgrade to 10.0-CAP48.0.

Relevant for customers who don´t use CAPcargo middleware and apps but use the Mobile app D365 integrations with their own app(s).

The changes are related to :
- 112045 Enhancements in handling of Dangerous goods
- 113147 Empties exchange
- 112673 Collect additional orders

New Mobile app activity types
- Collect new order (41) - used in activity feedback when the driver registers pickup of an order that was not planned in this tour
- Empties exchange (42) used in Empties exchange activities and activity feedback

New fields in Mobile app tour header (TALdraTourEntity):
- SHOWADRINFO (0/1) - Controls whether the app should show some Dangerous goods related information
- ICON2 - Name of an icon shown on the tour card (used only for Dangerous goods icons at the moment)

New fields in Mobile app tour stop (TALdraTourLineEntity):
- ADRVALUEARRIVAL (real) - Planned Dangerous goods calculated score upon arriving on this tour stop
- ADRLQARRIVAL - Planned dangerous goods limited quantity weight upon arriving on this tour stop
- ICON2 - Name of an icon shown on the tour stop card (used only for Dangerous goods icons at the moment)

New fields in Mobile app tour activity (TALdraTourActivityEntity):
- ICON2 - Name of an icon shown on the tour activity card (used only for Dangerous goods icons at the moment)
- QUANTITY2 - Another quantity that can be shown on the activity. Used only in Empties exchange activities at the moment (they have two quantities: inflow and outflow)

Driver can pick up orders that are not planned in this tour but are already available to be picked up.

Usability of the number entry activities (such as registering vehicle mileage) has been improved. Previously it was cumbersome to remove the default 0 value when typing a number.
Previously it was also posible to enter a negative value by clicking the "-" button. This has been prevented.

The user can now see the access point URL that the app is connected to. This information is shown in the About screen.

For items with hazardous material content - regardless whether WHS enabled or not -, the ADR score and the limited quantity weight are calculated and used in transport planning. The calculation, in both cases, follows the logic in standard D365 Warehouse management, even if the item is not WHS enabled. Compared to the standard logic, the only difference is making sure that in transport planning, the limited quantity weight is always in kg.

From a technical perspective, the ADR quantity will always be filled in from now on.

We don't provide any data migration job for existing data, in which the ADR quantity has value only if limited quantity is activated.

Next to the main danger and 2 side danger, a 3rd side danger is now available, as this can occur amongst the UN-numbers.

Previously, when Transport type parameter 'Register weight information' was set to Yes, the calculation of weight-related plan quantity on the Transport order line (at TRO creation, or at TRO additional line creation) was based on the transport unit gross weight + transport unit conversion rate for weight (multiplied, of course, with the Transport unit quantity).
The calculation logic was adjusted, so that:
- If Net weight = 0, then weight-related plan quantity is based on TU conversion rate for weight + gross weight (previous behavior)
- If Net weight > 0, then weight-related plan quantity is based only on gross weight per transport qty (new behavior)

New online Android mobile app, covering all activities within a Depot.

Existing 'Truck Loading App' is replaced by new 'Depot App'. The functionality covers the same and more requirements, mainly in the cross-docking area. New architecture and data model win an online approach ensure fast scanning performance and future extensibility. Relevant for customers who used Truck Loading App.

No data migration needed.
Organizational changes required from which moment on tours are not sent to the old Truck Loading App, but to the new Depot App.

Availability:
- CAP48: Public preview (CTP2)
- CAP49: Planned for GA

This data migration job cleans up 'orphan' subcontracting order lines (if any), which might have appeared in the system before the implementation of the fix for 112839 (as already announced, see CAP46).

The issue was happening only when customer assignment was created/saved in D365 with different customer account letter size (compared to database value). Eg. it was possible to save customer assignment against "migros", while the database name of customer account was "Migros". Such constellation then caused that Migros' orders were not available in the customer portal.
The issue was solved by proper sanitizing of customer assignment creation/saving in D365 (so "migros" is saved as "Migros").

The issue was only on GUI level (ie. "Price" field was enabled in order side details pane for user changes), but no harm was done to the data (as changed price was not saved into D365 backend).

Following issues were corrected - when changing the browser screen language (via dedicated language "flag") during address creation - following errors could have been encountered:
- address duplicity was wrongly detected (and users had to select between same address (one for "Switzerland", second for "Schweiz") or completely wrong address was offered for selection
- wrong map visualization

Previously the load/unload activity details often lacked information about the initial origin and final destination of the transport order, as well as origin/destination of the current transport leg.

Now we will always show following information:
- Heading to: Unload address of the current transport leg. Shown only when loading.
- Arriving from: Load address of the current transport leg. Shown only when unloading.
- Origin: Initial pickup address (load address of the transport order)
- Destination: Final destination address (unload address of the transport order)

Barcode scanning sound (beep) is now played also when scanning barcodes in the "New return order" process.

Access issues for 'Release to warehouse' in new shi-build V3 fixed.

The Goods arrival status (SCM status of predecessor transport leg) incorrectly indicated that the predecessor leg was not planned into a tour although it had been already dispatched. the issue was only present with cross-docking cases with more than 2 depot splits.

During several processes (such as creation of transport order and removal of transport order from dispatching), a warning message was sometimes shown (that the Customer X is blocked) and the process was cancelled.

Previously, during automatic creation of packages, the weight unit id on packages was taken from Transport parameters>Package management>Weight unit id instead of the Transport order line, causing a discrepancy when these two units were setup differently.

Previously, when Transport type was setup as a criteria in Tariff surcharge group, it was not respected when such surcharges were triggered during price calculation on subcontracting orders. The flag 'Negative' on the criteria setup was also misinterpreted.